Email Security Hardening – Deo 2: Anti-phishing i BEC zaštita

Prvi deo serije pokrio je tehničku autentifikaciju — SPF, DKIM, DMARC. Ovaj deo se bavi onim što ostaje čak i kad je sva tehnička autentifikacija besprekorno podešena: napadima koji ne pokušavaju da zaobiđu tehničku proveru, već je jednostavno zaobilaze na drugi način — ili tako što uopšte ne koriste vaš domen, ili tako što kompromituju legitiman nalog koji već prolazi svaku tehničku proveru jer to zaista jeste taj nalog. Business Email Compromise (BEC) je kategorija napada koja ovo najbolje ilustruje, i vredi na samom početku razumeti zašto je tehnička odbrana iz prvog dela serije, ma koliko dobro postavljena, samo deo odgovora.

Zašto BEC zaobilazi tačno ono što smo upravo izgradili

BEC napadi (poznati i kao CEO fraud ili izvršno predstavljanje) prema podacima FBI-jevog Internet Crime Complaint Center-a koštali su organizacije preko 16,6 milijardi dolara u jednoj nedavnoj godini, kroz više od 256.000 prijavljenih slučajeva, sa prosečnim gubitkom od oko 129.000 dolara po napadu. Ono što ovu kategoriju čini posebno opasnom nije tehnička sofisticiranost — često je suprotno, tehnički jednostavna — već to što cilja tačno ono što DMARC iz prvog dela serije ne pokriva.

Vredi ovo eksplicitno razjasniti, jer je čest izvor pogrešnog osećaja sigurnosti: savršeno podešen DMARC sa politikom p=reject štiti od toga da neko šalje mejl koji se lažno predstavlja kao da dolazi sa vašeg domena. Ne štiti ni od jednog od sledeća dva, jednako česta scenarija — napadač koji registruje sopstveni, sličan (lookalike) domen i šalje sa njega mejlove koji tehnički prolaze svaku autentifikacionu proveru, jer legitimno jesu ono što tvrde da jesu (samo za pogrešan, varljiv domen); ili napadač koji je kompromitovao stvaran, legitiman nalog unutar vaše ili partnerske organizacije i šalje mejlove sa te, potpuno autentične adrese. U oba slučaja, SPF/DKIM/DMARC prolaze bez problema — tehnička provera ne može da otkrije prevaru koja se ne oslanja na krivotvorenje domena koji štitite.

Lookalike domeni — jeftina, efikasna tehnika koja tehnički "prolazi"

Ovo zaslužuje detaljno tehničko objašnjenje, jer razumevanje konkretnih tehnika direktno pomaže u prepoznavanju. Typosquatting koristi uobičajene greške u kucanju ili blisku vizuelnu sličnost — zamena jednog slova, dodavanje ili izostavljanje karaktera. Combosquatting dodaje reči koje grade lažno poverenje (secure-, login-, support-) uz postojeći, prepoznatljiv brend. Homograph napadi idu korak dalje, koristeći Unicode karaktere koji izgledaju identično latiničnim slovima ali su tehnički potpuno različiti karakteri — kombinacija malog "r" i "n" jedno pored drugog vizuelno oponaša slovo "m", što znači da domen koji izgleda kao "rnicrosoft.com" na brz pogled deluje identično kao "microsoft.com".

Vredi dodati praktičnu napomenu o mobilnim uređajima, gde je ovaj rizik posebno izražen: na malim ekranima, mejl klijenti često prikazuju skraćen prikaz email adrese ili se korisnik prirodno fokusira isključivo na prikazano ime pošiljaoca (display name), ne na stvarnu adresu ispod njega — "CEO Ana Petrović" sa lookalike adrese izgleda jednako poverljivo kao i sa prave, jer se retko ko trudi da na malom ekranu proveri stvarnu adresu ispod prikazanog imena.

Šta treba uraditi

