С осени 2025 года наши специалисты отдела реагирования на киберугрозы отмечают рост числа инцидентов, связанных с деятельностью хакерской группы PhantomCore. Эта группировка специализируется на кибершпионаже и краже конфиденциальных данных у российских организаций. Злоумышленники, в первую очередь нацеленные на внутренние процессы скомпрометированной организации, могут длительное время присутствовать в инфраструктуре жертвы, постепенно расширяя свое присутствие в сети.

Ключевые моменты

- C сентября 2025 года PhantomCore активно атакуют серверы видеоконференцсвязи TrueConf.

- Используют вредоносный клиент TrueConf.

- Используют инструменты цифровой криминалистики для закрепления и получения учетных данных на скомпрометированном хосте.

- В ходе атак были задействованы собственные инструменты для создания обратного SSH-туннеля: MacTunnelRat (PhantomHeart), PhantomProxyLite, PhantomSscp.

Одной из самых актуальных уязвимостей в Windows Server Update Services (WSUS) стала критическая ошибка с идентификатором CVE-2025-59287 и оценкой CVSS 9.8. Она связана с десериализацией недоверенных данных в службе обновления Windows Server и позволяет неавторизованному удаленному злоумышленнику выполнить код на сервере, отправив специально сформированное событие.

В разборах эксплуатации шаги были указаны некорректно, так как их взяли из статьи. Однако позже авторы сами ее исправили и указали, что разбор относится к CVE-2023-35317, тогда как анализ CVE-2025-59287 перенесли в отдельную статью.

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

Привет, Хабр! 

Меня зовут Андрей Кузнецов, я ML-директор в Positive Technologies. Недавно я решил разобраться, какие бенчмарки измеряют способности языковых моделей в контексте задач кибербезопасности. Думал, что это займет вечер, — увы! Все оказалось куда хаотичнее, чем предполагалось. Поэтому делюсь тем, что собрал сам.

Первое, что бросилось в глаза, — полный бардак и отсутствие системы. Бенчи, про которые все пишут в 2024-м, могут вообще не упоминаться в свежих статьях 2025-го. А некоторые широко цитируемые датасеты при ближайшем рассмотрении оказываются сделанными очень небрежно, из-за чего непонятно, что они вообще измеряют. Поэтому, прежде чем лезть в конкретные примеры, давайте определимся, какими они бывают.

Всем привет! На связи Дмитрий Федосов, руководитель отдела наступательной безопасности экспертного центра безопасности (PT ESC) Positive Technologies, и Владислав Дриев, ведущий специалист нашего подразделения. Мы развиваем технологии автопентеста в рамках продукта PT Dephaze. Сегодня хотим наглядно показать, как автоматизированный взлом собственной инфраструктуры помогает выявлять реальные векторы атак, которыми злоумышленники могут воспользоваться в любую минуту.

С момента запуска PT Dephaze наша команда провела более 60 «пилотов» в организациях России и не только. Мы проанализировали этот опыт, собрали обратную связь от клиентов и улучшили технологии. В этой статье предлагаем вместе погрузиться в процесс использования нашей системы автопентеста на основании опыта наших пользователей. Разберем результаты и варианты их использования в защите.

Привет, Хабр!

На связи Олег Уланов (aka brain), багхантер и ведущий подкаста «Начинаем в багбаунти». Кстати, по итогам 2025 года стал топ-1 площадки Standoff Bug Bounty.

Этот материал мы подготовили вместе с Дмитрием Прохоровым, пентестером из PT SWARM (в мире багхантинга Дима известен как ratel_xx).

В статье речь пойдёт о поиске уязвимостей через загрузку файлов. Вы узнаете, как устроен механизм multipart/form-data, какие защитные механизмы ставят разработчики и как их обходить. Я покажу на практике, что можно сделать с расширениями файлов, Content-Type, magic bytes, а заодно затрону эксплойты типа race condition, zip-слайп и нестандартные векторы вроде загрузки .htaccess. Статья подойдёт для начинающих багхантеров, поэтому даже если у вас мало опыта смело заглядывайте под кат!

Привет, Хабр!

На связи команда PT Cyber Analytics. В этой статье расскажем о работе аналитиков в проектах по кибербезопасности, покажем, чем привлекает эта профессия и какие навыки необходимы, чтобы стать ее частью. Как и многие другие аналитики, мы занимаемся сбором, анализом и интерпретацией данных, отличие лишь в обрабатываемых данных: в нашем случае это информация об уязвимостях, угрозах и мерах защиты.

