Microsoft Exchange Breach-Infektion – Post-mortem

Unglücklicherweise mussten wir teilweise feststellen, dass Patches zur Behebung der Exchange-Schwachstellen zwar eingespielt wurden, jedoch trotzdem bereits Web-Shells auf Systemen platziert waren.

Durch das Anwenden der Patches werden die Schwachstellen zwar behoben, es werden jedoch keine Systemänderungen, Kompromittierungen oder zusätzliche Backdoors bereinigt, die Angreifer möglicherweise bereits VOR dem Patchen auf den Systemen platziert haben.

Wie im Beitrag C&C Traffic durch HAFNIUM Gruppe bereits beschrieben, gilt es als erstes die Infektion festzustellen und Updates einzuspielen bzw. Schutzvorkehrungen zu treffen.

Verifizieren Sie unbedingt nach dem Updatevorgang, ob die Schwachstelle auch tatsächlich behoben wurde bzw. ob sich noch Web-Shells auf den Systemen befinden.

Microsoft stellt hier auf GitHub Test- und Mitigation-Scripte bzw. ein Nmap Scritpting Engine File bereit, um die Exchange-Systeme analysieren bzw. schützen zu können.

Führen Sie vor allem im Nachgang das Script CompareExchangeHashes.ps1 aus, damit die Integrität der Exchange-Installation gewährleistet ist.

Ist davon auszugehen, dass eine Infektion bereits stattfand (da bspw. eine Web-Shell am Exchange vorzufinden oder C2-Traffic feststellbar war) und Ihre Exchange-Server kompromittiert wurden, gilt es weitere Ermittlungen durchzuführen.

Laut Microsoft konnten die folgenden Post-Exploitation Aktivitäten identifiziert werden:

• Dump der LSASS Memory und resultierend daraus Diebstahl von Zugangsdaten
• Komprimierung von Daten für Exfiltration mit 7-Zip
• Nutzung der Exchange Power-Shell für den Export von Mailbox-Daten
• Nutzung weiterer “Offensive-Security-Tools” wie Covenant, Nishang, und PowerCat für Remote-Access
• Entziehung der Domain-Admin Rechte für die Exchange-Server Administration über “net group “Exchange Organization administrators” administrator /del /domain&echo [S]&cd&echo [E]” um den Update-Vorgang zu stören

Um weitere Analysen durchführen zu können, empfehlen wir von betroffenen Systemen eine Kopie folgender Log-Files anzufertigen:

• HTTP web logs aus dem inetpub\Logs\LogFiles Verzeichnis inkl. aller Subverzeichnissen
• sämtlichen Inhalt des Exchange Web Servers (ebenfalls im inetpub Verzeichnis zu finden)
• Exchange Control Panel (ECP) Logs, welche sich in Program Files\Microsoft\Exchange Server\v15\Logging\ECP\Server befinden
• Microsoft Windows Event-Logs

Weitere Empfehlungen aus aktueller Sicht:

• sofern sich OWA und Active-Sync einschränken lässt, empfehlen wir, den Zugriff per Geo-Location auf die notwendigen Lokationen zu beschränken
• ausgehend sollte dem Exchange-Server lediglich SMTP ermöglicht werden, alle anderen Dienste wie http, https usw. sollte man am besten beschränken
• erzwingen Sie unbedingt die Kennwort-Änderung sämtlicher Konten, auch bzw. und im speziellen Service- und administrative Konten
• haben Sie auch einen Blick auf Ihre Backup-Infrastruktur und nehmen Sie diese aus dem Active-Directory heraus
• nehmen Sie diesen Fall zum Anlass und überdenken Sie Ihre Incident Response– bzw. Cyberdefence-Strategien
• wenn Sie annehmen, dass Ihr Server kompromittiert wurde, versuchen Sie die Exchange-Server von Ihren restlichen Netzwerk-Komponenten möglichst zu isolieren (Zero-Trust)
• Prüfung auf neu erstellte Active Directory Objekte (Benutzer und/oder privilegierte Benutzer) mittels RMM und Power-Shell
• Check von Mailbox-Weiterleitungen
• haben Sie ein wachsames Auge auf Anomalien im Netzewrk und nehmen Sie diese ggf. ernst

Nachdem die Absichten dieses Angriffs noch nicht vollständig bekannt sind, ist eine Prognose noch schwierig abzugeben.

Wir bleiben dran und werden Sie auch weiter informieren!