A ServiceNow business rule that quietly ships records out the back
A malicious business rule runs server-side on every record operation and exfiltrates silently for days. Logging the deployer out does nothing. You have to remove the code.
ServiceNow runs your own server side code on record operations through business rules and script includes. An attacker with the right roles can hide a backdoor in that automation and never log in again.
How the attack works
An account with admin or script author rights creates a malicious business rule, backed by a script include, on a sensitive table, and wires in a server side outbound REST message to an external endpoint. From then on, every normal record insert or update fires the rule, which posts record fields out to the attacker. The exfiltration blends into routine table activity and runs silently for days, scaling with normal volume, with no anomalous interactive login. In ATT&CK terms this is T1505, Server Software Component, paired with T1213, Data from Information Repositories.
Why it works
Broad admin and script author roles let a principal create scripted objects and outbound REST directly in production. Because the backdoor is server side code rather than a session, it keeps firing on everyone else’s activity no matter what you do to the deployer’s account. There is no rogue login to detect.
How to fix it
The scenario teaches that locking the deployer’s account is the wrong move: the principal is code, so you have to remove the code. Deactivate and delete the rogue business rule, its script include, and the outbound REST message, which stops the exfiltration on the next record operation. The durable fix is to restrict admin and script roles to a minimal set, require reviewed update set promotion through environments, control outbound REST and connection records, and sweep all scripted objects for other rogue rules. The customer update set and sys_audit history show who deployed what and when, and the outbound REST and transaction logs scope which records were sent across the full multi day window.
Practice it
We built this as a GraphLattice Range scenario so responders can rehearse removing server side code persistence when there is no login anomaly to follow.