Overview

External Remote Services (T1133) describes adversaries abusing legitimate remote access mechanisms — VPNs, Citrix, RDP gateways, SSH, VNC, exposed APIs, and similar services — to gain or maintain a foothold in a target environment. Attackers typically pair this technique with valid stolen credentials or exploit unauthenticated service exposures to establish a persistent, low-noise entry point that blends in with normal remote worker traffic.

Every organization that allows remote access — which is virtually every organization — is exposed to this technique. Because the access mechanism itself is intentional and trusted, malicious use is easy to miss without baselining normal behavior. Detection is critical: this technique is consistently observed in ransomware pre-positioning, state-sponsored intrusions, and supply chain attacks as both an initial access vector and a long-term persistence mechanism.

Attacker Perspective

Attackers treat external remote services as a low-risk, high-reward persistence channel because successful abuse is nearly indistinguishable from legitimate remote work activity.

• VPN credential abuse: After purchasing or phishing credentials, an adversary authenticates to a Pulse Secure, Fortinet SSL VPN, or Cisco AnyConnect gateway from a residential proxy IP, establishing a persistent tunnel into the corporate network without deploying any malware.
• Exposed Docker/Kubernetes API exploitation: A Kubernetes API server left accessible on TCP/6443 without authentication is targeted using kubectl --server=https://[target]:6443 get pods, allowing container deployment and command execution without any account compromise.
• Tor hidden service persistence via ShadowLink: On a compromised Windows host, the adversary drops ShadowLink masquerading as MsMpEng.exe (Windows Defender), which configures a Tor hidden service forwarding inbound .onion connections to the local RDP port (TCP/3389), creating a covert persistent access channel.
• ArcGIS / web-facing application exploitation: Flax Typhoon and similar actors exploit publicly facing services such as ArcGIS Server, causing ArcSOC.exe to drop web shells (.aspx, .ps1) that provide persistent remote code execution through a trusted external-facing HTTP endpoint.

This technique is attractive because it exploits infrastructure defenders intentionally leave open to the internet, uses legitimate protocols that are rarely blocked or deeply inspected, and — when paired with valid credentials — produces virtually no malware-based artifacts for endpoint tools to detect.

Detection Strategy

Required Telemetry

• Windows Security Event Log — Logon Events: Enable Audit Logon and Audit Account Logon via GPO (Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy). Generates Event ID 4624 (successful logon), 4625 (failed logon), 4648 (explicit credential use), and 4768/4769/4776 for Kerberos/NTLM authentication. Logon Type 10 (RemoteInteractive/RDP) and Type 3 (Network) are most relevant.
• Windows Security Event Log — Account Management: Enable Audit Special Logon to capture Event ID 4672 (privileged account logon). Critical for flagging admin-level remote sessions.
• VPN/Remote Access Gateway Logs: Collect authentication and session logs from Fortinet FortiGate, Pulse Secure, Cisco ASA, Palo Alto GlobalProtect, or similar. Key fields: source IP, username, authentication result, session duration, bytes transferred, geolocation. Forward via Syslog or API to your SIEM.
• Firewall / NSG Flow Logs: Enable connection logs for inbound traffic on ports 443, 3389, 22, 5900, 8443, 6443, 2375, 2376. These reveal direct external connections to services that should not be internet-facing.
• Linux Auditd — SSH and Authentication: Add rules: -w /etc/ssh/sshd_config -p wa -k ssh_config_change and -w /var/log/auth.log -p wa -k auth_log_watch. Collect /var/log/auth.log or /var/log/secure for SSH authentication events including source IP, username, and success/failure.
• Linux Auditd — Docker/Kubernetes API Access: Enable API server audit logging in Kubernetes (--audit-log-path and --audit-policy-file in kube-apiserver configuration). For Docker, enable the daemon log and monitor access to the Docker socket at /var/run/docker.sock using auditd rule: -w /var/run/docker.sock -p rwxa -k docker_sock.
• Windows Sysmon — Process and Network: Deploy Sysmon with a configuration capturing Event ID 1 (process create), Event ID 3 (network connection), and Event ID 11 (file created). Critical for detecting ShadowLink/Tor hidden service setup and web shell drops from processes like ArcSOC.exe. Install via: sysmon64.exe -accepteula -i sysmonconfig.xml.
• Windows File Event Logging (Sysmon EID 11): No additional GPO required beyond Sysmon deployment. Captures file creation with full path, creating process image path, and timestamp. Essential for detecting web shell and executable drops by internet-facing processes.
• Honeypot/Canary Logs (OpenCanary): Deploy OpenCanary nodes on internal subnets and enable SSH (logtype 4002), RDP, and HTTP canary services. Any authentication attempt against these is high-fidelity — configure to forward JSON events to SIEM via Syslog.
• DNS Logs: Collect internal DNS resolver query logs to detect Tor bootstrap queries (e.g., lookups to torproject.org infrastructure) or lookups to known VPN/proxy infrastructure from internal hosts where those lookups are unexpected.

