Skip to main content
Commerce Security Authority
Category: Fraud Typologies

Infostealer

Also known as: Info stealer, Information stealer, Stealer malware
Simply put

An infostealer is a type of malicious software designed to secretly collect personal and sensitive information from an infected device and send it to an attacker. It commonly targets things like passwords, login details, financial information, and data stored in web browsers. It typically operates quietly in the background so the victim does not notice the theft.

Formal definition

An infostealer is a category of malware whose primary function is to harvest personally identifiable information (PII) and credentials from a compromised host and exfiltrate that data to an attacker-controlled destination. Targeted data commonly includes login credentials, browser-stored data (such as saved passwords, cookies, and autofill entries), and financial information. Infostealers generally operate covertly to avoid detection and may be delivered through multiple attack vectors, including phishing. In a payment security context, credentials and financial data captured by an infostealer can enable downstream fraud such as account takeover; however, the specific data obtained depends on the malware variant and what is present on the infected device, and this evidence does not establish infostealers as a means of capturing full track data or other sensitive authentication data.

Why it matters

Infostealers matter to payment security teams because the credentials and financial data they harvest can serve as raw material for downstream fraud. When an infostealer captures login details, browser-stored passwords, cookies, and autofill entries from a compromised device, an attacker may reuse those credentials to gain unauthorized access to accounts, which can enable account takeover. The threat is amplified by the covert nature of this malware: because it typically operates quietly in the background, victims may not realize their data has been stolen until fraudulent activity appears.

The specific risk posed by any given infection depends on the malware variant and on what data happens to be present on the infected device. An infostealer that scrapes saved browser credentials from a customer's or employee's machine can expose reused passwords, session cookies, and stored financial information. That said, the evidence here does not establish infostealers as a means of capturing full track data or other sensitive authentication data, and teams should not assume that an infostealer infection automatically implies exposure of that class of data. The concrete impact should be assessed against what the specific variant is known to target and what data was actually accessible on the host.

Because infostealers commonly spread through multiple attack vectors, including phishing, they intersect with the broader credential-hygiene and endpoint-protection controls that support account security. Reducing the impact of stolen credentials, for example through multi-factor authentication and monitoring for anomalous account access, may help mitigate the account takeover risk, though no single control eliminates it.

Who it's relevant to

Fraud analysts and merchant risk teams
Credentials and financial data harvested by an infostealer can enable downstream fraud such as account takeover. Fraud teams should account for stolen-credential scenarios when interpreting anomalous account access and login patterns, while recognizing that the specific data obtained depends on the malware variant and the infected device.
Security engineers and endpoint defenders
Because infostealers operate covertly and can spread through multiple attack vectors including phishing, endpoint protection, monitoring, and phishing-resistant controls are central to reducing infection and exfiltration. These measures may help mitigate but do not eliminate the risk.
Compliance officers
Infostealer infections can expose credentials and financial information, which is relevant to how organizations protect access to systems that handle payment data. Teams should assess exposure based on what data the specific variant targets and what was accessible, rather than assuming a fixed outcome, and confirm applicable control requirements against the current published standards.
Acquirers and payment processors
Stolen credentials captured by infostealers can facilitate account takeover against merchant and customer accounts. Note that this evidence does not establish infostealers as a means of capturing full track data or other sensitive authentication data, so exposure assessments should be scoped to the credentials and financial data actually at risk.

Inside Infostealer

Credential Harvesting
Infostealer malware is commonly designed to collect stored usernames and passwords from browsers, password managers, email clients, and other applications on an infected endpoint.
Session and Cookie Theft
Many infostealers capture browser session tokens and authentication cookies, which may allow an attacker to reuse an authenticated session and potentially bypass some login-time controls.
Payment and Cardholder Data Exposure
Infostealers may attempt to collect payment-related data such as PAN, cardholder name, or expiration date where it is stored or entered on the compromised system. Sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, or PINs and PIN blocks) must not be stored after authorization, so its presence for theft depends on improper handling rather than permitted storage.
Data Exfiltration Channel
Collected data is typically transmitted to attacker-controlled infrastructure, often bundled into logs that may later be sold or reused for account takeover, card-not-present fraud, or other follow-on activity.
Delivery and Persistence Mechanisms
Infostealers are commonly delivered through phishing, malicious downloads, or compromised software, and may employ techniques intended to maintain access or evade detection on the host.

Common questions

Answers to the questions practitioners most commonly ask about Infostealer.

