No More Phish
4 subscribers
18 photos
2 videos
1 file
13 links
Веб-сервис обнаруживает домены с похожими именами торговых марок, которые могут неправомерно использовать бренд, в том числе для распространения фишинга
Download Telegram
Forwarded from FrontSecOps (Михаил Парфенов)
Frontend-фишинг с использованием JS Notification / Push API

Эти API предоставляют js-коду 📱 возможность показывать нативные уведомления браузера на устройстве пользователя. Push API (в отличии от Notification API) может показывать уведомления даже при закрытой вкладке браузера ⚠️, а на мобильных устройствах даже при закрытом браузере, поэтому рассмотрим именно его.

Исходные данные

Наше frontend-приложение уже запрашивало разрешение на показ уведомлений либо запросит, и пользователи согласятся (доверяют нашей компании).

В случае с мобильными устройствами пользователи добавили наше web-приложений на экран "Домой", что дает web-приложению права PWA (progressive web app), в том числе права на отправку push-уведомлений.

Предположим, что в ваш проект попал вредоносный js-код (с новыми версиями зависимостей, в результате компрометации сервера, сгенерирован "плохой" нейросетью и т.д.), а именно в код Service Worker (требование для вызова Push API, для Notification API в любое место в js-коде).

Злоумышленник получает возможность подключиться к своему серверу push-уведомлений и показывать пользователю нативные уведомления с любой картинкой/текстом/возможностью при клике редиректить пользователя на любой сайт⚠️. Это открывает безграничные возможности для фишинга 🤒

⚠️С вашего счета произведен перевод денег..
⚠️Заказ № 123456 оформлен, сумма 14 793 руб., дата доставки..
⚠️Обнаружен вирус на устройстве, выберите действие..
⚠️Ваш почтовый ящик заблокирован..
⚠️Кто-кто входит в ваш аккаунт..

Далее - кража учетных данных 🪪, загрузка вредоносного вложения с эксплойтом 💣 и т.п.

На Desktop и Android в push-уведомлении можно показать любую картинку (логотип банка, мессенджера, популярного приложения). В iOS всегда будет отображаться иконка нашего сайта.

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

Злоумышленники "хотят" наш frontend больше 💰, чем мы думаем… А уязвимости браузеров 📱 🌐 делают frontend-приложения идеальной точкой проникновения на устройства пользователей.

Как защититься?

🔹Контролировать использование WebAPI в frontend-приложении: Service Worker API, Push API, Notification API
🔹Контролировать целостность js-кода, включая код Service Worker
🔹Проводить инвентаризацию js-кода, включая динамически загружаемый, в runtime браузера при выполнении основных E2E-сценариев
🔹Контроль при каждом релизе и периодически в продакшене + реагирование

@FrontSecOps
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from AlexRedSec
Свежее исследование "Different Seas, Different Phishes" о нашем любимом: фишинговых симуляциях и попытках найти закономерности в поведении сотрудников🎣
В данной работе был проведен анализ 96 кампаний фишинговых симуляций, охвативших 36 организаций из различных секторов экономики, что довольно масштабно по сравнению с предыдущими аналогичными исследованиями.
Ниже описал главное и/или интересное.

Эффективность различных параметров фишинга:
🎯 Сценарии целевого фишинга (ожидаемо) повышали кликабельность на 22% по сравнению со сценариями массового фишинга.
🤑 Сценарии типа "Не упусти выгоду" демонстрировали на 18% более высокую вовлеченность, чем сценарии компрометации аккаунта, что подчеркивает эффективность страха упущенной выгоды (FOMO, привет!) по сравнению со страхом угрозы безопасности.
🧐 Повышение сложности шаблона давало лишь 6% роста кликабельности, что указывает на главенствующую роль психологического фактора и фактора контекста.

Межотраслевые и внутриорганизационные различия:
Организации сектора промышленности и производства показали на 41% меньше уровень кликабельности, чем сфера услуг, что связано с автоматизированными процессами и меньшей зависимостью от почтовых коммуникаций.
👨‍💻 Отделы маркетинга и продаж продемонстрировали более чем в два раза большую подверженность фишинговым симуляциям по сравнению с финансовым департаментом. Это различие может объясняться несколькими факторами: сотрудники финансовых департаментов, возможно, более осторожны с электронной почтой из-за характера их работы с конфиденциальной финансовой информацией, в то время как сотрудники отделов продаж и маркетинга могут быть более склонны к активному взаимодействию с внешними контактами и новыми возможностями.
👨‍💻 Менеджеры среднего звена на 15% чаще взаимодействовали с фишинговыми письмами, чем топ-менеджеры, что опровергает стереотип о большей уязвимости высшего руководства.

Рекомендации ИБ-специалистам:
➡️При построении системы защиты необходимо учитывать коммуникационные паттерны и рабочие процессы свойственные конкретной индустрии.
➡️При проведении тренингов также необходимо учитывать специфику работы различных департаментов, в т.ч. нюансы коммуникаций с "внешним миром".
➡️ Использование фишинговых симуляций с прогрессивно увеличивающейся персонализацией позволяет точнее оценивать реальную уязвимость организации, чем статичные тесты на базе шаблонных сценариев.

Также, авторы исследования подсветили, что в публичных отчетах вендоров решений security awareness human risk management сообщается о более высоких показателей кликов, что может свидетельствовать о предвзятой оценке, направленной на увеличение продаж их продуктов😏

#awareness #phishing #training #risk #hrm #simulation
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Год назад ICANN полностью перевела доступ к данным регистрации доменных имён в зонах gTLD с устаревшего протокола WHOIS на современный и безопасный RDAP (Registration Data Access Protocol).

🔹 Что изменилось?
— WHOIS больше не будет поддерживаться как основной источник данных.
— Все запросы о регистрации теперь должны направляться через RDAP — протокол, разработанный IETF с учётом требований безопасности, международной совместимости и гибкого контроля доступа.
— RDAP поддерживает различные методы аутентификации, HTTPS, структурированный JSON-формат и возможность дифференцированного доступа: данные можно разделять по уровням — публичные (для всех) и непубличные (для спецслужб, судов, кибербезопасников).

👨‍💻 Что делать разработчикам и SOC-командам?
— Новые gTLD могут не поддерживать RDRS в периходный период, поэтому лучше реализовать поддержку обоих протоколов.
— Интегрировать ICANN Lookup API или использовать публичные RDAP-адреса регистраторов.
— Настроить процессы запроса непубличных данных через RDRS — особенно если вы работаете в сфере кибербезопасности, защиты брендов или расследования инцидентов.

💡 Полезные ссылки
Новость о переходе
ICANN Lookup
— Документация по RDAP: RFC 7480-7483, 8521, 8056.

VK Telegram
#RDAP #WHOIS #ICANN