3side кибербезопасности

Боты пробива — ветряные мельницы Знаете, всё больше вижу активности вокруг борьбы с ботами пробива, но что произойдёт, если они окончательно уйдут в подполье? Это урежет лишь массовое использование утечек! У всех, кто их использовал во зло, доступ останется. Фактически это лишь скроет вершину айсберга и усложнит мониторинг с благими целями. Конечно, основная проблема тут — источники. Боты ведь только агрегаторы, строятся они на утекших базах. А что у нас утекло и сейчас присутствует на форумах? Кое‑что гораздо страшнее «Додо Пиццы»: * База «Роспаспорта» Там 1,2+ млрд строк с данными на декабрь 2021 года. Говорят, там суммарно данные примерно 160 млн граждан России, а именно — документы с фотографиями и адреса! * Объединённая база «Туроператоры» Там 126+ млн строк с данными на июнь 2026 года. Говорят, утекло из fstravel.com, tui.ru и samo.ru. Данные о пассажирах, их заказах, визах и подобное. Если бы подобных утечек не было, то и боты были бы не нужны. Оборотные штрафы введены, но они так и не применяются. А А уж кто ответит за массовые утечки государственных структур? Ведь именно они опаснее всего!

Рекламный баннер, который вас взломает Google шесть лет держал израильскую компанию Discover-Tech в списке проверенных рекламных партнёров — пока ее баннеры заражали устройства жертв шпионскими программами. Нажимать ничего было не нужно: было достаточно, что реклама просто появилась на экране. Её баннеры шли через Яндекс и Google, крутились в Viber и Duolingo, на BBC и «Нью-Йорк таймс», попадали в сети НАТО и российских госорганов. А в совете директоров сидел человек, который раньше продавал Pegasus. Доказано заражение сотрудников «Аль-Джазиры», но это лишь вершина айсберга. По данным исследователей, атаки шли как минимум в девяти странах, а «подходящими» для вредоносного кода система отметила больше 3,6 миллиона человек. Кто за этим стоит и как выпускники подразделения 8200, продавцы Pegasus и Predator и одна рекламная фирма связаны с теневой империей израильского кибершпионажа? Рассказываем по отчёту канадской Citizen Lab.

⏹️Хакеры ударили не по данным, а по товару Хакеры вмешались в системы управления холодильниками Danfoss в сотнях французских магазинов, включили длительную разморозку и испортили продукты. ⏪ Атаковали не отдельные холодильники, а общие контроллеры, доступ к которым часто открыт через интернет для подрядчиков, объясняет основатель 3side/4sec Антон Бочкарев: «В этом режиме камеры штатно нагреваются, чтобы растопить лед. Просто его продержали часами» ⏪ CEO «белых хакеров» Singleton Security Егор Богомолов отмечает: «Атака на инженерку бьет не по данным, а по физическому товару и людям. Тут нельзя “восстановиться из бэкапа”» Полностью исключить кибератаки невозможно, отмечает председатель ПК РАД КОП Рустам Гусейнов. Поэтому защита оборудования должна сочетаться с готовностью быстро восстановить работу после инцидента. 1⃣2⃣3⃣4⃣ Подписаться

Подтверждено: вас можно взломать через рекламный баннер. Даже без клика по нему. Мы тут много писали про израильский "наступательный" кибербез — например, как одна из местных компаний (умышленно или нет) засветила интерфейс управления системой для взлома мессенджеров. Теперь есть история еще фееричнее. Исследовали из канадской Citizen Lab вчера еще раз технически доказали: шпионское ПО можно доставлять через обычную таргетированную рекламу. Технику назвали AdFection, работает это так: израильская компания Discover-Tech выдавала себя за провайдера интернет-рекламы и покупала показы в Google, Yandex и других сетях. Баннер выглядел совершенно безобидно, но в момент показа незаметно сообщал серверу, кто его видит. Если этот человек был в списке целей, на телефон приходил вредоносный код и устанавливал шпионскую программу. Если нет, ничего не происходило, поэтому проверки рекламных сетей ничего подозрительного не находили. Именно так взломали как минимум 45 устройств сотрудников телеканала Al Jazeera, а в реальности - почти наверняка и множество других. За четыре месяца компания попыталась показать свою рекламу почти 4 миллиарда раз. Баннеры появлялись в Viber, Duolingo, Truecaller и на 120 тысячах сайтов, в том числе в сетях НАТО, Еврокомиссии, министерств обороны разных стран и российских госорганов. Вишенка на торте: Google годами держал эту компанию в списке «сертифицированных» партнёров. Хотите знать больше? Традиционно, если этот пост наберет 50 реакций, мы детально и подробно опишем, как все это произошло!

