A VPN, Citrix gateway or Remote Desktop Gateway that accepts a password alone turns one leaked credential into a full network session, and the attacker then looks exactly like a remote employee. MITRE ATT&CK T1133 External Remote Services covers adversaries using external-facing remote services, such as VPNs, Citrix and other access mechanisms, to gain initial access and to keep it. In ATT&CK v20 it sits in both the Initial Access (TA0001) and Persistence (TA0003) tactics and applies to Windows, Linux, macOS and container platforms. This guide explains the access paths at the level of the ATT&CK description, then concentrates on what defenders can log, alert on and harden at the gateway. It is for SOC analysts, network and identity engineers and anyone who owns a remote access service. For the appliance itself (patching, integrity checks, configuration) see the VPN Security Guide; this page focuses on the technique.
Key takeaways
- Credentials are the usual key. ATT&CK notes that access to Valid Accounts is often a requirement, so most T1133 activity is a successful logon, not an exploit.
- It is persistence as well as entry. Groups keep VPN or Citrix access as a redundant way back in, which is why ATT&CK lists the technique under two tactics.
- Unauthenticated services count too. An exposed Docker API, Kubernetes API server or kubelet gives the same result with no credential at all.
- MFA on every path, including the forgotten ones. The large incidents linked below came through a single remote access profile or portal that had no MFA.
- Detect on the session, not the packet. Gateway authentication logs, source reputation, device posture and what the session does next are the signals that separate an attacker from a user.
How the attack works
ATT&CK describes remote service gateways that manage connections and credential authentication, and lists Windows Remote Management and VNC as services that can also be used externally. The defender's view of the access paths:
| Path | What the adversary needs | Typical services | Closest related technique |
|---|---|---|---|
| Logon with stolen or bought credentials | A username and password (from phishing, infostealers, reuse or an access broker), sometimes a session token or VPN certificate | SSL and IPsec VPNs, Citrix Gateway, RD Gateway, VDI portals, OWA | T1078 Valid Accounts, T1110 Brute Force |
| Exposed service with no authentication | Network reachability only | Docker daemon API, Kubernetes API server, kubelet, Kubernetes dashboard | None: misconfiguration is the enabler |
| Partner or provider connection | Access to a third party's remote link | Site-to-site VPNs, supplier jump hosts | T1199 Trusted Relationship |
| Re-entry after compromise | A foothold inside, used to enable or add a remote service | WinRM listeners, SSH, Tor hidden services forwarding to RDP | Persistence in general |
Exploiting a vulnerability in the gateway itself is tracked separately as T1190 Exploit Public-Facing Application. In practice the two chain: CitrixBleed (CVE-2023-4966) and Ivanti Connect Secure (CVE-2023-46805 with CVE-2024-21887) were exploited, and stolen sessions or credentials were then used as ordinary remote access. All of these are in the CISA Known Exploited Vulnerabilities catalogue with known ransomware use.
Where it shows up
- Ransomware operators: ATT&CK records Akira using compromised VPN accounts for initial access, Play using RDP and VPNs, and Wizard Spider using stolen credentials against corporate VPN infrastructure.
- Extortion groups: LAPSUS$ gained access to VPN, RDP and Citrix VDI; Scattered Spider used Citrix and VPNs to persist and legitimate remote management tools to keep access.
- State-linked espionage: APT29 used compromised identities on VPNs and Citrix, including during the SolarWinds compromise; Volt Typhoon used VPNs for post-exploitation; Ke3chang used stolen VPN certificates; Sea Turtle used external-facing SSH.
- Container estates: TeamTNT targeted exposed Docker API ports and kubelets, and Kinsing and Doki ran through open Docker daemon APIs.
- Destructive operations: in the 2025 Poland wiper attacks recorded by ATT&CK, the threat actors used an internet-exposed FortiGate VPN interface for access.
Impact
T1133 rarely causes damage on its own; it hands the adversary an authenticated, encrypted session on the internal network that perimeter controls trust by design. From there the usual chain is discovery, credential theft, lateral movement and either data theft or ransomware. Because the session is legitimate, dwell time can be long: at Change Healthcare roughly nine days passed between the Citrix logon and ransomware deployment. Remote access is also a durable persistence channel, so removing malware without removing the account or session leaves the door open.
Detection
ATT&CK v20 maps one behaviour-chain detection strategy to T1133, with analytics for Windows, Linux, macOS and containers. Each follows the same shape: unusual external access, repeated failures followed by success, then internal activity. Practical telemetry:
| Source | Events or fields | What to look for |
|---|---|---|
| VPN, Citrix and RD Gateway logs | Authentication success and failure, source IP, client version, device posture result, assigned internal IP | Logon from a new country, ASN, hosting provider or anonymiser; one source IP authenticating many accounts; a client string never seen before |
| Windows Security log | 4624 (logon type 10 RemoteInteractive, type 3 Network), 4625 failures, 4776 NTLM validation | Type 10 logons to servers from the VPN pool by accounts that do not normally use RDP; IpAddress and WorkstationName that do not match managed devices |
| Identity provider sign-in logs | MFA result, authentication method, conditional access outcome, risk level | MFA not required or bypassed for the gateway application, legacy authentication, push approvals at odd hours |
| Linux and appliance syslog | sshd accepted and failed password events, RADIUS and LDAP bind results | Password logons where keys or certificates are expected; bursts of failures from external IPs |
| Kubernetes audit and container API logs | Requests from system:anonymous, pod create and exec, kubelet API calls | Any anonymous request that succeeds; container creation from external addresses on ports 2375, 6443 or 10250 |
| Network flow | Inbound connections to remote access ports (3389, 22, 5985/5986, 5900, VPN ports) | Direct inbound RDP, WinRM or VNC from the internet, which should not exist if access goes through a gateway |
Detection logic that works
- Dormant account logon: alert when an account with no remote access session for 60 or more days connects. The Colonial Pipeline attack began with a VPN profile that was no longer used but had never been disabled.
- Spray pattern: many different accounts succeeding from one source within minutes. Huntress saw exactly this in the SonicWall SSL VPN account compromises, where most connections came from a single IP.
- Session behaviour after logon: a VPN session that immediately scans internal ranges, opens RDP to many hosts or touches domain controllers is more telling than the logon itself.
- Session reuse: the same session identifier or cookie seen from two source IPs points to token theft, as with CitrixBleed.
- New listeners: a host that starts accepting WinRM, SSH or VNC from outside, or runs a Tor client, suggests an attacker adding their own remote service.
For log field mapping and correlation rules across appliances see the VPN and Firewall Log Detection Guide.
Metrics
- MFA coverage: share of remote access paths (every VPN profile, portal and gateway) that enforce MFA, target 100%.
- Dormant remote accounts: count of accounts with remote access rights and no logon in 90 days, trending to zero.
- Exposed services: number of internet-reachable RDP, SSH, WinRM, VNC, Docker or kubelet endpoints found by external scanning each month.
- Gateway patch latency: days from vendor fix to deployment for remote access appliances, with KEV entries tracked separately.
- Time to revoke: minutes from a suspicious remote session alert to account disablement and session termination.
Prevention and hardening
- MFA on every remote path (M1032): include legacy VPN profiles, Citrix and RD Gateway. For RD Gateway, the Microsoft Entra NPS extension adds MFA through RADIUS; the extension installs on the NPS server, not on the gateway, and Microsoft advises raising the RADIUS timeout to 30 to 60 seconds. ATT&CK warns that some MFA implementations can be intercepted, so prefer phishing-resistant methods. See the Phishing-Resistant MFA Guide.
- Centralise through managed concentrators (M1035): all remote access through a small number of gateways, never direct inbound RDP, SSH or WinRM.
- Deny direct access to internal systems (M1030): use proxies, gateways and firewalls so a VPN session lands in a restricted zone, not the flat network.
- Remove what is not needed (M1042): disable unused VPN profiles, portals, clientless modes and remote services; restrict all traffic to and from public Tor nodes (M1021).
- Device trust: NCSC recommends client certificates for machine authentication rather than pre-shared keys, with private keys in hardware-protected storage such as a TPM, and treating VPN services as internet-exposed attack surface to be patched promptly.
- Lock down container control planes: Docker's guidance is to reach a remote daemon over SSH or over TLS with
tlsverifyand a trusted CA, so only clients with a certificate from that CA connect. For kubelets, disable anonymous authentication and use Webhook authorisation. See the Kubernetes NHI Security Guide. - Move beyond network-level access: identity-aware, per-application access reduces what a stolen VPN credential is worth. See the Secure Remote Access Beyond VPN Guide.
Choosing controls
| Situation | First steps | Trade-off |
|---|---|---|
| Small organisation, one VPN | Enforce MFA, disable unused accounts, turn off direct RDP, subscribe to the vendor's advisories | Little capacity for analytics, so prevention carries the load |
| Large estate with several gateways | Inventory every portal and profile, federate all to one identity provider with conditional access, stream logs to the SIEM | Legacy appliances may not support modern MFA; plan replacement |
| Heavy third-party access | Separate supplier gateway, named accounts, time-bound access, session recording | More operational overhead for suppliers |
| Container and Kubernetes platforms | Private API endpoints, authenticated kubelets, no exposed Docker daemon | Operators need a bastion or private network path |
Phased rollout
- Inventory: scan your own external ranges for remote access services and list every VPN profile, portal and group allowed to use them.
- Clean up accounts: remove remote access from dormant and shared accounts; give each remaining account an owner.
- Pilot MFA and posture checks: enable for an IT pilot group in report-only or audit mode where the platform supports it, review failures, then widen by ring.
- Enforce and close bypasses: turn off legacy profiles and local accounts that skip MFA; keep a documented break-glass account with alerting. Rollback is re-enabling the previous policy for an affected ring, not removing MFA globally.
- Detect and rehearse: deploy the analytics above, then run an authorised test logon from an unusual location and confirm the alert and revocation path.
Where identity fits
Remote access gateways depend on machine credentials as well as user passwords: LDAP and RADIUS bind accounts, VPN pre-shared keys, device certificates and API keys used by management tooling. After any gateway configuration exposure, rotate these as well as user passwords, as the SonicWall case showed. Service accounts should never be allowed to start interactive VPN sessions. See the Remote Access Identity Guide.
Lessons from incidents
- One portal without MFA is enough: the Change Healthcare breach began with a stolen credential on a Citrix remote access portal that did not require MFA.
- Unused is not the same as disabled: the Colonial Pipeline VPN account had no MFA and was no longer in use, but stayed active.
- MFA at logon does not protect a stolen session: in CitrixBleed, leaked session tokens let attackers resume authenticated sessions; patching had to be followed by killing existing sessions.
Framework mapping
| Framework | References |
|---|---|
| ATT&CK mitigations | M1032 Multi-factor Authentication, M1035 Limit Access to Resource Over Network, M1030 Network Segmentation, M1042 Disable or Remove Feature or Program, M1021 Restrict Web-Based Content |
| NIST SP 800-53 Rev. 5 | AC-17 Remote Access, IA-2 Identification and Authentication, AC-2 Account Management, SC-7 Boundary Protection, SI-4 System Monitoring |
| NIST CSF 2.0 | PR.AA-03 (users, services and hardware are authenticated), PR.IR-01 (networks protected from unauthorised logical access), DE.CM-01 (networks monitored) |
| CIS Controls v8.1 | Control 6 Access Control Management (MFA for remote network access), Control 12 Network Infrastructure Management, Control 13 Network Monitoring and Defense |
| MITRE D3FEND | D3-MFA Multi-factor Authentication, D3-UGLPA User Geolocation Logon Pattern Analysis, D3-ANET Authentication Event Thresholding, D3-RTSD Remote Terminal Session Detection, D3-DRA Disable Remote Access |
Practitioner checklist
- List every internet-facing remote access service, profile and portal, and scan your ranges monthly for new ones.
- Enforce MFA, preferably phishing-resistant, on every remote path with no legacy or local-account bypass.
- Disable remote access for accounts unused for 90 days and alert on any dormant account logon.
- Block direct inbound RDP, SSH, WinRM and VNC; route all access through managed gateways.
- Patch remote access appliances as an emergency class, prioritising KEV entries, and terminate sessions after token-leak fixes.
- Stream gateway, identity provider and Windows 4624/4625 logs to the SIEM with spray, geography and dormant-account rules.
- Require authenticated, private Kubernetes and Docker control planes.
- Rotate bind accounts, pre-shared keys and device certificates after any gateway compromise or configuration leak.
Standards and references
- MITRE ATT&CK: External Remote Services (T1133)
- MITRE ATT&CK: Valid Accounts (T1078)
- NCSC: Virtual Private Networks (VPNs)
- Microsoft Learn: Integrate RD Gateway with Microsoft Entra multifactor authentication NPS extension
- Microsoft Learn: 4624(S) An account was successfully logged on
- Docker Docs: Protect the Docker daemon socket
- Kubernetes: Kubelet authentication/authorization
- CISA: Known Exploited Vulnerabilities Catalog
Related NHI Mgmt Group resources: VPN Security Guide · Initial Access Techniques Guide · Persistence Techniques Guide · Remote Desktop (RDP) Security Guide · MITRE ATT&CK T1078 Valid Accounts Guide