Как хакеры возвращаются в вашу сеть после атаки

Говорят, за одного битого двух небитых дают, а за одного взломанного двух невзломанных. Разумеется, если взломанные извлекли уроки из произошедшего у них инцидента

По статистике, 74% жертв шифровальщиков сталкивались с ними более 1 раза, а 33% — 4 (!) и более раз! Только представьте себе — тебя 4 раза хакнули, а ты так и не извлек никаких уроков!

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

Учитывая, что Украина, Россия, Израиль, Палестина, Йемен, Сирия, Иран и др. живут в условиях непрерывной кибервойны и постоянно сталкиваются с инцидентами ИБ, достаточно интересно читать чужой опыт, чтобы не повторять описанных ошибок. И не важно, кем они были сделаны.

Отсутствие анализа инцидента («Lessons Learned»)

Что происходит:

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

Почему это опасно:

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

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

Что делать:

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

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

• Устранить уязвимости до восстановления из бэкапов.

Частичная или отложенная реализация рекомендаций после атаки

Что происходит:

• Рекомендации экспертов либо игнорируются, либо выполняются выборочно.

  Нахрена вы их тогда вообще приглашали?

• Некоторые меры откладываются «на потом» из-за нехватки времени, бюджета или ресурсов.

Почему это опасно:

• Даже одна неустраненная уязвимость дает злоумышленникам путь обратно в инфраструктуру.

Что делать:

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

• Не откладывать внедрение даже тех мер, которые кажутся трудозатратными или «не срочными».

Проверяются не все устройства и узлы

Что происходит:

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

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

Почему это опасно:

• Вредоносный код мог быть размещен на этих «незначительных» системах, как на точках возврата.

• Хакеры могут использовать такие устройства для повторного проникновения или расширения своего присутствия во внутренней сети.

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

Что делать:

• Проверить все устройства в инфраструктуре, включая те, что не были задействованы в инциденте.

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

Уязвимости не устраняются при восстановлении

Что происходит:

Системы восстанавливаются, но:

• Не проводится обновление уязвимого ПО, особенно сервисов, доступных из интернета.

• Сервера, выходящие в интернет, не изолируются в DMZ.

Почему это опасно:

• Восстановление системы без устранения уязвимостей позволяет злоумышленникам зайти другим путем.

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

Что делать:

• Провести полную проверку «поверхности атаки», а на будущее использовать соответствующий инструментарий, решения класса ASM (Attack Surface Management).

• Реализовать сетевую сегментацию: отделить критические ресурсы от интернет-доступных сервисов.

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

Что делать, чтобы хакеры не вернулись

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

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

• Проверяйте все устройства, а не только ключевые серверы.

  Ну вот последние два совета, данные ДССЗЗИ, не так чтобы релевантны и работают только в небольших компаниях с маленькой инфраструктурой. В организациях на десятки тысяч узлов и сотни тысяч активных IP-адресов, патчить все дыры и проверять все устройства нереально. Нужно классифицировать, группировать, приоритизировать…

• Убедитесь, что резервные копии безопасны, а также что они вообще делаются.

Помните: защита — это не только предотвращение и реагирование, но и извлечение уроков!