Warnungsklassifizierung für böswillige Exchange-Connectors

Artikel
04/26/2024

Gilt für:

Microsoft Defender XDR

Bedrohungsakteure verwenden kompromittierte Austauschconnectors, um Spam- und Phishing-E-Mails massenweise an ahnungslose Empfänger zu senden, indem sie legitime E-Mails maskieren. Da der Connector kompromittiert ist, werden die E-Mails in der Regel von den Empfängern als vertrauenswürdig eingestuft. Diese Arten von Phishing-E-Mails sind gängige Vektoren für Phishing-Kampagnen und BEC-Szenario (Business Email Compromise). Daher müssen solche E-Mails stark überwacht werden, da die Wahrscheinlichkeit, dass erfolgreiche Empfänger kompromittiert werden, hoch ist.

Dieses Playbook hilft bei der Untersuchung von Instanzen, in denen schädliche Connectors von böswilligen Akteuren eingerichtet/bereitgestellt werden. Entsprechend ergreifen sie die erforderlichen Schritte, um den Angriff zu beheben und die daraus resultierenden Sicherheitsrisiken zu mindern. Das Playbook hilft bei der Klassifizierung der Warnungen als wahr positiv (TP) oder falsch positiv (FP). Wenn Warnungen TP sind, listet das Playbook die erforderlichen empfohlenen Aktionen zur Behebung des Angriffs auf. Dieses Playbook ist für Sicherheitsteams verfügbar, die die Warnungen überprüfen, verwalten und bewerten.

Im Folgenden finden Sie die Ergebnisse der Verwendung eines Playbooks:

Bestimmung der Warnung als böswillig (TP) oder gutartig (FP).
Wenn sie böswillig sind, entfernen Sie den schädlichen Connector aus der Umgebung.

Exchange-Connectors

Exchange-Connectors sind eine Sammlung von Anweisungen, mit denen Sie die Art und Weise anpassen, wie Ihre E-Mails zu Und von Ihrem Microsoft 365- oder Office 365 organization fließen. Normalerweise benötigen die meisten Microsoft 365- und Office 365-Organisationen keine Connectors für den regulären E-Mail-Fluss.

Connectors werden verwendet, um E-Mail-Datenverkehr zwischen Remote-E-Mail-Systemen und Office 365 (O365) oder O365 sowie lokalen E-Mail-Systemen weiterzuleiten.

Böswillige Exchange-Connectors

Angreifer können einen vorhandenen Exchange-Connector kompromittieren oder einen Administrator kompromittieren und einen neuen Connector einrichten, indem sie Phish- oder Spam-/Massen-E-Mails senden.

Die typischen Indikatoren eines schädlichen Connectors finden Sie beim Betrachten des E-Mail-Datenverkehrs und seiner Header. Beispielsweise, wenn E-Mail-Datenverkehr von einem Connectorknoten mit einem Konflikt zwischen den Absenderadressen P1 (Header-Absender) und P2 (Umschlagsender) sowie ohne Informationen zu AccountObjectId des Absenders beobachtet wird.

Diese Warnung versucht, solche Fälle des Nachrichtenflusses zu identifizieren, wobei die E-Mail-Sendeaktivität verdächtig erscheint, wenn relevante Informationen zum Absender nicht verfügbar sind.

Playbook-Workflow

Sie müssen die Sequenz befolgen, um böswillige Exchange-Connectors zu identifizieren:

Identifizieren Sie, welche Konten E-Mails senden:
- Scheinen Konten kompromittiert zu sein?
Identifizieren Sie den Connector, der in E-Mails weitergeleitet wird, die überprüft werden sollen:
- Wenn der Connector E-Mails mit hohem Volumen senden soll?
- Wenn der Connector vor kurzem geändert oder erstellt wurde?
Werden E-Mails an interne E-Mail-Adressen gesendet?
- Gehen E-Mails an externe Adressen (Spray and Pray Spam)?
- Gehen E-Mails an externe Adressen von Kunden oder Lieferanten (Lieferkettenangriff)?
Überprüfen Sie, ob der FROM-Header und die Umschlagsenderdomänen identisch oder unterschiedlich sind.

Untersuchen schädlicher Connectors

In diesem Abschnitt werden die Schritte zum Untersuchen einer Warnung und zum Beheben des Sicherheitsrisikos aufgrund dieses Vorfalls beschrieben.

