Карыстацкая працоўная станцыя - самае ўразлівае месца інфраструктуры па частцы інфармацыйнай бяспекі. Карыстачам можа прыйсці на працоўную пошту ліст быццам бы з бяспечнай крыніцы, але са спасылкай на заражаны сайт. Магчыма, нехта запампуе карысную для працы ўтыліту з невядома якога месца. Ды можна прыдумаць не адзін дзясятак кейсаў, як праз карыстачоў шкоднаснае ПА можа ўкараніцца на ўнутрыкарпаратыўныя рэсурсы. Таму працоўныя станцыі патрабуюць падвышанай увагі, і ў артыкуле мы распавядзем, адкуль і якія падзеі браць для адсочвання нападаў.
Для выяўлення нападу на самай ранняй стадыі ў АС WIndows ёсць тры карысных падзейных крыніцы: часопіс падзей бяспекі, часопіс сістэмнага маніторынгу і часопісы Power Shell.
Часопіс падзей бяспекі (Security Log)
Гэта галоўнае месца захоўвання сістэмных логаў бяспекі. Сюды складаюцца падзеі ўваходу/выхаду карыстальнікаў, доступу да аб'ектаў, змены палітык і іншых актыўнасцяў, злучаных з бяспекай. Зразумела, калі настроена адпаведная палітыка.
Перабор карыстальнікаў і груп (падзеі 4798 і 4799). Шкоднаснае ПА у самым пачатку нападу часта перабірае лакальныя ўліковыя запісы карыстачоў і лакальныя групы на працоўнай станцыі, каб знайсці ўліковыя дадзеныя для сваіх цёмных справак. Гэтыя падзеі дапамогуць выявіць шкоднасны код раней, чым ён рушыць далей і, выкарыстоўваючы сабраныя дадзеныя, распаўсюдзіцца на іншыя сістэмы.
Стварэнне лакальнага ўліковага запісу і змены ў лакальных групах (падзеі 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 і 5377). Атака можа таксама пачынацца, напрыклад, з дадання новага карыстальніка ў групу лакальных адміністратараў.
Спробы ўваходу з лакальным уліковым запісам (падзея 4624). Добрапрыстойныя карыстальнікі заходзяць з даменным уліковым запісам і выяўленне ўваходу пад лакальным уліковым запісам можа азначаць пачатак атакі. Падзея 4624 уключае таксама ўваходы пад даменным уліковым запісам, таму пры апрацоўцы падзей трэба зафільтраваць падзеі, у якіх дамен адрозніваецца ад імя працоўнай станцыі.
Спроба ўваходу з зададзеным уліковым запісам (падзея 4648). Такое бывае, калі працэс выконваецца ў рэжыме "Запуск ад імя" (run as). У нармальным рэжыме працы сістэм такога не павінна быць, таму такія падзеі мусяць знаходзіцца пад кантролем.
Блакаванне/разблакіроўка працоўнай станцыі (падзеі 4800-4803). Да катэгорыі падазроных падзей можна аднесці любыя дзеянні, якія адбываліся на заблакіраванай працоўнай станцыі.
Змяненні канфігурацыі файрвола (падзеі 4944-4958). Відавочна, што пры ўсталёўцы новага ПА налады канфігурацыі файрвола могуць мяняцца, што выкліча ілжывыя спрацоўванні. Кантраляваць такія змены ў большасці выпадкаў няма неабходнасці, але ведаць аб іх сапраўды лішнім не будзе.
Падлучэнне прылад Plug'n'play (падзея 6416 і толькі для WIndows 10). За гэтым важна сачыць, калі карыстачы звычайна не падлучаюць новыя прылады да працоўнай станцыі, а тут раптам раз - і падлучылі.
Windows уключае ў сябе 9 катэгорый аўдыту і 50 субкатэгорый для тонкай налады. Мінімальны набор субкатэгорый, які варта ўключыць у наладах:
Уваход/Выхад
- Logon;
- Logoff;
- Account Lockout;
- Other Logon/Logoff Events.
Кіраванне рахункамі
- User Account Management;
- Security Group Management.
Змена палітыкі
- Audit Policy Change;
- Authentication Policy Change;
- Authorization Policy Change.
Сістэмны манітор (Sysmon)
Sysmon – убудаваная ў Windows утыліта, якая ўмее запісваць падзеі ў сістэмны часопіс. Звычайна патрабуецца яго ўстанаўліваць асобна.
Гэтыя ж падзеі можна ў прынцыпе знайсці ў часопісе бяспекі (уключыўшы патрэбную палітыку аўдыту), але Sysmon дае больш падрабязнасцяў. Якія падзеі можна забіраць з Sysmon?
Стварэнне працэсу (ID падзеі 1). Сістэмны часопіс падзей бяспекі таксама можа сказаць, калі запусціўся які-небудзь *.exe і нават пакажа яго імя і шлях запуску. Але ў адрозненне ад Sysmon не зможа паказаць хэш дадатку. Зламыснае ПА можа звацца нават бяскрыўдным notepad.exe, але менавіта хэш выведзе яго на чыстую ваду.
Сеткавыя падлучэнні (ID падзеі 3). Відавочна, што сеткавых падлучэнняў шмат, і за ўсімі не ўсачыць. Але важна ўлічваць, што Sysmon у адрозненне ад таго ж Security Log умее прывязаць сеткавае падлучэнне да палёў ProcessID і ProcessGUID, паказвае порт і IP-адрасы крыніцы і прымача.
Змены ў сістэмным рэестры (ID падзеі 12-14). Самы просты спосаб дадаць сябе ў аўтазапуск - прапісацца ў рэестры. Security Log гэта ўмее, але Sysmon паказвае, хто занёс змены, калі, адкуль, process ID і папярэдняе значэнне ключа.
Стварэнне файла (ID падзеі 11). Sysmon, у адрозненне ад Security Log, пакажа не толькі размяшчэнне файла, але і яго імя. Зразумела, што за ўсім не ўсочыш, але можна ж праводзіць аўдыт пэўных дырэкторый.
А зараз тое, чаго ў палітыках Security Log няма, але ёсць у Sysmon:
Змяненне часу стварэння файла (ID падзеі 2). Некаторае шкоднаснае ПЗ можа падмяняць дату стварэння файла для яго ўтойвання з справаздач з нядаўна створанымі файламі.
Загрузка драйвераў і дынамічных бібліятэк (ID падзей 6-7). Адсочванне загрузкі ў памяць DLL і драйвераў прылад, праверка лічбавага подпісу і яе валіднасці.
Стварэнне патоку ў выкананым працэсе (ID падзеі 8). Адзін з відаў атакі, за якім таксама трэба сачыць.
Падзеі RawAccessRead (ID падзеі 9). Аперацыі чытання з дыска пры дапамозе ".". У абсалютнай большасці выпадкаў такая актыўнасць павінна лічыцца ненармальнай.
Стварэнне найменнага файлавага струменя (ID падзеі 15). Падзея рэгіструецца, калі ствараецца найменны файлавы струмень, які генеруе падзеі з хэшам змесціва файла.
Стварэнне named pipe і падключэння (ID падзеі 17-18). Адсочванне шкоднаснага кода, які камунікуе з іншымі кампанентамі праз named pipe.
Актыўнасць па WMI (ID падзеі 19). Рэгістрацыя падзей, якія генеруюцца пры звароце да сістэмы па пратаколе WMI.
Для абароны самога Sysmon трэба адсочваць падзеі з ID 4 (прыпынак і запуск Sysmon) і ID 16 (змена канфігурацыі Sysmon).
Часопісы Power Shell
Power Shell – магутны інструмент кіравання Windows-інфраструктурай, таму вялікія шанцы, што атакавалы абярэ менавіта яго. Для атрымання дадзеных аб падзеях Power Shell можна выкарыстоўваць дзве крыніцы: Windows PowerShell log і Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log
Загружаны пастаўшчык дадзеных (ID падзеі 600). Пастаўшчыкі PowerShell - гэта праграмы, якія служаць крыніцай дадзеных для PowerShell для прагляду і кіравання імі. Напрыклад, убудаванымі пастаўшчыкамі могуць быць зменныя асяроддзі Windows або сістэмны рэестр. За з'яўленнем новых пастаўшчыкоў трэба сачыць, каб своечасова выявіць зламысную актыўнасць. Напрыклад, калі бачыце, што сярод пастаўшчыкоў з'явіўся WSMan, значыць быў пачаты выдалены сеанс PowerShell.
Microsoft-WindowsPowerShell / Operational log (або MicrosoftWindows-PowerShellCore / Operational у PowerShell 6)
Журналіраванне модуляў (ID падзеі 4103). У падзеях захоўваецца інфармацыя аб кожнай выкананай камандзе і параметрах, з якімі яна выклікалася.
Журналіраванне блакіроўкі скрыптоў (ID падзеі 4104). Журналіраванне блакавання скрыптоў паказвае кожны выкананы блок кода PowerShell. Нават калі зламыснік паспрабуе схаваць каманду, гэты тып падзеі пакажа фактычна выкананую каманду PowerShell. Яшчэ ў гэтым тыпе падзеі могуць фіксавацца некаторыя выкананыя нізкаўзроўневыя выклікі API, гэтыя падзеі звычайна запісваецца як Verbose, але калі падазроная каманда ці сцэнар выкарыстоўваюцца ў блоку кода, ён будзе зарэгістраваны як c крытычнасцю Warning.
Звернеце ўвагу, што пасля налады прылады збору і аналізу гэтых падзей запатрабуецца дадатковы час на адладку для паніжэння колькасці ілжывых спрацоўванняў.
Раскажыце ў каментарах, якія збіраеце логі для аўдыту інфармацыйнай бяспекі і якія прылады для гэтага карыстаецеся. Адзін з нашых напрамкаў - рашэнні для аўдыту падзей інфармацыйнай бяспекі. Для рашэння задачы збору і аналізу логаў можам прапанаваць прыгледзецца да. , які ўмее сціскаць якія захоўваюцца дадзеныя з каэфіцыентам 20:1, а адзін яго ўсталяваны асобнік здольны апрацоўваць да 60000 падзей у секунду з 10000 крыніц.
Крыніца: habr.com