В Positive Technologies есть множество экспертов, которые проводят анализ защищенности различных систем для других компаний: проверяют их инфраструктуру, веб-приложения, банковские системы и т. д. По результатам этих работ необходимо донести информацию о выявленных проблемах в доступном формате, чтобы клиент смог понять, какие возможны последствия для его бизнеса в случае реальной хакерской атаки. На этом этапе и подключаются проектные аналитики — мы выступаем посредниками между экспертами («белыми» хакерами, расследователями и т. д.) и клиентом: объясняем результаты проведенных проверок, анализируем их, структурируем выводы и даем рекомендации, чтобы обратившиеся к нам компании видели, где их системы можно «взломать», и знали, как это исправить.  

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

Фишинг на протяжении многих лет остается одним из наиболее востребованных способов получения первоначального доступа к корпоративной инфраструктуре, сохраняя свою эффективность вопреки массовому внедрению многофакторной аутентификации (MFA) и инвестициям в антиспам-фильтрацию. 

 В инфополе еженедельно всплывают новости о «свежих» утечках: то база ритейлера, то данные клиентов банка. Мы привыкли думать, что ценность украденной информации эфемерна — как только дамп попал в паблик, он становится бесполезным мусором. Однако реальность теневого рынка 2025–2026 годов говорит об обратном.

Даже «мертвые» базы продолжают циркулировать, перепродаваться и приносить мошенникам сотни тысяч долларов. В этом материале мы разберем, как устроена экономика вторичного рынка данных, как злоумышленники косплеят известные группировки вроде ShinyHunters и почему «баян» пятилетней давности до сих пор опасен для вашего бизнеса.

В марте специалисты киберразведки PT ESC зафиксировали активность группировки Rare Werewolf (Rezet, Librarian Ghouls). На этот раз был обнаружен архив data.zip, содержащий следующую структуру файлов.

Под катом разбор вредоносных файлов, их структуры и назначения.

В наши дни соотношение полезного сигнала и шума в информационном пространстве приближается к единице. Иными словами, дезинформации почти столько же, сколько реальных фактов — и отличить одно от другого становится крайне трудно. Эти рекомендации помогут журналистам в условиях нехватки времени распознавать контент, сгенерированный с помощью ИИ. Предложенные семь категорий проверок полезно освоить каждому репортеру.

Я помогаю редакциям бороться с дезинформацией. И вот что меня особенно тревожит: обычная проверка фактов занимает несколько часов или даже дней, а ИИ способен производить фейковый контент за считаные минуты.

(Эта статья является переводом, а обложку мне прислал институтский коллега. По русскому языку Gemini вместе с Nano Banana пока ставим уверенную «двойку»)

В конце 2025 года группа киберразведки зафиксировала кампанию хакерской группировки Cloud Atlas, нацеленную на российские организации из сферы промышленности и военно-промышленного комплекса. 

Для первичного проникновения использовалась электронная почта: рассылка велась от имени реального контрагента через скомпрометированный почтовый ящик. 

В начале ноября 2025 года децентрализованный протокол Balancer V2 (composable stable pools) подвергся атаке, суммарные потери по разным сетям превысили 128 млн долларов. Причиной стала не ошибка доступа, не реентерабельность и не баг в проверках прав, а потеря точности при расчете инварианта из-за округления. Формально проблема сводилась к округлению при масштабировании значений и выглядела как допустимый технический компромисс. Экономический эффект, однако, оказался значительным.

Взлом Balancer, как и многие другие инциденты, уже подробно разобран в формате post-mortem — с реконструкцией того, как именно была проведена атака. В этой статье подход другой: мы посмотрим на тот же код глазами аудитора, который задается вопросом «что здесь может пойти не так?».

Представьте, что вы не знаете, какие устройства подключены к вашей сети, как они настроены и что там происходит. Страшно? Ещё бы! Многие компании как раз так и живут — не уделяют внимания аудиту сетевого оборудования. А зря. Без такой инвентаризации невозможно ни нормально управлять ИТ-инфраструктурой, ни защититься от угроз.

Мы наблюдаем в инфраструктуре клиентов это так часто, что поняли – нужно выдать базу. Мы – это руководитель практики развития MaxPatrol Carbon Константин Маньяков и эксперт центра безопасности (PT ESC) Данил Зарипов, и в этой статье мы будем разбираться в ключевых аспектах аудита сетевых устройств, его роли в построении эффективного управления активами и повышении уровня защищенности ИТ-инфраструктуры.

Чтобы автоматизированно проверять и централизованно обрабатывать огромное количество событий о происходящем в инфраструктуре, используется SIEM –– класс решений информационной безопасности, призванный анализировать события ИБ, собираемые c устройств инфраструктуры, выявлять подозрения на инциденты.

