Сотрудники российских компаний чаще клюют на фишинг от службы безопасности

Сотрудники российских компаний чаще клюют на фишинг от службы безопасности

Сотрудники российских компаний чаще клюют на фишинг от службы безопасности

Фишинг наиболее эффективен в том случае, если письма приходят от «службы безопасности». К такому выводу пришли аналитики из «Лаборатории Касперского», изучив поведение сотрудников российских компаний.

Собрать статистику помогла Kaspersky Automated Security Awareness Platform: служащие получали тестовые фишинговые письма, которые маскировались под сообщения от службы безопасности.

Интересно, что по вредоносной ссылке под таким прикрытием перешли почти 30% сотрудников. При этом 28% пользователей поверили уведомлениям о нарушении корпоративной политики использования веб-сервисов.

Чуть хуже отработала финансовая легенда: 24% работников открыли письма, в которых речь шла об изменениях в заработной плате. 23% клюнули на уведомления о налоговых задолженностях.

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

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

Российские провайдеры начали глушить защищённые DNS Google и Cloudflare

Пользователи сразу нескольких российских операторов пожаловались на проблемы с защищёнными DNS-сервисами Google и Cloudflare. Под ударом оказались протоколы DNS over HTTPS (DoH) и DNS over TLS (DoT), которые шифруют DNS-запросы и не позволяют провайдеру запросто подсматривать, к какому домену обращается пользователь.

По данным телеграм-канала bypassblock, сбои затронули абонентов «Ростелекома», «Дом.ру», «Таттелекома» и петербургского SkyNet.

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

При подключении к Cloudflare по адресам 1.1.1.1 и 1.0.0.1 через порт 853 TCP-рукопожатие проходит успешно, после чего соединение принудительно сбрасывается с ошибкой ECONNRESET — ещё до завершения TLS-аутентификации.


С Google Public DNS картина другая. Соединение с dns.google, 8.8.8.8 и 8.8.4.4 через порт 443 устанавливается, но после отправки TLS ClientHello ответы прекращаются.

Сессия либо висит до тайм-аута, либо завершается ошибкой unexpected eof while reading. Такое поведение может указывать на вмешательство промежуточного оборудования и фильтрацию по сигнатуре.

Симптомы различаются в зависимости от оператора и региона: у одних пользователей не работает только DoT, у других — DoH, а некоторым достался полный комплект. Техподдержка «Таттелекома» якобы прямо рекомендовала одному из абонентов отключить оба протокола для восстановления доступа.

Официального подтверждения централизованной блокировки пока нет. Однако совпадение сбоев у нескольких провайдеров и одновременные проблемы у Google и Cloudflare выглядят слишком сильно для обычной случайности.

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