Архив метки: DataLeakage

По поводу утечки данных из Metascan-а

По поводу утечки данных из Metascan-а

По поводу утечки данных из Metascan-а. Metascan - российский разработчик решений в области кибербезопасности, специализирующийся на автоматизированном контроле защищённости IT-инфраструктуры. Основной фокус компании - внешний периметр: обнаружение доступных из Интернет ресурсов организации, их постоянное сканирование и поиск уязвимостей.

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

Большая часть утекших данных - неприватные рабочие документы. Также среди них оказались несколько отчётов, которые сотрудники Metascan пересылали в корпоративном чате с нарушением регламента. Кроме того, был скомпрометирован код сканера, актуальный на 21.10.2025 г., и БД с маскированными пользователями до 2024 года.

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

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

Имхо, любая организация должна исходить из того, что потенциально любой сотрудник может слить всё, до чего у него есть доступ, сбежать на велосипеде через Верхний Ларс и начать шантажировать бывшего работодателя. Поэтому задача организации - снижать вероятность такого сценария различными способами. Тут и про DLP, и про минимизацию доступов. Но самая главная мера - не работать с чудаками (букву поменяйте по вкусу). Иногда лучше взять человека менее скиллового, но предсказуемого. Который дорожит своей репутацией, у которого есть семья/дети/ипотека, который не станет пускаться в сомнительные авантюры ради разового барыша. Собственно для этого в зрелых организациях есть Служба Безопасности и HR-ы, которые могут проверить бэкграунд человека и подсветить возможные риски ещё до найма. В небольших компаниях делать это, конечно, гораздо труднее, и поэтому риски выше.

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

Посмотрел, какие кейсы победителей премии Pentest award 2026 от Awillix были непосредственно связаны с уязвимостями

Посмотрел, какие кейсы победителей премии Pentest award 2026 от Awillix были непосредственно связаны с уязвимостями

Посмотрел, какие кейсы победителей премии Pentest award 2026 от Awillix были непосредственно связаны с уязвимостями. Подробности, как обычно, будут в осеннем спецвыпуске журнала "Хакер". Но общее впечатление можно составить и по краткому описанию кейсов в Хабр-статье с итогами церемонии награждения.

🔻 L3G5, победивший в номинации "AI", обнаружил схожие уязвимости в архитектуре ИИ-агентов двух крупных российских компаний, которые позволяли агентам выполнять привилегированные действия. L3G5 удалось показать, что эксплуатация этих уязвимостей в одном случае могла привести к утечке пользовательских запросов на адрес злоумышленника при анализе отравленного документа, а во втором - к раскрытию исходного кода всей агентской системы и получению доступа на запись в S3-хранилище с диалогами пользователей компании.

🔻 Хайдар Кабибо, победивший в номинации "Out of Scope", обнаружил уязвимость PhantomRPC в архитектуре Windows RPC (Remote Procedure Call), которая позволяет локально повышать привилегии до уровня SYSTEM. "Поскольку проблема связана с архитектурной уязвимостью, количество потенциальных векторов атаки фактически неограничено: любой новый процесс или служба, зависящие от RPC, могут ввести дополнительный путь повышения привилегий". Занимательно, что в Microsoft решили не заводить CVE-идентификатор для этой уязвимости. 🤷‍♂️

🔻 Денис Горюшев, победивший в категории "Девайс", обнаружил серию уязвимостей в Bluetooth-стеке некоторого embedded-устройства крупного китайского вендора. Уязвимости находятся в процессе ответственного раскрытия.

🔻 Владимир Кононович (DrMefistO), занявший второе место в категории "Девайс", продемонстрировал возможность загрузить собственную прошивку на автомобильные сигнализации (иммобилайзеры).

🔻 Иван Глинкин, занявший третье место в категории "Девайс", продемонстрировал возможность частичного восстановления данных из криптографических USB-накопителей после заявленного производителем полного сброса устройств.

🔻 Алексей Соловьев и Никита Свешников, победившие в категории "Системный взлом (Web & Logic)", обнаружили скрытые уязвимости в Си-компонентах языка PHP. В качестве последствий упоминают SQL-инъекции и каскадную десинхронизацию данных.

🔻 Влад Дриев и Олег Лабынцев, победившие в категории "Kill Chain", продемонстрировали цепочку от total black-box до компрометации двух доменов AD и ряда целевых сервисов вне доменной инфраструктуры. Георгий Кумуржи и Даниил Мамонтов, занявшие второе место в этой категории, получили доступ из Интернета к ЛВС организации, закрепились в инфраструктуре и реализовали ряд недопустимых событий, однако из описания непонятно, о каких именно событиях идёт речь. Cotsom, занявший третье место, продемонстрировал полную цепочку компрометации кластера Kubernetes: от первоначального проникновения через внешний периметр и захвата корпоративного кластера ClearML до реализации двух независимых векторов атаки на production-инфраструктуру. Упоминаются компрометация CSI-провайдера, злоупотребление механизмами GitLab CI/CD, а также обход политик Kyverno, позволивший развернуть привилегированный pod и получить административный контроль над кластером.

К сожалению, в статье с итогами вообще нет CVE/БДУ-идентификаторов. Если для уязвимостей, находящихся в процессе раскрытия (ну или отклонённых вендором), это понятно, то идентификаторы публично известных уязвимостей можно было бы и упоминать - для лучшего понимания кейсов и приоритизации устранения таких уязвимостей в инфраструктурах организаций. 😉