No password to reset: NetSuite integration token abuse

When the compromised identity is an integration rather than a person, the usual playbook misfires. There is no password, no MFA, and no user to lock out.

How the attack works

A NetSuite token-based-authentication integration role, meant for a nightly finance sync, has its consumer key and token secret leaked. An attacker replays the token from a host outside the sync allowlist and outside the nightly window, then runs a series of saved searches over general-ledger transactions and vendor records far beyond the normal sync set. The session pages through transaction and customer records using the SuiteTalk web-service API at volume well above baseline, then ships the pulled records to an external collector. The NetSuite login audit trail records the source host and timing of each token use, and the web-services and SuiteScript usage logs record what was pulled. This maps to T1213, Data from Information Repositories, and T1567, Exfiltration Over Web Service.

Why it works

Token-based auth is a non-interactive credential that does not use the user’s password or MFA at all, so the integration is a standing key to the ERP. The damage was large because the integration role could read the entire general ledger and all customer records, far more than a nightly sync needs.

How to fix it

Resetting the password of the finance user the integration was set up under does nothing, because token-based auth never touches that password or MFA. The real containment is to revoke the access token and disable the integration record and its role so the leaked consumer key and token secret cannot mint a new session. Durably, re-issue the integration with a least-privilege role scoped to only the records and saved searches the sync needs, lock it to the known sync host, and rotate the leaked key material.

Practice it

We built this as a GraphLattice Range scenario so responders learn to revoke the token and scope the role, not chase a human account.