Новый банковский Android-троян MaliBot обходит 2SV Google

Новый банковский Android-троян MaliBot обходит 2SV Google

Новый банковский Android-троян MaliBot обходит 2SV Google

Эксперты F5 обнаружили в дикой природе нового банковского трояна для Android, способного воровать учетные данные, куки и коды двухфакторной аутентификации (2FA). Многофункциональный зловред, нареченный MaliBot, также активно взаимодействует с оператором, открывая VNC-доступ к зараженному устройству.

Анализ опасной находки показал, что это сильно измененный и доработанный код банкера SOVA, с другим набором функций, мишеней, адресов C2 и методов упаковки. В настоящее время вредонос досаждает в основном жителям Испании и Италии; список интересующих его банков включает UniCredit, Santander, CaixaBank и CartaBCC. 

Распространяется MaliBot через мошеннические сайты, чаще всего под видом некого приложения Mining X или популярного кошелька CryptoApp (оригинал в Google Play собрал более 1 млн загрузок). Иногда встречаются и другие маскировочные имена — MySocialSecurity, Chrome. 

Чтобы заманить владельцев Android на вредоносные сайты, операторы зловреда используют смишинг: MaliBot умеет по команде проводить групповые СМС-рассылки, получая текст (с URL) и список адресатов с C2-сервера. Последний находится в России и некогда использовался для распространения файлового вируса Sality.

Функции нового Android-трояна многочисленны и разнообразны и включают следующие возможности:

  • сбор информации о зараженном устройстве (IP-адрес, AndroidID, модель, используемый язык, список установленных приложений, текущее состояние); 
  • журналирование выполняемых операций (успех, провал, ошибки) и событий телефонии (вызовы, СМС);
  • запуск и удаление приложений;
  • отправка СМС;
  • проведение оверлейных и инжект-атак;
  • кража данных из криптокошельков (Binance и Trust);
  • кража кодов MFA/2FA, в том числе из Google Authenticator;
  • кража куки;
  • кража СМС;
  • обход двухэтапной аутентификации Google;
  • обеспечение VNC-доступа и захват экрана.

Для выполнения своих задач в полном объеме троян после запуска подключается к C2-серверу и запрашивает у жертвы разрешение на доступ к специальным возможностям Android (Accessibility Service). С той же целью он регистрирует службы фоновой обработки, записи экрана, Accessibility, уведомлений (чтобы надоедать жертве, если она не дает доступ к спецвозможностям), а также приемники для перехвата СМС, звонков, сигналов тревоги и регистрации boot-активности.

Возможность использования Accessibility API и прямая связь с зараженным устройством позволяют оператору MaliBot обойти 2FA-преграды Google и войти в аккаунт жертвы со своего компьютера, используя украденные идентификаторы. Резидентный зловред при этом работает с окнами подсказок, нажимая нужные кнопки и вводя одноразовый код, высланный на C2-машину.

В Google Chrome усложнили кражу cookie — новая защита от угона сессий

Google перевела функцию Device Bound Session Credentials (DBSC) в общую доступность для пользователей Chrome на Windows. Теперь эта защита работает в Chrome 146 и должна заметно осложнить жизнь тем, кто крадёт сессионные cookies, чтобы потом входить в чужие аккаунты без пароля.

Принцип работы DBSC кроется в том, что браузер не просто хранит cookie, а криптографически привязывает сессию к конкретному устройству.

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

Особенно актуально это на фоне популярности так называемых инфостилеров. Такие вредоносные программы собирают с заражённых устройств всё подряд: пароли, данные автозаполнения, токены и, конечно, cookie. Этого бывает достаточно, чтобы злоумышленник зашёл в учётную запись жертвы, даже не зная её пароль. Потом такие данные нередко перепродают другим участникам киберпреступного рынка.

 

DBSC должна ломать именно такой сценарий. На Windows технология опирается на Trusted Platform Module, а на macOS — на Secure Enclave. С их помощью создаётся уникальная пара ключей, причём закрытый ключ не покидает устройство. Когда сайту нужно выдать новую короткоживущую cookie, Chrome должен доказать, что у него есть нужный закрытый ключ. Если ключ не на том устройстве, схема просто не срабатывает.

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

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

Пока публичный запуск ограничен Windows-пользователями Chrome 146, но Google уже подтвердила, что поддержку macOS добавят в одном из следующих релизов. Компания также заявила, что после начала внедрения DBSC уже заметила заметное снижение случаев кражи сессий.

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