Jump to content
Melde dich an, um diesen Inhalt zu abonnieren  
Knorkator

Infizierte Datei öffnet Windows Script Host obwohl per Reg Deaktiviert

Empfohlene Beiträge

Hallo zusammen,

 

ich habe bei uns den Windows Script Host per Registry Eintrag deaktiviert.

HKLM\Software\Microsoft\Windows Script Host\Settings -> Enabled = 0

cmd und cscript.exe bzw. wscript.exe liefert die gewünschte Meldung: Der Zugriff... deaktiviert..

 

Nun kam per Email eine .rtf Datei welche ich in einer VM ohne LAN (aber mit aktiviertem Reg-Schlüssel) zum Test geöffnet habe um mal zu schauen wie gut die Systeme funktionieren.

Um mal zu schauen was die infizierte Datei so veranstalten möchte, habe ich die Makros mal aktiviert.

Nach Aktivierung der Makros bekomme ich eine Fehlermeldung vom Windows Script Host, dass in Zeile 9 ein Fehler ist.

Fehler: Die angegebene Ressource konnte nicht gefunden werden.

 

Nun frage ich mich.. warum wird der manuelle Aufruf des Windows Script Host verweigert, per Word Makro aber zugelassen?

Mit dem Schutz ist dann ja nicht so weit her wie mir scheint.

 

An das Makro komme ich durch den Passwortschutz leider nicht dran.

 

 

 

 

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Achja.. das Script erzeugt eine Temporäre .VBE Datei im Temp Ordner.

Hier mal der "Code" sowie die Fehlermeldung als Screenshot

 

z3o3dcrw.jpg

bearbeitet von Knorkator

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Um mal zu schauen was die infizierte Datei so veranstalten möchte, habe ich die Makros mal aktiviert.

Meistens versuchen diese Programme nach der Infektion als erstes den eigentlichen Schadcode nachzuladen. So ja auch bei dir von "store.clarksvillevw.com", einem vermutlich ebenfalls gehackten Server.

Ohne LAN bekommst du den genannten Fehler, "die angegebene Resource kann nicht gefunden werden". Ohne nachgeladenes php-File kannst du natürlich auch nicht sehen, was der eigentliche Schadcode veranstalten würde.

 

Auch in Powershell ist das Schutzlevel vor Malware-code über "set-executionpolicy" maximal als nice2have zu bezeichnen. Es gibt etliche einfache Wege, diese Policy zu umgehen. Ich denke, in VBS wird es nicht anders gewesen sein.

 

Ein mögliches Schutzkonzept vor Malware dieser Art mit Windows-Boardmitteln wäre übrigens "DNS-Sinkholing" evtl. gepaart mit einem Honeypot-Server.

 

blub

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo,

 

ich implementiere eben die SRP gemäß NSA Dokument (das wurde ja in den letzten Wochen häufiger erwähnt) und habe dann mal cscript.exe explizit verboten... und siehe da.. das Makro wird nun korrekt geblockt.

Also ist der Registry Eintrag auch nur ein "nice2have".

 

Da fällt mir grade auf.. cscript.exe wird im Dokument ja nur zufällig erwähnt... wenn man dies nicht explizit verbietet hat man im fall von Locky etc. auch nicht viel gewonnen oder sehe ich das falsch?

bearbeitet von Knorkator

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

An das Makro komme ich durch den Passwortschutz leider nicht dran.

Was für ein Passwortschutz? VBE läßt sich mit scrdec14.exe relativ leicht wieder in lesbaren Code verwandeln :-) Wenn Du's net findest, schick mir ne PN.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Moin,

 

Nun frage ich mich.. warum wird der manuelle Aufruf des Windows Script Host verweigert, per Word Makro aber zugelassen?

 

wenn man die Frage etwas anders liest, wird am ehesten ein Schuh draus. Mehr oder weniger zufällig nutzt der hier betrachtete Trojaner den WSH. Müsste er ja nicht, er könnte auch den Scripthost von Office direkt nutzen.

 

Man sollte sich daher durch das Abschalten oder Verbieten des WSH nicht auf der sicheren Seite wähnen. Dafür sind aktuelle Angriffe meist zu gut gemacht. Insbesondere Locky gilt derzeit als ein richtig feines Stück Malware ...

 

Gruß, Nils

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Hallo Nils,

 

das abschalten des Windows Scripting Hosts per SRP bietet scheinbar einen besseren Schutz als die häufiger anzufindende Lösung per Registry Key.

Vollständige Sicherheit gibt es ja nicht.. man sollte nur nah dran sein.

:)

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen

Ich kann hier nur nochmals darauf hinweisen, das man die SRP im Default-Modus  "Alles verbieten", mit entsprechenden Ausnahmen, betreiben sollte. Dort ist  auch definiert, was ein ausführbares Programm ist. Die Ausführung  der Word-Makros kann so nur schwer verhindern. Die Ausführung der runtergeladenen EXE-Files aber  auf jeden Fall (die sollten aber schon am Proxy abgefangen werden). Die aktuelle Welle der Javascripte lässt einem so auch kalt.

Word-Macros sind gerade aus der Mode.

Diesen Beitrag teilen


Link zum Beitrag
Auf anderen Seiten teilen
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte überlege Dir, ob es nicht sinnvoller ist ein neues Thema zu erstellen.

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
Melde dich an, um diesen Inhalt zu abonnieren  

×