Does an infostealer only target passwords, so payment data is safe if I don't store logins in the browser?
No. Infostealers are designed to harvest a broad range of data from an infected host, which can include saved credentials, session cookies and tokens, autofill data, and clipboard contents. Because a payment page or administrative session can be captured through browser artifacts or session hijacking, cardholder data and access to systems handling it may be exposed even when the operator never explicitly targeted stored passwords. The scope of what is captured depends on the specific malware, its configuration, and what data is present on the host.
If my cardholder data is encrypted or tokenized at rest, does that make me immune to infostealers?
No. Encryption, tokenization, truncation, and masking transform or reduce stored data, but an infostealer operates on the endpoint and can capture data as it is entered, rendered, or held in memory before those protections apply, as well as session tokens and credentials that grant access to systems. These at-rest controls are intended to reduce exposure and may affect PCI DSS scope depending on implementation and validation, but they do not address data captured at the point of entry or an authenticated session on a compromised host.
What data on a compromised endpoint should we treat as potentially exposed after an infostealer infection?
Treat any data that was present, entered, or rendered on the host during the infection window as potentially exposed, including saved and typed credentials, browser session cookies and tokens, autofill and clipboard contents, and locally stored files. Where the endpoint handled cardholder data, that data may be in scope; note that sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs must not be stored after authorization, so its presence on an endpoint warrants specific investigation. The exact exposure depends on the malware variant, its configuration, and what was accessible during the compromise.
How does infostealer-driven session token theft affect our authentication controls?
Stolen session cookies or tokens can allow an attacker to resume an already-authenticated session, which may bypass controls applied at login, including multi-factor authentication that was satisfied earlier in that session. Multi-factor authentication is intended to strengthen the authentication event but does not by itself protect a live session whose token has been exfiltrated. Mitigations such as shorter session lifetimes, token binding, and re-authentication for sensitive actions may reduce this risk but involve usability trade-offs and do not eliminate it.
What detection trade-offs should we expect when monitoring for infostealer activity?
Detection approaches such as endpoint monitoring, credential-exposure feeds, and anomalous session or access detection can help surface compromise but carry false-positive and false-negative trade-offs. Overly sensitive rules may generate noise and alert fatigue, while stealthy or novel variants may evade signature-based detection entirely. No single detection control should be treated as comprehensive; layered monitoring and validation against observed behavior are generally more effective than reliance on one method.
What response steps are appropriate when credentials or sessions may have been captured by an infostealer?
Response typically includes isolating the affected host, invalidating potentially exposed credentials and active session tokens, and reviewing access to any systems reachable from the compromised endpoint, prioritizing those handling cardholder data. Because captured data may include tokens that bypass a login prompt, credential resets alone may be insufficient without session invalidation. Align actions with your incident response plan and applicable PCI DSS incident response requirements, confirming the specific requirement wording against the current published standard rather than assuming a fixed requirement number.

Common misconceptions

Infostealer-harvested credentials are useless if multi-factor authentication is enabled.
MFA can help reduce the impact of stolen credentials, but infostealers that capture active session tokens or authentication cookies may allow reuse of an already-authenticated session. MFA addresses login-time risk and is not intended to eliminate all account takeover paths on its own.
Encrypting or tokenizing stored payment data means an infostealer on the endpoint poses no risk.
Encryption, tokenization, truncation, masking, and hashing transform or reduce data differently, and their effect depends on implementation and validation. An infostealer operating on a system where data is entered, decrypted, or otherwise accessible in usable form may still capture it. These controls help reduce exposure but do not by themselves guarantee protection against endpoint compromise.
Infostealer activity is purely an internal IT security problem unrelated to PCI DSS.
Where an infostealer can access cardholder data or sensitive authentication data, endpoint and malware controls are relevant to protecting that data. The specific requirements and their numbering differ between PCI DSS versions, so applicability should be confirmed against the current published standard rather than assumed.

Best practices

Deploy and maintain anti-malware and endpoint detection controls on systems that handle or can access cardholder data, recognizing that detection controls carry false-positive and false-negative trade-offs and are not guaranteed to catch every infostealer variant.
Ensure sensitive authentication data is not retained after authorization, since data that is never stored cannot be harvested from the endpoint later.
Treat session tokens and authentication cookies as sensitive, and consider controls such as shorter session lifetimes and session invalidation to help reduce the value of stolen sessions.
Apply layered authentication appropriate to the risk point, understanding that MFA, 3-D Secure, and EMV chip authentication address different risks and no single control eliminates fraud.
Reduce the footprint of stored cardholder data through appropriate transformation methods such as tokenization, truncation, or masking, validating the implementation rather than relying on the label alone.
Confirm applicable malware, endpoint, and data-protection requirements against the current published PCI DSS version rather than assuming fixed requirement numbers or wording.