Vadászat Netflow-val

Share this:

A threat hunting egy régi jó eljárás a kiberbiztonság területén. Nem egy folyamat jellegű dologról beszélünk, hanem allokált időről, aminek része az ötletelés az elemzés, illetve az eredmények validálása és felhasználása.

A feladat végrehajtása folyamán adatkészletekkel dolgozunk (hálózati, végponti logok és metaadatok, biztonsági megoldások naplói, stb.), javarészt mandátum alapján, mivel mi sem láthatunk mindent, másrészről nem is egészséges annyira. A keresgélés a rosszindulatú tevékenységek észlelésére irányul, amelyek elkerülhetik, elkerülhették a meglévő IDPS rendszerünket vagy más automatizált biztonsági megoldásunkat. A találatok alapján aztán hipotéziseket generálunk. Itt nagyon fontos, az analitikus szemléletmód, meg egy strapább ülőgumó – utóbbi minden IT-s kollégának elkell ugye. Nem reaktív, hanem sokkal inkább proaktív tevékenység ez, amely olyan tényezőkre épül, mint a CTI, a „friendly intel” ( a rendszer üzleti folyamatinak és biztonsági ökoszisztémájának az ismerete)és a múltbéli tapasztalat! („Hol a manóban láttam ezt IoC-t korábban?”). A cél a támadók által használt taktikák, technikák és eljárások (TTP) azonosítása.

A Netflow csak egy adatkészlet a sok közül, ami hasznos lehet, igen hasznos. Különösen akkor, ha érzékeny infrastruktúrákban dolgozunk, ahol nincs lehetőségünk a teljes csomagokkal (pcap-ekkel) dolgozni. Talán nem is szeretnénk tudni ezen csomagok tartalmát, mert a felhasználói adatok is nagy mértékben érintettek lehetnek. Ezekben az esetekben a vadászathoz használhatunk a netflow-t, amit akár nevezhetünk a hálózati forgalom kivonatolt metaadatának. Ez gyakorlatias és hatékony a küldetésünk számára, mert az alábbi információkkal rendelkezik:

  • Forrás IP-címe
  • Cél IP-cím
  • IP protokoll
  • Forrásport
  • Célport
  • IP szolgáltatás típusa

A használata mellett szól még annak kis „lábnyoma”, tárhelyigénye, melynek köszönhetően gyorsabban lehet automata eszközök segítségével elemezni, illetve nem eszi úgy a tárhelyet. (100 GB PCAP ~ 380 MB Netflow).

A mi feladatunk tehát, nem csak kivizsgálni a hipotéziseket, hanem generálni is azokat.

Flowmon

Kezdjünk egy klasszikussal, a historikus elemzéssel. A SIEM rendszerünket etetjük valamilyen CTI adatforrással, csodás! De mi van, ha egy támadó már a környezetünkben bukkan fel, csak később jelenik meg a threat intel adatbázisban?

Ha ezekre is fel akarunk készülni és van egy pazar szabályzatunk az adatok tárolására vonatkozóan, például hatvan napos megőrzési időt előírva, akkor összehasonlíthatjuk a forrás és a cél IP címeket egy frissített CTI adatbázissal. Ez sem jelenti, hogy kilőttük a három pálcást, mert a támadó IP-je is eltűnhet az adatbázisból, de legalább esély van a hipotézis létrehozására. (Esélyünk sincs nyerni a lottón ha nem veszünk jegyet😉.) A historikus elemzés sokkal hatékonyabb a futtatható fájloknál (hash összehasonlítás), de ez most nem a mi témánk, így folytassuk a netflow-val.

A flow adatok erejének bemutatásához a legjobb, ha áttekintjük, hogy egy támadási modell mely szakaszában, szakaszaiban azonosíthatjuk támadóinkat.

