Расследование инцидентов ИБ in the wild: неожиданные источники информации

    image

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

    Почему вообще возникает недостаток основных артефактов? Причин может быть несколько:

    1. Инфраструктура не подготовлена подобающим образом для полноценного мониторинга и реагирования на события (об этом мы писали тут)
    2. Злоумышленник заметает следы, удаляя или модифицируя некоторые артефакты (он ведь тоже читает книги и статьи про Digital Forensic)
    3. Некоторые артефакты затерты системой, если с момента инцидента прошло достаточно времени (примеры – ротация журналов событий, затирание MFT-записей).

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

    В зависимости от ситуации на помощь могут прийти SIEM-системы, анализ сетевых потоков Netflow или сырого трафика (хотя в реальности в 90% случаев эта возможность отсутствует), а также необычные артефакты, которые относятся к какому-либо стороннему ПО, по стечению обстоятельств оказавшемуся в инфраструктуре заказчика.

    Именно на последнем типе артефактов мы и остановимся.

    Ivanti Endpoint Manager (ранее LANDESK Management Suite). Система управления ИТ-активами

    www.ivanti.ru/company/history/landesk

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

    1. события журнала Security перенаправлялись в отдельный временный файл,
    2. злоумышленник выполнял необходимые действия,
    3. события перенаправлялись обратно в журнал Security,
    4. временный файл удалялся.
    5. Profit!

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

    После непродолжительного анализа мы выяснили, что злоумышленник «живет» в инфраструктуре уже около 2-3 лет, что позволило скомпрометировать все ключевые серверы. В таких случаях возрастает ценность любых дополнительных источников информации, так как некоторые базовые артефакты либо перетираются, либо малоинформативны и не позволяют составить полную картину инцидента.

    В поисках дополнительных источников информации мы провели устную инвентаризацию сервисов и систем, используемых в инфраструктуре и выяснили, что совместно с внедрением нашего мониторинга заказчик начал разворачивать систему управления ИТ-активами
    Ivanti Endpoint Manager.

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

    HKLM\SOFTWARE\Wow6432Node]\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\MonitorLog\<Путь к исполняемому файлу>

    При этом в соответствующих ключах хранится следующая информация:

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


    Артефакты запуска процессов от Ivanti Endpoint

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

    Citrix NetScaler. Система предоставления доступа к корпоративным ресурсам и приложениям

    www.citrix.com/ru-ru/products/citrix-adc


    Схема работы Citrix NetScaler

    Еще одно любопытное расследование. Злоумышленник проник в инфраструктуру компании через VPN. Работал во временной зоне UTC +8. После аутентификации вел себя достаточно агрессивно (активно сканировал внутренние подсети по маске /24 и /16), вследствие чего, собственно, и был замечен.

    VPN был настроен на системе предоставления доступа к корпоративным ресурсам и приложениям Citrix NetScaler. Изучив ее логи, мы смогли установить время первого «визита» (читай – дату компрометации), используемые злоумышленником учетные записи сотрудников (к слову, было скомпрометировано больше 5 учеток) и IP-адреса прокси-серверов, с которых он вел работу.

    Само расследование закончилось удачно: нам удалось установить источник компрометации – оказалось, что внутренняя система сброса учетных данных, доступная из интернета, была подвержена SQL-инъекции.

    Но сейчас хочется отметить другое: после прохождения VPN-аутентификации на Citrix NetScaler удачно логировались все HTTP-запросы пользователей. Злоумышленник, вероятно, либо не знал этого, либо перепутал свои сетевые интерфейсы и пустил собственные запросы к поисковым системам через корпоративную сеть заказчика. Это позволило нам получить информацию об интересующих злоумышленника системах, его компетенциях и используемом инструментарии.


    Лог-файл Citrix NetScaler


    Информация, которую злоумышленник искал через Citrix NetScaler


    Информация, которую злоумышленник искал через Citrix NetScaler

    Secret Net Studio. Система защиты информации от НСД

    www.securitycode.ru/products/secret_net

    В один прекрасный день на нашу первую линию упал тикет с инцидентом на подозрительную аутентификацию под учетной записью ИТ-сотрудника компании на сервере администрирования в ночное время (сам сотрудник в это время был в отпуске, VPN у него не было). Архитектурно сервер администрирования находился в отдельном сетевом сегменте вместе с еще несколькими ключевыми серверами компании (в том числе и сервером Secret Net), при этом к нам в SIEM события поступали только с самого сервера администрирования (к сожалению, заказчики не всегда соглашаются подключать все потенциальные источники).

    Первая линия, отрабатывая тикет и собирая информацию о том, что происходило после аутентификации, натыкается на различные подозрительные запуски процессов (нестандартные пути, имена бинарных файлов в одну букву) и запуск mstsc.exe, свидетельствующий о возможной RDP-сессии.

    Поняв, что речь идет о потенциальной компрометации, мы запросили образы всех серверов
    и начали свой анализ. Открыв первый же образ (сервер Secret Net), получили в подарок «большой сюрприз»: журналы System, Security и Application были удалены, причем удалены так, что даже попытки восстановления не увенчались успехом. Удалось лишь сопоставить, что записи в журналах TerminalServices сервера Secret Net по времени совпадают с запуском mstsc.exe на сервере администрирования, а значит, злоумышленник точно был на Secret Net. Анализ остальных серверов также не дал результатов.

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

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

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


    Схема работы злоумышленника через сервер Secret Net Studio


    Лог-файл файлового контроля Secret Net Studio

    KVRT. Бесплатное антивирусное средство

    www.kaspersky.ru/downloads/thank-you/free-virus-removal-tool

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

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

    Среди используемых сканеров был KVRT, который обнаружил некоторые вредоносные файлы и поместил в карантин. Стандартное расположение файлов карантина – C:\KVRT_Data\Quarantine, а расшифровать их очень легко: простой XOR с общеизвестным ключом – e2 45 48 ec 69 0e 5c ac.


    Расшифрованный карантин KVRT

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



    Каждое расследование – это всегда что-то необычное, уникальное и разностороннее. Да, есть известные артефакты операционных систем, но до начала расследования трудно спрогнозировать полноту информации, которую можно будет получить после их анализа. Поэтому перед техническим расследованием инцидента мы рекомендуем провести инвентаризацию ПО и систем и не лениться изучить их как возможный источник в расследовании.
    Ростелеком-Солар
    Безопасность по имени Солнце

    Комментарии 5

      +1

      Все случаи с win платформой? Есть примеры с linux? Его как то побольше в серверном сегменте

        +2
        Нет, в данной статье речь не только про win платформу. Кейс с Citrix состоял в основном из Linux систем (злоумышленник искал Dirty Cow). Но наш опыт подсказывает, что полезная информация может быть в различных инфраструктурных системах и программах, вне зависимости от того на каких ОС они работают.
        +1

        Интересное изложение. Как сериал читаешь/смотришь

          0
          Вот интересно, типичное поведение хакера при проникновении — затереть свои следы. Мне очевидно решение, надо записи сопровождать хешем который учитывает текст записи и предыдущий хеш. То есть, нельзя ни поменять сообщение, ни стереть строчку — лог файл станет невалидным, примерно как блокчейн. Если что, я профан в IT безопасности.
            +1
            Подпись логов давно существует, для syslog это принято как стандарт в 2010 году ( RFC 5848), для винды что-то подобное тоже должно быть. Но пустой или невалидный лог не поможет узнать кто что сделал, а только просигнализирует о проблеме.
            Правильнее было бы настроить форвард логов на отдельно выделенный сервер с их последующим анализом, недавно как раз был пример этого habr.com/ru/company/tomhunter/blog/504088

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

          Самое читаемое