Low And Slow Intrusion

Expanded Definition

Low and slow intrusion is not a separate access model so much as an adversary operating style: the attacker deliberately reduces volume, timing, and obvious changes so activity blends into ordinary administration. In NHI security, that often means reusing valid service account credentials, token abuse, or tiny bursts of API calls instead of broad scanning or immediate payload deployment.

Definitions vary across vendors, but the core pattern is consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls concepts such as monitoring, access control, and auditability. The operational challenge is that low-frequency malicious actions can look like routine automation unless identity, context, and sequence are analyzed together. That is why NHI governance must account for credential lifetime, expected usage windows, and tool access rather than just login success. The most common misapplication is treating low event volume as low risk, which occurs when defenders ignore valid-but-abused service identities or long-lived secrets.

See also Ultimate Guide to NHIs for the governance context that makes this attack style especially difficult to spot.

Examples and Use Cases

Implementing detection for low and slow intrusion rigorously often introduces more telemetry correlation work, requiring organisations to weigh stronger detection against alert tuning and analyst time.

• A compromised API key is used once a day to enumerate a small set of cloud resources, avoiding threshold-based anomaly rules.
• A service account performs normal-looking read operations for weeks before the attacker uses it to access a sensitive secrets store.
• Attackers pivot through a CI/CD automation identity, making only minimal changes to pipeline jobs so review teams see routine maintenance.
• A trusted integration token is used intermittently to query internal endpoints, matching the cadence of legitimate application traffic.
• Long-lived credentials are abused from a familiar workload location, so network controls do not flag a sudden geographic or device shift.

For NHI teams, the practical lesson aligns with the identity-first guidance in Ultimate Guide to NHIs: the attacker succeeds by staying within the bounds of what appears operationally normal. Detection also benefits from event-handling patterns described in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially logging and continuous monitoring.

Why It Matters in NHI Security

Low and slow intrusion is dangerous because it exploits the exact trust assumptions that NHI programmes rely on: persistent access, delegated authority, and machine-to-machine continuity. When NHIs are overprivileged, weakly rotated, or poorly inventoried, an attacker can remain inside the environment while making only small, legitimate-looking moves. NHIMG research shows that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which broadens the blast radius of a quiet compromise.

This is why defenders need more than perimeter alerts. They need secret hygiene, short credential lifetimes, service-account visibility, and logs that connect identity to action over time. A low-and-slow actor often depends on the gap between authentication and accountability: the access is valid, but the purpose is not. Mapping controls to NIST SP 800-53 Rev 5 Security and Privacy Controls helps translate that concern into monitoring, least privilege, and anomaly detection requirements. Organisations typically encounter the real cost only after a sensitive system has been quietly queried or exfiltrated for weeks, at which point low and slow intrusion becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do fixed traffic rules miss low-and-slow attacks?
• What do security teams get wrong about low-and-slow application probing?
• What do security teams get wrong about low-and-slow login attacks?
• Low-and-slow probing