Дело о необъяснимых FTP-соединениях

Ключевой составляющей любого плана кибербезопасности является «непрерывный мониторинг», или возможность аудита и мониторинга через сетевое окружение, а также настройка автоматического анализа получающихся журналов для обнаружения аномального поведения, заслуживающего подробного исследования. Это часть нового менталитета «предполагаемых брешей», который признает, что не существует на 100 % защищенных систем. К несчастью, компания, оказавшаяся в центре этой истории, не имела всеобъемлющей системы мониторинга, поэтому была взломана некоторое время назад, что обнаружилось при обновлении сигнатур антивируса, удалившего заражение и привлекшего внимание к проблеме. Кроме подчеркивания, насколько слаба система безопасности во многих компаниях, данный случай иллюстрирует использование нескольких возможностей утилиты Sysinternals Process Monitor, включая диалог Process Tree и одну возможность, на которую многие не обращают внимания – способность программы Process Monitor контролировать сетевую активность.

Дело началось, когда сетевой администратор южноафриканской компании связался со службой поддержки Microsoft Services Premier Support и сообщил, что корпоративный Exchange-сервер, работающий под управлением Windows Server 2008 R2, создает исходящие FTP-соединения. Он заметил это только благодаря предупреждению установленного в компании Microsoft Forefront Endpoint Protection (FEP) о том, что тот вычистил с сервера кусок вредоносного кода. Предполагая, что сеть может быть по-прежнему скомпрометирована, несмотря на сообщение FEP о чистоте системы, администратор проверил журналы брандмауэров, защищающих периметр компании. К своему ужасу он обнаружил FTP-соединения, исчислявшимися сотнями в день на продолжении нескольких последних недель. Вместо попытки начать собственное расследование, администратор обратился в команду консультантов по безопасности Microsoft, специализирующуюся на помощи пользователям при восстановлении после атак.

Инженер поддержки Microsoft, которому было поручено дело, начал с пятиминутной трассировки событий сервера Exchange, выполненной с помощью программы Process Monitor. После завершения трассировки он открыл диалог Process Tree (дерево процессов), который находится в меню Tools и показывает отношения родитель-потомок для всех процессов, попавших в текущий журнал. Он сразу увидел, что за эти пять минут были запущены 20 FTP-процессов, каждый из которых был короткоживущим, за исключением одного, остававшегося по-прежнему активным (процесс 7324 на рисунке ниже):

Инженер обратился к командам, запускающим FTP-процессы, выбирая последние в дереве процессов, так чтобы их детали появились внизу диалога Process Tree. Причудливым образом половина команд содержала только аргумент “-?”, который выводит справку по FTP:

Другая половина была более интересна, она содержала ключи “-i” и “-s”:

Ключ “-i” выключает подсказку при пересылке нескольких файлов, а “-s” предписывает выполнить FTP-команды из файла, в данном случае, из файла “j”. Желая понять, что содержит файл “j”, инженер щелкнул на кнопке “Include Process” внизу диалога Process Tree, чтобы увидеть события, связанные с файлами процесса:

Он просмотрел результаты, отфильтровав журнал по “j” и обнаружил местоположение файла в нескольких событиях:

Он перешел в каталог C:\Windows\System32\i4333, но файла там не было. Это был тупик, и он переключил внимание на родительский процесс Cmd.exe и взглянул на его командную строку. Она была очень длинной и запутанной для простого понимания:

Он выделил ее, скопировал в буфер и вставил в Notepad, а затем разбил на составляющие, каждая из которых отделялась амперсандом “&”. Результат выглядел следующим образом:

Первая инструкция создавала каталог с именем i4333, а затем начиналось создание файла “j”. Команды, записанные в “j”, предписывали FTP соединиться с NUXZb.in.into4.info, зайти с именем «New» и паролем “123”, и загрузить все файлы с расширением “.exe”. После выполнения файл уничтожался и создавался командный файл, запускавший скачанные файлы, сначала с помощью Shell (параметр “start”), а затем из командной строки.

Краткое обращение к Whois показало, что имя хоста NUXZb относится к Protected Name Services и не содержит никакой полезной информации. Инженер отключил разрешение сетевых имен в Process Monitor и оставил в журнале исходящие FTP-соединения, чтобы увидеть IP-адрес, соответствующий разрешенному имени:

Определение местоположения IP-адреса в Интернет указало на IP-адрес ISP в Чикаго (теперь имя разрешается к другому IP-адресу), из чего инженер заключил, что либо соединение было со скомпрометированным сервером, либо атакующий располагался у этого ISP. Завершая анализ командной строки, он обратился к содержимому результирующего скрипта, D.bat, который по-прежнему был в каталоге и содержал единственную команду:

Не случайно, 134.exe оказался тем самым выполняемым кодом, на который среагировал Forefront, как на троян удаленного доступа (remote access Trojan, RAT) в предупреждении, с которого все началось. Поэтому скрипт не может найти его, и атака – или, по крайней мере, часть ее – была нейтрализована FEP. Также имейте в виду, что атака была автоматизирована и застряла в цикле, пытаясь активироваться.

Следующим шагом инженера было выяснить, как был запущен процесс командной строки. Взглянув на родительский процесс в дереве, он обнаружил, что все экземпляры запускались Sqlserver.exe:

Очевидно, это плохой знак, но не самое худшее: проверяя сетевую активность SQL Server в журнале, он обнаружил множество входящих подключений:

Поиск местоположений IP-адресов привел в Китай, Тунис, Тайвань и Марокко:

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

Он запустил специальный файл поддержки Microsoft, проверяющий различные установки безопасности SQL Server. Скрипт проработал несколько секунд и выдал обескураживающий результат: сервер имел административную учетную запись с пустым паролем, был настроен на аутентификацию в смешанном режиме и позволял хранимым процедурам запускать окно командной строки из-за разрешения «xp_cmdshell»:

Это означает, что любой пользователь Интернета мог зайти на сервер без пароля и выполнить задачу, вроде FTP, чтобы заразить систему собственными вредоносными программами.

С помощью программы Process Monitor и обсуждения с администратором компании, инженер службы поддержки составил ясное представление о случившемся: администратор компании установил SQL Server на Exchange Server компании за несколько недель до инцидента. Не осознавая, что сервер находится на периметре, он открыл порт SQL Server в локальном брандмауэре, оставил его с пустым паролем администратора и разрешил xp_cmdshell. Это произошло, несмотря на то, что даже если сервер не имеет связи с Интернет, такая конфигурация оставляет его безо всякой сетевой защиты. Спустя недолгое время, автоматическое вредоносное ПО, сканируя интернет в поисках незащищенных целей, столкнулось с открытым портом SQL, заразило сервер вредоносным кодом и, скорее всего, включило его в списки ботнета. Сигнатуры FEP для нового кода были доставлены на сервер спустя некоторое время, и программа удалила заражение. Вредоносное ПО по-прежнему пыталось реинтегрировать сервер в ботнет, когда было открыто дело в службе поддержки Microsoft. Хотя компания и не узнала, сколько данных было украдено в процессе заражения (и вообще было ли хоть сколько), это был очень громкий и ясный звоночек.

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