version : 0.8 (public beta)

Aether is a Windows memory-forensics and threat hunting tool that scans live process memory for malicious pattern, detect injection techniques, implant signatures, reflectively loaded .NET assemblies. it works with a multi-layer confidence model that dramatically reduce the false positive rate and hunt for malicious behaviour. Aether has good capabilities in detecting Hollowing, APC, thread hijacking techniques. Security analysts can use it to scan,hunt and snapshot suspicious region for offline analysis.

quick explainations for Aether core features, you can read the full technical blogpost to get more insights:

• Byte-pattern matching across process memory with a first-byte index that provides 50-100x speedup over naive scanning
• ASCII + UTF-16LE dual encoding — catches strings stored by the .NET CLR (where "msxsl:script" becomes 6D 00 73 00 78 00 ...)
• Dynamic rule loading from JSON files — drop new signatures into rules/ without recompilation
• PE header detection in MEM_PRIVATE regions — flags reflectively loaded .NET assemblies (MZ + PE + BSJB metadata)

Aether layers five filters on top of the raw working-set signal so a finding requires multiple agreeing indicators before it is reported with FP filtering:

Other structural checks:

• PEB module cross-reference : MEM_IMAGE allocations that are not in the PEB module list (DLL hollowing / module stomping)
• Working-set scan : modified-code page detection via K32QueryWorkingSetEx, batched with one syscall per region instead of one per 4 KB page (≈ 50-100× faster than the naïve loop)
• Private RWX detection : flags MEM_PRIVATE + PAGE_EXECUTE_* (it produces FP results) allocations (shellcode, JIT spray, dynamic code stub allocations)
• Hook-prologue probe — reads the first 16 bytes of each private code page and matches classic x86/x64 trampolines:
  • E9 ?? ?? ?? ?? — JMP rel32
  • FF 25 ?? ?? ?? ?? — JMP [rip+disp32]
  • 68 ?? ?? ?? ?? C3 — PUSH imm32 ; RET
  • 48 B8 ?? ?? ?? ?? ?? ?? ?? ?? FF E0 — MOV RAX, imm64 ; JMP RAX
  • 49 BB ?? ?? ?? ?? ?? ?? ?? ?? 41 FF E3 — Detours-style MOV R11, imm64 ; JMP R11
• CLR detection — section-object probe for Cor_Private_IPCBlock_v4_<PID> and the v2 Cor_Private_IPCBlock_<PID> (legacy .NET 2/3 / mscorwks), so noisy app-pools running old runtimes are not misclassified

Aether checks threads with stricter classification and cross-correlation against the L1–L5 findings. For every created thread in the target process Aether reads its Win32StartAddress via NtQueryInformationThread and, when access permits, also the live Rip / Eip via GetThreadContext / Wow64GetThreadContext. Each address is then graded as the following table, for more details read the blogpost:

What makes this stronger than the basic check "is start_address in any module" check:

• VirtualQueryEx cross-check — every address is queried for Type / Protect / AllocationBase in a single O(1) call instead of a linear scan over the module list
• Cross-correlation with L1–L5 — a thread whose start lands inside an already-flagged allocation is upgraded from "OK" to TSAV_MODIFIED_HOST
• PEB consistency — hollowed modules are detected even when the start address technically falls inside a "real" range
• Suspended-RIP probe — Win32StartAddress is process-writable via NtSetInformationThread and is the spoofable field; the live Rip of a suspended thread is the one a loader can't easily rewrite. We compare the two and flag any disagreement that resolves to a suspicious region
• WoW64 aware — automatically switches to Wow64GetThreadContext and reads Eip for 32-bit threads inside a 64-bit process
• Access-rights ladder — falls back from QUERY_INFORMATION | GET_CONTEXT → QUERY_INFORMATION → QUERY_LIMITED_INFORMATION per thread, so partial-access scenarios still produce useful classifications

Aether supports XOR detection pattern at stub level for now and adopt Shannon entropy alogrithm to check randomness of byte values in memory region, it flags everything above a threshold. to address high amount of FP, Aether uses multiple indicators.

• TCP connection monitoring — polls GetExtendedTcpTable for a target PID
• Beacon pattern detection — identifies periodic short-lived connections (classic C2 callback behavior)
• Connection table output — formatted console table with state, endpoint, hits, and protocol

• Colored console report with severity-based ANSI highlighting
• Machine-parseable JSON for SIEM / d-tect.py pipeline integration
• Graded suspicion output — each MODIFIED_CODE_* finding carries private_pages and region_pages so triage has the actual numbers
• Table-formatted output using Unicode box-drawing characters for connection monitoring

