Горячие новости. Публикуем небольшое интервью с представителями группировки datasuckers, которые ранее заявили о взломе «Додо Пиццы».
Поговорили о том, как они получили первоначальный доступ, как развивали атаку и сколько времени и ресурсов на это потратили.
*Важное примечание: администрация канала выступает против кибератак и много лет продвигает идеи информационной безопасности. Материал публикуется исключительно в познавательных целях. Технические подробности приводим со слов собеседников: это версия стороны, заявившей об атаке, а не независимо подтверждённая реконструкция инцидента.
1. Как проходил этап сбора информации?
Начали с их мобильного приложения — разобрали APK, вытащили Firebase-конфиги и карту из 95+ REST-эндпоинтов. Затем прошлись по публичному API, нашлись маршруты без авторизации и анонимные write-семейства. LinkedIn, GitHub-утечки и фишинг не использовались, всё через техническую разведку их публичной инфраструктуры.
2. Какие активы были в приоритете?
Приоритет — операционная БД юзеров и заказов. Целились в платформу данных: Databricks, Kusto, MySQL-монолиты. Бухгалтерия, переписка, шифрование для выкупа — не рылись в эту сторону.
3. Как оценивали периметр?
Сразу бросилось в глаза: publicapi-v1 имел 22 из 26 маршрутов без авторизации. Databricks-воркспейс допускал несанкционированное чтение внутренних файлов. QRATOR (технически говоря, WAF) стоял на части эндпоинтов, но обходился через headless Chromium.
4. Первоначальный вектор проникновения?
Техническая misconfiguration — file-read (LFI) в Databricks DBFS: через публичный эндпоинт читались внутренние файлы, среди которых оказался PAT-токен (ключ доступа). Сразу отмечу: не фишинг, не 0-day и не инфраструктура какого-то подрядчика.
5. Социальная инженерия?
Не использовалась. Никакого фишинга, deepfake, поддельных страниц. Весь путь технический, через ошибки конфигурирования.
6. Какую ошибку допустили администраторы?
Хранили креды в открытом виде в трёх внутренних системах: Superset-метадата (SQLalchemy_uri с паролями), OpenMetadata (PAT-токены плейнтекстом), KeyVault-скопы (доступные через компрометированные compute-токены). Главная ошибка — не encrypting secrets at rest в аналитических инструментах.
7. Сколько времени до прав администратора?
От первого касания (анализ APK) до полного доступа к данным — около 12–16 часов. От первой украденной креды (PAT из DBFS) до SQL-консоли на 27 прод-БД — около 4–6 часов.
8. Как закреплялись?
OAuth-токены с TTL 90 дней, вечная веб-сессия с auto-refresh каждые 12 часов, cluster-admin Kubernetes SA-токены. Новых пользователей не создавали, планировщик не трогали, бэкдоров в ПО не внедряли. Всё было очень просто)
9. Как обходили шифрование?
Данные были доступны через легитимные креды — шифрование at rest не мешало. Парадокс: Azure KeyVault (хранилище ключей) сам стал источником утечки — после получения RCE на кластере мы прочитали все секреты из KV напрямую.
10. Требовали ли вы выкуп?
Нет, не требовали. У Додо и Тез-Тур политика отрицания («ничего критичного не произошло — соответственно, и платить не за что»). Да и наше присутствие в Додо заметили почти сразу после скачки БД. Компания такого уровня, очевидно, не идёт на контакт с хакерами.
11. Один совет директору по ИТ?
Уберите пароли из инструментов аналитики. Конкретно: encrypt secrets at rest в Superset/OpenMetadata, ротируйте ВСЕ сервисные секреты (не только по чеклисту), поставьте алерты на аномальные blob-чтения. Одна эта правка закрыла бы 80% нашего пути.
12. Насколько легко обошли SOC?
Их SOC не заметил ничего за всё время. Выемка шла через SharedKey blob-чтения и OAuth API, это не попадает в журналы приложений. Единственные их реакции — на app-level шум (500-ки в Superset, WAF-триггеры) — расценили как баги, а не как атаку.
13. Могут ли компании такого масштаба защититься?
Да, но нужно перестать относиться к управлению секретами как к рутине. Технический барьер достижим: encrypt secrets, ротация всех (не только «важных») кредов, поведенческий мониторинг blob-доступа. Проблема организационная, не технологическая).
14. Сотрудничаете ли вы с другими группировками?
Нет, не сотрудничаем. Работаем сами.
15. Боитесь ли вы уголовного преследования?
Нет, и в реальной жизни все ведут себя как обычно. Никто не будет трубить всем своим знакомым, мол, я взломал Додо, Тез Тур! Живём, как простые люди. За себя не переживаем — используем многие средства анонимизации.
16. Сколько человек у вас в команде?
3 человека, очевидно, что у нас есть личные аккаунты друг друга и мы общались между собой)
17. Можно ли применить такую схему к любой российской компании?
Конкретная цепочка уникальна для стека Dodo (Databricks + Superset + OpenMetadata).
Но класс уязвимости — плейнтекст-креды в BI/каталогах/оркестраторах — распространён повсеместно. Любая компания, где Superset, Airflow или data-catalog хранят пароли без шифрования, уязвима тем же способом.
Поговорили о том, как они получили первоначальный доступ, как развивали атаку и сколько времени и ресурсов на это потратили.
*Важное примечание: администрация канала выступает против кибератак и много лет продвигает идеи информационной безопасности. Материал публикуется исключительно в познавательных целях. Технические подробности приводим со слов собеседников: это версия стороны, заявившей об атаке, а не независимо подтверждённая реконструкция инцидента.
1. Как проходил этап сбора информации?
Начали с их мобильного приложения — разобрали APK, вытащили Firebase-конфиги и карту из 95+ REST-эндпоинтов. Затем прошлись по публичному API, нашлись маршруты без авторизации и анонимные write-семейства. LinkedIn, GitHub-утечки и фишинг не использовались, всё через техническую разведку их публичной инфраструктуры.
2. Какие активы были в приоритете?
Приоритет — операционная БД юзеров и заказов. Целились в платформу данных: Databricks, Kusto, MySQL-монолиты. Бухгалтерия, переписка, шифрование для выкупа — не рылись в эту сторону.
3. Как оценивали периметр?
Сразу бросилось в глаза: publicapi-v1 имел 22 из 26 маршрутов без авторизации. Databricks-воркспейс допускал несанкционированное чтение внутренних файлов. QRATOR (технически говоря, WAF) стоял на части эндпоинтов, но обходился через headless Chromium.
4. Первоначальный вектор проникновения?
Техническая misconfiguration — file-read (LFI) в Databricks DBFS: через публичный эндпоинт читались внутренние файлы, среди которых оказался PAT-токен (ключ доступа). Сразу отмечу: не фишинг, не 0-day и не инфраструктура какого-то подрядчика.
5. Социальная инженерия?
Не использовалась. Никакого фишинга, deepfake, поддельных страниц. Весь путь технический, через ошибки конфигурирования.
6. Какую ошибку допустили администраторы?
Хранили креды в открытом виде в трёх внутренних системах: Superset-метадата (SQLalchemy_uri с паролями), OpenMetadata (PAT-токены плейнтекстом), KeyVault-скопы (доступные через компрометированные compute-токены). Главная ошибка — не encrypting secrets at rest в аналитических инструментах.
7. Сколько времени до прав администратора?
От первого касания (анализ APK) до полного доступа к данным — около 12–16 часов. От первой украденной креды (PAT из DBFS) до SQL-консоли на 27 прод-БД — около 4–6 часов.
8. Как закреплялись?
OAuth-токены с TTL 90 дней, вечная веб-сессия с auto-refresh каждые 12 часов, cluster-admin Kubernetes SA-токены. Новых пользователей не создавали, планировщик не трогали, бэкдоров в ПО не внедряли. Всё было очень просто)
9. Как обходили шифрование?
Данные были доступны через легитимные креды — шифрование at rest не мешало. Парадокс: Azure KeyVault (хранилище ключей) сам стал источником утечки — после получения RCE на кластере мы прочитали все секреты из KV напрямую.
10. Требовали ли вы выкуп?
Нет, не требовали. У Додо и Тез-Тур политика отрицания («ничего критичного не произошло — соответственно, и платить не за что»). Да и наше присутствие в Додо заметили почти сразу после скачки БД. Компания такого уровня, очевидно, не идёт на контакт с хакерами.
11. Один совет директору по ИТ?
Уберите пароли из инструментов аналитики. Конкретно: encrypt secrets at rest в Superset/OpenMetadata, ротируйте ВСЕ сервисные секреты (не только по чеклисту), поставьте алерты на аномальные blob-чтения. Одна эта правка закрыла бы 80% нашего пути.
12. Насколько легко обошли SOC?
Их SOC не заметил ничего за всё время. Выемка шла через SharedKey blob-чтения и OAuth API, это не попадает в журналы приложений. Единственные их реакции — на app-level шум (500-ки в Superset, WAF-триггеры) — расценили как баги, а не как атаку.
13. Могут ли компании такого масштаба защититься?
Да, но нужно перестать относиться к управлению секретами как к рутине. Технический барьер достижим: encrypt secrets, ротация всех (не только «важных») кредов, поведенческий мониторинг blob-доступа. Проблема организационная, не технологическая).
14. Сотрудничаете ли вы с другими группировками?
Нет, не сотрудничаем. Работаем сами.
15. Боитесь ли вы уголовного преследования?
Нет, и в реальной жизни все ведут себя как обычно. Никто не будет трубить всем своим знакомым, мол, я взломал Додо, Тез Тур! Живём, как простые люди. За себя не переживаем — используем многие средства анонимизации.
16. Сколько человек у вас в команде?
3 человека, очевидно, что у нас есть личные аккаунты друг друга и мы общались между собой)
17. Можно ли применить такую схему к любой российской компании?
Конкретная цепочка уникальна для стека Dodo (Databricks + Superset + OpenMetadata).
Но класс уязвимости — плейнтекст-креды в BI/каталогах/оркестраторах — распространён повсеместно. Любая компания, где Superset, Airflow или data-catalog хранят пароли без шифрования, уязвима тем же способом.