A támadók a Microsoft 365 egyik beépített levelezési funkcióját, a Direct Sendet használják arra, hogy olyan adathalász e-maileket küldjenek, amelyek a szervezet saját domainjéről érkező üzeneteknek tűnnek. A módszerhez nincs szükség felhasználói fiókra vagy jelszóra, a támadók közvetlenül kapcsolódnak a Microsoft 365 nyilvánosan elérhető levelezési végpontjához.
A Direct Sendet eredetileg arra tervezték, hogy a nyomtatók, szkennerek és régebbi, helyben működő alkalmazások külön levelezési fiók nélkül is küldhessenek e-maileket. A támadók ugyanezt a levelezési útvonalat használják ki, és például a vállalat HR-, pénzügyi vagy adminisztrációs munkatársának, illetve akár a vezérigazgatónak a nevében is küldhetnek üzenetet.
A KnowBe4 Threat Labs 2026 júliusában és augusztusában 29 785 megerősített Direct Send-hamisítást azonosított. Hétköznapokon hetente 22 – 32 ezer ilyen e-mailt figyeltek meg, hétvégén azonban a forgalom 1500 – 2000 üzenetre esett vissza. Ez arra utal, hogy a kampányokat a támadók a szervezetek szokásos munkaidejéhez igazították. Egy augusztusi üzenetet egyszerre 900 címzetthez küldtek el. Az esetek mintegy 35 százalékában melléklet is szerepelt, és ezek szinte mindegyikét veszélyesnek ítélték.
A leggyakoribb feladónevek között
- hr,
- admin,
- no-reply,
- accounting,
- meeting szavak szerepeltek.
Az üzenetek többféle csalási sémát alkalmaztak. Gyakoriak voltak a beszerzési vagy pénzügyi dokumentumokra hivatkozó e-mailek, amelyek egy hamis Microsoft-bejelentkezési oldalra vezettek. Más üzeneteket belső hangpostaértesítésnek, számlának vagy fizetési jóváhagyási kérésnek álcáztak. Olyan kampányokat is azonosítottak, amelyek látszólag legitim SharePoint- vagy OneDrive-hivatkozást használtak egy Windows .url parancsikon továbbítására, amely ezt követően a támadó infrastruktúrájára irányította át a felhasználót. A támadók 4023 esetben a Reply-To mezőt is más domainhez tartozó címre állították. Így a címzett válasza nem a megnevezett munkatárshoz, hanem közvetlenül a támadóhoz érkezett.
A támadások azért is lehetnek sikeresek, mert sok szervezetnél a DMARC szabályzata továbbra is p=none módban működik. Ilyenkor a rendszer észleli és naplózza a hitelesítési eltérést, de az üzenetet nem feltétlenül blokkolja.
Védekezési javaslatok:
- a DMARC-szabályzat ellenőrzése és szigorítása,
- a domain nevében történő levélküldés korlátozása,
- a funkció teljes letiltása, ha nincs rá szükség,
- a DKIM-aláírás engedélyezése.
Az ilyen visszaélés egyik fontos technikai ismertetőjele az X-MS-Exchange-Organization-AuthAs: Anonymous fejléc. Ha egy belső feladónak tűnő üzenet ezt a fejlécet tartalmazza, az arra utalhat, hogy az e-mail hitelesítés nélkül, a nyilvánosan elérhető levelezési végponton keresztül érkezett.