Народное голосование Всем привет, тут началось народное голосование премии: «Новая элита кибербеза» Я участвую в номинации ИБ-предприниматель, по результатам народного голосования сформируют шорт-лист, а далее будет оценка жюри, поэтому буду рад поддержке! Правда нас, ИБ-предпринимателей до 33 лет включительно всего трое, поэтому интересно, как будут выбирать? Голосовать тут: https://secpost.ru/rating-eleet

Datasuckers: ломали тех, кто ломается Была такая группировка в далёком 2011 году — называлась LulzSec. Пора её вспомнить, уж очень похожая вышла ситуация. Девиз LulzSec был прост: «Мы проорали с вашей безопасности». Они ломали всех, до кого могли дотянуться, достаточно простыми методами и очень громко об этом заявляли, обязательно публикуя материалы. Целились именно в крупные и известные компании. Тогда СМИ писали о них как о гениях и самой крутой группировке, хотя на деле они лишь собирали низковисящие фрукты. И вот новоиспечённая группа Datasuckers делала ровным счётом то же самое. Буквально недавно они взломали TezTour, Dodo Pizza и украинский ATBmarket. После взломов они активно пиарились, общались с аудиторией в комментариях в своём ТГ-канале, выкладывали материалы, включая отчёты по взлому! Что мы увидели в отчетах? Работу прокачанной нейронки с поддержкой специалиста уровня junior+ / middle-pentester. Никаких уязвимостей нулевого дня, редких техник, непубличных эксплойтов, кастомного вредоносного ПО. Буквально, любой пентестер мог это повторить, а при должной удаче и студент с хорошей нейронкой. По поводу того, где живут участники группы, тут внутри нашей команды мнение разделилось - версии были разные (Украина, Европа, иные страны). Но всегда мелькало и мнение «они просто не думают о последствиях» и могут жить в зоне досягаемости Российского правосудия, что в итоге и оправдалось! СМИ пишут, что первого их участника уже задержали. Им оказался 19-летний парень из Барнаула. Как именно его нашли - подробно не пишут, но кажется, у него в какой-то момент засветился домашний IP =) Остальные участники тоже установлены, пишут о гражданах Казахстана и Беларуси. Вспоминаем и взлом Гемотеста, где злоумышленник транслировал весь взлом в свой личный ТГ-канал, где не скрывал свою личность, буквально записывая кружочки! Итого Что LulzSec, что взломщик Гемотеста, что Datasuckers - получили свою минуту славы за взлом того, что получилось сломать, и были арестованы. Стоило того? P.S. Пост перевыложили, так как Markdown оказывается на разных устройствах выглядит по разному и поэтому текст с ним получается уродлив! Пока от экспериментов с ним откажемся.

Для тех кто перепугался что это нейропост, писалось человеком! Просто Телеграм с премиумом теперь умеет в Markdown и можно нормально оформлять посты, если на это есть время) P.S. Второй пост же написал Артем, без форматирования нейронкой, разница режет глаз, да!

ЦОДы под землей системно строит только одна страна. Но есть ... НЮАНС На самом деле, в мире есть только одно государство, которое сейчас системно строит крупные ЦОДы (коммерческие в том числе) под землей. Это Израиль. И там действительно все довольно серьезно. Например, иерусалимский ЦОД Bynet Data Centers в технопарке Хар-Хоцвим. Комплекс занимает около 14 000 м² и расположен под пятью уровнями парковки и офисной башней в 17 этажей. Сам ЦОД — это четыре этажа на глубине около 50 м. Для понимания, строительство обошлось примерно в $57 млн — это где-то в 2-4 раза дороже чем у Яндекса. Тут правда надо понимать тонкий момент. В Израиле с 2013 года есть конкретные требования по физической безопасности финансовой инфраструктуры, которые включают в себя (кроме очевидных вещей) соответствие сценариям национальных угроз. Проще говоря, ЦОД должен выдерживать попадание ракеты и взрыв рядом с ним. С 26 года критические данные нельзя хранить и обрабатывать за пределами Израиля (там требования даже жестче чем наш 152-ФЗ). Да, в Израиле государство оплачивает населению и бизнесу прямой ущерб от военных действий (считается, что армия существует на налоги и должна защитить страну, а если произошел ущерб, то это вина государства). Но простой, штрафы за нарушение SLA оно не оплачивает — и ЦОД под землей это буквально единственное решение. А теперь думаем. В 2024 году по территории Израиля было выпущено около 350 баллистических ракет. В 2025-26 уже по 650 в год, плюс десятки тысяч ракет РСЗО и тысячи БПЛА за тот же период. Да, большинство были перехвачены. Но кажется, тут начинаются риски немного другого порядка. И вот если вы ожидаете подобной ситуации, то ЦОДы логично убирать под землю. Если нет — то стоит считать ценник. Надземных ЦОДов в Израиле, кстати, тоже хватает, их там вообще много (рынок всего ~ в 3 раза меньше чем в РФ).