Bestimmen Sie, ob der Connector ein schlechtes (böswilliges) Verhalten aufweist.
- Suchen Sie nach Ereignissen, die auf ungewöhnlichen E-Mail-Datenverkehr hinweisen, und ermitteln Sie, ob kürzlich ein neuer Exchange-Connector hinzugefügt wurde.
  - Ermitteln Sie für den beobachteten E-Mail-Datenverkehr, ob die E-Mail-Konten kompromittiert sind, indem Sie überprüfen, ob die Konten für ungewöhnlichen E-Mail-Datenverkehr verantwortlich sind.
- Suchen Sie nach E-Mail-Inhalten, die schädliche Artefakte (fehlerhafte Links/Anlagen) enthalten.
- Suchen Sie nach Domänen, die nicht Teil Ihrer Umgebung sind.
Stellen Sie fest, dass die E-Mail-Konten nicht kompromittiert sind. Identifizieren Sie den Connector, der kürzlich in der Umgebung hinzugefügt oder geändert wurde.
Suchen Sie nach:
- Feldwerte im P1-Absender (E-Mail-Header-Absender) und P2-Absender (Umschlagsender) und überprüfen Sie, ob ein Konflikt vorliegt.
- Leere Werte im Feld SenderObjectId.
Verwenden Sie Telemetriedaten, um Folgendes zu beachten:
- Die NetworkMessageId (Nachrichten-ID) der E-Mails, die vom schädlichen Connector gesendet wurden.
- Das Erstellungsdatum des Connectors, das Datum der letzten Änderung und das Datum der letzten Änderung.
- Die IP-Adresse des Connectors, von dem aus der E-Mail-Datenverkehr beobachtet wird.

Abfragen für die erweiterte Suche

Sie können erweiterte Huntingabfragen verwenden, um Informationen im Zusammenhang mit einer Warnung zu sammeln und zu ermitteln, ob die Aktivität verdächtig ist.

Stellen Sie sicher, dass Sie Zugriff auf die folgenden Tabellen haben:

Tabellenname	Beschreibung
EmailEvents	Enthält Informationen im Zusammenhang mit dem E-Mail-Fluss.
CloudAppEvents	Enthält das Überwachungsprotokoll von Benutzeraktivitäten.
IdentityLogonEvents	Enthält Anmeldeinformationen für alle Benutzer.

References

AHQs-Beispiele zur Referenz:

Führen Sie diese KQL aus, um die Erstellung eines neuen Connectors zu überprüfen.

//modify timeWindow to modify the lookback.
let timeWindow = now(-7d); let timeNow = now();
CloudAppEvents
| where Timestamp between (timeWindow .. timeNow)
| where isnotempty(AccountObjectId)
| where ActionType == "New-InboundConnector"
| mvexpand property = RawEventData.Parameters
| extend ConnectorName = iff(property.Name == "Name", property.Value, ""), 
IsEnabled = iff((property.Name == "Enabled" and property.Value == "True"), 
true, false)
| where isnotempty( ConnectorName) or IsEnabled
| project-reorder ConnectorName, IsEnabled

Führen Sie diese KQL aus, um die Menge der Ereignisse vom warnungen Connector mit einem Zeitfenster von vor und nach den Warnungen zu überprüfen.

//modify timeWindow to modify the lookback.
let timeWindow = now(-7d); let timeNow = now();
let connectorOperations = pack_array("Set-OutboundConnector", 
"New-OutboundConnector", "Set-InboundConnector", "New-InboundConnector");
let mailThreshold = 100; //define threshold for inspection and filtering
let myConnector= //use this code block to specify relevant connector(s)
CloudAppEvents
| where Timestamp between (timeWindow .. timeNow)
| where ActionType has_any (connectorOperations)
| mv-expand property = RawEventData.Parameters
| where property.Name == "Name"
| summarize by ConnectorName=tostring(property.Value)
;
EmailEvents
| where isnotempty( toscalar (myConnector))
| where Timestamp between (timeWindow .. timeNow)
| where isnotempty( SenderObjectId) and isnotempty( Connectors)
| where Connectors in (toscalar (myConnector))
| summarize MailCount = dcount(NetworkMessageId) by Connectors, 
SenderObjectId, bin(Timestamp, 1h)
| where MailCount >= mailThreshold

Führen Sie diese KQL aus, um zu überprüfen, ob E-Mails an externe Domänen gesendet werden.

//modify timeWindow to modify the lookback.
let timeWindow = now(-7d); let timeNow = now();
EmailEvents
| where Timestamp between (timeWindow .. timeNow)
| where isnotempty( SenderObjectId)
| extend RecipientDomain= split(RecipientEmailAddress, "@")[1]
| where (SenderFromDomain != RecipientDomain) or (SenderMailFromDomain 
!= RecipientDomain)
| where EmailDirection !in ("Intra-org" , "Inbound") //comment this line to 
look across all mailflow directions

