Телеграм канал «ESCalator»

⚠️ Включил отладку по Wi-Fi — получил Mamont

В начале мая на устройствах Android была обнаружена уязвимость CVE-2026-0073, которая позволяет удаленно выполнять команды на мобильном устройстве без подтверждения со стороны пользователя.

Уязвимы устройства с Android 11 и выше, на которых включена функция отладки по Wi-Fi.

Функция отладки по Wi-Fi является легитимной — она позволяет подключаться к мобильному устройству для установки, тестирования приложений и создания резервных копий (скриншот 1). Для использования этой функции необходимо осуществить сопряжение с ПК и подтвердить доверенные связи. CVE-2026-0073 дает возможность пропустить этап подтверждения связей и сразу взаимодействовать с устройством.

🧐 Мы решили изучить, как далеко может зайти злоумышленник при эксплуатации данной CVE.

Схема заражения устройства:

1️⃣ Пользователь с включенной отладкой по Wi-Fi подключается к незащищенной Wi-Fi-сети.

2️⃣ Злоумышленник, находясь в этой же сети, сканирует ее на наличие адресов с открытыми портами для отладки по ADB (скриншот 2).

3️⃣ Проэксплуатировав CVE-2026-0073, злоумышленник получает доступ к командной строке мобильного устройства и может выполнять различные команды на устройстве (скриншот 3):

➖ получать доступ к спискам контактов, звонков, SMS-сообщений и установленных приложений;
➖ удалять и устанавливать приложения без ведома пользователя;
➖ повышать привилегии установленного приложения, выдав ему специальные разрешения на устройстве: специальные возможности (Accessibility Services) и доступ к уведомлениям (Notification Access).

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

4️⃣ Происходит кража пользовательских данных и их отправка на серверы злоумышленников.

Почему так происходит?

1️⃣ Уязвимость находится в демоне Android Debug Bridge — adbd: в функции проверки TLS-сертификатов adbd_tls_verify_cert в auth.cpp.

2️⃣ Атака затрагивает режим Wireless Debugging / ADB-over-TCP, где подключение между ПК и устройством строится через mutual TLS: Android проверяет клиентский сертификат подключающегося хоста.

3️⃣ В нормальном режиме adbd сравнивает публичный ключ сертификата клиента с ранее доверенным ключом, сохраненным после ADB pairing.

4️⃣ Ошибка возникает из-за неправильной обработки результата функции EVP_PKEY_cmp: код считает любое ненулевое значение успешным совпадением ключа.

5️⃣ Злоумышленник подменяет TLS-сертификат, используя ключ другого типа (например, EC/Ed25519 вместо RSA). В таком случае EVP_PKEY_cmp возвращает -1 («разные типы ключей»), но уязвимый код воспринимает это как успешную проверку.

6️⃣ Происходит обход mutual TLS-аутентификации: adbd ошибочно считает атакующего доверенным ADB-хостом.

7️⃣ После обхода проверки атакующий получает удаленный доступ к ADB shell без взаимодействия с пользователем устройства.

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

🛠 Как защитить ваши устройства:

1️⃣ Выключайте функцию отладки по Wi-Fi, когда она не используется. Ввиду особенности эксплуатации CVE-2026-0073 подвержены только устройства с включенной отладкой по Wi-Fi. Эта функция по умолчанию выключена, поэтому у обычных пользователей риск минимален.

2️⃣ Не включайте отладку по Wi-Fi в недоверенных сетях.

3️⃣ Устанавливайте обновления ОС на постоянной основе: патчи безопасности за май 2026 уже доступны на многих устройствах.

4️⃣ Настройте безопасность рабочей и личной Wi-Fi-сети: изолируйте клиентов и заблокируйте доступ по недоверенным портам.

5️⃣ Будьте внимательны к уведомлениям, которые приходят на ваше устройство. При подключении к отладке по Wi-Fi на экране устройства появляется уведомление о подключении стороннего устройства (скриншот 5).

Внимание к деталям сделает ваши устройства безопаснее.

#dfir #mobile #android #CVE
@ptescalator

Бриллиант почти не виден 💎

В ходе анализа дампов PT ESC IR периодически сталкивается с новыми семействами ВПО, которые не обнаруживаются по известным индикаторам и YARA-сигнатурам и хорошо мимикрируют под легитимные или системные файлы.

При наличии некоторого количества дампов машин со схожими ОС, содержащих результаты файлового сканирования, для поиска могут использоваться «нечеткие» (fuzzy) хэши, применение которых традиционно ограничено задачами поиска файлов, относительно схожих с ранее выявленными образцами ВПО.

