capev2

Malware Configuration And Payload Extraction

https://github.com/kevoreilly/capev2

Science Score: 54.0%

This score indicates how likely this project is to be science-related based on various indicators:

  • CITATION.cff file
    Found CITATION.cff file
  • codemeta.json file
    Found codemeta.json file
  • .zenodo.json file
    Found .zenodo.json file
  • DOI references
  • Academic publication links
  • Committers with academic emails
    1 of 160 committers (0.6%) from academic institutions
  • Institutional organization owner
  • JOSS paper metadata
  • Scientific vocabulary similarity
    Low similarity (12.3%) to scientific vocabulary

Keywords

cape configs debugging-tools malware malware-analysis malware-research reverse-engineering sandbox unpacking

Keywords from Contributors

transformers cryptocurrencies mesh interactive osmnx fairness spacy-extension generic libreoffice languages
Last synced: 6 months ago · JSON representation ·

Repository

Malware Configuration And Payload Extraction

Basic Info
Statistics
  • Stars: 2,629
  • Watchers: 65
  • Forks: 489
  • Open Issues: 33
  • Releases: 0
Topics
cape configs debugging-tools malware malware-analysis malware-research reverse-engineering sandbox unpacking
Created over 6 years ago · Last pushed 6 months ago
Metadata Files
Readme Changelog License Citation Security

README.md

CAPE: Malware Configuration And Payload Extraction - Documentation

CAPE is a malware sandbox.

A sandbox is used to execute malicious files in an isolated environment whilst instrumenting their dynamic behaviour and collecting forensic artefacts.

CAPE was derived from Cuckoo v1 which features the following core capabilities on the Windows platform:

  • Behavioral instrumentation based on API hooking
  • Capture of files created, modified and deleted during execution
  • Network traffic capture in PCAP format
  • Malware classification based on behavioral and network signatures
  • Screenshots of the desktop taken during the execution of the malware
  • Full memory dumps of the target system

CAPE complements Cuckoo's traditional sandbox output with several key additions:

  • Automated dynamic malware unpacking
  • Malware classification based on YARA signatures of unpacked payloads
  • Static & dynamic malware configuration extraction
  • Automated debugger programmable via YARA signatures, allowing:
    • Custom unpacking/config extractors
    • Dynamic anti-sandbox countermeasures
    • Instruction traces
  • Interactive desktop

There is a free demonstration instance online that anyone can use:

https://capesandbox.com - For account activation reach to https://twitter.com/capesandbox

Some History

Cuckoo Sandbox started as a Google Summer of Code project in 2010 within The Honeynet Project. It was originally designed and developed by Claudio Guarnieri, the first beta release was published in 2011. In January 2014, Cuckoo v1.0 was released.

2015 was a pivotal year, with a significant fork in Cuckoo's history. Development of the original monitor and API hooking method was halted in the main Cuckoo project. It was replaced by an alternative monitor using a restructuredText-based signature format compiled via Linux toolchain, created by Jurriaan Bremer.

Around the same time, a fork called Cuckoo-modified was created by Brad 'Spender' Spengler continuing development of the original monitor with significant improvements including 64-bit support and importantly introducing Microsoft's Visual Studio compiler.

During that same year development of a dynamic command-line configuration and payload extraction tool called CAPE was begun at Context Information Security by Kevin O'Reilly. The name was coined as an acronym of 'Config And Payload Extraction' and the original research focused on using API hooks provided by Microsoft's Detours library to capture unpacked malware payloads and configuration. However, it became apparent that API hooks alone provide insufficient power and precision to allow for unpacking of payloads or configs from arbitrary malware.

For this reason research began into a novel debugger concept to allow malware to be precisely controlled and instrumented whilst avoiding use of Microsoft debugging interfaces, in order to be as stealthy as possible. This debugger was integrated into the proof-of-concept Detours-based command-line tool, combining with API hooks and resulting in very powerful capabilities.

When initial work showed that it would be possible to replace Microsoft Detours with Cuckoo-modified's API hooking engine, the idea for CAPE Sandbox was born. With the addition of the debugger, automated unpacking, YARA-based classification and integrated config extraction, in September 2016 at 44con, CAPE Sandbox was publicly released for the first time: CAPE version 1.

