"No system is safe" –

Command & Conquer: Generals (2003)

Как говорили китайские юниты в С&С: Generals "No system is safe" – все системы уязвимы. И люди уязвимы не меньше. Про фишинг вроде бы все знают, но он по-прежнему остаётся самым популярным и результативным методом получения доступов и данных. В частности в сезоны праздников или распродаж, когда атакующие особенно активны. 

Компании нередко рассказывают на Хабре истории об отправке «учебных» фишинговых писем клиентам или сотрудникам. Мы тоже поделимся деталями предновогодней атаки на собственных сотрудников, о которой не знала даже команда реагирования безопасности (SOC). В статье вас ждёт процесс подготовки, схема атаки, а также поминутная хроника событий.

Дисклеймер: местами в тексте намеренно опущены детали и точные цифры/данные, чтобы не упрощать жизнь злоумышленникам. Мы знаем, что детали важны читателям Хабра и приводим интерпретированные данные, но всё же безопасность в первую очередь.   

Решаем проверить уязвимость

Одна из задач команды Application Security — поиск уязвимостей в продуктах компании. В ноябре 2022 года мы как раз нашли простую и эффективную для внешней атаки уязвимость. Сообщили о ней команде разработчиков, и заодно решили проверить потенциальные риски. 

Для атаки решили выбрать не классический вариант фишингового письма, а APT-атаку (Advanced Persistent Threat) – вид таргетированной кибератаки на конкретную компанию. Руководитель департамента безопасности согласился с идеей, но попросил сначала напомнить коллегам о существовании почтового фишинга как такового. Поэтому мы подготовили и раскатили на сотрудников обучающий курс по антифишингу в дополнение к существующим процедурам обучения согласно PCI DSS регламентам. 

В итоге идея с фишинговым письмом позволила бы нам не только оценить масштаб уязвимости и её критичность, но заодно и:

• Напомнить коллегам, как распознать подозрительное письмо и что с ним делать.

• Оценить эффективность обучения.

• Понять, насколько быстро мы узнаем об атаке и сможем устранить её последствия. 

• Улучшить внутренние процессы реагирования.

Запускаем обучающий курс для сотрудников

Материал для курса по Антифишингу команда Application Security написала за день. Коллеги из Training & Development перенесли материалы на платформу обучения iSpring и раскатили их на сотрудников. Людям пришло письмо с просьбой пройти пятнадцатиминутный курс: в нём 15 слайдов и короткий интерактивный тест. До обозначенного дедлайна была неделя. 

Курс был назначен для 700 сотрудников, из них 35% прошли его до конца.

Готовим атаку

Пока сотрудники знакомились с материалами курса, мы готовили атаку. О ней в компании знали всего несколько человек: 

• Команда Application Security. 

• IT Head департамента Security & Risk Management.

• CEO. 

Команды реагирования, которым предстояло защищаться от атаки и расследовать её, о плане с фишинговым письмом ничего не знали. 

Одни из самых успешных APT-атак требовали и требуют не только хорошей технической подготовки, но и социально-инженерной. В идеале таргет (то есть атакуемый) должен ожидать похожее по смыслу письмо, и оно должно легко вписываться в его картину мира. 

Во время нашего эксперимента на дворе как раз был «высокий сезон» для атак: сотрудники должны были пройти курс по фишинговым письмам до 8 декабря. Отсюда появилось содержание письма: компания запускает внутренний магазин, а пока он в разработке, сотрудник может выбрать себе новогодний подарок. 

Целью атаки была проверка уязвимости, параллельно сохранялась часть вводимых данных и cookies. Для чистоты эксперимента никакая внутренняя информация в подготовке не использовались: атакующие собрали информацию по внешним источникам, как это могли бы сделать настоящие злоумышленники. Команда Application Security не обращалась к корпоративным дизайнерам и не использовала корпоративный шаблон для писем. 

Чтобы сделать фишинговую атаку на сотрудников максимально таргетированной, понадобились:

• Дизайн и текст для нескольких писем: разные группы людей получили одинаковые по смыслу, но чуть разные по содержанию письма.

• Несколько новых доменов и их поддоменов. Разным группам получателей письма приходили с разных доменов и от разных адресатов. Мы использовали привычные корпоративные слова, такие как info или hr. 

• Несколько landing (посадочных) страниц, на которые вели ссылки из писем. На каждой из страниц была форма авторизации для сбора логинов и паролей. 

• Своя инфраструктура и сервис, который сохранял вводимые логины и пароли. При переадресации мы использовали найденную ранее уязвимость в продукте и собирали cookie. 