Но для правильного использования этой системы, а тем более для максимально эффективной ее эксплуатации, необходимо провести ряд организационных мероприятий, направленных на выстраивание правильной работы как специалистов, непосредственно взаимодействующих с SIEM (аналитиков ИБ, технических специалистов и администраторов), так и смежных подразделений организации, отвечающих за блок ИТ.

После установки система не становится эффективной сама по себе, и помимо наличия персонала, в чьем ведении она находится, также важны и процессы, которые структурируют и делают более прозрачной и прогнозируемой деятельность по выявлению инцидентов ИБ.

В статье я расскажу, какие процессы следует наладить для работы с SIEM, почему это важно, и какие последствия могут быть и, скорее всего, будут, если этого не сделать.

Всем привет! Меня зовут Роман. В ИТ я больше семи лет: начинал с разработки, а теперь занимаюсь AppSec и параллельно пробую себя в багхантинге. Сейчас вхожу в топ-25 рейтинга на Standoff Bug Bounty. Здесь я выступаю как начинающий исследователь багов и буду рад поделиться своими наработками. Сегодня обсудим уязвимости бизнес‑логики — сложные и часто недооцененные ошибки, способные привести к серьезному ущербу. Разберем, как их находить, почему они опасны и что делает охоту за ними в багбаунти такой увлекательной. Погнали!

Когда-то APT-группировками считались прогосударственные хакеры со сложными инструментами и стратегическими целями, а хактивистами — те, кто выражал цифровой протест. Сегодня определить границу между первыми и вторыми становится все сложнее. Некогда идеологически мотивированные хакеры все чаще выполняют задачи в интересах государств и аффилированных с ними структур, а ущерб от их атак уже достигает уровня APT-группировок. 

Мы, группа международной аналитики PT Cyber Analytics, проанализировали деятельность сотен группировок за год — получилось большое исследование. В статье расскажем о самом важном: как меняется ландшафт глобальных киберугроз, какие методы чаще всего используют атакующие и что нас ждет в будущем. А еще покажем топ интересных атак за 2025 год. 

Документацию можно готовить где угодно и как угодно. Писать инструкции в многочисленных CCMS, публиковать сайты через генераторы наподобие Sphinx, применять сложные разметки вроде DITA, вести базы знаний в Confluence или вообще собирать файлы в Word. У каждого инструмента и подхода есть свои плюсы и минусы. Выбор зависит от множества факторов: сложности, требований к результату, потребителя контента, бюджета отдела, объема накопившегося легаси — да и просто моды в профессиональной среде.

Но что если посмотреть на вопрос с другой стороны? Что если выбирать и проектировать систему документирования исходя из того, сколько свободы предоставляется техническому писателю?

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

Привет, Хабр!

Меня зовут Александр Коробко, я занимаюсь продуктовым маркетингом в Positive Technologies. Эту статью мы подготовили вместе с моим коллегой Семёном Костромичевым — он отвечает за развитие технологии управления активами aka Asset Management.

Представьте ситуацию: вы — безопасник, и вам нужно следить за тем, чтобы в инфраструктуре компании не было уязвимостей, которые могут использовать хакеры. Но недостатков безопасности может быть много, со всеми справится нереально, поэтому необходимо выбрать самые критичные и начать с их. Например, один из них — критическая уязвимость в ОС на ноутбуке кого-то из коллег,  а вы не знаете, кому именно он принадлежит ноутбук. Смотрите в Excel, а там сотрудник уволился полгода назад, железо передали стажеру, но в базу не внесли. Знакомо?

Привет, Хабр! Хочу поделиться честной историей, в которой мое желание избавиться от рутины, любовь к разработке, open source и enterprise переплелись самым тесным и неожиданным образом. Четыре года назад я всего лишь хотел делать свою восьмичасовую работу за пару часов, а остальное время отдыхать , добавить во внутренний тулинг удобные кнопочки и меню, используя свой опыт разработки, но все пошло не по плану, и я сначала стал разработчиком своего собственного инструмента VSCode-XP (open-vsx.org, marketplace.visualstudio.com), потом его мейнтейнером на GitHub, продвигал его использование среди экспертов на профильных конференциях. Потом наработанный открытым сообществом опыт перенял enterprise-продукт и получилась история в стиле Толкиновского «Хоббита, или Туда и обратно».

Open source инструменты удобны для разработчика: настраиваешь их под себя и не зависишь от чужих правил, ценников и внезапных ограничений. Плюс вокруг них обычно есть живая документация и комьюнити — проблемы и решения редко остаются «в вакууме».

Собрали с командой R&D список инструментов, которыми сами пользуемся ежедневно. В подборке — опенсорсные инструменты для разных ситуаций: от работы с Kubernetes и контейнерными реестрами до тестирования API, проверки чужих репозиториев и runtime‑наблюдения за безопасностью контейнеров.