Анализ вредоносного ПО с помощью Wireshark

Описание

В этой лабораторной работе я проанализировал известный вредоносный захват пакетов при эксплуатации уязвимости Log4J. Я начал свое исследование с того же подхода, который использую для анализа захватов пакетов: изучение статистики и выяснение того, сколько и как много конечных точек взаимодействуют. Заметив огромное количество IP-адресов, я захотел нанести их на глобальную карту, поэтому установил и настроил базу данных GEOIP от Max Mind, которая определяет страну и город по IP-адресу. Такое количество IP-адресов указывает на потенциальную атаку из ботнета, направленную на эксплуатацию Log4J или другое вредоносное сканирование. Поскольку в захваченном трафике использовался протокол http, а не https (зашифрованный), я смог идентифицировать эксплойт в открытом тексте, отфильтровав по строке "jndi", что означает Java Naming and Directory Interface. Первым пакетом из этого фильтра оказался HTTP POST-запрос, и при изучении поля User-Agent обнаружился ldap-запрос к IP-адресу, за которым следовал закодированный текст. Декодирование текста в CyberChef показало, что код содержит wget-запрос к IP-адресу для загрузки shell-скрипта, использование команды chmod для предоставления прав на выполнение и последующий запуск скрипта. Кроме того, чтобы выяснить, пыталась ли хостовая машина устанавливать исходящие соединения с публичными IP-адресами, что указывало бы на сервер управления и контроля (C2), я отфильтровал пакеты с этим IP-адресом в качестве источника и TCP SYN-пакеты для начала TCP-соединений и подтвердил, что соединений не было. Это может быть результатом установки исправления на машине или неявного правила брандмауэра, блокирующего исходящие соединения. Когда стало ясно, что атака не удалась, я провел дальнейшую разведку угроз по IP-адресу из wget-команды и обнаружил, что этот IP-адрес известен как вредоносный, а на вкладке сообщества в VirusTotal этот IP-адрес был связан с атаками Log4shell, что дополнительно подтвердило атаку. Мой подход заключался в том, чтобы сначала выяснить, кто взаимодействует с целевым сервером. Затем было необходимо определить, начал ли атакованный сервер (198.71.247.91) какие-либо новые исходящие соединения.

Используемые утилиты