Для меня, как аналитика, самые полезные и интересные доклады и статьи – те, которые освещают практические аспекты информационной безопасности и дают конкретные примеры инцидентов и методов их выявления и расследования. Поэтому сегодняшняя статья посвящена нескольким интересным кейсам, с которыми мы в Solar JSOC сталкивались за последнее время.

Такие нужные торренты…

В одном из наших клиентов вся сетевая активность различных приложений является объектом строгого профилирования и контроля. Исходящая сетевая активность приложений контролируется на уровне прокси-сервера, и обнаружение сетевой активности от нового «user-agent» считается событием информационной безопасности. В этом случае круглосуточная первая линия мониторинга Solar JSOC может либо эскалировать его на аналитика, ответственного за заказчика, либо самостоятельно оповестить заказчика по маршруту, установленному для этого типа инцидентов. Выбор зависит от типа сетевой активности, ее подозрительности и другой сопутствующей информации.

Здесь стоит отметить, что отслеживание user-agent не является высокорелевантным сценарием, так как изменить сообщаемый агент не составляет труда. Но в последнее время комплексные решения типа ngfw по косвенным признакам, таким как состав пакета, особенности заголовка, частотность, конечные серверы, ответы за исходящие запросы и прочее, умеют определять не транслируемого агента, а реальное приложение.

В рамках расследования первая линия организует сбор максимального количества данных по инциденту: информацию о машине, всех пользователях, проходивших аутентификацию за последние сутки, объемах трафика в рамках сетевой сессии данного ПО, ее длительность. При наличии локальных логов собирается информация о запускаемых на хосте процессах.

