Индустрия программ-вымогателей как услуги часто ассоциируется с высоким уровнем профессионализма и скрытности, однако реальность может быть гораздо прозаичнее. История Devman, начинающего русскоязычного оператора, пытающегося построить собственный RaaS-бренд, наглядно демонстрирует, как элементарные ошибки в операционной безопасности (OpSec) могут привести к полной компрометации внутренних процессов и репутационному краху ещё до того, как проект наберёт обороты. Этот случай служит важным напоминанием для специалистов по кибербезопасности о том, что даже потенциально опасные группы могут допускать детские промахи, оставляя цифровой след, который позволяет аналитикам заглянуть в самую кухню преступного бизнеса.
Описание
Devman, также известный в открытых источниках как @Inifintyink, начал свою деятельность в апреле 2025 года в качестве аффилиата (партнёра) для уже известных семейств программ-вымогателей Qilin и DragonForce. Однако к лету он решил создать собственный продукт, по сути, модифицировав код DragonForce, и к концу сентября 2025 года анонсировал публичную RaaS-платформу под собственным именем. Проблемы начались практически сразу. В мае исследователь Ракеш Кришнан обнародовал публичный IP-адрес, связанный с его скрытым сервисом в сети Tor, что стало первым публичным провалом. А в июле анализ компании Any.Run показал, что его "новая" программа-вымогатель является всего лишь ребрендингом DragonForce с критическим багом, из-за которого вредоносное ПО шифровало собственный файл с инструкциями по выплате выкупа.
Однако настоящая катастрофа для операционной безопасности Devman произошла дважды, с интервалом всего в месяц, и оба раза по одной и той же причине. В конце сентября 2025 года была скомпрометирована его внутренняя коммуникационная платформа на базе Rocket.Chat, о чём сообщили авторы блога te.mpe.st. Шокирующим образом, всего через месяц, в конце ноября, та же история повторилась. Аналитикам удалось получить доступ к новому экземпляру Rocket.Chat, который Devman использовал для координации действий своих аффилиатов, и извлечь переписку за период с 19 ноября по 3 декабря. Причём сервер, размещённый по адресу 203.91.74[.]97, оставался небезопасно сконфигурированным и доступным из интернета даже к середине декабря, что говорит о системном пренебрежении базовыми принципами безопасности.
Анализ этих приватных сообщений раскрывает внутреннюю кухню RaaS-операции. Devman выступает в роли координатора, распределяя между аффилиатами доступы к уже скомпрометированным сетям жертв. В ноябре в его распоряжении, по собственным заявлениям, были сети одной организации в Норвегии и четырёх в США, включая два полицейских участка. Интересно, что начальное проникновение часто осуществлялось через уязвимости или неправильные конфигурации межсетевых экранов FortiGate, что позволяло быстро получать права администратора домена. Аффилиаты должны были завершать атаку на одну сеть в течение 2-3 дней, прежде чем запрашивать новую жертву, что указывает на конвейерный подход к работе. В переписке также фигурирует помощник под псевдонимом jokerx, который курировал доступы наравне с Devman, и упоминается использование фреймворка для командования и управления Sliver C2.
Особенно показательными являются примеры плохого управления и абсурдных ситуаций. В октябре Devman, подобно менеджеру кол-центра, требовал от аффилиатов указывать в своих профилях рабочие часы, чтобы "знать, кого куда ставить". Когда жертва сообщила о неработающей ссылке для связи, Devman пафосно заявил в чате "ёбать я машина нахуй", а его соратник blackwall предложил в ответ разместить чат для жертв в открытом интернете, поскольку "многие компании не могут заходить в даркнет". Кроме того, группа проявила поразительную безрассудность, обсуждая атаку на то, что они сами подозревали в израильской ловушке (honeypot), с мотивацией "ок, давайте эксплуатировать, почему нет".
Эти утечки коммуникаций не просто раскрывают тактики, техники и процедуры (TTP) группы. Они демонстрируют фундаментальную проблему: в экосистеме RaaS, построенной на доверии аффилиатов, постоянные технические сбои, небезопасные каналы связи и непрофессиональное поведение быстро подрывают репутацию. Devman пытается представить себя серьёзным игроком, обновляя панель управления, добавляя новых жертв (часто из сферы здравоохранения в регионах со слабой киберзащитой) и ведя активность в соцсетях. Однако его платформа для утечек данных пока функционирует скорее как доска объявлений, а не как полноценный архив, а постоянные провалы в безопасности говорят о системной незрелости.
История Devman - это не просто анекдот из мира киберпреступности. Для специалистов по защите это напоминание о том, что даже за сложными атаками могут стоять неорганизованные группы, чья слабость часто кроется в человеческом факторе и пренебрежении базовой гигиеной цифровой безопасности. Мониторинг открытых источников, анализ утечек из подобных чатов и отслеживание низкоуровневых технических ошибок (таких как оставленные в открытом доступе серверы Rocket.Chat или связь скрытых сервисов с публичными IP-адресами) остаются мощными инструментами проактивной защиты и угрозного интеллекта. Падение Devman началось не с обнаружения сложного вредоносного кода, а с элементарной небрежности, и это, пожалуй, самый важный урок этой истории.
Индикаторы компрометации
IPv4
- 203.91.74.97
- 86.106.85.183
