kevoreilly/capev2Конфигурация вредоносного ПО и извлечение полезной нагрузки
Песочница используется для запуска вредоносных файлов в изолированной среде, одновременно инструментируя их динамическое поведение и собирая криминалистические артефакты.
CAPE была создана на основе Cuckoo v1, которая предоставляет следующие ключевые возможности на платформе Windows:
CAPE дополняет традиционный вывод песочницы Cuckoo несколькими ключевыми дополнениями:
Существует бесплатный демонстрационный экземпляр онлайн, который может использовать любой желающий:
https://capesandbox.com - Для активации учётной записи обратитесь к https://twitter.com/capesandbox
Cuckoo Sandbox начиналась как проект Google Summer of Code в 2010 году в рамках The Honeynet Project. Изначально она была спроектирована и разработана Клаудио Гуарниери (Claudio Guarnieri), первая бета-версия была опубликована в 2011 году. В январе 2014 года была выпущена Cuckoo v1.0.
2015 год стал поворотным, ознаменовавшись значительным форком в истории Cuckoo.
Разработка оригинального монитора и метода перехвата API была остановлена в
основном проекте Cuckoo. Он был заменён альтернативным монитором
с использованием формата сигнатур на основе restructuredText, компилируемого с помощью цепочки инструментов Linux,
созданного Юррианом Бремером (Jurriaan Bremer).
Примерно в то же время был создан форк под названием Cuckoo-modified Брэдом «Spender» Спенглером (Brad 'Spender' Spengler), продолживший разработку оригинального монитора со значительными улучшениями, включая поддержку 64-бит и, что важно, внедрение компилятора Microsoft Visual Studio.
В том же году началась разработка динамического инструмента командной строки для извлечения конфигурации и полезной нагрузки под названием CAPE в Context Information Security, автором стал Кевин О'Рейли (Kevin O'Reilly). Название было придумано как аббревиатура от 'Config And Payload Extraction' (Конфигурация и извлечение полезной нагрузки), а первоначальные исследования были сосредоточены на использовании перехватчиков API, предоставляемых библиотекой Microsoft Detours, для захвата распакованных вредоносных полезных нагрузок и конфигурации. Однако стало очевидно, что одних перехватчиков API недостаточно для обеспечения мощности и точности, необходимых для распаковки полезных нагрузок или конфигураций из произвольного вредоносного ПО.
По этой причине началось исследование новой концепции отладчика, позволяющей точно контролировать и инструментировать вредоносное ПО, избегая при этом использования интерфейсов отладки Microsoft, чтобы быть максимально скрытным. Этот отладчик был интегрирован в доказательный концепт инструмента командной строки на основе Detours, объединившись с перехватчиками API и обеспечив очень мощные возможности.
Когда начальная работа показала, что можно заменить Microsoft Detours на движок перехвата API от Cuckoo-modified, родилась идея CAPE Sandbox. С добавлением отладчика, автоматической распаковки, классификации на основе YARA и встроенного извлечения конфигурации, в сентябре 2016 года на 44con, CAPE Sandbox была впервые публично выпущена: CAPE версия 1.
Летом 2018 года проекту повезло увидеть начало огромных вкладов от Андрея «doomedraven» Бруховецкого, давнего участника Cuckoo. В 2019 году он начал гигантскую задачу портирования CAPE на Python 3 и в октябре того же года была выпущена CAPEv2.
CAPE постоянно разрабатывается и улучшается, чтобы идти в ногу с достижениями как в области вредоносного ПО, так и в возможностях операционных систем. В 2021 году была добавлена возможность программировать отладчик CAPE во время детонации с помощью динамических YARA-сканирований, что позволяет создавать динамические обходные пути для методов антипесочницы. Windows 10 стала операционной системой по умолчанию, а другие значительные дополнения включают интерактивный рабочий стол, захват полезной нагрузки AMSI (Anti-Malware Scan Interface), «перехват системных вызовов» на основе Microsoft Nirvana и контрмеры против прямых/косвенных системных вызовов на основе отладчика.
Вредоносное ПО может быть классифицировано в CAPE с помощью трёх механизмов:
Парсинг может выполняться с использованием собственного фреймворка CAPE, также поддерживаются следующие фреймворки: RATDecoders, DC3-MWCP, MalDuck или MaCo
def extract_config(data):, которая будет вызвана cape_utils.py, и без каких-либо сложностей.
CAPE использует многие методы или поведение вредоносного ПО для захвата распакованных полезных нагрузок:
Эти поведения приводят к захвату полезных нагрузок, которые внедряются, извлекаются или декомпрессируются для дальнейшего анализа. Кроме того, CAPE автоматически создаёт дамп процесса для каждого процесса или, в случае DLL, образ модуля DLL в памяти. Это полезно для образцов, упакованных простыми упаковщиками, где часто дамп образа модуля полностью распакован.
В дополнение к стандартным механизмам «пассивной» распаковки CAPE, можно включить «активную» распаковку, которая использует точки останова для обнаружения записи в недавно выделенные или защищённые области памяти, чтобы захватить распакованные полезные нагрузки как можно раньше до начала выполнения. Это включается через флажок в веб-интерфейсе или указанием опции unpacker=2 и по умолчанию отключено, так как может повлиять на качество детонации.
CAPE можно программировать через YARA-сигнатуры для распаковки конкретных упаковщиков. Например, упаковщики типа UPX очень распространены, и хотя в CAPE они приводят к пассивному захвату распакованных полезных нагрузок, захват по умолчанию происходит после того, как распакованная полезная нагрузка начала выполняться. Поэтому, обнаружив упаковщики, производные от UPX, динамически с помощью пользовательской YARA-сигнатуры и установив точку останова на последней инструкции упаковщика, можно захватить полезную нагрузку в её оригинальной точке входа (OEP) до того, как она начала выполняться.
Опция dump-on-api позволяет выгрузить модуль, когда он вызывает определённую функцию API, которая может быть указана в веб-интерфейсе (например, dump-on-api=DnsQuery_A).
Отладчик позволил CAPE развиваться за пределы своих первоначальных возможностей, которые теперь включают динамические обходы защиты от обхода. Поскольку современное вредоносное ПО часто пытается избежать анализа в песочницах, например, используя временные ловушки для виртуализации или обнаружения перехвата API, CAPE позволяет разрабатывать динамические контрмеры, объединяя действия отладчика внутри YARA-сигнатур для обнаружения уклоняющегося вредоносного ПО во время его детонации и выполняя манипуляции с потоком управления, чтобы заставить образец полностью детонировать или пропустить уклоняющиеся действия.
Быстрый доступ к отладчику возможен с помощью опций отправки bp0 – bp3, принимающих значения RVA или VA для установки точек останова, после чего будет выведена краткая трассировка инструкций, управляемая опциями count и depth (например, bp0=0x1234,depth=1,count=100).
Чтобы установить точку останова в точке входа модуля, используется ep вместо адреса (например, bp0=ep). Альтернативно, break-on-return позволяет установить точку останова на адресе возврата перехваченного API (например, break-on-return=NtGetContextThread). Необязательный параметр base-on-api позволяет установить базовый образ для точек останова RVA по вызову API (например, base-on-api=NtReadFile,bp0=0x2345).
Опции action0 – action3 позволяют выполнять действия при срабатывании точек останова, такие как дамп областей памяти (например, action0=dumpebx) или изменение потока управления выполнением (например, action1=skip). Документация CAPE содержит дополнительные примеры таких действий.
Репозиторий, содержащий код монитора CAPE, является отдельным.
Существует репозиторий сообщества с сигнатурами, содержащий несколько сотен сигнатур, разработанных сообществом CAPE. Все новые функции сообщества должны отправляться в этот репозиторий. Позже они могут быть перенесены в ядро, если разработчики смогут и захотят их поддерживать.
Пожалуйста, внесите свой вклад в этот проект, помогая создавать новые сигнатуры, парсеры или обходы для дополнительных семейств вредоносного ПО. В настоящее время в работе многое, так что следите за обновлениями.
Огромное спасибо @D00m3dR4v3n за самостоятельный порт CAPE на Python 3.
Python3
Только rooter должен выполняться от root, остальное — от пользователя cape. Запуск от root испортит права доступа.
conf!kvm-qemu.sh и cape2.sh ДОЛЖНЫ выполняться из сессии tmux, чтобы избежать проблем с ОС при разрыве ssh-соединения.<username> на реальный шаблон.<WOOT> внутри!sudo ./kvm-qemu.sh all <username> 2>&1 | tee kvm-qemu.logsudo ./cape2.sh base 2>&1 | tee cape.logconf.systemctl restart <имя_службы>journalctl -u <имя_службы>-h для меню помощи. Запуск службы в режиме отладки (-d) также может помочь.-h, но, пожалуйста, проверьте скрипты, чтобы понять, что они делают.git pullpython3 utils/community.py -waf см. -h перед выполнением, чтобы убедиться, что вы понимаетеgit add --all
git commit -m '[STASH]'
git pull --rebase origin master
# разрешить конфликты (rebase) при необходимости
git reset HEAD~1
# убедитесь, что репозиторий kevoreilly добавлен как удалённый (нужно выполнить только один раз)
git remote add kevoreilly https://github.com/kevoreilly/CAPEv2.git
# убедитесь, что все ваши изменения закоммичены в ветке, в которую вы будете сливать
git commit -a -m '<ваше сообщение коммита>'
# получите изменения из репозитория kevoreilly
git fetch kevoreilly
# слейте ветку master kevoreilly в вашу текущую ветку
git merge kevoreilly/master
# разрешите конфликты слияния, если необходимо
# отправьте в ваш репозиторий, если хотите
git push
Если вы используете CAPEv2 в своей работе, пожалуйста, цитируйте её, как указано в меню GitHub «Cite this repository».
pefile, так как каждый фиксирует версию, которую хочет.
pefile, так как она уже установлена. Вуаля, больше никакой боли.