MoriAgent: как разобрать слабый файловый IOC-сигнал

По данным Подразделения CRATU, в сводке внешнего источника приведён набор из четырёх файловых индикаторов, отнесённых к инструментам MoriAgent. Это пригодный сигнал для первичной проверки, но не подтверждение инцидента, исполнения ВПО или связи активов с конкретной кампанией. Для набора нет данных о ролях файлов, путях, платформах, доставке, родительских процессах и сетевой активности. Совпадение хэша — начало расследования, а не атрибуция.Текущее наблюдениеВсе четыре IOC опубликованы в одной текущей сводке внешнего источника: впервые и в последний раз они отмечены 18 октября 2026 года. Это само по себе не подтверждает их взаимосвязь. Набор для ретропоиска: — MD5: 3e7226b66846f399e30f1dd94a004353 — MD5: ba9993a91744cd9c182ce5ab72212a4c — SHA1: b9a9fea976845f844adc99e956397ff1db6ad844 — SHA1: bf09f01d777e59c90df3711fce5935c2ef4f0667 Разные алгоритмы хэширования не доказывают, что перед нами этапы одной цепочки. По имеющимся данным нельзя определить, являются ли файлы загрузчиком, DLL-бэкдором, вспомогательными компонентами или несвязанными артефактами.Как интерпретировать совпадениеЗапись о файле в телеметрии не означает его запуск. Событие запуска в EDR или журнале процессов с хэшем образа подтверждает исполнение; путь и имя файла, пользователь, родительский процесс, командная строка и временная линия повышают достоверность и помогают оценить масштаб. Сетевые события также нельзя приписывать этим индикаторам без дополнительного подтверждения. Microsoft Defender Antivirus детектирует и удаляет Trojan:Win32/MoriAgent.A!dha, однако Microsoft не приводит на соответствующей странице технических деталей поведения. Имя детекта полезно для сверки покрытия конкретных файлов и версий сигнатур, но не заменяет расследование.Исторический контекстВ 2020 году ClearSky описала волну PudPoul/MoriAgent: исполняемые файлы доставляли легитимный PDF и вредоносную DLL MoriAgent. Один из вариантов исследователи назвали PudPoul по имени файла pudding.dll. ClearSky наблюдала установку инструмента, но не смогла установить его непосредственную цель в скомпрометированных сетях. Связь этой активности с MuddyWater авторы отчёта сформулировали с оговорками. Для текущих хэшей это не атрибуция и не доказательство повторения исторической схемы. Историю можно использовать как гипотезу для проверки, но не как описание текущего наблюдения.Что проверить SOC1. Запустите ретропоиск всех четырёх хэшей в доступной телеметрии. Для каждого совпадения сохраните имя узла, путь, время, источник записи и статус: файл обнаружен или образ был запущен. Отсутствие совпадения не исключает присутствия файла: учитывайте покрытие, срок хранения данных и поддерживаемые алгоритмы хэширования. 2. Для подтверждённого запуска поднимите дерево процессов. Отдельно проверьте создание файла и создание процесса: файл мог оказаться в кэше браузера, карантине антивируса, архиве, резервной копии или хранилище образцов без исполнения. 3. Восстановите события до появления файла по журналам почтового шлюза, прокси-сервера, браузера и средства защиты почты. При наличии изучите происхождение архива, документа или DLL. Не задавайте механизм доставки заранее: нет подтверждений вложения, ярлыка, PowerShell или DLL side-loading. 4. Если запуск подтверждён, сопоставьте его с событиями на том же узле: дочерними процессами, изменениями файлов и сетевыми соединениями. Эскалацию стоит строить на подтверждённом исполнении и его контексте, а не на единственном файловом совпадении. Вывод: набор следует проверить на конечных точках, но его доказательная сила ограничена четырьмя хэшами из одной внешней сводки.