A dokumentum eredetije a következő hivatkozáson található:
http://defec.ru/indicators-of-compromise/
Az infrastruktúra tulajdonosoknak ajánlott rendszeresen ellenőrizniük, találhatóak-e kártékony komponensek az erőforrásaik között. Az erőforrás fertőződésének egyik módja, amikor kiberbűnözők ún. „zero-day” sérülékenységet használnak ki. Ebben az esetben az információs rendszerek védelmét ellátó biztonsági szoftverek fejlesztői még nem értesülnek a fenyegetésről. Ugyanakkor biztonsági szakértők már vizsgálhatnak az új fenyegetéshez kapcsolódó incidenseket. Sőt, a vizsgálatok bizonyos megállapításai már publikusan elérhetőek lehetnek.
Ezen riportok értékesek. Egy APT kampányról szóló tipikus riport a következő információkat tartalmazza:
-
a támadás célpontjai/áldozatai és a kiberbűnözők céljai
-
áldozat csomópontok listája (IP címek)
-
a kártékony komponensek, illetve a kiberbűnözői csoportok aktuális tevékenysége
-
a kiberbűnözők által használt eszközök (tool-ok) és kártékony komponensek részletes leírása
-
a command-and-control (C&C) szerver infrastruktúra leírása
-
a fertőzöttség jelei – a továbbiakban „indikátorok” (indicators of compromise – IOC)
Egy adott APT-vel kapcsolatos számos technikai részlet közül az „indikátorok” képviselik a legnagyobb gyakorlati értéket a biztonsági adminisztrátorok (security administrators) számára. Ez egy olyan adathalmaz, amely segítheti a vállalati IT infrastruktúra rendszer-adminisztrátorát a rendszerbeli káros tevékenység felismerésében és a megfelelő válaszlépések megtételében.
Hogyan kell használják a rendszer adminisztrátorok ezen adatokat a gyakorlatban? Ezen dokumentum erre a kérdésre igyekszik választ adni.
A fertőzöttség egy jele a kártékony tevékenység jeleiről szóló információ, amely oly módon van struktúrálva, hogy az az infrastruktúra fertőzöttségi jeleinek vizsgálatára tervezett automatizált eszközök számára könnyen átadható. Bár nincs általánosan elfogadott formátum ezen indikátorok leírására, több struktúrált adattípus széles körben használt és támogatott a szakterületen belül.
Indikátorok
Az indikátor egy fenyegetéshez köthető adatok listája (pl. fájlok elérési útvonalait vagy registry bejegyzéseket tartalmazó sztringek) amelyek felhasználhatóak egy fenyegetés detektálására az infrastruktúrán belül automatizált, szoftver alapú elemzéssel.
Egy egyszerű indikátor használati mód adott fájlok keresését foglalja magába különböző keresési kritériumok használatával: MD5 hash értékek, fájlnevek, létrehozási dátumok, méret és további attribútumok alapján. Továbbá lehet keresni a rendszer memóriájában is fenyegetés specifikus jeleket, valamint a Windows registry adatbázisában ismertté vált bejegyzéseket.
Az indikátor adatok különböző formában lehetnek megadva. Ezek közül egy formátum az OpenIOC. A többféle formátum lehetővé teszi, hogy az adatokat különböző biztonsági szoftverekbe lehessen beimportálni az indikátorok további feldolgozása érdekében. Egy adminisztrátor a jelentésekből származó indikátorokat olyan biztonsági szoftverekbe integrálhatja, mint :
-
Végpont védelmi osztályba tartozó megoldások
-
SIEM
-
IDS/IPS
-
HIDS/HIPS
-
Különböző incidensvizsgáló eszközök
Több kereskedelmi forgalmú megoldás létezik az indikátorok használatához, de sok esetben a hasonló nyílt forrású programok képességei is elegendőnek bizonyulnak a célrendszer fertőzöttségi jeleinek vizsgálatához. Egy ilyen példa a Loki – egy GPL licenszelésű indikátor vizsgáló/scanner, amellyel káros tevékenység eredményeként megjelenő indikátorokat lehet keresni a célrendszeren.
A rendszernek a Loki-val történő átvizsgálásához csak ki kell csomagolni az eszközt tartalmazó archívumot és hozzá kell adni a releváns indikátor attribútumokat a kereső szoftver tudásbázisához. A következő indikátor kategóriák az alkalmazás „signature” nevű könyvtárában találhatóak:
-
“filename-iocs” – különböző fenyegetések által létrehozott fájlrendszer attribútumokat tartalmazó szövegfájl;
-
“hash-iocs” – a fertőzött rendszerekben megjelenő kártékony komponensek MD5, SHA1 és SHA256 hash értékeinek listája;
-
“falsepositive-hashes” – kivételek listája: a kereső szoftver által, a releváns komponensek detektálása közben fals pozitívként megjelölt MD5, SHA1 és SHA256 hash értékek listája;.
Pédaként vegyük a Carbanak APT vizsgálatáról készült jelentést. A jelentés 36. oldala felsorolja azon malware komponensek MD5 hash értékeit, amelyek a fertőzést követően megjelenhetnek a rendszeren. Megnyitjuk a kereső szoftver “hash-iocs” nevű fájlját és megadunk benne egy a fenyegetésre vonatkozó szabályt a következő formában: <MD5>;<description> .
A Carbanak APT komponenseinek MD5 hash értékei a Loki program “hash-iocs” fájljában
A következő lépés egy indikátor létrehozása a „filename-iocs” nevű szövegfájlban, amely a kártékony komponensek fájlrendszerbeli attribútumait írja le. Az indikátor az alábbi formájú kell legyen:
# COMMENT
# REGULAREXPRESSION;SCORE
Fájlrendszer indikátor a Loki “filename-iocs” listájában
Miután bevittük a kereső szoftver tudásbázisába a releváns indikátorokat, elindíthatunk egy keresést (scan) a munkaállomáson. Ehhez a „loki.exe” futtatható állományt kell betölteni adminisztrátori jogosultsággal – máskülönben a szoftver nem lesz képes a RAM tartalmát átvizsgálni –, majd megvárni a keresés lefutását.
A Loki-val történő vizsgálat folyamata
YARA szabályok
Néha a riportok mellett, a bennük szereplő indikátorokon kívül „.yar” kiterjesztésű csatolmányokat is találunk. Ezek a fájlok a YARA-hoz tartalmaznak szabályokat – ami a kártékony minták azonosításához és kategorizálásához használható szoftver. A YARA szabályok speciális szintaxist használnak a rendszerbeli kártékony tevékenységet jelző attribútumok leírására. Ha egy ilyen szabály teljesül, az elemző egy fertőzést jelző ítéletet/döntést (verdict) hoz, amely tartalmazza a releváns részleteket is (pl. a fenyegetés neve).
A Loki kereső szoftver is támogatja a YARA szabályokat, így az adminisztrátor a jelentésekhez mellékelt .yar fájlokat is fel tudja használni a rendszerek ellenőrzéséhez. Ehhez csupán a program „signature” könyvtárába kell másolnia a .yar fájlokat és elindítani a fertőzöttségi vizsgálatot (scan).
Azonban a YARA project fejlesztői által készített hivatalos eszköz sokkal jobban használható a YARA szabályokkal való munkához, mivel a tudásbázisa rendszeresen frissül és sokkal átfogóbb, mint más hasonló eszközök adatbázisai. Ennek eredményeként a keresés (scan) sokkal átfogóbb információt ad a rendszer biztonságáról, több információt adva a rendszerben esetlegesen fellelhető kártékony komponensekről.
A munkaállomás átvizsgálásához csak be kell tölteni a YARA programot a szükséges paraméterekkel. Például:
yara32.exe –d md5= <MD5_hash><this_is_yara_rule.yar><dir_for_check>
ahol a „-d” paraméterrel adhatunk meg külső változó értékeket. Ha bármely szabályra illeszkedő egyezést talál, a program megjelenít egy értesítést, amely tartalmazza a szabály nevét és a komponenst, amely arra illeszkedik.
YARA szabály egyezéskori értesítés
A rendszer adminisztrátor indíthat kereséseket a rendszer indulásakor. Ez megoldható egy egyszerű PowerShell script írásával, ami elindítja a kereső programot a megfelelő paraméterekkel, és ha szükséges, az Active Directory segítségével megadható, hogy minden munkaállomáson fusson le bejelentkezéskor:
User configuration -> Windows configuration -> Scenarios -> Logon.
STIX és JSON
A Structured Threat Information Expression (STIX) egy egységesített nyelv a fenyegetésekhez köthető információk rögzítésére és a szoftver megoldásokba történő importálásra. Számos biztonsági megoldás képes STIX formátumban megadott információkat betölteni (A JSON-nal egyetemben, amely alább szerepel) az alábbi infrastruktúrákban történő használathoz:
-
SIEM
-
Indikátor alapú biztonsági szoftver megoldások (scanner-ek)
-
Igazságügyi vizsgálati (Forensic) platformok
-
Végpont védelmi osztályba tartozó szoftverek
STIX formátumú jelentés beimportálható az IBM QRadar-ba, ami egy népszerű SIEM megoldás, egy speciális python script-el:
./stix_import.py -f STIXDocument.xml -i 192.168.56.2 -t XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -r MyReferenceSet
ahol a „-f” paraméter definiálja a STIX dokumentum helyét, a „-i” paraméter definiálja a QRadar console-lal ellátott hoszt gépet és a „-t” paraméter adja meg a QRadar service token-jét.
A Splunk App for Enterprise Security elemző platform szintén támogatja a STIX riportokat. A STIX fájlnak .xml kiterjesztése kell legyen, hogy fel tudja azt dolgozni.
Említést érdemel, hogy létezik egy „openioc-to-stix” nevű Python eszköz, amivel az OpenIOC formátum STIX formátumba konvertálható, ami lehetővé teszi OpenIOC formában megadott indikátorok használatát olyan rendszerekben, amelyek az OpenIOC-t közvetlenül nem támogatják.
A JSON az egyik leg népszerűbb adatreprezentációs formátum, amelyet szintén gyakran használnak a fenyegetésekhez köthető ismertté vált adatok rögzítésére. A JSON adatok használata az adminisztrátor igényeinek és az azt használó szoftver megoldás függvénye. Például ha a JSON fájl vezérlő szerverek IP címeit tartalmazza, amelyekhez a fertőzött kliensek csatlakoznak, az infrastruktúra adminisztrátora beimportálhatja ezeket az IP címeket egy JSON formátumot támogató tűzfalmegoldás feketelistájára. Ha a tűzfalmegoldás nem támogatja a JSON formátumból való betöltést, az adminisztrátor egy parser (egy JSON fájl elemző) segítségével exportálhatja ki az IP cím listát a fájlból, és azt követően tudja beimportálni a tűzfal feketelistájára.
Konklúzió
A fertőzöttség jeleit rögzítő indikátorok segítik a fenyegetésekről ismertté vált adatok hatékony felhasználását: a malware azonosítását és az incidensre történő gyors reagálást. Ezek az indikátorok általában kiolvashatóak a jelentésekből, de az olvasók gyakran átsiklanak felettük. Még ha a kutatási projekt részleteit taglaló dokumentum nem is tartalmaz egy dedikált „Indicators of Compromise” szekciót, az olvasó mindig talál hasznos adatokat – a fertőzött rendszerekben talált attribútumokat – a szövegben, kiollózhatja az adatokat a fent említett formátumokba és beimportálhatja egy biztonsági megoldásba.
Ajánlott olvasmányok a témával kapcsolatban
https://blogs.rsa.com/understanding-indicators-of-compromise-ioc-part-i/
https://www.mandiant.com/blog/openioc-series-investigating-indicators-compromise-iocs-part/
http://blog.crowdstrike.com/indicators-attack-vs-indicators-compromise/
http://www.21ct.com/default/assets/File/12-indicators-of-compromise.pdf
