Gefahrenpotential Emailanhänge - Können verdächtige Hinweise nahezu vermieden werden?
 

Guten Tag,

es gibt ja bekanntlich viele Hinweise die schnell auf eine „gefährliche“ Email hinweisen:
schlechte deutsche Grammatik, seltsamer Absender, verdächtiges Dateiformat .exe, .zip etc.
Allerdings können diese „Fehler“ doch relativ einfach ausgemerzt werden.

Gehen wir mal davon aus, dass sich ein PC mit einem Wurm infiziert hat. Dieser Wurm lässt sich noch nicht von einem Antivirenprogramm identifizieren. Der Wurm nutzt die Outlook Kontakte und sendet sich selbstständig an ein paar Kontakte und nutzt sogar eine persönliche Anrede und schreibt einen freundlichen Text mit Hinweis auf ein Dokument im Anhang. Im Anhang befindet sich ein Excel-Dokument mit Makro-Virus. Beispieltext: „Hallo Peter, im Anhang findest du einmal die Kalkulation. Kannst du diese bitte prüfen?“

Als alternatives Szenario könnte man sich auch eine Stellenanzeige im Internet vorstellen. Die vermeintlichen Bewerber schicken Ihren Lebenslauf und die Bewerbung als Word-Dokumente mit Makro-Virus. So könnte es ein gezielter Angriff sein.


Lässt sich hier eigentlich noch mit bloßen Auge ein Gefahrenpotenzial feststellen? Wie kann man sich optimal schützen?

100 % Sicherheit gibt es nicht. "optimal" kann es daher deiner Frage nach nicht geben. Maßnahmen, die die Sicherheit erhöhen wären

zuallererst: Regelmäßige Backup auf externe Medien, die örtlich getrennt sicher verwahrt werden. Man kann nicht oft genug schreiben, dass man für seine Backups selbst verantwortlich ist und sich darum zu kümmern hat! Letztenendes ist es auch völlig egal ob ein Plattendefekt, ein Wohnungsbrand, ein Dieb oder eben ein Kryptotrojaner zuschlägt

und:

1) Anhänge nur öffnen, wenn kurz vorher telefonisch o.ä. vereinbart
2) wo möglich kein Windows und/oder MS-Office einsetzen
3) Virenscanner sind zwar nur ein Hilfsmittel, aber gegen ransoms hat sich die Verhaltenserkennung von Emsisoft bewährt

Ja, das sind alles Maßnahmen, die Arbeit machen und im Falle von Emsi auch definitiv Kosten verursachen. Aber Sicherheit zum Nulltarif gibt es nicht...

Also zum einen gibt es schon so ziemlich seit Office Makros unterstuetzt, die Option nur signierte Makros auszufuehren. Eine solche Signatur laesst sich kinderleicht erstellen und verteilen, die Installation des Zertifikats erfordert allerdings mehrere Mausklicks, wovon einer auch an der richtigen Stelle sein muss.

Neuere Officevarianten benutzen den Protected Mode, da der aber von den Benutzern gerne weggeklickt wurde, hat Microsoft im neuesten Office Makros per Standard deaktiviert und man muss sie erst zulassen.

Also mit einem Office 2016 lebt man nach derzeitigem Stand recht sicher. Allerdings gibt es guenstigere Alternativen wie die Softmakervarianten, welche recht gut sind oder LibreOffice, Openoffice usw. Einige davon sind gar kostenlos. Zumindestens bei Softmaker Pro muessten die Makros angepasst werden allerdings ist die Softmaker-API weniger umfangreich.

Ein vernuenftiger Scanner ist nie verkehrt aber Cosinus hat recht, die Mustererkennung ist meist zu langsam.

Passende Dateizugriffsrechte anzulegen ist meist hilfreich, wenn keine Aenderungsrechte vergeben sind, dann kann die Ransomware im Dreieck springen, geloescht wird da nix.
Allerdings kann sowas auch bei Drittanbietersoftware recht nervig sein. Manche Software legt erst die Datei an und schreibt zu einem spaeteren Zeitpunkt den Inhalt. Solche Software funktioniert dann in entsprechend geschuetzten Verzeichnissen nicht bzw. legt nur leere Dateien an.

Man kann Verzeichnissen auch die Ausfuehrungsrechte entziehen, das hilft aber nicht unbedingt gegen Makroschaedlinge.

Vorallem aber sollte man wissen, dass viele Schaedlinge sich ohne administrative Rechte ueberhaupt nicht im System einnisten koennen und auch auf diverse Netzwerkfunktionen dann keinen Zugriff haben. Manche funktionieren in einem User-Account ueberhaupt gar nicht.

Es gibt allerhand, was man proaktiv tun kann.

Die Adminrechte sind hier völlig wumpe. Es reichen die Userrechte aus um die Datei zu zerhacken und im Zweifel hat der User kein (vernünftiges) Backup, Schattenkopien nicht aktiv oder seine zerhackten Dateien liegen auf einem NAS, das das Feature Schattenkopien nicht kennt.

Sicher kann man viel proaktiv tun. Aber damit müssen sich die laien auch erstmal beschäftigen, das wollen sie nicht und sowieso ist Sicherheit ja eh zu teuer :D also muss es so gehen => Virenscanner rauf, reicht :balla:

Anders kann man sich den Erfolg von locky mit 5000 Infektionen pro Stunde allein in Deutschland nicht wirklich erklären. :kaffee:

Naja, aber als Admin nutzt der Dateisystemschutz wenig da man ihn auch wieder aufheben kann, im schlimmsten Fall muss die Malware noch den Besitz uebernehmen.

Ebenso laesst sich eben der MBR und das Dateisystem nicht zerschiessen ohne Adminrechte.

