Why do attackers increasingly use legitimate SaaS and remote management tools to hide in plain sight?

Why This Matters for Security Teams

Legitimate SaaS and remote management tools are attractive to attackers because they collapse the usual signals defenders rely on. Traffic is often encrypted, permitted, and business-like, which means C2, staging, file transfer, or remote execution can blend into approved activity. That makes per-service allow listing insufficient on its own. Security teams need identity-centric visibility, because the same platform can be safe in one context and hostile in another.

NHIMG’s 52 NHI breaches Report shows how quickly trusted identities and delegated access can become an attack path when credentials, tokens, or service accounts are abused. The pattern is not that attackers invent exotic tooling. It is that they repurpose tools already trusted by the enterprise, then operate through normal channels long enough to evade single-event detections. MITRE ATT&CK provides the behavioural lens for this, especially where living-off-the-land techniques and remote services overlap with standard admin activity. In practice, many security teams discover the abuse only after an incident has already crossed from initial access into persistence or lateral movement.

How It Works in Practice

Attackers choose legitimate SaaS and remote management platforms because these services already sit inside business workflows, outbound trust, and vendor relationships. The operational advantage is simple: defenders are less likely to block sanctioned software, and many controls focus on the application rather than the identity using it. That is why the real control gap is not merely “is this tool allowed?” but “is this identity behaving as expected within this tool?”

Defensive programs should baseline activity per identity, per tenant, and per tool. That means correlating sign-in patterns, API usage, admin actions, file movement, and command execution, then flagging deviations from the normal pattern for that exact account. Where possible, enrich detections with device posture, geolocation, session risk, and privilege level. NIST Cybersecurity Framework 2.0 supports this kind of ongoing monitoring and response discipline, while CISA advisories regularly show how abused remote access and cloud collaboration services are used in real intrusions.

• Track who normally uses each SaaS or remote management platform, not just whether the platform is approved.
• Alert on first-time actions such as bulk export, new admin grants, unusual API calls, or remote shell invocation.
• Restrict high-risk functions with step-up approval or just-in-time privilege where the platform supports it.
• Bind alerts to identity, session, and device context so sanctioned traffic does not automatically imply benign use.

For NHI-heavy environments, the lesson is similar to the one emphasized in Top 10 NHI Issues: trusted access paths fail when credentials outlive their intended scope, and when the organisation cannot distinguish routine automation from misuse. These controls tend to break down in highly distributed SaaS estates because tenant logs are fragmented, admin roles are inconsistent, and one identity may legitimately perform many different actions across multiple tools.

Common Variations and Edge Cases

Tighter identity monitoring often increases operational overhead, requiring organisations to balance detection fidelity against analyst fatigue and admin friction. That tradeoff becomes more pronounced in environments with heavy outsourcing, shared service desks, or many machine accounts, where “normal” behaviour is inherently broad.

Current guidance suggests that the hardest cases are not classic malware deliveries but authorised accounts used from unexpected places, by unexpected automation, or for unexpected objectives. In some SaaS platforms, there is no universal standard yet for how much behavioural telemetry is available or how long it is retained, so teams may need compensating controls such as stronger MFA, approval workflows, and tighter role scoping. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks and NHI Lifecycle Management Guide are useful references when SaaS access is tied to non-human identities, service accounts, or delegated automation.

The edge case that frequently surprises defenders is third-party remote support and MSP tooling. These tools are often legitimately privileged, heavily trusted, and sparsely reviewed, which makes attacker activity difficult to separate from real maintenance work. That is where current guidance suggests pairing behavioural analytics with strict session logging and explicit business justification. MITRE’s enterprise matrix and NIST Cybersecurity Framework 2.0 both reinforce the need for visibility, but neither can substitute for per-identity baselines in the tools attackers most often abuse.

Related resources from NHI Mgmt Group

• What breaks when ransomware attackers can use legitimate admin tools inside the network?
• How should security teams prevent automated exfiltration when attackers use legitimate system tools and approved cloud services?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• Why can a single SaaS app create such a large blast radius?