🧪 Мы — команда отдела сетевой экспертизы антивирусной лаборатории ESC и команда машинного обучения — однажды уже построили ML-модель на сетевом трафике, обучили ее на реальных сетевых сессиях и запустили в песочнице PT Sandbox для усиления возможностей по обнаружению вредоносов. Но мы решили не останавливаться на достигнутом — провели серию новых экспериментов, расширили набор входных признаков и протестировали модель на более сложных сценариях.

👾 Благодаря обновлению модель уже успела поймать несколько ранее неизвестных образцов: новую версию бэкдора Oyster, загрузчик APT GOFFEE, несколько стилеров (например, JustAskJacky) и еще ряд небольших, но подозрительных загрузчиков.

💡 Этот опыт подтверждает, что машинное обучение — отличный помощник традиционным сигнатурным решениям: оно видит скрытые паттерны и повышает общую детектируемость вредоносных сетевых сценариев.

Обо всем этом и не только рассказали в нашей статье на Хабре.

#network #avlab #ml
@ptescalator

В процессе мониторинга новых сетевых угроз в отделе сетевой экспертизы был замечен подозрительный трафик, который порождался файлом INTIMACAO_2025_006647.exe. Он маскировался под PDF и в переводе с португальского означал «Вызов в суд» (скриншот 1).

После запуска на хосте открывался документ-приманка и инициировалось сетевое взаимодействие с API Google, причем внешне оно было похоже на легитимные запросы, а не на типичный обмен с C2. Эта история нас заинтриговала, поэтому мы решили углубиться в анализ образца и понять, что именно он делает и какую роль в этой схеме играют неожиданные сетевые запросы к Google 🔍

Сразу перейдем к поведенческому анализу. После запуска в директорию /Temp дропались несколько PowerShell-скриптов: Clean_policies, Get_token и Apply_cbcm. Суть работы первого заключалась в подготовке зараженной машины — зачистке реестра от уже существующих локальных политик и настроек различных Chromium-браузеров, а также перезапуске браузерных процессов для оперативного применения внесенных изменений (скриншот 2). После этого Get_token.ps1 обращался к удаленному серверу и вытягивал оттуда некий токен (скриншот 3). В завершение третий скрипт, Apply_cbcm (скриншот 4), записывал полученный токен в политики Chrome на уровне системного реестра.

🙆 После более внимательного взгляда на имена параметров все стало достаточно прозрачно: вредонос проставлял CloudManagementEnrollmentToken и включал CloudPolicyOverridesPlatformPolicy, то есть явно переключал браузер на приоритет облачных политик. Такой набор названий практически прямым текстом указывал на использование Chrome Browser Cloud Management (судя по блогу Google Cloud, этот механизм должен был бороться со злом, а не примкнуть к нему) и на то, что основная цель здесь — привязать браузер к удаленной консоли управления, созданной злоумышленником.

Именно последствия работы этих скриптов мы в первую очередь и увидели в сетевом дампе (скриншот 5). Сначала обычным GET-запросом на C2 servidorunico.com возвращался тот самый enrollment-токен. Далее, после того как значение оказывалось прописано в реестре, браузер автоматически поднимал следующий этап цепочки — сам инициировал регистрацию в инфраструктуре Google и отправлял POST на API-эндпоинт с параметром request=register_browser. Ключевой маркер в этом запросе находился в заголовке Authorization, где токен передавался как GoogleEnrollmentToken, и именно это превращало внешне легитимный трафик к Google в индикатор привязки браузера к удаленному облачному управлению.

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

Stay tuned and happy hunting!

IoCs:

SHA256: 4442e1b545f0a571af113b0cc7455ecba1a603c81bbf84a52b9e61d332f97233
C2: servidorunico.com

#network #C2 #phishing #AVLab
@ptescalator

Например, эта функция появилась в протоколе SMB версии 3, для большинства DCERPC-соединений используется уровень аутентификации Packet Privacy, а сообщения протокола LDAP шифруются при включенной подписи (LDAP Signing).

У них есть кое-что общее: ключ шифрования Session Key в конечном счете генерируется на основе пароля учетной записи пользователя или ключа учетной записи устройства. Правда, сам алгоритм дешифрования сильно отличается в зависимости от протокола (NTLM или Kerberos).

1️⃣ NTLM-аутентификация

Самый простой случай: для расшифрования нам понадобится только пароль пользователя. Чтобы указать его в Wireshark, необходимо открыть Edit → Preferences, затем в параметрах протокола NTLMSSP вписать пароль в поле NT Password. Теперь рядом с зашифрованными блоками появятся расшифрованные (скриншот 1).

