Dela via

Aviseringsklassificering för misstänkta regler för inkorgsmanipulering

  • Artikel

Gäller för:

  • Microsoft Defender XDR

Hotaktörer kan använda komprometterade användarkonton för många skadliga syften, inklusive att läsa e-postmeddelanden i en användares inkorg, skapa inkorgsregler för att vidarebefordra e-postmeddelanden till externa konton, ta bort spårningar och skicka nätfiskemeddelanden. Skadliga inkorgsregler är vanliga vid hot mot företagsmeddelanden (BEC) och nätfiskekampanjer och det är viktigt att övervaka dem konsekvent.

Den här spelboken hjälper dig att undersöka alla incidenter som rör misstänkta inkorgsmanipuleringsregler som konfigurerats av angripare och vidta rekommenderade åtgärder för att åtgärda attacken och skydda ditt nätverk. Den här spelboken är avsedd för säkerhetsteam, inklusive SOC-analytiker (Security Operations Center) och IT-administratörer som granskar, undersöker och betygsätter aviseringarna. Du kan snabbt klassificera aviseringar som antingen en sann positiv (TP) eller en falsk positiv (TP) och vidta rekommenderade åtgärder för TP-aviseringarna för att åtgärda attacken.

Resultatet av att använda den här spelboken är:

  • Du identifierar aviseringarna som är associerade med regler för inkorgsmanipulering som skadliga aktiviteter (TP) eller godartade aktiviteter (FP).

    Om det är skadligt tar du bort skadliga regler för inkorgsmanipulering.

  • Du vidtar nödvändiga åtgärder om e-postmeddelanden vidarebefordrades till en skadlig e-postadress.

Regler för inkorgsmanipulering

Inkorgsregler är inställda på att automatiskt hantera e-postmeddelanden baserat på fördefinierade kriterier. Du kan till exempel skapa en inkorgsregel för att flytta alla meddelanden från din chef till en annan mapp eller vidarebefordra meddelanden som du får till en annan e-postadress.

Manipulationsregler för skadlig inkorg

Angripare kan konfigurera e-postregler för att dölja inkommande e-postmeddelanden i den komprometterade användarpostlådan för att dölja sina skadliga aktiviteter från användaren. De kan också ange regler i den komprometterade användarpostlådan för att ta bort e-postmeddelanden, flytta e-postmeddelandena till en annan mindre märkbar mapp (t.ex. RSS) eller vidarebefordra e-postmeddelanden till ett externt konto. Vissa regler kan flytta alla e-postmeddelanden till en annan mapp och markera dem som "lästa", medan vissa regler endast kan flytta e-postmeddelanden som innehåller specifika nyckelord i e-postmeddelandet eller ämnet.

Inkorgsregeln kan till exempel vara inställd på att söka efter nyckelord som "faktura", "nätfiske", "svara inte", "misstänkt e-post" eller "skräppost" och flytta dem till ett externt e-postkonto. Angripare kan också använda den komprometterade användarpostlådan för att distribuera skräppost, nätfiskemeddelanden eller skadlig kod.

Arbetsflöde

Här är arbetsflödet för att identifiera aktiviteter för misstänkt inkorgsmanipuleringsregel.

Arbetsflöde för aviseringsundersökning för regler för inkorgsmanipulering

Undersökningssteg

Det här avsnittet innehåller detaljerad stegvis vägledning för att reagera på incidenten och vidta de rekommenderade stegen för att skydda din organisation från ytterligare attacker.

1. Granska aviseringarna

Här är ett exempel på en avisering om inkorgshanteringsregler i aviseringskön.

Exempel på en regel för inkorgsmanipulering

Här är ett exempel på information om en avisering som utlöstes av en regel för skadlig inkorgsmanipulering.

Information om aviseringar som utlöstes av en regel för skadlig inkorgsmanipulering

2. Undersök parametrar för inkorgshanteringsregler

Kontrollera om reglerna ser misstänkta ut enligt följande regelparametrar eller kriterier:

  • Nyckelord

    Angriparen kan endast tillämpa manipulationsregeln på e-postmeddelanden som innehåller vissa ord. Du hittar dessa nyckelord under vissa attribut, till exempel: "BodyContainsWords", "SubjectContainsWords" eller "SubjectOrBodyContainsWords".

    Om det finns filtrering efter nyckelord kontrollerar du om nyckelorden verkar misstänkta för dig (vanliga scenarier är att filtrera e-postmeddelanden relaterade till angriparens aktiviteter, till exempel "nätfiske", "skräppost" och "svara inte" bland andra).

    Om det inte finns något filter alls kan det också vara misstänkt.

  • Målmappen

    För att undvika säkerhetsidentifiering kan angriparen flytta e-postmeddelandena till en mindre märkbar mapp och markera e-postmeddelandena som lästa (till exempel mappen RSS). Om angriparen använder åtgärden "MoveToFolder" och "MarkAsRead" kontrollerar du om målmappen på något sätt är relaterad till nyckelorden i regeln för att avgöra om den verkar misstänkt eller inte.

  • Ta bort alla

    Vissa angripare tar bara bort alla inkommande e-postmeddelanden för att dölja sin aktivitet. För det mesta är en regel för att "ta bort alla inkommande e-postmeddelanden" utan att filtrera dem med nyckelord en indikator på skadlig aktivitet.

