Потребителите на Microsoft 365 са изправени пред фишинг техника, изградена върху малка промяна: атакуващите оставят подателя в SMTP плика празен (empty envelope sender).

Това пропускане може да позволи на неавтентифицирано съобщение да премине през защитата Direct Send, докато показва на служителите адрес, който изглежда принадлежи на тяхната собствена организация.

Подходът не представлява софтуерен дефект в Microsoft и не изисква откраднат акаунт. Той се възползва от начина, по който контролът RejectDirectSend на Exchange Online проверява домейна в плика на подателя, а не адреса, показан в видимото поле „From“.

Тази разлика предоставя на киберпрестъпниците лесен път за имперсонация. Тя премахва бариера, създадена с цел спиране на особено рисков вид спуфинг (имитация) на електронна поща.

Изследователи от ReliaQuest идентифицираха този модел в активни фишинг кампании и го възпроизведоха в контролирана среда на Microsoft 365.

В доклад, споделен с Cyber Security News (CSN), от ReliaQuest заявяват, че техниката се е появявала многократно в несвързани организации през изминалата година. Убедително изглеждащ вътрешен имейл може да съдържа известие за документ, искане за плащане или примамка под формата на гласова поща.

Дори ако филтрите за поща засекат някои опити, всяко съобщение, което достигне до получател, създава възможност за кражба на идентификационни данни, доставяне на зловреден код, измамни финансови преводи и по-широко компрометиране на акаунти.

Празен подател в плика заобикаля проверките

Direct Send позволява на устройства и приложения да изпращат поща в рамките на един и същ Microsoft 365 клиент без автентификация. Предишни анализи на Microsoft 365 Direct Send документираха как атакуващи имитират вътрешни потребители, без да компрометират акаунт.

Функцията RejectDirectSend има за цел да отхвърля неавтентифицирана Direct Send поща, твърдяща, че идва от приет домейн на организацията. ReliaQuest изпращат две съобщения до хоста на клиента.

Съобщението, използващо домейна на клиента в плика на подателя, е отхвърлено, но това, използващо SMTP командата MAIL FROM:<>, е прието и поставено на опашка.

Получателят все още вижда същия вътрешен адрес за ИТ поддръжка във видимото поле „From“. Тъй като празният подател не съдържа домейн, RejectDirectSend няма с какво да сравнява приетите домейни на клиента.

Следователно контролът не прилага условието си за отхвърляне, въпреки че съобщението идва от неавтентифициран външен източник.

Приемането не означава непременно доставяне в входящата поща. Microsoft 365 маркира тестовото съобщение като анонимно, дава му ниво на спам доверие (Spam Confidence Level) 9 и го изпраща в Junk Email, след като SPF и DKIM не връщат резултат, а DMARC се проваля.

Въпреки това резултатите от филтрирането могат да варират в зависимост от съдържанието, инфраструктурата, конфигурацията и изключенията за доверени податели. В един от случаите съобщение, което се проваля на всяка проверка за автентификация, е класифицирано като фишинг с висока увереност, но достига до входящата поща, тъй като подправеният ръководител е бил в списъка с разрешени податели.

Организациите, следващи насоките за конфигурация на автентификацията на имейл, трябва също така да прегледат изключенията, които могат да отменят проверките.

Препоръки за защита

ReliaQuest анализира примери от септември 2025 г. до август 2026 г., насочени към ръководители, мениджъри, финансов персонал, екипи по обществени поръчки и служители, работещи с клиенти. Тези хора редовно обработват фактури, оферти, споделени файлове и инструкции за плащане, което прави бизнес езика убедителен.

Известията за споделяне на файлове са най-често срещани, последвани от искания за плащане, покани за обществени поръчки, предложения за кредити или инвестиции и покани за срещи. Някои съобщения използват SVG прикачени файлове, маскирани като записи на гласова поща.

Този подход напомня за фишинг с инфектирани SVG файлове, които могат да предизвикат пренасочване в браузъра, вместо да действат като изображения. Екипите по сигурност трябва да запазят RejectDirectSend, но да не го разглеждат като пълна защита.

Входящ конектор с ограничение по IP адрес позволява неавтентифициран Direct Send само от одобрени устройства и приложения. Той блокира всеки опит за Direct Send, включително тези с празен подател в плика.

Администраторите трябва да идентифицират системите, които наистина се нуждаят от Direct Send, и строго да ограничат одобрените изходящи IP адреси.

Премахнете неоправданите изключения за филтриране, включително разрешени податели, разрешени домейни, записи за безопасни податели и правила, които променят оценките за спам. Предишни случаи на спуфинг на вътрешни имейли показват защо доверените маршрути и снизходителните правила се нуждаят от щателна проверка.

И накрая, защитниците трябва да търсят празен подател в плика, съчетан с видим адрес „From“ в приет вътрешен домейн, което се различава от служебните съобщения за върната поща (bounce mail). Приоритетизирайте предупрежденията, при които SPF, DKIM или DMARC също са се провалили, но доставянето е извършено чрез правило за отмяна (override).

Слу служителите трябва да потвърждават неочаквани искания за плащания, документи или достъп чрез познат и верифициран канал, преди да предприемат действия.