🧐 На первом скриншоте показано распределение исполняемых файлов nix-подобной системы с учетом размера файлов (масштаб «обратно-логарифмический»: большие файлы системы расположены ближе к центру, малые — на периферии). Для группировки файлов с учетом их размера и сходства содержимого (необходимо учитывать, что данные переменные не всегда являются независимыми — например, при использовании алгоритма TLSH) потребуется провести процедуру «кластеризации» с учетом матрицы «перекрестных расстояний» между всеми (N) файлами системы, которая будет иметь размер (N^2).

Очевидно, что для сокращения размера данной матрицы возможно ввести разбиение диапазона размеров файлов одной либо нескольких совместно анализируемых систем — весь диапазон размеров может быть представлен как совокупность непересекающихся отрезков [x-ax;x+ax], где a<1, а x — центральная точка отрезка. Опыт показывает, что такое разделение позволяет, как правило, получить менее сотни размерных «поясов» при значении a=0.1. При дальнейшем анализе в пределах отдельных «поясов» количество образцов будет существенно меньше исходного общего количества.

Анализ «аномальности» образцов в пределах отдельного «пояса» возможно произвести с учетом различных факторов — среднего расстояния до остальных образцов, количества образцов, схожих с данным в пределах заданного порогового значения и т.п., за исключением случаев, когда в пределах «пояса» оказывается совсем малое (например, менее 10) количество файлов — в таком случае можно считать, что все они являются «условно аномальными».

Финальным этапом подобного анализа является выявление в пределах полученных для каждой из анализируемых систем «аномальных» групп файлов, которые удовлетворяют следующим критериям:

1️⃣ имеют малое количество схожих образцов либо высокое среднее расстояние до остальных образцов (для формализации можно задаться верхней половиной динамического диапазона);

2️⃣ не имеют в пределах одной системы файлов с идентичным именем, но отличным путем (что позволяет фильтровать системные файлы nix-подобных систем);

3️⃣ имеют малое количество файлов с аналогичным путем/именем на совместно анализируемых системах (или не имеют аналогов вовсе — то есть не являются обязательными для функционирования системы).

👀 Результатом подобного анализа является картина, показанная на втором скриншоте: размер файлов снова в «обратно-логарифмическом» масштабе, «максимально отличающиеся» файлы в пределах «размерного пояса» стремятся к угловой координате π радиан, а минимально отличающиеся — к 0. «Условно аномальные», т.е. практически уникальные по размеру файлы, имеют угловую координату 3π/2.

Общее количество определенных «аномалий» составляет для различных систем от 0,7% до 8% от исходного количества анализируемых исполняемых файлов, что позволяет проводить дальнейший анализ в ряде случаев просто «глазами» — из исходных тысяч файлов остается около полусотни.

Первый же «существенно отличающийся» файл в данном случае действительно представляет собой ВПО, причем для ансамбля из 12 анализируемых систем аналогичный образец уверенно обнаруживается еще на одной машине, а дальнейший поиск при «TLSH-расстоянии» не более 70 единиц позволяет выявить еще 5 образцов на различных машинах ансамбля с одинаковыми путями — все они принадлежат к одному семейству и реализуют закрепление ВПО посредством использования system-generators.

#tip #ir #malware
@ptescalator

你好! На связи группа Supply Chain Security 🩷

Мы сканируем опенсорс в реальном времени в поисках вредоносного кода. А также ответственные в ESCalator за публикации про интересности в Python Package Index и NPM 🏃‍♀️

Рады сообщить о коллаборации с парнями из PT Fusion и выпуске фидов по найденным угрозам в формате OSV (анонс). Там есть информация не только по вредоносным релизам, но и, например, по удаленным пакетам, что тоже является одним из факторов риска, который нужно учитывать при дальнейшем использовании таких пакетов.

Если в вашей компании есть разработка, и вы беспокоитесь о ее безопасности, то будем рады видеть вас в рядах наших пользователей 🤗

#scs
@ptescalator

Злоумышленник публикует .bash_history смотреть без регистрации и смс 😱

Команда Supply Chain Security отправила отчет администрации реестра npm о занятной маленькой кампании против Apple, среди них:

• apple-infra-network-v2 (170 скачиваний на момент репорта)
• apple-infra-final-escape (326 скачиваний)
• apple-infra-gcp-leak (165 скачиваний)
• apple-infra-ultimate-bypass (153 скачивания)
• agents-a365-runtime — мимикрия под пакет @microsoft/agents-a365-runtime (447 скачиваний)
• apple-security-internal-scanner-v3 (185 скачиваний)
• apple-coredata-internal-service (367 скачиваний)

Часть проектов первой волны лаконична и состоит из одного файла package.json весом менее 1 килобайта (скриншот 1).