In the summer of 2018 the project was fortunate to see the beginning of huge contributions from Andriy 'doomedraven' Brukhovetskyy, a long-time Cuckoo contributor. In 2019 he began the mammoth task of porting CAPE to Python 3 and in October of that year CAPEv2 was released.

CAPE has been continuously developed and improved to keep pace with advancements in both malware and operating system capabilities. In 2021, the ability to program CAPE's debugger during detonation via dynamic YARA scans was added, allowing for dynamic bypasses to be created for anti-sandbox techniques. Windows 10 became the default operating system, and other significant additions include interactive desktop, AMSI (Anti-Malware Scan Interface) payload capture, 'syscall hooking' based on Microsoft Nirvana and debugger-based direct/indirect syscall countermeasures.

Classification

image

Malware can be classified in CAPE via three mechanisms: * YARA scans of unpacked payloads * Suricata scans of network captures * Behavioral signatures scanning API hook output

Config Extraction

image

Parsing can be done using CAPE's own framework, alternatively the following frameworks are supported: RATDecoders, DC3-MWCP, MalDuck, or MaCo

Special note about config parsing frameworks:

  • Due to the nature of malware, since it changes constantly when any new version is released, something might become broken!
  • We suggest using CAPE's framework which is simply pure Python with entry point def extract_config(data): that will be called by cape_utils.py and 0 complications.
    • As a bonus, you can reuse your extractors in other projects.

Automated Unpacking

image

CAPE takes advantage of many malware techniques or behaviours to allow for unpacked payload capture: - Process injection - Shellcode injection - DLL injection - Process Hollowing - Process Doppelganging - Extraction or decompression of executable modules or shellcode in memory

These behaviours will result in the capture of payloads being injected, extracted, or decompressed for further analysis. In addition CAPE automatically creates a process dump for each process, or, in the case of a DLL, the DLL's module image in memory. This is useful for samples packed with simple packers, where often the module image dump is fully unpacked.

In addition to CAPE's default 'passive' unpacking mechanisms, it is possible to enable 'active' unpacking which uses breakpoints to detect writing to newly allocated or protected memory regions, in order to capture unpacked payloads as early as possible prior to execution. This is enabled via web submission tickbox or by specifying option unpacker=2 and is left off by default as it may impact detonation quality.

CAPE can be programmed via YARA signature to unpack specific packers. For example, UPX-type packers are very common and, although in CAPE these result in unpacked payloads being passively captured, the default capture is made after the unpacked payload has begun executing. Therefore by detecting UPX-derived packers dynamically via custom YARA signature and setting a breakpoint on the final packer instruction, it is possible to capture the payload at its original entry point (OEP) before it has begun executing.

image

image

The dump-on-api option allows a module to be dumped when it calls a specific API function that can be specified in the web interface (e.g. dump-on-api=DnsQuery_A).

Debugger

The debugger has allowed CAPE to continue to evolve beyond its original capabilities, which now include dynamic anti-evasion bypasses. Since modern malware commonly tries to evade analysis within sandboxes, for example by using timing traps for virtualisation or API hook detection, CAPE allows dynamic countermeasures to be developed combining debugger actions within Yara signatures to detect evasive malware as it detonates, and perform control-flow manipulation to force the sample to detonate fully or skip evasive actions.

image image

Quick access to the debugger is made possible with the submission options bp0 through bp3 accepting RVA or VA values to set breakpoints, whereupon a short instruction trace will be output, governed by count and depth options (e.g. bp0=0x1234,depth=1,count=100). image

To set a breakpoint at the module entry point, ep is used instead of an address (e.g. bp0=ep). Alternatively break-on-return allows for a breakpoint on the return address of a hooked API (e.g. break-on-return=NtGetContextThread). An optional base-on-api parameter allows the image base for RVA breakpoints to be set by API call (e.g. base-on-api=NtReadFile,bp0=0x2345).

image

