A felhasználói munkaállomás a legsebezhetőbb pont az információs biztonság terén az infrastruktúrában. A felhasználók a munkahelyi postafiókjukban kaphatnak olyan levelet, amely látszólag biztonságos forrásból érkezik, de egy fertőzött weboldalra mutató linket tartalmaz. Előfordulhat, hogy valaki egy, a munkához hasznos eszközt tölt le ismeretlen helyről. Számos forgatókönyvet lehet kitalálni arra, hogyan juthat be a kártékony szoftver a vállalati erőforrásokba a felhasználókon keresztül. Ezért a munkaállomások fokozott figyelmet igényelnek, és a cikkben arról beszélünk, honnan és milyen eseményeket érdemes figyelemmel kísérni a támadások nyomon követéséhez.
A támadás legkorábbi szakaszának észlelésére a Windows operációs rendszerben három hasznos eseményforrás áll rendelkezésre: a biztonsági eseménynapló, a rendszerfigyelő napló és a Power Shell naplók.
Biztonsági eseménynapló (Security Log)
Ez a legfontosabb hely a rendszer biztonsági naplóinak tárolására. Itt gyűlnek össze a felhasználói be- és kijelentkezési események, az objektumokhoz való hozzáférések, a politikák módosítása és más, a biztonsággal kapcsolatos tevékenységek. Természetesen, ha a megfelelő politika be van állítva.
Felhasználók és csoportok felfedezése (4798-as és 4799-es események). A kártékony szoftver a támadás elején gyakran átnézi a helyi felhasználói fiókokat és helyi csoportokat a munkaállomáson, hogy megtalálja a hitelesítő adatokat sötét ügyeinek lebonyolításához. Ezek az események segíthetnek a kártékony kód korai felfedezésében, még mielőtt az továbbhaladhatna és az összegyűjtött adatok segítségével elterjedne más rendszerekre.
Helyi felhasználói fiók létrehozása és módosítások a helyi csoportokban (4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 és 5377 események). A támadás például új felhasználó hozzáadásával is kezdődhet a helyi rendszergazdák csoportjához.
Kísérletek bejelentkezésre helyi felhasználói fiókkal (4624-es esemény). A jóhiszemű felhasználók domain fiókkal jelentkeznek be, így a helyi felhasználói fiókkal való bejelentkezés észlelése a támadás kezdetét jelentheti. A 4624-es esemény tartalmazza a domain fiókkal való bejelentkezéseket is, ezért az események feldolgozása során szűrni kell azokat az eseményeket, ahol a domain eltér a munkaállomás nevétől.
Kísérlet bejelentkezésre meghatározott fiókkal (4648-as esemény). Ez akkor fordul elő, amikor a folyamat "Futtatás mint" (run as) módban fut. Normál működési körülmények között ilyen nem történhet, ezért az ilyen eseményeket figyelemmel kell kísérni.
Munkaállomás zárolása / feloldása (4800-4803 események). Gyanús események közé tartozik minden olyan cselekvés, amely a zárolt munkaállomáson történt.
A tűzfal konfigurációs változásai (4944-4958 események). Nyilvánvaló, hogy új szoftver telepítésekor a tűzfal konfigurációs beállításai megváltozhatnak, ami hamis riasztásokat okozhat. Az ilyen változások ellenőrzésére a legtöbb esetben nincs szükség, de ha tudunk róluk, az hasznos lehet.
Plug’n’play eszközök csatlakoztatása (6416 esemény és csak Windows 10 esetén). Fontos odafigyelni erre, különösen ha a felhasználók általában nem csatlakoztatnak új eszközöket a munkaállomásukhoz, majd hirtelen csak úgy csatlakoztatnak egyet.
A Windows 9 audit kategóriát és 50 al-kategóriát tartalmaz a finomhangoláshoz. A legkisebb al-kategória készlet, amit érdemes aktiválni a beállításokban:
Bejelentkezés / Kijelentkezés
- Bejelentkezés;
- Kijelentkezés;
- Felhasználói fiók zárolás;
- Egyéb bejelentkezési / kijelentkezési események.
Fiókmenedzsment
- Felhasználói fiók kezelése;
- Biztonsági csoport kezelése.
Politika változása
- Audit politikai változása;
- Hitelesítési politika változása;
- Hozzáférési politika változása.
Rendszerfigyelő (Sysmon)
A Sysmon, a Windows-ba beépített eszköz, képes eseményeket rögzíteni a rendszer naplóba. Általában külön kell telepíteni.
Ezeket az eseményeket egyébként megtalálhatjuk a biztonsági naplóban (a szükséges audit politika aktiválásával), de a Sysmon részletesebb információkat ad. Milyen eseményeket gyűjthetünk a Sysmon-ból?
Folyamat létrehozása (1 esemény ID). A biztonsági eseménynapló is meg tudja mondani, mikor indult el egy *.exe fájl, és még az nevét és indítási útvonalát is megjeleníti. De a Sysmonhoz képest nem tudja megjeleníteni az alkalmazás hash-jét. A rosszindulatú szoftver akár ártalmatlan notepad.exe néven is ismerheti, de a hash képes leleplezni azt.
Hálózati kapcsolatok (3 esemény ID). Nyilvánvaló, hogy sok hálózati kapcsolatra van szükség, és nem lehet mindet figyelemmel kísérni. Fontos figyelembe venni, hogy a Sysmon, ellentétben a biztonsági naplóval, képes a hálózati kapcsolatokat a ProcessID és a ProcessGUID mezőkhöz kapcsolni, továbbá megjeleníti a portot és IP address a forrást és a célt.
Módosítások a rendszerleíró adatbázisban (12-14 esemény ID). A legjobb módszer, hogy automatikusan indítsd el magad, ha regisztrálsz a rendszerleíró adatbázisban. A Security Log ezt tudja, de a Sysmon megmutatja, ki, mikor, honnan, a process ID-t és a kulcs korábbi értékét módosította.
Fájl létrehozása (11-es esemény ID). A Sysmon, ellentétben a Security Log-gal, nemcsak a fájl helyét, hanem a nevét is megmutatja. Nyilvánvaló, hogy mindent nem lehet nyomon követni, de bizonyos könyvtárak auditálása lehetséges.
Most pedig jöjjön az, ami a Security Log politikáiban nincs, de a Sysmonban megtalálható:
A fájl létrehozási időpontjának megváltoztatása (2-es esemény ID). Néhány kártevő megváltoztathatja a fájl létrehozási dátumát, hogy elrejtse azt a nemrég létrehozott fájlok jelentéséből.
Illesztőprogramok és dinamikus könyvtárak betöltése (6-7-es esemény ID). DLL-ek és eszközillesztők memóriába töltésének nyomon követése, digitális aláírás ellenőrzése és érvényessége.
Szál létrehozása egy futó folyamatban (8-as esemény ID). Ez az egyik támadási forma, amelyre szintén figyelni kell.
RawAccessRead események (9-es esemény ID). Olyan lemezes olvasási műveletek, amelyek a „.” segítségével történnek. A legtöbb esetben ez a tevékenység abnormalitásként kell, hogy számítson.
Nevzett fájlfolyam létrehozása (15-ös esemény ID). Az esemény akkor regisztrálódik, amikor egy névvel ellátott fájlfolyam jön létre, amely a fájl tartalmának hash értékével eseményeket generál.
Névcső létrehozása és csatlakozások (17-18-as esemény ID). Kártevő kód nyomon követése, amely névcsövön keresztül kommunikál más összetevőkkel.
WMI tevékenység (19-es esemény ID). Azok az események, amelyek akkor jönnek létre, amikor a rendszerhez WMI protokollon keresztül fordulnak.
A Sysmon védelme érdekében figyelni kell a 4-es ID-jú eseményeket (Sysmon leállítás és indítás) és a 16-os ID-jú eseményeket (Sysmon konfiguráció módosítása).
Power Shell naplók
A Power Shell egy erőteljes eszköz a Windows infrastruktúra kezelésére, ezért nagy a valószínűsége, hogy a támadó éppen ezt választja. A Power Shell eseményeinek adatainak megszerzéséhez két forrást használhatunk: Windows PowerShell log és Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log
Adatszolgáltató betöltve (600-as esemény ID). A PowerShell provider is a program that serves as a data source for PowerShell to view and manage. For example, built-in providers might include Windows environment variables or the system registry. It's important to monitor for new providers to promptly identify malicious activity. For instance, if you see that WSMan has appeared among the providers, it means a remote PowerShell session has started.
Microsoft-WindowsPowerShell / Operational log (or MicrosoftWindows-PowerShellCore / Operational in PowerShell 6)
Module logging (Event ID 4103). Events store information about each executed command and the parameters with which it was invoked.
Script block logging (Event ID 4104). Script block logging shows every executed block of PowerShell code. Even if an attacker tries to hide a command, this type of event will reveal the actual executed PowerShell command. Additionally, this type of event may record some low-level API calls; these events are usually logged as Verbose, but if a suspicious command or script is used in the code block, it will be logged with a severity of Warning.
Note that after setting up the tool for collecting and analyzing these events, additional time will be needed for debugging to reduce false positives.
Please share in the comments what logs you collect for information security auditing and what tools you use for this. One of our focuses is solutions for auditing information security events. To address the task of collecting and analyzing logs, we can suggest looking into , which can compress stored data at a ratio of 20:1, and a single installed instance can process up to 60,000 events per second from 10,000 sources.
Forrás: habr.com
