Data exfiltration persists through insiders, supply chains and leaks

At a glance

What this is: This article explains common data exfiltration methods, distinguishes leakage from deliberate exfiltration, and cites insider and supply-chain incidents as examples.

Why it matters: It matters because exfiltration often succeeds through weak data-flow controls, which also affects identity and access governance wherever credentials, users, vendors, or scripts can move sensitive information out of scope.

By the numbers:

• Nearly 500 organizations and 24 million individuals were exposed through the mass exploitation of the MOVEit vulnerability.
• At least 136 organizations that did not use MOVEit directly were exposed through third-party vendors.

👉 Read Jscrambler's analysis of common data exfiltration methods and prevention

Context

Data exfiltration is the intentional copying or transfer of sensitive information out of an organisation’s environment. Data leakage is broader and usually starts with exposure caused by weakness, misconfiguration, or unsafe behaviour. In practice, leaked data often becomes the starting point for exfiltration when attackers, insiders, or third parties can move it beyond the original trust boundary. This is also an identity problem when credentials, privileged sessions, or vendor access create the path out.

The article is strongest when read as a control-gap discussion rather than a product note. It shows that exfiltration is not just about malware or perimeter compromise, but about whether an organisation can detect abnormal transfer, restrict script behaviour, and trace which identities or integrations had access before data left scope. That pattern is common across modern environments, especially where SaaS, third parties, and client-side code all touch sensitive data.

Key questions

Q: How should security teams reduce data exfiltration risk in environments with many trusted users and vendors?

A: Start by identifying which identities can legitimately access sensitive data and which of those can also move it out of approved channels. Then restrict copy, print, upload, and export paths, add behavioural monitoring for unusual transfer patterns, and enforce lifecycle review for vendor and privileged accounts. Exfiltration becomes harder when access and movement are governed together.

Q: Why do third-party integrations increase the risk of secret exposure?

A: Third-party integrations increase risk because they often move data across systems that were never designed as credential stores. If API keys, tokens, or passwords are embedded inside application records, attackers can discover and reuse them through normal app access. The result is a data governance problem that becomes an identity problem the moment secrets can be replayed elsewhere.

Q: What do organisations get wrong about preventing data exfiltration?

A: They often focus on perimeter controls and overlook the point where data is actually used. Sensitive information can be copied by insiders, moved through browser sessions, or transferred through legitimate integrations long before traditional alerts fire. Effective defence needs data-flow monitoring, identity context, and controls on client-side behaviour, not only network filtering.

Q: How do security teams know if exfiltration controls are actually working?

A: Look for evidence that bulk file access, compression, and outbound staging are detected early and correlated with privileged sessions. If teams only see the breach after a leak site post, the control failed. Effective monitoring should surface unusual data movement before attackers can weaponise it.

Technical breakdown

Leakage versus exfiltration: why the distinction matters

Data leakage and data exfiltration are related but not identical. Leakage is exposure caused by a weakness, such as a misconfiguration, vulnerable application, or unsafe client-side behaviour. Exfiltration is the deliberate removal of data by an attacker, insider, or compromised identity. The distinction matters because a leak may be the opening condition, but exfiltration is the action that turns exposure into loss. Control design therefore has to cover both prevention and detection, including telemetry on where data is rendered, copied, submitted, or transferred.

Practical implication: map both exposure paths and transfer paths, because preventing exfiltration requires controls on movement, not only on access.

How insiders, phishing and third parties move data out

Common exfiltration paths include insiders, social engineering, phishing, and uploads to external devices or services. These methods work because legitimate access exists first, then the attacker or malicious user repurposes that access to copy data outward. In supply-chain cases, the path may pass through a vendor or downstream integration rather than a direct compromise. That makes identity, entitlement, and session monitoring central, because the question becomes which user, service, or third party was trusted to touch the data before it was removed.

Practical implication: monitor privileged users, vendor accounts, and high-risk sessions for abnormal transfer patterns and off-platform destinations.

Why client-side script control is part of exfiltration defense

The article’s prevention section points to webpage integrity, script behaviour control, continuous protection, and alerting. That reflects an important reality: sensitive data can be stolen before it is fully committed to a backend control plane, especially through forms, injected scripts, or altered page logic. This is a browser and application integrity problem as much as a data problem. If malicious code can observe or alter what users submit, exfiltration can happen even when server-side access controls remain intact.

Practical implication: treat browser-side integrity and script monitoring as part of data-loss prevention, especially for forms that handle credentials or personal data.

Threat narrative

Attacker objective: The attacker wants to move sensitive data outside organisational control for theft, resale, coercion, or downstream misuse.

1. Entry occurs through a trusted user, compromised insider, phishing event, or third-party pathway that already has access to sensitive data.
2. Escalation happens when the actor copies, prints, uploads, or forwards the data outside approved channels instead of using it inside the business process.
3. Impact is achieved when customer records, credentials, financial data, or intellectual property leave the environment without detection or timely containment.

NHI Mgmt Group analysis

