Skip to content

PERFORMANCE_COMPARISON.md

Latest commit

 

History

History
166 lines (127 loc) · 6.87 KB

PERFORMANCE_COMPARISON.md

File metadata and controls

166 lines (127 loc) · 6.87 KB
Raw

LaraC2 Shell -- Performance Comparison: Official vs Internal API

Measured on a production MDE tenant across Windows, Linux, and macOS targets.

Head-to-Head Comparison

Command Execution Latency

Operation Official API Internal API Internal Advantage
Poll interval 2s 1s 2x more responsive
Session model Stateless (new action each time) Persistent (30-min, reusable) No reconnect overhead
whoami 20-28s avg 4.9s 4-6x faster
dir 14-25s avg 2.6s 5-8x faster
processes 20-75s avg 8.1s (incl. connect) 2-9x faster
connections ~15s 2.5s 6x faster
services ~15s 2.6s 6x faster
hostname 11-16s 3.8s 3x faster
multi-statement ~16s 3.9s 4x faster
invalid command 20-23s 4.8s 5x faster

Batch & Multi-Command

Feature Official API Internal API
Multiple commands per API call YES (up to 5) NO (sequential)
2-cmd batch 20s (one call) ~8s (two calls)
5-cmd batch 74s (one call) ~20s (five calls, faster per-cmd)
Cross-machine Separate actions Separate sessions
Session reuse N/A (stateless) YES (2-5s subsequent)

Throughput

Metric Internal API Official API
Commands/min (sustained) ~10-15 ~1-2
Near-real-time (<5s) YES (native, session reused) NO
Interactive feel YES NO (always >10s)

When to Use Which

Use Case Recommended API Why
Interactive investigation Internal 2-5s response, session reuse
Scripted automation (no MFA) Official Client credentials, no browser
Multi-command batch Official 5 commands per API call
Rapid sequential commands Internal No ActiveRequest conflicts
Multi-machine sweep Internal 2-5s per machine vs 15-30s
CI/CD pipeline Official App registration, no interactive auth
Near real-time response Internal 1s poll, persistent session

Real-Time Shell Feasibility

Measured Latencies

Operation Internal API Official API Speedup
processes (native) 3-15s 20-175s 2-12x
dir (native) 2-4s 14-25s 4-6x
connections (native) 2-4s ~15s 4-6x
services (native) 2-5s ~15s 3-6x
whoami (B64 wrapped) 4-9s 20-46s 3-5x
hostname (B64 wrapped) 4-7s 11-16s 2-4x
session connect 9-15s N/A (stateless) --
disconnect + reconnect 7-9s N/A --
cross-machine (new session) 7-10s 15-30s 2-3x

First command includes session connect time (~10-15s). Subsequent commands are 2-5s.

Conclusion

Internal API: YES -- with session reuse, native commands respond in 2-5s. This is as close to real-time as MDE allows. The bottleneck is the SenseIR agent on the target, not the framework.

Official API: NO -- minimum ~15s per command due to stateless architecture (submit -> poll -> fetch). Useful for automation and CI/CD, not interactive use.

Dynamic Limits (Documented vs Measured)

Limit MS Documented Measured Framework Handling
LR rate limit 10/min Confirmed 429 + Retry-After, sliding window queue
Library upload/min 100/min Confirmed Sliding window queue
Library upload/hour 1500/hr Confirmed Hourly counter
ActiveRequest 1 per machine Confirmed Smart cancel/wait + 12 retries
Session inactivity 30 min ~25-30 min observed Auto-reconnect
sccauth lifetime Undocumented ~45-60 min Silent re-auth (TOTP/passkey)
OAuth token 3600s 3599s measured Auto-refresh with 60s margin
XSRF TTL Undocumented ~4 min Auto-refresh
Args payload Undocumented ~30KB reliable, >35KB timeout, >40KB rejected Size warning + guidance
File upload 20MB Enforced Pre-upload size check
Batch commands 5 per call Confirmed (official only) Auto-split >5
Default timeout Undocumented 1800s (server decides) Per-command overrides
Shared action queue Undocumented Official + Internal share per-machine queue Cannot run simultaneously

API Flow Comparison

Official API: Upload -> Execute Flow

1. Upload executor stub (one-time): POST /libraryfiles -> 20-30s
2. Submit RunScript action: POST /machines/{id}/runliveresponse -> instant
3. Poll action status: GET /machineactions/{id} -> 2s intervals, 15-45s total
4. Fetch output: GET .../GetLiveResponseResultDownloadLink -> 2-5s
5. Download + parse JSON blob -> 1-2s
   Total per-command: 20-60s

Internal API: Session-Based Flow

1. Create session (one-time): POST /create_session -> 8-15s
2. Send command: POST /create_command -> instant
3. Poll command: GET /commands/{id} -> 1s intervals, 2-5s total
4. Output included in poll response (no separate download)
   Total per-command: 2-5s (after session established)

Comparison

Advantage Official API Internal API
No session management YES (stateless) Requires session lifecycle
Faster per-command NO (15-60s) YES (2-5s)
Batch multiple commands YES (up to 5) NO (sequential)
No ActiveRequest conflicts NO (1 per machine) YES (session queues internally)
Works in CI/CD YES (client creds) NO (needs portal auth)
Works without MFA YES (app registration) NO (portal auth requires user)

LaraC2 Shell vs Raw API

Step Raw Official API LaraC2 Shell
Stub upload Manual: build multipart, POST, handle conflicts Auto on connect, 409 override
B64 encode Manual: choose UTF-16LE/UTF-8 per OS Auto-detect OS, auto-encode
Build RunScript Manual: JSON with ScriptName + Args params Type command directly
Poll + fetch Manual: loop + download link + parse JSON Transparent: returns clean output
Error handling Manual: check 400/401/403/409/429/503 Automatic: retry, backoff, guidance
Multi-command Manual: build Commands[] array Automatic batching up to 5

Cross-OS Performance

executor_b64.sh works on Linux and macOS once properly uploaded.

Target OS Internal API Avg Official API Avg Notes
Windows ~7s ~30s Primary test target
Linux ~6s ~26-33s Proven working
macOS ~6s ~26-33s Proven working

Cross-OS constraints:

  1. .sh stubs must have Unix line endings (LF, not CRLF) or bash fails with "ambiguous redirect".
  2. Official API library upload does not sync .sh files to Linux/macOS. Upload via Internal API (portal) or Defender portal UI first.