When a machine gets infected by an infostealer like LummaC2 or Vidar, the malware leaves behind a specific set of output folders. Most threat actors focus on the easy, structured targets: browser cookies, saved passwords pulled from SQLite databases, and crypto wallet extensions. Passwords live in predictable places on an operating system, making them simple to pull and trade in bulk.
Non-human identities (NHIs) like API keys, cloud tokens and payment secrets are a completely different story.
These keys represent some of the highest value secrets an attacker could ever land. A single exposed token can grant direct administrative access to corporate AWS infrastructure, private GitHub repositories, payment gateways, or internal LLM applications – bypassing MFA and traditional perimeter security entirely.
Yet, despite their extreme value, these secrets are scattered everywhere. A single developer’s machine has tokens buried across .env files, local CLI configuration caches (~/.aws/credentials), build logs, shell histories, dynamic project configs, and temporary application dumps.
Because modern infostealers rely on broad file grabber modules that sweep up directory trees indiscriminately, they harvest these high value machine keys, sometimes by accident.
The paradox here is that attackers end up buried in their own noise. They harvest logs in bulk to find quick browser credentials, while active Stripe production keys and high privilege GitHub PATs sit unparsed in raw context files. The keys are incredibly powerful, but to the attacker, they might look like an unformatted text wall.
For security teams trying to clean up after an infection, finding and neutralizing these scattered, high impact secrets inside an infostealer dump before an attacker realizes what they have is critical. Here is how we dissect, parse, and verify these high value machine identities inside Lunar.
Finding the Needle: “Secret Parts” & Context Parsing #
Standard secret scanners look for simple string patterns in source code repos. But running basic regex against a raw, chaotic infostealer dump outputs endless noise and false positives.
To solve this, Lunar extracts exact Secret Parts – breaking raw strings down into their functional components (key type, prefix, signature, and owner mapping) – while linking them directly to the raw log context that proves where the token came from.
Case study 1: GitHub OAuth & Personal Access Tokens (PATs)
GitHub tokens carry an immense blast radius, often granting full access to private source code and CI/CD pipelines. When surfaced in Lunar, we pull the key string alongside its identity context and host forensics.
**Sensitive information and personal details are obfuscated for privacy. *
What data is available in Lunar?
Identity Mapping: Connects the token directly to the compromised GitHub user account.Forensic Context: Links the PAT back to the exact file path where it was buried alongside victim endpoint details (Computer Username).
Case study 2: OpenAI & LLM Provider API Keys
As organizations integrate LLM APIs into core products, leaked keys open the door to massive financial drain, quota theft, and proprietary data exposure.
**Sensitive information and personal details are obfuscated for privacy. *
What data is available in Lunar?
Raw Log Context Evidence: Preserves surrounding log lines, showing exactly how the string was scraped out of active process memory or temporary script files.Identity & Account Aggregation: Maps all developer email accounts and usernames tied to the compromised host environment for rapid internal ownership mapping.
Case study 3: Stripe API Keys
Exposing a payment processing key shifts an incident instantly from code exposure to direct financial risk and unauthorized data exfiltration.
**Sensitive information and personal details are obfuscated for privacy. *
What data is available in Lunar?
Raw Log Context Evidence: Preserves surrounding log lines, showing exactly how the string was scraped out of active process memory or temporary script files.Environment Parsing: Separates test keys (sk_test_…) from production secret keys (sk_live_…) based on structural key prefixes.
Case study 4: AWS Access Keys & Secret Keys
Cloud infrastructure keys represent full administrative exposure, frequently leaking as matching pairs inside local developer profiles (like ~/.aws/credentials).
**Sensitive information and personal details are obfuscated for privacy. *
What data is available in Lunar?
Credential Pairing: Pairs the key ID (AKIA…) with its corresponding secret key harvested from scattered log paths.IAM Scope & Attribution: Connects the exposed key pair to the underlying IAM role and cloud account structure.
Validation: Sorting Live Risk from Expired Noise #
When dealing with this powerful information, timing is everything. The most frustrating part of incident response is spending hours chasing dead, truncated, or already-rotated keys found in historical log archives.
Lunar runs non-destructive, real-time status checks against the issuing service as soon as a key is parsed from a stealer dump.
Verified (Active): The token is live, authenticated, and provides active access. This immediately escalates the incident to critical status and triggers automated revocation workflows.
Unverified The key string was extracted, but live testing confirms it is inactive or already rotated—preventing SOC teams from burning time on false alarms.
Conclusion #
Finding a leaked key inside a messy malware log shouldn’t require manual forensics. With automated parsing, clear identity mapping, and live status verification, teams can move from raw infostealer noise to verified token revocation in minutes.