Ich werf jetzt mal einfach was in den Raum.

Egal ob Emailanhang mit Wurm, Datei mit pöösem Makro, oder Ransomware, oder oder.

Was hat all das gemeinsam direkt nach Ausführung? Richtig, es wird erstmal auf die Platte kopiert, um dann ausgeführt zu werden.

Und beim kopieren/schreiben auf die Platte kommt wer und meckert? Richtig, das AV Programm.

Kann ich so genau nicht sagen ;). Bei mir hat es im letzten Jahrzehnt keiner unverschluesselt auf die Platte geschafft. Ist das noch so? *dreimal auf holzkopf geklopft*

Ich merke den Unterschied ob es ein bekannter Schaedling ist oder nicht, wenn die Mail gleich abgelehnt wird oder ich erst nach Tagen eine Bestaetigung bekomme.

Wenn der Schaedling auf der Platte ist, ist ja noch kein Hals und Beinbruch, solange er nicht ausgefuehrt wird. Wenn aber die Verhaltensanalyse anspringt, ist die Proverbiale schon am dampfen.

Was hatten das mit admin vs user zu tun?
Natürlich meckert im besten Fall das AV noch vor der Ausführung der malware, aber das ist doch egal ob man gerade mit Adminrechten rumturnt oder nicht.

@bombinho: Warum reitest du bei der crypto malware immer auf den eingeschränkten Rechten herum? Dem Anwender ist auch nicht wirklich geholfen wenn dank fehlender Rechte der MBR zwar noch intakt ist, aber seine Dateien trotzdem zerhackt wurden. MBR und Systemdateien lassen sich ja nun einfach recovern im Gegensatz zu all den persönlichen files.

Wie oft denn noch? Viele Infektionswege benoetigen zwingend Adminrechte. Und wenn das AV meckert, ist moeglicherweise bereits der Loader aktiv (Edit: oder anderer Unsinn im Gange).

Auch hier habe ich es oft genug gesagt, du wirst eine Datei ohne Aenderungsrechte nicht geaendert oder geloescht bekommen via Windows-API. Die Cryptomalware muesste dann alternative Dateisystemtreiber mitbringen um ueberhaupt etwas loeschen oder ueberschreiben zu koennen ergo geht nix verloren. Da ist nix zerhackt und wird nix zerhackt, vielleicht wird die Festplatte zugemuellt mit verschluesselten Daten aber die Originaldateien bleiben wo und wie sie sind.
Und wenn Dateisystem und MBR intakt bleiben, ging die ganze Attacke in Leere.

Das ist doch genau der Grund, warum Linux recht unanfaellig gegenueber den unter Windows ueblichen Attacken ist. Weil die Dateizugriffsrechte von vornherein schaerfer eingestellt sind.
Stell unter Linux aehnliche Zugriffsrechte ein wie unter einem adminbetriebenen Windows und da ist meist nicht mal mehr ein AV der dir noch die Hinterseite rettet.

Wie oft noch? Wie oft noch muss denn erwähnt werden, dass man für die crypto malware KEINE Adminrechte braucht?


Das ist doch Blödsinn. Wenn der ransom ohne Adminrechte gestartet wird, kann er zwar nix am System verfummeln aber die Userdaten zunindest des angemeldeten Users zerhacken. Und wie ich schon schrieb haben dann die wenigsten ein Backup oder Schattenkopien aktiviert. Oder die Daten lagen auf einem NAS.


Ach jetzt hast du diese Erkenntnis auch? :kaffee:
Du hast doch letztens da mit deinem python script etwas anderes behauptet oder nicht?
Fakt jedenfalls ist, dass man auch die Userdaten in einem unixoiden System zerhacken kann wenn "mutwillig" ein entsprechendes böses Script ausgeführt wird.

Es sei denn sie verschluesselt Dateisystem und MBR/VBR

Ich hoffe, alle Ransomware benutzt nur Standard-API-Zugriffe und versucht nicht via manipulierter Paketdaten mit dem CC zu kommunizieren um einen Private Key zu bekommen denn das geht ohne Adminrechte nicht und ohne asymmetrischen Schluessel wird es nix mit dem bombensichern Verschluesseln und anschliessendem Entschluesseln fuer Geld.
Ausserdem schafft die Malware es nicht ohne Adminrechte, das System zu blockieren um die Zahlungsaufforderung deutlich genug zu machen. Und die Ransomware schafft es auch nicht, sich zum spaeteren Entschluesseln festzusetzen.

Weiterhin kann Malware mit Adminrechten eben jede Rechteeinschraenkung des Dateisystems wieder aufheben, sprich Ausfuehrungsrechte und/oder Aenderungsrechte einraeumen.

So ganz nebenbei gibt es auch noch reichlich andere Malware, welche unterwegs ist und
auch Unfug anrichtet.

Ich habe gesagt, dass ein nicht/schlecht administriertes Linux auch nicht sicherer ist als ein nicht/schlecht administriertes Windows.
Aber wenn Du es gerne noch mal hoeren moechtest, Linux kommt oft mit sichereren Standardeinstellungen als Windows unter heutigen Gesichtspunkten.

Dass es angreifbar ist, ist ein Fakt. Dass es nicht angreifbar ist mit vielen unter Windows ueblichen Methoden ist auch richtig. Dass es auf jeden Fall angreifbar ist, wenn der Nutzer unbeabsichtigt mithilft gilt fuer beide Systeme gleichermaszen.

Und wieso straeubst Du Dich Windowsbenutzern Masznahmen zu empfehlen, die auch Linux sicherer machen?