• Дашборд, который в режиме реального времени показывал, кто открыл письмо, кто перешёл по ссылке, кто ввёл данные. 

Вот как выглядела схема атаки:

Команда Application Security:

• Развернула фреймворк Gophish на VPS-сервере.

• Зарегистрировала домен, созвучный с названием компании.

• Сгенерировала SSL-сертификат и настроила SSL-соединение.

• Создала разные фишинговые страницы в зависимости от «типа» пользователя.

• Приготовила всё необходимое для старта рассылки.

Отправляем письмо и следим за ситуацией

Днём атаки стало 8 декабря. Вот как развивались события.

11:13. Сотрудникам начинают приходить фишинговые письма. 

11:17. Первый человек пишет в публичный канал команды безопасности.

Это критически важный момент. Время от начала атаки до того, как о ней узнаёт команда безопасности, — это одна из основных метрик, Mean Time to Detect (MTTD). Не зная об атаке или инциденте, трудно среагировать на ситуацию и начать эффективное расследование.

На сокращение этой метрики направлены многие внутренние активности Security-команд. Мы создали для сотрудников понятный канал связи и безопасную среду без осуждения. У нас нет практики штрафов, напротив, мы максимально продвигаем решение делиться всем подозрительным как единственно верное.

11:17. Дежурный инженер SOC сразу тегает свою команду, чтобы коллеги обратили внимание на ситуацию. Он также просит сотрудника, сообщившего о подозрительном письме, прислать его вложением в [специальное место].

11:18. Ещё несколько сотрудников отписываются в треде, что получили похожее письмо, и пересылают примеры, в которых видны различные отправители. 

11:19. Команда SOC спрашивает в треде всех сотрудников, ответственных за коммуникации в компании, их ли это активность. В течение пары минут все отписываются, что нет, это не наше.

Параллельно с этим ещё несколько сотрудников сообщают, что открыли письма и перешли по ссылке, но не вводили данные. Они просят изменить их пользовательские учетные данные (пароль). 

11:20. Инженер SOC присылает первую инструкцию в том же треде: всем убедиться, что на устройстве установлен корпоративный антивирус, установить его, если нет, и самостоятельно сменить пароль к корпоративной учётке по указанной ссылке. 

Важно! В этот момент количество открытий письма и переходов по ссылке заметно упало.  

11:21. Представитель SOC пишет в общий чат компании, где есть все сотрудники, сообщение о подозрительном письме с инструкцией не переходить по ссылкам и немедленно сменить пароль от корпоративной учетной записи, если вдруг по ссылке перешли. Аналогичное сообщение отправляется всем на корпоративные почты на случай, если человек пропустит уведомление в Slack.

17:12. Внутренние коммуникации отправляют в общий чат сообщение о том, что атака была тренировочной, и напоминанием пройти курс по распознаванию фишинговых писем.  

Анализируем результаты

Мы планировали отправить все письма за 3-5 минут, но из-за публичного сервера-посредника время доставки чуть растянулось. Поэтому финальные цифры по эксперименту будут не совсем релевантными: часть сотрудников сначала увидела сообщения SOC, а только потом фишинговое письмо. Конечно, ни на какие ссылки они при этом не кликали и никакие учетные данные не оставляли. 

В статье мы можем привести только интерпретированные данные: 

1. Мы отправили 666 писем.

2. 2/3 сотрудников перешли по ссылке из фишингового письма и ввели свои учетные данные.

3. Несколько человек попробовали ввести другие логины и пароли (вероятно, предыдущие или от других сервисов), когда не получилось авторизоваться в форме на посадочной странице.

4. Никто из сотрудников, прошедших курс, свои данные не вводил.

И, конечно, уязвимость в продукте мы исправили. 

Краткие выводы

1. Обучение сыграло свою важную роль: команда SOC узнала о подозрительном письме спустя 5 минуты от его отправки и начала действовать. 

2. Коммуникации действительно помогают. После появления первого сообщения и инструкций в общих чатах произошёл «иммунологический ответ»: резкий спад количества кликов и попыток авторизоваться на лендинге. 

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

4. Контролируемая атака позволила нам найти несколько слабых мест в процессах реагирования и улучшить их.  

5. Обучение оказало позитивное влияние на сотрудников. Часть коллег, которые не проходили курс по фишингу до тренировочной APT-атаки, завершили его после. 

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

Напомним о дисклеймере ещё раз: местами в тексте намеренно опущены детали и точные цифры/данные, чтобы не упрощать жизнь злоумышленникам. Мы знаем, что детали важны читателям Хабра и приводим интерпретированные данные, но всё же безопасность в первую очередь.