Kako jedan kompromitirani korisnički račun postaje ulaz u sustav
U većini slučajeva napad ne počinje s tehničkim iskorištavanjem sustava. Ne počinje s exploitom niti s kompleksnim alatima. Počinje s pristupom. Najčešće kroz korisnički račun koji izgleda potpuno legitimno. Razlog je jednostavan. Korisnički računi su i dalje najlakša ulazna točka. Jedna lozinka korištena na više mjesta, jedan phishing mail ili jedan kompromitirani vanjski servis mogu biti dovoljni. Kada napadač dobije pristup računu, prvi korak ne izgleda kao napad. Login ide kroz standardni kanal. VPN, web aplikaciju, cloud servis. Nema očitog alarma. Aktivnost izgleda kao normalan korisnik. U tom trenutku ključno pitanje nije kako je račun kompromitiran, nego što taj račun može.
U praksi to vrlo brzo postane problem. Pristup mailu omogućuje reset drugih računa. Pristup SharePointu ili Driveu daje uvid u dokumente s internim informacijama. VPN pristup znači ulaz u internu mrežu. Pristup ticketing sustavu otkriva kako je IT organiziran i gdje se nalaze kritične točke. To nije ranjivost. To je normalno poslovno okruženje. Problem nastaje kada se takav pristup počne koristiti iz perspektive napadača.
Jedan od scenarija koji redovito vidimo tijekom testiranja počinje vrlo jednostavno. Korisnički račun ima pristup internom dokumentu. Dokument sadrži naming konvenciju servera, interne URL-ove i reference na servise. Iz toga se može prepoznati struktura sustava i identificirati ključni dijelovi okruženja, uključujući domensku infrastrukturu. Nakon toga testiranje postaje ciljano. Ako naming otkriva obrasce, traže se sustavi koji odgovaraju tim obrascima. Ako postoje reference na interne servise, ispituje se njihova dostupnost i konfiguracija. Ono što je na početku bio običan dokument postaje osnova za daljnje kretanje kroz sustav. Drugi čest scenarij uključuje file share. Korisnik ima pristup direktoriju u kojem se nalaze konfiguracijske datoteke. Jedna od njih sadrži connection string ili reference na drugi sustav. Time se otvara put prema dodatnom pristupu koji nije bio vidljiv izvan tog konteksta. Treći scenarij, koji je u praksi često najproblematičniji, uključuje lateralno kretanje unutar interne mreže. Kompromitirani korisnički račun ima VPN pristup. Nakon spajanja, napadač vidi interne servise koji nisu izloženi javno. Ako je segmentacija mreže/sustava slaba, moguće je pristupiti dodatnim sustavima bez posebnih ograničenja.
U takvim situacijama često se pokaže da jedan korisnički račun ima pristup na više servisa nego što bi trebao. Ponekad to uključuje i sustave povezane s autentikacijom ili upravljanjem korisnicima. Ne zato što je to planirano, nego zato što se pristupi kroz vrijeme šire, a rijetko se revidiraju. To je trenutak kada kompromitirani račun prestaje biti samo korisnički račun i postaje ulazna točka za širi napad. Važno je naglasiti da u svim tim scenarijima ništa nije “probijeno” na klasičan način. Pristup postoji, aktivnosti izgledaju legitimno i sustav se ponaša kako je dizajniran. Problem nije u jednoj grešci, nego u načinu na koji su pristupi i informacije raspoređeni.
Upravo u takvim situacijama AresISEC u praksi najčešće otkriva stvarnu izloženost. Ne kroz jednu kritičnu ranjivost, nego kroz povezivanje više manjih slabosti koje zajedno čine stvaran napadni put. Ključna stvar koju organizacije često podcjenjuju je da lozinka sama po sebi rijetko predstavlja problem. Problem je što ta lozinka otključava. Ako jedan korisnički račun omogućava pristup dokumentima, konfiguracijama i internim servisima bez jasnih ograničenja, tada njegova kompromitacija postaje početak puno većeg problema. Zato se sigurnost ne može svesti samo na jačinu lozinke ili MFA. To su važni elementi, ali ne rješavaju pitanje strukture sustava i stvarne izloženosti.
Stvarna sigurnost počinje razumijevanjem kako se sustav može koristiti na način koji nije bio planiran.
Izvori:
MITRE ATT&CK – Enterprise Matrix
Verizon – Data Breach Investigations Report
Znate li što jedan korisnički račun u vašem sustavu zapravo može dohvatiti i koliko daleko taj pristup ide?