offensive-keylogger-arch

Name: offensive-keylogger-arch
Author: SnailSploit

2.8kstars447forks

How to install offensive-keylogger-arch?

snailsploit/claude-red/offensive-keylogger-arch

$npx -y skills add SnailSploit/Claude-Red --skill offensive-keylogger-arch

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# SKILL: Novel research
2
3	## Metadata
4	- Skill Name: keylogger-architecture
5	- Folder: offensive-keylogger-arch
6	- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/Low-level%20Keylogger%20architecture_.md
7
8	## Description
9	Low-level keylogger architecture design: kernel driver hooks (WH_KEYBOARD_LL, 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.
10
11	## Trigger Phrases
12	Use this skill when the conversation involves any of:
13	`keylogger, keyboard hook, WH_KEYBOARD_LL, SetWindowsHookEx, ETW, kernel driver, input capture, low-level keylogger, malware architecture, stealth, exfiltration`
14
15	## Instructions for Claude
16
17	When this skill is active:
18	1. Load and apply the full methodology below as your operational checklist
19	2. Follow steps in order unless the user specifies otherwise
20	3. For each technique, consider applicability to the current target/context
21	4. Track which checklist items have been completed
22	5. Suggest next steps based on findings
23
24	---
25
26	## Full Methodology
27
28
29
30	Case study of different keylogger implementations, how to implement them and their individual IOCs.
31
32	---
33	## SetWindowHookEx
34	Majority of malware uses user32.dll!SetWindowHookEx to create a global hook event. this modifies an internal structure in `win32k.sys`.
35	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:
36
37	1. Validate and allocate a hook record
38	`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
39	2. Decide whether the hook procedure must live in the target process
40	- Low-level hooks (`WH_KEYBOARD_LL`, `WH_MOUSE_LL`)
41	– NO injection.
42	– 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* .
43	- All other global hooks (`WH_KEYBOARD`, `WH_CBT`, `WH_GETMESSAGE`, …)
44	– YES injection required.
45	– For every process that satisfies the filter (same desktop, matching bitness),
46	- 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.
47	- 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.
48	– 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.
49
50	3. Event routing at runtime
51	When the monitored event occurs (key press, window activation, etc.), `win32k` walks the hook chain inside the thread that owns the input queue.
52	- If the hook procedure lives in that process, the kernel simply calls the address inside the injected DLL.
53	- 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.
54	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.
55
56	4. Mandatory `CallNextHookEx`
57	Each hook handler must call `CallNextHookEx` to pass control down the chain.
58	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.
59	#### TLDR
60	- 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.
61	- 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.
62	- 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.).
63	- 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.
64	### IOCs:
65	- Could be caugh

People who liked this also viewed

6 picks

Type

offensive-keylogger-arch

2.8kstars447forks

View on GitHub

How to install offensive-keylogger-arch?

snailsploit/claude-red/offensive-keylogger-arch

$npx -y skills add SnailSploit/Claude-Red --skill offensive-keylogger-arch

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# SKILL: Novel research
2
3	## Metadata
4	- Skill Name: keylogger-architecture
5	- Folder: offensive-keylogger-arch
6	- Source: https://github.com/SnailSploit/offensive-checklist/blob/main/Low-level%20Keylogger%20architecture_.md
7
8	## Description
9	Low-level keylogger architecture design: kernel driver hooks (WH_KEYBOARD_LL, 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.
10
11	## Trigger Phrases
12	Use this skill when the conversation involves any of:
13	`keylogger, keyboard hook, WH_KEYBOARD_LL, SetWindowsHookEx, ETW, kernel driver, input capture, low-level keylogger, malware architecture, stealth, exfiltration`
14
15	## Instructions for Claude
16
17	When this skill is active:
18	1. Load and apply the full methodology below as your operational checklist
19	2. Follow steps in order unless the user specifies otherwise
20	3. For each technique, consider applicability to the current target/context
21	4. Track which checklist items have been completed
22	5. Suggest next steps based on findings
23
24	---
25
26	## Full Methodology
27
28
29
30	Case study of different keylogger implementations, how to implement them and their individual IOCs.
31
32	---
33	## SetWindowHookEx
34	Majority of malware uses user32.dll!SetWindowHookEx to create a global hook event. this modifies an internal structure in `win32k.sys`.
35	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:
36
37	1. Validate and allocate a hook record
38	`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
39	2. Decide whether the hook procedure must live in the target process
40	- Low-level hooks (`WH_KEYBOARD_LL`, `WH_MOUSE_LL`)
41	– NO injection.
42	– 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* .
43	- All other global hooks (`WH_KEYBOARD`, `WH_CBT`, `WH_GETMESSAGE`, …)
44	– YES injection required.
45	– For every process that satisfies the filter (same desktop, matching bitness),
46	- 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.
47	- 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.
48	– 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.
49
50	3. Event routing at runtime
51	When the monitored event occurs (key press, window activation, etc.), `win32k` walks the hook chain inside the thread that owns the input queue.
52	- If the hook procedure lives in that process, the kernel simply calls the address inside the injected DLL.
53	- 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.
54	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.
55
56	4. Mandatory `CallNextHookEx`
57	Each hook handler must call `CallNextHookEx` to pass control down the chain.
58	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.
59	#### TLDR
60	- 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.
61	- 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.
62	- 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.).
63	- 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.
64	### IOCs:
65	- Could be caugh

People who liked this also viewed

6 picks

Type