Egy cybertámadás forgatókönyve

Az alábbi cikkemben szeretném kötetlenebb stílusban bemutatni, hogyan zajlik egy célzott phishing cybertámadás. A levezetés mellett bemutatom azokat a Microsoft 365 / Azure szolgáltatásokat is, amikkel ezek a támadások lefülelhetők/megállíthatók.

Képzeletbeli támadónk, legyen a neve Mr. X, szeretne bejutni a Riprop Kft céges IT-rendszerébe, hogy onnan értékes adatokat szerezzen meg észrevétlenül. Célja tehát a rejtőzködés, nem a károkozás, így nem is gondolkodik romboló technikákban. A Riprop Kft egy “felhős” cég, a földi infrasruktúrája mellett M365-öt használ.

Mr. X, miután egyszerű script-kiddie megoldásokkal leellenőrizte hogy kívülről nem tud bejutni a hálózatba, másik támadási vektort keresett. Azt már megtanulta, hogy az emberi tényező (mulasztás, hiszékenység) a legtöbb sikerrel kecsegtető lehetőség, így a phishing mail támadás mellett döntött.

Kisméretű botnetje segítségével elkezdett leveleket küldözgetni a Riprop Kft egyes dolgozóinak. Az emailcímek formátumát ismerte (kis.jolan@riprop.com), így könnyű dolga volt. Az adathalász emailt úgy állította össze, hogy a benne lévő link egy O365 loginpage-re hasonlított, a levél tartalma pedig az volt hogy az IT Helpdesk kéri, hogy a belépésével erősítse meg az accountját.

(ennél vannak kifinomultabb támadások is, tudunk olyan esetről, ahol a támadók ismerték a titkárnő színházak iránti rajongását, ezért a kedvenc színháza formátumával preparált adathalász levelet küldtek neki…)

Lehetséges védekezés: az Office 365 Advanced Threat Protection szolgáltatás egy extra védelmi réteg az Exchange Online-ban. Segítségével az adathalász, és egyéb hamisított mailek (pl. a CEO nevében küldött, pénz átultalását utasító) kiszűrhetőek, fejlett AI alapján. Emellett képes a mailekben lévő linkek előzetes megvizsgálására és ha támadó webhelyre mutatnak, akkor letiltja az elérést a felhasználó számára. Szintén képes az emailekben érkező csatolmányok megvizsgálására, egy felhős virtualizált környezetben lefuttatására. Ha a kapott PDF file mondjuk egy preparált darab és megnyitásakor mindenféle gyanús tevékenységet végezne (powershell futtatás, http kapcsolódás egy ismeretlen IP-címhez, stb) akkor a csatolmányt letiltja, nem kézbesíti a felhasználónak.

Az alábbi képen összefoglalva a működése:

