ShellCloak

A proof-of-concept msi builder for red team research and controlled testing environments.

Disclaimer

This project and all associated materials are provided strictly for authorized red teaming and educational purposes only.

Unauthorized engagements using this project and associated materials are strictly prohibited. Unauthorized access on devices using this project and associated materials may cause serious legal consequences.

Installation

sudo apt install msitools wixl
git clone https://github.com/therustymate/ShellCloak.git
cd ShellCloak
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cd ./src

Usage

usage: ShellCloak.py [-h] [-o OUTPUT] [--custom CUSTOM] [--config-json CONFIG_JSON] [--product-name PRODUCT_NAME] [--language LANGUAGE] [--version VERSION] [--manufacturer MANUFACTURER]
                  [--upgrade-code UPGRADE_CODE] [--installer-version INSTALLER_VERSION] [--install-scope {perMachine,perUser}] [--root-dir-id ROOT_DIR_ID]
                  [--install-dir-name INSTALL_DIR_NAME] [--feature-title FEATURE_TITLE] [--file FILES] [--clear-files] [--print-config]

A proof-of-concept loader for red team research and controlled testing environments

options:
  -h, --help                              show this help message and exit
  -p PAYLOAD, --payload PAYLOAD           set python script payload path
  -o OUTPUT, --output OUTPUT              set output path
  --product-name PRODUCT_NAME             Product name
  --language LANGUAGE                     Language code, e.g. 1033
  --version VERSION                       Product version, e.g. 0.1.0
  --manufacturer MANUFACTURER             Manufacturer name
  --upgrade-code UPGRADE_CODE             Stable UpgradeCode GUID
  --installer-version INSTALLER_VERSION   InstallerVersion, e.g. 200
  --install-scope {perMachine,perUser}    Install scope
  --root-dir-id ROOT_DIR_ID               WiX root directory ID, e.g. ProgramFilesFolder or LocalAppDataFolder
  --install-dir-name INSTALL_DIR_NAME     Installation directory name
  --feature-title FEATURE_TITLE           Feature title
  --file FILES                            Add a file mapping. Repeatable. Format: --file "source=dist/app.exe,target=bin/app.exe"

Threat Model

Initial Access Vector

This project models an initial access scenario leveraging a .msi installer delivered through:

• Phishing attachments masquerading as legitimate software packages (Main Threat Model)
• Internal file shares or software repositories
• Simulated IT deployment workflows

Execution Flow

The modeled execution chain includes:

1. User executes the graphical .msi installer
2. Installer registers a auto startup run key during installation
3. Embedded python loads payload via .pth

Red Teamer Objectives

• Achieve initial code execution
• Minimize usage of unsigned binaries
• Evaluate evasion against AIR (Automated Investigation and Respond) endpoint security

Assumptions

• User interaction is required (installer execution)
• Target environment includes standard endpoint protections (EDR/AV)
• No prior persistence or privilege escalation is assumed

Architecture

The project is composed of the following components:

• MSI Wrapper
  • Installs singed binaries for Python 3.12
  • Registers a scheduled task (logon)
    • → Python (pip update)
      • → .PTH Script Loader
• Script Loader
  • Executes the included payload

Techniques Used

• Living-Off-The-Land: It is a technique where the attacker uses a legitimately signed binary (LOLBin, trusted binary) or executes/loads a directly prepared malicious binary in memory.

Detection Surface

• High-intensity Correlation Analysis: If the EDR strongly correlates scheduled tasks with Python execution, there is a high probability of detecting malicious activity.
• AMSI Detection: As a scripting language, Python can be monitored by amsi.dll for commands being executed in real time, which may lead to detection of malicious scripts.
• Abnormal Network Requests: Depending on the domain being connected to, abnormal connection requests may be detected.

Overall, this payload was developed to be detectable.

Mitigation & Defensive Insights

• ETW and AMSI Hardening: By strengthening AMSI rules, attacks using scripting languages can be defended against. Apply strong AMSI detection to well-known interpreters or scripting languages (e.g., Python, JavaScript, Java, .NET, VBS, etc.). Additionally, to defend against attacks on AMSI itself, such as AMSI patching, also harden ETW to defend against AMSI-related memory patches. In particular, detect/block artificial memory permission changes (e.g., RW -> RX) in the memory sections of ntdll.dll and amsi.dll. Through kernel-level event analysis, track and block memory state changes at specific locations.

• Correlation-based AIR: If correlation analysis suggests potential malware execution after the installation of a specific program, configure AIR (Automated Investigation and Response) to activate and proactively defend against threats. AIR can be triggered when a one-time immediate execution connection after program installation, or repeated execution connections after reboot/logon, are detected.

• Custom Rules: In a corporate environment, if there are departments or user groups that do not typically use or require scripting languages, set scripting languages to be blocked by default and allow them on a case-by-case basis as needed.

Limitations

• Direct Detection: In this scenario, it has been determined that detection is highly feasible in environments with mature behavioral correlation and telemetry coverage. The evasion capability against modern EDRs can be considered relatively weak. However, in less instrumented environments, detection may depend on rule quality and context.

• Custom C2 Development: Developing such functionality in Python introduces significant operational overhead and complicates efforts to maintain purely in-memory execution, particularly compared to lower-level or native implementations.

• Scenario Limitations: To achieve a state of partial evasion (warning-only) in a phishing attack, the target must manually install Python via the GUI, meaning this is only possible when the target is aware that they are installing Python. Silent installation (e.g., using /quiet) is more likely to trigger detection due to the combination of unattended installation behavior, process spawning patterns, and potential persistence setup, all of which are commonly monitored by modern EDR solutions.

Safe Usage Guidelines

• This project must only be used in isolated lab environments
• Do not deploy on production systems
• Do not use against systems without explicit authorization
• Payloads should remain non-destructive and controlled