В прошлом посте мы собрали типичные ошибки, которые могут сделать пострадавшие от инцидента до завершения расследования. Оказалось, что аналогичный список «нелучших практик» есть у коллег из Solar 4rays – они делали такой доклад на SOC Forum (видео). Теперь вы можете сравнить эти два списка популярных косяков и составить из них общий анти-плейбук для своих клиентов.
А мы тем временем покажем вам топ ошибок с другой стороны. Ведь даже те, кто профессионально занимается реагированием, иногда ошибаются. Поэтому наш следующий список вредных советов – чего не нужно делать специалистам по реагированию на инцидент:
(1) Собирать данные с систем, которые не были изолированы. Злоумышленники могут обнаружить триаж и вытащить из него чувствительную информацию. Атакующие могут изменить состояние системы (например, добавить персистенс) после создания триажа.
(2) Запускать подозрительные файлы на виртуалках с доступом в Интернет: злоумышленники поймут, что их действия анализируют. А ещё к злоумышленникам может утечь содержимое примонтированных к виртуалке шар (а вдруг там файлы с другого инцидента?). Поэтому сначала лучше определить основной функционал файла в виртуалке без доступа к Интернету или путём проведения статического анализа.
(3) Загружать артефакты пострадавших в общедоступные сервисы: VirusTotal, сервисы для декодирования/расшифровки неизвестных данных. В файлах/данных может быть конфиденциальная информация (пароли, ключи, название пострадавшей компании и т.д.)
(4) Писать в отчет не подтвержденную расследователем информацию, которую излагает пострадавший. «Порт RDP никогда не был доступен из Интернета…». «Ну ладно, был доступен, но там было ограничение по IP...» У расследователя нет задачи доверять. Его задача – сделать собственные доказанные выводы. Категорически запрещается не проверять выводы из других источников.
(5) Анализировать только известные логи/типы событий. Если вы не нашли ничего в стандартных логах Windows, вам могут помочь кастомные логи какого-то специфического софта. Например, в логах утилит для туннелирования может сохраниться время и IP-адрес входящих/исходящих подключений.
(6) Игнорировать зашифрованные диски виртуальных машин. Зачастую для ускорения процесса шифрования, трояны-шифровальщики шифруют большие файлы (например, диски виртуальных машин) не полностью. Если собрать такой файл у клиента, иногда из него удается вытащить журналы событий, файлы реестра и другую полезную для расследования информацию.
(7) При расследовании взлома web-сайта без разрешения клиента и наличия исходных кодов пытаться проверять на сайте различные вектора атак. Такими действиями вы можете случайно затереть какие-то страницы сайта; добавить код, который блокирует работу скриптов на фронтэнде; нарушить структуру БД; израсходовать ресурсы сервера; стриггерить СЗИ.
Подробнее о том, как правильно вести себя при расследовании инцидентов, расскажет наш эксперт Константин Сапронов в онлайновом эфире AM Live 11 декабря, в 11:00 МСК (для просмотра нужна регистрация по ссылке)
Post #71
3.79K

- 🔥 22
- 👍 7
- ❤ 3
- 👏 2
- ⚡ 1