Und so ganz nebenbei bin ich wirklich nicht geeignet um moegliche Szenarien fuer Linux zu durchdenken, da ich derzeit damit nur wenig Beruehrungspunkte habe.

Mal abgesehen von einem manipulierten Repo oder der Ausnutzung von uralten aber noch enthaltenen Luecken, wie bereits in der Vergangenheit demonstriert wurde.

In diese Richtung gehen ja gerne auch Angriffe auf IOS, OSX, Android. Nur dass dann eben die App-Shops/stores etc. unterwandert werden. Wenn ich mich nicht verbreiten kann, dann muss ich mich eben verbreiten lassen.

Okay, mir fiele noch ein, dass dank unverschluesseltem Dateisystem wahrscheinlich aehnliche Angriffe zur Bootzeit auf das Linux Rootpasswort denkbar waeren wie unter Windows auf das Adminpasswort.

Lies du eigentlich auch was ich schreibe? Ein zerhackter MBR ist doch völlig egal, kann einfach neu geschrieben werden. Es geht um die Dateien des Benutzers. Wenn die zerhackt sind hilft nur das Backup.


Das ist doch völlig irrelevant. Die Malware zerhackt die Daten, die sie zerhacken kann. Und für die Userdaten reichen die Rechte des Users, der die malware startet. Und um mit einem remoteserver zu kommunizieren braucht es auch keine Adminrechte.


Ja und???? :wtf:

Das Ziel von ransoms ist: Userdaten verschlüsseln!
Es geht fast garnicht um irgendwelche Dateisysteme, MBRs oder andere Systembereiche. Nochmal: die ransomware will in erster Linie den User treffen, nicht das System. Und Dateien zerhacken/verschlüsseln reicht da schon.

Dass man nicht ständig mit vollen Rechten ständig drin sei sollte ist ja wohl jedem klar. Aber die wenigstens beachten das, es ist unter Windows ja eh schon alles unkomfortabel genug, dann sind sie immer als Admin drin, dann wird auf Schattenkopien und Backups auch wenig bis garnicht geachtet.


Ja, aber das klang in dem anderen Thread von dir aber anders. Stichwort pythonscript. Und vorher in diesem Thread hast du das behauptet:

Also was denn jetzt? :wtf:


Das ist jetzt ziemlicher Dünnschiss. Ich ermutige keinen ständig als Admin drin zu sein. Nur lässt sich das irgendeinem DAU aber auch schlecht verkaufen, dass er sich für die Wartung, Installation von Programmen oder Updates erstmal ab- und als Admin neu anmelden muss oder per Rechtsklick => ausführen als... alles erledigen soll. Und das ist ne Sache die auch richtig nervt unter Windows.

Wie passen eigentlich die 5000 Locky Infektionen je Stunde laut Heise mit den Threads dazu in diesem Forum zusammen?

Hatte ich das nicht vor ein paar Tagen auch schon so ähnlich gefragt? :D

Ich kann nicht alles lesen. Aber ich halte die Heise Zahlen für eine starke Übertreibung. Gelinde gesagt.

Naja, in den ersten Stunden könnte das aber hinkommen. Und nicht jede Infektion führt bei jedem zu einem Totalschaden.

cosinus, zählt man aber auch Petya mit, dann werden nicht nur Userdaten verschlüsselt sondern die komplette Systemfestplatte, Petya lässt da wohl nichts aus und selbst ein reaparieren des MBR hilft nichts weil der Bootloader Windows nicht finden kann habe ich gelesen.
Quelle: http://www.computerbase.de/forum/showthread.php?t=1574127&page=2&p=18664454#post18664454

Natürlich braucht sowas wie petya Adminrechte. Aber um Userdateien zu zerstören braucht man die nicht. Ist das denn so schwierig nachzuvollziehen? :wtf:

Hat ja keiner behauptet das du nicht recht hast cosinus, wollte damit auch nur sagen das Petya ein anderes "Kaliber" ist als Locky, Teslacrypt usw.
Das ist ja das Problem bei Windows: das erste Benutzer Konto hat Adminrechte und sehr viele Anwender haben nur das eine Konto, das macht es Petya dann leicht.

Der Super-GAU wurde doch schon durch locky und andere ransoms davor erreicht: Userdaten zerhacken. Wenn jetzt noch durch petya zusätzlich das System beschädigt wird: na und? Das Betriebssystem ist wiederherstellbar. Notfalls eben zu Fuß über eine Windows DVD.

Naja, aber viele Laien sind bei sowas einfach komplett aufgeschmissen.

Korrigiere mich wenn ich falsch liege:daumenhocaber wenn Alles auf der Systemfestplatte von Petya verschlüsselt wurde und bis dato gibt es dafür ja noch kein Entschlüsselungstool ausser man geht auf die Erpresser ein dann kannste nix mehr herstellen und man müsste erst Diskpart clean oder vergleichbares ausführen um überhaupt die Festplatte nutzbar machen zu können. Wie also willst du dann Windows wiederherstellen können ohne Diskpart clean oder ein anderes Tool mit dieser Funktion ausgeführt zu haben? Erinner dich: der User im CB Forum hatte die Festplatte schon formatiert gehabt, hatte auch den MBR repariert und konnte trotzdem nicht Windows neu installieren, danach bekam er den Tipp mit Diskpart clean und erst danach konnte er wieder Windows installieren. Aber egal: ich wiederhole mich: mit der beste Schutz vor Petya, Locky oder Teslacrypt sind regelmässige Systembackups und Sicherungen persönlicher Daten wobei letzteres bei mir auch im jeden Systembackup von C drin ist weil ich relativ wenige wichtige persönlicher Daten habe in meinem Benutzerkonto.