Data exfiltration is an identity-governance problem when legitimate access becomes the transport layer. The article correctly separates leakage from deliberate theft, but the practical risk is that users, vendors, and service identities can all become export mechanisms once access exists. That is why identity lifecycle, entitlement scope, and session visibility matter as much as endpoint or network controls. Practitioners should treat exfiltration as a governance failure over who can move data, not only who can read it.

Third-party pathways now create the most dangerous blind spots in exfiltration control. The MOVEit example is a reminder that downstream exposure can be broader than the original target because partner access expands the blast radius. In identity terms, third-party accounts and delegated integrations need the same scrutiny as internal privileged users, including lifecycle offboarding and least-privilege review. The practitioner conclusion is simple: vendor access cannot remain a static trust assumption.

Browser-side integrity is an underused control plane for sensitive-data protection. The article’s emphasis on webpage integrity and script monitoring points to a real shift in exfiltration tradecraft, where data is stolen at the point of interaction rather than after backend compromise. That means client-side code, form handling, and dynamic script behaviour deserve security telemetry, especially for payment, credential, and personal data workflows. Practitioners should align application security with data-loss controls instead of treating them as separate disciplines.

Continuous monitoring is more valuable than retrospective reporting once exfiltration starts. The article’s detection, alerting, and audit themes reflect the fact that exfiltration is often fast and low-noise compared with destructive attacks. The named concept here is export-path governance: the ability to define, monitor, and constrain where sensitive data is allowed to go after it enters the business process. Teams that cannot trace export paths will struggle to prove containment or quantify impact, so they should build those traces into policy and logging.

What this signals

Export-path governance is becoming the practical control model for data exfiltration, because organisations need to know not only who can see data but also who can move it. That is especially true where third-party access, service identities, and browser-side workflows intersect. For identity teams, this shifts the programme from static entitlement review toward continuous visibility into data movement, supported by concepts in the Guide to the Secret Sprawl Challenge.

The strongest signal for practitioners is that exfiltration prevention now sits at the boundary between IAM, application security, and data controls. When data is handled through scripts, vendors, or delegated access, policy has to follow the transaction instead of the infrastructure alone. For teams using NIST-style control mappings, NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful anchor for auditability, access control, and monitoring.

For practitioners

• Map export paths for sensitive data Document where credentials, customer records, financial data, and intellectual property can be copied, printed, uploaded, or forwarded, then flag any route that crosses a trust boundary without logging.
• Tighten third-party access governance Review vendor accounts, delegated integrations, and OAuth-style connections for scope creep, inactive access, and missing offboarding so third parties cannot become silent exfiltration channels.
• Monitor browser-side script behaviour Add controls that detect injected or abnormal scripts on sensitive webpages, especially forms that collect credentials or regulated data, because exfiltration may begin before server-side validation completes.
• Correlate data movement with identity context Join endpoint, application, and identity logs so investigators can see which user, service account, or vendor identity touched data immediately before unusual transfer activity.
• Test incident containment for data removal scenarios Run exercises that assume the attacker already has legitimate access and focus on stopping transfer, preserving evidence, and determining whether the export was partial or complete.

Key takeaways

• Data exfiltration is not just a malware problem, because insiders, vendors, and browser-side workflows can all become the transfer path.
• The MOVEit and SunTrust examples show that legitimate access can become the mechanism of loss when export paths are not governed.
• Practitioners need identity-linked data-flow visibility, third-party lifecycle control, and script-integrity monitoring to contain exfiltration effectively.

Key terms

• Data exfiltration risk: Data exfiltration risk is the possibility that sensitive information leaves approved systems and enters an environment the organisation does not control. With Shadow AI, that often happens through ordinary user behaviour, which makes identity governance and data governance tightly linked rather than separate problems.
• Data Leakage Loop: A data leakage loop is a repeated exposure pattern where sensitive information enters an AI interaction, gets retained or indexed, and later reappears in unrelated responses or contexts. The danger is cumulative persistence, not a single failed request.
• Export-Path Governance: Export-path governance is the control discipline for monitoring and constraining where sensitive data can go after it has been accessed. It combines identity context, data-flow monitoring, and policy enforcement so organisations can see and limit copying, uploading, printing, and forwarding.
• Client-Side Integrity: Client-side integrity is the assurance that browser or application code shown to users has not been altered to capture or divert sensitive data. It matters when forms, scripts, or page logic can be manipulated before server-side controls receive the information.

What's in the full article

Jscrambler's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step prevention guidance for webpage integrity and continuous protection in form-based workflows
• The specific detection and alerting approach used to identify unusual or unauthorized data transfer patterns
• How control script behaviour is used to spot misconfigurations and suspicious client-side activity
• The article's reporting and audit workflow for documenting issues, recommended actions, and mitigation steps

👉 The full Jscrambler article covers the detection, script-control, and audit detail behind these exfiltration examples.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and identity lifecycle control. It helps practitioners connect identity decisions to the broader security and governance issues that drive exposure.