Lockheed Martin, Boeing and the 2025 Infostealer Threat: When Stolen Credentials Become a Data Exfiltration Problem
Lockheed Martin, Boeing and the 2025 Infostealer Threat: When Stolen Credentials Become a Data Exfiltration Problem
In February 2025, cybersecurity firm Hudson Rock published research that cut through a lot of enterprise security assumptions. Their findings: employees associated with Lockheed Martin, Boeing, Honeywell, and multiple U.S. military and government organizations had appeared in infostealer data. Stolen credentials, session cookies, VPN logins, and internal tool access — all of it available on cybercrime marketplaces for as little as $10 per log.
This was not a confirmed enterprise-wide breach at each named organization. That distinction matters, and we will explain exactly why. But the exposure documented by Hudson Rock illustrates something more important than a single breach headline: what happens after credentials are stolen, and why authentication failure is only the beginning of the problem.
What Happened in the 2025 Defense-Sector Infostealer Exposure
On February 17, 2025, Hudson Rock published findings from its analysis of cybercrime marketplace data. The firm identified active infostealer infections associated with employees at some of the most sensitive organizations in U.S. defense and government.
The data showed credentials, browser-stored passwords, VPN access tokens, session cookies, and internal application logins circulating in stealer logs tied to employee devices.
Lockheed Martin, Boeing, and Other Defense Contractors
Hudson Rock’s research identified infostealer-associated data linked to employees across several major contractors:
| Organization | Reported Infected Employees | What Was Potentially Exposed |
|---|---|---|
| Honeywell | 398 | Internal intranet, ADFS/SSO, IAM tools, Microsoft/Cisco/SAP integrations, third-party credentials |
| Boeing | 66 | Corporate credentials, internal system access |
| Lockheed Martin | 55 | Corporate credentials, internal system access |
| Leidos | 55 | Corporate credentials |
| BAE Systems | Reported | Corporate credentials |
| L3Harris | Reported | Corporate credentials |
The Honeywell case was the most documented. Hudson Rock reported that a single 30-year veteran engineer had 56 corporate credentials and 45 third-party credentials compromised. That one infection exposed not just the individual’s access but integrations with outside systems and partners.
U.S. Military and Government Accounts Were Exposed Too
The exposure was not limited to private contractors.
| Organization | Reported Scope | What Was Potentially Exposed |
|---|---|---|
| U.S. Army | 70+ infected employees, 1,300+ total users | VPN access, email, procurement portals |
| U.S. Navy | 30+ infected employees, 550+ users | Login credentials, military training platforms |
| FBI | Active infections reported | Investigative and cybersecurity personnel credentials |
| GAO | Active infections reported | Staff credentials |
Hudson Rock reported that Navy-associated stealer logs included credentials for military training platforms such as USALearning.gov and security integrations. The research noted that 256 third-party credentials were also exposed in Navy-connected data.
These are not obscure systems. VPN access, procurement portals, and development tools connected to defense infrastructure represent serious potential exposure if those credentials were successfully used downstream.
Infostealer Exposure Is Not the Same as a Corporate Data Breach
This distinction gets lost in most breach coverage. The Hudson Rock findings documented credential exposure through infostealer infections. That is not the same as confirming that Lockheed Martin or Boeing experienced network-wide intrusions.
Understanding why this matters requires understanding the actual attack chain.
Device Infection
Malware lands on an endpoint. The employee may not know it happened. The corporate security team may not see it, especially if the device is personal.
Credential Exposure
The infostealer collects saved passwords, browser credentials, cookies, and tokens from the infected device and packages them into a stealer log. That log can be sold or distributed on cybercrime marketplaces.
Account Compromise
A threat actor purchases or obtains the log and successfully authenticates using the stolen credentials. This step is not guaranteed but becomes significantly more likely when session cookies bypass MFA.
Enterprise Intrusion
The threat actor uses compromised account access to reach corporate resources — internal tools, file repositories, cloud environments.
Data Exfiltration
Sensitive data is identified, staged, and transferred outside controlled environments.
These stages are related, but they are not interchangeable.
The Hudson Rock research documents the first two stages across a wide range of defense-sector organizations. That is significant on its own. The downstream stages — intrusion and exfiltration — depend on whether those credentials were successfully used, which is a separate question from whether they were stolen.
What Is Infostealer Malware and How Does It Work
Infostealers are a specific category of malware designed to harvest authentication material from infected endpoints as quickly and quietly as possible. Hudson Rock estimates over 30 million computers have been infected by infostealers in recent years, with roughly one in five infected devices containing corporate credentials.
Initial Infection
Infostealers reach endpoints through a narrow set of delivery mechanisms, and most of them involve an ordinary human decision:
- Downloading pirated software or commercial software cracks
- Installing game mods from unverified sources
- Opening infected PDF attachments from phishing emails
- Running fake software installers
- Installing malicious browser extensions
- Clicking malicious ads (malvertising)
- Social engineering that leads to a malicious download
Hudson Rock specifically cited game mods, pirated software cracks, and infected PDFs as common infection vectors in their defense-sector findings. A defense engineer downloading a cracked application on a personal machine used for work can expose corporate credentials with no interaction from the employer’s security team.
Credential and Browser Data Collection
Once installed, infostealers move fast. They target:
- Saved usernames and passwords from browser credential stores
- Autofill data
- Browsing history
- Active and saved session cookies
- VPN credentials
- Corporate email account credentials
- Developer platform credentials (GitHub, Jira, Confluence)
- Enterprise SaaS application logins
- Internal application tokens
The harvest typically happens within minutes. The resulting data is packaged into a stealer log and exfiltrated from the device.
What Is a Stealer Log?
A stealer log is a structured data package produced by an infostealer containing everything the malware collected from an infected machine. Logs typically include credential pairs (usernames and passwords), cookies, browser data, and metadata about the infected device and its applications.
These logs are sold on cybercrime marketplaces, often in bulk. Hudson Rock reported that logs tied to defense contractor and military employee devices were available for as little as $10 per machine. Buyers can search marketplace listings by corporate domain, application type, or geographic region, making targeted acquisition of specific organizational credentials operationally straightforward for a motivated threat actor.
A single stealer log can contain dozens of credential sets from one employee. In the Honeywell case, one engineer’s log contained over 100 separate credentials.
Why Session Cookies Make Infostealers Especially Dangerous
Most cybersecurity conversation around credential theft focuses on passwords. Infostealers create a more serious problem: they steal active session cookies.
The difference matters.
A stolen password is dangerous but manageable. If you know a password was compromised, you reset it. MFA provides a meaningful checkpoint before account access is granted.
A stolen active session cookie is different. That cookie represents an already-authenticated session. The MFA challenge has already been passed. Resetting the password may not invalidate an active session token depending on how the application handles session lifecycle.
Can Infostealers Bypass MFA?
MFA substantially reduces account-compromise risk. It is not a complete defense against infostealers.
Hudson Rock specifically reported that stealer logs from defense-sector infections included active session cookies that could allow session hijacking and bypass normal MFA authentication challenges. Here is why:
- Session theft: The cookie represents a completed authentication, not a credential. Using it does not trigger a new MFA challenge.
- Token theft: Authentication tokens issued after successful MFA can be harvested separately from the password itself.
- Already-authenticated browsers: If the browser session is active when the infostealer runs, the cookie it captures may still be valid.
- MFA fatigue: Some attacks pair stolen credentials with push notification bombing to wear down the user.
- Recovery mechanisms: Password reset flows and account recovery options can sometimes be exploited independently of MFA.
The practical implication: credential rotation after an infostealer infection needs to include session revocation, not just password resets. We address that specifically in the remediation section below.
From a $10 Stealer Log to Enterprise Access
The Hudson Rock findings documented credentials available on open cybercrime marketplaces at extremely low price points. A motivated threat actor with basic operational knowledge can move from purchasing a stealer log to attempting enterprise access quickly.
Here is how that progression looks in practice:
Employee device infected → credentials and session cookies harvested → stealer log created and sold → credentials tested against corporate applications → successful authentication achieved → internal resource discovery begins → sensitive files and systems identified → data staged for transfer → exfiltration to external destination
Each arrow in that chain represents an opportunity for detection and disruption. But the chain only needs to succeed once to create a significant incident.
The attack does not require nation-state resources or sophisticated custom tooling at the intrusion stage. The infostealer handles the technically demanding work. What follows is closer to credential stuffing than an advanced persistent threat.
The Real Risk Is Not the Password. It Is What the Password Can Reach.
This is where most infostealer coverage stops being useful to enterprise security teams.
The credential is a key. The actual risk depends on what the key opens.
In a defense contractor environment, employee credentials can potentially reach:
- Engineering drawings and CAD files
- Software source code and build systems
- Intellectual property and research data
- Manufacturing process documentation
- Government contract documents
- Procurement system data
- Classified or controlled project materials
- Cloud storage environments
- Internal communication archives
- Large file repositories used for media, sensor data, or test results
Credential security asks whether an attacker can impersonate a user.
Data security asks what that user is permitted to access.
File security asks what happens to the data after access is granted.
Those are three separate questions that require three separate control layers. Most breach discussions stop at the first one.
Why the Honeywell Findings Make This a Supply Chain Story
The Honeywell data in Hudson Rock’s research introduced a dimension that affects organizations far beyond those named in the report.
Hudson Rock reported 472 third-party corporate credentials exposed in the Honeywell-connected data, including credentials associated with outside organizations and integrations. A 30-year Honeywell engineer’s device contained credentials for Microsoft, Cisco, and SAP integrations alongside internal Honeywell systems.
That third-party credential exposure is the supply chain problem.
Third-Party Credentials Expand the Blast Radius
A threat actor with a stealer log from a defense contractor employee does not only gain access to that contractor’s systems. They may also gain access to:
- Supplier portals
- Systems integrator platforms
- Managed service provider tools
- Consultant access credentials
- SaaS vendor environments shared across the supply chain
- Partner file-sharing platforms
The blast radius of a single infostealer infection extends as far as the infected employee’s credential footprint.
Your Own Endpoints May Not Be the Weakest Link
An organization can enforce strong endpoint controls, maintain excellent patch hygiene, and still inherit credential risk through trusted third-party relationships. If a supplier’s employee is infected and that supplier has credentials for your shared project environment, your internal security posture does not protect you from that exposure.
This is the core argument for zero-trust architecture applied to file access and data movement, not just network perimeter controls. Least privilege at the data layer matters independently of perimeter strength.
Personal Devices and BYOD Create a Security Blind Spot
Corporate EDR tools protect corporate-managed devices. They cannot see a personal laptop.
Consider this scenario:
- An employee signs into a corporate SaaS application from their home laptop.
- The browser saves the password.
- The employee later downloads software unrelated to work — a game, a cracked utility, a browser extension — that contains infostealer malware.
- The infostealer harvests all browser-stored credentials, including the corporate SaaS password and any active session cookies.
- The employer’s EDR platform never sees the infected device. No alert fires. No log entry is created.
The corporate credential is now in a stealer log regardless of how well the employer managed its own fleet.
BYOD policies that allow corporate application access on personal devices create an attack surface that endpoint detection cannot fully address. Controlling what those credentials can access and what they can transfer becomes the meaningful control layer.
What Happens After Stolen Credentials Provide Access
Assuming a threat actor successfully authenticates using stolen credentials, the post-access phase follows a predictable pattern.
Discovery
The threat actor determines what resources the compromised account can reach:
- File repositories and SharePoint environments
- Cloud storage (S3, Azure Blob, Google Cloud Storage)
- Development systems and code repositories
- FTP/SFTP endpoints used for file transfer workflows
- Collaboration platforms
- Internal databases and procurement systems
Collection
High-value files are identified. Engineering files, contracts, source code, and large datasets are common targets in defense contractor environments.
Staging
Files may be aggregated, compressed, or temporarily collected in a location from which transfer is operationally easier.
Exfiltration
Data is transferred to a destination outside the organization’s controlled environment. The transfer method may use legitimate-looking protocols, cloud sync tools, or approved file-transfer channels if the threat actor has access to them through the compromised account.
Successful authentication should never mean unrestricted file movement. That principle is the basis for controlling what happens at the data layer even when credential security fails.
Why Password Resets Alone May Not Be Enough
A common response to infostealer exposure is to reset the affected employee’s password. That is a necessary step. It is not sufficient.
Here is why:
- Active session cookies may remain valid after a password reset depending on application configuration
- Authentication tokens issued before the reset may still be active
- OAuth grants connected to the account are not automatically revoked
- API credentials stored separately from the main account credential are not affected by a password reset
- Third-party integrations with their own access tokens require separate revocation
A comprehensive post-infostealer remediation covers:
- Reimage or isolate the infected endpoint
- Reset all passwords associated with accounts stored on the device
- Revoke all active sessions across applications
- Revoke and rotate refresh tokens
- Rotate API credentials and service account keys
- Review and revoke OAuth application grants
- Force reauthentication on all connected devices
- Review authentication logs for access since the estimated infection date
- Review files accessed by the compromised account
- Review download history and file transfer activity
- Investigate third-party systems accessible through the account
- Check for new OAuth grants or application connections made after infection
- Continue monitoring for post-compromise activity for 30 to 90 days
- Assess whether endpoint reimaging revealed additional malware or persistence mechanisms
- Brief the affected employee on infection vectors and updated security hygiene
This is not a checklist most organizations have fully operationalized. The Hudson Rock findings suggest that infected employees at major defense contractors may have gone undetected for extended periods.
How Organizations Can Contain an Infostealer Incident
Prevention matters. Containment planning matters more, because infostealers succeed regularly even against well-resourced organizations.
Identify and Isolate the Endpoint
Determine which device was infected and remove it from network access before remediation begins. Do not rely on the employee’s self-report for infection timing. Check EDR telemetry and stealer log metadata if available.
Rotate Credentials and Revoke Sessions
Follow the full rotation checklist above. Password reset without session revocation leaves the door open.
Apply Least-Privilege Access
Review what the compromised account could access and reduce it to what the role actually requires. This limits blast radius for future incidents and may reveal over-provisioned access that predates the infection.
Identify Sensitive Data the User Could Access
Map the files, repositories, and systems the compromised account could reach. This informs both the risk assessment and the scope of the investigation.
Audit File Downloads and Transfer Activity
Review logs for bulk downloads, unusual file access patterns, or transfers to external destinations. Look for access patterns that differ from the employee’s normal behavior.
Restrict Unapproved Transfer Destinations
Enterprise file transfer workflows should operate through defined, controlled channels. Ad-hoc transfers using personal cloud storage, consumer file-sharing tools, or unapproved SaaS applications are exactly how data moves outside monitored paths.
Monitor for Bulk or Abnormal Data Movement
Anomaly detection on file access and transfer volume provides earlier warning than signature-based tools. A compromised account accessing 500 engineering files in four hours looks different from normal usage patterns.
Investigate Third-Party Accounts and Integrations
The stealer log may contain credentials for partner systems and integrations. Those third parties should be notified to review their own access logs.
Continue Monitoring After Credential Rotation
Post-compromise activity can occur weeks after the initial infection if persistence mechanisms survived remediation or if the threat actor was methodical in staging access. Treat the 90 days following an infostealer incident as an elevated monitoring period.
File Security Should Assume Credentials Will Eventually Be Compromised
This is a shift in thinking that traditional perimeter-focused security models resist. It is also accurate.
The older model: keep attackers out. If authentication is strong and perimeter controls are solid, data is protected.
The more resilient model: keep attackers out, and limit what compromised identities can do, and restrict what data can leave.
Defense-in-depth at the data layer includes:
- Least privilege: Accounts access only what they need. Compromised credentials inherit only that scope.
- Data classification: Sensitive files are tagged and subject to additional access controls based on classification.
- Controlled transfer paths: Files move through defined workflows with authentication, authorization, and audit trails.
- Egress monitoring: Transfers to external destinations are logged and anomalous patterns trigger review.
- Destination controls: Known, approved destinations for file movement. Transfers to unapproved endpoints require additional authorization or are blocked.
- Encryption in transit: Data in transfer is protected against interception even when credentials are compromised.
- Malware scanning: Incoming files are scanned before they enter trusted workflows, preventing infostealer-laden content from entering controlled environments.
PacGenesis specializes in IBM Aspera-based enterprise file transfer workflows that incorporate access controls, transfer auditing, and integration with enterprise security tooling. The architecture supports exactly the kind of layered data-layer defense that infostealer-era threat models require.
Secure File Transfer as a Containment Control
IBM Aspera is not an infostealer prevention tool. No file transfer solution is.
What enterprise file transfer architecture does provide is a controlled, auditable channel for data movement. That matters for infostealer containment because the exfiltration stage of the attack chain depends on files being transferable through some channel. When legitimate file movement occurs through defined workflows, anomalous transfers become visible against that baseline.
Organizations that centralize large-file movement through enterprise transfer platforms gain:
- Known transfer workflows: Defined sources, destinations, and authorization requirements
- Authentication and authorization at the transfer layer: Not just at login
- Full audit trails: Who transferred what, when, and where
- Encryption in transit: Protection against interception during transfer
- Integration with security monitoring: Transfer activity logs that feed into SIEM and anomaly detection
If a compromised account attempts to exfiltrate 50 gigabytes of engineering files to an unrecognized external destination, a controlled transfer environment makes that action visible. An environment where files can move through any number of ad-hoc channels makes that same action much harder to detect.
Learn more about malware protection in enterprise file transfers
Scan Files Before They Enter Trusted Workflows
The infostealer threat runs in both directions. Organizations focused on preventing credential theft also need to think about the content entering their environments.
A file delivered to a defense contractor through a supplier portal, a shared project workspace, or an Aspera ingestion workflow is trusted the moment it clears authentication. If that file contains malware, it enters the controlled environment through an authorized channel.
PacGenesis integrates Trend Micro Vision One File Security into Aspera ingestion workflows specifically to address this problem. Files are scanned for malware, ransomware, trojans, spyware, and polymorphic variants before they are processed or stored, and suspicious content is quarantined rather than allowed to propagate.
Trend Micro File Storage Security can scan content without removing it from cloud storage environments, maintaining workflow continuity while applying detection at the content layer. Network Security components can inspect ingress and egress traffic, adding detection coverage at the transfer layer itself.
Enterprise file malware scanning with Trend Micro Vision One File Security
Trend Micro Cloud One suite of offerings
The 2023 Boeing LockBit Attack Was a Different Incident
When searching for Boeing cybersecurity news, the 2023 LockBit ransomware attack appears prominently. It is a separate incident with a separate attack path.
In October 2023, LockBit ransomware operators breached Boeing’s parts and distribution business. The group demanded a reported $200 million ransom, one of the largest ransom demands publicly documented at the time. Boeing refused to pay. LockBit subsequently published approximately 43 gigabytes of data allegedly taken from Boeing’s systems, including management software configurations, monitoring logs, and auditing tools.
Boeing confirmed the incident impacted elements of its parts and distribution operations. The company stated it did not affect flight safety.
The attack vector in the 2023 LockBit incident was separate from infostealer credential theft. Security researchers identified potential exploitation of CVE-2023-4966, a Citrix vulnerability sometimes called “Citrix Bleed,” as a possible entry point.
The common thread between the 2023 ransomware incident and the 2025 infostealer findings is not the attack method. It is the attacker’s consistent interest in the data defense contractors hold.
The 2026 Lockheed Martin Claims Are Also a Separate Story
Searches for Lockheed Martin cybersecurity incidents in 2026 may return results related to separate claims involving threat actors using the names APT Iran or Handala.
Those reports are distinct from the Hudson Rock infostealer research published in February 2025.
2025 Hudson Rock findings: Infostealer infections associated with defense contractor and military employees, resulting in credential and session data appearing in cybercrime marketplace logs.
2026 APT Iran/Handala claims: Separate publicly reported allegations involving different threat actors, different claimed attack methods, and different reported targets.
Do not conflate them. They involve different incidents, different attribution, and different evidence bases.
What Security Teams Should Do When an Employee Appears in a Stealer Log
If your organization identifies an employee’s credentials in a stealer log — through threat intelligence services, law enforcement notification, or Hudson Rock-style research — this is the recommended response sequence:
- Confirm the affected endpoint
- Disconnect or isolate it immediately
- Reimage or thoroughly remediate the system
- Identify all credentials stored or used on the device
- Reset passwords for all affected accounts
- Revoke all active sessions
- Rotate API keys and application credentials
- Review MFA configuration and registered devices
- Audit OAuth permissions and application grants
- Examine authentication logs from the estimated infection date forward
- Review files accessed after the infection
- Identify unusual or bulk download activity
- Audit outbound file transfers during the exposure window
- Review third-party systems accessible through the compromised account
- Continue monitoring for post-compromise activity for at least 90 days
Lessons From the 2025 Defense Infostealer Exposure
The Hudson Rock findings were alarming in their scope. They were not surprising to anyone who tracks the infostealer market seriously.
Infostealers succeed because they exploit human behavior at scale. No security budget eliminates the risk that an employee will download compromised software on a device they also use for work. The infection vectors are mundane. The downstream consequences are not.
What the defense sector exposure illustrates is that credential theft is not the endpoint of the attack. It is the beginning. The chain that follows — from stealer log to authenticated access to data discovery to exfiltration — runs through the data layer, not just the identity layer.
Endpoint protection limits initial infection risk.
Identity protection limits what compromised credentials can do.
Data-access control limits what an authenticated session can reach.
Secure file movement limits what can leave.
Egress control limits where it can go.
These are not redundant layers. Each one provides a control point that the others do not. And increasingly, as AI agents, machine identities, and autonomous data movement become standard parts of enterprise infrastructure, the principle at the center of all of them matters more than it ever has:
An identity’s ability to authenticate should not automatically grant unlimited ability to move data.
Frequently Asked Questions
What is infostealer malware? Infostealer malware is a category of malicious software designed to harvest authentication material from infected devices, including saved passwords, session cookies, browser credentials, and VPN tokens. The harvested data is packaged into stealer logs and sold on cybercrime marketplaces.
What data does infostealer malware steal? Infostealers typically collect saved usernames and passwords, browser autofill data, active session cookies, VPN credentials, corporate application credentials, developer platform tokens, and browsing history. A single infected device can yield dozens of separate credential sets.
What is a stealer log? A stealer log is a data package produced by infostealer malware containing the credentials, cookies, and browser data collected from an infected device. These logs are sold on cybercrime marketplaces, often for as little as $10 per log, and can be searched by corporate domain or application type.
Can infostealers bypass MFA? MFA significantly reduces account-compromise risk but does not fully neutralize infostealer threats. Infostealers can capture active session cookies that represent already-authenticated sessions, bypassing the MFA checkpoint. They can also harvest authentication tokens issued after successful MFA completion.
Is resetting a password enough after an infostealer infection? No. Password reset is a necessary first step but does not revoke active sessions, invalidate authentication tokens, cancel OAuth grants, or rotate API credentials. A complete remediation requires all of those steps plus endpoint reimaging and extended post-compromise monitoring.
What happened to Boeing in the 2025 infostealer findings? Hudson Rock reported that credentials associated with approximately 66 Boeing employees appeared in infostealer data. This reflects credential and session data harvested from infected employee devices, not a confirmed enterprise-wide breach of Boeing’s network.
Was Lockheed Martin breached by infostealer malware in 2025? Hudson Rock’s research found credentials associated with approximately 55 Lockheed Martin employees in infostealer data. This documents credential exposure at the device level. It does not confirm that Lockheed Martin’s enterprise network was successfully penetrated using those credentials.
How do companies detect infostealer infections? Detection sources include endpoint detection and response tools (when the infected device is corporate-managed), threat intelligence services that monitor cybercrime marketplaces for organizational domains, law enforcement notifications, and infostealer intelligence platforms like Hudson Rock’s. Personal devices used for work often fall outside corporate EDR visibility.
How can organizations protect against infostealer malware? Layered controls are necessary: strong endpoint hygiene, least-privilege access for all accounts, short-lived authentication tokens with aggressive session timeouts, MFA across all applications, prohibition of personal device access to corporate applications where possible, threat intelligence monitoring for credential exposure, and regular review of OAuth grants and third-party integrations.
Why are defense contractors attractive targets for infostealers? Defense contractors hold extremely high-value data — engineering designs, military technology specifications, government contract documents, and access to government networks and procurement systems. Credentials that reach that data can be used directly or sold to threat actors willing to pay a premium for defense-sector access.
How can stolen credentials lead to data exfiltration? Stolen credentials provide authenticated access to corporate applications. From there, a threat actor follows a predictable sequence: discovery of accessible resources, identification of high-value files, staging of target data, and transfer to an external destination. Controlling what authenticated sessions can access and transfer limits the damage from credential theft at each stage of that chain.