hab ich doch geschrieben: Notfalls "zu Fuß" bei sowas wie petya alles neu installieren.

Dazu muss man ja erst mal die Festplatte so gelöscht haben das man Windows wieder installieren kann also etwas wie Diskpart oder vergleichbares einsetzen. besser: man hat Systembackups der gesamten Systemfestplatte inkl. MBR Mitsicherung oder zumindest von der Systempartition C ebenfalls inkl. mitgesicherten MBR.

man purzel, genau das soll "zu Fuß" doch bedeuten. Oder soll ich hier jetzten jeden Teilschritt erzählen :balla:

Nein sollst du nicht.
Kannste ja machen wenn du willst für die Mitleser die eben noch nicht wissen was eine Infektion mit Petya mit sich bringt. Dann wüssten die was zu tun ist und das übliche formatieren nicht ausreicht.

Dann ist ja gut :D

Wobei so ganz glauben kann ich das noch nicht, dass man da unbedingt die Platte vorher nullen muss. Das Windows-Setup erstellt bei der Installation einen neuen MBR. Einfach bei der Installation alle Partitionen auflösen und neu erstellen müsste eigentlich reichen.

Lese halt im anderen Forum was da geschrieben wurde. So weit ich mich erinnere hatte der betroffene User den MBR neu geschrieben und konnte aber trotzdem dann Windows nicht neu installieren. Dann wurde ihm erklärt was bei einer Formatierung nur passiert und das die Festplatte mehrfach mit Nullen überschrieben/gelöscht werden muss inkl. den MBR. Ich zitiere mal: Quelle: http://www.computerbase.de/forum/sho....php?t=1571643
Übrigens bekam ich das heute in etwa bestätigt von meinem Bekannten der einen 1 Mann PC Service hat: der hatte vor ein paar Tagen einen Kunden mit Petya, er hätte dem Kunden die Festplatte löschen müssen, aber das Glück war das der Kunde ein Backup hatte ich weiß jetzt aber nicht ob das ein Systembackup war oder Datensicherung das hatte ich nicht nachgefragt.

Ja, aber EIGENTLICH braucht man das nicht. Das Windows-Setup sollte allein in der Lage sein, einen neuen MBR zu schreiben. Der Typ in dem von dir verlinkten Thread hat doch nur die Platte ausgebaut und woanders (schnell) formatiert. Das ändert natürlich rein garnix am MBR.

Um den MBR zu killen braucht man nicht die gesamte Platte zu nullen. Das dauert ja auch viel zu lange ohne dass man davon einen echten Vorteil hätte.

cosinus, selbst das langsame formatieren reicht bei Petya nicht aus und auch nicht mit der Win DVD den MBR neu zu schreiben. Fakt ist so wie ich es verstanden habe das auf alle Fälle der MBR so gelöscht werden muss wie es Diskpart macht. Hat mir mein Bekannter auch so gesagt das ein formatieren oder neu schreiben des MBR bei Petya nicht reicht. Und eine Bitte(falls du es noch nicht gemacht hast:daumenhoc)lese den ganzen Thread durch und auch diesen: http://www.computerbase.de/forum/sho....php?t=1574127
Wichtig ist wohl der Sektor der Festplatte in der der MBR sitzt das der genullt wird würde ich jetzt tippen. Aber selbst wenn man nur den MBR Bereich nullen und dann den MBR neu schreiben würde, was würde das nutzen? Petya verschlüsselt alles auf der Systemfestplatte inkl. Windows Verzeichnis und von daher würde der MFT Windows nicht finden und Windows könnte nicht gebootet werden.

Es ist völlig wumpe ob langsam oder schnell formatiert wird. Das Formatieren erstellt nur das Dateisystem auf der angebebenen Partition oder dem Volume neu. Da wird nix am MBR gemacht beim Befehl format.

Und nochmal, wenn ich das Windows-Setup starte, daraus alle Partitionen auflöse und neu erstelle und dann auch in ein neu erstelltes Volume Windows hineininstalliere, muss das Windows-Setup auch einen neuen MBR erstellen.

Und sieh mal hier => https://de.wikipedia.org/wiki/Master_Boot_Record

Im Aufbau des MBR wird deutlich, dass wenn du diesen komplett nullst, also die ersten 512 Byte, dann überschreibst du nicht nur den Bootloader, sondern auch die Partitionstabelle. Also sieht die Platte danach komplett leer aus. GPT ist natürlich etwas anders aufgebaut => https://de.wikipedia.org/wiki/GUID_Partition_Table

Was schreib ich denn die ganze Zeit mit Verweis auf das andere Forum? das eben formatieren nicht reicht und mit Verweis auf die beiden Threads das ein neu schreiben des MBR wohl nicht reicht und dieser Sektor der Festplatte wohl genullt werden muss weil sich Petya wohl teilweise so stark da reinsetzt das es das neu schreiben des MBR überstehen würde. Wenn du es besser weißt(oder denkst du weißt es besser als die User des anderen Forums)cosinus, dann ist es eben so.

Du reißt meine Postings wieder voll aus dem Kontext! :kloppen:

Ich hab nie behauptet, dass ein einfaches Formatieren reiche, aber du hast meine Ausführungen mit dem Windows-Setup weggelassen! :twak:

Und bei MBR gibt es kein stark reinsetzen! Wenn du die ersten 512 Bytes einer MBR-Schema-HDD null, dann sieht die danach völlig leer aus! Und genau dieser MBR wird bei einem Windows-Setup auch neu geschrieben.

Deswegen versteh ich nicht, warum man ein diskpart clean all machen muss wenn die Theorie etwas ganz anderes besagt.