Telegram doesn't show this post on the web. Open it in Telegram to see it.

Один график, который не о том. После ударов по дата‑центрам Яндекса на графике глобального анти‑DDoS‑провайдера Cloudflare произошло значительное падение трафика со стороны сетей Яндекса в России. Одна проблема: график называется «Bot vs. Human». А значительная часть людей, особенно зарубежных журналистов, воспринимает слово «bot» лишь в контексте написания автоматических комментариев в соцсетях. Как правило для рекламы или пропаганды. И как журналисты трактовали график? «Так и надо, интернет станет чище» — в таком ключе написали куча респектабельных СМИ, аккаунтов в соцсетях, а робкие попытки возразить никто не слышит. А на деле как? Яндекс - поисковая система, помните ещё? И bot‑трафик от Яндекса — это автоматический обход интернета, чтобы поисковик работал. Так же, как обходит весь интернет Google или иные поисковики и платформы сбора данных — например, Shodan. Собственно, Cloudflare публикует общую статистику запросов, не разделяя их по типам. Отдельная статистика по ботам‑комментаторам есть только у самих соцсетей. Но люди видят только то, что хотят видеть и к чему привыкли.

❤️ Что зарезервировать, чтобы пережить потерю ЦОДа: памятка За неделю из строя вышли три площадки Яндекса: Сасово, Калуга и Владимир. Yandex Cloud перешёл в аварийный режим. К сожалению, быстро восстановить работу проекта в такой ситуации помогает только наличие резерва и/или бэкапов у другого провайдера. Мы подготовили для вас памятку: Что можно и нужно проверить сейчас, чтобы в случае подобного форс-мажора иметь возможность быстрого восстановление проекта. Бэкапы должны храниться у другого провайдера или на собственном оборудовании вне основного дата-центра. ➡️Что обязательно нужно сохранить 1. Базы данных • Полные бэкапы PostgreSQL, MySQL и других используемых СУБД. • Журналы транзакций (WAL, binlog), если важно восстановление на конкретный момент. • Конфигурации СУБД, роли, права и расширения. • Для критичных систем в иделе иметь реплику у независимого провайдера. Важно: автобэкапы managed-баз не заменяют независимую копию. 2. Файлы и объектные хранилища • Пользовательские загрузки, документы, медиафайлы. • Содержимое S3-бакетов и файловых хранилищ. • Данные с постоянных дисков, которые нельзя воссоздать автоматически. На резервном хранилище включите версионирование и, по возможности, защиту от удаления (Object Lock). 3. Код и CI/CD • Git-репозитории, включая историю и теги. • Конфигурации пайплайнов. • Настройки CI/CD, раннеров и интеграций. • Необходимые переменные и секреты — в отдельном защищённом хранилище. 4. Docker-образы и зависимости • Все образы, которые сейчас используются в production, с точными версиями или digest. • Собственные базовые образы. • Критичные пакеты и зависимости, если их повторная загрузка не гарантирована. 5. Конфигурации инфраструктуры • Terraform, Ansible, Helm charts и values. • Terraform state. • Конфигурации Nginx, HAProxy, приложений и балансировщиков. • Сетевые настройки, правила firewall, маршрутизацию. 6. Секреты, ключи и сертификаты • Секреты приложений и сервисных аккаунтов. • Ключи шифрования резервных копий. • TLS-сертификаты или механизм их автоматического перевыпуска. 7. Очереди, кеши и другие stateful-сервисы • RabbitMQ, Kafka: конфигурации, топологию, права и критичные данные, если их необходимо сохранить. • Redis: настройки и резервные копии, если он используется не только как кеш. • Поисковые индексы и другие хранилища, которые невозможно быстро пересоздать. 8. Внешние интеграции и сетевые соединения Составьте и сохраните вне основной инфраструктуры список внешних сервисов, с которыми взаимодействуют ваши приложения. С кем интегрированы: внешние API, платёжные системы, партнёры, SaaS-сервисы и другие системы. Для каждой интеграции зафиксируйте: - Адреса, порты, протоколы и направления соединений. - Используемые IP-адреса и правила whitelist. - VPN-туннели, приватные соединения и маршруты. - Конфигурации подключений и необходимые сертификаты. - Контакты технических специалистов и ответственных со стороны партнёров. Отдельно: если у вас Kubernetes Для восстановления Kubernetes недостаточно сохранить манифесты приложений. Проверьте, что у вас есть: • Описание инфраструктуры: Terraform или другие инструменты для создания нового кластера, сетей, узлов и балансировщиков. • Бэкапы Persistent Volumes: независимые копии данных, а не только снапшоты дисков текущего облака. • План развёртывания: порядок восстановления системных компонентов, операторов, баз данных и приложений. Если кластер managed, отдельно проверьте, что его можно создать у другого провайдера, а приложения не зависят от специфичных сервисов текущего облака. ➡️Что сделать прямо сейчас, если времени мало? 1. Выгрузить актуальные резервные копии баз и критичных файлов на независимую площадку. 2. Сохранить production-образы и убедиться, что доступны исходный код и конфигурации. 3. Проверить доступность секретов, ключей шифрования, DNS и административных учётных записей. 4. Зафиксировать порядок восстановления и ответственных. 5. Проверить восстановление хотя бы одного критичного сервиса из резервной копии.

