Atexec-pro под капотом использует сервис TSCH против привычного ATSVC и работает через TCP (т.е. пайпы не используем). На мой взгляд примечательно то, что в своей работе он файловую систему практически не трогает (кроме создания самой таски), но при этом позволяет получать нам вывод. Обычно подобные инструменты для этих целей используют промежуточный файл на диске, который затем удаляют (atexec, smbexec, wmiexec). AtExec-pro же для хранения вывода команды использует описание задачи :)
Давайте разберем принцип выполнения отдельной произвольной команды в этом инструменте:
1) Формируются рандомное имя задачи (состоит из 8 символов [A-Za-z]) и рандомный ключ
2) Команда, которую мы хотим исполнить шифруется этим ключом (AES) и в дальнейшем будет записана в описание задачи, думаю этим и вызван максимальный размер.
3) Далее берется шаблон PS скрипта, в нём мы указываем ключ из шага 1, который предварительно конвертировали в base64, и указываем имя задачи. В случае обычной команды это будет https://github.com/Ridter/atexec-pro/blob/main/libs/powershells/cmd.ps1. Сам скрипт по имени задачи дергает описание, расшифровывает его, выполняет команду и далее обновляет описание с выводом этой команды.
4) Далее полученный PS скрипт переводим в base64. Этот скрипт будем выполнять в самой задаче при выполнении через
powershell -enc.5) Создаём задачу и запускаем её.
6) Далее в цикле дергаем задачу, ждём её остановки и забираем результат.
7) Удаляем задачу.
Что в итоге имеем на хосте?
Событие 4698 на создание задачи (будет в Action команда powershell.exe -NonInteractive -enc <...>)
События 4688 на запуск процесса
Событие 4104 на выполнение скрипта powershell
Событие 4702 на обновление задачи после выполнения команды (запись вывода)
Событие 4699 на удаление задачи
Наибольшую ценность в плане детекта имеют события 4698 и 4104.
4698 содержит описание созданной задачи, в ней мы можем зацепиться за фиксированное для atexec и atexec-pro строку
<StartBoundary>2015-07-15T20:35:13.2757294</StartBoundary> в поле TaskContent.4104 в данном случае будет содержать переведенную из Base64 строку (то есть не обфусцированную), именно в ней можно увидеть ранее рассмотренный выше шаблон с заполненными полями. 4104 включается через Script Block Logging, если явно он не включен, то будет логироваться через AMSI (будет логировать только подозрительные на своё усмотрение в журнал Powershell/Operational). На основе этого события можно надергать ключевых элементов для детекта из поля script_block_text.
Если у вас используются RPC-фильтры, то действуем аналогично SCShell (https://t.me/beaverdreamer/169), в данном случае у сервиса UUID 86D35949-83C9-4044-B424-DB363231FD0C.
#rpc #atexec #schtasks