Was befindet sich denn in den ersten Sektoren einer Festplatte und warum und was wird von welchem Befehl wie ueberschrieben? Das waere eventuell die Antwort.

Und auf welchen Wegen kann man sicher stellen, dass man in der Bootreihenfolge vor dem OS steht? Ich hoffe, dass solche Grundlagen gelehrt werden bei der Ausbildung zum Malwarejaeger.

Wobei es da noch alternative Konzepte gibt, die von konventionellen Bootkits zum Beispiel genutzt werden um vor Ort zu bleiben.

Dir ist schon klar, dass purzel hier nicht zum malwareteam gehört? :rolleyes:

Purzelbaer nicht, das ist korrekt.

https://blog.malwarebytes.org/threat...ya-ransomware/

Die Screenshots enthalten auf den zweiten Blick allerhand Informationen wie Offsets und Sektornummern.

cosinus, so wie ich das bei dem einen User verstanden habe, konnte er nach dem formatieren der Festplatte das Setup der Windows CD nicht starten und Petya kam dem zuvor: Wie also hätte er den MBR mit dem Windows CD Setup neu schreiben sollen? Ausserdem vermute ich das selbst das petya im MBR überlebt, denn: Quelle: https://translate.google.de/translat...e/&prev=search

Purzelbaer, kennst Du den prinzipiellen logischen Aufbau von Festplatten?

Also die Unterteilung in Zylinder, Kopf, Sektor? (Ahh, ich glaube im Deutschen eher Spur statt Zylinder)

Nein.

Also, Du musst Dir das so vorstellen, dass da nicht wie auf einer CD/DVD usw. eine Spirale drauf ist sondern die Spuren sind geschlossene Ringe. Da sich aber mehrere Platten (Also Festplatten-Platten) drin befinden koennen, haben diese Platten Lesekoepfe. In so eine Spur passen aber mehrere Sektoren.

Wenn ein Rechner auf eine Platte zugreift, dann muss er in der Lage sein, die Daten zu finden. Also befindet sich auf der ersten Platte in der ersten Spur im ersten Sektor der MBR.

Dieser MBR koennte jetzt enthalten, wo die Daten auf der Platte liegen aber dann koennte man nicht starten. Enthielte er aber ausfuehrbare Daten, dann wuesste man nicht, wo das Betriebssystem ist. Also enthaelt er normalerweise als allererstes eine Anweisung, das folgende zu ignorieren und mit der Ausfuehrung erst an einem etwas entfernten Punkt weiterzumachen.

Dieser uebersprungene Datenbereich enthaelt nun (normalerweise) die Partitionstabelle, also quasi die Daten, wo sich Daten befinden.

Und danach kommt dann der Code, der festlegt, was weiterhin passieren soll.

Nun ist es aber so, dass eine Partition niemals in dieser Spur anfaengt sondern fruehestens in der naechsten. Darum sind da einige scheinbar ungenutzte Sektoren.
In diese Sektoren werden gerne Bootmanager geschrieben.

Befaende sich so ein Bootmanager in Spur 0, dann wuerde der ausfuehrbare Code des MBR so umgeschrieben, dass im Anschluss der Bootmanager ausgefuehrt wird.

Das normale Neuschreiben des MBR wird aber tunlichst die Partitionstabelle unangetastet lassen, weil das ansonsten ein Totalverlust der Daten sein koennte. In dieser Partitionstabelle ist festgelegt, welche Partition ohne Bootmanager gestartet werden wuerde.
Es wird nur der ausfuehrbare Code ersetzt, welcher dann in aller Regel den Bootmanager ignoriert und an der in der Partitionstabelle angegebenen Stelle weiterbootet.

Nun koennte man den Bootmanager, wenn vorhanden, manipulieren oder einen eigenen benutzen um vor dem OS zur Ausfuehrung zu kommen.

Man koennte aber auch die Partitionstabelle so manipulieren, dass der eigene Code als naechstes ausgefuehrt wird und dann die Originale als virtuelle Partitionstabelle zur Verfuegung stellt. Da koennte aber ein Bootmanager reinfunken.

Petya kuemmert sich um die Konventionen mehr oder weniger gar nicht sondern ueberschreibt den MBR samt Partitionstabelle.

Ob der Speicherbereich mit der Partitionstabelle so manipuliert ist, dass Petya trotzdem zur Ausfuehrung kommt, das ist leider in der Analyse nicht beschrieben.

Aber durch das Ueberschreiben der Partitionstabelle alleine ist, vor allem bei stark fragmentierten Systemen fast vollstaendiger Datenverlust die Folge. Petya aber speichert die ueberschriebenen Sektoren vor seinem eigenen Code mit einer Verschleierung (Xor "7"). Also liesse sich das alles recht gut Wiederherstellen, wenn Petya nicht auch noch das gesamte Dateisystem verschluesselt haette.

Sorry, irgendwie war der erste Teil verloren gegangen.

Im Prinzip kommt, solange das Bios nicht komplett von einem anderen Datentraeger bootet bis zur Eliminierung von Petya immer Petya, Petyafragmente oder zufaelliger Code zur Ausfuehrung.

Ich hab noch eine Info meines Bekannten mit dem ich gerade telefoniert habe: er sagte mir das Windows Setup der Windows CD konnte wegen der Petya Infizierung die Festplatte nicht erkennen und die Festplatte hatte ein ganz anderes Dateisystem gehabt durch Petya. Selbst wenn er es versucht hätte den MBR neu zu schreiben mit dem Setup, wäre das deshalb gescheitert weil schlicht und ergreifend die Festplatte nicht vom Windows Setup erkannt werden kann duch das veränderte Dateisystem.

Jupp, siehe den Teil mit der Partitionstabelle.

