Демон в короне: нашли связи Obstinate Mogwai с IAmTheKing
Мы опубликовали подробный разбор TTP группировки, которую мы называем Obstinate Mogwai. В отчете подробно разобрали их modus operandi и немного коснулись их инструментария (о нём позже ещё напишем отдельный лонгрид).
Среди прочего в статье рассказываем, как:
🫡 пришли в инфраструктуру и обнаружили, что группировка находилась там около двух лет. Это помогло нам весьма подробно проследить эволюцию их инструментария;
🫡 обнаружили артефакты применения довольно экзотических техники "T1113 - Screen Capture";
🫡 рассказали о применении уникальных бэкдоров Donnect DimanoRAT и .NET KingOfHearts.
Но главное: нашли немало пересечений с IAmTheKing, и чуть меньше — с APT31, Hafnium и Space Pirates.
Как всегда в наших отчетах, к анализу добавили вагон индикаторов.
Читать статью
Мы опубликовали подробный разбор TTP группировки, которую мы называем Obstinate Mogwai. В отчете подробно разобрали их modus operandi и немного коснулись их инструментария (о нём позже ещё напишем отдельный лонгрид).
Среди прочего в статье рассказываем, как:
Но главное: нашли немало пересечений с IAmTheKing, и чуть меньше — с APT31, Hafnium и Space Pirates.
Как всегда в наших отчетах, к анализу добавили вагон индикаторов.
Читать статью
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥24👾6⚡5🫡5❤2🍌1
Connect like there is no firewall. Securely
Змеи впадают в зимнюю спячку, из которой выходят только к середине весны. Но мы круглый год готовы к новым атакам Shedding Zmiy!
Сегодня поговорим об использованной группировкой утилите gsocket.
Утилита из набора Global Socket позволяет процессам, работающим в разных подсетях, взаимодействовать друг с другом сквозь firewall и NAT, подменяя привычное общение в рамках IP-адресов на собственный стандарт GSRN. Такой подход делает инструмент удобным выбором для удалённого управления скомпрометированной инфраструктурой.
Как обнаружить активность, специфичную для gsocket, в своей инфраструктуре?
Gsocket может выдать себя по следующим признакам:
1. Мимикрия под kernel thread через подмену argv0:
Нас интересует событие запуска процесса, где нулевой аргумент окружен квадратными скобками. Список нулевых аргументов конечен и захардкожен.
Пример события, на котором можно строить детект:
2. Использование "временных" директорий:
Обращаем внимание на запуск бинарей из
Пример события, на котором можно строить детект:
3. Использование специфичных статических переменных в коде утилиты:
Например, GSOCKET_ARGS или GS_ARGS содержат в себе ключ, который обеспечит шифрование канала между процессами.
Пример события, на котором можно строить детект:
4. Использование скрытых директорий:
Одна из директорий где закрепляется gsocket -- это
В процессе Threat Hunting'а отслеживаем запуск бинарей из таких скрытых директорий.
Пример события, на котором можно строить детект:
5. Аномалии запуска процессов:
Если пропустили первую технику, отслеживаем запуск shell от родительских процессов, скрытых под kernel thread
Пример события, на котором можно строить детект:
6*. Закрепление как сервис:
Обратим внимание, что этот артефакт не является однозначным указанием на активность gsocket, но может послужить ещё одной деталью для обогащения в руках Threat Hunt-аналитика.
Пример события, на котором можно строить детект:
Змеи впадают в зимнюю спячку, из которой выходят только к середине весны. Но мы круглый год готовы к новым атакам Shedding Zmiy!
Сегодня поговорим об использованной группировкой утилите gsocket.
Утилита из набора Global Socket позволяет процессам, работающим в разных подсетях, взаимодействовать друг с другом сквозь firewall и NAT, подменяя привычное общение в рамках IP-адресов на собственный стандарт GSRN. Такой подход делает инструмент удобным выбором для удалённого управления скомпрометированной инфраструктурой.
Как обнаружить активность, специфичную для gsocket, в своей инфраструктуре?
Gsocket может выдать себя по следующим признакам:
1. Мимикрия под kernel thread через подмену argv0:
Нас интересует событие запуска процесса, где нулевой аргумент окружен квадратными скобками. Список нулевых аргументов конечен и захардкожен.
exec -a \[kworker\] gs-netcat
Пример события, на котором можно строить детект:
{
"evt.type": "execve",
"proc.cmdline": "defunct",
"proc.exe": "[watchdogd]",
"proc.exepath": "/home/user/.config/htop/defunct",
"proc.name": "defunct"
}2. Использование "временных" директорий:
Обращаем внимание на запуск бинарей из
/tmp /var/tmp /dev/shm /run/shm
Пример события, на котором можно строить детект:
{
"evt.type": "execve",
"proc.exepath": "/dev/shm/gs-netcat",
"proc.name": "gs-netcat"
}3. Использование специфичных статических переменных в коде утилиты:
Например, GSOCKET_ARGS или GS_ARGS содержат в себе ключ, который обеспечит шифрование канала между процессами.
GS_ARGS=-s GAnzLxyo5zzTGdwYPRUVpF -li
Пример события, на котором можно строить детект:
{
"proc.env": "GS_ARGS=-s 7vAKxiEmosrpzPy6DJL19J -t _GSOCKET_SERVER_CHECK_SEC=15",
"evt.type": "execve",
"proc.cmdline": "defunct",
"proc.cwd": "/home/user/",
"proc.exe": "[watchdogd]",
"proc.exepath": "/home/user/.config/htop/defunct",
"proc.name": "defunct"
}4. Использование скрытых директорий:
Одна из директорий где закрепляется gsocket -- это
/home/user/.config
В процессе Threat Hunting'а отслеживаем запуск бинарей из таких скрытых директорий.
Пример события, на котором можно строить детект:
{
"evt.type": "execve",
"proc.cmdline": "defunct",
"proc.exepath": "/home/user/.config/htop/defunct",
"proc.name": "defunct"
}5. Аномалии запуска процессов:
Если пропустили первую технику, отслеживаем запуск shell от родительских процессов, скрытых под kernel thread
proc.parent_name:\[\*\] AND proc.name:"bash"
Пример события, на котором можно строить детект:
{
"proc.env": "SHELL=/bin/bash HISTFILE=/dev/null SHLVL=0",
"evt.type": "execve",
"proc.aname[2]": "defunct",
"proc.exepath": "/usr/bin/bash",
"proc.name": "bash",
"proc.pexe": "[watchdogd]",
"proc.pid": 159078,
"proc.pname": "bash"
}6*. Закрепление как сервис:
Обратим внимание, что этот артефакт не является однозначным указанием на активность gsocket, но может послужить ещё одной деталью для обогащения в руках Threat Hunt-аналитика.
Пример события, на котором можно строить детект:
{
"evt.arg.flags": "O_NONBLOCK|O_CREAT|O_WRONLY|O_F_CREATED",
"evt.res": "SUCCESS",
"evt.type": "openat",
"fd.name": "/lib/systemd/system/defunct.service",
"proc.cmdline": "touch /lib/systemd/system/defunct.service",
"proc.exepath": "/usr/bin/touch",
"proc.name": "touch"
}🔥28👍9❤5👾5
Нос по ветру: как наш DNS-сниффер помогает искать Blind-уязвимости
Поиск Blind-уязвимостей зачастую является нетривиальной задачей, для решения которой может потребоваться большой «зоопарк» программных средств, а также применение специального подхода, такого как получение DNS-запроса с уязвимого сервера. Популярные средства, используемые для решения этой задачи, такие как dnschef, на наш взгляд, не удобны для совместной работы большой команды, а Burp Collaborator является облачным решением, что подходит далеко не для всех проектов.
Поэтому мы разработали собственный DNS-сниффер с веб-интерфейсом, который является удобным решением для совместной работы и обладает рядом преимуществ:
🫡 объединяет возможности самого сниффера и других популярных инструментов (например, InteractSH);
🫡 позволяет гибко настраивать права доступа;
🫡 наглядно отображает результаты для последующей обработки.
Так, например, для поиска Blind-RCE можно использовать разработанное нами программное обеспечение в сочетании с полезными нагрузками, которые позволяют отправлять HTTP-запросы от имени сервера (например, популярные утилиты curl и wget). В результате возможно не только получить DNS-запрос и таким образом подтвердить наличие уязвимости, но и убедиться в наличии доступа в Интернет с уязвимого узла с помощью информации о поступивших HTTP-запросах, которая сохраняется в журнале DNS-сниффера. И все эти возможности доступны в рамках одного программного решения.
Мы используем DNS-сниффер уже на протяжении пяти лет в различных проектах, и он показал удобство применения и высокую эффективность в решении задач своего класса.
На Github уже доступны исходные коды и необходимая документация.
Поиск Blind-уязвимостей зачастую является нетривиальной задачей, для решения которой может потребоваться большой «зоопарк» программных средств, а также применение специального подхода, такого как получение DNS-запроса с уязвимого сервера. Популярные средства, используемые для решения этой задачи, такие как dnschef, на наш взгляд, не удобны для совместной работы большой команды, а Burp Collaborator является облачным решением, что подходит далеко не для всех проектов.
Поэтому мы разработали собственный DNS-сниффер с веб-интерфейсом, который является удобным решением для совместной работы и обладает рядом преимуществ:
Так, например, для поиска Blind-RCE можно использовать разработанное нами программное обеспечение в сочетании с полезными нагрузками, которые позволяют отправлять HTTP-запросы от имени сервера (например, популярные утилиты curl и wget). В результате возможно не только получить DNS-запрос и таким образом подтвердить наличие уязвимости, но и убедиться в наличии доступа в Интернет с уязвимого узла с помощью информации о поступивших HTTP-запросах, которая сохраняется в журнале DNS-сниффера. И все эти возможности доступны в рамках одного программного решения.
Мы используем DNS-сниффер уже на протяжении пяти лет в различных проектах, и он показал удобство применения и высокую эффективность в решении задач своего класса.
На Github уже доступны исходные коды и необходимая документация.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15✍7👾4🤯2👨💻1🆒1
Как обнаружить эксплуатацию CVE-2024-42640
Не так давно стало известно об уязвимости в angular-base64-upload, которая носит название CVE-2024-42640.
Данная уязвимость позволяет злоумышленнику загружать произвольные файлы на сервер. Затронуты все версии до 0.1.21.
Так что, если ваше приложение написано с использованием фреймворка Angular, то настоятельно рекомендуем проверить версии.
В ходе эмуляции данной активности команде Solar 4RAYS стало очевидно, что эксплуатация уязвимости подразумевает загрузку произвольного файла на сервер (на
Данные действия приводят к возможности выполнения произвольного кода на целевом сервере.
Поделимся детектирующей логикой, которая позволит заблокировать эксплуатацию данной уязвимости:
1. Блокировать все
2. Так же можно добавить блокирующие правила на
Не так давно стало известно об уязвимости в angular-base64-upload, которая носит название CVE-2024-42640.
Данная уязвимость позволяет злоумышленнику загружать произвольные файлы на сервер. Затронуты все версии до 0.1.21.
Так что, если ваше приложение написано с использованием фреймворка Angular, то настоятельно рекомендуем проверить версии.
В ходе эмуляции данной активности команде Solar 4RAYS стало очевидно, что эксплуатация уязвимости подразумевает загрузку произвольного файла на сервер (на
demo/server.php), к которому впоследствии можно получить доступ (и запустить!) через /uploads.Данные действия приводят к возможности выполнения произвольного кода на целевом сервере.
Поделимся детектирующей логикой, которая позволит заблокировать эксплуатацию данной уязвимости:
1. Блокировать все
POST запросы на URI содержащий demo/server.php и body передающем файл с исполняемым расширением, напримерphp|sh|exe|pl|py|jsp|asp|bash|php[0-9]+|pht|phpt|phtml|aspx
2. Так же можно добавить блокирующие правила на
GET запросы к исполняемым файлам, находящиеся в директории /uploads🔥13❤8👍7🤨1🙈1
Задачи Шредингера: сокрытие популярного Persistence из вывода утилит Windows
Так ли хорошо вы знаете, как устроен планировщик задач Windows? Внимательно ли читаете то, как меняется операционная система от версии к версии? А что, если мы скажем, что за последние 12 лет планировщик задач изменился до неузнаваемости?
В нашей новой статье мы рассказываем:
— почему
— как атакующие обходят логирование планировщика и скрывают задачи от WinAPI;
— как анализировать задачи в системе, если популярные утилиты не умеют этого делать.
Также мы готовы поделиться нашим инструментом для анализа задач – плагином для популярной утилиты Registry Explorer, который вместе с исходным кодом вы можете загрузить с нашего Github.
Плагин позволит вам:
— просмотреть действительные команд-лайны всех имеющихся в системе задач;
— подсветить задачи, которые могут быть скрыты от WinAPI.
Читать статью
Так ли хорошо вы знаете, как устроен планировщик задач Windows? Внимательно ли читаете то, как меняется операционная система от версии к версии? А что, если мы скажем, что за последние 12 лет планировщик задач изменился до неузнаваемости?
В нашей новой статье мы рассказываем:
— почему
C:\Windows\System32\Tasks не является достоверным источником данных о задачах;— как атакующие обходят логирование планировщика и скрывают задачи от WinAPI;
— как анализировать задачи в системе, если популярные утилиты не умеют этого делать.
Также мы готовы поделиться нашим инструментом для анализа задач – плагином для популярной утилиты Registry Explorer, который вместе с исходным кодом вы можете загрузить с нашего Github.
Плагин позволит вам:
— просмотреть действительные команд-лайны всех имеющихся в системе задач;
— подсветить задачи, которые могут быть скрыты от WinAPI.
Читать статью
🔥20👍8❤7🥰1👻1👾1