Signatures are organised into JSON rule packs. Drop any of these into the rules/ directory:

Each rule file is a JSON array of signature objects:

[
  {
    "pattern": "msxsl:script",
    "weight": 5,
    "category": "engine_xslt",
    "description": "XSLT script block declaration"
  }
]

category maps to one of: engine_xslt, engine_codedom, engine_managed, c2_tcp, c2_http, c2_sql, c2_smtp, c2_file, c2_dns, evasion, reflective_load, webshell_generic.

Aether.exe --scan --pid <PID> [OPTIONS]
Aether.exe --scan --lookup "ProcessName.exe"
Aether.exe --hunt <PID> SLEEP_MS PERIOD
Aether.exe --scan-all [OPTIONS]

  Scan Results for PID 4820
  ==================================================
  Regions: 847 total, 312 scanned, 287 system-skipped
  Bytes scanned: 214.35 MB
  Read errors: 3
  Scan time: 1247 ms

  [HIGH] ENGINE_XSLT | score=18 hits=4 [T1220]
    +5 "msxsl:script" @ 0x7FFE2A3B1000 (ascii)
    +6 "urn:payload"  @ 0x7FFE2A3B1200 (ascii)
    +4 "enableScript" @ 0x7FFE2A3B1400 (utf16le)
    +3 "XsltSettings" @ 0x7FFE2A3B1600 (ascii)

  [CRITICAL] REFLECTIVE_LOAD | 2 PE headers in MEM_PRIVATE
    (1 with .NET BSJB metadata) [T1620]

  ---- Structural IOCs (8) ----
  [HIGH]     MISSING_PEB             @ 0x000001D6E0000000 (1048576 bytes)
  [HIGH]     DISK_MEM_DIFF           @ 0x000001D6E0001000 (4 private / 240 pages)
  [HIGH]     MODIFIED_CODE_HIGH      @ 0x000001D6E0001000 (4 private / 240 pages)
  [HIGH]     PRIVATE_RWX             @ 0x000001D6EDDD0000 (12288 bytes)
  [CRITICAL] XOR_PE_HEADER           @ 0x000001D6EDDD0000 (4 bytes)
  [CRITICAL] TSAV_SHELLCODE_PRIVATE  @ 0x000001D6EDDD0000 (8472 bytes)
  [HIGH]     TSAV_MODIFIED_HOST      @ 0x000001D6E0001000 (8476 bytes)
  [HIGH]     THREAD_START_ANOMALY    @ 0x0 (2 bytes)

With --verbose you also see per-thread detail and recovered XOR keys:

  [!] XOR_PE_HEADER @ 0x1D6EDDD0000 key_len=4 key=AABBCCDD
  [!] TID:8472 SHELLCODE_PRIVATE start=0x1D6EDDD0150
  [!] TID:8476 MODIFIED_HOST     start=0x1D6E0001A80 host=msi.dll

The recovered key bytes can be passed to a one-liner (python -c 'import sys; k=bytes.fromhex("AABBCCDD"); d=sys.stdin.buffer.read(); sys.stdout. buffer.write(bytes(b^k[i%len(k)] for i,b in enumerate(d)))') to dump the decrypted PE for analysis.

• Zig 0.16 — download here
• Cross-compilation works from any host OS (Linux, macOS, Windows)

git clone https://github.com/0xsp-SRD/aether
cd aether

# Debug build (safety checks enabled)
zig build

# Release build (smaller, faster binary)
zig build -Doptimize=ReleaseSafe
# or
zig build -Doptimize=ReleaseFast

The built executable lands in zig-out/bin/Aether.exe.

Copy zig-out/bin/Aether.exe and the rules/ directory to the target Windows machine if you want to perform additional signature scan. if the target process requires Administrative privileges, you need to run Aether.exe with Administrator privileges.

• Usermode only — no kernel driver; cannot detect rootkits or kernel-level manipulations
• IPv4 only — TCP connection monitoring does not support IPv6 endpoints for now.
• L5 disk diff requires file access — if the original module file has been deleted or is locked, the on-disk diff silently skips that module (other layers still run)
• TSAV spoof-trampoline list resolves in the scanner's own process — catches the common case where system DLLs share an ASLR base session-wide but may miss targets with unique per-process bases (rare on Win10+)
• TSAV RIP probe only catches suspended threads — a Win32StartAddress rewrite on an already-running thread can only be detected if the thread happens to be parked in a wait when probed (same constraint as Moneta)
• XOR-PE detection is basic on this release