Вступление

Идея написать блог о том, как злоумышленники используют для перемещения в инфраструктуре жертвы возможности службы Windows Remote Management (WinRM) (Т1021.006), возникла у меня еще в январе 2022 года. И виной тому стали не затянувшиеся новогодние праздники и наличие свободного времени, как может показаться, а как раз наоборот. В тот момент криминалисты F.A.C.C.T. столкнулись с очередным «праздничным» всплеском кибератак на российские компании, и в процессе реагирования на инцидент у одного из наших клиентов обнаружили интересный кейс, о котором хочу подробно рассказать.

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

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

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

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

Для перемещений по сети злоумышленники преимущественно использовали протокол удаленного рабочего стола (Remote Desktop Protocol), а после того как он был запрещен администраторами, переключились на WinRM. Использование злоумышленниками данной службы и наличие недокументированного и ранее не описанного артефакта, который был впервые обнаружен в ходе нашего реагирования, позволили выявить и дополнить список скомпрометированных узлов и лишить злоумышленников возможности взаимодействовать с сетью клиента.

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

Что такое WinRM

— это название как службы, так и протокола Windows, разработанного прежде всего для IT-специалистов. Она используется для удаленного управления, администрирования и мониторинга систем.

WinRM была впервые представлена в операционной системе Windows Vista в 2006 году и с тех пор интегрирована во все последующие версии Windows.

Краткая техническая справка

WinRM является реализацией протокола WS-Management, предназначенного для управления различными устройствами при помощи SOAP-запросов.

  • Служба WinRM запускается и работает в контексте процесса svchost.exe -k NetworkServices -p -s WinRM.
  • Начиная с версии 2.0 WinRM, слушатель службы %systemroot%\system32\WsmSvc.dll по умолчанию прослушивает порты 5985/TCP для HTTP-соединений и 5986/TCP для HTTPS-соединений. В Windows Server 2008 / Windows 7 использовались 80/TCP и 443/TCP соответственно.
  • WinRM поддерживает следующие механизмы аутентификации:
    • Basic — для аутентификации клиента и авторизации его запросов к серверу с помощью базовых HTTP-заголовков. Этот механизм аутентификации небезопасный и не рекомендуется к использованию, так как передача учетных данных происходит в явном виде.
    • Digest — это механизм аутентификации, который использует HTTP-заголовки для передачи аутентификационных данных между клиентом и сервером с помощью хеш-функции.
    • NTLM — для аутентификации клиента по имени пользователя и паролю, если клиент и сервер не являются членами одного домена или если применяется схожий механизм аутентификации.
    • Kerberos — для взаимной аутентификации между клиентом и сервером в домене Windows. Клиент и сервер должны быть членами одного домена.
    • SSL-сертификаты — для проверки легитимности сервера и клиента при использовании протокола HTTPS. Этот механизм аутентификации обеспечивает безопасность передаваемых данных посредством шифрования.
    • CredSSP — для делегирования учетных данных на сервер, который может их использовать для выполнения задач на удаленных компьютерах.
  • WinRM позволяет создать список доверенных узлов.
  • WinRM позволяет устанавливать продолжительные интерактивные сеансы с удаленным хостом, выполнять отдельные команды, скрипты, а также запросы WMI (CIM).

Выполнение PSRP, WinRS, CIM over WinRM

Перед тем как мы поговорим о том, какие артефакты могут нам помочь в расследовании инцидентов, хотелось бы рассказать об основных способах выполнения команд на хостах при помощи WinRM.

Как уже ранее говорилось, WinRM позволяет устанавливать интерактивные сессии и выполнять различные команды. При помощи штатных средств Windows это можно сделать несколькими способами:

  • PowerShell Remoting (PSRP)
    Например:
    Invoke-Command -ComputerName <RemoteComputer> -Scriptblock {EVIL.exe}
    Enter-PSSession -ComputerName <RemoteComputer> и др.
  • Windows Remote Shell (WinRS)
    Например:
    winrs -r: <RemoteComputer> EVIL.exe
  • WMI (CIM) over WinRM (начиная с PowerShell версии 3.0 добавлены командлеты CIM, работа которых осуществляется через WinRM).
    Например:
    Invoke-CimMethod -ClassName Win32_Process -MethodName «Create» -ComputerName <RemoteComputer> -Arguments @{CommandLine=’EVIL.exe’} и др.

Процессы, порождаемые PSRP, WinRS, CIM over WinRM

В зависимости от выбранного способа выполнения WinRM передаст управление DCOM-серверу (Distributed Component Object Model), который проведет запуск одного из трех провайдеров:

  1. %systemroot%\system32\wsmprovhost.exe (Microsoft Web Services Management Provider Host);
  2. %systemroot%\system32\winrshost.exe (Microsoft Windows Remote Shell Host);
  3. %systemroot%\system32\wbem\wmiprvse.exe (Windows Management Instrumentation Provider Host).

Таким образом, процесс того или иного провайдера будет запущен в контексте процесса svchost.exe -k -DcomLaunch -p, который, в свою очередь, станет родительским для порождаемой полезной нагрузки.

На рис. 1, 2 и 3 представлены цепочки процессов, возникающие при использовании PowerShell Remoting, Windows Remote Shell, а также при выполнении CIM-запросов.

Инструменты Red Team

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

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

Теперь рассмотрим небольшую эмуляцию, проделанную при помощи Evil-WinRM, и проведем реконструкцию активности на хосте по записям журналов событий.

В рамках данной эмуляции мы подключились к контроллеру домена, выполнили команды whoami, hostname, загрузили в него файл evil.exe и запустили его (рис. 4).

