34
AMSI – это интерфейс Microsoft, через который PowerShell, WSH, VBA, .NET и другие компоненты передают содержимое на проверку антивирусному движку до и во время исполнения, поэтому он давно стал ключевой точкой контроля для fileless- и script-based атак. В типовой цепочке задействуются AmsiInitialize, AmsiOpenSession, AmsiScanBuffer и AmsiScanString, а AmsiScanString по сути опирается на AmsiScanBuffer, поэтому именно эта функция часто фигурирует в публичных исследованиях как основная цель атакующих.
Memory patching в контексте AMSI означает изменение поведения уже загруженной в память amsi.dll внутри конкретного процесса, а не замену файла на диске. Публичные разборы прямо подчеркивают, что такой подход непостоянный: изменения живут только в памяти текущего процесса, а оригинальная библиотека на диске не затрагивается.
Почему техника деградировала
Еще несколько лет назад патчинг считался “рабочей классикой”, потому что позволял грубо оборвать путь от скриптового движка к проверке содержимого. Но к 2025–2026 году публичные материалы и обсуждения уже фиксируют другую картину: стандартные патчи для AmsiScanBuffer хорошо известны защитным продуктам, а типовые сигнатуры и поведенческие корреляции нередко делают такой обход шумным и краткоживущим.
Отдельная проблема в том, что обход AMSI сам по себе не решает задачу уклонения от всей защитной цепочки. В практических гайдах для red team прямо отмечается, что статический детект, AppLocker, Script Block Logging, ETW и последующее сканирование памяти могут сработать даже тогда, когда AMSI в процессе уже нарушен. Иными словами, в 2026 году memory patching – это уже не универсальный ключ, а скорее индикатор того, что защитная команда должна внимательно смотреть на целостность памяти и аномалии исполнения.
Что именно защищать
Для defenders главный вывод простой: защищать нужно не только точку вызова AMSI, но и весь контекст вокруг нее. Поскольку AMSI используется PowerShell, WSH, Office VBA, WMI и .NET, мониторинг должен охватывать запуск скриптовых интерпретаторов, динамическую загрузку сборок, нетипичные цепочки API-вызовов и изменения прав памяти в пользовательских процессах.
Особое внимание стоит уделять случаям, когда после “успешного” запуска скрипта происходит in-memory загрузка .NET-сборок. В разборе на Хабре показано, что при Assembly.Load включается дополнительный путь проверки через CLR, после чего AmsiScanBuffer снова становится критичной точкой, а значит однократное нарушение ранней инициализации не всегда дает злоумышленнику желаемый результат.
Практика детекта в 2026
На практике у синих команд работают три уровня контроля. Первый – телеметрия на изменения исполняемой памяти и подозрительные переходы прав страниц, второй – мониторинг PowerShell и .NET на предмет аномальной загрузки и отраженного исполнения, третий – последующее сканирование памяти, потому что публичные тесты показывают: патч может сработать сначала, но быть обнаружен позже во время отдельного memory scan.
Хороший признак компрометации – рассинхрон между “чистым” поведением процесса на уровне журналов и нетипичными изменениями в кодовых секциях загруженных модулей. Если процесс продолжает выполнять подозрительные скриптовые или .NET-действия, а AMSI-события выглядят “слишком тихо”, это повод проверять целостность amsi.dll в памяти, цепочки вызовов и наличие пользовательских хуков или исключений, перенаправляющих нормальный поток исполнения.
Что делать команде защиты