You’ve discovered an employee’s credentials in a stealer log. The credential rotation is mandatory and obvious. The next question is the harder one: what’s the actual state of the infected machine, and what did the attacker take that you don’t see in the credential dump? Stealer logs include enough context to answer most of that, if you know how to read them.
What’s in a stealer log file
A typical stealer log archive contains a predictable directory structure. System.txt, basic system info: hostname, OS version, CPU, GPU, RAM, installed antivirus, screen resolution, public IP, system locale, timezone. Passwords.txt, saved browser passwords by URL. Cookies/, folder per browser containing the stolen cookie databases. Autofill.txt, names, addresses, credit cards from browser autofill. Wallets/, extracted wallet files for any installed crypto software. Screenshot.png, desktop capture at the moment of exfiltration. Sometimes Software.txt with the list of installed applications.
Each artefact tells you something forensically useful.
Identifying which machine
System.txt tells you the hostname. If the hostname follows your corporate naming convention, you can identify the exact device immediately. If it’s a personal machine (the employee was working from a laptop with their saved corporate credentials), the hardware specs and locale narrow it down.
The desktop screenshot is often the giveaway. It shows what the user had open at the moment of infection, sometimes a sales dashboard with the company logo visible, sometimes a corporate email client. That tells you both who the user was and what they were doing.
Identifying the infection vector
The Software.txt or process list in the log occasionally reveals the malware’s drop path. Common patterns: a recently-installed “FreeYouTube_Downloader.exe” or “Adobe_Activator.exe” with a creation date matching the log timestamp. Cracks of paid software (Photoshop, AutoCAD, Office) are the dominant vector. “AI Tools” and “Game Cheats” sit in the next tier.
The browser history (when included) often shows the page where the malicious download came from, a SEO-poisoned search result, a malvertising landing page, a fake CAPTCHA page. Knowing the source helps you block the upstream channel for other employees.
Determining what was actually taken
The log file is what was sent on day one. After that initial exfiltration, the attacker may have continued operating on the machine, harvested additional credentials as the user logged into new services, accessed connected drives, or pivoted into the corporate network. The log file is a snapshot, not the complete inventory of damage.
If the cookie dump includes corporate-VPN or Microsoft 365 cookies, assume the attacker accessed those sessions before they expired. Check the corresponding access logs for activity from unfamiliar IP ranges. If you find any, you’re past credential rotation and into incident response.
Cleaning the infected machine properly
For corporate-owned devices: image-wipe and rebuild. Not “run a scan.” Modern stealers persist through scans, drop secondary loaders, and sometimes leave dormant access tools that activate weeks later. The only safe answer is a clean install.
For personal devices that touched corporate credentials: the conversation with the employee is harder. Recommend a full reset, but recognise that not all employees will do it. The minimum: rotate every credential, revoke every active session in the corporate IdP, and treat the personal device as untrusted for corporate access until it’s been rebuilt.
The defensive lift this enables
Done well, this forensic process turns a “credentials in a log dump” finding into actionable intelligence: which devices to rebuild, which sessions to revoke, which infection patterns to communicate to other employees, which upstream malvertising or SEO-poisoned domain to block. The log file by itself is a problem; read carefully, it’s a roadmap to fixing the problem.