Эксперты 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.

Правда ли MAX нельзя отвязать от Госуслуг: что показала проверка

В соцсетях разошлась тревожная информация о том, что если привязать мессенджер MAX к аккаунту на «Госуслугах», то потом вернуть обычное подтверждение входа по СМС уже не получится. Но, судя по доступным данным, это не так.

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

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

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

Если MAX уже подключён, в настройках это отображается отдельно: система показывает, что вход осуществляется по паролю и одноразовому коду из мессенджера. После этого пользователь может выбрать другой способ подтверждения личности — например, СМС, одноразовый код TOTP или биометрию.

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

Иначе говоря, история о том, что после привязки MAX от него уже нельзя отказаться, пока не подтверждается. Похоже, в этот раз речь идёт скорее о типичном преувеличении, чем о реальной проблеме сервиса.

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