Привет Хабр! На связи Аеза и сегодня мы осветим очень злободневную тему – выявление подозрительных активностей в трафике. Мы не будем говорить о каких-то специализированных решениях, типа IDS/IPS, а вместо этого рассмотрим основные принципы выявления подозрительных действий что называется вручную.

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

Wireshark можно загрузить c официального ресурса проекта, либо установить с помощью менеджера пакетов.

HTTPS не проблема

Шифрование TLS сейчас стало стандартом де факто при передаче трафика по сети. Если в прежние времена в дампе трафика можно было встретить незашифрованный HTTP, то сейчас такое практически невозможно. Большинство веб-сайтов используют защищенный протокол Hypertext Transfer Protocol Secure (HTTPS). Но, как и большинство веб-сайтов, различные типы вредоносного ПО также используют HTTPS. Так нам необходимо понять, что произошло на основе дампа, нужно  получить трафик в расшифрованном виде. Поэтому, для начала нам нужно расшифровать HTTPS.

Так как мы находимся на стороне защитников, у нас есть административный доступ на все пользовательские машины, и мы можем включить журналирование сессионных ключей в файл. Далее в этой статье мы будем рассматривать ОС Windows, так как она больше всего подвержена атакам вредоносов, по крайней мере среди десктопных систем.

Для того, чтобы включить журналирование ключей, необходимо перейти в раздел Панель управления → Система и безопасность → Система. На вкладке «Дополнительные параметры системы» нажимаем кнопку «Переменные среды».

Далее в разделе "Переменные среды" для пользователя необходимо добавить переменную SSLKEYLOGFILE и указать в качестве значения полный путь и имя файла, в котором будут сохраняться ключи.

В нашем случае ОС Windows 10 Pro 19045.5737 и этот способ сработал. Однако, если у вас не получилось запустить логирование, то в качестве альтернативы можно попробовать воспользоваться Powershell.

 [Environment]::SetEnvironmentVariable("SSLKEYLOGFILE", "c:\Temp\sslkeylog.txt", "User1")

В Linux для выполнения той же задачи просто выполним:

export SSLKEYLOGFILE=/путь/к/файлу/sslkeylog.log

Теперь мы можем смело приступать к сбору трафика, так как с помощью файла журнала ключей мы можем расшифровать HTTPS-активность в pcap и просмотреть ее содержимое.

Получаем артефакт

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

У нас имеется дамп трафика и журнал с ключами. Сначала нам необходимо подгрузить в Wireshark файл с ключами. Для этого выберем Edit → Preferences… → Protocols и в списке укажем TLS.

Далее необходимо подгрузить файл с журналом ключей:

Теперь все готово к работе с дампом трафика. После открытия файла мы видим множество различных пакетов. Прежде всего нужно немного настроить Wireshark под наши задачи. В частности, уберем столбцы с МАС адресами отправителя и получателя, так как они нам сейчас не нужны. Для этого выбираем название каждого из ненужных столбцов и далее указываем Remove this Column.

Также неплохо было бы включить разрешение доменных имен для сетевых адресов. Для этого выберем View → Name resolution → Resolve Network Addresses. Также, при необходимости можно указать нужный формат времени также во вкладке View → Time Display Format.

Теперь необходимо отфильтровать только те пакеты, которые нас интересуют. Нам нужно найти пакеты с запросами HTTP или рукопожатия TLS так как именно с этих пакетов начинаются сессии. И на всякий случай уберем SSDP (Simple Service Discovery Protocol) пакеты, так как они будут только засорять наш вывод.

В итоге укажем следующий фильтр:

(http.request or tls.handshake.type eq 1) and !(ssdp)

В итоге для моего примера получилась следующая картина:

Как видно в дампе сайтов не так много и каждый из них можно проверить, например с помощью всем известного ресурса virustotal.com. Например, представленный в дампе ресурс 105711.com некоторые антивирусные вендоры определили, как вредоносный или фишинговый.

Давайте посмотрим, что было передано во время сессии с этим сайтом. Для этого выберем первый пакет и нажав правую кнопку мыши укажем Follow → TLS Stream.

Как видно, все оказалось довольно скучно: всего лишь ошибка 502 Bad Gateway.

Посмотрим следующий ресурс foodsgoodforliver.com. Этот сайт сочло подозрительным даже меньшее число антивирусных вендоров, правда среди них есть Kaspersky, что наводит на некоторые мысли.

Давайте также посмотрим TLS сессию. Здесь в самом начале мы видим кое-что интересное.

