kitos/Angerona
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Bof and assemblies completed

Browse Source
This commit is contained in:
marcos.luna
2025-12-16 14:22:51 +01:00
parent e45375cbd5
commit 9351102878
18 changed files with 372 additions and 544 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation-payload/Cazalla/commands.md
+64 -64
View File
@@ -812,6 +812,7 @@ inline_execute -BOF <bof_file> [-Arguments <arguments>]
- `string:hello` or `-z:hello` - Null-terminated string
- `wchar:hello` or `-Z:hello` - Wide character string
- `base64:abc==` or `-b:abc==` - Base64-encoded binary data
- `bytes:hexstring` - Hexadecimal string of bytes
**Examples:**
```
@@ -821,29 +822,37 @@ inline_execute -BOF netstat.x64.o -Arguments int32:4 string:TCP
```
**Features:**
- In-memory execution: BOFs are executed directly in the current process memory without creating new processes
- COFF loader: Full COFF loader implementation supporting x64 BOFs with relocations and symbol resolution
- Beacon API compatibility: Compatible with Cobalt Strike BOF API (BeaconPrintf, BeaconOutput, etc.)
- Output capture: Automatically captures and returns BOF output
- Argument parsing: Supports multiple argument types (int16, int32, string, wchar, base64)
- **In-Memory Execution**: BOFs are executed directly in the current process memory without creating new processes
- **COFF Loader**: Full COFF loader implementation supporting x64 BOFs with relocations and symbol resolution
- **Beacon API Compatibility**: Compatible with Cobalt Strike BOF API (BeaconPrintf, BeaconOutput, etc.)
- **Output Capture**: Automatically captures and returns BOF output via BeaconPrintf/BeaconOutput
- **Argument Parsing**: Supports multiple argument types (int16, int32, string, wchar, base64, bytes)
- **Thread Isolation**: BOFs execute in a separate thread with 30-second timeout to prevent agent crashes
- **Process Create Artifact**: Automatically creates a "Process Create" artifact for tracking
**Output:**
```
[inline_execute] BOF execution requested
[inline_execute] File ID: abc123...
[BOF Output]
Module Name: ntdll.dll
Base Address: 0x7ffa12340000
Size: 0x1f0000
```
**OPSEC Considerations:**
- Process Create artifact: BOF execution creates a "Process Create" artifact that is logged
- Memory allocation: BOFs allocate executable memory which may be detected by EDR solutions
- API hooking: Some EDR solutions monitor API calls that BOFs make
- Symbol resolution: External symbol resolution (LoadLibraryA, GetProcAddress) may be logged
- No new process: Unlike `shell` or `execute_assembly`, BOFs execute in-process, reducing some detection vectors
- **MEDIUM OPSEC RISK**: In-process execution reduces some detection vectors compared to process spawning
- **Process Create Artifact**: BOF execution creates a "Process Create" artifact that is logged in Mythic
- **Memory Allocation**: BOFs allocate executable memory (PAGE_EXECUTE_READWRITE) which may be detected by EDR solutions
- **API Monitoring**: External symbol resolution (LoadLibraryA, GetProcAddress) may be logged by EDR/XDR
- **Memory Scanning**: Allocated executable memory may be scanned by EDR memory protection features
- **No New Process**: Unlike `shell`, BOFs execute in-process, reducing some detection vectors
- **Thread Isolation**: BOFs execute in a separate thread with timeout protection
**Related:** [`inline_execute_assembly`](#inline_execute_assembly---execute-net-assembly-in-process), [`execute_assembly`](#execute_assembly---execute-net-assembly-in-remote-process), [Artifacts Support](features.md#artifacts-support)
**Technical Details:**
- Arguments are serialized using Packer format: `[size:4 bytes LE][data]`
- Boolean values are automatically converted to integers (0 or 1) before serialization
- BOFs that hang will timeout after 30 seconds and output will still be captured
**Related:** [`inline_execute_assembly`](#inline_execute_assembly---execute-net-assembly-in-process), [Artifacts Support](features.md#artifacts-support), [Detailed Documentation](commands/inline_execute.md)
---
@@ -862,7 +871,7 @@ inline_execute_assembly -Assembly <assembly_file> [-Arguments <args>] [--patchex
- `-Arguments` or `assembly_arguments` (optional): Arguments to pass to the assembly
- `--patchexit` or `patch_exit` (optional, default: false): Patch `System.Environment.Exit` to prevent the Beacon process from exiting
- `--amsi` or `amsi` (optional, default: false): Bypass AMSI by patching `clr.dll` instead of `amsi.dll` to avoid common detections
- `--etw` or `etw` (optional, default: false): Bypass ETW by EAT hooking `advapi32.dll!EventWrite`
- `--etw` or `etw` (optional, default: false): Bypass ETW by EAT hooking `advapi32.dll!EventWrite` to point to a function that returns immediately
**Examples:**
```
@@ -872,60 +881,51 @@ inline_execute_assembly -Assembly SharpHound.exe -Arguments "-c All" --patchexit
```
**Features:**
- In-process execution: Executes .NET assemblies in the current process without spawning new processes
- AMSI bypass: Optional AMSI bypass by patching clr.dll (more evasive than patching amsi.dll)
- ETW bypass: Optional ETW bypass via EAT hooking
- Exit patch: Prevents assemblies from calling `System.Environment.Exit` and terminating the agent
- Output capture: Automatically captures and returns assembly output
- BOF-based: Uses the Inline-EA BOF under the hood (executed via `inline_execute`)
- **In-Process Execution**: Executes .NET assemblies in the current process without spawning new processes
- **AMSI Bypass**: Optional AMSI bypass by patching `clr.dll` (more evasive than patching `amsi.dll`)
- **ETW Bypass**: Optional ETW bypass via EAT hooking
- **Exit Patch**: Prevents assemblies from calling `System.Environment.Exit` and terminating the agent
- **Output Capture**: Automatically captures and returns assembly output via completion callback
- **BOF-Based**: Uses the Inline-EA BOF (`inline-ea.x64.o`) under the hood (executed via `inline_execute`)
- **Process Create Artifact**: Automatically creates a "Process Create" artifact for tracking
- **Subtask Integration**: Creates a subtask that calls `inline_execute`, with output aggregated via completion callback
**How It Works:**
1. Retrieves the .NET assembly from Mythic
2. Searches for the Inline-EA BOF (`inline-ea.x64.o`) in Mythic's file store
3. Creates a subtask that calls `inline_execute` with the Inline-EA BOF
4. Passes the .NET assembly as raw bytes (hex-encoded) to the BOF
5. BOF loads the assembly into memory using .NET CLR APIs
6. Optional bypasses (AMSI, ETW) are applied if requested via flags
7. Assembly's entry point is executed with the provided arguments
8. Output is captured via `BeaconPrintf` and returned to the parent task through a completion callback
**Output:**
```
SharpUp execution started...
[*] Checking for insecure file permissions...
[*] Checking for unquoted service paths...
[+] Found: C:\Program Files\Vulnerable Service\service.exe
[*] Completed Privesc Checks in 17 seconds
```
**OPSEC Considerations:**
- Process Create artifact: Assembly execution creates a "Process Create" artifact
- CLR loading: Loading .NET assemblies into memory may be detected by EDR solutions
- AMSI bypass: Patching clr.dll for AMSI bypass may trigger behavioral detections
- ETW bypass: EAT hooking may be detected by advanced EDR solutions
- No new process: Executes in-process, reducing some detection vectors compared to `execute_assembly`
- **MEDIUM OPSEC RISK**: In-process execution provides better OPSEC than process spawning (no process injection)
- **Process Create Artifact**: Assembly execution creates a "Process Create" artifact that is logged in Mythic
- **CLR Loading**: Loading .NET assemblies into memory may be detected by EDR solutions
- **AMSI Bypass**: Patching `clr.dll` for AMSI bypass may trigger behavioral detections (more evasive than patching `amsi.dll`)
- **ETW Bypass**: EAT hooking `advapi32.dll!EventWrite` may be detected by advanced EDR solutions
- **No New Process**: Executes in-process, reducing some detection vectors compared to process spawning
- **Memory Allocation**: Allocates executable memory for the assembly, which may be scanned by EDR
- **Thread Isolation**: BOF execution runs in a separate thread with timeout protection
**Related:** [`inline_execute`](#inline_execute---execute-beacon-object-file-bof), [`execute_assembly`](#execute_assembly---execute-net-assembly-in-remote-process), [Artifacts Support](features.md#artifacts-support)
**Technical Details:**
- Uses Inline-EA BOF developed by @EricEsquivel (https://github.com/EricEsquivel/Inline-EA)
- Boolean flags (`--amsi`, `--etw`, `--patchexit`) are automatically converted to integers (0 or 1) for the BOF
- If BOF execution hangs, it will timeout after 30 seconds and output will still be captured
- Output is aggregated from the subtask and displayed directly in the main command (not as a subtask)
---
### `execute_assembly` - Execute .NET Assembly in Remote Process
Execute a .NET Assembly in a remote process and retrieve its output.
**Syntax:**
```
execute_assembly -Assembly <assembly_file> -Arguments <args>
```
**Parameters:**
- `-Assembly` or `assembly_name` (required): Name of an already uploaded .NET assembly (e.g., `SharpUp.exe`)
- `assembly_file` (required for new uploads): A new .NET assembly file to upload and execute
- `-Arguments` or `assembly_arguments` (required): Arguments to pass to the assembly
**Examples:**
```
execute_assembly -Assembly SharpUp.exe -Arguments "audit"
execute_assembly -Assembly Seatbelt.exe -Arguments "all"
execute_assembly -Assembly SharpHound.exe -Arguments "-c All -d domain.local"
```
**Features:**
- Shellcode conversion: Automatically converts .NET assemblies to shellcode using Donut
- Process injection: Injects shellcode into a target process (defaults to current process)
- Output capture: Captures and returns assembly output
- No file system: Assembly is executed entirely in memory without writing to disk
**OPSEC Considerations:**
- **HIGH OPSEC RISK**: Process injection is heavily monitored by EDR/XDR solutions
- Shellcode injection: Donut shellcode injection may trigger behavioral detections
- Process Create artifact: Creates a "Process Create" artifact
- Memory scanning: Injected shellcode may be scanned by EDR memory protection
- API monitoring: Process injection APIs (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread) are monitored
- Donut detection: Donut shellcode patterns may be detected by advanced security solutions
**Related:** [`inline_execute_assembly`](#inline_execute_assembly---execute-net-assembly-in-process) (better OPSEC), [`inline_execute`](#inline_execute---execute-beacon-object-file-bof), [Artifacts Support](features.md#artifacts-support)
**Related:** [`inline_execute`](#inline_execute---execute-beacon-object-file-bof), [Artifacts Support](features.md#artifacts-support), [Detailed Documentation](commands/inline_execute_assembly.md)
---
documentation-payload/Cazalla/commands/README.md
-1
View File
@@ -45,7 +45,6 @@ Complete documentation for all Cazalla agent commands, organized by category.
- [`inline_execute`](inline_execute.md) - Execute Beacon Object Files (BOFs)
- [`inline_execute_assembly`](inline_execute_assembly.md) - Execute .NET assemblies in-process
- [`execute_assembly`](execute_assembly.md) - Execute .NET assemblies in remote processes
## Control Commands
documentation-payload/Cazalla/commands/execute_assembly.md
-109
View File
@@ -1,109 +0,0 @@
# execute_assembly - Execute .NET Assembly in Remote Process
Execute a .NET Assembly in a remote process and retrieve its output.
## Description
The `execute_assembly` command converts a .NET assembly to shellcode using Donut and injects it into a remote process (or the current process if no target is specified). The assembly is executed in the target process and its output is captured and returned.
## Syntax
```
execute_assembly -Assembly <assembly_file> -Arguments <args>
```
## Parameters
- `-Assembly` or `assembly_name` (required): Name of an already uploaded .NET assembly (e.g., `SharpUp.exe`)
- `assembly_file` (required for new uploads): A new .NET assembly file to upload and execute
- `-Arguments` or `assembly_arguments` (required): Arguments to pass to the assembly
## Examples
```
# Execute assembly with arguments
execute_assembly -Assembly SharpUp.exe -Arguments "audit"
# Execute Seatbelt with all checks
execute_assembly -Assembly Seatbelt.exe -Arguments "all"
# Execute SharpHound for domain enumeration
execute_assembly -Assembly SharpHound.exe -Arguments "-c All -d domain.local"
```
## Features
- **Shellcode Conversion**: Automatically converts .NET assemblies to shellcode using Donut
- **Process Injection**: Injects shellcode into a target process (defaults to current process)
- **Output Capture**: Captures and returns assembly output
- **No File System**: Assembly is executed entirely in memory without writing to disk
## How It Works
1. The command retrieves the .NET assembly from Mythic
2. The assembly is converted to shellcode using Donut
3. A subtask is created to call `inject_shellcode` with the generated shellcode
4. The shellcode is injected into the target process
5. The .NET assembly is loaded and executed in the target process
6. Output is captured and returned to Mythic
## Output
```
[execute_assembly] Converting .NET Assembly to Shellcode...
[execute_assembly] Shellcode generated: 123456 bytes
[execute_assembly] Injecting shellcode into process...
[Assembly Output]
SharpUp execution started...
[*] Checking for insecure file permissions...
[+] Found: C:\Program Files\Vulnerable Service\service.exe
```
## OPSEC Considerations
- **HIGH OPSEC RISK**: Process injection is heavily monitored by EDR/XDR solutions
- **Shellcode Injection**: Donut shellcode injection may trigger behavioral detections
- **Process Create Artifact**: Creates a "Process Create" artifact
- **Memory Scanning**: Injected shellcode may be scanned by EDR memory protection
- **API Monitoring**: Process injection APIs (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread) are monitored
- **Donut Detection**: Donut shellcode patterns may be detected by advanced security solutions
## Technical Details
### Donut Integration
The command uses Donut to convert .NET assemblies to position-independent shellcode:
- Automatically handles .NET assembly loading
- Supports .NET Framework and .NET Core assemblies
- Generates position-independent shellcode
- Handles assembly dependencies
### Process Injection
The shellcode injection process:
1. Shellcode is generated from the .NET assembly
2. Shellcode is registered as a temporary file in Mythic
3. `inject_shellcode` command is called via subtask
4. Shellcode is injected into the target process
5. Assembly executes and output is captured
## Error Handling
The command handles various error scenarios:
- **Assembly Not Found**: Returns error if assembly file cannot be retrieved
- **Donut Conversion Failure**: Returns error if assembly cannot be converted to shellcode
- **Injection Failure**: Returns error if shellcode cannot be injected
- **Execution Failure**: Returns error if assembly fails to execute
## Related
- [`inline_execute_assembly`](inline_execute_assembly.md) - Execute .NET assemblies in-process (better OPSEC)
- [`inline_execute`](inline_execute.md) - Execute BOFs directly
- [Artifacts Support](../features.md#artifacts-support)
---
**Command Category:** Execution & Control
**Requires Admin:** No (unless injecting into protected process)
**MITRE ATT&CK:** [T1055 - Process Injection](https://attack.mitre.org/techniques/T1055/), [T1620 - Reflective Code Loading](https://attack.mitre.org/techniques/T1620/)
documentation-payload/Cazalla/commands/inline_execute.md
+29 -11
View File
@@ -53,23 +53,26 @@ inline_execute -BOF custom_bof.x64.o -Arguments int32:5678
## Output
The command returns the output captured from the BOF via `BeaconPrintf` or `BeaconOutput`:
```
[inline_execute] BOF execution requested
[inline_execute] File ID: abc123...
[inline_execute] Arguments: int32:1234
[BOF Output]
Module Name: ntdll.dll
Base Address: 0x7ffa12340000
Size: 0x1f0000
```
If the BOF produces no output, the command will indicate successful execution.
## OPSEC Considerations
- **Process Create Artifact**: BOF execution creates a "Process Create" artifact that is logged
- **Memory Allocation**: BOFs allocate executable memory which may be detected by EDR solutions
- **API Hooking**: Some EDR solutions monitor API calls that BOFs make
- **Symbol Resolution**: External symbol resolution (LoadLibraryA, GetProcAddress) may be logged
- **No New Process**: Unlike `shell` or `execute_assembly`, BOFs execute in-process, reducing some detection vectors
- **MEDIUM OPSEC RISK**: In-process execution reduces some detection vectors compared to process spawning
- **Process Create Artifact**: BOF execution creates a "Process Create" artifact that is logged in Mythic
- **Memory Allocation**: BOFs allocate executable memory (PAGE_EXECUTE_READWRITE) which may be detected by EDR solutions
- **API Monitoring**: External symbol resolution (LoadLibraryA, GetProcAddress) may be logged by EDR/XDR
- **Memory Scanning**: Allocated executable memory may be scanned by EDR memory protection features
- **No New Process**: Unlike `shell`, BOFs execute in-process, reducing some detection vectors
- **Thread Isolation**: BOFs execute in a separate thread with a 30-second timeout to prevent agent crashes
## Technical Details
@@ -82,16 +85,32 @@ The COFF loader implementation:
- Resolves external symbols via LoadLibraryA/GetProcAddress
- Maps sections with PAGE_EXECUTE_READWRITE permissions
### Thread Isolation
BOFs are executed in a separate thread to prevent agent crashes:
- **Timeout**: 30-second timeout for BOF execution
- **Thread Termination**: If BOF hangs, the thread is terminated after timeout
- **Output Capture**: Output is captured even if BOF hangs or times out
- **Agent Stability**: Main agent thread continues to function even if BOF crashes
### Beacon API Compatibility
The following Beacon API functions are supported:
- `BeaconPrintf` - Formatted output
- `BeaconOutput` - Raw output
- `BeaconPrintf` - Formatted output (captured and returned)
- `BeaconOutput` - Raw output (captured and returned)
- `BeaconDataParse` - Parse input data
- `BeaconDataInt`, `BeaconDataShort`, `BeaconDataExtract` - Data extraction
- `BeaconUseToken`, `BeaconRevertToken` - Token manipulation
- `BeaconIsAdmin` - Admin check
### Argument Serialization
Arguments are serialized using the Packer class format:
- Each argument is prefixed with its size (4 bytes, little-endian)
- Arguments are packed sequentially: `[size:4][data][size:4][data]...`
- The total buffer size is prepended to the argument buffer
- Boolean values are converted to integers (0 or 1) before serialization
## Error Handling
The command handles various error scenarios:
@@ -103,7 +122,6 @@ The command handles various error scenarios:
## Related
- [`inline_execute_assembly`](inline_execute_assembly.md) - Execute .NET assemblies in-process
- [`execute_assembly`](execute_assembly.md) - Execute .NET assemblies in remote processes
- [Artifacts Support](../features.md#artifacts-support)
---
documentation-payload/Cazalla/commands/inline_execute_assembly.md
+28 -17
View File
@@ -45,32 +45,40 @@ inline_execute_assembly -Assembly SharpHound.exe -Arguments "-c All" --patchexit
## How It Works
1. The command creates a subtask that calls `inline_execute` with the Inline-EA BOF
2. The .NET assembly is passed to the BOF as raw bytes
3. The BOF loads the assembly into memory using .NET CLR APIs
4. Optional bypasses (AMSI, ETW) are applied if requested
5. The assembly's entry point is executed with the provided arguments
6. Output is captured and returned to Mythic
1. The command retrieves the .NET assembly from Mythic
2. The command searches for the Inline-EA BOF (`inline-ea.x64.o`) in Mythic's file store
3. A subtask is created that calls `inline_execute` with the Inline-EA BOF
4. The .NET assembly is passed to the BOF as raw bytes (hex-encoded)
5. The BOF loads the assembly into memory using .NET CLR APIs
6. Optional bypasses (AMSI, ETW) are applied if requested via flags
7. The assembly's entry point is executed with the provided arguments
8. Output is captured via `BeaconPrintf` and returned to the parent task through a completion callback
9. The completion callback aggregates the output and displays it in the main command
## Output
The command returns the output from the .NET assembly execution:
```
[inline_execute_assembly] Assembly execution requested
[BOF Output from Inline-EA]
SharpUp execution started...
[*] Checking for insecure file permissions...
[*] Checking for unquoted service paths...
[+] Found: C:\Program Files\Vulnerable Service\service.exe
[*] Completed Privesc Checks in 17 seconds
```
The output is captured from the Inline-EA BOF execution and displayed directly in the main command (not as a subtask).
## OPSEC Considerations
- **Process Create Artifact**: Assembly execution creates a "Process Create" artifact
- **MEDIUM OPSEC RISK**: In-process execution provides better OPSEC than process spawning (no process injection)
- **Process Create Artifact**: Assembly execution creates a "Process Create" artifact that is logged in Mythic
- **CLR Loading**: Loading .NET assemblies into memory may be detected by EDR solutions
- **AMSI Bypass**: Patching clr.dll for AMSI bypass may trigger behavioral detections
- **ETW Bypass**: EAT hooking may be detected by advanced EDR solutions
- **No New Process**: Executes in-process, reducing some detection vectors compared to `execute_assembly`
- **Memory Allocation**: Allocates executable memory for the assembly, which may be scanned
- **AMSI Bypass**: Patching `clr.dll` for AMSI bypass may trigger behavioral detections (more evasive than patching `amsi.dll`)
- **ETW Bypass**: EAT hooking `advapi32.dll!EventWrite` may be detected by advanced EDR solutions
- **No New Process**: Executes in-process, reducing some detection vectors compared to process spawning
- **Memory Allocation**: Allocates executable memory for the assembly, which may be scanned by EDR
- **Thread Isolation**: BOF execution runs in a separate thread with timeout protection
## Technical Details
@@ -84,22 +92,25 @@ This command uses the Inline-EA BOF developed by @EricEsquivel:
### Bypass Options
- **--patchexit**: Patches `System.Environment.Exit` to prevent the assembly from terminating the agent process
- **--amsi**: Bypasses AMSI by patching `clr.dll` instead of `amsi.dll` (more evasive)
- **--etw**: Bypasses ETW by hooking `advapi32.dll!EventWrite` via Export Address Table (EAT) hooking
- **--patchexit**: Patches `System.Environment.Exit` to prevent the assembly from terminating the agent process. Default: `false`
- **--amsi**: Bypasses AMSI by patching `clr.dll` instead of `amsi.dll` (more evasive than traditional AMSI bypasses). Default: `false`
- **--etw**: Bypasses ETW by hooking `advapi32.dll!EventWrite` via Export Address Table (EAT) hooking. Default: `false`
**Note**: Boolean flags (`--amsi`, `--etw`, `--patchexit`) are automatically converted to integers (0 or 1) for the BOF.
## Error Handling
The command handles various error scenarios:
- **Assembly Not Found**: Returns error if assembly file cannot be retrieved from Mythic
- **BOF Not Found**: Returns error if Inline-EA BOF (`inline-ea.x64.o`) is not found in Mythic's file store
- **BOF Execution Failure**: Returns error if Inline-EA BOF cannot be executed
- **Assembly Load Failure**: Returns error if .NET assembly cannot be loaded
- **Bypass Failure**: May fail silently if bypasses cannot be applied
- **Timeout**: If BOF execution hangs, it will timeout after 30 seconds and output will still be captured
## Related
- [`inline_execute`](inline_execute.md) - Execute BOFs directly
- [`execute_assembly`](execute_assembly.md) - Execute .NET assemblies in remote processes
- [Artifacts Support](../features.md#artifacts-support)
---
documentation-payload/Cazalla/examples.md
+55
View File
@@ -494,6 +494,41 @@ keylog_start
keylog_stop
```
### BOF Execution
```bash
# Execute a BOF with no arguments
inline_execute -BOF whoami.x64.o
# Execute a BOF with integer argument
inline_execute -BOF listmods.x64.o -Arguments int32:1234
# Execute a BOF with multiple arguments
inline_execute -BOF netstat.x64.o -Arguments int32:4 string:TCP
# Execute a BOF with base64-encoded data
inline_execute -BOF custom_bof.x64.o -Arguments base64:YWJjZGVm
```
### .NET Assembly Execution (In-Process)
```bash
# Execute assembly with arguments
inline_execute_assembly -Assembly SharpUp.exe -Arguments "audit"
# Execute with AMSI and ETW bypass
inline_execute_assembly -Assembly Seatbelt.exe -Arguments "all" --amsi --etw
# Execute with all bypasses enabled
inline_execute_assembly -Assembly SharpHound.exe -Arguments "-c All -d domain.local" --patchexit --amsi --etw
# Execute privilege escalation check
inline_execute_assembly -Assembly SharpUp.exe -Arguments "audit" --patchexit
# Execute domain enumeration
inline_execute_assembly -Assembly SharpHound.exe -Arguments "-c All -d domain.local" --amsi --etw
```
### Complete Post-Exploitation Workflow
```bash
@@ -608,6 +643,26 @@ whoami
# (Commands run with domain credentials if token selected)
```
### Code Execution Workflow
```bash
# 1. Execute a BOF for lightweight operations
inline_execute -BOF whoami.x64.o
inline_execute -BOF listmods.x64.o -Arguments int32:1234
# 2. Execute .NET assembly for privilege escalation
inline_execute_assembly -Assembly SharpUp.exe -Arguments "audit" --patchexit
# 3. Execute .NET assembly with bypasses for enumeration
inline_execute_assembly -Assembly Seatbelt.exe -Arguments "all" --amsi --etw
# 4. Execute domain enumeration
inline_execute_assembly -Assembly SharpHound.exe -Arguments "-c All -d domain.local" --amsi --etw
# Note: inline_execute_assembly provides better OPSEC than process spawning
# (no process injection, in-process execution)
```
---
## Tips and Best Practices
documentation-payload/Cazalla/features.md
-1
View File
@@ -155,7 +155,6 @@ Cazalla automatically reports artifacts created during command execution, allowi
| **Process Create** | `shell` | Command execution via cmd.exe |
| **Process Create** | `inline_execute` | BOF execution in current process |
| **Process Create** | `inline_execute_assembly` | .NET assembly execution in-process |
| **Process Create** | `execute_assembly` | .NET assembly execution via process injection |
| **File Write** | `cp`, `mkdir`, `upload` | File creation or modification |
| **File Delete** | `rm` | File or directory deletion |
| **File Read** | `download` | File download operations |
documentation-payload/Cazalla/logging.md
+1 -1
View File
@@ -2,7 +2,7 @@
title = "Logging & Syslog"
chapter = false
weight = 50
pre = "6. "
pre = "7. "
+++
# 📊 Logging & Syslog
documentation-payload/Cazalla/opsec.md
+3 -10
View File
@@ -78,7 +78,6 @@ These commands are **highly detectable** and require careful consideration:
| Command | Risk Level | Detection Likelihood | Alternatives |
|---------|-----------|---------------------|--------------|
| `shell` | HIGH | High (cmd.exe spawn) | Use built-in Cazalla commands when possible |
| `execute_assembly` | HIGH | High (process injection, Donut shellcode) | `inline_execute_assembly` for in-process execution |
| `steal_token` | HIGH | High (EDR/XDR monitoring) | `make_token` when credentials available |
| `rm` (system files) | HIGH | Blocked for safety | Never delete system files |
| `screenshot` | HIGH | Screen capture detection | Use sparingly, consider timing |
@@ -90,7 +89,7 @@ These commands have **moderate detection risk**:
| Command | Risk Level | Detection Likelihood | Notes |
|---------|-----------|---------------------|-------|
| `inline_execute` | MEDIUM | Memory allocation, API calls | In-process execution reduces some detection vectors |
| `inline_execute_assembly` | MEDIUM | CLR loading, memory allocation | Better OPSEC than `execute_assembly` (no process injection) |
| `inline_execute_assembly` | MEDIUM | CLR loading, memory allocation | In-process execution (no process injection) |
| `download` | MEDIUM | File access logging | Large files may trigger DLP |
| `upload` | MEDIUM | File write detection | Suspicious extensions monitored |
| `socks` | MEDIUM | Network traffic analysis | High bandwidth usage |
@@ -118,7 +117,6 @@ These commands have **low detection risk**:
**Endpoint Detection and Response (EDR)** and **Extended Detection and Response (XDR)** solutions monitor:
- **Process Creation**: `shell` command spawns `cmd.exe` (highly monitored)
- **Process Injection**: `execute_assembly` uses Donut shellcode injection (heavily monitored)
- **Memory Allocation**: `inline_execute` and `inline_execute_assembly` allocate executable memory (may be scanned)
- **CLR Loading**: Loading .NET assemblies into memory may trigger EDR detections
- **Token Manipulation**: `steal_token` and `make_token` generate authentication events
@@ -128,7 +126,7 @@ These commands have **low detection risk**:
**Mitigation Strategies:**
- Use built-in Cazalla commands instead of `shell` when possible
- Prefer `inline_execute_assembly` over `execute_assembly` for better OPSEC (in-process vs process injection)
- Use `inline_execute_assembly` for .NET assembly execution (in-process, no process injection)
- Use `inline_execute` for BOFs when possible (no process creation)
- Prefer `make_token` over `steal_token` when credentials are available
- Avoid accessing LSASS or other critical system processes
@@ -339,12 +337,7 @@ Built-in Cazalla commands:
#### `inline_execute_assembly`
- **Risk**: MEDIUM
- **Detection**: CLR loading, memory allocation, AMSI/ETW bypass attempts may trigger behavioral detections
- **Best Practice**: Better OPSEC than `execute_assembly` (no process injection). Use `--amsi` and `--etw` flags when needed, but be aware they may be detected.
#### `execute_assembly`
- **Risk**: HIGH
- **Detection**: Process injection (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread), Donut shellcode patterns, memory scanning
- **Best Practice**: Use only when necessary. Prefer `inline_execute_assembly` for better OPSEC. High detection risk due to process injection techniques.
- **Best Practice**: In-process execution (no process injection). Use `--amsi` and `--etw` flags when needed, but be aware they may be detected.
#### `rev2self`
- **Risk**: LOW