-
Похожий контент
-
-
От m1pod
Доброго времени точно такая же проблема, как я понял это троян. Простыми антивирусами не удаляется. Не знаю что делать. Выполнил всё вышеперечисленное, прикрепляю архив
DESKTOP-7C276PF_2025-03-03_23-49-45_v4.99.10v x64.7z
Сообщение от модератора Mark D. Pearlstone Перемещено из темы.
-
От KL FC Bot
Сразу после католического Рождества стало известно о многоэтапной атаке на разработчиков популярных расширений Google Chrome. Самой известной целью по иронии судьбы стало ИБ-расширение от компании Cyberhaven, скомпрометированное прямо перед праздниками (о таких рисках мы предупреждали). По мере расследования инцидента список пополнился как минимум 35 популярными расширениями с суммарным числом установок 2,5 млн копий. Целью злоумышленников является похищение данных из браузеров пользователей, которые установили троянизированные обновления расширений. В ходе данной кампании преступники фокусировались на похищении учетных данных от сервисов Meta* с целью компрометации чужих бизнес-аккаунтов и запуска своей рекламы за чужой счет. Но, в теории, вредоносные расширения позволяют похищать и другие данные из браузера. Рассказываем о том, как устроена атака и какие меры принять для защиты на разных ее этапах.
Атака на разработчиков: злоупотребление OAuth
Чтобы внедрить троянскую функциональность в популярные расширения Chrome, преступники разработали оригинальную систему фишинга. Они рассылают разработчикам письма, замаскированные под стандартные оповещения Google о том, что расширение нарушает политики Chrome Web Store и его описание необходимо скорректировать. Текст и верстка сообщения хорошо мимикрируют под типовые аналогичные письма Google, поэтому для жертвы письмо выглядит убедительно. Более того, во многих случаях письмо отправляется с домена, специально зарегистрированного для атаки на конкретное расширение и содержащего название расширения прямо в имени домена.
Клик по ссылке в письме приводит на легитимную страницу аутентификации Google. Пройдя ее, разработчик видит еще один стандартный экран Google, предлагающий авторизоваться по OAuth в приложении Privacy Policy Extension и в рамках входа в это приложение дать ему определенные права. Эта стандартная процедура проходит на легитимных страницах Google, только приложение Privacy Policy Extension запрашивает права на публикацию расширений в Web Store. Если разработчик дает такое разрешение, то авторы Privacy Policy Extension получают возможность публикации обновлений в Web Store от лица жертвы.
В данном случае атакующие не крадут пароль и другие реквизиты доступа разработчика, не обходят MFA. Они просто злоупотребляют системой Google по делегированию прав, чтобы выманить у разработчика разрешение на обновление его расширения. Судя по длинному списку зарегистрированных злоумышленниками доменов, они пытались атаковать гораздо больше, чем 35 расширений. В тех случаях, когда атака проходила успешно, они выпускали обновленную версию расширения, добавляя в него два файла, ответственные за кражу куки-файлов и других данных Facebook** (worker.js и content.js).
View the full article
-
От KL FC Bot
Чуть больше года назад в посте Google OAuth и фантомные аккаунты мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга. Недавно выяснилось, что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.
Как работает аутентификация при использовании «Вход с аккаунтом Google»
Некоторые могут подумать, что, доверяя опции «Вход с аккаунтом Google», компания получает надежный механизм аутентификации, использующий продвинутые технологии Google и широкие возможности интернет-гиганта по мониторингу пользователей. Однако на деле это не так: при входе с Google OAuth применяется достаточно примитивная проверка. Сводится она, как правило, к тому, что у пользователя есть доступ к почтовому адресу, который привязан к Google Workspace организации.
Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.
Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:
В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты. Источник
View the full article
-
От Bercolitt
Если попытаться зайти в свой почтовый ящик mail.yandex через аккаунт с неправильным паролем, форма входа в аккаунт начинает быстро моргаться не реагируя на команды управление. Такое впечатление, что идет подбор пароля в автоматическом режиме. После перезагрузки закладки браузера, учетная запись ящика блокируется.
Если в приложении Kaspersky Password Manager с одним почтовым сервером связаны несколько учетных записей, то выбрать конкретную учетную запись для переходла не получается. Видишь одну учетную запись, а улетает совсем по другой.
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти