GOFFEE (Paper Werewolf): Как мы разбирали агента COW — наследника Poseidon

Всем привет! И снова на связи отдел реагирования и цифровой криминалистики Angara MTDR.

В ходе одного из расследований мы наткнулись на группу серверов, где злоумышленники закрепились с помощью Go-агентов для C2-фреймворка Mythic. Всё выглядело стандартно: systemd-юниты, периодические колбэки, знакомая многим архитектура. Но когда мы попытались разобрать сами файлы, начались сюрпризы.

Исполнительные файлы были обфусцированы Garble и дополнительно упакованы UPX. Однако упаковщик оказался модифицированным: служебные заголовки оказались частично удалены или повреждены, и upx -d отказывался работать. После ручного восстановления мы всё-таки распаковали образцы, но исходных имён функций, пакетов и типов в коде практически не осталось — Garble сделал своё дело.

Первичные признаки указывали на агента Poseidon, который ранее уже встречался в атаках GOFFEE. Мы сверили находки с публичными версиями Poseidon и его форком Freyja — и поняли, это не они.

Перед нами оказалась самостоятельная ветка разработки. Мы назвали её COW — по внутреннему имени, сохранившемуся в некоторых образцах. В первой части мы расскажем:

• как восстановили происхождение COW и почему его основой стал именно Poseidon, а не Freyja;

• как нашли другие версии агента с новыми возможностями;

• как проследили развитие COW и сравнили его с публичными агентами Mythic.

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

Но обо всём по порядку.

Общая характеристика

GOFFEE (Paper Werewolf) — российско-ориентированная APT-группировка, ведущая активные шпионские операции как минимум с 2022 года. Основной способ первоначального доступа — тщательно подготовленный целевой фишинг, после которого злоумышленники быстро переходят к закреплению, разведке инфраструктуры и развертыванию собственного инструментария. Группа регулярно обновляет арсенал, сочетая открытые проекты с собственными разработками и постепенно смещая фокус в сторону Linux-инфраструктуры.

Основные способы проникновения

1. Целевые фишинговые письма и вредоносные вложения:
   - RAR-архивы;
   - документы Microsoft Office с макросами;
   - исполняемые файлы с двойным расширением (*.pdf.exe, *.doc.exe);
   - HTA-файлы.

2. Эксплуатация публично известных уязвимостей:
   - ProxyLogon (CVE-2021-26855, 26857, 26858, 27065);
   - ProxyNotShell (CVE-2022-41040, 41082);
   - CVE-2019-16098;

Основные инструменты

• PowerTaskel — PowerShell-агент для Mythic с модульной архитектурой.

• PowerModul — модульный имплант.

• MiRat — собственный агент Mythic.

• Sauropsida — Linux-руткит на основе Reptile.

• BindSycler — SSH-туннель на Go.

• DQuic — QUIC-туннель.

• Модифицированный Owowa.

Для сокрытия вредоносных компонентов активно применяются Garble, Ebowla, модифицированный UPX и собственные алгоритмы шифрования.

Основные цели

Группа не специализируется на одной отрасли. Среди известных жертв:

• государственные организации;

• энергетика;

• телеком;

• СМИ;

• строительство;

• промышленность;

• оборонный сектор;

• организации с доступом к другим компаниям.

Особенности деятельности

• Практически непрерывная активность.

• Большое количество одновременно проводимых кампаний.

• Значительные ресурсы на подготовку фишинга.

• Регулярная разработка собственного ВПО.

• Быстрое внедрение новых инструментов.

• Активное использование Linux-инфраструктуры.

• Хорошо развитые средства туннелирования и обхода сетевых ограничений.

• Использование доверенных отношений между организациями для дальнейшего развития атаки.

GOFFEE представляет собой зрелую кибершпионскую группировку со стабильной собственной разработкой вредоносного ПО. Если ранние кампании строились вокруг PowerShell и компрометации Microsoft Exchange, то с 2024–2025 годов заметен переход к более сложным операциям с использованием собственного инструментария для Linux, сетевого туннелирования и скрытого управления. Арсенал группы постепенно смещается от использования готовых средств к развитию собственных модифицированных агентов и инфраструктуры C2.

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

Исследование агентов Mythic

На нескольких скомпрометированных Linux-серверах были обнаружены Go-агенты для C2-фреймворка Mythic. Злоумышленники использовали их для удалённого управления системами, а закрепление выполняли с помощью юнитов systemd.

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

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

Были обнаружены похожие агенты Mythic для Linux и Windows. В найденных образцах сохранилось внутреннее название COW. Далее оно используется для обозначения исследуемой ветки и позволяет отделить её от публичных агентов Mythic. В следующих разделах последовательно рассмотрены происхождение COW, его отличия от Poseidon и Freyja, известные образцы и изменения, накопившиеся в них со временем.

Происхождение от Poseidon

После распаковки образцов в них удалось обнаружить строки get_tasking, tasking_size и post_response. Они относятся к протоколу обмена Mythic и используются при получении заданий и отправке результатов их выполнения. Это позволило определить C2-фреймворк, но не конкретный агент: те же элементы встречаются в разных проектах Mythic.

Среди публичных агентов, написанных на Go, наиболее близкими оказались Poseidon и Freyja. Такое сходство ожидаемо: Freyja создана на основе Poseidon и сохранила часть его архитектуры. Поэтому общая структура программы, протокол Mythic и совпадающие названия команд сами по себе не позволяли установить, от какой именно ветки происходит COW.

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

/Mythic/agent_code/pkg/utils/p2p/poseidon_tcp.go

Файл poseidon_tcp.go присутствовал в исходном коде Poseidon и использовался в реализации P2P-связи между агентами. Впоследствии структура публичного проекта изменилась, но в более ранних версиях этот файл можно найти под тем же именем и по сопоставимому пути.

Во Freyja файла poseidon_tcp.go не было. Поэтому находка указывает именно на кодовую базу Poseidon, а не только на общее происхождение обоих публичных агентов.

На то же происхождение указывает устройство отдельных компонентов агента. В COW сохранились характерные для Poseidon организация профилей, обработка заданий Mythic и структура P2P-модуля. В ранних образцах также встречаются унаследованные имена параметров и фрагменты реализации команд.

По отдельности эти совпадения нельзя считать однозначными: часть кода могла присутствовать и в других производных проектах. Однако вместе с сохранившимся именем poseidon_tcp.go они подтверждают, что основой COW послужил именно Poseidon.

Таким образом, Poseidon корректно описывает происхождение COW, но не должен автоматически использоваться как название исследованных образцов.

Отличия от публичных Poseidon и Freyja

Установленное происхождение от Poseidon ещё не означает, что обнаруженные образцы можно считать одной из его публичных версий. Сравнение показало различия сразу в нескольких компонентах агента: конфигурации, поддерживаемых командах, C2-профилях и механизмах связи p2p. Тем более были найдены версии под Windows, а Poseidon поддерживает только Linux и MacOS.

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

В ранних версиях Poseidon и Freyja конфигурационные параметры, как и в COW, передавались через ldflags. Позднее публичные агенты перешли к единой конфигурации в формате JSON, закодированной в Base64. COW сохранил прежний подход, но дополнил его собственными параметрами и изменил логику работы с C2.

Различался и набор доступных команд. Часть функций COW была унаследована от Poseidon, однако некоторые команды получили другую реализацию, а для ряда возможностей прямых аналогов в публичных Poseidon и Freyja не нашлось. Наиболее заметно это проявлялось в Windows-сборках, где присутствовали собственные средства работы с реестром, выполнения .NET-кода и закрепления в системе.

Основные различия приведены в таблице.

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

Ретроспективный поиск образцов

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

Поиск позволил обнаружить несколько Linux- и Windows-сборок. В отличие от файлов, полученных в ходе расследования, часть найденных образцов не была обфусцирована Garble. В них сохранились названия пакетов, функций и исходных файлов, что упростило восстановление структуры агента и сравнение с публичными проектами Mythic.

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

Связь найденных файлов с GOFFEE

Принадлежность найденных на VirusTotal образцов к инструментарию GOFFEE определялась по открытым источникам. Использовались два основных критерия:

• образец или его хеш был указан в публичном отчёте о компьютерном инциденте, связанном с GOFFEE;

• в конфигурации образца присутствовал C2-адрес, который ранее публиковался как часть инфраструктуры, использовавшейся в атаках GOFFEE.

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

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

Датировка

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

Поэтому для приблизительной датировки использовалась совокупность признаков:

• значение KillDate, если оно присутствовало в конфигурации;

• дата регистрации C2-домена;

• первое появление файла на VirusTotal;

• дата публикации отчёта, в котором упоминался образец;

• известный период соответствующего компьютерного инцидента.

Ни один из этих признаков, взятый отдельно, не определяет дату сборки. Например, KillDate задаёт окончание срока работы агента, а не момент его создания. По этой причине далее указываются приблизительные периоды использования образцов, а не точные даты выпуска версий COW.

Ограничения поиска

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

UPX удаляет исходные строки из доступного для поиска представления файла, а Garble изменяет имена пакетов, функций и типов. Поэтому упакованные или обфусцированные версии COW могли не попасть в результаты. Это особенно важно для Windows-сборок: отсутствие дополнительных файлов на VirusTotal не означает, что они не существовали или не использовались в атаках.

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

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

Конфигурация и механизмы связи

Конфигурация COW задавалась во время сборки с помощью ldflags. Значения параметров записывались в глобальные переменные, поэтому их удавалось восстановить даже в большинстве образцов, обфусцированных Garble.

Сокращённая строка сборки одного из исследованных файлов выглядела следующим образом:

-ldflags="-s -w \
-X 'cow/agent_code/pkg/profiles.UUID=a4dd86ec-fd00-44a6-90d5-a506ca3ca1b9' \
-X 'cow/agent_code/pkg/profiles.egress_order=WyJodHRwIiwiZHluYW1pY2h0dHAiLCJkbnMiXQ==' \
-X 'cow/agent_code/pkg/profiles.egress_failover=failover' \
-X 'cow/agent_code/pkg/profiles.failedConnectionCountThresholdString=10' \
-X 'cow/agent_code/pkg/profiles.http_callback_host=https://NewGenius.org' \
-X 'cow/agent_code/pkg/profiles.http_additional_callback_hosts=https://NewGeniusQwsa.org' \
-X 'cow/agent_code/pkg/profiles.http_callback_port=443' \
-X 'cow/agent_code/pkg/profiles.http_get_uri=packet/paint' \
-X 'cow/agent_code/pkg/profiles.http_post_uri=piece/candle' \
-X 'cow/agent_code/pkg/profiles.http_callback_interval=10' \
-X 'cow/agent_code/pkg/profiles.http_callback_jitter=23' \
-X 'cow/agent_code/pkg/profiles.http_encrypted_exchange_check=true' \
-X 'cow/agent_code/pkg/profiles.http_AESPSK=CFQTckGRcrZKhuhoNfmPPs3hfVrw0VS1IoLergO5mkI=' \
-X 'cow/agent_code/pkg/profiles.http_killdate=2026-03-21' \
-buildid="

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

Помимо основного сервера управления агент мог использовать резервные адреса, заданные в http_additional_callback_hosts. После определённого числа неудачных попыток подключения происходило переключение на следующий C2. Порог определялся параметром failedConnectionCountThresholdString.

Отдельно задавался порядок использования транспортов. Например, значение egress_order из приведённой конфигурации после декодирования содержало следующий список:

["http", "dynamichttp", "dns"]

Хотя профили dynamichttp и dns в найденном образце отсутствовали, как и код для их обработки.

P2P

Помимо прямого подключения к серверу управления, COW мог передавать трафик через другие скомпрометированные узлы. Однако способ организации P2P-связи различался в разных версиях агента.

В образцах первого поколения параметры P2P задавались ещё на этапе сборки вместе с остальной конфигурацией. В результате схема соединений была заранее определена и не могла изменяться после запуска агента. Это отличало COW от Poseidon и Freyja, где P2P-соединения создаются по команде оператора.

В более поздних образцах появился такой же механизм динамического подключения. Агент получил команды для создания и удаления P2P-каналов во время работы. В исследованных версиях поддерживались три варианта соединения:

link_p2p_tcp / unlink_p2p_tcp — соединение между двумя агентами COW;
link_poseidon_tcp / unlink_poseidon_tcp — подключение к агенту Poseidon;
link_webshell / unlink_webshell — передача трафика через webshell.

Таким образом, поздние версии COW уже поддерживали тот же принцип работы P2P, что и Poseidon и Freyja: оператор мог создавать и разрывать соединения между агентами непосредственно во время операции, без выпуска новой сборки.

Ранние образцы COW

К раннему поколению COW мы отнесли Linux- и Windows-сборки конца 2024 — начала 2025 года. Доступных файлов немного, поэтому границы этого периода приблизительные. Образцы объединяет небольшой набор команд и одинаковый подход к P2P: параметры соединения задавались при сборке и не могли меняться во время работы агента.

Linux-версия поддерживала четыре команды:

В Windows-сборке присутствовало пять команд:

Наборы заметно различались. Linux-версия позволяла выполнять команды и использовать заражённый узел как SOCKS-прокси. Windows-сборка вместо этого получила функции запуска шеллкода и .NET-сборок. Полноценных команд для работы с файлами, процессами и реестром в этих образцах ещё не было.

В Windows-файлах сохранились ссылки на дополнительные пакеты:

gitlab.rt/malware/offensive_gometa
gitlab.rt/malware/go-clr

Первый использовался в компонентах, связанных с выполнением полезной нагрузки, второй — для работы с .NET CLR. Эти зависимости не входили в публичный Poseidon и, вероятно, разрабатывались отдельно для Windows-ветки COW.

Главной особенностью ранних образцов была статическая настройка P2P. Вместе с параметрами HTTP-профиля при сборке задавались:

p2p_tcp_AESPSK
p2p_tcp_encrypted_exchange_check
p2p_tcp_port

Оператор заранее определял порт, ключ и режим первоначального обмена. Отдельных команд для создания или разрыва P2P-соединений в ранних сборках не было. Этим COW отличался от Poseidon и Freyja, где P2P-связью управляли динамически через команды агента.

Ранние Linux- и Windows-сборки нельзя считать полностью одинаковыми платформенными вариантами: их функциональность уже тогда различалась. Однако общая конфигурация, устройство агента и статическая настройка P2P позволяют отнести их к одному этапу развития COW.

Развитие Windows-ветки

В Windows-образцах 2025 года COW превратился из небольшого загрузчика с несколькими командами в полноценный агент удалённого управления. В нём появились средства для работы с файлами, процессами и реестром, выполнения PowerShell, создания снимков экрана и закрепления в системе.

Поддерживаемые команды можно разделить на несколько групп:

Команды inject_shellcode и load_exe_assembly позволяли выполнять дополнительные модули без сохранения их в виде отдельных исполняемых файлов. В первом случае агент получал шеллкод, во втором — .NET-сборку, которую загружал с помощью встроенного механизма работы с CLR.

Отдельный блок команд предназначался для закрепления. В COW было сразу четыре варианта: persistence_bat, persistence_load, persistence_load2 и persistence_run. Их наличие показывает, что Windows-ветка разрабатывалась с учётом длительной работы в системе, а не только запуска отдельных полезных нагрузок.

Изменился и подход к P2P. Вместо заранее заданного соединения оператор мог создавать и разрывать каналы во время работы агента. Для этого использовались три пары команд:

link_p2p_tcp      / unlink_p2p_tcp
link_poseidon_tcp / unlink_poseidon_tcp
link_webshell     / unlink_webshell

p2p_tcp использовался для связи между экземплярами COW. Отдельные команды poseidon_tcp обеспечивали взаимодействие с агентами Poseidon, а webshell позволял включить в цепочку скомпрометированный веб-сервер.

По набору возможностей Windows-версия 2025 года уже заметно отличалась от ранних образцов. Агент позволял проводить основные действия после компрометации без постоянной загрузки сторонних утилит: перемещаться по файловой системе, собирать данные, выполнять код, работать с реестром и поддерживать несколько вариантов связи с инфраструктурой Mythic.

Linux-образцы 2026 года

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

Команда shell запускала полученное задание через /bin/bash или /bin/sh. Для основных операций с файлами отдельная оболочка уже не требовалась: агент мог самостоятельно просматривать каталоги, читать, загружать и удалять файлы.

Набор P2P-команд в целом повторял подход, уже использовавшийся в Windows-ветке. Оператор мог во время работы агента создавать и разрывать соединения через p2p_tcp, poseidon_tcp или webshell. При этом в Linux-образцах не было команд для закрепления, аналогичных Windows-версии. В исследуемой инфраструктуре этот вопрос решался отдельно — запуск COW обеспечивали юниты systemd.

Ещё одно отличие касалось срока работы агента. В ранних образцах конфигурация содержала KillDate, после наступления которой агент должен был прекратить работу. В Linux-сборках 2026 года соответствующая проверка больше не выполнялась.

Все исследованные файлы этого периода были обфусцированы Garble и упакованы изменённым UPX. Это не добавляло агенту новых возможностей, но заметно усложняло его разбор и скрывало большую часть признаков, которые сохранились в ранних образцах.

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

Эволюция COW

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

Схема развития COW

Самые ранние известные версии были сравнительно простыми. Linux- и Windows-сборки уже отличались по своему назначению: Linux-агент использовался главным образом для получения оболочки и организации SOCKS-туннеля, тогда как Windows-версия была ориентирована на выполнение шеллкода и .NET-сборок. Несмотря на различия, обе использовали один и тот же подход к P2P-соединениям: адрес, порт и ключ задавались ещё при сборке и не менялись во время работы.

Следующий заметный этап относится к Windows-образцам 2025 года. К этому моменту агент перестал быть набором нескольких специализированных функций и превратился в полноценный инструмент удалённого управления. Существенно расширился набор команд, появились средства закрепления, а статическая схема P2P уступила место динамической. Вместо заранее заданных параметров оператор получил возможность создавать и разрывать соединения непосредственно во время работы агента, в том числе через p2p_tcp, poseidon_tcp и webshell.

Linux-образцы, обнаруженные в 2026 году, развивались по тому же пути. Если ранние версии ограничивались несколькими базовыми возможностями, то поздние уже поддерживали работу с файлами и процессами, создание снимков экрана и те же механизмы динамического подключения, что и Windows-ветка. При этом часть различий между платформами сохранилась. Например, команды закрепления присутствовали только в Windows-версии, тогда как в исследованном инциденте на Linux злоумышленники использовали обычные юниты systemd.

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

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

Именно поэтому современные версии COW уже нельзя считать очередной модификацией Poseidon. Кодовая база публичного агента послужила отправной точкой, однако за время развития проект получил собственные механизмы связи, новые команды и платформенные особенности. В образцах, которые использовала GOFFEE в 2025–2026 годах, связь с Poseidon уже скорее объясняет происхождение агента, чем описывает его реальные возможности.

Мы проследили путь COW от минималистичного агента с четырьмя командами до полноценного инструмента, который GOFFEE использует в своих операциях. Установили происхождение от Poseidon, описали отличия от публичных агентов и показали, как менялась архитектура, конфигурация и P2P-механизмы. Кодовая база публичного проекта послужила отправной точкой, но за два года COW приобрёл собственные механизмы связи, платформенные расширения и функциональность, которой нет у Poseidon. Однако технический разбор — лишь половина истории. Когда мы обратились к инфраструктуре, с которой взаимодействовали эти агенты, обнаружилось нечто более интересное: один из серверов операторов был настроен настолько небрежно, что позволил нам заглянуть в их повседневную работу — логи команд, журналы сканирований и NTLM-ответы от сотен систем. Именно этим — методами, целями и тактикой GOFFEE, которые скрывались за кодом, — мы займёмся во второй части.