Банковский троян Ramnit возобновляет свою активность

Банковский троян Ramnit возобновляет свою активность

Банковский троян Ramnit возобновляет свою активность

Исследователи IBM объявили о том, что после восьмимесячной паузы троян Ramnit возвращается с новым командным центром.

Ramnit был впервые обнаружен в 2010 году, тогда он представлял собой червя с функцией самокопирования. Однако с тех пор зловред очень сильно эволюционировал, злоумышленники решили сделать из него банковский троян. В 2011 Ramnit позаимствовал многие функции у Zeus, чей исходный код просочился в сеть, и с тех пор является полноценным банковским трояном со своим центром управления и списком целей.

Исследователи в области безопасности отмечают, что после долгого периода бездействия авторы Ramnit запустили в июле кампанию, которая ориентировалась на шесть крупных банков в Соединенном Королевстве.

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

Тем не менее, некоторые изменения все же наблюдаются – модуль Hooker был улучшен и переименован в Grabber.

«Также известный как Spy, этот модуль предназначен для подключения к браузеру жертвы, мониторинга URL, это позволяет красть данные в режиме реального времени», - объясняет Limor Kessem, эксперт IBM.

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

Кроме этого, Ramnit имеет модуль Virtual Network Computing (VNC), но не использует его сразу. Это происходит по усмотрению злоумышленника – если он сочтет нужным, то командный центр отдаст команду трояну загрузить модуль VNC.

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

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Исследователь безопасности Дэвид Лидбитер обнаружил уязвимость в OpenSSH — CVE-2025-61984 — которая демонстрирует: даже мелкие особенности парсинга команд и поведения shell могут привести к удалённому выполнению кода.

Суть проблемы проста и неприятна: в OpenSSH (до версии 10.1) контрол-символы в именах пользователей, полученных из ненадёжных источников, могли не отфильтровываться.

Когда такое «имя» подставлялось в ProxyCommand (через переменную %r), OpenSSH формировал строку для exec, которую запускал через shell. Если в этой строке оказывались символы вроде $[ и символы новой строки, некоторые оболочки (например, bash) могли интерпретировать это так, что первая команда аварийно завершается, а затем выполняется то, что идёт после — то есть возможна инъекция команды.

Эксплуатация требует специфической связки: конфигурация, использующая ProxyCommand с %r, уязвимая оболочка и «входной» источник имени пользователя, который злоумышленник контролирует. Практический пример — злоумышленный .gitmodules, где в URL подставляют строку вроде:

[submodule "foo"]
  path = foo
  url = "$[+]\nsource poc.sh\n@foo.example.com:foo"

Если SSH-конфиг содержит строку вроде

ProxyCommand some-command %r@%h:%p

и вы запускаете git clone --recursive, то в подходящих условиях может выполниться source poc.sh — до установления самого соединения.

Важно понимать: условия для успешной атаки нишевые, но реальны — инструментальная цепочка Git → SSH → shell и автоматизация (CI/CD) дают атакующему много точек входа. Проблема усугубляется тем, что OpenSSH фильтровал многие метасимволы, но пропустил $ и [ — и это создало неожиданный вектор.

Исправление уже включено в OpenSSH 10.1: разработчики начали проверять и запрещать управляющие символы в именах пользователей через iscntrl() в ssh.c. То есть долгосрочное решение — обновиться до 10.1 или новее.

Если обновиться сразу нельзя, Лидбитер предлагает два практических временных шага. Во-первых, брать имя пользователя в одинарные кавычки в ProxyCommand, чтобы предотвратить подстановку:

ProxyCommand some-command '%r@%h:%p'

(Обратите внимание: одинарные кавычки нужны именно потому, что двойные не защитят от $[ — оболочка всё ещё будет их обрабатывать.) Во-вторых, по умолчанию отключить SSH-подмодули в Git и не позволять автоматические URL-хендлеры, которые могут передавать непроверенные SSH-команды:

git config --global protocol.ssh.allow user

Главный вывод — не полагаться на то, что «маленький» символ или строка не принесут беды: при передаче входа от ненадёжных источников через несколько инструментов даже неочевидная каверза в парсинге может стать критической. Рекомендуется как можно скорее обновить OpenSSH или применить временные защитные меры в конфигурациях ProxyCommand и политиках Git.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru