Hogyan kerüljük el a spam mappát egy adathalászat-szimuláció során?

Tavaly egy red team felmérés részeként adathalászat-szimulációt végeztem. Megosztom, mit tanultam a spamszűrőkről. A belső levelezőrendszerhez is hozzáfértem, így a vizsgált környezetben ellenőrizhettem a feltételezéseimet.

Egy szabály mindenre érvényes: illeszkedjünk a megszokott környezethez, és tűnjünk minél hitelesebbnek — ne csak az automatizált eszközök, hanem az emberek számára is. Próbáljunk annak a szemszögéből gondolkodni, aki a szűrőket beállította.

Infrastruktúra

Az SMTP-fejlécek nagyon összetettek lehetnek. Az első kampányomban a legegyszerűbb megoldás egy Microsoft 365-cím használata és megfelelő beállítása volt. Az Outlook kliens a megszokott Outlook-levelekre jellemző SMTP-fejléceket küldi. Mivel vállalati környezetben széles körben használják, a legtöbb eszköz ismeri a fejléceit. Emiatt meg sem próbáltam saját Python-kódot írni a cél SMTP-szerverével való közvetlen kommunikációhoz. Nem kellett minden fejlécet megértenem; az volt a célom, hogy a levél a beérkező üzenetek közé kerüljön, ne a spam mappába.

A DKIM, SPF és DMARC beállítása elengedhetetlen. Ezek nélkül aligha várható, hogy elkerüljük a spam mappát.

Más megoldások, például a SendGrid vagy az SMTP2GO is használhatók; nincs kapcsolatunk ezekkel a cégekkel. Az ilyen szolgáltatók általában API-végpontokat kínálnak, így kódból automatizálható a levélküldés. A megbízható kézbesítés az üzletük alapja: nem maradnának talpon, ha leveleik állandóan spamként végeznék. Ilyen szolgáltatás választásakor azonban előbb kérjünk engedélyt, mert külön szabályaik lehetnek. Ugyanez a webhely tárhelyszolgáltatására is vonatkozik.

Feladócím

Domain

Magától értetődő, hogy az olyan ingyenes szolgáltatói címek, mint a „@gmail.com” vagy „@outlook.com”, ebben a helyzetben nem megfelelőek.

Egy „something.onmicrosoft.com” jellegű domain működhet, mert az onmicrosoft.com-címek még elég gyakoriak ahhoz, hogy valamennyi tiltólistázása túlzott intézkedés legyen.

Én azonban saját domaineket használtam. Valószínűleg a domain kora a legfontosabb tényező. Bár a pontos elvárt kort nehéz megállapítani, három hónapnál fiatalabb domainnel nem indítanék adathalászat-szimulációt. Előre kell készülni a domainek regisztrálásával, vagy lejáró domaint lehet vásárolni. Naponta járnak le domainek. Az utóbbi lehetőségnél figyelembe kell venni az etikai szempontokat, mert egyes lejáró domaineket még használhatnak.

Besorolás

Léteznek külső kategorizálási adatbázisok, amelyekbe adathalász webhelyeket jelentenek be. Feltételezem, hogy a biztonsági eszközök ezekkel is azonosítják a veszélyes domaineket. Ugyanakkor az adatbázisok legitim webhelyeket is kategorizálnak, például a pénzügyi szektor oldalait.

A mi esetünkben nem akartuk, hogy a szimulációs oldal forgalmát megjelöljék, ezért minden domaint olyan kategóriába soroltunk, amely jellemzően érzékeny adatokat kezel, például a pénzügyek közé. A besorolás alátámasztására a választott kategóriához illő főoldalt készítettem.

Azt is feltételeztük, hogy a szimulált rosszindulatú levél fogadása előtt egy automatizált rendszer ellenőrizte a domain kategóriáját. Erre azonban nem volt konkrét bizonyítékunk.

A cím helyi része

Érdemes kitalálni egy nevet, például „John Doe”-t, és erre épülő címeket létrehozni, mint a jdoe, john.doe vagy johndoe.

Azt tapasztaltam, hogy a „noreply” vagy „info” helyi részt használó címekről küldött levelek közvetlenül a spam mappába kerültek.

Tartalom

Megfigyeltem, hogy a hivatkozást tartalmazó levelek nagyobb valószínűséggel kerültek spambe.

Ennek mérséklésére barátságos, megszokott vállalati hangvételű megszólítást és egyszerű, munkakört tartalmazó aláírást használtam.

A legtöbb esetben az URL nélküli, egyszerű szöveges levelek — akár HTML-formátumban — nagyobb eséllyel jutottak a beérkező üzenetek közé. Lehetséges stratégia, hogy a hivatkozásos követő levelet csak a címzett válasza után küldjük el. Ehhez az első levélben válaszadásra kell ösztönözni. Ezt nem alkalmaztam, de végső lehetőségként számoltam vele.

Azt is feltételeztem, hogy a hivatkozást tartalmazó levelek bizonyos szavai tiltólistán szerepelnek. Részletesebb kifejtés nélkül: érdemes kerülni a feltűnő UUID-alapú követőazonosítókat az URL-ekben és a túlzottan értékesítésközpontú szöveget.

URL

Tapasztalatom szerint a hivatkozást akkor engedte át a rendszer, ha nem minősítette rosszindulatúnak. Egy egyszerű kérdőív elegendő volt; a bejelentkezési űrlapot egy másik, automatikusan nem ellenőrzött oldalra helyeztem. A webszerver naplóiban ellenőrizhető, mit vizsgált meg automatikusan a bot.

Időzítés és a levelek száma

Ezer levél egyszerre történő kiküldése szinte biztosan aktiválná a spamszűrőket. Ehelyett az alábbi gyakorlatokat követtem:

• Olyan időpontokban küldtem levelet, amikor egy ember is jellemzően küldene: munkaidőben.
• Korlátoztam az egyszerre elküldött levelek számát, hogy ne keltsenek feltűnést.
• A levelek között 30–60 perces szüneteket tartottam, időnként még „ebédszünetet” is, bár nem minden nap.