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.

(forrás)