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

В этой статье команда департамента аудита и консалтинга Group-IB решила пойти дальше и поделиться своим опытом социотехнического тестирования, которое проводила в этом году. Расскажем, для каких целей использовать данный вид тестирования, какие форматы предпочитали компании, что лучше выбрать в следующем году, а также, каких результатов ждать.

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

С чего начинается социотехническое тестирование?

Тестирование начинается с формулирования целей. Именно цель определяет остальные составляющие:

• время на подготовку к тестированию
• объем разведывательных работ
• формат тестирования
• условия, которые должна обеспечить компания для старта работ
• стоимость тестирования (эту составляющую не обсуждаем в статье)

Для чего и как проводить такое тестирование?

Социотехническое тестирование может проводиться для установления:

• уровня осведомленности сотрудников и их практических навыков в распознавании социотехнических атак
• эффективности функционирования систем обеспечения информационной безопасности
• уровня подготовки сотрудников ИТ- и ИБ-отделов к выявлению и реагированию на социотехнические атаки (уровень осведомленности в вопросах безопасности данных сотрудников выше, что повышает сложность тестирования)
• возможности компрометации инфраструктуры (социотехническое тестирование может применяться для тестирования на проникновение)

Соотношение цели социотехнического тестирования (социальная инженерия или СИ) и других его составляющих представлено в таблице.

	Определить уровень подготовленности сотрудников	Определить эффективность функционирования СЗИ	Определить уровень подготовленности сотрудников ИТ- и ИБ-отделов	Компрометация инфраструктуры
Формат тестирования	• письма со ссылкой на поддельный ресурс (фишинг) • письма с исполняемым вложением (нагрузка) • телефонное взаимодействие (вишинг)	• письма со ссылкой на поддельный ресурс (фишинг) • письма с исполняемым вложением (нагрузка)	• письма со ссылкой на поддельный ресурс (фишинг) • письма с исполняемым вложением (нагрузка) • телефонное взаимодействие (вишинг)	• письма со ссылкой на поддельный ресурс (фишинг) • письма с исполняемым вложением (нагрузка)
Начальные условия	• ФИО сотрудников и email-адреса • номера телефонов, ФИО и/или должности сотрудников, а также любая другая информация согласно легенде • добавление в белые списки (email-адреса, домены, СЗИ и т.д.)	• ФИО сотрудников и email-адреса	• ФИО сотрудников и email-адреса • номера телефонов, ФИО и/или должности сотрудников, а также любая другая информация согласно легенде • добавление в белые списки (email-адреса, домены, СЗИ и т.д.)	• входная информация не предоставляется
Время на подготовку	Одна неделя	Две недели	Одна-две недели	Три недели

Теория, теория… Где же обещанные истории?

Да-да. Раз обещали рассказать про опыт и историями поделимся. Основные моменты мы расскажем немного позже — в кейсах. А сейчас немного отвлечемся на различные ошибки и просто любопытные моменты.

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

Как показывает практика, ошибки, вызванные недопонимаем сторон, встречаются достаточно часто. Например, со стороны компаний, заказывающих социотехническое тестирование, нас поджидали следующие неожиданности:

• затягивание согласования легенды и предоставления адресов почты для рассылки
• предоставление неактуального списка сотрудников
• многократная отработка одной легенды на одних и тех же сотрудниках
• загрузка подготовленной полезной нагрузки в используемое СЗИ (да-да, здесь речь про проверку осведомленности/подготовленности сотрудников, а не СЗИ...)
• добавление сотрудников ИТ/ИБ-отделов в рабочую переписку (при том что их уровень осведомленности и проверялся)

Но будем честны — эксперты тоже не застрахованы от подобных ошибок, влияющих на результаты тестирования. И вот одна из них:

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

Первое телефонное взаимодействие было успешным: ряд сотрудников, поддавшись на уговоры эксперта, совершили потенциально опасные действия.

Второе тестирование тоже: сотрудники поверили легенде и охотно выполнили все, о чем их попросили.

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

Шок! Как так? Поиск ошибки начали с повторной проверки списка сотрудников, заявленных на каждое из трех тестирований. Совпадений нет. Потом проверили номера телефонов… И вот он — один номер телефона, только в первом тестировании он заявлен для Ивановой Анны Сергеевны, а в третьем — для Петровой Анны Сергеевны (здесь и далее используются вымышленные имена). За время, прошедшее между тестированиями, девушка сменила фамилию.

В ходе первого тестирования Иванова Анна Сергеевна поверила в легенду и выполнила все действия, следуя указаниям эксперта, а вот Петрова Анна Сергеевна быстро поставила на место нерадивого эксперта.

Получается, что ошибка была допущена на этапе подготовки: эксперт проверил только фамилии сотрудников, но проигнорировал номера телефонов.

Что из этого можно вынести? На ошибках учатся, и теперь мы внимательнее проверяем списки сотрудников, по разным критериям, разрабатываем сценарии отхода, а эксперты делятся друг с другом своими ошибками на Вики-страницах, чтобы не повторять их.

Разбираем тренды уходящего года

Форматы социотехнического тестирования

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

В проектах использовались следующие форматы социотехнического тестирования:

• рассылка фишинговых писем со ссылкой на поддельный ресурс — 52%
• рассылка фишинговых писем с исполняемым вложением — 36%
• телефонные звонки (вишинг) — 12%

Самым результативным (отношение количества попавшихся к общему числу получателей) из представленных форматов стал вишинг — 37%.

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

2020 год отметился настоящим бумом вишинга — как в плане звонков от самих злоумышленников, так и в плане расследований СМИ. В этом году легенды вишинга стали более разнообразны и изобретательны: предложение медицинских и юридических услуг, звонки от лица сотрудника прокуратуры, и не стоит забывать о классике — расследование подозрительного перевода банком (порядком приевшийся прием, но, к сожалению, все еще работающий).

Высокая результативность вишинга объясняется следующими моментами:

• Заранее известна информация, которую нужно получить. Это позволяет сформировать сценарий разговора, проработать вопросы, которые надо задать для достижения цели. Есть возможность подготовить пути отхода, если собеседник начнет что-то подозревать.
• Большой объем работ по сбору информации о сотрудниках и компании, которая используется для формирования легенды и сценария разговора. Например:
  
  — о сотрудниках: ФИО, номер мобильного телефона, добавочный номер, адрес корпоративной электронной почты, ник в телеграмме, отдел, в котором работает сотрудник, его должность, дата рождения и фото;
  
  — о компании: наименования подразделений и имена руководителей ключевых подразделений; используемые внутренние системы.
• В разговоре используется информация, которая указывает на осведомленность эксперта о внутренних процессах компании; отсылки на распоряжения, якобы полученные от начальников структурных подразделений компании. Например:
  

  Эксперт: Здравствуйте, Татьяна Игоревна! Звоню вам по просьбе руководителя Владимира Алексеевича Кузнецова. У нас произошел инцидент ИБ: по вашему пропуску сегодня через систему контроля управления доступом был зафиксирован проход в хранилище M.

• Эксперт демонстрирует эмоциональную заинтересованность в сложившейся ситуации или схожие интересы, чтобы притупить внимание собеседника:
  

  Эксперт: Вы пользуетесь ноутбуком только как рабочим компьютером или по каким-то еще личным делам?
  Сотрудник: Ну, смотрю YouTube еще.
  Эксперт: Да-да, я понимаю. Не переживайте. Просто возможно, что ваша доменная учетная запись была скомпрометирована и с ее помощью смогли пройти через СКУД.

Также следует помнить про внезапность звонка (человек может не понять, кто звонит) и возможность подмены номера. Таким образом, все перечисленные приемы позволяют увеличить доверие со стороны сотрудника и ослабить его бдительность.

Что касается диалогов выше, все они приведены из реального разговора, который состоялся в рамках проекта по вишингу. В кейсе №1 подробнее рассказываем про проект и его результаты.

Кейс №1

Цель: получить информацию разной степени критичности (компания определила информацию, которую считала конфиденциальной).
Легенда: сотрудника уведомляют об инциденте ИБ — его пропуск использовали для несанкционированного прохода через СКУД в хранилище М. Служба безопасности расследует инцидент и звонит, чтобы узнать текущее местоположение пропуска, где находился пропуск в рабочее время, существуют ли альтернативные способы для прохождения СКУД. Звонят в нерабочее время (выходной день). Эксперт должен убедить сотрудника проверить доменную учетную запись на факт компрометации — сотрудника просят аутентифицироваться на резервном портале (фишинговый ресурс).


Вернемся к Татьяне Игоревне и информации, которую она предоставила за время разговора:

• использует пропуск и специальный браслет для прохождения СКУД
• пропуск и браслет находятся дома
• использует корпоративную электронную почту дома
• предоставила свои учетные данные, введя их на фишинговом ресурсе:
  
  02.03.2020 13:48:25#0.2.0.2#ida****:rsa****55#Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 YaBrowser/19.3.1.828 Yowser/2.5 Safari/537.36

Компания остановила тестирование сотрудников после того как:

• 29 телефонных взаимодействий было нами произведено;
• 23 сотрудника раскрыли конфиденциальную информацию различного уровня критичности.

Как видно из примера, вишинг может использоваться не только для получения личной или конфиденциальной информации, но и для получения прямого доступа к инфраструктуре.

Какие могут быть результаты

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

Один из ключевых факторов успеха в том, что рядовой сотрудник зачастую не разбирается в доменах, поддоменах и пр. Как следствие, он не видит разницы между portal-domain.ru и portal.domain.ru. Слова и порядок их употребления совпадают и там, и там, а вот символы можно пропустить по невнимательности или в спешке.

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



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

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

Также сотрудники часто пересылают письма своим коллегам.

Кейс №2

Цель: оценить осведомленность сотрудников в вопросах информационной безопасности.
Легенда: ознакомиться с новой системой премирования. К письму прилагался документ «Премии.xls».


За время тестирования удалось успешно подключиться к компьютерам 11 сотрудников (14% участников). Столкнувшись якобы с проблемой в работе документа, сотрудники вступали в переписку с экспертами — в том числе и не заявленные в тестировании сотрудники.

Пример одной из таких переписок ниже:





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

Окей, возвращаемся к тенденциям

В 2020-м стали чаще появляться новости о том, что злоумышленники используют фишинг и вишинг в рамках одной атаки. К примеру, в начале декабря сообщалось, что злоумышленники рассылают уведомления о долгах за ЖКУ в размере 10–20 тысяч рублей, которые якобы появились за время карантина, и просят оплатить поддельные квитанции онлайн.

Если человек проигнорировал письмо – ему звонили от имени сотрудника управляющей компании для проверки ранее совершенных платежей. Преступники убеждали, что долг по квартплате есть, и узнавали способы оплаты и реквизиты карты, которая использовалась для платежа, а затем предлагали сделать пробную транзакцию и сообщить им код из SMS.

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

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

Таким образом, проекты, в которых одновременно использовались фишинг и вишинг, оказались более результативными, чем те, где использовался только фишинг. Сотрудники, которые подозревали, что проводится тестирование, меняли свое мнение, верили в легитимность писем и охотно шли на контакт с экспертами.

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

Легенды

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

Ниже представлены основные примеры легенд:

• Изменение в графике работы
• Изменение в IT-системах
• Система премирования
• Скидки и бонусы
• События в компании

Самой результативной легендой было информирование об изменениях в системе премирования.

Кроме того, упоминание легитимного сервиса, используемого многими компаниями, такого как Office 365, повышает доверие сотрудника. Такой подход часто используют реальные злоумышленники для проведения социотехнических атак.

Реалии 2020-го привнесли новое веяние в легенды социотехнического тестирования, да и реальных атак тоже. На первый план вышла коронавирусная инфекция и все, что с ней связано.

Когда коронавирус только начинался, компании просили не использовать его в качестве легенды, поскольку отсылка к столь актуальной теме гарантировала высокую результативность и негативно сказывалась на настроении сотрудников. Мы отвечали, что реальные злоумышленники не так этичны и активно используют эту легенду с начала пандемии, но получали категорический отказ. В результате табу на использование COVID-19 было снято с введением новых ограничительных мер осенью. Возможно, именно в этот момент компании осознали, что коронавирус с нами надолго и его игнорирование может привести к рискам.

Первый же проект с COVID-19 продемонстрировал неослабевающий интерес людей к данной теме и, как следствие, больше половины участников тестирования выполнили потенциально опасные действия.

Пожалуйста, прислушивайтесь к экспертам при выборе легенд.

Кейс №3

Цель: оценить осведомленность сотрудников в вопросах информационной безопасности.
Легенда: проверить сервис удаленного доступа, поскольку сотрудники переходят на удаленную работу из-за COVID-19. Для проверки доступа надо ввести учетные данные от рабочего компьютера на фишинговой странице, которая копировала страницу входа на VPN-портал.


Пример письма для рассылки:


Мы получили следующие результаты:

Нужно больше тестирований или «что будет в периоде»

Каждая подобная статья заканчивается списком рекомендаций, которые позволят повысить осведомленность сотрудников в вопросах информационной безопасности.

К примеру, проверять источник письма или путь, по которому ведет ссылка. В целом, разумная рекомендация, но на практике не всегда работает. Вот смотрите: сотрудник, который получает 15 писем в день (возможно, среди читателей найдутся те, кто мечтает получать *всего* 15 писем в день), а чтение и участие в переписке не его основной вид деятельности, не будет до буквы, до знака проверять адрес отправителя или сверять его ФИО с корпоративным списком контактов.

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

Еще одна типичная рекомендация — регулярные тестирования персонала. Это замечательно, но тоже не всегда работает. Почему — смотрите в кейсе №4.

Кейс №4

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

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

Результат регулярного тестирования оказался таким же, как и у нерегулярного: сотрудники переходили по ссылкам, вступали в переписку и раскрывали конфиденциальную информацию. Результативность отдельного тестирования в большей степени определялась актуальностью легенды. В 3 квартале легенда с COVID-19 заставила людей забыть о тренингах, наставлениях и рекомендациях.


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

Кейс №5

В этом примере демонстрируем, как выявленное на ранних этапах социотехническое тестирование оказалось результативным только из-за того, что сотрудники, распознавшие тестирование, не оповестили о нем коллег.

Цель: получить валидные учетные данные сотрудников.
Легенда: проверить наличие доступа к новому корпоративному порталу.


Активная фаза социотехнического тестирования началась 11 февраля 2020 года в 13:30 (МСК).

Первые учетные данные мы получили через 4 минуты:

Дата и время	IP-адрес / MAC-адрес	Введенные логин и пароль	Общая информация о конфигурации рабочей станции
11.02.2020 13:34	0.0.0.1	ni*********a:V******v	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36
11.02.2020 13:34	0.0.0.6	mi****a:2******aB3	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15

Примерно через 30 минут после начала тестирования получили данные, явно указывающие, что легенда раскрыта и сотрудники либо догадались о проводимом тестировании, либо заподозрили атаку: вместо учетных данных в логах собиралась ненормативная лексика.

Дата и время	IP-адрес / MAC-адрес	Введенные логин и пароль	Общая информация о конфигурации рабочей станции
11.02.2020 14:02	0.0.0.71	Idi ** *** sobaka:ahahhahaha	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36

Судя по полученным результатам (IP-адрес и информация о рабочей станции), мы подозревали, что это администратор. К этому моменту получили уже 37 учетных данных. Цель достигнута!

Тестирование можно сворачивать и садиться за отчет, но сотрудники продолжали вводить учетные данные. Последний ввод данных был зафиксирован 17 февраля. Следовательно, сотрудники, распознавшие тестирование (или атаку), не предупредили об этом своих коллег.

Дата и время	IP-адрес / MAC-адрес	Введенные логин и пароль	Общая информация о конфигурации рабочей станции
17.02.2020 14:08	0.0.0.55	Ty********v:T**********rah	Mozilla/5.0 (iPhone; CPU iPhone OS 12_1_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1

Всего получили 76 уникальных учетных данных. Валидность каждой пары была подтверждена.

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

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

Итоги, проблемы и рекомендации

Наверное, уже пора заканчивать со всеми этими рассказами и историями.

Может показаться, что конец какой-то пессимистичный (какой год — такой и конец): сотрудники необучаемы, рассеяны и бизнес все еще в опасности.

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

Также не забывайте о простых правилах цифровой гигиены и рекомендациях по повышению осведомленности в ИБ.

Мы уже говорили, что в интернете достаточно статей о социотехническом тестировании (такая есть и у нас), а также статей с рекомендациями по повышению защиты. Поэтому хотим в очередной раз просто напомнить, что здесь нужен комплексный подход, а значит следует помнить о:

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

Возвращаясь к основному вопросу: что же выбрать в 2021-м?

Мы решили оставить его на размышление вам. Рекомендуем попробовать фишинг + вишинг или только вишинг. Поможет сотрудникам не только в корпоративной среде, но и при подобных атаках в нерабочей обстановке.

Главное, про что стоит помнить: обучение и социотехнические тестирования должны быть направлены на формирование культуры поведения, которая позволит своевременно выявлять и эффективно реагировать на различные атаки.

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