Wenn an externe Domänen gesendet wird, wer sonst in der Umgebung ähnliche E-Mails sendet (Kann einen kompromittierten Benutzer angeben, wenn der Empfänger eine unbekannte Domäne ist).

//modify timeWindow to modify the lookback.
let timeWindow = now(-7d); let timeNow = now();
let countThreshold= 100; //modify count threshold accordingly 
EmailEvents
| where Timestamp between (timeWindow .. timeNow)
| where isnotempty( SenderObjectId)
| extend RecipientDomain= split(RecipientEmailAddress, "@")[1]
| where (SenderFromDomain != RecipientDomain) or (SenderMailFromDomain 
!= RecipientDomain)
| where EmailDirection !in ("Intra-org" , "Inbound")
| summarize MailCount= dcount(NetworkMessageId) by SenderObjectId, 
SenderFromAddress, SenderMailFromAddress , bin(Timestamp, 1h)
| where MailCount > countThreshold

Überprüfen des E-Mail-Inhalts auf schlechtes Verhalten
Sehen Sie sich die URLs in der E-Mail oder E-Mail an, die Anlagen enthalten.

Überlegungen zu AHQ

Im Folgenden finden Sie die AHQ-Überlegungen zum Schutz der Empfänger vor böswilligen Angriffen.

Suchen Sie nach Administratoranmeldungen für Diejenigen, die Häufig Connectors von ungewöhnlichen Standorten verwalten (generieren Sie Statistiken, und schließen Sie Speicherorte aus, an denen die meisten erfolgreichen Anmeldungen beobachtet werden).

Suchen Sie nach Anmeldefehlern von ungewöhnlichen Speicherorten.

//modify timeWindow to modify the lookback.
let timeWindow = now(-7d); let timeNow = now();
let logonFail= materialize (
IdentityLogonEvents
| where Timestamp between (timeWindow .. timeNow)
| where isnotempty(AccountObjectId)
| where Application != "Active Directory"
| where ActionType == "LogonFailed"
| where ISP != "Microsoft Azure"
| summarize failedLogonCount=count(), LatestTime = max(Timestamp), 
EarliestTime = min(Timestamp) by AccountObjectId, Application, ISP, 
CountryCode, bin(Timestamp, 60s)
| where failedLogonCount > 100);
// let hasLogonFails = isnotempty(toscalar (logonFail));
let logonFailUsers = materialize ( logonFail | distinct AccountObjectId | 
take 100);
let hasLogonFails = isnotempty(toscalar (logonFailUsers));
let logonSuccess=
IdentityLogonEvents
| where hasLogonFails
| where Timestamp between (timeWindow .. timeNow)
| where AccountObjectId in (logonFailUsers)
| where Application != "Active Directory"
| where ISP != "Microsoft Azure"
| where ActionType == "LogonSuccess"
| project SuccessTime= Timestamp, ReportId, AccountUpn, AccountObjectId, 
ISP, CountryCode, Application;
logonFail
| join kind = innerunique logonSuccess on AccountObjectId, ISP, Application
| where SuccessTime between (LatestTime .. (LatestTime + 10s))
| summarize arg_min(SuccessTime, ReportId), EarliestFailedTime=min
(EarliestTime), LatestFailedTime=max(LatestTime), failedLogonCount=
take_any(failedLogonCount), SuccessLogonCount=count(), ISPSet=
make_set(ISP), CountrySet=make_set(CountryCode), AppSet=make_set
(Application) by AccountObjectId, AccountUpn
| project-rename Timestamp=SuccessTime

Empfohlene Aktionen

Nachdem festgestellt wurde, dass die beobachteten Warnungsaktivitäten Teil von TP sind, klassifizieren Sie diese Warnungen, und führen Sie die folgenden Aktionen aus:

Deaktivieren oder entfernen Sie den Connector, der als schädlich eingestuft wurde.
Wenn das Administratorkonto kompromittiert wurde, setzen Sie die Anmeldeinformationen des Administratorkontos zurück. Deaktivieren/widerrufen Sie außerdem Token für das kompromittierte Administratorkonto und aktivieren Sie die mehrstufige Authentifizierung für alle Administratorkonten.
Suchen Sie nach verdächtigen Aktivitäten, die vom Administrator ausgeführt werden.
Überprüfen Sie, ob andere verdächtige Aktivitäten in anderen Connectors in der Umgebung vorhanden sind.

Siehe auch

Tipp

Möchten Sie mehr erfahren? Engage mit der Microsoft-Sicherheitscommunity in unserer Tech Community: Microsoft Defender XDR Tech Community.

Freigeben über