2️⃣ Kerberos

Для расшифрования сессий с аутентификацией Kerberos необходим пароль либо учетной записи пользователя, либо сервисной учетной записи, поскольку оба эти пароля участвуют в формировании сессионного ключа. По сути, нам сначала необходимо расшифровать значение сессионного ключа внутри Kerberos, а затем использовать его для декрипта SMB или других протоколов. Сначала необходимо сгенерировать keytab-файл.

Генерация keytab-файла по паролю пользователя

Из Kerberos-ответа AS-REP узнаем алгоритм шифрования и значение соли по формуле <REALM> + <cname>. В нашем случае они будут равны aes256-cts-hmac-sha1-96 и ATTDETT.STFo_walsh соответственно, причем важно обратить внимание на регистр (скр. 2).

С помощью Linux-утилиты kutils добавляем запись для нужного пользователя, используя команду addent с параметром -password. Параметры указываем как в команде ниже, причем параметр -k (Key Version Number, kvno) может быть любым числом. Сохраняем keytab при помощи команды wkt (скр. 3).

ktutil: addent -password -p o_walsh@ATTDETT.STF -k 2 -e aes256-cts-hmac-sha1-96

Генерация keytab-файла по ключу сервисной УЗ

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

Из TGS-ответа так же достаем алгоритм шифрования и с помощью той же утилиты kutils добавляем запись. Разница лишь в том, что вместо пароля используем параметр -key с ключом сервисной учетной записи, получить который можно, например, с помощью скрипта secretsdump из фреймворка Impacket. Параметр -p (principal) для Wireshark неважен, можем указать любые значения -p и -k (скр. 4).

ktutil: addent -key -p something@RANDOM.RND -k 666 -e aes256-cts-hmac-sha1-96

Как использовать полученный keytab-файл?

В Wireshark включаем параметр Try to decrypt Kerberos blobs:

Edit → Preferences → Protocols → KRB5 → Try to decrypt Kerberos blobs

Чтобы указать keytab-файл в Wireshark, необходимо открыть Edit → Preferences, затем в параметрах протокола KRB5 выбрать файл Kerberos keytab file. Часть полей будут отображаться нерасшифрованными — это нормально. Затем приступаем к дешифровке SMB3.

SMB3

Нам понадобится тот самый сессионный ключ. Найти его можно в поле keyvalue в пакетах TGS-REP или AP-REQ. Затем берем один из интересующих нас пакетов SMB3 и копируем из хедера Session ID (как на скр. 5, 6).

Указываем сессионный ключ и Session ID в поле Secret session key в Wireshark в параметрах протокола SMB2:

Edit → Preferences → Protocols → SMB2 → Secret session key for decryption

Бинго! Получаем расшифрованный SMB3 (скр. 7). Тот же самый алгоритм работает и для дешифрования других протоколов (DCERPC, LDAP и т. д.).

#dfir #tip #network
@ptescalator

w, err := os.OpenFile("/path/to/SSLKEYLOGFILE", os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0600)
config := &tls.Config{KeyLogWriter: w}

export SSLKEYLOGFILE=/path/to/keylog.log

export SSLKEYLOGFILE=/path/to/keylog.log
python main.py

node --tls-keylog=/path/to/keylog.log program.js

export NODE_OPTIONS=--tls-keylog=/path/to/keylog.log

"realitySettings": {
  "serverName": "yahoo.com",
  "publicKey": "publicKey",
  "shortId": "shortId",
  "fingerprint": "chrome",
  "spiderX": "/",
  "masterKeyLog": "/path/to/keylog"
}

Об этом на этой неделе в Китае во время третьего саммита по кибербезопасности, в рамках которого прошла шестая международная антивирусная конференция, рассказала Ксения Наумова, старший специалист отдела сетевой экспертизы антивирусной лаборатории PT ESC. В канале делимся подробностями из доклада 🍸

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

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

Мы решили, что этот недуг можно смело обернуть в преимущество: сигнатуры могут ловить не только экзактовые вредоносы, но и аномальное поведение, которое эти образцы порождают.

Что может являться интересующей нас аномалией?

➡️ Необычные размеры пакетов;
➡️ неизвестные протоколы;
➡️ подозрительные DNS-запросы / подозрительные TLD в DNS;
➡️ скачки трафика / задержки;
➡️ нарушения RFC;
➡️ применение обфускации, кодирования, шифрования;
➡️ и многое другое…

Мы провели небольшой анализ существующих правил на детектирование аномалий в наборе опенсорсных сигнатур Emerging Threats — HUNTING (скриншот 1):

