Detect CorKLOG by looking for keylogging indicators such as suspicious access to keyboard input, injected code in user processes, and outbound exfiltration of captured data. Watch for new persistence entries, unusual DLL loading, and processes that collect input while masking their purpose. Combine endpoint telemetry with network monitoring for small, repeated uploads.
What to look for on endpoints when CorKLOG is trying to hide
CorKLOG detection starts with endpoint behavior, because the most reliable clues usually appear where the malware touches input, memory, and process state. Security teams should treat suspicious access to keyboard input, injected code in user processes, unusual DLL loading, and processes that appear to read keystrokes while masking their purpose as core hunting signals. Those indicators matter most when they show up together.
Look for the pattern, not just one event. A single odd DLL load may be noisy, but a process that injects into another process, hooks input paths, and then stays resident is more consistent with a keylogger than a normal application. Baseline which processes should ever interact with keyboard input, and flag anything outside that trusted set.
How to confirm exfiltration from captured input
Once a host-side indicator appears, confirm whether the captured data is being moved off the box. CorKLOG-style activity often produces small, repeated uploads that can blend into ordinary traffic, so network monitoring should focus on frequency, destination reputation, and timing rather than volume alone. Repeated outbound connections shortly after input capture are a stronger signal than a single large transfer.
Correlate endpoint telemetry with network logs to connect the dots: process creation, DLL loads, injected code, and keyboard access on one side, then periodic outbound sessions on the other. If the same process or its child processes are involved in both collection and upload, the case becomes much stronger. That correlation is often what turns suspicious behavior into a defensible detection.
What usually distinguishes CorKLOG from ordinary application noise
The difference is usually the combination of persistence, stealth, and purpose. New persistence entries show that the malware is trying to survive reboot or logoff, while input collection and obfuscated process behavior suggest deliberate concealment. Teams should prioritize detections that join those behaviors together, because each one alone can look benign in isolation.
For investigation, focus on whether the process lineage makes sense. A legitimate productivity app may read input for a real user function, but it should not also create unusual persistence, inject code, or stage repeated outbound transfers. That mismatch between stated purpose and actual behavior is often the clearest sign of malicious collection.
Risk and Threat Considerations
Keylogging is high-impact because it can capture credentials, session material, sensitive messages, and other data that immediately expands attacker access. The threat becomes more serious when the malware hides inside trusted user processes, because that can delay detection and let exfiltration continue long enough to support follow-on compromise.
Failure mechanism: The malware blends keyboard capture, code injection, and persistence into normal-looking process activity, then sends stolen data in small bursts that evade volume-based alerts.
Impact: Security teams may miss the compromise until credentials are reused, sessions are hijacked, or the collected input is leveraged for broader intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1056 — Input Capture | CorKLOG detection centers on keylogging and input-capture behavior. |
| T1055 — Process Injection | Injected code in user processes is a core CorKLOG hunting signal. | |
| T1547 — Boot or Logon Autostart Execution | New persistence entries are part of the detection pattern for CorKLOG. | |
| Recommendation — Map keyboard-access activity to T1056 and alert on suspicious input capture paths. Correlate process injection with keylogging telemetry to confirm malicious collection. Hunt for new autostart entries on hosts that also show input capture and exfiltration. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find anomalous events | Small repeated uploads require network monitoring to spot exfiltration. |
| DE.CM-07 — Monitoring for unauthorized personnel, connections, devices, software, and information is performed | Unusual DLL loads and rogue software activity fit host monitoring needs. | |
| Recommendation — Tune network monitoring to flag repeated low-volume uploads tied to suspicious processes. Flag unauthorized software behaviors such as unusual DLL loading and process masking. | ||
Practitioner Guidance
What to verify: Confirm which processes are allowed to access keyboard input on managed endpoints, and compare that allowlist against live telemetry. If a process loads unusual DLLs, creates persistence, and also generates outbound traffic soon after input events, treat it as a priority investigation even if the individual alerts look low severity.
Decision rule: If the suspected process can access user input and also reach external networks, prioritize containment and credential review before deep reverse engineering. If exfiltration is already visible, the key question is whether the collection has affected other accounts or systems, not whether the malware family is fully identified.
Practitioner takeaway: The strongest CorKLOG detections come from correlation, not single indicators, so teams should hunt for the chain of input access, injection, persistence, and repeated exfiltration as one event stream.