Vielleicht muss ich noch die Partitionstabelle erklaeren.
Auf einer Festplatte koennen mehrere Laufwerke sein. Also zum Beispiel C:, D:, etc.

Das sind natuerlich keine Festplatten sondern Partitionen. Und wo genau diese sich befinden, dass ist (normalerweise) in der Partitionstabelle enthalten.

Hat Petya diese zerstoert, dann weiss niemand, wo die sein sind, aber wie erwaehnt, laesst sich das relativ einfach wiederherstellen. Aber nach der Wiederherstellung sind die verschluesselten Daten mehr oder weniger entgueltig verloren, da dabei die zur Entschluesselung notwendigen Informationen von Petya ueberschrieben werden.

Deswegen ist es immer anzuraten, einen solchen Datentraeger auszubauen und vorerst mit einem Neuen weiterzumachen, fuer den Fall, dass z.B. eine Schwachstelle in der Schluesselerzeugung oder die Schluesseldatenbank gefunden werden.

Auch wenn sich nur ein Laufwerk auf der Platte befindet sind natuerlich z.B. Anfangspunkt und Endpunkt in der Partitionstabelle enthalten.

Deswegen kann man Laufwerke auch Verkleinern oder Vergroessern (solange es der Platz hergibt).

bombinho, selbst wenn man den MBR samt Partitionstabelle wiederherstellen könnte, hätte man dann als User das Problem das Petya alles auf der Systempartition/Systemfestplatte verschlüsselt inkl. Windows Verzeichnis und nicht nur wie bei Locky oder Teslacrypt nur das Benutzerkonto was da drin ist. Andererseits habe ich im G-Data Blog gelesen das Petya nur auf die Systemfestplatte losgeht und das lässt die Hoffnung das andere Partitionen auf der Festplatte verschont bleiben. Wie ich aber die Hacker einschätze wird es eine neue Generation von Petya geben die alle Partitionen wenn nicht sogar alle Festplatten im Computer verschlüsselt.

Leider ergibt sich aus der Analyse auch nicht, inwiefern eventuell vorhandene mehrere verwendete Platten angegriffen werden und ebensowenig, wie mit Laufwerken mit mehreren Partitionen verfahren wird. Sollte nur die Betriebssystempartition ein verschluesseltes Dateisystem haben, koennte es durchaus lohnend sein, die originale gespeicherte Partitionstabelle wiederherzustellen.

Denn dann waere die Datenpartition einfach wieder da. Aber es trennen nur wenige Leute bewusst ihre Partitionen. Immerhin ist es mir schon bei vielen vorkonfigurierten Rechnern untergekommen, dass mehrere Partitionen angelegt waren.

@purzelbaer:
Naja, wenn jemand meine Systemplatte zerschmeisst, dann kann ich da nur muede drueber laecheln, denn ausser dem OS und den Programmen ist da nix weiter drauf. (Okay, falsch, es sind noch einige temporaere Daten drauf)

Im schlimmsten Fall habe ich danach ein frisch aufgesetztes System mit weniger Altlasten.

Aus diesem Grund mache ich von meiner Systemplatte auch keine Backups.

Petya verschluesselt nicht Alles, es lassen sich Sachen aus den Rohdaten wiederherstellen.
Eine moderne Festplatte mit grosser Kapazitaet voll zu verschluesseln wuerde viele Stunden bis Tage dauern.

Ja, die kurzen Codeschnipsel sehen geradezu aesthetisch aus. Da steckt mit Sicherheit noch Einiges in der Pipeline. Ich hoffe nur, dass der/diejenigen nicht an Exploits oder aehnliches kommen.

Allerdings wird das nicht ganz trivial mit dem Verschluesseln von weiteren Platten, denn moderne Dateisysteme koennen ganz schoen kompliziert sein. Ein Laufwerk kann ueber mehrere Partitionen oder gar Platten verteilt sein. Platten koennen mehrere Partitionen enthalten, Partitionen koennen mehrere Laufwerke enthalten und nahezu beliebige Mixturen davon usw.

Also nochmal, ganz von Anfang:

1.) User baut infizierte Platte aus
2.) schließt die Platte an einen anderen (nicht infizierten) Rechner (USB?) an
3.) löscht da die bestehenden Partitionen
4.) erstellt eine neue und formatiert diese

Das einzige was da im MBR geändert wird, ist die Partitionstabelle: Partitionen löschen und neu anlegen. Ein Format der Partitionen ändert nix am MBR. Wenn Partitionen gelöscht oder erstellt werden wird auch nur der Teil für die Partitionstabelle angefasst, mehr nicht, also nicht der Teil mit dem Bootloader. Deswegen ist es da auch folgerichtig, dass der Bootloader von Petya da noch drauf ist.

Das Teil kann aber niemals vor dem BIOS/POST erscheinen, da erst später versucht wird von einem Laufwerk wie Festplatte, DVD oder USB-Stick zu booten. Die Reihenfolge ist ja BIOS hinterlegt. Wenn der Schreiberling da meint, er wolle ins BIOS mit F1, sieht aber dann den petya, dann hat er bestimmt was falsch gemacht. Zu spät die Setuptaste (um ins BIOS zu kommen) gedrückt oder es war garnicht F1. Mit F1 kommt man auch meistens nicht ins Setup. Das ist aber vom Hersteller abhängig; ich kenne F2, F10 und ENTF (DEL), fürs Bootmenü F8, F11 oder F12. Aber F1 um ins BIOS zu kommen daran kann ich mich nicht entsinnen.

Vgl http://winfuture.de/videos/Software/So-funktioniert-der-Krypto-Trojaner-Petya-16005.html

