Письмо-приманку с трояном Bayrob маскируют под сообщение от Amazon

Письмо-приманку с трояном Bayrob маскируют под сообщение от Amazon

Письмо-приманку с трояном Bayrob маскируют под сообщение от Amazon

Международная антивирусная компания Eset предупредила о росте активности троянской программы Win32/Bayrob. Как сообщили в Eset, распространение Bayrob осуществляется классическим для этого вида ПО способом — в электронной рассылке.

Письмо-приманка замаскировано под официальное сообщение сервиса Amazon. В приложении к письму содержится ZIP-архив с исполняемым файлом. После запуска вредоносная программа выводит на экран сообщение об ошибке, чтобы убедить пользователя в ее безопасности. На самом деле Bayrob уже действует и используется атакующими в качестве бэкдора.

Как рассказали в Eset, основная цель операторов Bayrob — сбор данных для получения финансовой выгоды: сведений о банковских картах, паролей и логинов от онлайн-банкинга. Чтобы получить эту информацию, троян обращается к удаленному серверу, загружает другие вредоносные программы, запускает исполняемые файлы и отправляет собранные данные злоумышленникам.

Для контакта с удаленным сервером Bayrob генерирует различные URL-адреса, помимо используемого. Один из URL, обнаруженных специалистами Eset, зарегистрирован японским представительством Amazon. Вероятно, атакующие управляют зараженными ПК при помощи сервера, входящего в состав инфраструктуры Amazon Web Services. Это не означает, что скомпрометирована вся инфраструктура Amazon — сервер мог быть арендован официально третьими лицами, полагают в компании.

По данным Eset, первые модификации Bayrob обнаружены еще в 2007 г. С конца 2015 г. троян активно используется в атаках на пользователей стран Европы, Южной Африки, Австралии и Новой Зеландии. В январе большинство заражений приходилось на Испанию, Австрию, Германию и Италию.

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

Эксперты Eset рекомендуют игнорировать подозрительные письма от неизвестных отправителей. Антивирусные продукты Eset NOD32 детектируют новую вредоносную программу как Win32/ Bayrob.

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

Проще говоря, чем активнее подсистема используется и исследуется, тем быстрее там находят ошибки.

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

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