Options action0 - action3 allow actions to be performed when breakpoints are hit, such as dumping memory regions (e.g. action0=dumpebx) or changing the execution control flow (e.g. action1=skip). CAPE`s documentation contains further examples of such actions.

capemon

The repository containing the code for the CAPE's monitor is distinct.

Updates summary changelog

Community contributions

There is a community repository of signatures containing several hundred signatures developed by the CAPE community. All new community feature should be pushed to that repo. Later they can be moved to core if devs are able and willing to maintain them.

Please contribute to this project by helping create new signatures, parsers, or bypasses for further malware families. There are many in the works currently, so watch this space.

A huge thank you to @D00m3dR4v3n for single-handedly porting CAPE to Python 3.

Installation recommendations and scripts for optimal performance

  • Python3

    • agent.py is tested with python (3.7.2|3.8) x86. You should use x86 python version inside of the VM!
    • host tested with python3 version 3.10, 3.12, but newer versions should work too
  • Only rooter should be executed as root, the rest as cape user. Running as root will mess with permissions.

  • Become familiar with the documentation and do read ALL config files inside of conf folder!

  • For best compabitility we strongly suggest installing on Ubuntu 24.04 LTS and using Windows 10 21H2 as target.

  • kvm-qemu.sh and cape2.sh SHOULD BE executed from tmux session to prevent any OS problems if ssh connections breaks.

  • KVM is recommended as the hypervisor.

    • Replace <username> with a real pattern.
    • You need to replace all <WOOT> inside!
    • Read it! You must understand what it does! It has configuration in header of the script.
    • sudo ./kvm-qemu.sh all <username> 2>&1 | tee kvm-qemu.log
  • To install CAPE itself, cape2.sh with all optimizations

    • Read and understand what it does! This is not a silver bullet for all your problems! It has configuration in header of the script.
    • sudo ./cape2.sh base 2>&1 | tee cape.log
  • After installing everything save both installation logs as gold!

  • Configure CAPE by doing mods to config files inside conf folder.

  • Restart all CAPE services to pick config changes and run CAPE properly!

    • CAPE Services
      • cape.service
      • cape-processor.service
      • cape-web.service
      • cape-rooter.service
      • To restart any service use systemctl restart <service_name>
      • To see service log use journalctl -u <service_name>
    • To debug any problem, stop the relevant service and run the command that runs that service by hand to see more logs. Check -h for the help menu. Running the service in debug mode (-d) can help as well.
  • Reboot and enjoy!

  • All scripts contain help -h, but please check the scripts to understand what they are doing.

How to create VMs with virt-manager see docs for configuration

Virtual machine core dependency

How to update

  • CAPE: git pull
  • community: python3 utils/community.py -waf see -h before to ensure you understand

How to upgrade with a lot of custom small modifications that can't be public?

With rebase

``` git add --all git commit -m '[STASH]' git pull --rebase origin master

fix conflict (rebase) if needed

git reset HEAD~1 ```

With merge

```

make sure kevoreilly repo has been added as a remote (only needs to be done once)

git remote add kevoreilly https://github.com/kevoreilly/CAPEv2.git

make sure all your changes are commited on the branch which you will be merging

git commit -a -m ''

fetch changes from kevoreilly repo

git fetch kevoreilly

merge kevoreilly master branch into your current branch

git merge kevoreilly/master

fix merge conflicts if needed

push to your repo if desired

