На пентесте инфраструктуры логистической компании основная цель была Active Directory, но первый foothold случился через Mattermost - самохостируемый инстанс с дефолтным incoming webhook, через который бот CI/CD-пайплайна отправлял deploy-логи с AWS-ключами в plaintext. Три строки в
curl, один вызов API - и initial access в облако появился задолго до того, как я добрался до контроллера домена.Корпоративные мессенджеры - одна из самых недооценённых поверхностей атаки. Компании вкладываются в WAF и EDR, а переписку аудируют в последнюю очередь. Если вообще аудируют. Ниже - методология, которую я применяю при аудите безопасности мессенджеров, с конкретными инструментами, командами и ограничениями каждой техники.
Место мессенджера в цепочке атаки
Прежде чем разбирать конкретные техники пентеста - зачем атакующему вообще нужен мессенджер? В терминах MITRE ATT&CK корпоративные коммуникации фигурируют минимум в трёх тактиках: Подробнее - в нашем статье о пентест мобильных приложений.- Initial Access - фишинг через сервис (Spearphishing via Service, T1566.003): вместо email атакующий отправляет вредоносную ссылку или файл через Slack, Teams или внутренний чат. Контент-фильтрация там на порядок слабее почтового шлюза
- Credential Access - извлечение учётных данных из сообщений (Chat Messages, T1552.008): пароли, API-токены, SSH-ключи, которые сотрудники пересылают друг другу в чате
- Collection - сбор данных из мессенджеров (Messaging Applications, T1213.005): выгрузка переписки, файлов, контактов после компрометации учётной записи
При пентесте мессенджера работа идёт на пересечении нескольких доменов: веб-приложение (REST API), мобильный клиент, десктоп (Electron), сетевой трафик и криптография. Это и определяет набор инструментов.
Recon - fingerprinting до первого запроса к мессенджеру
Определение класса и версии
Первый шаг - понять, что перед вами. Безопасность корпоративных коммуникаций радикально зависит от класса решения, и подход к каждому отличается.| Класс | Примеры | Что доступно для аудита | Типичные находки |
|---|---|---|---|
| SaaS (облачный) | Slack, Teams | API, интеграции, конфигурация workspace | Избыточные OAuth-скоупы, утечки токенов в логах |
| Self-hosted | Mattermost, Rocket.Chat, Matrix/Synapse | Сервер целиком + API + конфигурация | Дефолтные credentials, открытые admin-панели, устаревшие версии |
| Custom (собственная разработка) | Внутренние решения | Полный стек | Всё вышеперечисленное + логические уязвимости бизнес-процессов |
[Применимо: grey box / white box, внешний и внутренний пентест]
Для self-hosted решений recon начинается стандартно:
nmap -sV по целевому хосту покажет версию Nginx/Apache и косвенно - продукт за ним. Mattermost отдаёт характерный заголовок X-Version-Id. Rocket.Chat раскрывает версию через endpoint /api/info без аутентификации. Matrix/Synapse - через /_matrix/federation/v1/version.Ограничение: для SaaS-решений (Slack, Teams) серверный fingerprinting бесполезен - вы работаете с инфраструктурой вендора. Фокус целиком смещается на конфигурацию workspace и интеграции.
Анализ OAuth-интеграций и ботов
В каждом корпоративном мессенджере живут боты и интеграции - одна из самых жирных поверхностей атаки. Почему:- Webhook URL часто содержит токен прямо в URL (Slack incoming webhooks:
https://hooks.slack.com/services/T00/B00/XXXX) - Боты получают OAuth-скоупы, избыточные для задачи: бот для нотификаций с правом
channels:readна все приватные каналы - Токены ботов не ротируются годами и не покрываются MFA
На этом этапе запрашиваем у заказчика (grey box) или находим самостоятельно:
- Список установленных приложений/ботов и их OAuth-скоупы
- Webhook URL (поиск в репозиториях, CI/CD-конфигах, переменных окружения)
- Сервисные учётные записи мессенджера
Анализ трафика мессенджеров
Требования к окружению
- ОС: Kali Linux 2024.x+ или macOS с brew
- RAM: минимум 8 ГБ (mitmproxy + Wireshark одновременно)
- Инструменты: mitmproxy 10.x+ (активно поддерживается, OSS), Wireshark 4.x+ (активно поддерживается, OSS), собственный CA-сертификат
- Сеть: контролируемый сегмент - физический доступ к Wi-Fi или VLAN, режим online
- Права: root/sudo для перехвата трафика, письменное согласие заказчика на перехват
Перехват через mitmproxy
Большинство мессенджеров используют TLS 1.2+ для транспорта, но десктопные Electron-клиенты (Slack, Mattermost, Teams) и мобильные приложения по-разному реализуют certificate pinning. Это техника Network Sniffing (T1040, Credential Access / Discovery) по MITRE ATT&CK.[Применимо: внутренний пентест, grey box с доступом к устройству]
Bash:
# Запуск mitmproxy с фильтром по домену мессенджера
mitmproxy --mode transparent --set block_global=false -w messenger_traffic.flow --view-filter "~d mattermost.corp.local | ~d slack.com"- Токены в заголовках - Bearer-токены в
Authorization, cookie с session ID. Передаются ли они по незащищённым каналам при fallback? - API-вызовы без аутентификации - некоторые эндпоинты self-hosted решений доступны без токена (получение публичных каналов, список пользователей)
- Метаданные - даже при E2EE метаданные (кто с кем, когда, объём данных) идут в открытом виде и доступны при анализе трафика мессенджеров
Ограничения: certificate pinning в мобильных клиентах Slack и Teams делает прозрачный перехват невозможным без модификации приложения (Frida). Десктопные Electron-клиенты обычно доверяют системному хранилищу сертификатов - pinning там встречается реже.
Пентест API мессенджера - уязвимости корпоративных мессенджеров
Webhook-инъекции и утечка токенов
Webhook - входная точка, которую разработчики защищают хуже всего. Типичный сценарий: CI/CD (Jenkins, GitLab CI) отправляет уведомления в канал мессенджера через incoming webhook.Что проверять в рамках тестирования безопасности мессенджеров:
- Аутентификация webhook - принимает ли endpoint произвольные POST-запросы без подписи? Mattermost incoming webhooks по умолчанию не проверяют payload signature
- Формат сообщений - можно ли через webhook отправить сообщение с произвольным
usernameиicon_url, имитируя системные уведомления (social engineering внутри мессенджера) - Утечка webhook URL - поиск в публичных репозиториях, Docker-образах, CI/CD-конфигурациях. Один найденный webhook URL = возможность отправлять сообщения от имени бота в любой канал
Broken Access Control в API чатов
Для self-hosted мессенджеров тестирование API проводится через Burp Suite (коммерческий, активно поддерживается PortSwigger) по методологии OWASP WSTG, но с мессенджер-специфичными проверками:- IDOR на сообщения - подмена
message_idилиchannel_idв API-запросе. Можно ли прочитать сообщения чужого приватного канала? - Эскалация ролей - может ли обычный пользователь через API назначить себе роль
adminилиchannel_admin? - Экспорт данных - API для compliance-экспорта переписки доступен только администраторам? Или любой пользователь с валидным токеном способен выгрузить историю всех каналов?
Ограничение: SaaS-решения (Slack, Teams) не позволяют тестировать серверную логику - баги ищутся только на уровне API-вызовов с позиции пользователя. Фаззинг серверных эндпоинтов Slack приведёт к бану IP и нарушению Terms of Service.
Проверка шифрования мессенджеров: криптографический аудит
End-to-end encryption - что реально проверять
Анализ защищённости мессенджеров на уровне E2EE - отдельная дисциплина. Тут сканер не поможет. По классификации OWASP ASVS (уровни 2-3) криптографические проверки включают валидацию конкретных реализаций, а не просто галочку "шифрование включено".Ключевые вопросы при аудите E2EE:
- Какой протокол? Signal Protocol (Double Ratchet) - стандарт де-факто, используется в WhatsApp, Signal, частично Matrix (Olm/Megolm). Но реализация может расходиться со спецификацией
- Обмен ключами - TOFU (Trust On First Use) без верификации fingerprint открывает возможность MITM при первом подключении
- Что именно шифруется? Тело сообщения - да. А метаданные (отправитель, получатель, время, размер)? Вложения? Реакции?
- Групповые чаты - sender keys vs pairwise encryption. При добавлении нового участника пересоздаются ли сессионные ключи?
Downgrade-атаки на протокол
[Применимо: внутренний пентест с контролем сетевого сегмента]Если мессенджер поддерживает и E2EE, и обычный режим, проверяется:
- Можно ли принудительно переключить сессию на не-E2EE (downgrade)
- Уведомляется ли пользователь при смене ключа собеседника
- Работает ли E2EE при переключении между Wi-Fi и мобильной сетью без разрыва
Ограничение: полноценный криптоаудит протокола требует white box доступа к исходному коду. В black box и grey box оценивается только поведение клиента - наличие downgrade, реакция на подмену ключей, утечки в трафике.
Извлечение артефактов: от SQLite до Frida
Локальное хранилище десктопных клиентов
Десктопные клиенты мессенджеров (Electron-приложения Slack, Mattermost, Teams) хранят данные локально. На скомпрометированном хосте это золотая жила для утечки данных через мессенджеры.Типичные пути хранения:
- Slack:
~/.config/Slack/Local Storage/leveldb/(Chromium LevelDB) - Mattermost:
~/.config/Mattermost/- SQLite-база с историей сообщений - Teams:
~/.config/Microsoft/Microsoft Teams/- cookies, tokens в LevelDB
Bash:
# Извлечение токенов из LevelDB Slack на GNU/Linux
strings ~/.config/Slack/Local\ Storage/leveldb/*.ldb | grep -oP 'xoxc-[a-zA-Z0-9-]+'xoxc-, xoxb-, xoxp- для Slack) позволяют обращаться к API от имени пользователя без пароля и без MFA. По MITRE ATT&CK это Valid Accounts (T1078, Initial Access / Persistence) - украденный токен функционально эквивалентен легитимной сессии.Ограничения: в Windows-среде с настроенным DPAPI токены могут быть зашифрованы ключом пользователя - потребуется DPAPI-расшифровка, что добавляет шаг к цепочке. На macOS - Keychain Access с паролем пользователя.
Динамический анализ мобильных клиентов
[Применимо: grey/white box, мобильное приложение мессенджера, рутованное устройство или эмулятор]Frida (активно поддерживается, OSS) позволяет перехватывать вызовы криптографических функций в рантайме и проверять, действительно ли сквозное шифрование работает как заявлено.
JavaScript:
// Frida hook: перехват вызова шифрования в мобильном клиенте
// Имя функции зависит от конкретного приложения - это пример для демонстрации подхода
Interceptor.attach(Module.findExportByName("libsignal.so", "signal_encrypt"), {
onEnter: function(args) {
console.log("[*] signal_encrypt called");
console.log(" plaintext len: " + args[1].toInt32());
}
});libsignal.so не загружается или отправка идёт через обычный HTTP POST - E2EE не работает для этого типа сообщений. Бывает, что текстовые сообщения шифруются, а вложения летят в чём мать родила.Ограничение: Frida требует root/jailbreak на устройстве. На iOS с актуальным jailbreak ситуация нестабильная (мягко говоря). На Android рекомендуется эмулятор с API level, соответствующим целевому приложению.
Выбор вектора при пентесте мессенджера
Decision tree: какой вектор выбрать в зависимости от условий аудита корпоративного мессенджера.| Условие | Вектор | Основной инструмент |
|---|---|---|
| Self-hosted, grey box, есть учётные записи разных ролей | API-тестирование: IDOR, privilege escalation, export | Burp Suite + методология OWASP WSTG |
| Доступ к рабочей станции сотрудника | Извлечение токенов из SQLite/LevelDB | strings, sqlite3, ручной анализ |
| Контроль сетевого сегмента (внутренний пентест) | Перехват трафика, downgrade-атаки | mitmproxy, Wireshark |
| Root-доступ к мобильному устройству | Анализ E2EE-реализации, обход pinning | Frida |
| Только внешний доступ (black box, SaaS) | Webhook-интеграции, OAuth-скоупы, phishing через сервис | Burp Suite, OSINT по утечкам токенов |
| White box, доступ к коду | Криптографический аудит протокола, code review | Ручной анализ + специализированные фреймворки |
Trade-off: инструменты тестирования безопасности мессенджеров
| Инструмент | Преимущества | Ограничения | Когда использовать | Когда НЕ использовать |
|---|---|---|---|---|
| Burp Suite | Полноценный перехват и модификация API-запросов, расширения для автоматизации | Не подходит для бинарных протоколов (Matrix Federation), требует настройки SSL для каждого клиента | API-тестирование self-hosted мессенджеров | Анализ криптопримитивов E2EE |
| mitmproxy | Скриптуемость на Python, фильтрация по домену, сохранение flows для повторного анализа | Бесполезен при certificate pinning без Frida, не парсит custom-протоколы | Перехват REST API трафика Electron-клиентов | Мобильные клиенты с pinning |
| Wireshark | Глубокий анализ пакетов, TLS-расшифровка при наличии SSLKEYLOGFILE | Пассивный - не модифицирует трафик, генерирует огромный объём данных | Анализ метаданных, выявление fallback на незащищённые протоколы | Активное тестирование API |
| Frida | Динамический анализ без исходного кода, хук любой экспортируемой функции | Требует root/jailbreak, нестабилен на свежих iOS | Проверка реальной работы E2EE в рантайме, обход pinning | Серверная часть, нет физического доступа |
Чеклист аудита безопасности корпоративного мессенджера
Клиентская часть:
- Проверить хранение токенов на диске: plaintext vs зашифрованное хранилище (DPAPI, Keychain)
- Проверить, инвалидируется ли сессия на сервере при logout (не только удаление с клиента)
- Проверить кэширование сообщений и вложений на диске - наличие шифрования at rest
Между тем, за два года работы с корпоративными инсталляциями я вытаскивал из чатов AWS-ключи, пароли от production-баз, VPN-конфиги с приватными ключами и однажды - полный дамп клиентской базы, который менеджер переслал коллеге CSV-файлом в приватном канале Slack. Ни один из этих случаев не был бы обнаружен существующими средствами мониторинга, потому что мессенджер не входил в периметр детекции.
Мессенджер в корпоративной инфраструктуре - это одновременно хранилище секретов, канал доставки payload и вектор lateral movement. Пока его не начнут включать в скоуп пентеста по умолчанию, а не по отдельному запросу за дополнительную оплату - мы будем продолжать находить там одни и те же AWS-ключи и одни и те же дампы. Проверьте свой Mattermost прямо сейчас -
grep -ri "AKIA" /opt/mattermost/data/ - и посмотрите, сколько ключей там валяется.
Последнее редактирование модератором:
