mirror of
https://github.com/magnus919/agent-skills.git
synced 2026-09-12 20:16:29 +03:00
313 lines
12 KiB
Markdown
313 lines
12 KiB
Markdown
# Security Analysis: Rules, Scoring, and Interpretation
|
|
|
|
Reference for interpreting the security analysis commands: `binary triage`,
|
|
`binary suspicious-apis`, `binary capability-map`, and `binary diagnostics`.
|
|
Load this when interpreting security rule output, understanding risk scores,
|
|
or deciding which findings to prioritize.
|
|
|
|
## Security Command Overview
|
|
|
|
| Command | What It Does | Primary Output |
|
|
|---------|-------------|----------------|
|
|
| `binary triage` | Broad automated assessment with rule engine | observations[], heuristics[], unknowns[] |
|
|
| `binary suspicious-apis` | API-level risk scoring against priority rules | matches[] with risk_score and rule_id |
|
|
| `binary capability-map` | Functional area suggestions from rule-derived indicators | capabilities[] with evidence sources |
|
|
| `binary diagnostics` | Cumulative diagnostic log from all commands | items[] with severity, category, message |
|
|
|
|
## Rule Engine Architecture
|
|
|
|
The rule engine is the security analysis core. It evaluates rules against
|
|
backend data and produces structured results.
|
|
|
|
### Rule Types
|
|
|
|
| Type | Evaluated By | Purpose |
|
|
|------|-------------|---------|
|
|
| Priority rules | `suspicious-apis` | High-signal detection rules for known-malicious API patterns |
|
|
| Heuristic rules | `triage` | Broad pattern matching for suspicious characteristics |
|
|
| Capability rules | `capability-map` | Functional area classification from indicators |
|
|
|
|
### Rule Components
|
|
|
|
Each rule defines:
|
|
- `rule_id`: Stable identifier (e.g., `process-injection`, `credential-access`,
|
|
`network-listener`).
|
|
- `pattern`: What to match (API names, string patterns, section characteristics).
|
|
- `confidence`: How to score matches (evidence count, strength, false-positive
|
|
rate).
|
|
- `priority`: Whether this rule is a priority rule (evaluated by
|
|
`suspicious-apis`).
|
|
|
|
### Rules Are Repository-Owned
|
|
|
|
Rules live in the repository, not in the backend. This means:
|
|
- Rules are versioned, inspectable, and explainable.
|
|
- Rule changes are auditable through git history.
|
|
- The rule set can be extended without modifying the backend.
|
|
- Rule output is reproducible for a given binary and rule version.
|
|
|
|
## Interpreting Suspicious API Results
|
|
|
|
The `binary suspicious-apis` command evaluates only priority rules.
|
|
|
|
```bash
|
|
binary suspicious-apis --project <proj> --json
|
|
```
|
|
|
|
### Response Structure
|
|
|
|
```json
|
|
{
|
|
"data": {
|
|
"rules_applied": ["process-injection", "credential-access", "persistence", ...],
|
|
"matches": [
|
|
{
|
|
"api_name": "VirtualAlloc",
|
|
"risk_score": 8,
|
|
"confidence": "HIGH",
|
|
"rule_id": "process-injection"
|
|
}
|
|
]
|
|
}
|
|
}
|
|
```
|
|
|
|
### Understanding Risk Scores
|
|
|
|
Risk scores are rule-defined numeric values indicating how strongly a match
|
|
signals the associated behavior:
|
|
|
|
| Score Range | Interpretation | Action |
|
|
|-------------|---------------|--------|
|
|
| 8-10 | Strong signal of the associated behavior | Flag prominently. Investigate the calling code. |
|
|
| 5-7 | Moderate signal | Note in assessment. Cross-reference with other indicators. |
|
|
| 1-4 | Weak signal | Note but don't center assessment on it. May be a false positive. |
|
|
|
|
**Risk scores are relative to the rule, not absolute.** A score of 8 for
|
|
`process-injection` means "strong evidence of process injection," not
|
|
"this binary is 80% likely to be malicious." Different rules have different
|
|
score distributions.
|
|
|
|
### API Match Interpretation
|
|
|
|
Each match ties a specific API to a rule:
|
|
|
|
- `api_name`: The import name that triggered the match.
|
|
- `risk_score`: How strongly this API contributes to the rule.
|
|
- `confidence`: Rule engine confidence in this match.
|
|
- `rule_id`: Which rule produced this match.
|
|
|
|
**Important:** A match means the API was detected in the import table. It does
|
|
NOT mean the API is called at runtime, nor does it reveal the call parameters.
|
|
Static analysis provides evidence of capability, not confirmation of behavior.
|
|
|
|
### Priority vs Non-Priority Rules
|
|
|
|
Only priority rules are evaluated by `suspicious-apis`. The `rules_applied`
|
|
field lists which rules were evaluated. Non-priority rules may still produce
|
|
heuristics in `binary triage`, but they are not in the `suspicious-apis`
|
|
output.
|
|
|
|
## Interpreting Capability Map Results
|
|
|
|
The `binary capability-map` command suggests functional areas:
|
|
|
|
```bash
|
|
binary capability-map --project <proj> --json
|
|
```
|
|
|
|
### Response Structure
|
|
|
|
```json
|
|
{
|
|
"data": {
|
|
"capabilities": [
|
|
{
|
|
"name": "cryptography",
|
|
"confidence": "HIGH",
|
|
"evidence": [
|
|
{"source": "import", "reference": "CryptEncrypt"},
|
|
{"source": "import", "reference": "CryptDecrypt"},
|
|
{"source": "string", "reference": "AES-256-CBC"}
|
|
]
|
|
}
|
|
]
|
|
}
|
|
}
|
|
```
|
|
|
|
### Capability Categories
|
|
|
|
Common capability categories and what they indicate:
|
|
|
|
| Capability | Typical Evidence | Legitimate Use | Suspicious Context |
|
|
|-----------|------------------|---------------|-------------------|
|
|
| cryptography | CryptEncrypt, CryptDecrypt, AES/RC4 constants | Data protection, TLS, DRM | Ransomware, credential encryption, C2 obfuscation |
|
|
| networking | socket, connect, WinHTTP, URLDownloadToFile | Web requests, API clients | C2 communication, data exfiltration |
|
|
| file-system | CreateFile, ReadFile, WriteFile, FindFirstFile | File I/O, config loading | File enumeration, data harvesting |
|
|
| process-creation | CreateProcess, ShellExecute, system() | Legitimate child processes | Process hollowing, command execution |
|
|
| process-injection | VirtualAllocEx, WriteProcessMemory, CreateRemoteThread | Debuggers, profilers | Malicious code injection |
|
|
| service-management | CreateService, StartService, OpenSCManager | Installers, service apps | Persistence, privilege escalation |
|
|
| registry | RegOpenKey, RegSetValue, RegCreateKey | Configuration storage | Persistence (Run keys), system modification |
|
|
| keylogging | SetWindowsHookEx, GetAsyncKeyState, GetKeyState | Hotkey utilities, accessibility | Credential theft, surveillance |
|
|
| anti-debugging | IsDebuggerPresent, NtQueryInformationProcess, CheckRemoteDebuggerPresent | Copy protection, DRM | Malware evasion |
|
|
| privilege-escalation | AdjustTokenPrivileges, LookupPrivilegeValue | Service initialization | Unauthorized privilege acquisition |
|
|
| code-execution | VirtualProtect (PAGE_EXECUTE_READWRITE), CreateThread | JIT compilers, self-modifying config | Shellcode execution |
|
|
|
|
### Evidence Types
|
|
|
|
Each capability entry includes evidence references:
|
|
|
|
| Evidence Source | Example | What It Means |
|
|
|----------------|---------|---------------|
|
|
| `import` | `"CreateFileW"` | The API is in the import table |
|
|
| `string` | `"/etc/passwd"` | The string literal appears in the binary |
|
|
| `section` | `".text, entropy 7.8"` | A section characteristic triggered the rule |
|
|
| `export` | `"ServiceMain"` | The binary exports a function with this name |
|
|
|
|
**Capabilities are rule-derived indicators, not verified functional proof.**
|
|
A capability entry says "this binary can probably do X," not "this binary does
|
|
X." Always cite capabilities with their confidence level.
|
|
|
|
## Interpreting Diagnostics for Security
|
|
|
|
Diagnostics are critical for security analysis — a diagnostic may reveal that a
|
|
key analysis step failed:
|
|
|
|
```bash
|
|
binary diagnostics --project <proj> --json
|
|
```
|
|
|
|
### Security-Relevant Diagnostic Categories
|
|
|
|
| Category | Meaning | Security Implication |
|
|
|----------|---------|---------------------|
|
|
| `decompiler` | Decompilation failed or timed out | Cannot analyze function-level logic |
|
|
| `symbol-resolution` | Symbols could not be resolved | Unknown import targets (possible obfuscation) |
|
|
| `memory-limit` | Memory limit hit during analysis | Analysis was truncated; results incomplete |
|
|
| `output-truncation` | Output exceeded size limits | Some results were dropped |
|
|
| `timeout` | Operation timed out | Analysis did not complete |
|
|
| `unsupported-format` | A sub-component is an unrecognized format | Possible custom packer or obfuscation |
|
|
| `indirect-call` | Indirect call target unresolved | Code flow unknown at those call sites |
|
|
|
|
**Always review diagnostics before presenting security findings.** If the
|
|
decompiler timed out on 50% of functions, you cannot claim "the binary does
|
|
not contain malicious code in any function."
|
|
|
|
## Common Security Analysis Patterns
|
|
|
|
### Pattern 1: Process Injection
|
|
|
|
**CLI evidence:**
|
|
```bash
|
|
binary suspicious-apis --project <proj> --json
|
|
# Look for matches with rule_id: "process-injection"
|
|
```
|
|
|
|
**Key APIs in the chain:**
|
|
1. VirtualAllocEx / NtAllocateVirtualMemory — allocate memory in target
|
|
2. WriteProcessMemory — write payload to target
|
|
3. CreateRemoteThread / NtCreateThreadEx — execute payload in target
|
|
|
|
**Confidence:**
|
|
- All 3 APIs present → HIGH
|
|
- 2 of 3 present → MEDIUM
|
|
- Only CreateRemoteThread → LOW (used by debuggers and profilers too)
|
|
|
|
**Follow-up:**
|
|
```bash
|
|
binary xrefs --project <proj> function:CreateRemoteThread --json
|
|
# Who calls it? With what parameters can be deduced from surrounding code?
|
|
```
|
|
|
|
### Pattern 2: Persistence Mechanisms
|
|
|
|
**CLI evidence:**
|
|
```bash
|
|
binary suspicious-apis --project <proj> --json
|
|
# Look for: service-management, registry, scheduled-tasks rules
|
|
```
|
|
|
|
**Key indicators:**
|
|
- Services: CreateService, StartService, OpenSCManager
|
|
- Registry Run keys: RegSetValueEx + "Run" string
|
|
- Scheduled tasks: ITaskScheduler COM interface or schtasks.exe strings
|
|
- Startup folder: SHGetSpecialFolderPath + CopyFile pattern
|
|
- DLL hijacking: exports matching known hijackable DLL names
|
|
|
|
**Follow-up:**
|
|
```bash
|
|
binary strings --project <proj> --contains "CurrentVersion\\Run" --json
|
|
binary strings --project <proj> --contains "Services\\" --json
|
|
```
|
|
|
|
### Pattern 3: Data Exfiltration
|
|
|
|
**CLI evidence:**
|
|
```bash
|
|
binary capability-map --project <proj> --json
|
|
# Look for: networking + file-system capabilities together
|
|
```
|
|
|
|
**Key indicators:**
|
|
- Network + file enumeration APIs in the same binary
|
|
- HTTP(S) APIs (WinHTTP, WinINet, URLDownloadToFile)
|
|
- FTP APIs (InternetOpenUrl with FTP)
|
|
- Raw sockets (socket + connect + send)
|
|
- Archive/compression APIs (zip, cab, custom compression)
|
|
- Credential access APIs (CryptUnprotectData, LsaRetrievePrivateData)
|
|
|
|
**Follow-up:**
|
|
```bash
|
|
binary strings --project <proj> --contains "http" --json
|
|
# Look for hardcoded C2 URLs or IP addresses
|
|
```
|
|
|
|
### Pattern 4: Anti-Analysis
|
|
|
|
**CLI evidence:**
|
|
```bash
|
|
binary strings --project <proj> --contains "IsDebuggerPresent" --json
|
|
# Also check for NtQueryInformationProcess, CheckRemoteDebuggerPresent
|
|
```
|
|
|
|
**Key indicators:**
|
|
- Debugger detection: IsDebuggerPresent, NtQueryInformationProcess(ProcessDebugPort), CheckRemoteDebuggerPresent
|
|
- VM detection: CPUID instruction, registry keys for VMware/VirtualBox, MAC address prefixes
|
|
- Timing checks: rdtsc, QueryPerformanceCounter, GetTickCount (timing-based detection)
|
|
- Anti-disassembly: junk bytes, overlapping instructions, opaque predicates
|
|
|
|
**Confidence caveat:** Many anti-debug APIs appear in benign applications
|
|
(copy protection, DRM, some game engines). A single IsDebuggerPresent does not
|
|
indicate malicious intent.
|
|
|
|
**Follow-up:**
|
|
```bash
|
|
binary decompile --project <proj> function:<entry-or-suspicious-func> --json
|
|
# Does the function branch on the debugger check result?
|
|
# Benign: just returns or logs. Suspicious: exits, corrupts data, or changes behavior.
|
|
```
|
|
|
|
## When to Escalate
|
|
|
|
Static analysis has inherent limits. Know when to recommend escalation:
|
|
|
|
| Scenario | Recommendation |
|
|
|----------|---------------|
|
|
| Packed or encrypted binary | "Static analysis cannot proceed on packed code. Unpacking (dynamic or manual) is required." |
|
|
| All key functions are indirect calls | "The binary resolves most functions at runtime. Dynamic analysis or emulation is needed to trace actual behavior." |
|
|
| Multiple HIGH-confidence malicious patterns | "Static analysis reveals strong indicators of malicious intent. Recommend sandbox execution or manual reverse engineering." |
|
|
| Firmware with custom OS | "This firmware uses a proprietary RTOS that Ghidra cannot analyze. Manual reverse engineering with architecture-specific tools may be needed." |
|
|
| Binary crashes or hangs the analyzer | "The binary may contain anti-analysis constructs that affect the analysis tool itself. Proceed with caution." |
|
|
|
|
## Security Command Limits
|
|
|
|
| Limit | Default | Maximum |
|
|
|-------|---------|---------|
|
|
| suspicious-apis result count | 100 | 1000 |
|
|
| capability-map result count | 100 | 1000 |
|
|
| triage per-category limit | 100 | 1000 |
|
|
|
|
If limits are hit, the output is truncated and truncation diagnostics appear.
|
|
Always check for truncation before presenting complete-seeming results.
|