Detect direct connections to virtual machines by monitoring authentication, remote access, and network flow logs for management traffic that bypasses approved bastions or session gateways. Flag first-time source hosts, unusual geographies, and privileged logons outside normal maintenance windows. Confirm whether the connection came from an authorised administrator, automation account, or compromised identity.
What counts as a direct cloud VM connection?
A direct VM connection is any management-session path that reaches the instance without going through the approved control point, such as a bastion host, session gateway, or similar access broker. The signal is not just “remote login happened”, it is “remote login happened from somewhere that should not normally touch the VM directly”.
That distinction matters because the same SSH, RDP, or agent-based management traffic can be legitimate during maintenance, but suspicious when it appears from a new source host, a strange region, or an identity that does not normally administer the workload. The detection problem is therefore partly network-based and partly identity-based.
Security teams should treat the control plane and the login path as separate questions. A session can be technically valid and still be operationally abnormal if it bypasses the standard access route, arrives outside the expected window, or uses an account that does not match the change ticket or automation pattern.
Which logs and signals expose the bypass?
The most useful telemetry is a combination of authentication logs, remote access logs, and network flow data. Authentication logs show who authenticated, with what account, and from where. Remote access logs show whether the session reached the VM through an approved entry point. Flow logs and firewall records show whether management ports were reached directly from unexpected sources.
Look for first-seen source hosts, source IPs that do not map to the normal admin network, and geographies that do not match the team’s operating pattern. Also watch for privileged logons that happen at unusual times, especially when they do not align with maintenance windows or known automation schedules.
The strongest detections combine these signals rather than using any one of them alone. A login from a known administrator may still be suspicious if it comes from an unapproved network path. Likewise, a normal source subnet may still be concerning if the identity behind the session is an automation account that should never be interactive.
For cloud teams, the practical question is whether the session path reflects the intended architecture. NHIMG’s Cloud Security Guide is a useful reference point for the surrounding cloud controls that make these detections easier to interpret.
How do you separate legitimate administration from suspicious access?
Start by comparing the session against the expected operator, source, and timing profile. A valid administrative session should line up with a known administrator, a managed jump path, and a documented reason for access. If any one of those is missing, the session deserves review even before you ask whether it was malicious.
Automation is a common false-positive source, so teams need a clean inventory of service accounts, scheduled jobs, and orchestration tools that are allowed to touch VMs. If the connection came from an automation account, validate whether that account is allowed to initiate interactive or semi-interactive access, or whether it should only be performing a machine-to-machine task.
When the source is unknown, the next step is to determine whether the connection represents an approved exception, a misconfiguration, or a compromised identity. That triage is faster when the team can correlate session logs with identity logs and with the approved access path for that workload.
Risk and Threat Considerations
Direct VM access is risky because it can bypass the normal choke points where teams expect logging, MFA enforcement, session recording, and approval controls to exist. Attackers prefer these paths because they can blend into ordinary administrative activity once they obtain a valid account or token.
Failure mechanism: The control fails when management traffic is allowed to reach the VM from sources that are not constrained by bastioning, session brokering, or source restrictions, or when the identity used for access is too broad to distinguish normal administration from compromise.
Impact: A successful bypass can hide intrusion activity in routine admin noise, expand the blast radius of a stolen privileged identity, and make it harder to prove whether the session was legitimate or abusive after the fact.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Networks and environments are monitored to detect potential cybersecurity events | Direct VM connections are detected by monitoring management traffic and unusual session paths. |
| Recommendation — Monitor management paths and alert on unexpected direct-to-VM access patterns. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Session, authentication and network events must be logged to spot bypassed access routes. |
| AC-17 — Remote Access | Direct VM connections are a remote-access control problem requiring approved session paths. | |
| Recommendation — Log remote access and authentication events needed to reconstruct direct VM connections. Restrict and monitor remote administration to approved connection paths. | ||
| MITRE ATT&CK | T1021 — Remote Services | Direct VM connections often use SSH, RDP or similar remote services that defenders can hunt for. |
| Recommendation — Map unexpected SSH, RDP and similar sessions to remote-service attack paths. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Approved access paths, admin identities and exception handling are central to this detection. |
| Recommendation — Control and review administrative access paths for direct VM exposure. | ||
Practitioner Guidance
What to prioritise: Build the detection around the approved access path first, then add anomaly logic on top. If you do not know what “normal” source host, geography, and maintenance window look like for a VM class, your alerting will either miss real bypasses or drown in routine admin traffic.
What to verify: For every flagged session, verify three things in order: the source route, the identity used, and the business justification. If the connection did not come through the expected gateway, treat the identity as the next question, not the final answer.
Practitioner takeaway: The best detector is not the one that finds the most logins, it is the one that can quickly prove whether a login followed the approved path or arrived through an access route that should never have been exposed.
Related resources from NHI Mgmt Group
- How should security teams detect compromised human accounts across cloud apps?
- How should security teams detect identity compromise across cloud and SaaS environments?
- How do security teams detect cloud data theft that uses legitimate interfaces?
- How should security teams detect Android malware that abuses cloud services for exfiltration?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org