External Remote Services
Description
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](https://attack.mitre.org/techniques/T1021/006) and [VNC](https://attack.mitre.org/techniques/T1021/005) can also be used externally.(Citation: MacOS VNC software for Remote Desktop) Access to [Valid Accounts](https://attack.mitre.org/techniques/T1078) 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.(Citation: Volexity Virtual Private Keylogging) 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.(Citation: Trend Micro Exposed Docker Server)(Citation: Unit 42 Hildegard Malware) 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.(Citation: The BadPilot campaign) Adversaries may get `ShadowLink` to persist on a system by masquerading it as an MS Defender application.(Citation: Russian threat actors dig in, prepare to seize on war fatigue)
Mapped SPARTA techniques
8 techniques
Once a spacecraft SDR is compromised, it functions as the externally-facing remote service granting access to the spacecraft — conceptually equivalent to T1133 'External Remote Services' in enterprise context; cross-domain moderate because the SDR is RF-side rather than IP-side.
Secondary/backup communication channels (TDRSS, contingency uplinks, alternate ground sites) are externally-facing remote services to the spacecraft — T1133 'External Remote Services' covers using such services as the initial-access vector when they are inadequately protected (often less monitored than primary TT&C).
An alternate/backup ground station functions as an external remote service for the spacecraft; abusing it as the initial-access path matches T1133 'External Remote Services' at cross-domain level.
A backup receiver (alternate antenna, redundant transponder path) is an external remote interface to the spacecraft; abuse of it as an initial-access path matches T1133 'External Remote Services'.
Mapped by SPARTA, not curated by SafeMode Space.
Mapped by SPARTA, not curated by SafeMode Space.
Mapped by SPARTA, not curated by SafeMode Space.
T1133 'External Remote Services' is in persistence tactic and addresses adversary persistent access via VPNs/Citrix/remote-access services; SPARTA PER-0003 covers persistent presence on ground systems frequently maintained through these same remote-access mechanisms (operator VPNs, contractor RDP, vendor SSH). Tactic and activity align.
Cross-framework references
Relationships published by the source frameworks themselves, reproduced here with attribution. They are not SafeMode Space mappings and carry no confidence rating of ours.
Countered by 1 in MITRE D3FEND (Defensive Techniques)
Cite as SafeMode Space, mitre-attack-enterprise T1133.