git push ```

How to cite this work

If you use CAPEv2 in your work, please cite it as specified in the "Cite this repository" GitHub menu.

Special note about 3rd part dependencies:

  • They becoming a headache, specially those that using pefile as each pins version that they want.
    • Our suggestion is clone/fork them, remove pefile dependency as you already have it installed. Volia no more pain.

Docs

Owner

  • Name: Kevin O'Reilly
  • Login: kevoreilly
  • Kind: user

Creator of CAPE Sandbox

Citation (CITATION.cff)

cff-version: 1.2.0
title: "CAPE: Malware Configuration And Payload Extraction"
message: "If you use this software, please cite it as below."
type: software
authors:
  - given-names: Kevin
    family-names: O'Reilly
  - given-names: Andriy
    family-names: Brukhovetskyy
url: "https://github.com/kevoreilly/CAPEv2"
version: 2
abstract: >
  CAPEv2: Malware Configuration And Payload Extraction is a
  malware sandbox.
keywords:
  - malware
  - sandbox
  - cape
  - capev2
  - analysis
license: GPL-3.0

Committers

Last synced: 9 months ago

All Time
  • Total Commits: 6,736
  • Total Committers: 160
  • Avg Commits per committer: 42.1
  • Development Distribution Score (DDS): 0.497
Past Year
  • Commits: 804
  • Committers: 48
  • Avg Commits per committer: 16.75
  • Development Distribution Score (DDS): 0.713
Top Committers
Name Email Commits
doomedraven d****n@g****m 3,389
Kevin O'Reilly k****y@g****m 857
GitHub Actions a****n@g****m 612
enzo 7****k 335
cccs-kevin 5****n 173
TheMythologist l****1@g****m 99
cccs-mog 1****g 93
doomedraven d****n@g****m 81
dependabot[bot] 4****] 71
Tommy Beadle t****e@s****m 61
Tommy Beadle t****e 54
Lint Action l****n@s****m 52
Nick Bargnesi n****i@s****m 50
Sean Whalen 4****k 49
qux-bbb 1****9@q****m 36
xiangchen96 x****n@g****m 35
Josh Feather 1****r 35
Bart b****e 34
diˈtekSHən 4****n 33
RazviOverflow r****w@g****m 32
Rony r****3@p****h 30
winson0123 7****3 30
Robin Koumis r****s@s****m 27
ClaudioWayne 3****e 26
Firmy Yang f****y@g****m 24
N1neSun 9****1@q****m 20
Mohannad Raafat 6****e 19
Yung Binary 9****y 19
Mohannad Raafat 6****0 17
David Santos 4****a 16
and 130 more...

Issues and Pull Requests

Last synced: 6 months ago

All Time
  • Total issues: 260
  • Total pull requests: 769
  • Average time to close issues: 25 days
  • Average time to close pull requests: 3 days
  • Total issue authors: 141
  • Total pull request authors: 76
  • Average comments per issue: 3.72
  • Average comments per pull request: 0.82
  • Merged pull requests: 627
  • Bot issues: 0
  • Bot pull requests: 61
Past Year
  • Issues: 129
  • Pull requests: 380
  • Average time to close issues: 5 days
  • Average time to close pull requests: 1 day
  • Issue authors: 75
  • Pull request authors: 39
  • Average comments per issue: 2.61
  • Average comments per pull request: 0.6
  • Merged pull requests: 301
  • Bot issues: 0
  • Bot pull requests: 37
Top Authors
Issue Authors
  • seanthegeek (18)
  • xme (12)
  • ChrisThibodeaux (9)
  • doomedraven (7)
  • superonion7890 (6)
  • waason (5)
  • YungBinary (5)
  • CarsonHrusovsky (4)
  • qux-bbb (4)
  • desen33 (4)
  • dfr-fands (4)
  • pschivo (4)
  • bartblaze (4)
  • joser12345678 (3)
  • RyanInsolencee (3)
Pull Request Authors
  • doomedraven (121)
  • enzok (111)
  • dependabot[bot] (61)
  • xiangchen96 (44)
  • rkoumis (40)
  • josh-feather (37)
  • tbeadle (36)
  • ditekshen (25)
  • cccs-mog (25)
  • ClaudioWayne (23)
  • dsecuma (20)
  • ChrisThibodeaux (16)
  • nbargnesi (12)
  • YungBinary (12)
  • bartblaze (12)
Top Labels
Issue Labels
aws (2) azure (2) duplicate (1) help wanted (1)
Pull Request Labels
dependencies (61) python (61) onhold (1)

Dependencies

.github/workflows/antitemplaters.yml_disabled actions
  • actions/checkout v3 composite
  • lucasbento/auto-close-issues v1.0.2 composite
.github/workflows/cape_sh.yml actions
  • actions/checkout v2 composite
.github/workflows/export-requirements.yml actions
  • actions/checkout v3 composite
  • actions/setup-python v4 composite
.github/workflows/pip-audit.yml actions
  • actions/checkout v3 composite
  • pypa/gh-action-pip-audit v1.0.0 composite
.github/workflows/python-package.yml actions
  • actions/checkout v3 composite
  • actions/setup-python v4 composite
  • dorny/paths-filter v2 composite
.github/workflows/todo.yml_disabled actions
  • actions/checkout master composite
  • alstr/todo-to-issue-action v4.6.8 composite
.github/workflows/yara-audit.yml actions
  • actions/checkout v3 composite
  • actions/setup-python v4 composite
docs/requirements.txt pypi
poetry.lock pypi
  • 183 dependencies
pyproject.toml pypi
  • black ^22.3.0 develop
  • func-timeout ^4.3.5 develop
  • httpretty ^1.1.4 develop
  • isort ^5.10.1 develop
  • pre-commit ^2.19.0 develop
  • pytest 7.2.0 develop
  • pytest-asyncio 0.18.3 develop
  • pytest-cov 3.0.0 develop
  • pytest-django 4.5.2 develop
  • pytest-mock 3.7.0 develop
  • pytest-pretty 1.1.0 develop
  • pytest-xdist 3.0.2 develop
  • pytest_asyncio 0.18.3 develop
  • tenacity 8.1.0 develop
  • Cython 0.29.24
  • Django 4.2.5
  • Jinja2 ^3.1.2
  • LnkParse3 1.2.0
  • Pebble 4.6.3
  • Pillow >=8.2.0
  • SFlock2 0.3.52
  • SQLAlchemy 1.4.22
  • SQLAlchemy-Utils 0.37.8
  • Werkzeug 2.2.3
  • alembic 1.9.4
  • bs4 0.0.1
  • cachetools ^5.3.0
  • capstone 4.0.2
  • certifi 2023.07.22
  • channels ^3.0.5
  • chardet 4.0.0
  • crudini 0.9.4
  • cryptography 41.0.4
  • django-allauth 0.54.0
  • django-crispy-forms 1.14.0
  • django-csp 3.7
  • django-extensions 3.2.1
  • django-ratelimit 3.0.1
  • django-recaptcha 3.0.0
  • django-settings-export 1.2.1
  • djangorestframework 3.14.0
  • dnfile 0.13.0
  • dnspython 2.1.0
  • dpkt 1.9.6
  • flare-capa 6.0.0
  • gevent 23.9.1
  • greenlet 3.0.0rc3
  • gunicorn ^20.1.0
  • maxminddb 2.2.0
  • netstruct 1.1.2
  • olefile 0.46
  • oletools 0.60
  • orjson 3.8.5
  • packaging 23.1
  • pefile *
  • psutil 5.8.0
  • psycopg2-binary ^2.9.5
  • pyOpenSSL 23.2.0
  • pyattck 7.1.1
  • pycryptodomex 3.14.0
  • pydeep2 0.5.1
  • pygal 2.4.0
  • pyguacamole ^0.11
  • pymongo >=4.0.1
  • python ^3.8
  • python-dateutil 2.8.2
  • python-tlsh 4.5.0
  • python-whois 0.7.3
  • pytz 2021.1
  • pyzipper 0.3.5
  • regex 2021.7.6
  • requests 2.31.0
  • requests-file 1.5.1
  • ruff 0.0.290
  • setproctitle 1.3.2
  • setuptools 68.0.0
  • tldextract 3.5.0
  • uvicorn ^0.18.2
  • yara-python 4.3.1
requirements.txt pypi
  • alembic ==1.9.4
  • anyio ==4.0.0
  • asgiref ==3.7.2
  • attrs ==21.4.0
  • autobahn ==23.1.2
  • automat ==22.10.0
  • backports-zoneinfo ==0.2.1
  • beautifulsoup4 ==4.12.2
  • bs4 ==0.0.1
  • cachetools ==5.3.1
  • capstone ==4.0.2
  • certifi ==2023.7.22
  • cffi ==1.15.1
  • channels ==3.0.5
  • chardet ==4.0.0
  • charset-normalizer ==3.2.0
  • click ==8.1.7
  • colorama ==0.4.6
  • colorclass ==2.2.2
  • commonmark ==0.9.1
  • constantly ==15.1.0
  • crudini ==0.9.4
  • cryptography ==41.0.4
  • cxxfilt ==0.2.2
  • cython ==0.29.24
  • daphne ==3.0.2
  • defusedxml ==0.7.1
  • django ==4.2.5
  • django-allauth ==0.54.0
  • django-crispy-forms ==1.14.0
  • django-csp ==3.7
  • django-extensions ==3.2.1
  • django-ratelimit ==3.0.1
  • django-recaptcha ==3.0.0
  • django-settings-export ==1.2.1
  • djangorestframework ==3.14.0
  • dncil ==1.0.2
  • dnfile ==0.13.0
  • dnspython ==2.1.0
  • dpkt ==1.9.6
  • easygui ==0.98.3
  • et-xmlfile ==1.1.0
  • exceptiongroup ==1.1.3
  • filelock ==3.12.4
  • fire ==0.4.0
  • flare-capa ==6.0.0
  • funcy ==2.0
  • future ==0.18.3
  • gevent ==23.9.1
  • greenlet ==3.0.0rc3
  • gunicorn ==20.1.0
  • h11 ==0.14.0
  • halo ==0.0.31
  • httptools ==0.6.0
  • hyperlink ==21.0.0
  • ida-netnode ==3.0
  • ida-settings ==2.1.0
  • idna ==3.4
  • importlib-metadata ==3.3.0
  • importlib-resources ==6.0.1
  • incremental ==22.10.0
  • iniparse ==0.5
  • intervaltree ==3.1.0
  • jinja2 ==3.1.2
  • lnkparse3 ==1.2.0
  • log-symbols ==0.0.14
  • mako ==1.2.4
  • markupsafe ==2.1.3
  • maxminddb ==2.2.0
  • msgpack ==1.0.5
  • msoffcrypto-tool ==5.1.1
  • netstruct ==1.1.2
  • networkx ==3.1
  • oauthlib ==3.2.2
  • olefile ==0.46
  • oletools ==0.60
  • openpyxl ==3.1.2
  • orjson ==3.8.5
  • packaging ==23.1
  • pcodedmp ==1.2.6
  • pebble ==4.6.3
  • pefile ==2023.2.7
  • pillow ==10.0.1
  • protobuf ==4.23.4
  • psutil ==5.8.0
  • psycopg2-binary ==2.9.7
  • pyasn1 ==0.4.8
  • pyasn1-modules ==0.2.8
  • pyattck ==7.1.1
  • pyattck-data ==2.6.3
  • pycparser ==2.21
  • pycryptodomex ==3.14.0
  • pydantic ==1.10.9
  • pydeep2 ==0.5.1
  • pyelftools ==0.29
  • pygal ==2.4.0
  • pygments ==2.16.1
  • pyguacamole ==0.11
  • pyjwt ==2.8.0
  • pymongo ==4.5.0
  • pyopenssl ==23.2.0
  • pyparsing ==2.4.7
  • pysocks ==1.7.1
  • python-dateutil ==2.8.2
  • python-dotenv ==1.0.0
  • python-flirt ==0.8.6
  • python-magic ==0.4.27
  • python-tlsh ==4.5.0
  • python-whois ==0.7.3
  • python3-openid ==3.2.0
  • pytz ==2021.1
  • pyyaml ==6.0
  • pyzipper ==0.3.5
  • regex ==2021.7.6
  • requests ==2.31.0
  • requests-file ==1.5.1
  • requests-oauthlib ==1.3.1
  • rich ==12.6.0
  • ruamel-yaml ==0.17.32
  • ruamel-yaml-clib ==0.2.7
  • ruff ==0.0.290
  • service-identity ==23.1.0
  • setproctitle ==1.3.2
  • setuptools ==68.0.0
  • sflock2 ==0.3.52
  • six ==1.16.0
  • sniffio ==1.3.0
  • sortedcontainers ==2.4.0
  • soupsieve ==2.5
  • spinners ==0.0.24
  • sqlalchemy ==1.4.22
  • sqlalchemy-utils ==0.37.8
  • sqlparse ==0.4.4
  • tabulate ==0.9.0
  • termcolor ==2.3.0
  • tldextract ==3.5.0
  • tqdm ==4.65.0
  • twisted ==23.8.0
  • twisted-iocpsupport ==1.0.4
  • txaio ==23.1.1
  • typing-extensions ==4.7.1
  • tzdata ==2023.3
  • unicorn ==2.0.1.post1
  • urllib3 ==2.0.4
  • uvicorn ==0.18.3
  • uvloop ==0.17.0
  • viv-utils ==0.7.9
  • vivisect ==1.1.1
  • watchfiles ==0.20.0
  • wcwidth ==0.2.6
  • websockets ==11.0.3
  • werkzeug ==2.2.3
  • win-unicode-console ==0.5
  • yara-python ==4.3.1
  • zipp ==3.16.2
  • zope-event ==5.0
  • zope-interface ==6.0