Das kann so garnicht sein. Vllt kann das Windows-Setup die Partitionen nicht mehr lesen, weil nicht nur die MFT verschlüsselt wurde. Windows weigert sich auch von einem intakten Dateisystem zu lesen, wenn es auf dem "falschen" Partitionstyp liegt. (zB bei Linux-fdisk kannst du das schön sehen und editieren)

1. Regel der Datenrettung: Nie auf dem Originaldatentraeger schreiben. Und nie meint nie ohne Ausnahme bis eine erfolgreiche Datenrettung abgeschlossen ist.

Aber korrekt ist, hat man keine alternativen Datentraeger und ist bereit Kompromisse einzugehen und die Daten erstmal abgeschrieben hat, dann ist alles, was man wiederbekommt ein Gewinn.

Bei Vorhandensein von mehreren Partitionen wuerde ich mir das von Malwarebytes.org vermittelte Wissen zunutze machen, und die originale Partitionstabelle von Hand wiederherstellen. Dann sind unter Umstaenden wenigstens die anderen Partitionen nutzbar.

Die Systempartition ist vermutlich Schrott, wenn nicht ein Wunder geschieht. Aber wir hatten ja schon ein oder zwei davon.

Vielleicht solltet ihr noch zusätzlich erwähnen, dass das BIOS sich NICHT auf der Festplatte befindet.

cosinus ich kann dir nur sagen das mir mein Bekannter sagte das das Windows Setup die Festplatte nicht erkennen/finden konnte und das das Dateisystem der Festplatte wohl geändert wurde und nicht mehr NTFS war. Ob er die Festplatte ausgebaut hatte und an einem anderen PC angeschlossen hatte, das weiß ich nicht habe ich auch nicht danach gefragt.

Vllt sollten wir bei petya auch erwähnen, dass da kein echter Totenschädel im Monitor sitzt :D

So, das ist schonmal Quatsch. Ich denke hier werden wieder mehrere Dinge in einen Topf geworfen.

1.) Wenn die Platte angeblich nicht gefunden wurde, kann dein Bekannter nicht wissen, welche Dateisysteme Windows auf den Partitionen überhaupt noch erkannt hat

2.) eine Partition ist keine Festplatte, sondern immer nur ein Bereich (Intervall) auf einer Platte, der sich von Sektor A-N erstreckt

3.) wenn petya das Dateisystem und den MBR zerschießt ist es nicht wirklich verwunderlich, dass Windows nicht mehr unbedingt ein NTFS erkennt wo ein NTFS sein sollte

4.) MBR, Partition, Dateisystem...das sind alles Dinge die sich auf der Platte selbst abspielen, für das Betriebssystem und den Menschen wichtig sind um die Platte vernünftig benutzen zu können, aber die Platte selbst weiß von diesen Konstrukten im Prinzip nix. Sie ist ja nur ein "dummes" blockdevice.

Also nochmal kurz: das Windows-Setup von DVD muss auch eine infizierte Platte sehen, also auf jeden Falls das Gerät selbst. Aber wie es die Partitionen erkennt steht auf einem anderen Blatt. Auf jeden Fall kann man aus dem Windows-Setup alle Partitionen löschen, neu erstellen, einen neuen MBR schreiben oder eben die Platte komplett nullen wenn man denn unbedingt will.

Neue Erkenntnisse von G-Data zu Petya die Usern mit Geduld Hoffnung machen könnten:
Quelle: http://winfuture.de/news,91710.html

Naja, das muss nicht korrekt sein. Zum einen koennen sich Kopien des Bios bei manchen Herstellern auf der Platte befinden, quasi als Sicherungsmasznahme und zum anderen ist das Bios ja bei neueren Rechnern oft kein Bios mehr sondern eine Biosemulation von der UEFI Firmware, welche wiederum Module auf der Festplatte haben kann.

Aber richtig ist, dass sich die beim Start auszufuehrenden Startroutinen zumindestens teilweise auf dem (x)ROM befinden muessen.

Kann es bei modernen Systemen mit UEFI echt sein, dass man nicht mehr ins Setup kommt, weil die Festplatte kaputt oder überschrieben ist? Ich komme ganz ohne Festplatte problemlos in mein BIOS...

Zumindestens vorlaeufig nicht. Aber UEFI ist sehr flexibel und kann zum Beispiel das Laden einer eigenen Benutzeroberflaeche erlauben, das wuerde dann von der Platte nachgeladen werden ohne sich um die Partitionstabelle oder das zu ladende Betriebssystem zu kuemmern.

Es koennte hoechstens kritisch werden, wenn die Sicherheitskopie auf der Platte zur selben Zeit zerschossen wird wie die Laderoutine im Bios. Im Prinzip ist dann meist ein Urloader implementiert, welcher in einem ROM sitzt und nicht umprogrammiert werden kann. Der wuerde im Falle eines als nicht startbar gekennzeichneten Bios versuchen, das Bios wieder von der Platte zu laden. Ist dieses auch hinueber, ist es natuerlich unguenstig und abhaengig, was der Hersteller implementiert hat, wie dann verfahren wird.

Es ist auch denkbar, dass der Inhalt des (x)PROMs mit der Kopie auf der Platte beim Startvorgang verglichen wird aber das wuerde dann die Frage aufwerfen, welches von beiden denn tatsaechlich manipuliert ist.

Machbar ist vieles und es ist am Ende vom Hersteller abhaengig, ob und wie zusaetzliche Sicherheit geboten wird.

Es gibt wohl schon Hersteller, die ein Modul anbieten, welches einen Browser und einen Mediaplayer beinhaltet. Und da das Ganze sehr einfach aufgebaut ist, ist es quasi fast sofort nach dem Einschalten funktionsfaehig.

