La uzanta laborstacio estas la plej vundebla punkto de la infrastrukturo laŭ informa sekureco. Uzantoj povas ricevi leteron al sia laborretpoŝto, kiu ŝajnas esti de sekura fonto, sed kun ligilo al infektita retejo. Eble iu elŝutos ilon utilan por laboro de nekonata loko. Jes, vi povas elpensi dekojn da kazoj pri kiel malware povas enfiltri internajn kompaniajn rimedojn per uzantoj. Tial, laborstacioj postulas pli grandan atenton, kaj en ĉi tiu artikolo ni diros al vi kie kaj kiajn eventojn fari por kontroli atakojn.
Por detekti atakon en la plej frua ebla etapo, WINdows havas tri utilajn okazaĵfontojn: la Sekureca Okazaĵo-Protokolo, la Sistemo-Monitorado-Protokolo kaj la Power Shell-Protokolo.
Sekureca Event Log
Ĉi tio estas la ĉefa konserva loko por sistemaj sekurecaj protokoloj. Ĉi tio inkluzivas eventojn de uzantsaluto/elsaluto, aliro al objektoj, politikaj ŝanĝoj kaj aliaj sekurecaj agadoj. Kompreneble, se la taŭga politiko estas agordita.
Nombrado de uzantoj kaj grupoj (okazaĵoj 4798 kaj 4799). Je la komenco mem de atako, malware ofte serĉas tra lokaj uzantkontoj kaj lokaj grupoj sur laborstacio por trovi akreditaĵojn por siaj ombraj negocoj. Ĉi tiuj eventoj helpos detekti malican kodon antaŭ ol ĝi pluiras kaj, uzante la kolektitajn datumojn, disvastiĝas al aliaj sistemoj.
Kreado de loka konto kaj ŝanĝoj en lokaj grupoj (okazaĵoj 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 kaj 5377). La atako ankaŭ povas komenciĝi, ekzemple, aldonante novan uzanton al la grupo de lokaj administrantoj.
Ensalutprovoj kun loka konto (okazaĵo 4624). Estimindaj uzantoj ensalutu kun domajna konto, kaj identigi ensaluton sub loka konto povas signifi la komencon de atako. Okazaĵo 4624 ankaŭ inkluzivas ensalutojn sub domajna konto, do dum prilaborado de eventoj, vi devas filtri eventojn, kie la domajno diferencas de la nomo de la laborstacio.
Provo ensaluti kun la specifita konto (okazaĵo 4648). Ĉi tio okazas kiam la procezo funkcias en "kuru kiel" reĝimo. Ĉi tio ne devus okazi dum normala funkciado de sistemoj, do tiaj eventoj devas esti kontrolitaj.
Ŝlosi/malŝlosi la laborstacion (okazaĵoj 4800-4803). La kategorio da suspektindaj eventoj inkluzivas iujn ajn agojn, kiuj okazis sur ŝlosita laborstacio.
Ŝanĝoj de agordo de fajroŝirmilo (okazaĵoj 4944-4958). Evidente, kiam vi instalas novan programaron, la agordoj de fajroŝirmilo povas ŝanĝiĝi, kio kaŭzos falsajn pozitivojn. Plejofte, ne necesas kontroli tiajn ŝanĝojn, sed certe ne malutilos scii pri ili.
Konektante Plug'n'play-aparatojn (okazaĵo 6416 kaj nur por WINdows 10). Gravas observi ĉi tion se uzantoj kutime ne konektas novajn aparatojn al la laborstacio, sed tiam subite ili faras.
Vindozo inkluzivas 9 reviziajn kategoriojn kaj 50 subkategoriojn por fajnagordado. La minimuma aro de subkategorioj kiuj devus esti ebligitaj en la agordoj:
Ensaluti / Fermi
- Ensaluto;
- Elsaluti;
- Konto Lockout;
- Aliaj Ensaluti/Malsaluti Eventojn.
Administrado de Kontoj
- Administrado de Uzanto-Konto;
- Administrado de Sekureca Grupo.
Politika Ŝanĝo
- Revizia Politika Ŝanĝo;
- Aŭtentikiga Politiko Ŝanĝo;
- Rajtigo-Politiko Ŝanĝo.
Sistema Monitoro (Sysmon)
Sysmon estas ilo enkonstruita en Vindozo, kiu povas registri eventojn en la sistema protokolo. Kutime vi devas instali ĝin aparte.
Ĉi tiuj samaj eventoj principe troviĝas en la sekureca protokolo (ebligante la deziratan revizian politikon), sed Sysmon provizas pli da detaloj. Kiuj eventoj povas esti prenitaj de Sysmon?
Proceza kreado (okazaĵo ID 1). La sistema sekureca evento-protokolo ankaŭ povas diri al vi kiam *.exe komenciĝis kaj eĉ montri ĝian nomon kaj lanĉan vojon. Sed male al Sysmon, ĝi ne povos montri la aplikaĵon haŝiŝon. Malica programaro eĉ povas esti nomita sendanĝera notepad.exe, sed ĝi estas la haŝiŝo, kiu lumigos ĝin.
Retaj Konektoj (Event ID 3). Evidente, ekzistas multaj retaj konektoj, kaj estas neeble konservi trakon de ĉiuj. Sed gravas konsideri, ke Sysmon, male al Security Log, povas ligi retan konekton al la kampoj ProcessID kaj ProcessGUID, kaj montras la havenon kaj IP-adresojn de la fonto kaj celloko.
Ŝanĝoj en la sistema registro (okazaĵo ID 12-14). La plej facila maniero aldoni vin al aŭtorun estas registriĝi en la registro. Sekureca Protokolo povas fari tion, sed Sysmon montras, kiu faris la ŝanĝojn, kiam, de kie, procesas ID kaj la antaŭa ŝlosilvaloro.
Kreado de dosiero (identigo de evento 11). Sysmon, male al Security Log, montros ne nur la lokon de la dosiero, sed ankaŭ ĝian nomon. Estas klare, ke vi ne povas konservi trakon de ĉio, sed vi povas kontroli iujn dosierujojn.
Kaj nun kio ne estas en Security Log-politikoj, sed estas en Sysmon:
Ŝanĝo de la krea tempo de dosiero (identigo de evento 2). Iuj malbon-programoj povas falsigi la kredaton de dosiero por kaŝi ĝin de raportoj pri lastatempe kreitaj dosieroj.
Ŝargado de ŝoforoj kaj dinamikaj bibliotekoj (identigiloj de eventoj 6-7). Monitorante la ŝarĝon de DLL-oj kaj aparato-ŝoforoj en memoron, kontrolante la ciferecan subskribon kaj ĝian validecon.
Kreu fadenon en kuranta procezo (okazaĵo ID 8). Unu speco de atako, kiu ankaŭ devas esti monitorita.
RawAccessRead Eventoj (Eventa ID 9). Diskolegaj operacioj uzante ".". En la granda plimulto de kazoj, tia agado devus esti konsiderata nenormala.
Kreu nomitan dosierfluon (identigilo de evento 15). Okazaĵo estas registrita kiam nomita dosierfluo estas kreita kiu elsendas eventojn kun hash de la enhavo de la dosiero.
Kreante nomitan tubon kaj konekton (okazaĵo ID 17-18). Spurado de malica kodo, kiu komunikas kun aliaj komponantoj per la nomita tubo.
WMI-agado (identigilo de evento 19). Registrado de eventoj, kiuj estas generitaj dum aliro al la sistemo per la WMI-protokolo.
Por protekti Sysmon mem, vi devas monitori eventojn kun ID 4 (Sysmon ĉesanta kaj startanta) kaj ID 16 (Sysmon-agordaj ŝanĝoj).
Potencaj Ŝelaj Registroj
Power Shell estas potenca ilo por administri Vindozan infrastrukturon, do estas grandaj ŝancoj, ke atakanto elektos ĝin. Estas du fontoj, kiujn vi povas uzi por akiri Power Shell-okazajn datumojn: Windows PowerShell-protokolo kaj Microsoft-WindowsPowerShell/Operacia protokolo.
Vindoza PowerShell protokolo
Datumprovizanto ŝargita (okazaĵo ID 600). PowerShell-provizantoj estas programoj kiuj provizas fonton de datumoj por ke PowerShell rigardu kaj administru. Ekzemple, enkonstruitaj provizantoj povus esti Vindozaj mediovariabloj aŭ la sistema registro. La apero de novaj provizantoj devas esti monitorita por detekti malican agadon ĝustatempe. Ekzemple, se vi vidas WSMan aperanta inter la provizantoj, tiam fora PowerShell-sesio estis komencita.
Microsoft-WindowsPowerShell/Operacia protokolo (aŭ MicrosoftWindows-PowerShellCore/Operacia en PowerShell 6)
Modula ensalutu (okazaĵo ID 4103). Eventoj konservas informojn pri ĉiu ekzekutita komando kaj la parametroj per kiuj ĝi estis vokita.
Skripto blokanta protokolado (okazaĵo ID 4104). Skripta blokado de registrado montras ĉiun blokon de PowerShell-kodo efektivigita. Eĉ se atakanto provas kaŝi la komandon, ĉi tiu eventospeco montros la PowerShell-komandon, kiu efektive estis efektivigita. Ĉi tiu eventospeco ankaŭ povas registri iujn malaltnivelajn API-vokojn faritajn, ĉi tiuj eventoj estas kutime registritaj kiel Vorbozaj, sed se suspektinda komando aŭ skripto estas uzata en bloko de kodo, ĝi estos registrita kiel Averta severeco.
Bonvolu noti, ke post kiam la ilo estas agordita por kolekti kaj analizi ĉi tiujn eventojn, plia sencimiga tempo estos postulata por redukti la nombron da falsaj pozitivoj.
Diru al ni en la komentoj, kiajn protokolojn vi kolektas por informaj sekurecaj revizioj kaj kiajn ilojn vi uzas por tio. Unu el niaj fokusoj estas solvoj por revizii informajn sekurecajn eventojn. Por solvi la problemon pri kolektado kaj analizo de ŝtipoj, ni povas sugesti pli detale rigardi , kiu povas kunpremi konservitajn datumojn kun proporcio de 20:1, kaj unu instalita kazo de ĝi kapablas prilabori ĝis 60000 eventojn je sekundo de 10000 fontoj.
fonto: www.habr.com