greysec/malware-analysis-pipeline
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: malware-analysis-pipeline

Browse Source
This commit is contained in:
ghstshdw
2026-05-08 17:45:23 -05:00
commit 11b6032fcc
4 changed files with 1052 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
PRODUCT-SPEC.md
+209
View File
@@ -0,0 +1,209 @@
# GreySec MAL — Product Specification
**Product:** GreySec Malware Analysis Lab
**Version:** 1.0
**Status:** BUILDING
**Date:** 2026-05-07
**Owner:** GreySec (COO: Hermes, CEO: Adam)
---
## What the Product Is
GreySec MAL is a self-hosted malware analysis sandbox for red team operators and security teams. You upload a binary payload, detonate it in an isolated Windows 11 VM instrumented with EDR, and receive a structured analysis report — including a Detection Score (0-100) and MITRE ATT&CK kill chain map — in under 5 minutes.
**The core promise:** Know exactly what your C2 payloads look like to EDR before you deploy them. Client data never leaves your infrastructure.
---
## What the Client Gets
### Primary Deliverable: Analysis Report
Each analysis produces:
1. **Detection Score (0-100)**
- 0-20: Clean — deployable in most environments
- 21-40: Low — minor suspicious activity, review before deployment
- 41-60: Medium — multiple suspicious syscalls, test in isolation
- 61-80: High — significant EDR coverage, likely blocked by most EDR
- 81-100: Critical — extensive offensive tooling, not production-ready
2. **MITRE ATT&CK Kill Chain Map**
- Ordered list of ATT&CK tactics and techniques the payload used
- Example: `T1086 (PowerShell) → T1055 (Process Injection) → T1105 (Ingress Tool Transfer)`
- Each technique linked to GreySec advisory on how to modify the payload to evade detection
3. **Behavioral Analysis Summary**
- File operations (created / modified / deleted)
- Network operations (outbound connections, DNS queries, C2 indicators)
- Process operations (child spawn, process injection)
- Registry operations (modified keys)
4. **Raw Event Log** (optional, for manual review)
- Full Fibratus event stream for the analysis session
- Requested separately — not included by default
---
## Target Buyer
### Primary: Red Team Operator at MSSP or Security Firm
**Pain point:** They run adversary simulation engagements for clients. Before deploying C2 payloads, they need to know if the payload will be detected. Cloud malware analysis tools (VirusTotal, ANY.RUN) send IOCs to third parties — bad for client confidentiality and for their own operational security.
**Current workaround:** Manual RE, testing in isolated VMs, or just hoping for the best. Very time-consuming at scale.
**What they'd pay:** $500-2,000/month for a self-hosted tool that speeds up their validation cycle without leaking IOCs.
**Buying trigger:** A client engagement where they got burned — payload detected early, red team exercise cut short.
---
### Secondary: Security Team at Healthcare Organization
**Pain point:** HIPAA BAA obligations. Any cloud-based malware analysis tool that processes client PHI-adjacent files is a potential BAA violation. They cannot send binaries containing PHI-adjacent content to VirusTotal.
**Current workaround:** Manual analysis only, or no analysis because it's too slow. Risk of deploying undetected malware that exfiltrates PHI.
**What they'd pay:** $1,000-3,000/month — healthcare organizations pay premiums for compliance-grade tools.
**Buying trigger:** A HIPAA audit that flags "malware analysis tool usage" as a gap, or a near-miss incident involving suspicious binary.
---
### Tertiary: CISO at Law Firm or Financial Institution
**Pain point:** Client confidentiality is non-negotiable. They cannot risk binaries containing M&A data, litigation strategy, or financial records being processed by a third-party cloud service.
**Current workaround:** Complete ban on external malware analysis tools, or only using isolated air-gapped analysis VMs.
**What they'd pay:** $2,000-5,000/month for a tool that guarantees data never leaves their infra.
**Buying trigger:** A data incident at a competitor or peer firm that involved malware analysis tools leaking confidential data.
---
## SLA (Target)
| Metric | Target | Notes |
|--------|--------|-------|
| Analysis turnaround | < 5 minutes for payloads < 10MB | TBD — needs benchmarking |
| Report availability | Via API or dashboard within 1 minute of analysis complete | — |
| System uptime | 99% | TBD — needs redundancy planning with Adam |
| Max payload size | 50MB | Hard limit — VM memory constraints |
| Concurrent analyses | 3 simultaneous | TBD — needs capacity testing |
**What we do not commit to:** Detecting polymorphic packers, hardware implants, or nation-state tooling with novel evasions (0-day complexity). We detect known offensive techniques, not novel bypasses.
---
## Limitations
- **Polymorphic/packed malware:** If a binary unpacks at runtime into new code patterns, static analysis and Fibratus kernel events may not see the unpacked payload. Our analysis covers the execution path we observe — not dynamic unpackers that change behavior mid-run.
- **Hardware implants/BIOS rootkits:** These operate below the OS layer. Fibratus (kernel-level) does not capture firmware-level activity.
- **Nation-state 0-day:** Detection Score will be low for novel techniques with no known syscall patterns. A 0-day syscall that no EDR rule covers will score as clean. We detect known offensive techniques, not novel bypasses.
- **ARM/IoT binaries:** Our analysis VM is Windows x86_64. ARM Windows binaries will not run in this environment. Linux ARM analysis is a future roadmap item.
- **macOS binaries:** Not supported in V1. Future roadmap.
---
## Competitive Landscape
| Tool | Model | Cost | Strengths | Weaknesses for Our Buyer |
|------|-------|------|-----------|--------------------------|
| **VirusTotal** | Cloud | $0-650/mo | Huge IOC database, easy | IOCs sent to third party, bad for red team ops, no behavioral analysis |
| **ANY.RUN** | Cloud | $99+/mo | Interactive malware analysis | IOCs shared with community, expensive for high volume, no self-hosted option |
| **Joe Sandbox** | Cloud + on-prem | Enterprise | Full analysis, MITRE mapping | Very expensive, complex setup for on-prem, slow turnaround |
| **Hybrid Analysis** | Cloud | Free + paid | Good IOC DB, fast | IOCs submitted to public DB, no self-hosted, freemium limits |
| **Elastic + Lima Charlie** | Self-hosted | Open source + $ | Full SIEM + EDR control | Requires significant engineering to build our specific output, not turnkey |
| **GreySec MAL** | **Self-hosted** | **TBD** | **Client data never leaves infra, local AI augmentations, MITRE ATT&CK output, Detection Score** | **V1 is new (May 2026), limited IOC DB, not a massive public dataset** |
**GreySec MAL's positioning:**
- Self-hosted — client data never leaves their infra (the legal and operational differentiator)
- Local AI-augmented — not just static analysis, AI-assisted behavioral interpretation
- Turnkey — not a SIEM/EDR tool that requires a team to operate
- MITRE ATT&CK native — not just IOCs, structured kill chain output
---
## Pricing Framework (Internal Only)
**Do not share externally. Adam reviews and approves all client-facing numbers.**
### Build vs. Buy Analysis
**Building this yourself (internal team):**
- Engineering time: 80-120 hours to replicate GreySec MAL feature set
- Ongoing maintenance: 10-15 hours/month (VM updates, EDR rule updates, model retraining)
- Infrastructure: $200-400/month (VM hosting, compute, storage)
- Total first-year cost: $15,000-25,000 + engineering risk
**Using GreySec MAL:**
- Setup: TBD (Adam to price)
- Monthly: TBD (Adam to price based on usage tiers)
- Value: Zero engineering risk, faster time-to-value, GreySec maintains the stack
### Internal Cost Basis
| Cost Item | Monthly |
|-----------|---------|
| VM hosting (Windows 11) | ~$50 |
| Docker/RabbitMQ compute | ~$20 |
| Supabase (storage + API) | ~$25 |
| AI compute (local Ollama, amortized) | ~$50 |
| **Total direct cost** | **~$145/month** |
Plus human review time per analysis: ~5-10 minutes of analyst time at $105-135/hr.
### Margin Targets
Internal target: minimum 4x direct cost at scale.
At 20 analyses/month: ($145 + $35 human time) × 4 = $720/month breakeven on direct costs.
---
## Roadmap (Future Tiers)
### V1 (Current Build — MVP)
- Single binary upload
- Windows x86_64 analysis only
- Detection Score + MITRE ATT&CK output
- Web dashboard
- Client upload portal (API key auth)
### V2 (Next Quarter)
- DLL analysis support
- Multi-file upload (.zip with dependencies)
- Batch analysis (up to 10 binaries per job)
- Comparative output (compare two payloads side-by-side)
- API for CI/CD integration (automated testing in build pipeline)
### V3 (Future)
- Linux binary analysis (Ubuntu VM + strace + osquery)
- macOS binary analysis (if demand warrants)
- ARM IoT analysis (if demand warrants)
- Malware family classification (this is Ransomware, this is a Dropper, etc.)
- YARA rule generation from analysis results
- Multi-tenant isolation (each client gets their own VM)
---
## What GreySec Gets Out of This
Building MAL accomplishes three things for GreySec:
1. **Internal tooling:** We use this ourselves for red team engagements — testing C2 payloads before deployment, validating client malware samples in IR engagements.
2. **Product revenue:** First productized internal capability that can be sold as a subscription. Opens a new revenue line beyond consulting.
3. **Proof of AI capability:** MAL demonstrates that GreySec's agent infrastructure can build operational security tooling — a differentiator in proposal conversations vs. firms that just sell human hours.
---
**Status:** BUILDING — do not share externally until 4 critical bugs are fixed and Detection Score is validated against real payloads.
**Next decision needed from Adam:** Pricing tiers and setup fee. See pricing framework above — internal only.
SALES-SPEC.md
+160
View File
@@ -0,0 +1,160 @@
# GreySec MAL — Sales Specification
**Product:** GreySec Malware Analysis Lab
**Status:** Internal — for Adam review
**Date:** 2026-05-07
**Classification:** Internal only — no client-facing numbers
---
## Market Analysis
### The Problem Nobody Talks About
Red team operators, security researchers, and adversarial testing teams have a problem they don't talk about publicly: they need to test their C2 payloads and malware samples before deploying them, but every cloud-based malware analysis tool sends those samples to a third party.
VirusTotal has 80+ anti-virus engines and a massive IOC database. If you upload a C2 payload there, every major AV vendor now has that payload's signature — including the ones your clients are running. You've just burned your own operation.
ANY.RUN, Joe Sandbox, Hybrid Analysis — same problem. Samples go into a community database, get analyzed by third-party engines, and the IOCs propagate.
For offensive security teams, this is an operational security nightmare.
### Who Actually Pays for Self-Hosted Malware Analysis
Not enterprises — they don't run offensive operations. The real buyers:
1. **MSSPs running adversary simulation engagements**
- They test C2 payloads against client environments
- They cannot send client malware to VirusTotal — that's a client data breach
- They can't afford to burn their own IOCs before deployment
- Willing to pay: $500-2,000/month for a reliable self-hosted solution
2. **Security teams at healthcare organizations**
- HIPAA BAA obligations mean cloud malware tools are off-limits for anything touching PHI
- They need to validate that their endpoint controls detect known malware strains
- They want to test suspected malicious files from email attachments before sandboxing
- Willing to pay: $1,000-3,000/month (healthcare premium)
3. **Law firms and financial institutions**
- Client confidentiality is attorney-client privilege or regulatory mandated
- Malware samples from M&A due diligence, litigation support, or financial investigations
- Cannot send those to third parties under any circumstance
- Willing to pay: $2,000-5,000/month
4. **Red team operators at government/defense contractors**
- Sensitive operations where cloud submissions are a clearance violation
- Air-gapped analysis VMs are the norm — they want something that works like VirusTotal but stays local
- Willing to pay: $1,000-4,000/month
### The Pain Is Real and Growing
The offensive security industry is booming. Red team ops, adversary simulation, purple team testing — all of these require payload analysis before deployment. The more mature teams have figured out the cloud problem. The less mature ones are still burning IOCs and wondering why their C2 keeps getting flagged on day one.
GreySec MAL is positioned for the market that's figured out the problem and wants a turnkey solution, not another custom build.
---
## Competitive Landscape
| Tool | Model | Cost/Month | Self-Hosted | Key Limitation |
|------|-------|------------|------------|---------------|
| VirusTotal | Cloud | $0-650 | No | IOCs shared with AV vendors |
| ANY.RUN | Cloud | $99-399 | No | IOCs shared with community |
| Joe Sandbox | Cloud + on-prem | Enterprise | Yes | $50K+ setup, slow |
| Hybrid Analysis | Cloud | Free + $50+ | No | Public IOC database |
| Triage | Cloud | $250+ | Yes (enterprise) | Complex setup |
| GreySec MAL | **Self-hosted** | **TBD** | **Yes — fully** | **V1 (new, May 2026)** |
**GreySec MAL's key differentiation:**
- Client data never leaves your infrastructure (legal differentiator)
- MITRE ATT&CK kill chain mapping (structured, not just IOC dumps)
- Detection Score (0-100) — actionable output, not raw event logs
- Local AI augmentation — doesn't rely on cloud AV signatures alone
---
## Buyer Personas
### Persona 1: Marcus, Red Team Lead at Nexus MSSP
**Who:** Marcus runs adversary simulation for 12 enterprise clients. His team deploys C2 infrastructure, tests phishing campaigns, and validates security controls. Every week they build 3-5 custom payloads.
**Pain:** Before deploying any payload, Marcus's team manually spins up an isolated VM and watches what the payload does. It takes 20-30 minutes per payload. They process 15-20 payloads per week. That's 5-10 hours of manual analysis time — every week.
**What he really wants:** Drop the payload, get a report in 5 minutes, move on.
**What he'll pay:** $1,200/month for a tool that eliminates 8 hours of manual analysis per week.
**Buying trigger:** A client engagement where their C2 was flagged on day one — they burned the operation because they didn't test it.
---
### Persona 2: Dr. Sarah Chen, CISO at Pacific Regional Medical Center
**Who:** Sarah oversees security for a 2,000-bed healthcare system with 8 affiliated clinics. HIPAA compliance is her top priority. She has a BAA with a cloud SIEM provider but has told her team: no cloud malware analysis, ever.
**Pain:** Her IR team handles suspicious email attachments from clinical staff. They need to know if a file is malicious before they sandbox it. They've been doing manual RE or just hoping. They've had two near-misses where they deployed a file that turned out to be credential-stealing malware.
**What she really wants:** A locked-down environment where her IR team can drop a file and get a detection verdict in 5 minutes. No cloud. No BAA risk.
**What she'll pay:** $2,500/month for healthcare org pricing.
**Buying trigger:** A HIPAA audit that flags "malware analysis procedures" as inadequate. Or a near-miss where they almost deployed undetected malware.
---
### Persona 3: James Rodriguez, Senior Associate at Morrison & Vale Law
**Who:** James handles cybersecurity for a 200-attorney law firm. They process M&A documents, litigation evidence, and financial records for high-stakes cases. Any malware analysis must be done on-site with zero data leaving the firm.
**Pain:** A suspicious file arrives via secure file transfer from a client. James needs to know if it's malware before his team opens it. He has an isolated VM but no structured way to analyze the file beyond "it looks suspicious."
**What he really wants:** A simple report: is this malware, and what does it do?
**What he'll pay:** $800/month — law firms are price-conscious but security is non-negotiable.
**Buying trigger:** After the Okta breach at a peer firm that involved malware delivered via secure file transfer. He realized his firm had no formal malware analysis process.
---
## Pricing Framework (Internal)
### Direct Cost Basis
| Cost Item | Monthly (at 20 analyses) |
|-----------|--------------------------|
| Windows VM (hosting) | $50 |
| Docker/RabbitMQ compute | $20 |
| Supabase storage + API | $25 |
| AI compute (local Ollama) | $50 |
| Human review (5 min × 20) | $175 (at $105/hr) |
| **Total** | **$320/month** |
At 4x margin: ~$1,280/month. At 5x margin: ~$1,600/month.
### Price Tiers (Internal Planning Only — No Client Numbers)
| Tier | Analyses/Month | Price Target | Buyer |
|------|---------------|-------------|-------|
| Essentials | 20 | ~$1,000-1,200/mo | Small MSSP, solo researcher |
| Professional | 50 | ~$2,000-2,500/mo | MSSP, healthcare org |
| Enterprise | Unlimited | ~$4,000-5,000/mo | Large enterprise, law/finance |
Setup fee: 1 month fee (standard SaaS onboarding).
**Adam to finalize all client-facing numbers before external distribution.**
---
## Objection Handling
**"Why not just use VirusTotal? It's free."**
VirusTotal is free for IOCs. The cost is your C2 payload signatures being distributed to every AV vendor globally. For offensive security, VirusTotal burns your operation. We give you the same behavioral analysis without sharing your IOCs with anyone.
**"How is this different from just running a VM with Wireshark?"**
Manual analysis takes 20-30 minutes per payload and requires an expert watching the VM. GreySec MAL automates the analysis, produces a structured MITRE ATT&CK kill chain, and gives you a Detection Score you can track over time.
**"Isn't this just for hackers?"**
It's the same technology your blue team uses to build detection rules. We use it for testing our own offensive tools. Healthcare organizations use it to validate that their EDR detects known attack patterns. Law firms use it to screen files before opening them in a client engagement.
**"What if the AI gets it wrong?"**
The Detection Score is based on observed behavior (syscalls, network activity, process behavior), not AI inference. If Fibratus sees a payload call VirtualAllocEx + WriteProcessMemory + CreateRemoteThread, that scores high regardless of what the AI model thinks. The AI augments the analysis; the data is from the actual execution.
TECHNICAL-RUNBOOK.md
+362
View File
@@ -0,0 +1,362 @@
# GreySec MAL — Technical Runbook
**Product:** GreySec Malware Analysis Lab
**Version:** 1.0
**Updated:** 2026-05-07
**Parent:** `~/greysec/tools/malware-analysis-pipeline/kanban.md`
---
## Architecture
```
Docker Host (Linux)
172.28.0.1
│
┌───────────────────[Docker Bridge: 172.28.0.0/24]────────────────────┐
│ │
LitterBox API Windows 11 VM
:1337 172.28.0.10
(upload portal) │
(orchestration) Fibratus (kernel)
(result storage) │
Whiskers (:8080)
RabbitMQ │
:5672 │
│ RedEdr reporting
variant_event_consumer │
│ │
Supabase │
(results DB) │
│ [SHARE MOUNT]
Web Dashboard C:\analysis\
```
**Key address:** LitterBox API = `http://172.28.0.1:1337`
**Key address:** Whiskers (inside VM) = `http://172.28.0.10:8080`
---
## Component Inventory
| Component | Location | Port | Purpose | Credentials |
|-----------|----------|------|---------|-------------|
| LitterBox API | `~/greysec/tools/LitterBox/` | 1337 | Upload portal + orchestration | None (local) |
| RabbitMQ | Docker container | 5672 | Event queue | guest/guest (local) |
| variant_event_consumer | `~/bin/greysec/variant_event_consumer.py` | — | Parse events → Supabase | Via env |
| fibratus_rabbitmq_bridge | `~/bin/greysec/fibratus_rabbitmq_bridge.py` | — | Bridge Fibratus to RabbitMQ | Via env |
| Whiskers | Inside Windows VM | 8080 | EDR REST API | None |
| Fibratus | Inside Windows VM | — | Kernel event capture | — |
| RedEdr | Inside Windows VM | — | EDR reporting (RedEdr.exe) | — |
| Supabase | Cloud (or local) | 3000 | Results database | greysec-dev-key-2026 |
| pre-flight-vm-check.sh | `~/bin/greysec/pre-flight-vm-check.sh` | — | VM health check script | — |
---
## Prerequisites
Before running the pipeline:
1. Docker daemon running on Linux host
2. Windows 11 VM running at 172.28.0.10
3. Kali container reachable from host
4. Supabase accessible at localhost:3000 (or cloud)
5. MacBook Ollama reachable at 100.127.137.64 (for AI augmentations)
---
## Pre-Flight Checklist
Run before every session:
```bash
# 1. Check Docker containers
docker ps --format "table {{.Names}}\t{{.Status}}" | grep -E "litterbox|rabbitmq|fibratus"
# 2. Check VM is running
ping -c 2 172.28.0.10
# 3. Check Whiskers is up
curl -s http://172.28.0.10:8080/health
# Expected: {"status":"ok"} or similar
# 4. Check RabbitMQ is up
curl -s -u guest:guest http://localhost:15672/api/overview | jq '.queue_messages'
# Expected: {"count": N, "message": "ok"}
# 5. Check Supabase reachable
curl -s http://localhost:3000/health | jq '.status'
# Expected: "ready"
# 6. Check share mount from VM side (AFTER FIX — currently broken)
# From inside VM:
# curl -F "file=@test.exe" http://172.28.0.1:1337/upload
```
If any check fails, resolve before uploading payloads.
---
## Startup Sequence
Run in order. Wait for each to be healthy before moving to the next.
```bash
# 1. Start Docker stack
cd ~/greysec/tools/LitterBox
docker-compose up -d
# Wait 30 seconds
# 2. Verify containers are up
docker ps | grep -E "litterbox|rabbitmq"
# 3. Start variant_event_consumer
cd ~/greysec/tools/LitterBox
python3 ~/bin/greysec/variant_event_consumer.py &
# Or use supervisor/systemd if running as service
# 4. Verify VM is running
ping -c 1 172.28.0.10
# 5. Start Whiskers (manual PAExec — until Task 3 is done)
# From inside VM or via PAExec:
# PAExec \\172.28.0.10 -u administrator -p [password] "C:\path\to\whiskers.exe"
# Until Task 3 is done, this is manual and needs to be redone after VM reboot
# 6. Verify Whiskers is responding
curl -s http://172.28.0.10:8080/health
# 7. Verify Fibratus is running inside VM
# On VM: sc query fibratus
# Should show RUNNING
# 8. Verify RabbitMQ connection from consumer
curl -s -u guest:guest http://localhost:15672/api/overview | jq '.message_stats'
```
---
## Shutdown Sequence
```bash
# 1. Stop uploading new payloads (drain queue)
# Check RabbitMQ for pending messages
curl -s -u guest:guest http://localhost:15672/api/queues | jq '.[] | select(.messages > 0)'
# 2. Stop variant_event_consumer
pkill -f variant_event_consumer
# 3. Stop Whiskers (if Task 3 not done — manual)
# On VM: taskkill /IM whiskers.exe /F
# 4. Stop Docker containers
cd ~/greysec/tools/LitterBox
docker-compose down
# 5. Shutdown VM
# virsh shutdown greysec-win11
# or from inside VM: shutdown /s /t 0
```
---
## Payload Upload Procedure
### Via CLI (current method)
```bash
# Upload a payload
curl -X POST http://172.28.0.1:1337/upload \
-F "file=@ransomware_sim_v1.py" \
-F "timeout=30" \
-F "metadata={\"name\":\"ransomware_sim_v1\",\"category\":\"test\",\"submitted_by\":\"operator\"}"
# Check job status
curl http://172.28.0.1:1337/jobs/[JOB_ID]
# Get results
curl http://172.28.0.1:1337/results/[JOB_ID]
```
### Via Client Portal (future — Task 7)
```bash
# Authenticated upload (future)
curl -X POST https://[client-portal-host]/upload \
-H "Authorization: Bearer [API_KEY]" \
-F "file=@payload.exe" \
-F "timeout=60"
# Returns job_id for polling
```
---
## Reading the Results
### Detection Score (0-100)
The primary deliverable metric.
| Score | Interpretation | Action |
|-------|---------------|--------|
| 0-20 | Clean — no suspicious syscalls | Deployable in most environments |
| 21-40 | Low — minor suspicious activity | Review behavioral summary before deployment |
| 41-60 | Medium — multiple suspicious syscalls | Modify payload or test in isolated environment |
| 61-80 | High — significant EDR coverage | Likely to be blocked by most EDR products |
| 81-100 | Critical — extensive offensive tooling | Not recommended for production use |
### MITRE ATT&CK Kill Chain
The sequence of ATT&CK tactics and techniques the payload used.
**Format:**
```
[1] T1086 — PowerShell: one-liner downloader
[2] T1055 — Process Injection: VirtualAllocEx + WriteProcessMemory
[3] T1055 — Process Injection: CreateRemoteThread
[4] T1105 — Ingress Tool Transfer: URLDownloadToFile
```
**What to look for:**
- Technique count > 3: sophisticated payload
- T1055 (Process Injection): likely evasion attempt
- T1105 (Ingress Tool Transfer): network Indicators
- T1486 (Data Encrypted for Impact): ransomware behavior
### Behavioral Summary
Text summary of what the payload did:
- File operations (created/modified/deleted)
- Network operations (outbound connections, DNS queries)
- Process operations (spawned children, injected into processes)
- Registry operations (modified keys)
---
## Troubleshooting Guide
### Problem: Payload never starts processing
**Symptoms:** Upload returns 200 OK but no job in queue.
**Diagnosis:**
1. Check share mount is reachable from VM (see Issue 1)
2. Check `curl -v http://172.28.0.1:1337/jobs` — does job appear?
3. Check LitterBox logs: `docker logs litterbox-api`
**Fix order:** Verify share mount → verify upload endpoint → check LitterBox logs
---
### Problem: Payload killed at exactly 5 seconds
**Symptoms:** All payloads die at 5 seconds, regardless of timeout setting.
**Diagnosis:** This is Issue 4. Check `manager.py` lines 418-419.
```bash
grep -n "init_wait_time" ~/greysec/tools/LitterBox/app/analyzers/manager.py
# Should show hardcoded value = 5
```
**Fix:** Change to respect config.yaml value.
---
### Problem: Whiskers endpoint returns 502 or timeout
**Symptoms:** `curl http://172.28.0.10:8080/api/alerts/fibratus/since` fails.
**Diagnosis:** Whiskers process died (Issue 3 — no keepalive).
**Fix (immediate):** PAExec back into VM and restart Whiskers.
**Fix (permanent):** Task 3 — install as Windows service.
---
### Problem: RedEdr report is empty despite real syscalls
**Symptoms:** Whiskers returns events but RedEdr shows nothing.
**Diagnosis:** This is Issue 2. Fibratus sees events but they don't reach the final report.
**Fix:** Trace the event path:
1. Inside VM: run `fibratus dump` — are events being captured by Fibratus?
2. `curl http://172.28.0.10:8080/api/alerts/fibratus/since` — does Whiskers see them?
3. Check `variant_event_consumer` logs — is it receiving from RabbitMQ?
4. Check Supabase `malware_analyses` table — are events stored?
Find the break point and fix at that layer.
---
### Problem: RabbitMQ queue not draining
**Symptoms:** `curl -u guest:guest http://localhost:15672/api/queues` shows messages accumulating.
**Diagnosis:** `variant_event_consumer` is not running or is crashing on messages.
**Fix:**
```bash
# Restart consumer with verbose logging
python3 -v ~/bin/greysec/variant_event_consumer.py
# Check consumer is running
ps aux | grep variant_event_consumer
```
---
### Problem: VM unreachable at 172.28.0.10
**Symptoms:** `ping 172.28.0.10` fails.
**Diagnosis:** VM is down or Docker bridge network changed.
**Fix:**
```bash
# Check VM status
virsh list --all
# Restart VM
virsh start greysec-win11
# Verify Docker bridge
docker network inspect bridge | jq '.[0].IPAM.Config[0].Subnet'
```
---
## Escalation Path
**If you encounter any of these, ping @Adam immediately:**
1. VM will not start or boots to BSOD
2. Docker stack fails to start after host reboot
3. Supabase is unreachable and not recoverable within 5 minutes
4. MacBook Ollama needs to be re-authenticated (token expired)
5. Any of the 4 critical bugs cannot be resolved within 2 hours of focused work
**Before escalating:**
- Document what you tried
- Note exact error messages
- Note which component is failing (ping the exact hop)
**Format for escalation:**
```
[@Adam] [COMPONENT] is broken: [ONE-LINE DESCRIPTION]
What I tried: [SHORT LIST]
Error: [EXACT ERROR]
Last working: [WHEN — if known]
```
---
## Appendix: Test Payloads
| Name | Path | Purpose | Expected Behavior |
|------|------|---------|-------------------|
| ransomware_sim_v1.py | `~/greysec/engagements/litterbox-fibratus-deploy/payloads/` | Detection Score test | 60-80 score, multiple ATT&CK techniques |
| ransomware_sim_v2.c | `~/greysec/engagements/litterbox-fibratus-deploy/payloads/` | Extended run test | Run > 5 seconds, capture output |
| ransomware_sim_v3.c | `~/greysec/engagements/litterbox-fibratus-deploy/payloads/` | Extended run test | Same as v2 |
| calc.exe | Windows system binary | Clean baseline test | Score < 20 |
| notepad.exe | Windows system binary | Clean baseline test | Score < 20 |
kanban.md
+321
View File
@@ -0,0 +1,321 @@
# GreySec MAL — Master Kanban
**Product:** GreySec Malware Analysis Lab
**Type:** Internal Build Project
**Status:** BUILDING
**Updated:** 2026-05-07
**Parent debrief:** `~/greysec/ops/debriefs/malware-lab-2026-05-07.md`
---
## Background
GreySec MAL is a self-hosted malware analysis sandbox for red team operators. It takes a binary payload, detonates it in an isolated Windows 11 VM instrumented with EDR (Fibratus + Whiskers + RedEdr), captures behavioral events via RabbitMQ, and produces a client-facing analysis report with a Detection Score (0-100) and MITRE ATT&CK kill chain map.
**Architecture:**
```
Payload Upload → LitterBox (:1337) → SMB Share Mount → Windows VM (:1337)
↓
Fibratus (kernel events)
Whiskers (REST API :8080)
RedEdr (EDR reporting)
↓
RabbitMQ (event queue)
↓
variant_event_consumer (Python)
↓
Supabase (structured data)
↓
Detection Score + MITRE ATT&CK Report
```
**Current status:** ARCHITECTURE VERIFIED. 4 critical bugs block end-to-end operation. Fix order is strict.
---
## Pipeline Definition
**What the product IS:**
Drop a binary. Get a Detection Score + MITRE ATT&CK kill chain. Client data never leaves your infrastructure.
**What the client receives:**
- Detection Score (0-100) — how likely this payload is to be flagged by EDR
- MITRE ATT&CK kill chain map — which tactics and techniques the payload uses
- Behavioral analysis summary — what the payload actually did (file ops, network ops, process ops)
- Raw event log (optional) — full Fibratus event stream for manual review
**Target buyer:**
- Red team operators testing C2 payloads before deployment
- MSSPs running adversary simulation for clients
- Security teams with HIPAA/BAA obligations that prevent cloud malware analysis
- Law firms and financial institutions with strict client confidentiality requirements
**SLA (target):**
- Analysis turnaround: < 5 minutes for typical payloads (< 10MB)
- Report available: via web dashboard or API
- Uptime: 99% (target, TBD with Adam)
---
## Current State
### What Works
- v1 Python payload: ran for 16 seconds, generated real EDR events, Fibratus saw them, Whiskers returned them via `/api/alerts/fibratus/since` — core event path verified
- RabbitMQ → variant_event_consumer → Supabase: working
- Docker-compose stack: LitterBox, RabbitMQ, Fibratus bridge, consumer all start cleanly
- Pre-flight check script exists at `~/bin/greysec/pre-flight-vm-check.sh` (not yet run in a session)
### What Is Broken
| # | Bug | Severity | Fix Time | Cascade |
|---|-----|----------|----------|---------|
| 1 | VM share mount `\\172.28.0.1\share` unreachable from Windows VM — payloads may not reach analysis dir | CRITICAL | 30 min | Blocks all testing |
| 2 | RedEdr returns zero events despite Fibratus seeing real syscalls — event data doesn't reach final report | CRITICAL | 30-60 min | Blocks EDR validation |
| 3 | Whiskers has no Windows service wrapper — dies when parent process exits, requires manual PAExec restart | CRITICAL | 1 hour | Blocks reliability |
| 4 | manager.py lines 418-419 hardcodes `init_wait_time = 5` regardless of config — payloads killed at 5s | DEGRADED | 30 min | Blocks extended runs |
**Fix order:** 1 → 2 → 3 → 4. Issue 4 is blocked by Issue 1 (can't test 4 until share mount works).
---
## BOARD
### BACKLOG
- [ ] Build Detection Score algorithm (0-100 from Fibratus event frequency + severity + MITRE technique count)
- [ ] Build web dashboard for results (currently Supabase only — no client-facing UI)
- [ ] Build client upload portal (currently manual `curl` to localhost:1337)
- [ ] Build MITRE ATT&CK kill chain mapper (Fibratus events → ATT&CK tactic/technique IDs)
- [ ] Write `greysec-malware-pipeline` skill (standalone — not yet created)
- [ ] Add payload hardening guidance output (what to change in the binary to lower Detection Score)
- [ ] Set up TLS for LitterBox API (currently plain HTTP — fine for internal, not for client-facing portal)
- [ ] Build multi-user access control (when portal is client-facing, need auth)
- [ ] Benchmark performance: typical payload analysis time, max payload size, concurrent analysis capacity
### IN PROGRESS
_(empty — no work currently active)_
### VALIDATING
_(empty)_
### DONE
- [x] Architecture design (RabbitMQ + Fibratus + Whiskers + Supabase)
- [x] Docker-compose stack (LitterBox + RabbitMQ + bridges)
- [x] v1 Python payload proves end-to-end event path
- [x] Pre-flight VM check script written (`~/bin/greysec/pre-flight-vm-check.sh`)
- [x] Supabase schema for analysis results
### BLOCKED
- [ ] **ISSUE 1: VM share mount** — Cannot test payloads until SMB share is reachable from inside VM
- [ ] **ISSUE 2: RedEdr zero events** — Cannot validate EDR reporting until share mount works
---
## Technical Fix Tasks
### Task 1: Fix VM Share Mount (CRITICAL — do first)
**What:** `\\172.28.0.1\share` (SMB) not reachable from inside Windows VM at 172.28.0.10
**Root cause:** Docker bridge network (172.28.0.0/24) may not be attached to VM network interface. SMB port 445 may be blocked by Windows Firewall.
**Fix approach A:** Verify Docker bridge attachment and open Windows Firewall for SMB.
**Fix approach B (preferred):** Replace SMB mount with HTTP upload endpoint inside VM — more reliable across Docker bridge, no firewall holes.
**Files to touch:**
- `~/greysec/tools/LitterBox/docker-compose.yml` (change mount mechanism)
- May need new endpoint in `~/greysec/tools/LitterBox/app/analyzers/payload_receiver.py`
**Who:** qwen2.5-coder:14b
**Time:** ~30 minutes
**Verification:** From inside VM: `curl -F "file=@test.exe" http://172.28.0.1:PORT/upload` returns 200
**Acceptance criteria:**
- VM can reach LitterBox upload endpoint
- Payload file appears in VM analysis directory
- LitterBox begins processing within 10 seconds of upload
---
### Task 2: Fix RedEdr Zero Events (CRITICAL — do second)
**What:** Fibratus sees real syscalls. Whiskers `/api/alerts/fibratus/since` returns events. But RedEdr report shows nothing.
**Root cause:** Trace path: Fibratus writes to Windows Application Event Log → Whiskers reads via `wevtutil` → publishes over HTTP → consumer receives. Something breaks between Whiskers and final report.
**Fix approach:**
1. Check Fibratus filter rules — are they capturing the right event types?
2. Check Whiskers polling interval — is it fast enough?
3. Check `variant_event_consumer.py` — is it parsing Whiskers output correctly?
4. Run a known-syscall payload and trace events at each hop
**Files to touch:**
- `~/bin/greysec/fibratus_rabbitmq_bridge.py`
- `~/bin/greysec/variant_event_consumer.py`
- Fibratus config `~/greysec/tools/fibratus/config.yaml`
**Who:** qwen2.5-coder:14b
**Time:** ~30-60 minutes (diagnosis + fix)
**Verification:** Run ransomware_sim_v1.py payload → confirm events in RedEdr report, not just Whiskers endpoint
**Acceptance criteria:**
- Payload makes real OpenProcess/CreateFile syscalls
- Fibratus events appear in Whiskers `/api/alerts/fibratus/since` output
- Events are parsed and stored in Supabase
- RedEdr-format report shows the events with correct timestamps
---
### Task 3: Install Whiskers as Windows Service (CRITICAL — do third)
**What:** Whiskers dies when PAExec parent exits. No persistence across VM restart or process crash.
**Fix:** Install Whiskers as a Windows service using `nssm` (Non-Sucking Service Manager) or `instsrv`.
**Files to touch:**
- VM-side setup: install nssm, run `nssm install Whiskers "C:\path\to\whiskers.exe" "--port 8080"`
**Who:** qwen2.5-coder:14b
**Time:** ~1 hour
**Verification:** Reboot VM → wait 5 minutes → confirm Whiskers still reachable at `http://172.28.0.10:8080/api/alerts/fibratus/since`
**Acceptance criteria:**
- Whiskers survives VM reboot without manual intervention
- Whiskers survives its own parent process exiting
- Health check `curl http://172.28.0.10:8080/health` returns 200
---
### Task 4: Fix manager.py Timeout Handler (DEGRADED — do fourth)
**What:** `~/greysec/tools/LitterBox/app/analyzers/manager.py` lines 418-419 hardcode `init_wait_time = 5` in the `"terminated after"` error handler, overriding `config.yaml`.
**Fix:** Change `init_wait_time = 5` to `init_wait_time = config.get('wait_time', 15)` or similar.
**Files to touch:**
- `~/greysec/tools/LitterBox/app/analyzers/manager.py` (lines ~418-419)
**Who:** qwen2.5-coder:14b
**Time:** ~30 minutes
**Verification:** Set `wait_time: 30` in config.yaml → run a 20-second payload → confirm it runs for 20+ seconds, not 5
**Acceptance criteria:**
- Config value respected, not hardcoded fallback
- C payloads (v2, v3) that need > 5 seconds run to completion
---
## Product Build Tasks
### Task 5: Detection Score Algorithm
**What:** The primary client deliverable. A score from 0-100 that rates how likely this payload is to be detected by EDR.
**Approach:** Combine:
- Event count: how many syscalls per minute
- Event severity: which syscalls (OpenProcess = medium, VirtualAlloc + WriteProcess = high)
- MITRE technique count: how many distinct ATT&CK techniques used
- Network indicators: outbound connections = higher score
- Process injection indicators: highest score
**Output:** JSON field in Supabase + dashboard display
**Formula (target):** `score = min(100, (event_count * 0.1) + (technique_count * 15) + (severity_multiplier * 20) + (network_indicator * 25))`
**Who:** qwen2.5-coder:14b or glm-5.1:cloud for algorithm design
**Time:** ~2 hours
**Verification:** Run 3 known-clean files (calc.exe, notepad.exe) → score < 20. Run ransomware_sim payload → score > 60.
---
### Task 6: Web Dashboard
**What:** Client-facing results dashboard. Currently Supabase only — no UI.
**Stack:** TBD (recommend: Simple Python Flask or FastAPI + HTMX for simplicity, or integrate into existing GreySec dashboard)
**Pages:**
- Upload page: drag-and-drop binary, job ID returned
- Results page: Detection Score, MITRE kill chain visualization, behavioral summary
- History: past analyses for the client's org
**Who:** qwen2.5-coder:14b (or Adam if design decision needed)
**Time:** ~4 hours
**Dependencies:** Task 1, 2, 5 complete first
---
### Task 7: Client Upload Portal
**What:** Authenticated API endpoint for clients to submit binaries. Currently manual `curl` to localhost.
**Features:**
- API key auth per client org
- File type validation (.exe, .dll, .bin, .ps1, .py)
- Max file size: 50MB
- Sandbox: each org gets isolated analysis environment (future scope — V1 is shared infra)
**Files to touch:**
- `~/greysec/tools/LitterBox/app/analyzers/payload_receiver.py` (new endpoints)
- `~/greysec/tools/LitterBox/Config/config.yaml` (API key config)
**Who:** qwen2.5-coder:14b
**Time:** ~2 hours
**Dependencies:** Task 1 (share mount fix) must be complete
---
### Task 8: MITRE ATT&CK Kill Chain Mapper
**What:** Map Fibratus syscall events to MITRE ATT&CK tactic and technique IDs automatically.
**Approach:** Build a mapping table:
- `NtOpenProcess` → T1086 (PowerShell), T1055 (Process Injection)
- `NtCreateFile` on sensitive paths → T1005 (Data from System Files)
- `VirtualAllocEx` + `WriteProcessMemory` → T1055 (Process Injection)
- `CreateRemoteThread` → T1055 (Process Injection)
- ` RegSetValue` → T1112 (Modify Registry)
- `URLDownloadToFile` → T1105 (Ingress Tool Transfer)
**Output:** Kill chain visualization (text or SVG) showing sequence of ATT&CK techniques used
**Files to touch:** `~/bin/greysec/variant_event_consumer.py` (add mapping logic)
**Who:** qwen2.5-coder:14b
**Time:** ~2 hours (building the mapping table is the work)
**Dependencies:** Task 2 (RedEdr events must flow)
---
## Definition of Done
GreySec MAL is operational when:
1. All 4 critical bugs are fixed and verified
2. A known-malicious payload (ransomware_sim_v1.py) produces a Detection Score > 60
3. MITRE ATT&CK kill chain shows at least 3 techniques for that payload
4. A known-clean payload (notepad.exe) produces a Detection Score < 20
5. Analysis turnaround is < 5 minutes for a 1MB binary
6. Client upload portal accepts a binary via API and returns a job ID
7. Results are accessible via web dashboard within 5 minutes of upload
8. Skill file `greysec-malware-pipeline` exists and documents the full operational procedure
9. Time tracking is hooked into the pipeline (AI minutes logged to TIME-LOG)
10. gbrain logging is hooked into the pipeline (findings logged post-analysis)
---
## DEBT (Action Items from This Kanban)
| Action Item | Priority | Status | Notes |
|------------|----------|--------|-------|
| Fix VM share mount (Task 1) | CRITICAL | open | Do first — blocks all testing |
| Fix RedEdr zero events (Task 2) | CRITICAL | open | Do second — blocks reporting |
| Install Whiskers as Windows service (Task 3) | CRITICAL | open | Do third — blocks reliability |
| Fix manager.py timeout (Task 4) | DEGRADED | open | Do fourth |
| Build Detection Score algorithm (Task 5) | HIGH | open | Primary deliverable metric |
| Build web dashboard (Task 6) | HIGH | open | Client-facing UI |
| Build client upload portal (Task 7) | HIGH | open | API for clients |
| Build MITRE ATT&CK mapper (Task 8) | HIGH | open | Kill chain output |
| Write greysec-malware-pipeline skill | MEDIUM | open | Docs |
| Add TIME-LOG hook | MEDIUM | open | Cost tracking |
| Add gbrain logging hook | MEDIUM | open | Knowledge capture |