TGViewer
in2security in2security @intosecurity · 11.9K subscribers
Post #1482 2.28K
Горячие новости. Публикуем небольшое интервью с представителями группировки 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 хранят пароли без шифрования, уязвима тем же способом.
  • ❤ 23
  • 🔥 17
  • 👍 12
  • 😁 5
  • 👏 2
More from @intosecurity
  1. Oct 6, 2026О фейковых инвестплатформах мы писали десятки раз. Но там надо хоть на сайт зайти, а потом…
  2. Aug 19, 2026Смотрите, какой интересный сайт попался. На нём предлагают скачать YouTube, который якобы…
  3. Aug 17, 2026Прекрасная история о том, как пострадавшая компания сама помогла продавцу утечки доказать,…
  4. Aug 17, 2026Давненько не было нормального фишинга для кражи доступа в личный кабинет клиента банка, а…
  5. Aug 13, 2026Любопытный бизнес по продаже фейковых авиабилетов кто-то затеял. Причем тут сразу говорят,…
  6. Aug 13, 2026Мошенники превратили телефон в удлинитель для банковской карты Жертве позвонил «сотрудник…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →