Обмани меня, если сможешь

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

Что произошло на самом деле? В отношении группы компаний, куда входил институт, специалисты Group-IB проводили тестирование на проникновение в формате близком к Red Teaming (проще говоря, это имитация целевых атак на вашу компанию с использованием самых продвинутых методов и инструментов из арсенала хакерских группировок). Мы подробно рассказывали о Red Teaming здесь. Важно знать, что при проведении такого теста может применяться очень широкий спектр атак из заранее согласованных, в том числе социальная инженерия. Понятно, что само размещение кота не было конечной целью происходящего. А было следующее:

• веб-сайт института был размещен на сервере в самой сети института, а не на сторонних серверах;
• найдена утечка учетной записи отдела кадров (файл журнала писем в корне сайта). Администрировать сайт с этой учетной записью было нельзя, но можно было редактировать страницы вакансий;
• изменяя страницы, можно было разместить свои скрипты на языке JavaScript. Обычно они делают страницы интерактивными, но в данной ситуации этими же скриптами можно было похитить из браузера посетителя то, что отличало отдел кадров от программиста, а программиста от простого посетителя — идентификатор сессии на сайте. Кот был триггером атаки и картинкой для привлечения внимания. На языке разметки сайтов HTML это выглядело так: если у вас загрузилась картинка, JavaScript уже исполнился и ваш идентификатор сессии вместе с данными о вашем браузере и IP-адресе уже был похищен.
• С похищенным идентификатором сессии администратора можно было бы получить полный доступ к сайту, размещать исполняемые страницы на языке PHP, а значит, получить выход в операционную систему сервера, а затем уже и в саму локальную сеть, что и было важной промежуточной целью проекта.

Атака закончилась частичным успехом — идентификатор сессии администратора был похищен, но он был привязан к IP-адресу. Обойти это не удалось, мы не смогли повысить привилегии на сайте до администраторских, зато повысили себе настроение. Конечный результат в итоге получили на другом участке сетевого периметра.

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

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

Обычно по результатам проектов с социальной инженерией мы составляем статистику, которая, как известно, вещь сухая и скучная. Столько-то процентов получателей открыло вложение из письма, столько-то перешло по ссылке, а вот эти трое вообще ввели свои логин и пароль. В одном проекте мы получили более 100% ввода паролей — то есть вышло больше, чем разослали.

Произошло это так: отправлялось фишинговое письмо, якобы от CISO госкорпорации, с требованием «срочно протестировать изменения в почтовом сервисе». Письмо попало на руководителя крупного подразделения, которое занималось техподдержкой. Руководитель был очень старателен в исполнении поручений от высокого начальства и переслал его всем подчиненным. Сам колл-центр оказался довольно большим. В целом, ситуации, когда кто-то пересылает «интересные» фишинговые письма своим коллегам и те тоже попадаются — довольно частое явление. Для нас это лучшая обратная связь по качеству составления письма.

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

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

1. Кто мой собеседник?
2. Откуда возникли его предложение или просьба (никогда ведь такого не было, и вот появилось)?
3. Что необычного в этом запросе?

Даже необычный тип шрифта письма или несвойственный отправителю стиль речи могут запустить цепочку сомнений, которая остановит атаку. Прописанные инструкции тоже нужны, но они работают по-другому, при этом не могут конкретизировать все возможные ситуации. Например, администраторы ИБ пишут в них, что нельзя вводить свой пароль на сторонних ресурсах. А если пароль просит «свой», «корпоративный» сетевой ресурс? Пользователь думает: «В нашей компании и так есть два десятка сервисов с единой учетной записью, почему бы не появиться еще одному?» Отсюда вытекает еще одно правило: хорошо выстроенный рабочий процесс также прямо влияет на безопасность: если соседний отдел может запросить у вас информацию только письменно и только через вашего руководителя, человек «от доверенного партнера компании» подавно не сможет ее запросить по телефону — для вас это будет нонсенс. Особенно стоит насторожиться, если ваш собеседник требует все сделать прямо сейчас, или «ASAP», как модно писать. Даже в обычной работе такая ситуация часто не является здоровой, а в условиях возможных атак — это сильный триггер. Нет времени объяснять, запускай мой файл!

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

Хорошее обучение всегда должно включать практику. Здесь на помощь могут прийти специалисты по тестированию на проникновение. Следующий вопрос: а что и как мы будем тестировать? Мы в Group-IB предлагаем следующий подход — сразу выбрать фокус тестирования: либо оценивать готовность к атакам только самих пользователей, либо же проверять защищенность компании в целом. А тестировать методами социальной инженерии, имитируя реальные атаки — то есть теми же самыми фишингом, рассылкой исполняемых документов, звонками и другими техниками.

В первом случае атака тщательно готовится совместно с представителями заказчика, в основном с его ИТ- и ИБ-специалистами. Согласуются легенды, инструменты и техники атак. Заказчик сам предоставляет фокус-группы и списки пользователей для атаки, которые включают все нужные контакты. Создаются исключения на средствах защиты, так как сообщения и исполняемые нагрузки обязательно должны дойти до получателя, ведь в таком проекте интерес представляет только реакция людей. Опционально можно заложить в атаку маркеры, по которым пользователь может догадаться о том, что это и есть атака — например, можно сделать пару орфографических ошибок в сообщениях либо оставить неточности в копировании фирменного стиля. По окончании проекта получается та самая «сухая статистика»: какие фокус-группы и в каком объеме среагировали на сценарии.

Во втором случае — атака проводится c нулевыми исходными знаниями, методом «черного ящика». Мы самостоятельно собираем информацию о компании, ее сотрудниках, сетевом периметре, формируем легенды для атаки, выбираем методы, ищем возможные применяемые в целевой компании средства защиты, адаптируем инструменты, составляем сценарии. Наши специалисты используют как классические методы разведки по открытым источникам (OSINT), так и продукт собственной разработки Group-IB — Threat Intelligence, систему, которая при подготовке к фишингу может выступать агрегатором информации о компании за длительный период, используя в том числе и закрытую информацию. Разумеется, чтобы атака не стала неприятным сюрпризом, ее детали также согласуются с заказчиком. Получается полноценный тест на проникновение, но в его основе будет продвинутая социальная инженерия. Логичная опция в таком случае — развитие атаки внутри сети, вплоть до получения наивысших прав во внутренних системах. Кстати, схожим образом мы применяем социотехнические атаки и в Red Teaming, и в некоторых тестах на проникновение. В результате заказчик получит независимое комплексное видение своей защищенности от определенного вида социотехнических атак, а также демонстрацию эффективности (или наоборот, неэффективности) выстроенной линии обороны от внешних угроз.

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

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

• Наличие обязательной двухфакторной аутентификации на сервисах, которые опубликованы в интернете. Выпускать в 2019 году такие сервисы без систем Single Sign On, без защиты от перебора паролей и без двухфакторной аутентификации в компании размером от нескольких сотен человек равносильно открытому призыву «сломай меня». Правильно внедренная защита сделает быстрое применение похищенных паролей невозможным и даст время на устранение последствий фишинговой атаки.
• Контроль разграничения доступа, минимизация прав пользователей в системах и соблюдение руководств по безопасной настройке продуктов, которые выпускает каждый крупный производитель. Это зачастую простые по своей сути, но очень эффективные и сложные в практической реализации меры, которыми все в той или иной степени пренебрегают ради скорости работы. А некоторые настолько необходимы, что без них ни одно средство защиты не спасет.
• Хорошо выстроенная линия фильтрации электронной почты. Антиспам, тотальная проверка вложений на наличие вредоносного кода, в том числе динамическое тестирование через песочницы. Хорошо подготовленная атака подразумевает, что исполняемое вложение не будет детектироваться антивирусными средствами. Песочница же, наоборот, проверит все на себе, используя файлы так же, как их использует человек. В результате возможная вредоносная составляющая будет раскрыта по производимым изменениям внутри песочницы.
• Средства защиты от целенаправленных атак. Как уже отмечалось, классические антивирусные средства не будут детектировать вредоносные файлы при хорошо подготовленной атаке. Наиболее продвинутые продукты должны автоматически отслеживать совокупность событий, происходящих в сети — как на уровне отдельного хоста, так и на уровне трафика внутри сети. В случае атак проявляются очень характерные цепочки событий, которые можно отследить и остановить, если иметь сфокусированный на события такого рода мониторинг.

Оригинал статьи опубликован в журнале «Information Security/ Информационная безопасность» #6, 2019.