Här är ett exempel på en regelkonfiguration för "ta bort alla inkommande e-postmeddelanden" (som visas i RawEventData.Parameters) för den relevanta händelseloggen.

Exempel på en regelkonfiguration för att ta bort alla inkommande e-postmeddelanden

3. Undersök IP-adressen

Granska attributen för DEN IP-adress som utförde den relevanta händelsen när regeln skapades:

  • Search för andra misstänkta molnaktiviteter som kommer från samma IP-adress i klientorganisationen. Misstänkt aktivitet kan till exempel vara flera misslyckade inloggningsförsök.
  • Är Isp vanligt och rimligt för den här användaren?
  • Är platsen gemensam och rimlig för den här användaren?

4. Undersök misstänkt aktivitet av användaren innan du skapar reglerna

Du kan granska alla användaraktiviteter innan regler har skapats, söka efter indikatorer för komprogettering och undersöka användaråtgärder som verkar misstänkta.

För flera misslyckade inloggningar undersöker du till exempel:

  • Inloggningsaktivitet

    Kontrollera att inloggningsaktiviteten innan regeln skapas inte är misstänkt. (gemensam plats/ISP/user-agent).

  • Varningar

    Kontrollera om användaren har fått aviseringar innan du skapar reglerna. Detta kan tyda på att användarkontot kan ha komprometterats. Till exempel omöjlig reseavisering, sällan land/region, flera misslyckade inloggningar, bland annat.)

  • Incident

    Kontrollera om aviseringen är associerad med andra aviseringar som indikerar en incident. I så fall kontrollerar du om incidenten innehåller andra sanna positiva aviseringar.

Avancerade jaktfrågor

Avancerad jakt är ett frågebaserat verktyg för hotjakt där du kan granska händelser i nätverket för att hitta hotindikatorer.

Använd den här frågan för att hitta alla nya inkorgsregelhändelser under ett visst tidsfönster.

let start_date = now(-10h);
let end_date = now();
let user_id = ""; // enter here the user id
CloudAppEvents
| where Timestamp between (start_date .. end_date)
| where AccountObjectId == user_id
| where Application == @"Microsoft Exchange Online"
| where ActionType in ("Set-Mailbox", "New-InboxRule", "Set-InboxRule", "UpdateInboxRules") //set new inbox rule related operations
| project Timestamp, ActionType, CountryCode, City, ISP, IPAddress, RuleConfig = RawEventData.Parameters, RawEventData

Kolumnen RuleConfig tillhandahåller den nya inkorgsregelkonfigurationen.

Använd den här frågan för att kontrollera om Internetleverantören är vanlig för användaren genom att titta på användarens historik.

let alert_date = now(); //enter alert date
let timeback = 60d;
let userid = ""; //enter here user id
CloudAppEvents
| where Timestamp between ((alert_date-timeback)..(alert_date-1h))
| where AccountObjectId == userid
| make-series ActivityCount = count() default = 0 on Timestamp  from (alert_date-timeback) to (alert_date-1h) step 12h by ISP

Använd den här frågan för att kontrollera om landet/regionen är vanligt för användaren genom att titta på användarens historik.

let alert_date = now(); //enter alert date
let timeback = 60d;
let userid = ""; //enter here user id
CloudAppEvents
| where Timestamp between ((alert_date-timeback)..(alert_date-1h))
| where AccountObjectId == userid
| make-series ActivityCount = count() default = 0 on Timestamp  from (alert_date-timeback) to (alert_date-1h) step 12h by CountryCode

Använd den här frågan för att kontrollera om användaragenten är gemensam för användaren genom att titta på användarens historik.

let alert_date = now(); //enter alert date
let timeback = 60d;
let userid = ""; //enter here user id
CloudAppEvents
| where Timestamp between ((alert_date-timeback)..(alert_date-1h))
| where AccountObjectId == userid
| make-series ActivityCount = count() default = 0 on Timestamp  from (alert_date-timeback) to (alert_date-1h) step 12h by UserAgent
  1. Inaktivera den skadliga inkorgsregeln.
  2. Återställ autentiseringsuppgifterna för användarkontot. Du kan också kontrollera om användarkontot har komprometterats med Microsoft Defender for Cloud Apps, vilket hämtar säkerhetssignaler från Microsoft Entra ID Protection.
  3. Search för andra skadliga aktiviteter som utförs av det berörda användarkontot.
  4. Sök efter annan misstänkt aktivitet i klientorganisationen som kommer från samma IP-adress eller från samma ISP (om ISP är ovanlig) för att hitta andra komprometterade användarkonton.

Se även

Tips

Vill du veta mer? Engage med Microsofts säkerhetscommunity i vår Tech Community: Microsoft Defender XDR Tech Community.