Mmcp.market

offensive-keylogger-arch skill

by SnailSploit·SnailSploit/Claude-Red·7.0k stars·MIT

No description in the SKILL.md.

A94/100content scan

Is the offensive-keylogger-arch skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.

  • lowSKILL.md:1

    The name should be 1 to 64 lowercase letters, digits or hyphens.

    (missing)
  • lowSKILL.md:1

    No description, so an agent cannot tell when to use the skill.

    (missing)

Install the offensive-keylogger-arch skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description. 

git clone --depth 1 https://github.com/SnailSploit/Claude-Red.git /tmp/Claude-Red
mkdir -p ~/.claude/skills
cp -r /tmp/Claude-Red/Skills/infrastructure/offensive-keylogger-arch ~/.claude/skills/offensive-keylogger-arch
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

SKILL: Novel research

Metadata

  • Skill Name: keylogger-architecture
  • Folder: offensive-keylogger-arch
  • Source: https://github.com/SnailSploit/offensive-checklist/blob/main/Low-level%20Keylogger%20architecture_.md

Description

Low-level keylogger architecture design: kernel driver hooks (WHKEYBOARDLL, SetWindowsHookEx), ETW-based input capture, user-mode vs kernel-mode approaches, stealth techniques, and data exfiltration. Use for understanding input capture mechanisms, EDR evasion research, or malware architecture analysis.

Trigger Phrases

Use this skill when the conversation involves any of: keylogger, keyboard hook, WHKEYBOARDLL, SetWindowsHookEx, ETW, kernel driver, input capture, low-level keylogger, malware architecture, stealth, exfiltration

Instructions for Claude

When this skill is active:

  1. Load and apply the full methodology below as your operational checklist
  2. Follow steps in order unless the user specifies otherwise
  3. For each technique, consider applicability to the current target/context
  4. Track which checklist items have been completed
  5. Suggest next steps based on findings

Full Methodology

Case study of different keylogger implementations, how to implement them and their individual IOCs.

SetWindowHookEx

Majority of malware uses user32.dll!SetWindowHookEx to create a global hook event. this modifies an internal structure in win32k.sys. Internally, SetWindowsHookEx is just a user-mode wrapper around NtUserSetWindowsHookEx (which itself wraps around zzzzNtUserSetWindowsHookEx) in win32k.sys. What happens after you call it depends on the hook type you request but the sequence is always the same four steps:

win32k.sys creates an internal HOOK structure, fills in the filter type, module handle, thread/desktop IDs, and inserts the structure at the head of the global hook chain for that type

  1. Validate and allocate a hook record
  1. Decide whether the hook procedure must live in the target process

– NO injection. – The system leaves the hook DLL in the original caller’s address space and simply delivers the event to that process via an internal WM message posted to its hidden “ghost” window** .

  • Low-level hooks (WHKEYBOARDLL, WHMOUSELL)

– YES injection required. – For every process that satisfies the filter (same desktop, matching bitness),

  • All other global hooks (WHKEYBOARD, WHCBT, WHGETMESSAGE, …)**

– The first time the target thread is about to return to user mode, the kernel APCs the loader, so the DLL’s DllMain runs in the context of the victim process.

  • In/before Vista: win32k queues an asynchronous load request to csrss.exe, which in turn calls LoadLibraryEx inside the target process, mapping the hook DLL and fixing up its entry point.
  • After Vista: The target process is added to a pending-load list inside win32k; the first user-mode exit from kernel to that process takes the APC and calls LdrLoadDll directly.

When the monitored event occurs (key press, window activation, etc.), win32k walks the hook chain inside the thread that owns the input queue.

  1. Event routing at runtime

That thread must keep pumping messages; otherwise, the system blocks all further input for the desktop, which is why low-level hooks are so easy to detect by their side-effect on system responsiveness.

  • If the hook procedure lives in that process, the kernel simply calls the address inside the injected DLL.
  • If the procedure lives in another process (low-level case), the kernel marshals the raw parameters (KBDLLHOOKSTRUCT / MSLLHOOKSTRUCT) into an internal message and posts it to the installing thread’s message queue.

Each hook handler must call CallNextHookEx to pass control down the chain. Internally, CallNextHookEx is just a call back into win32k, which continues the chain walk; if any handler fails to call it, the chain is broken and subsequent handlers never run. This might break input for the whole session.

  1. Mandatory CallNextHookEx