Третий удар, массовая миграция, фатальные ошибки. Сейчас многие компании занимаются миграцией из дата‑центров Яндекса, и самое страшное — то, что, торопясь, они допускают фатальные ошибки. Самая частая из них — опасные настройки фаерволов! При экстренной миграции велик соблазн настроить «так, чтобы как можно быстрее заработало». Но вместе с трафиком от ваших пользователей к вам зайдут и злоумышленники. Это может стать вторым эффектом от ударов: массовый взлом компаний из‑за экстренной миграции. А дальше — слив данных, шифрование и остановка работы на ещё больший срок. Будьте осторожны, держите безопасность в фокусе. Если нужно, мы можем помочь и оперативно проверить вашу новую инфраструктуру. P. S. Последний удар задел частично и нас, но далеко не так серьёзно, как множество бизнесов по всей России.

Рунет: чем централизованнее, тем уязвимее. Удар по дата‑центру Яндекса побудил многих «околовоенных» экспертов высказаться на темы, близкие к кибербезу. Давайте мы, как профильный канал, тоже прокомментируем эту тему. Все мы помним, что Рунет у нас уже много лет суверенен, независим и достаточно централизован. Он буквально завязан на несколько ключевых провайдеров и их дата‑центры. Проект централизации первично децентрализованной технологии «Интернет» выполнялся по различным причинам — их мы обсуждать в этом посте не будем. Но фактически успех этого проекта привёл к тому, что буквально на около десятка дата‑центров в европейской части России завязано функционирование примерно всего Рунета. Поэтому, господа военные эксперты: может, суммарно дата‑центров у нас и сотни по всей стране, может, и очень крупных много. Но вывести из строя нужно гораздо меньше, и они вовсе не на Камчатке. Их нужно питать, обслуживать, обеспечивать логистикой. Они все в полётной доступности средств поражения по вполне прагматичным причинам. Могут ли облачные провайдеры быстренько «переехать» в безопасные дружественные страны? Конечно, нет. 152‑ФЗ («О персональных данных») жёстко ограничивает в этом, а 187‑ФЗ (регулирующий безопасность критической информационной инфраструктуры) вводит прямо запрет на зарубежные облака и SaaS‑сервисы. Централизация тут однозначно стреляет нам в ногу: в плане физического поражения инфраструктуры мы стали уязвимее.

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

В рамках дейтинга будет доступна легализованная услуга "Глаз Государства"! 😂

Сегодня смотрел предварительный список вопросов Эфир обещает быть очень конкретным!

