Hitno je. Ma i hitnije nego hitno. Njihov kupac je zaprimio e-mail od njihovog djelatnika i s njihove domene. U mailu se navodi da su promijenili banku, SWIFT i broj računa. Odsada je naš klijent na švicarskom računu ING banke i sve uplate bi trebale ići na novi bankovni račun.
Bilo je gotovo nemoguće razaznati drugu stranu od uzbuđenja Jedino što shvaćamo je da ih je, kupac nazvao da provjeri navode, na sreću, ali još nije platio nikakve pristojbe.
Tehnička pozadina
Za klijenta smo već podešavali neke stvari radi već pokušanih metoda prevare. Zapravo, u posljednjih nekoliko godina nije se dogodio niti jedan incident. Međutim, čovjek se nađe u nevjerici i preispitivanju samog sebe, što smo zaboravili i gdje smo napravili propust.
Klijent koristi Microsoft Exchange 2016 i sve zakrpe i zadnji CU (nije sigurnosni propust).
Ispred Exchangea je i firewall s IPS (Intrusion Prevention System) koji traži napade na aplikaciju (nije niti near-zero-day propust).
Svi korisnici e-maila pristupaju Exchange serveru na https kriptiranome portu 443 s validnim certifikatom (nije niti prisluškivanje veze).
Cijela domena klijenta ima stroga SPF, DKIM i DMARC pravila (nije niti email spoofing ili zavaravanje pošiljatelja).
Korisnik koristi 14-znamenkasti zaporku, velika i mala slova, brojke i poseban znak (nije brute-force vjerojatan).
Koji je vrag onda?
Hoj Windows logu, ubila te tama…
Budući da je Microsoft Exchange prošle godine često bio meta napada, zabrinuti smo da je cijeli poslužitelj kompromitiran. Krenuli smo putem istraživanja Windows logova, pristupa, ECP, testiranje TestProxyExchange i nismo našli nikakav backdoor na serveru.
Okrećemo se korisnicima.
Čitanje IIS logova pristupa na Exchangeu je poseban sadizam. Gotovo svaki korisnik ima poštanski sandučić na svom pametnom telefonu i računalu. Korisnik često izlazi iz ureda gdje se automatski spaja na mobilnu Internet mrežu, pa se vraća natrag na WiFi i svaki put se to zapisuje u log, što komplicira ionako ogromnu podatkovnu buku.
Naravno, čitanje loga je također teško. Log se rotira kad dosegne određenu veličinu i otvara se novi log.
Unutar samog loga su podaci jako teško čitljivi za uočiti neku nepravilnost.
Stoga, ako u logu pronađete ciljanog korisnika da se povezuje s neke adrese, morat ćete provjeriti je li IP adresa zaista od korisnika ili od napadača. Adresa trebala bi barem odgovarati državi/regiji u kojoj se nalazi. Ako imamo IP iz Sjedinjenih Država, a korisnik u to vrijeme nije u Sjedinjenim Državama, onda nešto nije uredu.
Međutim, izvlačiti sva spajanja iz loga i zatim tražiti na Internet servisima odakle je IP adresa, je zbilja dosadan i zamarajući posao.
Stoga tražimo alternative.
Big data i parseanje logova
Mijenjamo strategiju. Umjesto pretraživanja zapis po zapis, idemo uzeti sve logove i uvući ih u bazu podataka ElasticSearch.
Raščlanit ćemo svaki zapis, tj. bazi ćemo reći šta je koji tip podatka u dijelu jedne linije loga. Imamo korisničko ime, IP adresu, Status kod, itd.
Dižemo i Logstash, te radimo GROK (parser) uzorak koji će podijeliti hrpu teksta u smislene dijelove.
Konačno, imamo bazu za rad i pretragu kakvu zaslužujemo.
Ali to nije sve! Pošto smo označili IP adresu, ElasticSearch radi provjeru države i grada iz koje se spajanje obavlja. I sve to stavlja u druga polja, koja također možemo se koristiti i za pretraživanje.
Slažemo mapu spajanja svih korisnika.
Međutim, još je šuma podataka, imamo i uredna spajanja i pokušaje spajanja. Oni validni su s statusom 200, stavljamo to u filtar, te još filtriramo korisnika s čijeg računa je i slan lažni e-mail.
Grupiramo i po državama… I?
Račun je povezan s vanjskom IP adresom (iz UK) gdje korisnik nije bio prisutan.
Interna istraga kod klijenta
Obavještavamo klijenta da smo vidjeli datum prvog UK spajanja sa poslužiteljem.
U razgovoru s korisnikom e -pošte saznali smo da je primio phishing mail u kojoj se od njega traži da se ponovno prijavi sa lozinkom kako bi izbjegao zaključavanje svog računa e-pošte, što je rado učinio.