Tegyük fel, hogy ez a védelmi megoldás nem volt beállítva Riprop Kft-nál, így az adathalász mailek akadálytalanul bejuthattak. Sajnos kb. harminc dolgozó nem figyelt eléggé, és gondolkodás nélkül megadta a felhasználónevét és jelszavát a kért URL-re kattintva (közben morogva, hogy “jajj, az IT már megint akar valamit, kétnaponta küldenek maileket, azt se tudom már mit akarnak”. (ez nagyon fontos szempont IT-oldalról, hogy nem szabad “elárasztani” infókkal-változásokkal a felhasználókat, hiszen nem tisztjük ilyen mélységben követni. Teljesen jogosan, csak a munkájukat akarják végezni. Fontos tehát megtalálni az egyensúlyt az oktatás-kommunikáció-informálás között, különben a felhasználók közömbössé válnak és könnyebben esnek ilyen tévedések áldozatául)

Lehetséges védekezés: van mód az O365-be jelszó nélkül bejelentkezni. Használható az okostelefonokkal a Phone Sign-in megoldás (az O365 a név megadása után nem jelszót kér be, hanem a Microsoft Authenticator alkalmazáson megjelenít 3 számjegyet és a megfelelőt kell kiválasztani. A kiválasztás után pedig az okostelefon ujjelnyomat-azonosítása a második faktor.

Ha a Riprop Kft-nél ez a megoldást implementálták volna, a dolgozóknak feltűnik, hogy miért jelszót kér a rendszer, mikor mindig Phone SignIn-t használtak.

Szintén használható a FIDO2 biztonsági kulcs erre a célra, az USB-s hardveres kulcs végzi a hitelesítést, jelszó megadására ott sincs szükség.

Támadónk, Mr.X számára tehát megnyílt az aranybánya, volt harminc érvényes felhasználóneve és jelszava a rendszerhez. Mivel lusta volt próbálgatni egyenként a hozzáféréseket, a már meglévő botnetje segítségével kezdett el belogolni a Riprop Kft rendszerébe a megszerzett accountokkal.

Lehetséges védekezés: Az Azure AD Identity Protection szolgáltatás monitorozza a felhasználói belépéseket, szokásokat. Az ezektől eltérő jelenségekre (pl. bejelentkezés ismeretlen országból (ahol a felhasználó nem járt az elmúlt fél évben), lehetetlen utazás megvalósulása (több belépés rövid idő alatt, pl. pár perc eltéréssel Moszkva és Madrid), belépés TOR-hálózatból, vagy botnet-tag számítógépről) azonnal reagál. Az észlelt anomáliákhoz akciókat is tud hozzárendelni, pl. ismeretlen helyről belépés esetén kényszeríti az MFA hitelesítés végrehajtását, vagy kompromittálódott account esetén azonnal letiltja azt és csak a helpdesk oldhatja fel.

(Kompromittálódott accountok: azok, amiknek kiszivárgott a név/jelszó párosa, és megtalálhatóak mindenféle adatbázisokban. Nem titok, a Microsoft elég sok pénzt és energiát áldoz rá, hogy jelen legyen a “darkweben” is, ahol az ilyen adatbázisok megtalálhatók. Ha talál egyezést, az adatbáziban szerepel a név/jelszó páros, azonnal tudja értesíteni az Azure AD-t, aki a fenti módon letiltja az accountot.

Sajnos mivel a Riprop Kft-nél ez a megoldás sem volt implementálva, nem tűnt fel senkinek, hogy tömegesen jelentkeznek be a felhasználók adataival, különböző országokból.

A baj megtörtént, támadónk bejutott a rendszerbe. Volt néhány alapszintű (tehát admin privilégiumokkal nem rendelkező) accountja, amivel szabadon tudott mozogni a hálózaton. A további lépések ilyenkor a támadó részéről:

  • felmérni, milyen szenzitív (admin jogkörrel bíró) accountok vannak a hálózatban (ezt hívják Reconnaissance-nak)
  • megpróbálni hozzáférést szerezni a szenzitív accountokhoz (lateral movement)
  • végül átvenni az uralmat a rendszer felett, admin jogosultságokkal megbújni a rendszerben (domain dominance)

Mr. X tehát különböző felderítési technikákat alkalmazva (ldap lekérdezések, stb) eljut odáig, hogy van a hálózatban egy Terminal Server, amihez van működő accountja is, ráadásul a TS-en futó régi számlázóprogram miatt local admin jogosultsággal. Ide belépve felfedezi, hogy bizony a helyi IT hibázott és konfigurációs hiba miatt a víruskereső nem működik. Innentől felgyorsulnak az események:

Mivel admin joga van, rögtön látja, hogy még a domain adminok is ide lépnek be, sőt, van éppen bejelentkezett admin. Különféle programok segítségével (pl. Mimikatz) képes kinyerni a TS memóriájából a domain admin jelszóhash-t! Ne felejtsük el, a vírusirtó nem működik a gépen, tehát bármilyen malware jellegű programot lefuttathat.

A megszerzett hash-hel továbbhalad a központi SQL szerver felé, és a domain admint megszemélyesítve bejut az adatbázisszerverre. Ujjgyakorlatként még a domain controllerre is ellátogat, ahol kiállít magának a örök lejáratú kerberos ticketet, így bármelyik szerveren tud már mozogni. Itt a vége, csapda bezárult, a domain dominance megvalósult. Mr. X uralja a hálózatot, az SQL szerverről csendben készít adatbázis dumpokat és http segítségével tölti fel őket a saját rendszerébe. A történésekről nem tud senki, Mr. X hónapokig rejtőzhet a hálózatban (az átlagidő, a bejutásról a felfedezésig, 180 nap körül van, azaz a támadók gyakran fél évig is garázdálkodhatnak a rendszerben, mire felfedezik őket).

Lehetséges védekezés: az Azure ATP segítségével a fenti folyamatok egyenként detektálhatók (Reconnaissance-Lateral Movement-Domain Dominance), így az adminoknak azonnal van módjuk a támadást megakadályozni. A támadónak időre van szüksége, amíg a felderítést stb végrehajtja, ez sokszor több hét is lehet, így van idő a támadás kifejlődése előtt megállítani azt.

Az Azure ATP a domain controllerekre telepített szenzorok segítségével elemzik a hálózati forgalmat és azonnal riasztást küldenek különféle támadási észlelések esetén. Az alábbi táblázat mutat pár észlelési típust, de ez folyamatosan fejlődik, és felhős technológia révén, folyamatosan frissül is.

Kiegészítő védekezés: többszintű jogosultsági rendszer kialakítása. Külön accountok admin feladatokra, “sima” usernek sose legyen admin szerepköre. Admin accountokkal csak védett gépekre lehessen bejelentkezni, többfaktoros hitelesítéssel (pl. security key vagy virtual smart card)

Mint a fenti forgatókönyv is mutatja, a támadás könnyen megvalósítható, a fenyegetés nagy. A cikkben leírt védelmi megoldások viszont nagyrészt megtalálhatóak az O365/M365 előfizetésekben, csak elő kell őket venni a polcról és beüzemelni. Egy ilyen kiépített rendszerrel, a támadás kb az első lépésnél (phishing mailek megérkezése) elhalt volna.

Miért van szükség az E5-re?

Az M365 E5 a legnagyobb nagyvállalati csomag, ami a Microsoftnál elérhető. A cikkben csak az IT-biztonsággal kapcsolatos részeire térek ki, az egyéb komponenseire (PowerBI, Audio Conferencing stb) nem.

Miért érdemes tehát az E5-be invesztálni? A legfőbb szempont, hogy nem kell csak IT-kiadásként gondolni a licenszekre, hanem komoly szerepük van az üzletfolytonosság fenntartásában. Ha egy vírustámadás miatt leáll a cég működése, az veszteség. A flottaüzemeltetők sem költségként tekintenek minden kötelező szervizelésre, hanem befeketetésként, hogy az üzlet működjön, fennakadás nélkül és bevételt termeljen.

A modern IT-világban már nem nehéz megoldani a folytonossághoz szükséges redundanciát, akár felhős, akár földi eszközökkel. Mindig be lehet tenni még egy szervert, még egy switchet, még egy internetkapcsolatot behúzni egy X-edik szolgáltatótól.

A következő feladat ennek a működésnek a “faltól-falig” védelme. A védekezés minden cég feladata, mérettől függetlenül. A végpontok, az identitások (felhasználói accountok) és céges adatok védelme kritikus feladat.

Régi és veszélyes gondolkodás, hogy “á, ki kíváncsi a mi adatainkra…”. Előfordult már, hogy a “kis” marketing partner céget törték fel, így szerezve belépési adatokat és hozzáféréseket a “nagy” céghez.

Az alábbi ábrán a klasszikus támadási lánc, az attack kill chain látható:

Balról jobbra haladva, röviden: phishing levelekkel és emberi tévedést- hiszékenységet kihasználva a támadók bejutnak a rendszerbe. Onnan továbbhaladva megpróbálnak egyre magasabb jogosultságokat megszerezni (lateral movement, admin jogosultságok megszerzése). Végül átveszik az irányítást a domain felett és a megszerzett adatokat kijuttatják (extrafilate data)

Itt jön be a képbe az E5 szerepe:

A fenti támadási lánc minden eleméhez van védelmi megoldása. A támadások már az elején azonosíthatók és megakadályozhatók.

Ahogy a képen látjuk, a támadás első fázisára az O365 ATP nyújt megoldást. A phishing maileket fejlett gépi intelligenciával megtámogatva megszűri, a csatolmányokat felhős sandboxban lefuttatja és elemzi viselkedésüket, a mailekben érkező linkeket megszűri, reputációs adatbázis alapján. Szintén erős az anti-spoofing, azaz levélhamisítás elleni védelme.

A következő részben az account feltörési kísérleteket és esetlegesen ellopott identitásokat az Azure AD Identity Protection és Azure ATP szolgáltatásokkal lehet felfedezni és megállítani.

Az Identity Protection figyel a bejelentkezési anomáliákra (idegen országokból, fertőzött hálózatból történéő belépésékre) és szükség esetén kikényszeríti a multi-faktoros hitelesítést, így meggyőződve róla, hogy a valódi felhasználó lépett be.

Az Azure ATP pedig a földi rendszerek kommunikációját figyeli (domain controllerek) és figyelmeztet, ha támadás készülődik (pl. jelszótöréses támadás egy felhasználói fiók ellen vagy Kerberos-ticket manipuláció). Ahogy az Identity Protection esetében, itt is a gépi elemzés segíti a támadások felmérését.

A céges adatok kiszivárogatásának megakadályozására és DLP-funkcióra pedig az utolsó fázisban szereplő Cloud App Security képes.

A Cloud App Security képes felmérni a végpontok (laptopok) forgalmát, adatszivárgási, jogosultatlan megosztási kísérletekre felhívni a figyelmet és megállítani azokat.

Milyen szolgáltatásokat kapunk még az E5-tel?

  • Self-service password reset, önkiszolgáló jelszóvisszaállítás: a felhasználók az IT-helpdesk segítsége nélkül tudják resetelni elfelejtett jelszavukat, kétfaktoros hitelesítés mellett
  • Conditional Access, feltételes hozzáférés: segítségével definiálható, hogy melyik felhős (és adott esetben földi) céges erőforráshoz milyen feltételek esetén lehet hozzáférni. Például, céges levelezés csak domain-tag gépről legyen elérhető.
  • Azure Information Protection, dokumentumvédelmi megoldás: a céges adatok kategorizálására és szükség esetén védelmére is. A védett dokumentumokhoz csak a meghatározott jogosultsággal bíró kör fér hozzá, függetlenül a file helyétől (emailen elküldve, USB-re kimásolva stb.)
  • Azure AD Privileged Identity Management, felhős jogosultságkezelési megoldás: admin szerepkörök időre történő megadása, auditálással, kötelező előzetes jóváhagyásokkal. Segítségével előírható, hogy ki, mennyi időre, milyen jogosultságot kapjon, majd az idő letelte után automatikusan visszavonódik.
  • Azure MFA, többfaktoros hitelesítés: segítéségvel az erőforrásokhoz való hozzáférést megerősíthetjük, a jelszavas bejelentkezésen túl. A fent említett Identity Protectionnal kombinálva, különböző scenáriókra is automatikus reagálás előírható. Például másik kontinensről történő bejelentkezési kísérlet esetén kötelező MFA-hitelesítés végrehajtása.
  • Microsoft Defender ATP: végpontvédelmi megoldás, ami a fejlett támadási formákat és fenyegetéseket észleli és elhárítja. Figyeli a végpontok viselkedését és gépi intelligencia segítségével proaktívan választ ad a felmerülő incidensekre

A teljes E5 funkcionalitás listája elérhető az alábbi linken: https://docs.microsoft.com/office365/servicedescriptions/downloads/microsoft-365-compliance-licensing-comparison.pdf

A fenti termékek működése és nagyfokú integráltsága miatt (pl. Azure ATP integrálódik a Cloud App Securityvel, így egy helyen tekinthetők meg az érintett fenyegetések) számít igazán ütőképesnek az M365 E5. Amennyiben olyan megoldást keresünk, amivel a céges adatokat, a végpontokat és felhasználói fiókokat biztonságban szeretnénk tudni, az E5 egy jó alternatíva lehet.

OneDrive mint felhasználói backup

Az alábbi cikkben az OneDrive nem új, de vállalati környezetben kevéssé használt funkcióját szeretném bemutatni: automatikus folder átirányítást.

Picit messzebbről indulva: vállalati környezetben nagyon régóta szabályozott, hogy adatokat nem mentünk a helyi gépre, kizárólag a fileszerverre/sharepointra/egyéb központi helyre, amit az IT felügyel, redundáns, van róla mentés stb.

A valóságban viszont számos alkalommal előfordul, hogy a szabályozás ellenére bizony a Desktopra, Documentsbe, egyéb helyekre kerülnek a fileok (tegye fel a kezét, aki még nem “követett el” ilyet 🙂 ) Ennek okai változatosak “nem volt jó a hálózat, nem értem el a fileszervert” , “nem ment valamiért a vpn” és bizony sok alkalmazás alapból ezeket a helyeket kínálja fel mentésre.

A probléma pedig akkor van, mikor a géppel valami történik, tönkremegy benne az adathordozó, ellopják, egyéb dráma történik. Ilyenkor senki nem szeretne az illető helyében lenni, akinek a főnökénél kell számot adnia róla, hogy miért veszett el a nagyon fontos szerződés vagy egyéb céges adat…

A megoldást az OneDrive KnownFolderMove funkciója jelentheti, azaz a gépen található Desktop, Documents és Pictures folderek átirányítását az OneDrive-ba. Innentől kezdve ha bármit lementünk mondjuk a Desktopra, az automatikusan szinkronizálódik a felhőbe.

A KFM (KnownFolderMove) funkció bekapcsolható Intune-nal menedzselt gépek esetén, illetve System Center Configuration Manager és Group Policy is támogatott.

Kétféle módon működhet történhet az átmozgatás:

Automatikusan, ekkor a felhasználó üzenetet kap, hogy a mappák átkerültek az OneDrive-ba

Vagy a felhasználóknak kell elvégezniük a beállítást és ekkor kapnak egy felbukkanó üzenetet:

Amennyiben a felhasználó csak bezárja az ablakot, további üzenetekkel fogja informálni a rendszer, hogy ez a beállítás kötelező:

Ez addig ott marad a képernyő sarkában (nem zárható be) amíg a beállítás meg nem történik.

A legjobb megközelítés a két policy ötvözése: legyen automatikus az átmozgatás, de ha az nem sikerül valamiért, akkor a felhasználót kéri fel a rendszer hogy végezze el. Ekkor persze lehet kérni az IT segítségét, és az adminok is biztosak lehetnek benne, hogy mindenhol végbement az átmozgatás.

Az adminoknak szintén jó hír, hogy policyból letiltható hogy a felhasználók megszüntessék ezt az átirányítást. Ilyenkor az OneDrive kliensen a Stop Backup gomb kiszürkül, tehát nincs mód rá, hogy ezek a mappák kikerüljenek a védelem alól.

Tervezéskor érdemes még észbentartani, hogy egyes felhasználóknál nagy lehet a Desktop/Documents/Pictures mappa mérete, ami a KFM beállításkor jelentős hálózati forgalmat fog okozni.

A KFM implementálása erősen ajánlott bármilyen vállalati környezetben, az automatikus mentés nagy terhet levesz a felhasználók és rendszergazdák válláról egyaránt.

Istvánffy Zoltán

Új szemlélet az IT-biztonságban – Zero Trust Modell

avagy a perimeter-alapú hálózati védekezés miért kevés?

Az utóbbi években bekövetkezett robbanásszerű IT-fejlődés komoly kihívás elé állítja az üzemeltetőket és cégvezetőket egyaránt. Elterjedtek a mobileszközök (laptopok, tabletek, okostelefonok), az olcsó internet gyakorlatilag közszolgáltatássá lépett elő, és ezek a folyamatok változást generáltak a felhasználók oldalán is.

Egyre nőtt az igény, hogy mobileszközét a céges hálózaton kívül is használhassa, dolgozhasson otthonról, esetleg akár a saját eszközeit is bevethesse (BYOD). Alapvető elvárás lett, hogy a levelezését kezelhesse az okostelefonján, utazás közben is tudjon céges dokumentumokat megnyitni és így tovább. Az IT-mobilitás megteremtése kvázi kötelező feladat lett.

Ennek a nyomásnak a szervezetek igyekeznek is megfelelni, a felhős megoldások bevezetésével egyre könnyebbé válik a szolgáltatások elérése (pl, Exchange Online, Microsoft Teams), már akár az otthoni tableten is gond nélkül lehet követni a céges levelezést. Az eszközök védelmét is igyekeznek úgy-ahogy megoldani, általában antivirus megoldás bevezetésével (laptopok esetén, okostelefonoknál szinte semmi…)

Ettől függetlenül azonban a szervezeteknél még mindig kardinális kérdés maradt a klasszikus céges hálózat védelme. Ez érthető, hiszen a nagyon új, “felhőben született” cégeket leszámítva, mindenki rendelkezik földi infrasruktúrával, ott található az identitás-középpont (Active Directory), és a céges erőforrások nagy része is. A védelemre jellemzően nagy figyelmet fordítanak, robosztus tűzfalrendszer-megoldások, IDS/IPS, DDOS védelem,bonyolult VPN-es megoldások, ezekre hajlamosak milliókat is költeni. Sok esetben csak annyi a gondolatmenet, hogy “mi védettek vagyunk, minket nem lehet feltörni”

A gond ott kezdődik, hogy ezek a védelmi megoldások csak “kintről”, az internet felől élnek. Mi történik, ha egy mobilkliens bekerül a céges hálózatba? Semmi, hiszen a határon belül van, nem vonatkozik rá védelmi policy. Sok terméknél a belső hálózat esetén leold minden védelem, az eszköz “szabaddá válik”.

(Természetesen, vannak megoldások a belső hálózat védelmére, kliensek szűrésére. Régen a Microsoft Network Access Protection tudta ellátni ezt a feladatot, illetve a Cisco-nak is van ilyen terméke)

A céges adatok, adatvagyon védelme viszont ugyanúgy lényeges, nem számít, honnan érik el a kliensek, külső vagy belső hálózatból. Itt jön a képbe a Zero Trust megközelítés:

“Állandó ellenőrzés, bizalom nélkül!”

A Zero Trust három alapelve:

  • az identitás (felhasználó hitelesítése) ellenőrzése
  • az eszköz védelme (egészségi állapota legyen megfelelő)
  • hozzáférés ellenőrzése (csak annyi jogosultsága legyen a felhasználónak, és csak azokhoz, ami éppen szükséges)

Hogyan biztosíthatók ezek?

Identitás védelmének erősítése és megkövetelése: többfaktoros hitelesítés megkövetelésével, biometrikus azonosítási megoldásokkal, jelszavak felszámolásával

Eszköz állapota: az eszközök MDM-megoldásba bevonásával, megfelelő egészség-állapot megkövetelésével (device health)

Least privileged user rights: senkinek ne legyen több jogosultsága, mint szükséges

A fenti három tétel megvalósításával (vonatkozzon ez külső-belső hálózatra) nagy lépés lehet tenni a biztonság növelésére.

A Microsoft Zero Trust architektúráját a lenti ábra szemlélteti:

A megoldás lényege: a felhasználó az Azure AD-ban hitelesíti magát (MFA-val), az eszközének felügyeletét az Intune látja el. Az Itune előír egy bizonyos egészség-állapotot az eszköz számára (pl. kötelező lennie vírusirtó megoldásnak, vagy PIN kód és eszköztitkosítás megléte). Az Azure AD Conditional Access megköveteli, felhasználó esetén kockázati szint nem lehet magas (azaz nem komprimittálódott az accountja, nem voltak gyanús bejelentkezési kísérletei több országból stb.). Szintén megkövetelhető, hogy milyen alkalmazásokkal lehet elérni a céges erőforrásokat. A Conditional Access segítségével ez a végtelenségig variálható, a szervezet igényei szerint.

Az utolsó jobboldali kockán látjuk az Azure Application Proxy megnevezést. Ennek segítségével földi (on-premise) erőforrásokat tudunk biztonságosan publikálni, adott esetben a földi Sharepoint elérését is a fenti feltételrendszehez köthetjük. Még akkor is, ha a kliens és az SP szerver egy hálózatban vannak!

Összefoglalva: az Azure AD-Intune-Azure Application Proxy segítségével megvalósulhat a Zero Trust Modell, amellyel valós időben szűrhető-engedhető-tiltható, hogy milyen erőforrást milyen felhasználó, milyen feltételekkel érhet el.

A Zero Tust Modell felé elmozdulás nagyon ajánlott minden szervezet számára, megfelelő feltételek biztosításval kielégíti a biztonsági és felhasználói élmények iránti igényeket.