• Registrovati bar najočiglednije, najverovatnije varijante sopstvenog domena (uobičajene greške u kucanju, popularne alternativne TLD ekstenzije) defanzivno, kako ih napadač ne bi mogao registrovati prvi — ovo je jeftina, jednostavna mera koja zatvara najniže visećeg voća
• Uvesti kontinuirano praćenje novoregistrovanih domena sličnih organizacionom imenu i brendu — kroz Certificate Transparency logove (koji beleže izdavanje TLS sertifikata i time otkrivaju domene koji se pripremaju za aktivnu upotrebu), WHOIS praćenje, ili namenske servise za zaštitu brenda, u zavisnosti od budžeta i veličine organizacije
• Obučiti zaposlene da fokus stavljaju na stvarnu email adresu, ne samo na prikazano ime pošiljaoca — konkretna, ponovljena vežba (pokazati primere lookalike adresa tokom obuke) daje mnogo bolji rezultat od apstraktnog upozorenja "budite oprezni"
• Konfigurisati email gateway ili filter da posebno označava mejlove sa novoregistrovanih domena (domen star manje od određenog broja dana) — legitimni poslovni partneri retko iznenada počnu komunikaciju sa domena koji je registrovan pre par dana
• Razumeti da DMARC i lookalike zaštita rešavaju različite probleme i oba su potrebna — DMARC štiti vaš domen od krivotvorenja, dok zaštita od lookalike domena štiti od toga da neko koristi sopstveni, sličan domen da vas prevari; investicija u jedno ne umanjuje potrebu za drugim

Kompromitovan legitiman nalog — kad autentifikacija nije problem, već rešenje koje je zaobiđeno

Ovo je scenario koji nijedna tehnička autentifikacija ne može otkriti, jer mejl zaista dolazi sa legitimnog, autentičnog naloga — napadač je jednostavno preuzeo kontrolu nad njim, tipično kroz krađu kredencijala (phishing, curenje lozinke sa drugog, kompromitovanog servisa gde je ista lozinka ponovo korišćena) ili zaobilaženje MFA kroz tehnike poput MFA fatigue (bombardovanje korisnika ponovljenim zahtevima za odobrenje dok neko, iz zamora ili nepažnje, ne odobri jedan od njih). Jednom unutar naloga, napadač često provodi vreme u izviđanju — čitanju prethodne prepiske da nauči stil pisanja, prepozna stvarne, tekuće projekte, i identifikuje pravi trenutak za ubacivanje lažnog zahteva (npr. tačno kad se očekuje stvarna faktura od poznatog dobavljača).

Šta treba uraditi

• Zahtevati MFA za pristup email nalozima bez izuzetka, po istom principu opisanom kroz svaku prethodnu seriju o kritičnoj infrastrukturi na ovom blogu — ovo ostaje pojedinačno najefikasnija mera protiv krađe kredencijala kao ulazne tačke
• Koristiti phishing-otpornu MFA (hardverski ključevi, FIDO2/passkeys) gde je izvodivo, umesto SMS ili čak standardnih push notifikacija koje su podložne MFA fatigue tehnikama opisanim ranije u tekstu
• Pratiti neuobičajene obrasce prijave na email naloge — nova geografska lokacija, neuobičajeno doba dana, ili prijava odmah nakon niza odbijenih MFA zahteva — kroz mogućnosti platforme (detaljnije obrađene u kasnijim delovima serije za Exchange i Google Workspace) ili SIEM integraciju
• Pratiti kreiranje pravila za automatsko prosleđivanje ili brisanje mejlova unutar naloga — čest, konkretan trag koji napadač ostavlja nakon kompromitacije naloga je pravilo koje tiho prosleđuje kopiju svake ulazne poruke na spoljnu adresu, ili automatski premešta odgovore na određene ključne reči (npr. "faktura", "banka") u fasciklu koju vlasnik naloga ne proverava

Verifikacija van mejla — jedina prava odbrana protiv uspešno izvedenog scenarija

Ovo je najvažniji, praktičan zaključak celog dela, pa vredi ga naglasiti direktno: ako je cilj napadača da ubedi nekoga da uradi nešto (izvrši prenos novca, promeni podatke o bankovnom računu dobavljača, otkrije osetljive podatke), ni najbolja tehnička odbrana ne može garantovano sprečiti dovoljno ubedljiv, dobro istražen pokušaj. Jedina pouzdana odbrana je proces koji zahteva potvrdu van samog email kanala pre nego što se bilo koja finansijski ili operativno značajna akcija izvrši.

Šta treba uraditi