17 апреля 2017 года примерно в 3 часа ночи было зафиксировано успешное внешнее соединение одного из средств удаленного администрирования, осуществленное с рабочего ноутбука сотрудника технической поддержки. Отдел техподдержки – единственный, кому разрешено использование данного типа user-agent`ов, но в данном случае вместо штатного средства использовалось утилита TightVNC. Ноутбук не был подключен к Solar JSOC, поэтому аналитики первой линии не могли собрать локальные логи машины и эскалировали инцидент на дежурного аналитика второй линии, параллельно готовя оповещение заказчика по электронной почте.

Далее приведена хронология событий:
03:08:02. Инцидент.
03:26:00. Оповещение специалистом первой линии дежурного аналитика по телефону.
03:29:00. Согласование с заказчиком подключения машины на уровне локальных логов ОС.
03:32:48. Оповещение от 1-й линии в сторону Заказчика.
03:48:00. Подключение машины к SIEM-системе.

Благодаря заранее настроенному расширенному аудиту на всех рабочих станциях (в том числе мобильных) и серверах заказчика, стало понятно, что активность произошла вследствие скачивания и запуска процесса tnvserver.exe. Выявить родительский процесс помогло расширенное логирование, которое мы настраиваем у заказчиков в обязательном порядке. Им торрент-клиент, который антивирус не посчитал вредоносносным ПО.


Общая хронология событий выглядит следующий образом:

Ситуация с так называемым псевдополезным ПО очень сложная, так как доказать его «зловредность» довольно проблематично, хотя большинство таких утилит ведет сбор статистики о работе пользователя на хосте, а часть способна запускать дополнительные компоненты и выполнять удаленные команды. Однако при этом псевдополезное ПО может параллельно исполнять свое основное предназначение, ради которого его и скачивали, а «зловредные» функции могут некоторое время находиться в состоянии спячки или добавляться в последующих версиях при обновлении.

Выявить такие программы с каждым годом все труднее. Если раньше маркерами служили навязчивая реклама, огромное количество баннеров, жалобы пользователей и кривой код, то сегодня этими «фичами» может обладать любой бесплатный продукт, разрабатываемый «энтузиастами». Обычно такие программы предлагают сказать музыку или фильмы, ускорить работу компьютера, очистить реестр, загрузить торренты и прочее.

Часть антивирусных решений способна детектировать такие продукты как not-a-virus, то есть ПО, потенциально опасное для пользователя, но выполняющее при этом полезные функции. Другая часть антивирусов никак на них не реагирует.

Опасность псевдополезного ПО в том, что на подавляющем большинстве рабочих станций и на домашних компьютерах оно ведет себя совершенно нормально, выполняя свои основные функции и отсылая разработчикам телеметрию. Но когда такое ПО попадает в интересную для злоумышленников инфраструктуру, например, в крупную компанию, активируются его вредоносные функции или докачиваются компоненты, предоставляющие возможность удаленного исполнения команд или организации сеанса remote administration. Далее такой хост выставляется на продажу в даркнете как точка проникновения в инфраструктуру компании.

Дальнейшие схемы работы злоумышленников разнообразны, но сводятся к хищению денег и/или ценной информации.

Вместо морали в финале этой истории хотелось бы дать несколько рекомендаций:

1. Ограничивайте возможность прямых соединений через межсетевые экраны для пользователей, используйте прокси-серверы. Они обладают категоризацией, позволяющей на основании трафика или адресов выявить использование средств удаленного администрирования.
2. Используйте антивирусное ПО, которое умеет детектировать not-a-virus.
3. Проводите полноценный тренинг security awareness среди пользователей.
4. Ограничивайте привилегии пользователей на рабочих станциях. В данном случае это помогло бы предотвратить установку как основного ПО, так и дополнительных пакетов.
5. По возможности регулируйте установленное на хостах ПО, в том числе ограничением пользователей в правах (запрет локального администратора).
6. Агрегация репутационных баз и интеграция их в SIEM-систему позволит выявить недетектируемые образцы вредоносных программ в инфраструктуре, использование TOR, средств удаленного администрирования и пр.

Контроль служебных учетных записей

Второй кейс касается использования легитимных средств в работе ИТ и ИБ в качестве инструмента для проникновения в критичную инфраструктуру.

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

На первом этапе расследования источником информации для анализа инцидента служили серверы, на которых хранились электронные реквизиты платежной системы. Эти серверы мы подключили на уровне локальных логов ОС Windows (максимальная глубина хранения составила 2 месяца для журнала System Event Log, Security — неделя)

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

На этом этапе мы подключили дополнительные источники:

• ретроспективные логи с пограничных и межсегментных МСЭ (агрегировались с помощью syslog-сервера)
• локальные логи сервера ***** (далее – SRV)

Оказалось, что сделать анализ локальных логов хоста server невозможно из-за их очистки, но при анализе образа данного хоста в восстановленном и декодированном файле wtmp (записывает данные в входе и выходе из системы) были найдены записи по аутентификации под учетной записью root за несколько недель до инцидента.

Также на SRV были обнаружены следы программного обеспечения, используемого злоумышленниками для проникновения в инфраструктуру, – программные пакеты nmap (система сканирования и выявления уязвимостей) и medusa (система интеллектуального подбора паролей).

При анализе логов межсегментных межсетевых экранов в период с первой аутентификации на хосте SRV по УЗ root и до момента инцидента были выявлены множественные попытки установления соединений с сервера на различные ресурсы компании по протоколу smb. Вероятнее всего, целью была парольная или другая значимая для проникновения информация.

Это можно наглядно представить внутренними средствами HPE ArcSight:


Далее были зафиксированы значительные (свыше 10 Мбайт) сессии по протоколу smb с хоста SRV на скомпрометированные серверы. Они осуществлялись в то же самое время, что и события аутентификации из локальных логов. Вероятнее всего, пароль учетной записи techuser был скомпрометирован в результате успешной эксплуатации уязвимости протокола smb на хосте. Уязвимость позволяла пройти беспарольную аутентификацию в системе под служебной учетной записью Windows и скомпрометировать пароли учетных записей через процесс lsass.exe.

Далее под учетной записью techuser была установлена системная служба, выполняющая функции remoteshell.

Основные особенности работы данного ПО таковы:

• Процесс установки и сборки использует только внутренние инструменты powershell, что существенно усложняет возможность его детектирования.
• Запускается новый экземпляр системного процесса svchost.exe с динамической сборкой кода в памяти процесса, тем самым усложняя возможность его определения как вручную, так и с помощью автоматизированного ПО.
• Для коммуникации с управляющим сервером используется порт 9887 (на сервере предварительно было добавлено разрешающее правило на локальном межсетевом экране).
• ПО не оставляет следов на файловой системе, функционирует целиком в оперативной памяти и удаляется по факту завершения сессии/

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

После того, как мы восстановили хронологию событий и исследовали обнаруженное вредоносное ПО, пришло время оценить масштаб бедствия:

• Сколько учетных записей скомпрометировано.
• Существуют ли резервные каналы попадания в инфраструктуру компании.
• Какие еще системы были затронуты.
  

Компании были выданы рекомендации по минимизации рисков и, в частности, проработке вопросов закрытия следующих каналов доступа злоумышленника в инфраструктуру.

• Удаленный доступ в сеть компании:
  
  • Проанализировать все факты удаленного доступа в сеть компании за два месяца (мы предоставили выгрузку), выполнить верификацию активностей пользователей.
  • Провести инвентаризацию всех учетных записей с правами удаленного доступа, отозвать избыточные права.
  • Обновить пароли всем пользователям удаленного доступа.
  
  
• Использование утилит удаленного администрирования или доступа к центру управления через прокси-сервер:
  
  
  • Проанализировать все факты доступа к подозрительным ресурсам/с использованием нестандартных протоколов через прокси-сервер (здесь мы предоставили выгрузку и сделали приоритизацию подозрительных активностей).
  • Введено ограничение прямого доступа в Интернет в сети компании для гарантированного перенаправления всего Интернет-трафика через прокси-сервера.
  
  
• Аудит всех хостов компании на предмет использования ПО, применяемого хакерскими группировками для компрометации паролей (Mimikatz, procdump).

Вроде APT….или нет?

Следующий кейс, выявленный в рамках пилотного проекта Solar JSOC, выглядит очень нестандартно, так как по всем признакам он должен быть про APT – spoiler alert! – но на самом деле нет. Итак, дано:

• Несколько вредоносов: keylogger, RAT и еще пачка других.
• Скомпрометированная машина помощника генерального директора.
• Злоумышленники, использовавшие этот хост несколько месяцев.

На старте пилотного проекта при подключении инфраструктурных источников значительная часть сценариев выявления инцидентов начинает работать сразу, без каких-либо дополнительных усилий. К этим сценариям, среди прочего, относятся обращения к потенциально опасным хостам по версии различных репутационных баз, агрегируемых в Solar JSOC.

Сценарий работает по следующему принципу: Существует несколько активных листов – лист с ip-адресами, лист с доменами 2-4 уровня, лист с полными ссылками к вредоносным объектам. Специальный скрипт нормализует различные репутационные базы, приводя их к единому виду. Далее каждое правило работает либо с различными полями, проверяя вхождение зафиксированных на межсетевых экранах событий со строками activelist по полям target address либо request url host (target host name), либо request url.

При подключении пограничного межсетевого экрана были обнаружены обращения на известные потенциально опасные ресурсы (IP-адреса C&C-серверов), которые могли свидетельствовать о заражениях внутренних ресурсов компании вредоносным ПО.

По каждой сработке были проведены подробные разборы ситуаций. Мы собрали с хостов локальные логи операционных систем и выявили процессы, которые инициировали соединения к внешним адресам.

Один из потенциально зараженных хостов оказался рабочей станцией помощника генерального директора компании. В результате исследования машины на ней были обнаружены следы вредоносного ПО, включая шпионское ПО Mipko Personal Monitor (MPK).

Шпионское программное обеспечение MPK было установлено на АРМ из-под учетной записи АРМ\Serv. При этом первый вход данной учетной записи на рабочую станцию был выполнен за несколько месяцев до самой установки.

Mipko Personal Monitor собирал с рабочей станции информацию о запускаемых процессах, снимки рабочего стола, а также данные с клавиатуры, из буфера обмена и активных окон браузера.

Контроль и сбор информации осуществлялся в отношении двух учетных записей: АРМ\serv и учетной записи помощника.

Перехваченные данные каждые 8 часов отсылались на внешние ресурсы:

• ***nks.biz по FTP
• ******@gmail.com

Факты передачи при этом были подтверждены событиями с пограничного межсетевого экрана.

С момента первого входа под учетной записью АРМ\serv и до момента проведения расследования на хосте фиксировались множественные входящие удаленные сеансы RDP с различных внешних адресов (в среднем 10 000 соединений в сутки).

Скриншоты, собранные шпионским ПО MPK, демонстрировали весьма любопытную активность из-под учетной записи АРМ\Serv:

• Попытки внедрения PHP-скрипта во множество сайтов.
• Регистрация мобильных номеров, множественные регистрации различных почтовых ящиков.
• Ввод данных по различным кредитным картам на сайтах.
• Переводы небольших денежных сумм на различные счета/электронные кошельки и мобильные номера.
• Совершение покупок на различных торговых площадках.

Также в результате анализа логов MPK был найден файл, в котором содержалось более 500 различных внешних IP адресов, которые доступны извне по RDP, вместе с учетными данными для подключения (логин-пароль).

По всей видимости, АРМ помощника использовали как промежуточную машину для атак на веб-сайты, кражи данных банковских карт/учетных данных пользователей этих сайтов и перевода денежных средств со скомпрометированных карт и счетов, а также обналичку через покупки. Судя по всему, зараженная рабочая станция была одной из сети скомпрометированных машин, которыми пользуются злоумышленники в своих целях.

А теперь немного техники.

В результате исследования были обнаружены следующие нелегитимные утилиты (нелегитимность подтверждена в том числе владельцем АРМ).

В ходе мероприятий по локализации активности MPK мы получили дополнительную информацию:

• Обнаружена скрытая директория MPK, расположенная по пути: C:\ProgramData. Содержимое данной директории представляло собой PE-объекты, необходимые для функционирования «MPK», а также конфигурационные и лог-файлы.
  В результате сканирования данной директории обнаружены множественные объекты с сигнатурой JFIF (JPEG File Interchange Format), что говорит о наличии в ней изображений.
  
  
• Обнаружены активные процессы, имеющие непосредственное отношение к функционированию «MPK»:
  mpk.exe (NT AUTHORITY)
  mpkl64.exe (NT AUTHORITY)
  lsynchost.exe (NT AUTHORITY)
  
  
• Обнаружены успешные попытки внедрения PE-объектов (MPK64.dll и MPK.dll), являющиеся компонентами MPK, в адресное пространство активных процессов.
  В результате трассировки активных процессов обнаружен факт перехвата данных, вводимых в окна приложений и передаваемых через буфер обмена. Функционал перехвата реализован в PE-объектах: MPK64.dll и MPK.dll.
  

Для того чтобы установить функциональность данной сборки MPK и определить, какая информация могла быть собрана и передана третьим лицам в результате работы вредноса, мы получили с АРМ помощника следующие данные:

• Файловая система: %SYSTEMROOT%\ProgramData\MPK\*
  %SYSTEMROOT%\SysWoW64\Mpk\*
  %SYSTEMROOT%\Prefetch\*
  %SYSTEMROOT%\inf\*
  %SYSTEMROOT%\System32\Logs\*
  %USERPROFILE%\AppData\Local\ Temporary Internet Files\*
  %USERPROFILE%\Temp\*
  
• Экспорт реестра: HKEY_CURRENT_USER
  HKEY_LOCAL_MACHINE
  HKEY_USERS
  
• Активный снимок оперативной памяти.

В директории «C:\Windows\MPK» были обнаружены лог-файлы, которые содержали информацию о ходе установке программного обеспечения и конфигурационных параметрах работы: mpk_em_log.txt и *.dat. В результате анализа были получены подробности установки и работы MPK:

• Установщиком был PE-объект — mpk_emni_mpk.exe. Основные компоненты, необходимые для установки, располагались в директории C:\Users\Serv\Desktop\1\6\*.
  
  
• В случае функционирования внутреннего брандмауэра Windows для него создавались специальные правила:
  
  
  
  
• Учетным записям помощника и АРМ\Serv были присвоены директории с именами «1» и «2». Эти скрытые директории, расположенные в C:\ProgramData, содержали перехваченные данные.

По итогам расследования заказчику были выданы следующие рекомендации:

1. «Перезалить» операционную систему на рабочей станции.
2. Сменить пароли от всех учетных записей, которыми пользовались на данной рабочей станции.
3. В случае, если служба Service-Desk подключалась к данной рабочей станции и вводила там свои учетных данные, рекомендовалось сменить пароли от них.
4. Запретить белый IP-адрес и прямой доступ в Интернет для данной рабочей станции. Если наличие белого IP-адреса является производственной необходимостью, то использовать повышенные требования по безопасности к любым удаленным подключениям к ней:
   
   
   • Пароли повышенной стойкости;
   • Частая смена паролей;
   • Жесткое ограничение IP-адресов, с которых возможны какие-либо входящие подключения;
   • Контроль состояния антивирусного средства;
   • Изоляция рабочей станции в отдельный сегмент без доступов к внутренним ресурсам компании или со строгим ограничением такого доступа к конкретным ресурсам.
5. Проверить всю инфраструктуру компании на наличие подобного шпионского ПО, средств удаленного администрирования, другого несанкционированного ПО.
6. Осуществлять мониторинг критичных рабочих станций и серверов по следующим направлениям:
   
   
   • сетевая активность к известным опасным и вредоносным ресурсам (в режиме реального времени);
   • активность привилегированных учетных записей;
   • запускаемые процессы;
   • изменения системных директорий и критичных веток реестра;
   • использование систем удаленного управления;
   • вирусная активность;
   • вредоносные почтовые рассылки на пользователей;
   • аномалии в профилях подключения к критичным серверам и рабочим станциям;
   • использования служебных учетных записей не по назначению.

Как можно видеть, не всегда случаи компрометации машины и длительного нахождения на ней вредоносов ведут к взлому инфраструктуры клиента. Иногда у злоумышленников свои приземленные цели, и зараженные хосты используются лишь как средство их достижения. Но потенциально все могло закончиться сильно хуже – количество «чувствительной» информации у сотрудников такого звена обычно велико, и ее утечка может нанести серьезный ущерб.

В этом статье я осветил лишь три кейса из многих, которые мы наблюдаем в JSOC. Инциденты случаются ежедневно, в основном рутинные, но бывают и интересные экземпляры. Учитывая их количество, думаю, скоро выйдет вторая серия обзора интересных кейсов из жизни Solar JSOC.

https://habrahabr.ru/post/333816/