Фишинг с погружением. Как мы втерлись в доверие, прикинувшись разработчиком

Все это про­исхо­дило в рам­ках ред­тимин­га и по кон­трак­ту. Перед началом тес­тирова­ния заказ­чик пре­дос­тавил нам:

• спи­сок клю­чевых тех­ничес­ких спе­циалис­тов ком­пании;
• кон­так­тные дан­ные сот­рудни­ков: име­на, адре­са элек­трон­ной поч­ты, ник­ней­мы в Telegram.

По­ка мы готови­лись, гря­нула гром­кая фишин­говая ата­ка от Lazarus Group — под удар попала бир­жа Bybit. Пос­ле инци­ден­та коман­да заказ­чика ста­ла бди­тель­нее.

Кампания 1

Этап раз­ведки показал, что у заказ­чика поч­та на Google Workspace (кор­поратив­ном Gmail). У Gmail жес­ткие антиспам‑филь­тры, плюс сей­час в Web3 тему фишин­га не игно­рят. Поэто­му мы иска­ли вари­анты для точеч­ных рас­сылок с реаль­ных поч­товых сер­висов сто­рон­них плат­форм, которы­ми поль­зует­ся заказ­чик. Пись­ма с легитим­ных доменов вызыва­ют боль­ше доверия и реже летят в спам.

Ког­да разоб­рались со сто­рон­ним сер­висом для дос­тавки писем, взя­ли откры­тую AITM‑плат­форму Evilginx, слег­ка адап­тирова­ли ее (выпили­ли пас­халки из кода) и нас­тро­или редирект на фишин­говую стра­ницу логина Gmail.

В арсе­нале у нас был Evilginx с кас­томным фиш­летом для обхо­да MFA в эко­сис­теме Google: через под­ход Browser-in-the-Middle он вору­ет сес­сион­ные куки Gmail пос­ле вво­да кода и уме­ет обхо­дить и ста­тичес­кие, и эвристи­чес­кие про­вер­ки Chrome, вклю­чая Google Safe Browsing. Фишин­говую стра­ницу мы соб­рали и прог­нали на акту­аль­ных защитах Chrome и Firefox.

Что­бы не палить­ся перед ботами и сни­зить риск, что домен отме­тят как фишин­говый, мы под­няли сер­вис на Microsoft Azure Functions. Он мас­киру­ет фишин­говую стра­ницу, обфусци­руя JavaScript и редирек­ты, и зло­упот­ребля­ет довери­ем к домену Azure App Service (*.azurewebsites.net).

В редирек­торе тоже были «канарей­ки» (canary links) — ссыл­ки, которые нуж­ны толь­ко для фик­сации кли­ка. Их исполь­зовали для отсле­жива­ния вза­имо­дей­ствий вмес­то дру­гих механиз­мов вро­де magic byte.

Что­бы слать пись­ма от домена заказ­чика, мы исполь­зовали встро­енный инс­тру­мент плат­формы для email‑уве­дом­лений. Он не огра­ничи­вал содер­жимое, так что через поч­товые сер­висы заказ­чика мож­но было отправ­лять любые сооб­щения.

Кам­пания стро­илась на рас­сылке авто­мати­зиро­ван­ных приг­лашений клю­чевым сот­рудни­кам ком­пании заказ­чика с при­зывом завер­шить регис­тра­цию. Ниже — обра­зец пись­ма из тес­та: оно ста­биль­но обхо­дило спам- и кон­тент‑филь­тры Gmail.

На сле­дующий день пос­ле рас­сылки домен помети­ли как фишин­говый, внут­реннюю коман­ду пре­дуп­редили: не откры­вать ссыл­ки и не вво­дить дан­ные.

Итог: один клик по ссыл­ке, ноль перех­ватов дан­ных.

Кампания 2

Пос­ле про­вала пер­вой фишин­говой кам­пании мы решили дей­ство­вать точ­нее: про­тес­тирова­ли нес­коль­ко сце­нари­ев — дос­тавку ссы­лок на фиш­лет для Google через Telegram и дру­гие трю­ки. Но ни один вари­ант не получил­ся дос­таточ­но убе­дитель­ным.

Мы допол­нитель­но выяс­нили, какую сто­рон­нюю плат­форму Web3‑ана­лити­ки исполь­зует заказ­чик: под­сказ­ку наш­ли в опи­сании вакан­сии на их сер­вере Discord.

Даль­ше мы попыта­лись сыг­рать на доверии к легитим­ному сай­ту. При раз­боре наш­ли пач­ку уяз­вимос­тей (их потом переда­ли ком­пании) и утеч­ки внут­ренней инфы. По ним ста­ло ясно, что сот­рудни­ки заказ­чика авто­ризу­ются через Google Workspace SSO: у кор­поратив­ных про­филей — ава­тар­ки из Gmail. На бэкен­де тор­чала уста­рев­шая поч­товая служ­ба уве­дом­лений, через нее мож­но было нас­тра­ивать боевые каналы опо­веще­ния по поч­те.