• Uvesti obaveznu, van-kanalsku (out-of-band) verifikaciju za sve zahteve koji uključuju prenos novca ili promenu bankovnih podataka — telefonski poziv na unapred poznat, proveren broj (nikad na broj naveden u samom sumnjivom mejlu), ne odgovor na isti mejl thread
• Sprovesti dual-approval (dvostruko odobrenje) za finansijske transakcije preko definisanog praga vrednosti — dve nezavisne osobe moraju odobriti pre izvršenja, čime se napadaču onemogućava da uspešnom prevarom jedne osobe direktno izvrši transakciju
• Za promene osetljivih podataka (bankovni računi dobavljača, kontakt podaci izvršnog osoblja), zahtevati potvrdu kroz unapred dogovoren, alternativan kanal — ne prihvatati promenu bankovnog računa dobavljača isključivo na osnovu mejla, bez telefonskog poziva na poznat broj tog dobavljača
• Za scenarije koji uključuju video ili glasovnu komunikaciju kao deo verifikacije, imati na umu rastući rizik deepfake tehnologije — sofisticiraniji napadi u 2026. godini sve češće koriste generisan glas ili video u realnom vremenu da oponašaju izvršnog direktora tokom poziva, što znači da čak ni glasovna potvrda više nije apsolutno pouzdana bez dodatnog konteksta (unapred dogovorena, tajna reč za posebno osetljive transakcije je jedna praktična, jednostavna mera)
• Dokumentovati ovaj proces kao formalnu, obaveznu politiku, ne kao neformalnu, prećutnu naviku — formalna politika daje zaposlenima jasan, odbranjiv razlog da odbiju ili odlože zahtev koji deluje hitno, čak i kad navodno dolazi od izvršnog direktora

Napomena o riziku: istraživanja dosledno pokazuju da brzina reagovanja nakon otkrivanja uspešnog BEC napada direktno određuje ishod — preko polovine žrtava koje su brzo reagovale uspele su da povrate značajan deo (preko 80 procenata) ukradenih sredstava, dok odlaganje reagovanja dramatično smanjuje šansu za povraćaj. Imati unapred pripremljen, jasan proces za trenutak kad se otkrije uspešan napad — ko se odmah kontaktira (banka, FBI IC3 ili lokalni ekvivalent, pravni tim) — jer trenutak otkrivanja nije vreme da se taj proces prvi put smišlja.

Simulacije i obuka — merljiva, ne simbolička praksa

Isti princip koji se provlači kroz svaku seriju na ovom blogu o testiranju (backup restauracija, firewall pravila, incident response) primenjuje se i ovde: sposobnost prepoznavanja phishing/BEC pokušaja ne treba pretpostaviti, već redovno testirati kroz kontrolisane, realistične simulacije.

Šta treba uraditi

• Sprovoditi redovne, realistične phishing simulacije (ne samo očigledne, lako prepoznatljive testove) koje odražavaju stvarne, aktuelne tehnike, uključujući scenarije koji specifično oponašaju BEC obrazac (hitan zahtev navodno od izvršnog rukovodstva)
• Meriti i pratiti trend rezultata tokom vremena po timu ili odeljenju, ne samo ukupan, jednokratan procenat — odeljenje sa finansijskim ovlašćenjima (koja su direktna meta BEC napada) zaslužuje pojačanu pažnju i češće testiranje od odeljenja bez takvih ovlašćenja
• Tretirati rezultate simulacije kao priliku za dodatnu obuku, ne kao osnovu za kažnjavanje pojedinaca — kažnjavajući pristup vodi ka prikrivanju grešaka i kasnijem prijavljivanju stvarnih incidenata, tačno suprotno od željenog ishoda
• Uključiti konkretan, jasan proces prijavljivanja sumnjivog mejla (npr. dugme za prijavu unutar mejl klijenta) i osigurati da prijavljeni slučajevi zaista dobiju brz, vidljiv odgovor — zaposleni koji prijavi sumnjiv mejl i nikad ne dobije nikakvu povratnu informaciju brzo prestaje da se trudi da prijavljuje

Ovim se zaokružuje pregled anti-phishing i BEC principa koji dopunjuju tehničku autentifikaciju iz prvog dela serije. Sledeći deo prelazi na konkretnu platformu — Exchange Server i Exchange Online — i pokazuje kako se principi opisani kroz prva dva dela ove serije primenjuju u praksi kroz specifična podešavanja te, najrasprostranjenije poslovne email platforme.