Key Indicators

• Impossible travel / geographic anomaly: In VPN/auth gateway logs, check source_ip geolocation against the user’s previous N successful login locations. Flag when the same username authenticates from two countries within a timeframe that makes physical travel impossible (e.g., US and Ukraine within 2 hours).
• Authentication from Tor exit nodes or known VPN/proxy ranges: In VPN and firewall logs, match source_ip against threat intelligence feeds for Tor exit node IPs and commercial VPN ranges. Command pattern to enrich: source_ip IN [tor_exit_list].
• New VPN SSL Web Portal configuration change: In FortiGate event logs, look for action = "Add" and cfgpath = "vpn.ssl.web.portal". Legitimate portal additions are rare and change-controlled — any unscheduled addition is suspicious.
• Direct inbound connections to management ports: In firewall flow logs, flag inbound connections on dest_port IN [3389, 22, 5900, 6443, 2375, 2376, 10250] where src_ip is not in an approved remote-access IP range.
• Tor-related process execution: In Sysmon EID 1, look for Image ending in tor.exe or MsMpEng.exe running from non-standard paths (e.g., C:\ProgramData\, C:\Users\[user]\AppData\ rather than C:\Program Files\Windows Defender\). Also watch for CommandLine containing --hidden-service or SocksPort.
• Web shell / executable drop by internet-facing processes: In Sysmon EID 11, flag Image values matching internet-facing service processes — ArcSOC.exe, w3wp.exe, httpd.exe, nginx, tomcat — creating files with extensions .aspx, .php, .ps1, .exe, .dll, .bat, .cmd, .js, .py.
• OpenCanary SSH login attempt: Any event in OpenCanary logs with logtype = 4002 indicates an active reconnaissance or lateral movement attempt against a canary SSH service — treat as high-fidelity.
• Kubernetes API server anonymous or unexpected access: In K8s audit logs, flag requests where user.username = "system:anonymous" or where a known service account is making requests from an external sourceIPs value outside the cluster CIDR.
• Unusual RDP session duration or off-hours timing: In Windows EID 4624 (Logon Type 10), correlate session start time and source IP against a baseline. Flag sessions starting between 22:00–06:00 local time from external IPs not previously seen for that user.

Detection Logic

Rule 1 — Broad: External authentication to remote access services outside business hours or from new geolocations
IF vpn_auth.result = "success" AND vpn_auth.source_ip NOT IN [known_corp_ips] AND (hour(vpn_auth.timestamp) < 6 OR hour(vpn_auth.timestamp) > 22) AND vpn_auth.username NOT IN [scheduled_service_accounts] THEN alert

This catches the widest set of suspicious VPN authentications by combining off-hours timing with external source IP. Expected volume is moderate — legitimate remote workers in other time zones and travel cases will generate noise. Use this to build a queue for analyst review, not as a direct escalation trigger.

Rule 2 — Medium: Inbound connection to management/remote-access port from non-approved source IP
IF firewall.dest_port IN [3389, 22, 5900, 6443, 2375, 10250] AND firewall.direction = "inbound" AND firewall.action = "allow" AND firewall.src_ip NOT IN [approved_remote_access_ranges] THEN alert

This detects direct external exposure of services that should only be accessible through a VPN or jump host. Low expected volume when approved ranges are well-defined. High-confidence signal for container API (6443, 2375, 10250) and VNC (5900) hits, which are rarely legitimate from external IPs.

Rule 3 — High Precision: Executable or script file created by an internet-facing process
IF sysmon.event_id = 11 AND sysmon.Image ENDSWITH_ANY ["\ArcSOC.exe", "\w3wp.exe", "\httpd.exe", "\php-cgi.exe", "\tomcat.exe"] AND sysmon.TargetFilename ENDSWITH_ANY [".aspx", ".php", ".ps1", ".exe", ".dll", ".bat", ".cmd", ".vbs", ".js", ".py"] THEN alert HIGH

This is a high-precision rule targeting web shell drops and payload staging by compromised external-facing services. Expected volume is very low — these processes have no legitimate reason to create executable content. Any hit warrants immediate investigation.

Rule 4 — High Precision: Tor or ShadowLink hidden service configuration on a Windows endpoint
IF sysmon.event_id = 1 AND (sysmon.Image ENDSWITH "\tor.exe" OR (sysmon.Image ENDSWITH "\MsMpEng.exe" AND sysmon.Image NOT STARTSWITH "C:\Program Files\Windows Defender")) AND (sysmon.CommandLine CONTAINS "--hidden-service" OR sysmon.CommandLine CONTAINS "SocksPort" OR sysmon.Image NOT STARTSWITH "C:\Program Files") THEN alert CRITICAL

