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:
Falls ein IOC gefunden wird, wird die entsprechende Stelle rot markiert (dies ist nur ein Beispiel):
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.
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
Vielen Dank für deine ständige super Arbeit Frank
Hi, gibt’s für Exchange 2013 unter Server 2012 R2 auch ein Tool / Skript?
Hallo,
Es gibt wohl eine Anpassung bei der Regel im IIS, da diese so ungenau ist. Dafür muss das @ entfernt werden in der Regel.
Hallo miteinander,
kann mich dem Lob nur anschließen.
Auch bei uns keine Auffälligkeiten.
Guter Wochenstart an alle
Jetzt wo man den Pattern für die Rewrite-Regel ändern muss, muss da auch das Skript angepasst werden ?
Danke!
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
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…
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}
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.
Exchange 2019 und ein Exchange 2016 beide mit aktuellem CU und SU alles grün. Im Test kommt 403 wie erwartet.
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.
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
Noch als Info, wer noch Exchange 2013 unter Windows 2012 am Laufen hat; da gibts kein get-filehash sondern nur ne Fehlermeldung.
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.
Argh, mein Fehler. Beim speichern hat mir der Browser den HTML Quellcode kopiert und nicht die ps1 Datei an sich.
Jetzt ist alles grün.
Schönes Wochenende noch :D
Logfiles lediglich für 14 Tage einzurichten halte ich für grob fahrlässig.
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… ;-)
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?
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.
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.
Danke für das Skript.
Auf 26 Exchange Servern in der EU kein Befall festzustellen.
gerade durchgeführt, alles gut!
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
$var = get-ExecutionPolicy
Set-ExecutionPolicy Unrestricted
**Script ausführen**
Set-ExecutionPolicy $var
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
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
Hallo Jens,
das Script ermittelt den Pfad der Logs aus der IIS Konfiguration. Es sind keine Anpassungen nötig.
Beste Grüße,
Frank
Besten Dank.
Script lief auf beiden Mailservern durch und hat keine Einträge gefunden.
Alles grün