Felderítés: Az aktív felderítés nagyon könnyen megtalálható a Netflow-ban. Például, ha visszatérő, külső IP címeket tapasztalunk az internet felé nyitott, publikált szolgáltatásainkhoz és azok nem a munkavállalók, partnerek címei, illetve, ha az „abuseipdb” sincs elragadtatva tőle és még csak hírportált sem üzemeltetünk. Különösen igaz, ha egy kis portscan, host-sweep-scan stb. is párosul hozzá. Ez az azonosítási eljárás szervezeten belül és kívül is érvényes.

„Fegyverkezés” aka. [Weaponizing]: Ez az a szakasz, aminek az azonosítása nem lehetséges – civil eszközökkel-, csak ha rendelkezünk adatokkal az ellenséges aktor hálózatából.

Kézbesítés, szállítás aka. delivery: Ha egy támadás kívülről jön akkor azt a hálózati áramlásban láthatjuk. Például, hogy valaki folyamatosan, huzamosabb ideig próbálkozik egy webkiszolgálónkon vagy nagy csomagok érkeznek mindenkinek a hálózaton, adott e-mail protokollon.

Exploitálás: Általában ez egy kliens oldali elemzés segítségével észlelhető, amit nem láthatunk a hálózati forgalomban, de mit tehetünk, ha van egy sikeresen exploitált hosztunk és kigyomlálták a naplókat? Meglepő módon lehetőségünk van nyílik a Netflow használatára, hogy képet kapjunk például az oldalirányú mozgásról.

Telepítés: Ennek detektálásában érdekes lehet egy kívülről érkezett portscannelés nyoma, illetve a kommunikáció ismert, rosszindulatú IP címek irányába, emellett pedig tunnelezést is lehet jelezni, ha szokatlan, illetve enkriptált csomagok áramlanak különböző, általában nem ezekkel operáló protokollon (pl. DNS, SMTP). Emellett az elemzésben segíthet a CTI rendszer is (IP, DGA, hash stb.)

Parancs és vezérlés (C2): Egy távoli támadás esetén láthatunk beaconinget a hálózati áramlásban, akár vizuális megjelenítő rendszeren, vagy egy adatfolyam-elemzés révén. Ha a forgalmat a C2 hostról érkező külső kapcsolatról elemezzük, meg kell vizsgálnunk az RDP kapcsolatokat, amelyeknek nem kellene ott lenniük. Ha ez egy belső hosztra mutat, ami normális a szerverek számára, de nem a végpontoknál, akkor bizony gyanakodhatunk. A rejtett csatornákat (DNS, http, ICMP tunnel) is láthatjuk. Ezek a csatornák komoly adatszivárogtatásra is képesek, de a malware is használhatja beszélni a gazdival. A malware-es „ügyfélszolgálat” jobb, mint sok nagyvállalat supportja… Felismertünk peer-to-peer vagy pulling utasításokat, stealth HTTP Post-ot, gyanús domain aktivitást, a TOR tevékenységet stb.

Célkitűzések: Itt csak párat említenék, trivialitása miatt. Például az adatszivárogtatás könnyen észrevehető a netflow-ban, a forgalmi görbe csúcsainál, egyszerű. Az oldalirányú mozgás esetén ha a hosztok és a végpontok között horizontális hálózat forgalom látható, a hagyományos vertikálissal szemben akkor lehet, hogy a webszerver szkenneli a tartományvezérlőnket. Az is érdekes lehet, ha szervereknek Skype forgalma van. Kivel beszélnének?

SiLK

Ami az eszközöket illeti, a tárház gazdag: A YAF-et DPI és P0f OS ujjlenyomatokhoz, SiLK-hoz vagy iSiLK-hez lehet használni GUI-val, mely támogathatja a tanulási folyamatot, vagy Argus, ami egy kliens program natív Netflow-adatokhoz. Végül, de nem utolsó sorban a Zeek(Bro), ahol a weird.log érdekes lehet. Ha integrált, „konyhakész” megoldás jöhet csak szóba, akkor a SELKS, a Security Onion vagy más disztrókat sorolnék. Végül, de nem utolsó sorban a Flowmon a bolti Netflow termékek koronázatlan királya😊

Other Posts