TLDR

  • Low-level hooks look stealthy because no foreign code is mapped, but they pin the installing thread and are trivially detected by their message-queue footprint.
  • Regular global hooks achieve true code injection without WriteProcessMemory or CreateRemoteThread, but they leave a mapped DLL behind in every hooked process. Easy VAD artefact for EDRs.
  • most EDRs avoid exhaustive VAD walks for every process on every event due to performance, but many will do targeted scans on on suspicious events (allocation > 64 kB, RWX, etc.).
  • The hook chain is global per desktop: once installed, your procedure sees every qualifying event on that desktop, which is why a single call can key-log the whole user session.

IOCs:

  • Could be caught by a hook in user32
  • Additional entry in the VAD (EDRs can check if the DLL is signed),
  • Mapped or on-disk DLL
  • Is it signed?
  • Memory scanners could detect non-backed-by-disk executable memory.
  • Does it have anything to do here?
  • Could be bypassed by ovewriting a present, mapped DLL with our memory?
  • Would need to prevent user from interacting with keyboard while it happens.

NtUserSetWindowsHookEx / zzzzNtUserSetWindowsHookEx

Same as above but you're directly calling the lower-level function. Same IOCs, really. You're only bypassing potential hooks in user32.dll. The full logic of these functions could be reimplemented fully without a jump to external modules but it has too much IOCs and is too complex to implement to really be interesting.

Session boundary: raw-input registration is per-session, not per-desktop. A service in session-0 cannot register for keyboard raw-input and expect to see session-1 keystrokes – the HID packets are routed to the session that owns the target HWND. (You can open the physical keyboard device object directly and parse HID, but that is a completely different attack surface – needs admin, bypasses win32k.)

IOCs:

  • Additional entry in the VAD (EDRs can check if the DLL is signed),
  • ^ only theorical. No EDR implements this afaik
  • Mapped or on-disk DLL
  • Is it signed?
  • Memory scanners could detect non-backed-by-disk executable memory.
  • Does it have anything to do here?

NtUserRegisterRawInputDevices / RegisterRawInputDevices

tells the window manager to deliver raw HID packets to one specific HWND (or to the thread whose queue the window is attached to)

Practical abuse scenario

  1. Start a background thread in our process or implement a PeekMessage / GetMessage loop.
  2. Create a zero-sized message-only window (HWND_MESSAGE).
  3. Register keyboard raw-input with RIDEVINPUTSINK – > this routes all keyboard traffic to our window even when it is not in the foreground** .
  4. Pump the thread’s message queue forever; in the WM_INPUT handler call GetRawInputData and log the RAWKEYBOARD payload.
  5. exfil
  6. Profit?

Because no hook is installed, this technique:

  • does not appear in WinDbg’s !hook list
  • leaves no cross-process DLL mapping
  • is invisible to most EDR “hook chain” sensors

this still requires your process to stay alive and message-aware, and it cannot key-log from sessions it is not running in.

Kernel-mode implementation:

Allocates a kernel copy of the array

  1. Sets an oplock to prevent race conditions
  2. Validates parameters
  3. Win32AllocPoolWithQuotaZInit

Calls the INTERNAL worker (see below). It walks the array, updates the per-thread raw-input hook list, tells hidclass which top-level windows want raw HID traffic, etc.

  1. RegisterRawInputDevices(v9, a2, 0)

Emits an ETW event for Audit/Threat-Intelligence so that defenders can see which process just asked for raw keyboard data (keylogger-style activity).

  1. EtwTraceAuditApiRegisterRawInputDevices
  1. Cleanup

The internal worker modifies our process's EPROCESS structure. This makes it so that we can't re-implement this from user-mode.

IOCs:

→ This is the strongest IOC for this technique; do not discount it.

  • Raises ETW event from kernel-mode win32kfull.sys driver.
  • NOT AVOIDABLE!
  • Do AVs/EDRs really monitor it though?
  • Rumors have it that Defender does since 20H1.
  • The ETW payload contains PID, TID, UsagePage, Usage, Flags – enough to trivially score “key-board raw-input from a non-interactive process” as suspicious.
  • Channel is on by default and cannot be disabled without patching the kernel.