This targets ShadowLink-style Tor persistence, specifically the masquerading pattern of a Tor binary or ShadowLink pretending to be Windows Defender. Expected volume is near-zero in most environments. Any hit should be treated as a confirmed incident pending investigation.

Tuning Guidance

• Legitimate remote workers in global time zones: Off-hours VPN rules will fire for employees in APAC or EMEA connecting during what is nighttime in the SIEM’s configured timezone. Mitigate by building per-user or per-department time-of-day baselines over 30 days, then alerting on deviation from the individual user’s historical pattern rather than an absolute hour threshold. Exclude username IN [known_global_remote_workers] from the broad rule and rely on geolocation anomaly for those users instead.
• Approved VPN split-tunnel and jump host IPs: Firewall rules detecting inbound management port connections will fire for legitimate IT jump servers and privileged access workstations (PAWs). Maintain and regularly audit an approved_remote_access_ranges reference list. Add a suppression: src_ip IN [approved_paw_ranges, jump_host_ips].
• Automated deployment pipelines writing to web roots: The internet-facing process file creation rule may fire for CI/CD pipelines that deploy content via IIS worker processes or application servers. Identify the specific deployment service accounts and scheduled task patterns, then exclude: user IN [iis_deploy_svc, cicd_agent] AND TargetFilename STARTSWITH [approved_deploy_paths]. Do not blanket-exclude the process image — narrow the exclusion to the specific path and account.
• Security scanning tools touching Docker/Kubernetes APIs: Vulnerability scanners (Tenable, Qualys) and internal security tools may connect to container management APIs from non-cluster IPs. Maintain an explicit exclusion for src_ip IN [scanner_ips] paired with dest_port IN [6443, 2375] rather than removing the rule entirely. Validate the scanner IP list quarterly.
• Legitimate Tor Browser use by researchers or analysts: Threat intelligence or OSINT teams may legitimately run Tor Browser. The ShadowLink/Tor rule should be scoped to server-class systems and hosts outside the analyst VLAN. Add exclusion: host_role NOT IN [analyst_workstations] and verify the Tor binary path matches the official Tor Browser installation path rather than a temp or AppData path.

When the Alert Fires: Investigation Steps

1. Verify the alert is real and pull the raw event. Navigate directly to the originating log source in your SIEM (VPN gateway syslog, Sysmon event store, or firewall flow log) and confirm the raw event exists with all expected fields populated. A missing or malformed event may indicate a logging pipeline issue rather than a true alert.
2. Identify the affected host and user account and check for privilege. Determine the authenticating username and the target host from the alert. Query your identity store (Active Directory via Event ID 4672, or your IAM system) to confirm whether the account holds admin, service account, or privileged roles — escalate priority immediately if privileged.
3. Pull the full command-line and parent process chain for any endpoint activity. In Sysmon EID 1 events on the affected host, retrieve the full CommandLine, Image, ParentImage, and ParentCommandLine fields for all processes spawned within 30 minutes of the alert time. Unusual parent-child relationships (e.g., ArcSOC.exe spawning cmd.exe or powershell.exe) are strong confirmation indicators.
4. Check for network connections established from the affected host. Query Sysmon EID 3 or firewall flow logs for all outbound connections from the host in the 2-hour window around the alert. Flag any connections to Tor infrastructure, uncommon geolocations, high-entropy domain names, or non-standard ports — document all unique destination IPs and domains for threat intelligence lookup.
5. Check for files written to disk on the affected host. Query Sysmon EID 11 for files created by suspicious processes in the alert window, paying particular attention to web-accessible directories (inetpub, application server roots), temp directories, and ProgramData. Hash any identified files and check against VirusTotal or your internal threat intel platform.
6. Search for lateral movement originating from this host. In Windows Security logs (EID 4624 Logon Types 3 and 10) and in your EDR, search for authentication events or network connections from the compromised host to other internal systems within 24 hours of the alert. Pivot on the compromised account in your SIEM to find any authentications to hosts the account does not normally access.
7. Make the escalation decision based on what you’ve found. Escalate to a confirmed incident if you observe any of the following: a web shell or executable dropped by an internet-facing process, a Tor/ShadowLink process executing, authentication from a known malicious IP or impossible travel pair, or evidence of lateral movement. If the investigation reveals a misconfigured scanner or a traveling employee with no suspicious follow-on activity, document findings and close with a tuning recommendation.

Response Playbook

Containment

