Гэты артыкул з'яўляецца першай часткай серыі па аналізе Sysmon-пагроз. Усе астатнія часткі серыі:
Частка 1. Знаёмства з аналізам логаў Sysmon (мы тут)
Частка 2. Выкарыстанне дадзеных з Sysmon падзей для выяўлення пагроз
Частка 3. Паглыблены аналіз Sysmon-пагроз з дапамогай графаў
Калі вы займаецеся інфармацыйнай бяспекай, напэўна вам часта даводзіцца разбірацца ў адбывалых нападах. Калі ў вас ужо накіданае вока, вы можаце пашукаць нестандартную актыўнасць у "волкіх" неапрацаваных логах - скажам, PowerShell-скрыпт з запушчанай або VBS-скрыпт, які прыкідваецца Word-файлам, - проста прагортваючы апошнюю актыўнасць у часопісе падзей Windows. Але гэта рэальна вялікі галаўны боль. На шчасце, Microsoft стварыў Sysmon, які робіць аналіз нападаў куды прасцейшым.
Жадаеце разабрацца ў базавых ідэях, якія стаяць за якія адлюстроўваюцца ў логу Sysmon пагрозамі? Запампуйце наша кіраўніцтва і вы ўсведамляеце, як інсайдэры могуць неўзаметку назіраць за іншымі супрацоўнікамі. Асноўнай праблемай працы з часопісам падзей Windows з'яўляецца адсутнасць інфармацыі аб бацькоўскіх працэсах, г.зн. з яго нельга зразумець іерархію працэсаў. У запісах лога Sysmon жа наадварот, утрымоўваюцца ідэнтыфікатар працэсу бацькі, яго імя і які запускаецца камандны радок. Дзякуй табе, Microsoft.
У першай частцы нашай серыі мы паглядзім, што можна зрабіць з базавай інфармацыяй з Sysmon. У другой частцы мы ў поўнай меры скарыстаемся інфармацыяй аб бацькоўскіх працэсах для стварэння больш комплексных структур адпаведнасці, якія вядомы як графы пагроз. У трэцяй частцы мы разгледзім просты алгарытм, які скануе граф пагроз для пошуку нестандартнай актыўнасці праз аналіз "вагі" графа. А ў канцы ў якасці ўзнагароды вас чакае акуратны (і зразумелы) імавернасны метад выяўлення пагроз.
Частка 1: Знаёмства з аналізам логаў Sysmon
Што дапаможа разабрацца ў складанасцях часопіса падзей? У канчатковым выніку - SIEM. Яна праводзіць нармалізацыю падзей і спрашчае іх наступны аналіз. Але нам не абавязкова заходзіць так далёка, прынамсі першыя часы. У пачатку для разумення прынцыпаў SIEM дастаткова будзе паспрабаваць выдатную бясплатную ўтыліту Sysmon. І з ёй на здзіўленне лёгка працаваць. Так трымаць, Microsoft!
Якія ёсць магчымасці ў Sysmon?
Калі коратка - карысная і чытэльная інфармацыя аб працэсах (гл. карцінкі ніжэй). Вы выявіце кучу карысных дэталяў, якіх няма ў часопісе падзей Windows, але самае галоўнае - наступныя палі:
- ID працэсу (у дзесятковай форме, а не hex!)
- ID бацькоўскага працэсу
- Камандны радок працэсу
- Камандны радок бацькоўскага працэсу
- Хэш выявы файла
- Імёны выяў файла
Sysmon усталёўваецца адначасова і як драйвер прылады, і як служба - падрабязней Яе ключавой перавагай з'яўляецца магчымасць аналізу логаў з некалькіх крыніц, карэляцыя інфармацыі і вывад выніковых значэнняў у адну тэчку часопіса падзей, якая знаходзіцца па шляху Microsoft -> Windows -> Sysmon -> Operational. У маіх уласных расследаваннях логаў Windows, ад якіх валасы ўстаюць дыбам, мне ўвесь час даводзілася перамыкацца паміж, скажам, тэчкай з логамі PowerShell, і тэчкай «Бяспека», прагортваючы часопісы падзей у гераічны спробе неяк супаставіць значэнні паміж імі. Гэта ні разу не лёгкая задача, і як я потым зразумеў, лепш было адразу назапасіцца аспірынам.
Sysmon жа робіць якасны скачок наперад, падаючы карысную (ці як любяць казаць вендары - дзейсную) інфармацыю для дапамогі ў разуменні асноўных працэсаў. Напрыклад, я запусціў скрытную сесію , Сімулюе перамяшчэнне разумнага інсайдэра ўнутры сеткі. Вось што пры гэтым вы ўбачыце ў часопісе падзей Windows:
У часопісе Windows бачная нейкая інфармацыя аб працэсе, але яна малакарысная. Плюс ідэнтыфікатары працэсаў у шаснаццатковай форме???
У прафесійнага ІТ-спецыяліста з разуменнем асноў хакінга павінен выклікаць падазрэнне камандны радок. Выкарыстанне cmd.exe для наступнага запуску іншай каманды з перанакіраваннем высновы ў файл з дзіўнай назвай - гэта відавочна падобна на дзеянні софту па кантролі і кіраванню : такім спосабам ствараецца псеўда-шэл з дапамогай службаў WMI.
Цяпер давайце зірнем на эквівалент запісу з Sysmon, звярнуўшы ўвагу на тое, колькі дадатковай інфармацыі яна нам дае:
Магчымасці Sysmon на адным скрыншоце: дэталёвая інфармацыя аб працэсе ў чытэльнай форме
Вы не толькі бачыце камандны радок, але і імя файла, шлях да выкананага прыкладання, што Windows ведае пра гэта (“Windows Command Processor”), ідэнтыфікатар бацькоўскага працэсу, камандны радок з бацькоў, які запусціў cmd-шелл, а таксама рэальнае імя файла бацькоўскага працэсу. Усё ў адным месцы, нарэшце!
З лога Sysmon мы можам зрабіць выснову, што з высокай дзеллю верагоднасці гэты падазроны камандны радок, якую мы бачылі ў «волкіх» логах, не з'яўляецца вынікам звычайнай працы супрацоўніка. Хутчэй наадварот, яна была згенераваная C2-падобным працэсам – wmiexec, як я згадваў раней – і была наўпрост спароджаная працэсам WMI службы (WmiPrvSe). Цяпер у нас ёсць індыкатар таго, што выдалены зламыснік ці інсайдэр спрабуе карпаратыўную інфраструктуру на зуб.
Прадстаўляем Get-Sysmonlogs
Вядома выдатна, калі Sysmon размяшчае логі ў адным месцы. Але, напэўна, было б яшчэ лепш, калі б мы маглі атрымаць доступ да індывідуальных палёў лога праграмным спосабам - напрыклад, праз каманды PowerShell. У гэтым выпадку можна было б напісаць невялікі PowerShell-скрыпт, які б аўтаматызаваў пошук патэнцыйных пагроз!
Не ў мяне першага ўзнікла такая ідэя. І добра, што ў некаторых пастах форумаў і GitHub ужо растлумачана, як выкарыстоўваць PowerShell для парсінгу Sysmon-лога. У маім выпадку мне хацелася пазбегнуць неабходнасці напісання асобных радкоў парсінг-скрыпта для кожнага поля Sysmon. Таму я выкарыстоўваў прынцып лянівага чалавека і, як мне здаецца, у выніку прыдумаў нешта цікавае.
Першым важным момантам з'яўляецца магчымасць каманды чытаць Sysmon логі, фільтраваць патрэбныя падзеі і выводзіць вынік у PS зменную, як тут:
$events = Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" | where { $_.id -eq 1 -or $_.id -eq 11}
Калі вы захочаце самастойна праверыць працу каманды, то праз адлюстраванне кантэнту ў першым элеменце масіва $events, $events[0].Message, на вынахадзе можна атрымаць серыю тэкставых радкоў з вельмі простым фарматам: імя поля Sysmon, двокроп'е і затым само значэнне.
Ура! Выснова Sysmon лога ў гатовы пад JSON-фармат
Вы думаеце аб тым жа, аб чым і я? Прыклаўшы яшчэ трохі намаганняў, можна сканвертаваць выснову ў адфарматаваны пад JSON-радок і затым загрузіць яе напрамую ў PS-аб'ект з дапамогай магутнай каманды .
Я пакажу PowerShell-код для канвертавання - ён вельмі просты - у наступнай частцы. А пакуль што давайце зірнем, што можа рабіць мая новая каманда пад назовам get-sysmonlogs, якую я ўсталяваў як PS-модуль.
Замест паглыблення ў аналіз логаў Sysmon праз нязручны інтэрфейс часопіса падзей, мы можам без намаганняў шукаць інкрыментальную актыўнасць непасрэдна з PowerShell-сесіі, а таксама выкарыстоўваць PS-каманду (аліас - «?») для скарачэння вынікаў выдачы:
Спіс cmd-шэлаў, запушчаных праз WMI. Аналіз пагроз танна з дапамогай нашай уласнай каманды Get-Sysmonlogs
Дзіўна! Я стварыў інструмент апытання Sysmon-лога, як калі б ён быў базай даных. У нашым артыкуле пра адзначалася, што гэтую функцыю і выканаюць апісваная ў ім крутая ўтыліта, хоць фармальна ўсё ж праз рэальны SQL-падобны інтэрфейс. Так, EQL вытанчаны, Але мы закранем яго ў трэцяй частцы.
Sysmon і аналіз графаў
Давайце абстрагуемся і падумаем, што мы толькі што стварылі. У сутнасці, у нас зараз ёсць база дадзеных падзей Windows, даступная праз PowerShell. Як я адзначыў раней, паміж запісамі існуюць злучэнні ці сувязі - праз ParentProcessId - таму можна атрымаць поўную іерархію працэсаў.
Калі вы чыталі серыю то ведаеце, што хакеры кахаюць ствараць складаныя шматэтапныя напады, у якіх кожны працэс выконвае сваю маленькую ролю і рыхтуе плацдарм для наступнага кроку. Такія рэчы вельмі складана адлавіць проста з "волкага" лога.
Але з маёй камандай Get-Sysmonlogs і дадатковай структурай дадзеных, якую мы разгледзім далей па тэксце (вядома ж, гэта граф), у нас з'явіцца практычны спосаб выявіць пагрозы - для чаго патрабуецца толькі выканаць правільны пошук па вяршынях.
Як заўсёды ў нашых DYI блог-праектах, чым больш вы працуеце над аналізам дэталяў пагроз у невялікім маштабе, тым лепш вы ўсведамляеце, наколькі складаным з'яўляецца дэтэктаванне пагроз на ўзроўні арганізацыі. І гэтае ўсведамленне з'яўляецца вельмі важным момантам.
Мы сустрэнем першыя цікавыя складанасці ў другой частцы артыкула, дзе пачнем звязваць адзін з адным Sysmon-падзеі ў куды больш складаныя структуры.
Крыніца: habr.com