– create a hidden desktop (logged by Object Manager auditing), or – open the \Device\KeyboardClass0 device directly (creates IRPMJREAD telemetry).

  • Raw-input must have a window station and desktop – the call fails (ERRORINVALIDWINDOWHANDLE) if the thread is not connected to a desktop. Services running in session-0 with no desktop therefore cannot use this path; they must** either:

Both are easy to alert on.

More skills from SnailSploit/Claude-Red

  • Aoffensive-active-directoryActive Directory attack methodology for internal network red team engagements. Covers reconnaissance (BloodHound, PowerView, ADExplorer), credential abuse (Kerberoasting, ASREProasting, NTLM relay, LLMNR/NBT-NS poisoning), privilege escalation (ACL abuse, GPO abuse, unconstrained/constrained delegation), lateral movement (Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, WMI/WinRM/PsExec), persistence (Golden/Silver/Diamond Tickets, DCSync, DCShadow, AdminSDHolder, Skeleton Key), forest trust attacks, ADCS abuse (ESC1-ESC15), and modern MDI/Defender for Identity evasion. Use when assessing on-prem AD, hybrid AD/Entra ID environments, or ADCS deployments.
  • Aoffensive-advanced-redteamComprehensive red team operations methodology covering full engagement lifecycle from planning through reporting. Addresses engagement scoping and rules of engagement negotiation, multi-tier C2 infrastructure design with redirectors and domain fronting, malleable traffic profiles and beacon tradecraft, OPSEC discipline including attribution avoidance and indicator management, EDR and AMSI evasion techniques using direct syscalls and unhooking, data collection with chain-of-custody controls, and structured reporting with purple team debrief workflows. Covers assumed-breach, external-to-internal, insider threat, and hybrid physical-cyber engagement scenarios with MITRE ATT&CK mapping throughout. Targets operators planning or executing adversary simulation engagements against mature defenders.
  • Coffensive-ai-security
  • Aoffensive-anti-forensicsAnti-forensics and evidence destruction techniques for red team operators conducting authorized engagements. Covers log clearing on Windows (wevtutil, Clear-EventLog, ETW provider patching) and Linux (journal truncation, utmp/wtmp binary editing, syslog manipulation), timestamp manipulation via Timestomp and SetMACE to defeat timeline analysis, filesystem-level anti-forensics including NTFS Alternate Data Streams for payload hiding and secure deletion with sdelete/shred, memory artifact removal to counter live forensics, disk artifact manipulation targeting MFT entries and USN journal records, network forensics evasion through encrypted C2 channels and DNS-over-HTTPS tunneling, and anti-VM/sandbox detection to avoid dynamic analysis environments. Tools: Timestomp, wevtutil, sdelete, shred, MimiPenguin, Invoke-Phant0m. Aligns to MITRE ATT&CK T1070 (Indicator Removal), T1027 (Obfuscated Files or Information), T1497 (Virtualization/Sandbox Evasion). Each technique includes the forensic artifact it targets, the destruction or manipulation method, and the defender perspective so operators understand detection gaps they must account for.
  • Aoffensive-api-abuseAdvanced API exploitation methodology focused on business logic abuse and sophisticated attack patterns that bypass traditional security controls. Covers business logic bypass through API call chaining and workflow manipulation. Addresses GraphQL-specific attacks including batching for credential brute-force, query depth exploitation, and introspection abuse. Includes pagination exploitation for data exfiltration, webhook hijacking for SSRF and data interception, and resource exhaustion through algorithmic complexity attacks. Covers race conditions in API transactions using parallel request techniques. Provides comprehensive JWT manipulation including algorithm confusion, kid injection, jku/x5u abuse, and claim tampering. Details API key leakage detection across source repositories, client-side code, and error messages. Covers undocumented endpoint discovery through predictable naming, debug routes, and source map analysis. Tooling includes Arjun, ParamSpider, jwt_tool, and GraphQL Voyager. Designed for authorized penetration testers targeting business logic layers that automated scanners miss.
  • Aoffensive-api-securityComprehensive API security testing methodology covering REST, gRPC, and WebSocket attack surfaces. Addresses the full OWASP API Security Top 10 2023 including BOLA/IDOR, broken authentication, excessive data exposure, rate limiting bypass, BFLA, mass assignment, SSRF, and security misconfiguration. Includes REST-specific attacks such as HTTP verb tampering, content-type switching, and parameter pollution. Covers gRPC exploitation through protobuf interception, reflection API enumeration, and metadata injection. Addresses WebSocket vulnerabilities including origin bypass, message injection, and cross-site WebSocket hijacking. Provides tooling guidance for Burp Suite, Postman, grpcurl, websocat, and mitmproxy. Each technique includes detection signatures and defensive indicators so you understand what artifacts your testing leaves behind. Designed for authorized penetration testing engagements against API-driven architectures.
  • Aoffensive-bluetooth-bleBluetooth Low Energy (BLE) attack methodology — GATT enumeration, characteristic read/write without auth, pairing downgrade (Just Works forced), LE Secure Connections bypass, MITM via active relay, sniffing with Sniffle (TI CC1352) / Ubertooth / Frontline, encryption key extraction (LE Legacy Pairing crackable, LE Secure Connections strong), proximity authentication abuse (cars, locks), and companion-app trust analysis. Use for IoT BLE devices, smart locks, fitness trackers, medical devices, BLE beacons, or any device pairing over BLE.
  • Aoffensive-bluetooth-classicBluetooth Classic (BR/EDR) attack methodology — device discovery, service enumeration via SDP, LMP/L2CAP layer attacks, legacy PIN cracking (BlueBorne / KNOB), Bluetooth file-transfer abuse (BlueSnarfing legacy), unauthenticated profile abuse (HSP, HFP, OPP), and modern relevance against older industrial / automotive / accessory targets. Use when in-scope devices use Bluetooth Classic (Bluetooth ≤ 4.0 BR/EDR) — common in legacy car kits, industrial sensors, older medical devices, and audio accessories.
  • Aoffensive-bug-identification
  • Aoffensive-business-logicBusiness logic vulnerability testing for web/mobile/API engagements. Covers workflow bypass, state machine violations, multi-step process abuse, price/quantity/discount manipulation, currency confusion, coupon stacking, refund/chargeback abuse, race conditions on logic boundaries, parameter tampering for hidden flows, role/tenant boundary violations, time-of-check vs use, anti-automation defeat, fraud-detection evasion, and subscription/quota abuse. Use when scoping an application after surface-level OWASP Top 10 has been covered, or when the asset is a transactional/marketplace/fintech/e-commerce/SaaS app where logic flaws produce direct financial impact.
  • Aoffensive-c2-frameworksCommand and Control framework deployment, configuration, and operational tradecraft for red team engagements. Covers Cobalt Strike (malleable C2 profiles, Beacon types HTTP/HTTPS/DNS/SMB, Beacon Object Files for in-memory execution, sleep and jitter tuning, named pipe pivoting), Sliver (implant generation across mTLS/WireGuard/DNS transport, operator multiplayer mode, armory extensions), Mythic (agent ecosystem with Apollo/Poseidon/Medusa, C2 profile configuration, translation containers), Havoc (Demon agent with sleep obfuscation via Ekko/Zilean, indirect syscalls, dotnet inline execution), Metasploit (msfvenom payload generation, multi/handler staging, Meterpreter post-exploitation modules), redirector architecture using Apache mod_rewrite and Nginx, domain fronting through CDN providers, DNS-based C2 for restrictive network egress, and TLS certificate management for infrastructure OPSEC. Tools: Cobalt Strike, Sliver, Mythic, Havoc, Metasploit Framework. Aligns to MITRE ATT&CK T1071 (Application Layer Protocol), T1573 (Encrypted Channel), T1090 (Proxy/Connection Proxy).
  • Doffensive-cicd-pipelineComprehensive CI/CD pipeline exploitation methodology covering GitHub Actions injection vectors (expression injection via PR titles and issue bodies, workflow_run event abuse, GITHUB_TOKEN over-scoping, composite action supply chain compromise), Jenkins attack paths (Groovy sandbox escapes, script console remote code execution, Java remoting deserialization, credential store dumping, shared library injection), GitLab CI exploitation (YAML anchor injection, runner registration token abuse, CI variable extraction, protected branch bypass via merge request pipelines), and Azure DevOps pipeline agent compromise with service connection theft. Includes artifact poisoning techniques across all platforms, tooling guidance for gato and jenkins-attack-framework, and maps to MITRE ATT&CK T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain). Covers enumeration of pipeline configurations, privilege escalation from contributor to code execution, lateral movement through pipeline trust boundaries, and persistence via modified workflow definitions. Each technique section provides working exploitation code, detection indicators, and defensive countermeasures.

All agent skills → · MCP servers