Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Adversaries may leverage external-facing remote services to initially access and/or persist within a network.
| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 61% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 55% | 0% |
| case-12 | ✗→✓ | ▲ Improved | 25% | 0% |
| case-14 | ✗→✓ | ▲ Improved | 126% | 0% |
| case-15 | ✗→✓ | ▲ Improved | 16% | 0% |
Adversaries may leverage external-facing remote services to initially access and/or persist within a network. Remote services such as VPNs, Citrix, and other access mechanisms allow users to connect to internal enterprise network resources from external locations. There are often remote service gateways that manage connections and credential authentication for these services. Services such as Windows Remote Management and VNC can also be used externally.
Access to Valid Accounts to use the service is often a requirement, which could be obtained through credential pharming or by obtaining the credentials from users after compromising the enterprise network. Access to remote services may be used as a redundant or persistent access mechanism during an operation.
Access may also be gained through an exposed service that doesn’t require authentication. In containerized environments, this may include an exposed Docker API, Kubernetes API server, kubelet, or web application such as the Kubernetes dashboard.
Adversaries may also establish persistence on network by configuring a Tor hidden service on a compromised system. Adversaries may utilize the tool ShadowLink to facilitate the installation and configuration of the Tor hidden service. Tor hidden service is then accessible via the Tor network because ShadowLink sets up a .onion address on the compromised system. ShadowLink may be used to forward any inbound connections to RDP, allowing the adversaries to have remote access. Adversaries may get ShadowLink to persist on a system by masquerading it as an MS Defender application.
Platforms: Containers, Linux, macOS, Windows
The following tests are from Atomic Red Team and provide actionable ways to test this technique:
Running Chrome VPN Extensions via the Registry install 2 vpn extension, please see "T1133\src\list of vpn extension.txt" to view complete list
Supported Platforms: windows Elevation Required: Yes
powershell$extList = #{extension_id} foreach ($extension in $extList) { New-Item -Path HKLM:\Software\Wow6432Node\Google\Chrome\Extensions\$extension -Force New-ItemProperty -Path "HKLM:\Software\Wow6432Node\Google\Chrome\Extensions\$extension" -Name "update_url" -Value "https://clients2.google.com/service/update2/crx" -PropertyType "String" -Force} Start chrome Start-Sleep -Seconds 30 Stop-Process -Name "chrome"
Dependencies:
If Atomic Red Team tests are not applicable, manually verify the technique by:
Restrict all traffic to and from public Tor nodes.
Deny direct remote access to internal systems through the use of network proxies, gateways, and firewalls.
Disable or block remotely available services that may be unnecessary.
Limit access to remote services through centrally managed concentrators such as VPNs and other managed remote access systems.
Use strong two-factor or multi-factor authentication for remote service accounts to mitigate an adversary's ability to leverage stolen credentials, but be aware of Multi-Factor Authentication Interception techniques for some two-factor authentication implementations.
| Finding | Severity | Impact | | --------------------------------------------- | -------- | ----------- | | External Remote Services technique applicable | High | Persistence |
| CWE ID | Title | | ------- | ----------------------------- | | CWE-276 | Incorrect Default Permissions |
Other measured skills in the registry, with their headline benchmark lift.