Клуб ИТ-лидеров Global CIO приглашает вас принять участие в живом разговоре «После атаки: как сохранить работу бизнеса, когда ИТ-инфраструктура частично недоступна» 🗓 9 октября | 11:00–12:30 | онлайн Ламповый формат для своих, без рекламы. Киберустойчивость — это не только защита от атаки. Что делать, когда часть инфраструктуры уже недоступна, а бизнес должен продолжать работу? Обсудим, как сохранить критичные процессы и какие сценарии стоит отработать заранее. Модератор: 🙋🏻‍♂️ Владимир Дрюков, Директор по услугам и технологиям, ГК Инностейдж Эксперты эфира: 🙋🏼‍♂️Михаил Хавин, CISO, Аскона Лайф Групп 🙋🏼‍♂️Анатолий Скородумов, руководитель отдела кибербезопасности, Лента 🙋🏻‍♂️ Антон Бочкарев, Эксперт по информационной безопасности, Сооснователь компаний 3side/4sec Участие бесплатное ПРОГРАММА И РЕГИСТРАЦИЯ Присоединяйтесь! Материал по итогам будет доступен в Клубе ИТ-лидеров Global CIO. Подписывайтесь на сообщество Global CIO в МАХ и ВКонтакте #Клуб_ИТлидеров

ИНТЕНСИВ ПО БЕЗОПАСНОСТИ: ПРОВЕРКА НА ПРОЧНОСТЬ 2026 Друзья, 14 октября в Москве (Холидей Инн Сокольники) стартует главная практическая конференция для тех, кто занимается анализом защищенности. - Почему «мы проверились» — это не равно «мы поняли риски»? - Как не купить красивый отчет вместо реального уровня защиты? - Где грань между пентестом, Red Team и Purple Team? В программе — 3 потока: 🔹 Стратегия для CISO и руководителей (бюджеты, приоритеты, выбор инструментов). 🔹 Практика для технических специалистов (сканирование, ASM, человеческий фактор). 🔹 Спецпрактики (АСУ ТП, право на взлом, этичный хакинг и ИИ). 🎤 Вас ждут пленарные дискуссии, круглые столы CISO, мастер-классы от пентестеров и живое общение с вендорами. 📅 Когда: 14 октября 2026 г. 📍 Где: Москва, Холидей Инн Сокольники ⏳ Программа и регистрация по ссылке. P.S. Мы как обычно инфопартнер

«Может ли взлом быть госизменой?» Это не тема нашей лекции. Это запрос, который военный связист армии США вбил в Google. Теперь у него будет почти шесть лет, чтобы подумать над ответ. Что известно? — Кэмерон Вагениус, 21 год, связист армии США, служил на базе в Южной Корее. В сети — kiberphant0m. — С апреля 2023 по декабрь 2024 вместе с двумя подельниками взламывал американские технологические и телеком-компании. Жертв минимум десять, среди них AT&T и Verizon. Это часть той самой волны взломов через облако Snowflake, где пострадало больше 165 организаций. — Данные качали и шантажировали владельцев: заплатите, или выложим на BreachForums и XSS. Всего пытались выбить минимум миллион долларов. — Задержали его в декабре 2024 в Техасе, рядом с армейской базой. Вину признал. Приговор: 70 месяцев тюрьмы и $294 978 компенсации. А теперь лучшее из материалов обвинения. Почти весь ноябрь 2024 он переписывался с адресом, который считал почтой иностранной разведки, и предлагал ей купить украденное. В октябре гуглил «куда дезертировать из армии, чтобы меня не выдали», «американские военные, перебежавшие в Россию» и адрес посольства России в Вашингтоне. Сразу после переписки с «разведкой» появился тот самый запрос про госизмену. А ещё в ноябре 2024-го, сразу после ареста подельника, он выложил на хакерском форуме «журналы звонков» Трампа и Харрис из AT&T. Не записи разговоров, а кто кому и когда звонил. Были ли они настоящими, так и не подтвердилось. Армейский связист гуглил план побега от американского правительства в американском Google. Это не opsec, это явка с повинной в рассрочку. Как ломали? Никаких zero-day и голливудских сцен. Пароли подбирали перебором по SSH: инструмент для этого Вагениус сам помогал писать. Вся волна Snowflake держалась на украденных учётках к облачным хранилищам, где не было второго фактора. Ни одна из этих компаний не проиграла гениям. Они проиграли перебору паролей и отсутствию MFA. Что делать? Включить второй фактор везде, куда можно войти из интернета. Одна эта мера сорвала бы всю схему.

Совместный проект с Ингосстрахом — финалист премии "За вклад в безопасность цифрового будущего" Наш совместный проект с Ингосстрахом — Кибер-Инго Смарт — стал финалистом в номинации "Лучший проект – сервисы цифрового будущего". Хотим сказать большое спасибо коллегам из Ингоса что поверили в наш общий продукт. Будем делать его еще лучше. А пока — новый AI-SOC на ИИ-агентах активно пилотируется в нескольких компаниях, мы дорабатываем его. Все идет хорошо, посмотрим что получится на выходе. Но в любом случае приятно.