• Isolate the affected host — keep it powered on. Use your EDR console (CrowdStrike, Defender for Endpoint, SentinelOne) to network-isolate the host immediately. Do not power it off — volatile memory, active connections, and running processes contain forensic evidence. If no EDR is available, block the host at the network switch level using a quarantine VLAN via 802.1X or manual ACL change.
• Disable the affected user account. In Active Directory, run Disable-ADAccount -Identity [username] or use the AD Users and Computers console. For cloud identities (Entra ID/Azure AD), disable via the portal or Set-AzureADUser -ObjectId [UPN] -AccountEnabled $false. Do this before resetting the password to prevent the attacker from using a cached token.
• Revoke all active remote access sessions for the user. On your VPN gateway (FortiGate, Pulse, Cisco), terminate the active session immediately via the admin console or CLI. For RDP, use query session /server:[hostname] and reset session [id] /server:[hostname]. For cloud services, revoke all OAuth tokens and active sessions via your IdP.
• Block identified C2 IPs, domains, and Tor exit nodes at the perimeter. Push identified malicious IPs and domains to your firewall blocklist and DNS sinkhole. If Tor was detected, block Tor exit node IP ranges at the perimeter firewall and consider blocking DNS resolution to torproject.org and known Tor bootstrap addresses on the internal resolver.
• Terminate any identified malicious processes on the host. If the host cannot be immediately isolated, use your EDR to kill the specific malicious process by PID (e.g., the ShadowLink/Tor process or the web shell handler). Record the PID, parent process, and command line before termination for the forensic record.

Eradication

• Remove all identified persistence mechanisms. On Windows, check Scheduled Tasks (schtasks /query /fo LIST /v), Services (sc query type= all), Registry Run keys (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run and the HKCU equivalent), and Startup folders. Remove any entries tied to the malicious binary or service name. On Linux, check crontab -l, /etc/cron.*, systemctl list-units, and /etc/rc.local.
• Delete all dropped payloads, web shells, and attacker tools. Based on the files identified in step 5 of the investigation, delete all dropped files. For web shells in IIS or application server directories, also verify the directory listing in IIS Manager or the application config to ensure no additional mapped handlers were added. Hash all deleted files before removal for the incident record.
• Reset credentials for the compromised account and all accounts used on the affected host. Reset the password for the identified account using a secure, randomized password. Also reset passwords for any other accounts that authenticated to the compromised host during the attack window, as credentials may have been harvested from memory (LSASS). If Kerberoastable service accounts were exposed, rotate those immediately.
• Audit and harden the exploited remote service. If a VPN portal or API endpoint was exploited or misconfigured, review the configuration baseline. Remove any unauthorized VPN SSL Web Portals added (FortiGate: config vpn ssl web portal → delete [portal_name]). Ensure Docker and Kubernetes APIs are not exposed to the internet — verify with nmap -sV -p 6443,2375,2376 [external_ip] from an external vantage point.
• Verify no lateral movement targets were compromised. For each internal host the compromised account authenticated to during the attack window, run a quick triage: check for new local accounts, new scheduled tasks, and new services created in the attack window. If any secondary host shows indicators, treat it as a separate affected system and begin containment for that host.

Recovery

• Verify the host is clean before reconnecting — re-image if confidence is low. Run a full EDR scan and review all persistence locations manually before removing the network isolation. If you cannot confirm with high confidence that all attacker artifacts have been removed (especially for web shells on complex application servers), re-image the host from a known-good baseline and redeploy the application from source control.
• Re-enable the user account only after credential reset and MFA validation are confirmed. Before re-enabling the account, ensure the password has been reset, MFA has been re-enrolled from a clean device, and the user has been briefed on the incident. Do not re-enable the account based on a password reset alone if the original compromise vector was credential phishing.
• Monitor the affected host and user account intensively for 72 hours post-remediation. Create a temporary high-sensitivity watchlist in your SIEM for the affected hostname and username. Alert on any new remote authentication, process execution outside normal baselines, or outbound connection to previously unseen external IPs. This catches re-compromise attempts and any persistence mechanisms missed during eradication.
• Review and update detection rules with new IOCs discovered during the investigation. Add any newly identified malicious IPs, domains, file hashes, and process names to your detection rules and threat intelligence platform. If the attacker used a novel technique variant, write a new Sigma rule and share it with your detection engineering team for deployment across the SIEM.
• Document the full incident timeline and conduct a lessons-learned review. Produce an incident report covering the initial access vector, full attack timeline, affected systems, attacker actions, and remediation steps taken. Use this to drive a targeted review: Was MFA enforced on the exploited remote service? Were management ports unnecessarily exposed? Feed findings directly into your next vulnerability management and security architecture review cycle.