В первом GET запросе мы запрашиваем файл invest_20.dll и как видно далее, его получаем, так как первые два байта MZ это заголовок PE-формата выполнимых файлов Windows. Ну и всем известное предупреждение про невозможность запуска в режиме DOS! Очевидно, что перед нами выполнимый файл, который пользователь загрузил себе на машину. Давайте извлечем его из дампа.

Для этого выберем Export Objects → HTTP.

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

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

Ищем активность в LDAP

Разобравшись с простым примером загрузки вредоносного файла, давайте усложним нашу задачу. Теперь нам известен только IP адрес скомпрометированного узла и необходимо узнать что это за узел и как его собственно взломали..

Итак, нам известен только адрес клиентской машины 10.8.15.133, также известно, что эта машина входит в состав домена Active Directory. И собственно все. Однако, для того, чтобы разобраться в том, что происходило в сети одного адреса как правило бывает недостаточно, поэтому хорошо было бы узнать имя узла и имя пользователя, который на нем работал. Начнем с имени узла.

Для того, чтобы найти имя зараженного узла можно отфильтровать пакеты NetBios в Wireshark, по адресу 10.8.15.133. Для этого воспользуемся фильтром nbns.

Как уже было сказано чуть выше, наша машина входит в домен AD. Соответственно для того, чтобы узнать имя пользователя воспользуемся поиском пакетов по протоколу Kerberos.

Искать будем по фильтру:

Kerberos.CNameString

Для удобства можно добавить отдельный столбец в Wireshark, в котором будет отображаться значение CNAME. Для этого выберем один из найденных пакетов, укажем в нем поле Kerberos → Cname → Name и нажав правую кнопку мыши, выберем Apply as Column.

Теперь мы можем найти имя учетной записи пользователя Windows plucero, связанное с 10.8.15.133. Помимо логина мы можем извлечь из трафика имеющуюся в AD информацию об имени и фамилии данного пользователя.

Для этого нам потребуется следующий фильтр:

ldap.AttributeDescription == «givenName»

Часть нашей задачи мы решили: узнали кто и когда работал с этой машины. Теперь попробуем выяснить каким образом произошла компрометация. Здесь мы воспользуемся уже рассмотренными ранее способами.

Начнем с экспорта файлов из дампа. Как видно, Wireshark предлагает нам экспортировать большое количество различных данных.

Проверка на Virustotal показала, что 72.5.43.29 и quote.checkfedexexp.com могут представлять определенную опасность. Мы можем экспортировать zip-архив с сайта quote.checkfedexexp.com и DLL с сайта 72.5.43.29, используя уже знакомый нам путь меню Файл → Экспорт объекта → HTTP....

Имя zip-архива содержится в заголовках HTTP-ответа, которые можно увидеть, проследив за TCP или HTTP-потоком данного конкретного HTTP GET-запроса.

Этот zip-архив содержит .js-файл. Если дважды щелкнуть (в песочнице!) по распакованному файлу .js на уязвимом хосте, Windows он будет выполнен с помощью wscript.exe.

Если мы проследим поток TCP для первого HTTP GET-запроса к 72.5.43.29, мы увидим признаки передачи выполнимого файла, а для того, чтобы определить, является ли это EXE или DLL, воспользуемся командой file из дистрибутива Linux.

Анализ на VirusTotal для этой DLL показал много интересных срабатываний.

В результате чего мы можем сделать выводы о том, какое вредоносное ПО использовалось и откуда оно было загружено.

Тренируемся на кошках

Для тех читателей, кого заинтересовала тема анализа трафика и выявление вредоносных активностей мы можем предложить для начала рассмотреть тестовые примеры реальных вредоносов, представленные на сайте https://www.malware-traffic-analysis.net/. На этом ресурсе есть образцы трафика, содержащие реальные вредоносы, так что пользоваться этими дампами надо аккуратно. Также на сайте есть инструкции с разбором этих дампов трафика и необходимыми пояснениями. При этом стоит отметить, что на этом веб ресурсе представлены достаточно свежие дампы трафика.

Также посмотреть дампы трафика можно на https://github.com/thongsia/Public-Pcaps, https://github.com/tatsuiman/malware-traffic-analysis.net. Здесь образцы будут не такие свежие, но зато их довольно много для различных видов вредоносов.

Подведем итоги

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

В этой статье мы подробно рассмотрели использование Wireshark для анализа дампа трафика и выявления в нем подозрительной активности. Надеемся, что этот материал был полезен и интересен для читателя.