Bash-однострочник:
🌟Получает содержимое /etc/resolv.conf — DNS-конфигурацию устройства.
🌟Проверяет возможность разрезолвить домен internal.apple.com через nslookup / host.
🌟Забирает записи ARP-кеша (таблицы сопоставлений ip-адресов на MAC-адреса).
🌟Обращает внимание на следующие переменные окружения по маске: *PROXY*, *TENCENT*, *REGION*, *ZONE*.

Смысл переменных окружения:

PROXY* — забрать настройки корпоративных прокси (HTTP_PROXY, HTTPS_PROXY и другие). Там может попасться значение наподобие http://proxy[.]departmentname.companyname[.]local, позволяющее детальнее идентифицировать жертву;

TENCENT* — вероятно признак инфраструктуры Tencent Cloud

REGION и ZONE — переменные окружения, в которой может храниться местоположение облака, например eu-west-1

Этот отчет обрамляется текстом --- NETWORK PIVOT AUDIT --- и --- AUDIT SELESAI --- (индонезийский «Отчет окончен») и отправляется автору пакета.

———

Легко можно поверить, что это пентест- либо багбаунти-активность против Apple: аккуратно собирается отпечаток жертвы, без информации, которая представляла бы коммерческую ценность.

Однако часть дальнейших релизов имеют занятную логику (скриншот 2):

1️⃣ Попытка украсть значение одной из переменных окружения в следующем порядке: NPM_TOKEN, NODE_AUTH_TOKEN, GITHUB_TOKEN, NPM_AUTH_TOKEN. Если их нет, то попробуем взять authToken из файла ~/.npmrc

2️⃣ Надеясь, что у окружения есть доступ к внутреннему хранилищу npm-пакетов, попытка скачать пакет apple-app-store-server-library, пересобрать его с новой версией и опубликовать в глобальном npmjs.org

Our honest reaction на второй пункт: 🤔 Ну и индонезийских комментариев стало больше.

———

По мере развития кампании злоумышленник перестал пускать в глаза пыль благих намерений и стал просто красть все интересные переменные окружения, а также забирать токены Azure IMDS.

В какой-то момент автор, тестируя логику публикации пакета от имени жертвы, случайно упаковал в один из своих релизов все свои скрипты, node-логи и даже .bash-history 🤔 (скриншот 3).

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

echo 'длинный валидный однострочный package.json c инфостилером в preinstall-логике' > package.json && npm publish

В bash history также попали комментарии. Их мог оставить сам злоумышленник, копируя команды из диалога с LLM, а мог и сам агент:

// Masukin ini ke dalam script preinstall lu
# Nyari di mana lokasi instalasi npm lo
# Biasanya hasilnya di /usr/bin/npm. Sekarang kita liat isinya:

В переводе на английский:

// Enter this into your preinstall script
# Find your npm installation location
# Usually, it's in /usr/bin/npm. Now let's look at the contents:

———

На дворе 2026 год. Фреймворки для автопентеста уже существуют. Blue team тоже не отстает и предлагает свои решения по использованию LLM в тех же SIEM. Пройдет время, и нам, человекам, останется только с попкорном смотреть за этим противостоянием 🍿

#npm #ti #scs
@ptescalator

Мы тут больше про ML, но чтобы что-то делать в ИБ приходится разбираться как там всё устроено. SOC, аналитики, ночные смены, вот это всё.

И как-то поймали себя на мысли: читать про MITRE и смотреть отчёты про APT-кампании — это понятно. А вот попробовать на собственной шкуре, каково это — сидеть в три ночи и думать «это атака через запуск PowerShell из ворда у бухгалтера или просто кто-то макросы открыл» — ну такое, попробовать особо негде.

Поэтому Тимур Смирнов сел и сделал маленькую браузерную игру — Dwell Time.
Три ночные смены, 30 алертов, ты SOC-аналитик первой линии. Тыкаешь что делать: разрешить, заблокировать, эскалировать или копнуть дальше. В конце говорят, где налажал и дают ссылки почитать про каждую технику, чтобы реально что-то выучить.

Игра пока совсем простая, уровня «вход в SOC». Но если зайдёт — хочется докрутить до прикладной штуки, которая покрывала бы и threat hunting, и pentest, и detection engineering. Чтобы можно было постепенно прокачиваться по разным сферам ИБ через один сюжет в игровой форме🎮

Бесплатно, в браузере, минут на 15-20.

Если попробуете — интересно ваше мнение. Что зашло, что не понятно, какие сферы ИБ хотелось бы видеть дальше. Пишите в комменты.

https://sucky-charm.itch.io/dwell-time