➡️ ~510 правил на XOR-шифрование HTTP-запросов;
➡️ ~50 правил на кодированные в Base64 данные;
➡️ ~50 правил на подозрительные TLD в DNS;
➡️ правила на содержимое в ZIP, эксфильтрацию и т. п.

Показательный пример удачного hunting-правила:

alert http $HOME_NET any -> $EXTERNAL_NET any (sid: 2027117; msg:"ET HUNTING Suspicious POST with Common Windows Process Names - Possible Process List Exfiltration"; flow:established,to_server; http.method; content:"POST"; http.request_body; content:"csrss.exe"; content:"explorer.exe"; fast_pattern; content:"svchost.exe"; content:"lsass.exe"; ...)

А на скриншоте 2 — пример такого подозрительного трафика.

Однако искать аномалии можно не только с помощью открытых правил, но и самостоятельно — например, нарушения RFC, конкретно RFC 2616, определяющего протокол HTTP (скриншот 3). Можно поискать HTTP-запросы, у которых заголовок Referer не содержит схему:

alert http any any -> any any (msg: "SUSPICIOUS [PTsecurity] HTTP header Referer RFC2616 violation"; flow: established, to_server; content: "Referer|3a|"; http_header; content: !"Referer|3a 20|http"; http_header; ...)

В наши сети попадал бэкдор EAGERBEE и другие интересные образцы (скриншот 4).

Или, например, можно поискать простую команду PING внутри GZIP (скриншот 5):

alert tcp any any -> any any (msg: "SUSPICIOUS [PTsecurity] Generic Ping command inside Gzip"; flow: established, to_server; content: "|1f 8b 08 00 00 00 00 00 04 00 0b c8 cc 4b 07 00 c3 92 e7 85 04 00 00 00|"; ...)

По итогам срабатываний и дальнейших исследований к нам попадали SheetRAT и zgRAT (скриншот 6).

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

🫵 Выводы простые: generic-правила, особенно в корреляции друг с другом, могут значительно помогать в детектировании как давно известных, так и абсолютно новых угроз, о которых пока никто не знает. Можно пользоваться открытыми наборами сетевых сигнатур — ET Open, PT Open, а можно смело писать свои.

Happy hunting!

#suricata #network #signature #rules #hunt #detect
@ptescalator

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

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

1️⃣ Первый пример

Самым примитивным примером из сегодняшней подборки является использование конструкции:

document.write(unescape(atob(

Внутри нее зашит внешний подгружаемый скрипт flyit.com.ar/wp-includes/certificates/js_host/outlk.js, который содержит в себе jQuery библиотеку и дополнительный код, отправляющий на campusmin.sitb.edu.ar/completion/classes/php_host/_xls3.php?_do=xxx_form креды пользователя.

Минутка ликбеза: функция atob позволяет декодировать base64-строку, а document.write записывает содержимое аргумента в DOM активной страницы, подменяя ее текущее содержимое. В данном случае обфускация минимальная — в основном используется только сжатие (минификация).

2️⃣ Второй пример

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

Бесплатные деобфускаторы не справляются с преобразованием кода, поэтому прибегнем к ручному реверсу JavaScript: используемые выделенные функции, методы atob и document.write формируют веб-страницу, которая впоследствии подгружает скрипт с 7354770595-1323985617.cos.ap-seoul.myqcloud.com/attach%2Fbootstrap.min.js (обфусцирован с помощью бесплатного сервиса obfuscator.io), где как раз и содержится сбор кредов пользователя. Затем логин и пароль отправляются на C2 злоумышленников — miguel.uscourtaccess.com/next.php.

Сможете найти пасхалочки на скрине? 😏

3️⃣ Третий пример

В третьем случае для формирования поддельной страницы, представляющую собой брендированную версию стандартной формы ввода аутентификационных данных, используется фишинговый набор WikiKit. Он получил свое название за перенаправления на Википедию в случае отключенного в браузере JavaScript или недействительной фишинговой ссылки. Этот скрипт блокирует использование отладочных средств (хотя обойти их в целом несложно), а собранные данные отправляются на cotceur.com.

Какие у нас рекомендации? 🧐

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

• на вкладке Network браузера проверяйте origin подгружаемых дополнительных ресурсов, все-таки jQuery лучше получать с легитимного домена jQuery или известного CDN.

• использование функции atob (декодирование base64), еще и с

aHR0cHM6
aHR0cDo

внутри (в результате декодирования получается https: или http:) — поистине страшная смесь! А если добавить к этому document.write (добавления контента в html-документ) и unescape (устаревший метод для декодирования URI) — это точно редфлаг 🚩

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

💡 Хотим отметить, что не стоит видеть подозрительность везде — например, сжатие кода и популярные виды обфускации часто используют в легитимных проектах! Решили поразбирать JS-код сами just for run и увидели странный POST-запрос? Будем верить, что вы указали фальшивый пароль 🤞🏻

Happy hunting!

#hunt #network #phishing
@ptescalator

Надеюсь, вы помните, что у нас есть публичный репозиторий правил Suricata (писали о запуске ресурса в другом посте) и настроили suricata-update на поддержку официального источника правил ptrules/open ?

Если что, то вот ссылочка на репозиторий.

Не одними уязвимостями и хактулами живем 🙂

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

Из интересного:

— загрузчик RustyNet, стилер WorldWind, RAT'ник Slam, о которых писали ранее (в этом посте, этом и этом);
— вредонос для Android: SpyNote, Hydra, Zanubis;
— ужасный RAT'ник XWorm и много других интересных образцов.

Все правила вы можете найти на нашем сайте.

ВПО не пройдет, happy hunting!

#suricata #network #signature #rules
@ptescalator

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

Находка, как и ее предшественники, все также продолжает использовать сервисы icanhazip, mylnikov.org + Google Карты для определения внешнего IP-адреса и геолокации (скриншот 1). Реализация модуля сбора информации тоже не изменилась, за исключением пары структур.

🐔 Мутации же затронули сетевую часть и набор функций стилера. Теперь он не передает информацию через Telegram. Вместо этого сообщения улетают на С2-сервер злоумышленников в следующем порядке: checkin → exfiltration → close. Форматы этих сообщений представлены на скриншоте 2.

Из стилера также пропали функции для кражи VPN-конфигов и паролей от игровых лончеров и Wi-Fi. Но взамен развилась способность агрессивно распространяться через USB-носители. Если на внешнем диске есть экзешники, то стилер удалит их и запишет себя под их именами (скриншот 3).

Не находите, что повеяло старыми добрыми временами дикого вирусописательства? 😏

Чтобы уменьшить риск заражения, ставьте сигнатурные прививки и проходите антивирусные осмотры.

Заодно давайте покроем стилер правилом, детектирующим checkin:

alert tcp any any -> any any (msg: "STEALER [PTsecurity] WorldWind checkin"; flow: established, to_server; stream_size: client, <, 80; stream_size: server, =, 1; content: "|46 00 00 00|"; startswith; fast_pattern; content: "{|22|id|22 3a| 0"; within: 8; content: "|22|hwid|22 3a|"; within: 10; content: !"|20|"; distance: 2; within: 32; content: "|22|country|22 3a|"; distance: 32; content: !","; distance: 0; classtype: trojan-activity; metadata: malware_family WorldWind; sid: 1; rev: 1;)

IOCs:

84d52de2b69e14f26259da07297e02eb2c4ac32045a690f65a267fe931da0433
20.208.136.72:12346

Будьте здоровы и happy hunting!

#hunt #C2 #detect #ioc #malware #network #suricata
@ptescalator

Да это яяяя Внутри большой команды PT Expert Security Center есть отдельная группа экспертов, главная задача которых — разрабатывать правила обнаружения для сетевых средств защиты. Вы уже наверняка знакомы с некоторыми постами про сетевые артефакты от этой команды.

Спустя два года перерыва мы возвращаемся к вам с обновленным порталом и снова начинаем публиковать части своей экспертизы в виде Suricata-правил 🔥

Из обновлений:

1. Правила для последних уязвимостей.
2. Правила для обнаружения крайне популярных в узких кругах инструментов Croc и gsocket.
3. А также несколько правил для выявления горизонтального перемещения в сети Active Directory.

Настройте suricata-update на поддержку официального источника правил ptrules/open и следите за обновлениями на нашей странице в X.

👋🏼 Stay tuned

#suricata #network #signature #rules
@ptescalator

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg: "Slam V2.0 FB set ping"; flow: established, to_client; dsize: 8<>17; content: "?PING"; endswith; flowbits: set, slam_ping; flowbits: noalert; sid: 1; rev: 1; classtype: trojan-activity;)

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg: "Slam V2.0 ping-pong"; flow: established, to_server; dsize: 8<>17; content: "PONG#"; startswith; content: "#"; endswith; flowbits: isset, slam_ping; threshold: type limit, track by_dst, count 2, seconds 240; sid: 2; rev: 1; classtype: trojan-activity;)

SHA-256: e42088a37531929e3e775bdfacc5a3ee974e4f59d5290907c2131f434eef345b
C2: 77.231.153.42