Действия с хоста атакующего

Рис. 4. Действия с хоста атакующего

В данном случае, при реконструкции действий атакующего, в журналах атакуемой ОС мы обнаружим список характерных событий, указывающих на использование PowerShell Remoting. Наиболее информативные из них, по моему мнению, представлены ниже.

Описание

ID события

1. События с назначенными привилегиями и нового входа с Logon ID, именем пользователя и адресом удаленного хоста 4672, 4624 (Security.evtx)
2. Событие запуска провайдера wsmprovhost.exe и оболочки WS-Man 4688 (Security.evtx)

91 (Microsoft-Windows-WinRM%4Operational.evtx)

3. События запуска процессов whoami.exe, hostname.exe, порождаемых от провайдера (оболочки) wsmprovhost.exe 4688 (Security.evtx)

400, 800 (Windows PowerShell.evtx)

4103, 4104 (Microsoft-Windows-PowerShell%4Operational.evtx)

4. Вызовы командлетов и создание блоков скрипта при доставке полезной нагрузки evil.exe 4103, 4104 (Microsoft-Windows-PowerShell%4Operational.evtx)
5. События запуска процесса evil.exe, порождаемого от провайдера (оболочки) wsmprovhost.exe 4688 (Security.evtx)

800 (Windows PowerShell.evtx)

4103, 4104 (Microsoft-Windows-PowerShell%4Operational.evtx)

6. Событие остановки оболочки wsmprovhost.exe 403 (Windows PowerShell.evtx)
7. Событие выхода 4634 (Security.evtx)

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

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

Так, однажды погрузившись в исследование, нами был обнаружен параметр реестра WSManSafeClientList, который позволяет не только выявить технику продвижения, но и ряд потенциально эксплуатируемых атакующими узлов (рис. 5).

Список «безопасных» клиентов

Рис. 5. Список «безопасных» клиентов

Список «безопасных» клиентов

Параметр реестра WSManSafeClientList появился в системах с момента появления Windows 8 и располагается по пути HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\SafeClientList. В него сохраняются IP-адреса успешно подключавшихся с помощью WinRM клиентов. А запись в него осуществляется слушателем службы WsmSvc.dll.

Проведенными исследованиями установлено, что:

  • параметр WSManSafeClientList отсутствует на хостах, к которым подключения не осуществлялись (в том числе когда служба WinRM сконфигурирована и запущена);
  • в параметр WSManSafeClientList записываются HEX-значения адресов IPv4 и IPv6, ранее подключавшихся при помощи WinRM;
  • максимальный размер параметра составляет 160 байт и может содержать до 10 уникальных IP-адресов;
  • размер каждой записи составляет 16 байт (рис. 6).
Пример 10 записей параметра WSManSafeClientList и их интерпретация

Рис. 6. Пример 10 записей параметра WSManSafeClientList и их интерпретация

Запись адресов в параметр WSManSafeClientList осуществляется спустя 15 минут после успешного подключения с адреса, которого нет среди ранее записанных адресов, или в момент остановки службы.

В случае если адрес последнего подключившегося хоста уже имеется в списке, то порядок адресов в параметре не меняется и запись в него не производится.

При превышении количества записей в параметре первый адрес в списке будет удален, а новый — добавлен в конец списка (рис. 7).

Пример 10 записей параметра WSManSafeClientList после превышения лимита записей

Рис. 7. Пример 10 записей параметра WSManSafeClientList после превышения лимита записей

Выводы и рекомендации

Несмотря на то, что WinRM — не самый часто используемый инструмент, возможности, предоставляемые атакующим службой WinRM и тривиальность детектирования традиционных методов продвижения по сети, обусловят все большее распространение данной техники.

Для защиты от подобных атак мы в очередной раз рекомендуем следующее:

  • Регулярно осуществляйте установку критических обновлений операционной системы и используемых программных продуктов.
  • Обеспечьте надежную защиту средств удаленного доступа в ИТ-инфраструктуру, в том числе с помощью мультифакторной аутентификации.
  • Глубина хранения журналов событий операционной системы и средств защиты информации должна быть не менее 3 месяцев.
  • Настройте сбор Windows событий:
    1. успешных и неуспешных попыток входа;
    2. включение/отключение учетных записей, их блокировка;
    3. создание локальных и доменных учетных записей;
    4. добавление пользователей в группы, особенно предоставляющие повышенные привилегии;
    5. создание служб, процессов и задач в планировщике;
    6. изменение доменных и локальных политик безопасности;
    7. выполнение команд, при помощи различных командных интерпретаторов;
    8. критические срабатывания встроенного защитника Windows (Windows Defender);
    9. доступа к объектам общей сетевой папки;
    10.  очистки журналов событий.
  • Обеспечить защиту конечных устройств поможет решение F.A.C.C.T. Managed XDR, а  Attack Surface Management — позволит контролировать уровень информационной безопасности инфраструктуры организации.
  • Чтобы сформировать надежную, эффективную на практике защиту потребуются не только временные и материальные затраты, но и четкий список того, что необходимо улучшать или строить заново для успешного противостояния современным угрозам. Составить такой перечень поможет комплекс услуг Лаборатории компьютерной криминалистики компании F.A.C.C.T. по оценке готовности компании к реагированию на инциденты, а также проведение киберучений в формате Purple Teaming.

Реагирование на инциденты от F.A.C.C.T.

Если ваша компания подверглась кибератаке важно как можно скорее обратиться к экспертам по реагированию на инциденты