В этом году перед «Противостоянием» мы в очередной раз собрали сборную «солянку» частично из сотрудников Solar Security, частично из неравнодушных друзей и SOCостроителей России. В статье попробуем описать весь процесс участия в «Противостоянии» — какие были «пасхалки» от организаторов, какие шли атаки, как мы защищались, какие инструменты отработали и т.д.
В прошлом году наша команда занималась мониторингом Телекома (который по инфраструктуре не сильно отличался от Офиса, но не суть). В этом году SOCов стало меньше, инфраструктура Телекома лишилась домена, рабочих станций и большей части серверов, и мы решили поработать еще и с Офисом.
У каждого участника на противостоянии были свои цели и задачи. Для нас основной задачей была возможность в «боевых условиях» проверить контент по работе с endpoint (сетевую часть мы проверили в прошлом году), идеи по выявлению различных методов доставки вредоносного ПО на рабочие станции пользователей и закрепления Атакующих в инфраструктуре. Офис для этого подходил идеально, особенно с учетом того, что организаторы обещали «врага внутри».
Если подвести интегральную оценку мероприятия, все было достаточно бодро и интересно. Обе инфраструктуры, которые мы защищали, обошлись без успешных атак в области защиты и при работе (GSM Телекома оказался не в скоупе защиты или мониторинга). Инфраструктуры от атакующих мы защитили полностью (хотя команда Телекома и получила желтую карточку за споры с арбитром). Еще по дороге нашли пару «пасхалок» от организаторов, чем, видимо, и лишили себя увлекательной борьбы с внутренним врагом. Теперь обо всем по порядку.
Мониторинг доступности инфраструктуры и актуальность настроек аудита
По опыту прошлого года было понятно, что инфраструктура нестатична и может меняться в произвольные моменты времени. Вот только если в прошлом году она росла (нам прилетело 6 хостов на внешнем периметре в течение 10 минут), то в этом стала стремительно сокращаться. На момент старта количество серверов внутри сети сократилось до 11, и количество рабочих станций – до 15.
В таких условиях быстро стало понятно, что, несмотря на настроенный аудит, нужна достоверная информация о его состоянии. Ведь если виртуалку с любым из хостов откатят, то мы останемся и без патчей, и без мониторинга.
В итоге приличная часть времени уходила на то, чтобы оперативно разбираться с возникающими проблемами. Хосты периодически подвисали (вход в консоль по RDP мог занимать полчаса), их ребутали, и все это серьезно портило нервы. Одно радует – мониторинг доступности сработал на все 100.
Первые инциденты – Web
Ожидаемо все начинается с внешних веб-сервисов. Сканировали постоянно, пытались закидывать шеллы и дефейсить сайты периодически.
Вот так иногда атакующие раскрывают себя (успешная эксплуатация SSTI в фотохостинге: defcon.ru/web-security/3840):
В итоге в условиях PHDays вполне неплохо отработало правило:
Теперь любая попытка получить контроль над хостом и инициировать соединения на свои хосты вполне неплохо детектировалась.
В какой-то момент смотреть за всем этим стало скучно и на сервере сделали chmod –x /bin/nc.
Результат:
Видимо, народ со стороны Атакующих несколько обиделся и пошли запросы такие:
Общие результаты:
А где же атаки внутри сети?
За все время мониторинга не было зафиксировано ни одного проникновения атакующих за периметр Офиса.
Наверное, в этом самое большое разочарование в прошедшем PHDays, поскольку работа с коллбэками, внедренным вредоносным ПО и инсайдерами – один из очень серьезных пластов жизни текущей информационной безопасности и SOCа. Общаясь с коллегами из команд Защитников, мы слышали от всех, что основной вектор направлен на преодоление периметра: сканят веб, иногда дефейсят сайты, используют уязвимости.
При этом мы регулярно проводили свои проверки на детекты по разным хостам, и все они проходили успешно. Все, что мы планировали детектировать – все отрабатывало.
К сожалению, ввиду отсутствия атак, детально показать логику обнаружения не выйдет. Поэтому пара примеров, как подобные детекты выглядят в нашей инфраструктуре:
В целом наличие незащищенной инфраструктуры и банка в режиме мониторинга, а не блокирования сильно изменило фокус внимания Атакующих. Большую часть времени они концентрировались на взломе и аудите защищенности именно этой инфраструктуры, а не на пробивании оборонительных редутов Защитников и SOCов. В итоге и часть богатого инструментария Атакующих не была применена на инфраструктурах Защитников, и часть сюрпризов Защитников и SOCов по детекту и противодействию осталась не до конца проверенной в боевых условиях.
Тем не менее, не стоит воспринимать это как критику в сторону организаторов. Они проделали колоссальный объем работ по запуску мероприятия, инфраструктур и сложных интеграций, и при всех возникающих сложностях PHDays подтвердило свой статус одной из ключевых ИБ-конференций. Но SOCам и Защитникам хочется больше огня и хардкора, и мы готовы помочь в его изобретении ;)
В прошлом году наша команда занималась мониторингом Телекома (который по инфраструктуре не сильно отличался от Офиса, но не суть). В этом году SOCов стало меньше, инфраструктура Телекома лишилась домена, рабочих станций и большей части серверов, и мы решили поработать еще и с Офисом.
У каждого участника на противостоянии были свои цели и задачи. Для нас основной задачей была возможность в «боевых условиях» проверить контент по работе с endpoint (сетевую часть мы проверили в прошлом году), идеи по выявлению различных методов доставки вредоносного ПО на рабочие станции пользователей и закрепления Атакующих в инфраструктуре. Офис для этого подходил идеально, особенно с учетом того, что организаторы обещали «врага внутри».
Если подвести интегральную оценку мероприятия, все было достаточно бодро и интересно. Обе инфраструктуры, которые мы защищали, обошлись без успешных атак в области защиты и при работе (GSM Телекома оказался не в скоупе защиты или мониторинга). Инфраструктуры от атакующих мы защитили полностью (хотя команда Телекома и получила желтую карточку за споры с арбитром). Еще по дороге нашли пару «пасхалок» от организаторов, чем, видимо, и лишили себя увлекательной борьбы с внутренним врагом. Теперь обо всем по порядку.
Этап подготовки, или как инфраструктура выглядит до начала игры
- По задумке организаторов, «в целях сохранения баланса в инфраструктурах компаний присутствует постоянное, с небольшим люфтом, число уязвимостей». На практике это выглядит как Windows 2008 R2 без единого обновления на всех 50 хостах. Это был первый сюрприз. При этом возможность обновления ОС выбивали чуть ли не с боем, ибо должен быть «баланс».
Но обновляться надо в любом случае, т.к., например, Sysmon v6 на Windows 2008 и Windows 7 уже не устанавливается, поскольку ОС не может проверить цифровую подпись. Решение.
- Вторым сюрпризом было число Web-приложений в инфраструктуре офиса. Видимо, решили собрать все известные платформы с наибольшим количеством дырявого софта.
- Как выглядела инфраструктура в целом:
- 25 серверов с OS Windows 2008 R2. Основной функционал – база mysql под каждый из внешних веб-сервисов.
- 25 рабочих станций Windows 7.
- 32 внешних сервиса, преимущественно Ubuntu с разнообразным веб-контентом.
СЗИ, на которые у Защитников хватило средств:
- CheckPoint FW + IPS на внешнем периметре сети.
- Kaspersky AV 10 на рабочих станциях + Kaspersky for windows server 8.0 на серверах.
- Kaspersky for Linux на внешних веб серверах.
- ObserveIT на всех серверах инфраструктуры.
Мониторинг в SOC:
- ArcSight – СЗИ + аудит ОС.
- Splunk – netflow + Unix Audit. Мониторинг Web + мониторинг сетевых атак, наличия новых хостов\сервисов.
- По договоренности с Защитниками помимо мониторинга мы взяли на себя реагирование по Windows-инфраструктуре. В том числе и по той причине, что необходимый нам аудит раскатывается не совсем тривиально и нам самим нужно было определить проблемные места.
Общая концепция мониторинга инфраструктуры
- Внешний Web:
- На уровне ОС – auth log + auditd на EXECVE + изменение конфигов Web-сервера и каталогов /tmp/.
- Аудит выполняемых команд в bash (что-то вроде webplay.pro/linux/syslog-log-bash-history-every-user.html, но сильно улучшенное).
- Надежда на CheckPoint IPS.
- Kaspersky AV на Linux. Не то чтобы мы в него сильно верили, но раз уж он есть...
Задачи для мониторинга (взяли по минимуму, чтобы не совсем стыдно было):
- Внешние сканирования.
- Подборы паролей и входы на сервера по SSH не из наших сегментов.
- Создание скриптов в ОС.
- Немного кастомных сценариев, которые дописывались на лету под изменение инфраструктуры.
- ОС Windows:
- Sysmon v6:
- Запуск процессов (много плюсов по сравнению со стандартным аудитом Windows).
- Создание файлов и изменение реестра (включается сразу на весь хост, не нужно настраивать отдельно на каждом каталоге).
- Загрузка библиотек (очень хотелось увидеть использование «хакерами» различного вредоносного ПО).
- Обращение к адресному пространству других процессов.
- Аудит OS Windows (Advanced Audit Configuration).
Здесь тоже нет никакой магии, все стандартно. Единственный момент – в обязательном порядке включался аудит категории «Filtering Platform Connection», в которой есть возможность сопоставить сетевые события с процессами, которые эти соединения инициируют.
- Пара библиотек, которые на старте инжектятся в процессы cmd.exe и powershell.exe и логируют все введенные команды. Чудесная вещь :)
- Несколько «сюрпризов» для Атакующих:
- Взяли на вооружение опыт обследований на проектах и сделали УЗ svcbackup в домене с паролем в комментариях. И рядом правило на детект любой активности под этой УЗ:
- Патчи ставить – это хорошо и правильно, но несправедливо по отношению к Атакующим. Поэтому мы решили помочь организаторам, и обновления на ОС стали выглядеть так:
- Мы все же ждали, что Атакующие быстро попадут внутрь сети, поэтому через домен практически на все рабочие станции раскатили LSA Protect для защиты от Mimikatz. Но при этом не для всех типов УЗ, и только Logon Credential
HKLM\SYSYTEM\CurrentControlSet\Control\SecurityProvider\Wdigest /v UseLogonCredential /t REG_DWORD /d 0
Естественно, с мониторингом изменения соответствующего параметра в реестре.
- На случай, если бы Атакующие при попадании в систему попытались бы отключить нас от управления (например, включив блокирующие правила на FW), был подготовлен скрипт, работающий по расписанию и меняющий политику на исходную при наличии событий включения FW:
Внимание, спойлер!$compname = Get-WMIObject Win32_ComputerSystem | Select-Object -ExpandProperty name $outputevent = Get-WinEvent –LogName "Microsoft-Windows-Windows Firewall With Advanced Security/Firewall" | Where-object {$_.ID -eq 2003} | Format-list TimeCreated, Message | Out-File $env:temp\JSOC_TEMP_FW #reg.exp = (?i).(.*value.*yes) $readoutputeventE = type $env:temp\JSOC_TEMP_FW | Select-String -Pattern "Value: Yes" if ($readoutputeventE) { & $env:systemroot\getrulesFW.vbe & $env:systemroot\System32\cmd.exe /c netsh advfirewall import $env:systemroot\JSOC.wfw Get-WinEvent –LogName "Microsoft-Windows-Windows Firewall With Advanced Security/Firewall" | Where-object {$_.ID -eq 2003} | Format-list TimeCreated, Message | Out-File $env:temp\JSOC_FW_LOG & $env:systemroot\System32\wevtutil.exe cl "Microsoft-Windows-Windows Firewall With Advanced Security/Firewall" Write-EventLog –LogName Application –Source "Application" –EntryType Information –EventID 666 –Message "Firewall enabled detected: START AUTORESPONSE!!1111" }
- Взяли на вооружение опыт обследований на проектах и сделали УЗ svcbackup в домене с паролем в комментариях. И рядом правило на детект любой активности под этой УЗ:
- Sysmon v6:
- Контент по мониторингу ОС Windows в итоге разбился на несколько частей:
- Стандартный контент Solar JSOC, который работает на всех заказчиках.
- Отдельные правила по детектированию аномальной активности и попыток закрепления в ОС.
Про первую часть писать неинтересно, а вот на второй остановимся немного подробнее.
Общая идея следующая:
- Детектируем варианты закрепления в ОС. Описывать долго, лучше дам ссылку на отличную презентацию коллег из ЛК на PHDays, которые замечательно расписали все методы детектирования: www.phdays.com/program/231388
- Детектируем сетевую активность системных процессов. Для этого собирали профили работы и настраивали списки исключений по тому, что было признано легитимным.
- Детектируем активность системных процессов на файловой системе и в реестре. Для этого также собирали профили и составляли списки разрешенной активности.
- Детектируем изменение веток реестра, которые отвечают за автозапуск приложений и библиотек при старте системы и/или входе пользователя.
- Детектируем изменение веток реестра, которые отвечают за защиту от условного mimikatz и его аналогов, изменения командлетов powershell и т.д.
В целом это тема для отдельных статей, возможно, чуть позже опишем подробнее.
После того, как весь аудит был настроен и запущены правила, появились первые результаты. Начали фиксировать сетевую активность от процесса svchost.exe на некий внешний сервер 208.91.197.46:9999, которого не было в нашем профиле. В ArcSight это выглядело следующим образом:
После беглого анализа выяснилось, что вредоносный код используется в svchost.exe через вредоносную dll: c:\windows\FileName.jpg:
Параллельно с ней обнаружился еще один вредонос на том же сервере. Вот только функционал не успели изучить, удалили сразу же, как увидели :)
c:\program files (x86)\wina\wina.exe (471d39a51a79f342033c5b0636c244dc).
www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/troj_scar.alr + www.virustotal.com/ru/file/1154535130d546eaa33bbc9051a9cb91e2b0e3a3991286c3d5b0a708110c9aa7/analysis
Возможно, это стало нашей самой большой ошибкой за время противостояния, но мы «прибили» этот сюрприз от организаторов еще до начала игры. Вполне вероятно, что он был частью какого-то масштабного плана, но уже поздно о чем-то сожалеть :)
С такими результатами мы и пошли спать последний раз перед началом игры.
Противостояние
Мониторинг доступности инфраструктуры и актуальность настроек аудита
По опыту прошлого года было понятно, что инфраструктура нестатична и может меняться в произвольные моменты времени. Вот только если в прошлом году она росла (нам прилетело 6 хостов на внешнем периметре в течение 10 минут), то в этом стала стремительно сокращаться. На момент старта количество серверов внутри сети сократилось до 11, и количество рабочих станций – до 15.
В таких условиях быстро стало понятно, что, несмотря на настроенный аудит, нужна достоверная информация о его состоянии. Ведь если виртуалку с любым из хостов откатят, то мы останемся и без патчей, и без мониторинга.
В итоге приличная часть времени уходила на то, чтобы оперативно разбираться с возникающими проблемами. Хосты периодически подвисали (вход в консоль по RDP мог занимать полчаса), их ребутали, и все это серьезно портило нервы. Одно радует – мониторинг доступности сработал на все 100.
Первые инциденты – Web
Ожидаемо все начинается с внешних веб-сервисов. Сканировали постоянно, пытались закидывать шеллы и дефейсить сайты периодически.
Вот так иногда атакующие раскрывают себя (успешная эксплуатация SSTI в фотохостинге: defcon.ru/web-security/3840):
/var/lib/php5/sess_vhd4sts3mpk78n4qacc4o8knm0:logged|b:1;name|s:98:"{{_self.env.registerUndefinedFilterCallback('exec')}} {{_self.env.getFilter('ping 100.64.199.5')}}";username|s:4:"test";avatar|s:25:"images/default_avatar.jpg";
В итоге в условиях PHDays вполне неплохо отработало правило:
Теперь любая попытка получить контроль над хостом и инициировать соединения на свои хосты вполне неплохо детектировалась.
В какой-то момент смотреть за всем этим стало скучно и на сервере сделали chmod –x /bin/nc.
Результат:
[Tue May 23 21:41:36.273170 2017] [:error] [pid 4203] [client 198.18.78.12:23814] PHP Notice: Undefined index: avatar in /var/www/html/models/User.php on line 21, referer: http://203.0.113.155/login.php
sh: 1: /bin/nc: Permission denied
sh: 1: /bin/nc: Permission denied
Видимо, народ со стороны Атакующих несколько обиделся и пошли запросы такие:
198.18.78.12 - - [24/May/2017:01:48:33 +0400] "GET /xymfrxtestfilehu****.php?hu***a=%63%61%74%20%2f%74%6d%70%2f%6d%79%70%69%70%65%7c%2f%62%69%6e%2f%64%61%73%68%20%32%3e%26%31%7c%6e%63%20%2d%6c%20%39%39%39%39%20%3e%2f%74%6d%70%2f%6d%79%70%69%70%65 HTTP/1.1" 200 1985 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0"
Общие результаты:
- Подключение к базе (напомню, web-серверы во внешнем сегменте, а их базы данных – внутри сети) на всех серверах не отличалось оригинальностью:
define('DB_NAME', 'wordpress'); /** MySQL database username */ define('DB_USER', 'wordpressuser'); /** MySQL database password */ define('DB_PASSWORD', 'secondstrongpassword'); /** MySQL hostname */ define('DB_HOST', 'o-srv05.office.cityf');
Однажды этим даже воспользовались :)
- Удивительно, но большое количество попыток залить что-то на сервер детектировалось AV Kaspersky:
Object HEUR:Backdoor.PHP.PhpShell.eg is detected in /var/www/modx/temp/8f18b8d9d5a4cdbbe1f2962fa3868dd4/fonts/s.php Object HEUR:Backdoor.Multi.Mibsun.gen is detected in /tmp/.Xorg/tshd Object HEUR:Backdoor.Linux.Agent.ai is detected in /tmp/.Xorg/tsh/tsh Object HEUR:Exploit.Linux.CVE-2017-7308.a is detected in /tmp/pwn123 Object HEUR:Exploit.Linux.Dirtycow.a is detected in /tmp/cowroot
- Мониторинг error-лога веб-сервера + аудит запуска приложений – частично решают проблему отсутствия WAF.
- Без WAF очень плохо. Быстро закрыть какую-то дыру в некоторых случаях просто невозможно.
А где же атаки внутри сети?
За все время мониторинга не было зафиксировано ни одного проникновения атакующих за периметр Офиса.
Наверное, в этом самое большое разочарование в прошедшем PHDays, поскольку работа с коллбэками, внедренным вредоносным ПО и инсайдерами – один из очень серьезных пластов жизни текущей информационной безопасности и SOCа. Общаясь с коллегами из команд Защитников, мы слышали от всех, что основной вектор направлен на преодоление периметра: сканят веб, иногда дефейсят сайты, используют уязвимости.
При этом мы регулярно проводили свои проверки на детекты по разным хостам, и все они проходили успешно. Все, что мы планировали детектировать – все отрабатывало.
К сожалению, ввиду отсутствия атак, детально показать логику обнаружения не выйдет. Поэтому пара примеров, как подобные детекты выглядят в нашей инфраструктуре:
- Пример внедрения кейлоггера в процесс mstsc.exe. Алерт на не подписанную библиотеку -> Смотрим обращения к процессу, который эту библиотеку загрузил -> По PID получаем дальнейшую активность и исходные вредоносные библиотеки.
- SandBox SIEM ? Так выглядит криптор обыкновенный:
В целом наличие незащищенной инфраструктуры и банка в режиме мониторинга, а не блокирования сильно изменило фокус внимания Атакующих. Большую часть времени они концентрировались на взломе и аудите защищенности именно этой инфраструктуры, а не на пробивании оборонительных редутов Защитников и SOCов. В итоге и часть богатого инструментария Атакующих не была применена на инфраструктурах Защитников, и часть сюрпризов Защитников и SOCов по детекту и противодействию осталась не до конца проверенной в боевых условиях.
Тем не менее, не стоит воспринимать это как критику в сторону организаторов. Они проделали колоссальный объем работ по запуску мероприятия, инфраструктур и сложных интеграций, и при всех возникающих сложностях PHDays подтвердило свой статус одной из ключевых ИБ-конференций. Но SOCам и Защитникам хочется больше огня и хардкора, и мы готовы помочь в его изобретении ;)
Поделиться с друзьями