Эксперты BI.ZONE рассказали, как можно выявить атаку Zerologon

Эксперты BI.ZONE рассказали, как можно выявить атаку Zerologon

Эксперты BI.ZONE рассказали, как можно выявить атаку Zerologon

Исследователи из ИБ-компании BI.ZONE изучили опасную уязвимость Windows, получившую известность как Zerologon, и разработали несколько методов обнаружения фактов ее эксплуатации. Эксперты надеются, что использование созданных ими правил позволит также ускорить классификацию киберинцидентов.

Уязвимость Zerologon (CVE-2020-1472) была выявлена в протоколе шифрования, который использует Windows-служба Netlogon. Использование бреши позволяет автору атаки обойти аутентификацию,  повысить свои привилегии до уровня администратора домена и получить доступ на запись к базе данных Active Directory. Уязвимость затрагивает серверные ОС Windows; разработчик уже выпустил патч и опубликовал руководство для пользователей, однако злоумышленники не оставляют попыток проникнуть в сети Windows через эту лазейку.

Эксперты BI.ZONE проанализировали несколько известных концепций атаки (proof-of-concept, PoC) на Zerologon, а также эксплойты, обнаруженные в атаках, и выяснили, что все они работают в целом одинаково. На основании полученных результатов было разработано три способа обнаружения эксплойт-атаки: по событиям журналов аудита Windows, по сетевому трафику и при помощи YARA-правил.

В первом случае администратору Windows придется включить режим отладки Netlogon с помощью команды nltest /dbflag:0x2080ffff. После перезапуска служба начнет сохранять большую часть событий в файл журнала (отыскивается по пути C:\Windows\debug\netlogon.txt). Признаком атаки могут служить следующие события на контроллере домена:

  • 5805 — ошибка аутентификации сессии, доступ запрещен;
  • 5723 — ошибка установления сессии из-за отсутствия доверенного аккаунта в базе данных безопасности;
  • 4742 — изменение учетной записи компьютера контроллера домена (должно насторожить при отсутствии события 5823, говорящего о легитимной смене пароля по истечении заданного срока, либо при регистрации обоих событий с интервалом в 1 минуту).

Для эксплуатации Zerologon злоумышленники зачастую задействуют легитимный инструмент Mimikatz или пользуются виртуальной машиной под управлением ОС Kali Linux, поэтому имена mimikatz и kali в записях событий 5805 и 5723 могут более явно свидетельствовать об атаке.

Для удобства отслеживания Zerologon-событий с помощью SIEM исследователи сформулировали три правила:

  • (EventID = ’5805′ OR EventID = ’5723′) AND (Message contains ’kali’ OR Message contains ’mimikatz’)
  • when both of (EventID = ’4742′ AND TargetUserName IN «Domain_Controller_Accounts_List» AND PasswordLastSet != ’-’) and not (EventID = ’5823′) were detected on the same host within 1 minute (требует внесения списка контроллеров домена в набор Domain_Controller_Accounts_List)
  • when both of (EventID = ’4742′ AND TargetUserName IN «Domain_Controller_Accounts_List» AND PasswordLastSet != ’-’) and (EventID = ’5805′) were detected on the same host within 1 minute

Попытку эксплуатации Zerologon можно выявить и путем анализа сетевого трафика с помощью IDS или IPS. Признаком атаки в данном случае, по словам экспертов, будет служить «аномально большое количество запросов из одного источника по протоколу DCE/RPC с парами методов NetrServerReqChallenge и NetrServerAuthenticate за короткий промежуток времени». Кроме того, выдать вредоносную активность могут уникальные артефакты, но они не всегда присутствуют в трафике.

По итогам исследования было также создано YARA-правило для выявления следов эксплуатации Zerologon в памяти процесса lsass.exe. Обращение к сервису проверки подлинности локальной системы (LSASS) происходит при попытке аутентификации на контроллере домена. В результате в адресном пространстве lsass.exe остаются артефакты, которые тоже могут служить признаками атаки. В ходе тестирования созданное экспертами YARA-правило с успехом отработало на ОС Windows Server 2012 R2 и Windows Server 2016.

Сотрудники против: 52% компаний буксуют с переходом на тонкие клиенты

Переход на тонкие клиенты в российских компаниях чаще всего тормозит вовсе не техника, а люди. По данным опроса среди зрителей и участников эфира AM Live «Тонкий клиент: инструмент создания цифровых корпоративных рабочих мест», 52% компаний не могут полноценно перейти на такую модель из-за сопротивления сотрудников, привыкших к обычным компьютерам.

На этом фоне особенно показательно выглядит другая цифра: только 25% компаний уже используют удалённые рабочие места через десктопы или тонкие клиенты.

Иначе говоря, три четверти по-прежнему опираются либо на офисные компьютеры, либо на добросовестность сотрудников, которые работают с собственных устройств. А это, как отмечали участники дискуссии, оставляет бизнес в довольно уязвимом положении: данные и учётные записи оказываются размазаны по множеству конечных точек, и каждая из них потенциально может стать входом в корпоративную сеть.

Идея тонких клиентов как раз в обратном: рабочее место у сотрудника есть, но сами данные и основные процессы остаются внутри защищённой инфраструктуры компании. Директор департамента управления продуктовым портфелем Getmobit Василий Шубин по этому поводу высказался довольно жёстко: когда сотрудникам разрешают работать с личных устройств, компания фактически перекладывает риск на конечного пользователя.

Впрочем, дело не только в привычках. Второй по популярности барьер — поддержка периферии, на неё пожаловались 46% опрошенных. Дальше причины идут уже с заметным отрывом: 32% считают проблемой высокую стоимость внедрения, 28% говорят о несовместимости приложений, 26% — о нехватке экспертизы у ИТ-команд, ещё 22% упомянули ограничения сети и каналов связи.

Некоторых экспертов такой высокий результат у пункта с периферией удивил, но в «Лаборатории Касперского» ничего необычного в этом не увидели. Старший менеджер по продукту Kaspersky Thin Client Михаил Левинский объяснил, что вопрос здесь упирается не только в сами устройства, но и в зрелость поддержки: у кого-то может быть старый монитор или нестандартная периферия, и важно, насколько быстро вендор готов на такие запросы реагировать. При этом, по его словам, сами операционные системы, конечно, должны нормально поддерживать проброс периферийных устройств.

Похожую мысль озвучили и в Uveon — Облачные технологии. Там обратили внимание, что часть проблем, которые пользователи приписывают именно тонким клиентам, на деле относится шире — к тому, как в компании вообще выстроена инфраструктура рабочих мест. Иными словами, не всё здесь упирается в «железку»: многое решается на уровне софта и архитектуры.

При этом в обсуждении прозвучала и осторожно позитивная нота. Генеральный директор «АМ Медиа» Илья Шабанов заметил, что заметно сократилась доля тех, кто считает главным препятствием именно стоимость внедрения. Это может говорить о том, что рынок таких решений в России постепенно взрослеет, а сами технологии перестают восприниматься как что-то слишком дорогое и экзотическое.

RSS: Новости на портале Anti-Malware.ru