Der Ersteller des UEFI Moduls ist in der gluecklichen Position, er muss sich weder um Kompatibilitaeten mit anderer Software oder Hardware kuemmern und hat obendrein noch die Hardwarespezifikationen zur Verfuegung.

Das kann auch schon passieren, wenn man noch ein altes System mit nur BIOS hat. So einen Fall hatte ich vor ein paar Jahren bei Nachbar's Notebook gesehen...defekte Platte war drin, hat alles blockiert. Man ist nichtmal mehr ins BIOS gekommen, kurz: das System war quasi tot, nicht mehr benutzbar. :kaffee:

Okay, da hat Cosinus allerdings recht, wenn das Bios nicht ueber die beep codes hinauskommt, dann ist es Essig.

Aber soweit mag ich (bei Malware) nicht mal denken, gleichwohl ein Niederlaender? zu dem Thema mal referriert hat.

https://www.youtube.com/watch?v=HitPEFU7EVY

Naja, bei solchen Fehlern muss man dann halt sehen und systematisch vorgehen. Ein Laufwerk nach dem anderen abklemmen und schauen ob das System (POST) dann hochkommt bis man das schuldige Gerät identifiziert hat. Das hat jetzt aber nix mit Infektionen/malware zu tun

Naja, Angriffe auf die Hardware sind jetzt auch nichts ganz Neues bei Malware.

Wenn man mal die derzeitigen Trends weiterspinnt, dann koennte auch ein Malwareschreiber mal auf die Idee kommen, die Firmware der Festplatte zu manipulieren, machbar ist das offensichtlich und die einzige Voraussetzung dafuer sind Adminrechte.

Wozu denn die Firmware der Platte ändern, der Aufwand ist doch viel zu hoch. Es ist doch viel einfacher auf die Blödheit der Masse zu setzen:

- der User bekommt eine Spam-Mail aus sonderbare Quelle, dort ist ein Link auf eine Datei in Dropbox
- klickt auf den Link und landet auf der Dropbox-Seite
- lädt selbstverständlich die Datei da runter :D (das geht bei Dropbox aber nicht automatisch, da kommt man zu einem Dialog und muss gezielt "download" wählen!)
- der User entpackt das heruntergeladene Archiv und startet selbstversändlich die entpackte ausführbare Datei
- da das Virus Admin-Rechte braucht, fragt Windows nochmals nach einer Bestätigung (UAC)
- User nickt die Bestätigung natürlich ab


:rofl:

Wenn man soviel Mithilfe seiner Opfer erwarten kann, kommt für die Masse eher nochmehr davon als doch eher sowas Gezielteres wie Firmware-Manipulationen. Ich weiß nicht genau wie das funktionieren kann, stelle mir aber so eine Art undokumentierte SATA-Befehle vor, mit der man die Firmware in der Platte irgendwann überreden kann, sich zu ändern/überschreiben - aber dann müsste der Pöhsewicht ja auch schon genau wissen welche Firmware auf welche Platte genau da er raufpacken will und woher weiß er eigentlich, dass die "geheimen" SATA-Befehle bei jedem Modell oder gar Herstellerübgreifend gleich sind?

Wie stellt denn der Pöhsewicht sicher, dass seine neue gepatchte Firmware keine Bugs hat, die zu einem no booter führen? :confused:

Ich glaub, der Aufwand rechnet sich einfach nicht nicht. Oder kannst du das Gegenteil beweisen/erörtern?

Prinzipiell richtig, aber wenn es um blosse Zerstoerungswut geht, muss man sich keine Gedanken um das was und wo machen sondern einfach nur ein paar Nullen schreiben und fertig.

Ähm ja...:wtf:...um diesen niederen Trieb auszuleben müssen die malware creator also unbedingt deiner Meinung nach an der Firmware rumbasteln? Oder doch nur "Nullen schreiben"? :D

Naja, ein paar Nullen an der falschen Stelle + Backup ist ja offensichtlich Zeitverlust. Aber an der richtigen falschen Stelle ist dann mehr oder minder auch wirtschaftlicher Verlust garantiert.

Und ohne professionelle Hilfe sind alle Daten in Sekundenbruchteilen statt vielen vielen Stunden wech.

Theoretisch koennte man gar ein paar Bytes der Firmware verschluesseln und die Enschluesselung etwas unter dem Preis einer professionellen Datenrettungsfirma anbieten.

Der Thread ist irgendwie entgleist in Richtung Bootviren/Bootkit-Tutorial? :rofl:

Na dann: http://www.malwaretech.com/2015/06/hard-disk-firmware-rootkit-surviving.html
Es stimmt wohl so, man kann der Platte irgendwelchen Untergrund-ATA-Schrott senden und die Firmware überschreiben.
Nach derzeitigem Stand soll das ausschliesslich im Kernelmodus möglich sein. Wenn der Angreifer bei hiesigen Windows-Systemen im Kernel landet, ist sowieso etwas grundsätzlich schief gelaufen.

Grüsse und frohes Bootkit-Coden!
Microwave

Naja, wenn wir schon beim Anleitungen schreiben sind, dann wuerde ich noch auf den Bootzeitpunkt verweisen ;)

[SARCASM]
Die paar Millisekunden sollte der Nutzer ja nun auch noch warten koennen.
[/SARCASM]

Ja, wenn man bedenkt, dass sich das ganze auf ein XP - Projekt bezog ...

Da sieht man es mal wieder, wir brauchen unbedingt mehr "Trusted Hardware".

Da haben wenigstens nur wenige Zugriff auf die Zertifikate und garantiert nicht der Nutzer.