Exchange Zero-Day Angriff per PowerShell feststellen

Die Exchange Server Zero-Day Schwachstelle wurde heute bekannt und wird bereits aktiv ausgenutzt. Eine entsprechende Abwehrmaßnahme existiert und sollte möglichst schnell umgesetzt werden. Wie die Abwehrmaßnahme umgesetzt wird, lässt sich hier nachlesen:

Auf der Webseite des Unternehmens GTSC wurden Details über den aktuell laufenden Angriff genannt, für diese IOCs habe ich ein kleines PowerShell Script erstellt:

write-host "
------------------------------------------------------
Checking for suspicious files...
------------------------------------------------------
"

$SuspiciousFiles = @(
"C:\root\DrSDKCaller.exe",
"C:\Users\Public\all.exe",
"C:\Users\Public\dump.dll",
"C:\Users\Public\ad.exe",
"C:\PerfLogs\gpg-error.exe",
"C:\PerfLogs\cm.exe",
"C:\Program Files\Common Files\system\ado\msado32.tlb"
)

foreach ($SuspiciousFile in $SuspiciousFiles) {
	if (test-path $SuspiciousFile) {
		write-host "Suspicious File $SuspiciousFile found!" -foregroundcolor red
	}
	else {
		write-host "Suspicious File $SuspiciousFile not found!" -foregroundcolor green
	}
}

write-host "
------------------------------------------------------
Checking IIS Logs for IOCs... (this can take some time)
------------------------------------------------------
"
Import-Module WebAdministration
$IISLogdir = (get-item "IIS:\Sites\Default Web Site").logfile.directory
if ($IISLogdir -match "%SystemDrive%") {
	$IISLogdir = $IISLogdir.replace("%SystemDrive%","c:")
}
$IOCs = Get-ChildItem -Recurse -Path $IISLogdir -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'
if ($IOCs) {
	write-host "IOC powershell.*autodiscover\.json.*\@.*200 found in IIS Logs" -foregroundcolor red
}
else {
	write-host "IOC powershell.*autodiscover\.json.*\@.*200 not found in IIS Logs" -foregroundcolor green
}
write-host "
------------------------------------------------------
Checking for WebShells...
------------------------------------------------------
"
$Webshell1 = [PSCustomObject]@{
	ID = 1
    Name = "FrontEnd\HttpProxy\owa\auth\pxh4HG1v.ashx"
    Hash = "c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1"
}
$Webshell2 = [PSCustomObject]@{
	ID = 2
    Name = "FrontEnd\HttpProxy\owa\auth\RedirSuiteServiceProxy.aspx"
    Hash = "65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5"
}
$Webshell3 = [PSCustomObject]@{
	ID = 3
    Name = "FrontEnd\HttpProxy\owa\auth\RedirSuiteServiceProxy.aspx"
    Hash = "b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca"
}
$Webshell4 = [PSCustomObject]@{
	ID = 4
    Name = "FrontEnd\HttpProxy\owa\auth\errorEE.aspx"
    Hash = "be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257"
}
[System.Collections.ArrayList]$WebShellArray = @()
$WebShellArray.Add($Webshell1) | out-null
$WebShellArray.Add($Webshell2) | out-null
$WebShellArray.Add($Webshell3) | out-null
$WebShellArray.Add($Webshell4) | out-null

foreach ($WebShell in $WebShellArray) {
	$WebshellPath = "$exinstall" + $WebShell.Name
	if (test-path $WebshellPath) {
		$FileHash = (Get-FileHash $WebshellPath).Hash.ToLower()
		if ($Webshell.Hash -eq $FileHash) {
			write-host "WebShell File $WebshellPath found!" -foregroundcolor red
		}
		else {
			write-host "WebShell File $WebshellPath not found!" -foregroundcolor green
		}
	}
	else {
		write-host "WebShell File $WebshellPath not found!" -foregroundcolor green
	}
}

Das Script habe ich auch auf GitHub veröffentlicht (falls jemand Fehler findet oder sich beteiligen möchte):

Das Script kann in eine Datei mit dem Namen „Search-ExchangeProxyNotShell.ps1“ kopiert werden und auf dem Exchange Server in der Exchange Management Shell mit administrativen Rechten (Run as Admin) ausgeführt werden. Die Ausgabe sieht dann so aus, wenn keine IOCs gefunden wurden:

Exchange Zero-Day Angriff per PowerShell feststellen

Falls ein IOC gefunden wird, wird die entsprechende Stelle rot markiert (dies ist nur ein Beispiel):

Exchange Zero-Day Angriff per PowerShell feststellen

Sollte ein Treffer auftreten, sollte der Server genau untersucht werden. Im Zweifelsfall sollte der Server neu installiert werden. Dies ist in einer DAG keine große Sache und führt auch zu keiner Einschränkung der Exchange Verfügbarkeit. Gibt es nur einen Server, müssen ein paar Stunden Downtime eingeplant werden. Hier ist die Vorgehensweise beschrieben:

Da Microsoft aktuell von wenigen zielgerichteten Angriffen spricht und daher auch scheinbar keine Exchange Emergency Mitigation veröffentlicht hat, würden mich eure Ergebnisse interessieren. Gibt es hier Leser mit erfolgreichen Angriffen oder Angriffsversuchen?

Diese Zero-Day Schwachstelle hat übrigens den Namen „ProxyNotShell“, in Anspielung auf die letzte Zero-Day Lücke „ProxyShell“ bekommen.

29 Gedanken zu „Exchange Zero-Day Angriff per PowerShell feststellen“

  1. Vielen dank für deine super Arbeit Frank!

    Eine Frage hätte ich noch:

    Wir nutzen einen Exchange im Hybrid Modus der selber keine Mailboxen hostet.
    Die RemotePowershell der ExchangeOnline User werden mit „get-user“ allerdings mit „true“ angezeigt.

    Hat dies irgend ein Impact auf unseren Exchange OnPrem? Oder handelt es sich lediglich um die Online RemotePShell welche sowie nicht von dem Issue betroffen ist?

    Danke & Viele Grüße

    Antworten
  2. Auf unseren Mailsevern hat MS auch aus der Ferne das Emergency-Mitigations aktiviert.
    Habe nun zwei Regeln drin, einmal die gesetzte von mir am Freitag und nun noch zusätzlich die von MS

    Antworten
  3. Muss der PowerShell Befehl für die Logs nicht korrigiert werden?
    Get-ChildItem -Recurse -Path -Filter „*.log“ | Select-String -Pattern ‚powershell.*autodiscover\\.json.*\\@.*200‘
    -ODER-
    Get-ChildItem -Recurse -Path -Filter „*.log“ | Select-String -Pattern ‚powershell.*autodiscover\.json.*\@.*200‘ -SimpleMatch
    Also entweder mit \\ oder die 2. Zeile mit -SimpleMatch verwenden…

    Antworten
  4. Inzwischen scheinen auch die Emergency-Mitigations aktiv zu sein (M1.1):

    C:\Windows\system32> Get-ExchangeServer -Identity mail | Format-List Name,MitigationsApplied
    Name : MAIL
    MitigationsApplied : {M1.1, PING1}

    Antworten
  5. Hallo,
    genauso ist es bei mir auch mit einer „roten“ Zeile IOC powershell.*autodiscover\.json.*\@.*200 found in IIS Logs, wie bei Carsten, da
    ich auch die Test URL aufgerufen hatte.

    Antworten
  6. Wie immer super Arbeit von Franky. Ich spreche sicher im Namen von allen wenn ich Dir für deinen immer wertvollen Input Danke.
    Skript läuft super und bisher kein Treffer.

    Antworten
  7. Noch eine kleine Warnung:

    Ich dachte erste es ist alles Grün, aber da war das Script noch am scannen der IIS Logs. Am Ende habe ich plötzlich einen Treffer mit folgender Zeile erhalten:

    IOC powershell.*autodiscover\.json.*\@.*200 found in IIS Logs

    Das ist in meinem Fall aber ein false-positive.

    Mit folgendem Befehl konnte ich dann ausmachen wo genau der Eintrag herkommt:

    Get-ChildItem -Recurse -Path „C:\inetpub\logs“ -Filter „*.log“ | Select-String -Pattern ‚powershell.*autodiscover\.json.*\@.*200‘

    Ich hatte den Befehl schon zuvor ausgeführt und habe 0 Treffer erhalten. Jetzt erhalte ich einen Treffer vom 30.09.
    aus Firefox heraus.

    Kurz im Verlauf geschaut und festgestellt, dass ich die URL selber als Test des URL-Rewrites aufgerufen hatte mit folgendem Link:

    https://my.domain.de/autodiscover/autodiscover.json?@evil.com/powershell&Email=autodiscover/autodiscover.json%3f@evil.com

    Wenn der Rewrite greift kommt hier 403 raus bzw bei der Microsoft Version wird der Zugriff direkt geblockt.

    Dieser kleine Test war nun in den IIS Logs enthalten und hat das Script rot anschlagen lassen.

    Also jeder, der den URL-Rewrite mit einem Link getestet hat wird hier wohl eine rote Meldung bekommen.

    Mein Blutdruck nimmt wieder normale Werte an… :D

    Gruß und schönes Wochenende

    Antworten
  8. Leider schmeißt es bei nur Fehler aus:

    Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
    Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen („&“), um es als Teil einer Zeichenfolge zu
    übergeben.

    Antworten
  9. Auch von mir: DANKE!!

    1xEX2016: Kein Fund

    …allerdings sind meine IIS-Logs nur ca. 14 Tage alt, wäre also die Frage, ob davor mal was war.
    Absolute Sicherheit gibt es aber ja bekanntermaßen sowieso nicht… ;-)

    Antworten
  10. Hi.

    Bei uns sind die Logfiles recht alt unter inetpub/logs/logfiles
    Kann es sein, dass man diese Logfiles erst aktivieren muss?
    Wenn ja, an welcher Stelle denn?

    Antworten
  11. Unser Ex2016 mit CU22 ist auch sauber. Den Workaround hatte ich gestern gleich durchgeführt. Unser Ex2016 läuft hinter einer Sophos XG mit WAF. Ich hoffe, diese fängt solche Angriffe ab.

    Ich möchte mich hiermit ganz herzlich bei Frank für seine unermüdliche Arbeit bedanken. Du sparst mir sehr viel Arbeit und Zeit mit Deinen Beiträgen. Wir werden uns entsprechend bedanken.

    Antworten
    • Wir haben ebenfalls den Exchange hinter einer Sophos mit WAF.

      Gestern vor dem Workaround gingen testweise gesendete Anfragen noch durch, nach dem Workaround nicht mehr.

      Da der Test nur sehr rudimentär war und nur grob nach dem Muster der Rewrite-Regel „handgestrickt“, kann ich keine verlässliche Aussage geben, es steht aber zu befürchten, dass die WAF diesen Angriff nicht erkennt.

      Zum Glück wurden wir nicht angegriffen.

      Antworten
  12. Servus Frank,

    leider mag das Script bei mir nicht:

    .\Search-ExchangeProxyNotShell.ps1 : Die Datei „C:\install\Search-ExchangeProxyNotShell.ps1“ kann nicht geladen
    werden. Die Datei „C:\install\Search-ExchangeProxyNotShell.ps1“ ist nicht digital signiert. Sie können dieses Skript
    im aktuellen System nicht ausführen. Weitere Informationen zum Ausführen von Skripts und Festlegen der
    Ausführungsrichtlinie erhalten Sie unter „about_Execution_Policies“ (https:/go.microsoft.com/fwlink/?LinkID=135170)..
    In Zeile:1 Zeichen:1
    + .\Search-ExchangeProxyNotShell.ps1
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : Sicherheitsfehler: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

    Antworten
  13. Hallo Frank,

    danke für die Mühe um diese Uhrzeit!

    Ich habe gerade mal unsere letzten beiden verblieben Exchange-Server „gescannt“ und die Workarounds angewandt. Das Risiko sollte in unserem Fall aber relativ gering sein. Beide Server haben nach „Extern“ nur noch Autodiscover (hier ja relevant) und EWS veröffentlicht. Allerdings auch nur für M365 IPs (Exchange Hybrid). Zudem befinden diese sich hinter einer WAF. Wobei ModSecurity hier sicherlich standardmäßig auch nicht greift.

    Beste Grüße
    Martin

    Antworten
  14. Eine Frage von mir, kenne mich nicht wirklich mit Skripten aus..

    Wir haben die Logfiles von dem Ordner Inetpub auf einer extra Platte und nicht C.
    Scannt er diese Dateien und wenn ja muss ich ihm das explizit sagen?

    Danke vorab

    Antworten

Schreibe einen Kommentar