Saldırganlar haben laut einem Bericht von Golem ein gefälschtes Jobangebot genutzt, um eine zentrale Windows-Sicherheitsgrenze zu überwinden. Das Muster ist Verteidigern inzwischen vertraut: Eine überzeugende Recruiting-Ansprache – ein Headhunter, eine Programmieraufgabe, ein Dokument oder Werkzeug zum Prüfen – bringt das Ziel dazu, etwas auszuführen, und genau dieser Code zählt, nicht der Lebenslauf.
Im beschriebenen Fall galt der Angriff dem Windows-Kernel. Statt einer Speicherfehler-Lücke setzen solche Kampagnen zunehmend auf einen legitimen, aber verwundbaren signierten Treiber – die Technik bring your own vulnerable driver –, um bösartigen Code auf der höchsten Privilegienstufe zu laden und die Schutzfunktionen abzuschalten, die ihn sonst stoppen würden.
Attraktiv ist der Ansatz gerade deshalb, weil er das Modell untergräbt, auf das Nutzer bauen: Der Treiber ist signiert, also vertraut das Betriebssystem ihm; der Code, der ihn missbraucht, muss gar keine neue Lücke sein. Abwehrmaßnahmen existieren – Microsofts Sperrliste für verwundbare Treiber, Speicherintegrität und die dafür nötigen virtualisierungsbasierten Sicherheitsfunktionen sowie Regeln zur Verringerung der Angriffsfläche –, doch jede muss aktiviert sein, und Hardware-Unterstützung ist eine Voraussetzung, die nicht jede Flotte erfüllt.
Die Lehre betrifft weniger einen einzelnen Fehler als den Köder. Recruiting-basiertes Social Engineering funktioniert weiter, weil es Ehrgeiz statt Neugier adressiert: Eine Nachricht, die schmeichelt, wird geöffnet, eine Datei, die wie eine Testaufgabe aussieht, wird ausgeführt. Awareness-Schulungen, die vor Rechnungen warnen, sind mit Ködern, die als Karrierechance auftreten, nicht mitgewachsen.
Die praktischen Empfehlungen folgen direkt daraus. Unaufgeforderte Angebote mit Anhängen, ausführbaren Dateien oder Prüfaufgaben sollten bis zum Beweis des Gegenteils als feindselig gelten, solche Dateien gehören in eine isolierte Umgebung, und der Kontakt sollte über einen selbst gewählten Kanal bestätigt werden. Administrativ gilt: prüfen, dass Sperrliste und Speicherintegrität auf verwalteten Rechnern tatsächlich aktiv sind – und es nicht anzunehmen.
