Потвърждение на поръчка от Dell пристига във входящата ви поща и изглежда напълно автентично: изпратено е от домейна за поръчки на Dell, преминава DKIM и DMARC проверките, използва реалния шаблон на Dell и потвърждава покупка на Microsoft Project Standard 2024 на стойност 736,09 щатски долара, която никога не сте правили. Под полето „Адрес за доставка“, където би трябвало да стои реален адрес, е изписана думата „Helpline“ (линия за помощ) и телефонен номер – кукичката за измама с обратно обаждане (callback scam).
Имейлът изглежда автентичен, защото всъщност е такъв. Атакуващият е подал единствено този номер, а собствената система на Dell го е поставила там и е изпратила писмото.
Превръщане на легитимните платформи в куриери
През изминалата година, според Cisco Talos, атакуващите са злоупотребили с над 25 легитимни платформи, обхващащи услуги за съвместна работа, споделяне на файлове, анкети, разплащания и изкуствен интелект. Атакуващите подават към тези платформи враждебни входни данни и ги оставят да извършат доставката.
Изследователите на Cisco описват три варианта на тази техника.
В две кампании с общо около 1400 съобщения атакуващите са злоупотребили с трансакционната поща на Staples и Dell. Те са вмъкнали фалшиви номера за поддръжка в полетата за таксуване и доставка на потвърждения за поръчки с висока стойност (iPad в случая на Staples). Целта не е кликване върху връзка, а телефонно обаждане, което извежда жертвата изцяло извън комуникацията по имейл.
Бомбардирането на пощенски списъци (list bombing) е традиционна тактика за отказ на услуга или отвличане на вниманието, която в част от случаите се пренасочва за доставка на злонамерено съдържание. Атакуващият изпраща имейл адресите на жертвите към легитимни процеси за регистрация, абонамент или уведомяване, и жертвите биват засипани с автоматизирани имейли за потвърждение.
Някои от тях, както отбелязват изследователите на Cisco, съдържат примамка, въведена в полетата за име, компания или длъжност на лошо валидиран формуляр. Приветственият имейл на платформата след това я доставя, като прави съобщението да изглежда като официално писмо от платформата.
Известията за неуспешна доставка (известни още като „върнати имейли“ или bounced email) могат да върнат копие от оригиналното съобщение обратно към подателя. Независимо дали чрез обратно разсейване (backscatter) от подправен подател в плика (envelope sender), или чрез умишлено предизвикана грешка, атакуващият може да накара върнатото писмо да пренесе злонамерен код.
В един от наблюдаваните от Talos случаи известие за грешка при доставка на поща е пренасяло примамка за споделяне на файлове с тема WeTransfer:
Върнатият имейл доставя примамка за споделяне на файлове (Източник: Cisco Talos)
„Целта на атакуващия беше да направи фишинг примамката да изглежда по-малко като непоискано външно съобщение и повече като част от техническа грешка при доставката, която изисква преглед. Потребителите са свикнали да възприемат системните грешки като безобидни и е много по-вероятно да реагират на „административна“ корекция, отколкото на подозрителен, самостоятелен фишинг имейл“, обясняват изследователите.
Автентикиран не означава безопасен
Имейл автентикацията е създадена, за да отговори на един въпрос: дошло ли е това съобщение от мястото, от което твърди, че идва? Протоколите SPF, DKIM и DMARC отговарят отлично на този въпрос, но те не казват нищо за това какво е било зададено на изпращащата система да каже.
Тази пролука осигурява повърхност за атака. Всяко поле, контролирано от потребител, което платформата по-късно визуализира в имейл, може да се превърне в канал. Атакуващият предоставя съдържанието, а доверената система осигурява добрата репутация, шаблона и успешно преминаващите проверки заглавни части (headers).
Всички ние трябва да бъдем внимателни с всеки получен имейл, но собствениците на платформи са тези, които трябва да валидират въвежданите от потребителите стойности, преди да ги съхраняват и визуализират.
„Телефонни номера, URL адреси, маркиране, нови редове и спешни формулировки, типични за екипи за поддръжка, трябва да бъдат отхвърляни или отбелязвани като подозрителни, когато се появят в полета, където нямат място“, съветват от Cisco Talos.
Междувременно шлюзовете за сигурност трябва да инспектират напълно визуализираното съобщение – включително HTML, текст, URL адреси, пренасочвания, прикачени файлове, полета за персонализация и вложено MIME съдържание – а не само подателя и шаблона.
Talos също така препоръчва да се проверява дали трансакционната поща съответства на процеса, който я е генерирал. Касова бележка с неочакван номер за поддръжка, инструкции за анулиране или спешен тон трябва да събуди подозрение.
„При отчетите за доставка рекурсивната инспекция на MIME е особено важна. Шлюзовете трябва да анализират DSN контейнерите, да извличат върнатите съобщения или техни фрагменти и да прилагат стандартен анализ за фишинг, зловреден код и URL адреси към вложеното съдържание. Върнатото писмо трябва да обяснява грешка при доставка, а не да предоставя сляп път за ненадежден злонамерен код“, допълват изследователите.