Skip to content
Sign In
Learn

T1133

External Remote Services

Also appears in: Initial Access

What it is

Attackers get in through the services an organization exposes for remote work, such as a VPN, a remote desktop gateway or a remote access portal, usually with stolen credentials. It is a technique under the Initial Access and Persistence tactics. Because the connection arrives through the front door the organization built, it looks like an employee working from home.

How adversaries use it

The attacker signs in to the remote access service with credentials stolen by phishing, bought from another criminal or guessed. If the service doesn't require a second factor, or the attacker can get past it, they arrive inside the network as that user. They often return the same way later, which makes the service a way to stay in as well as get in.

Detect it in Elastic

Data source: VPN and remote access gateway logs (vendor-specific, mapped to ECS)

Key fields

event.category: authentication, for each sign-in attempt event.outcome: success or failure user.name: the account that signed in source.ip: the address the connection came from source.geo.country_iso_code: where that address is registered, when the logs are enriched observer.name: the gateway that handled it @timestamp

Example event

{
  "user": {
    "name": "a.halloran"
  },
  "event": {
    "outcome": "success",
    "category": [
      "authentication"
    ]
  },
  "source": {
    "ip": "203.0.113.84"
  },
  "observer": {
    "name": "gw-012.corp.example"
  },
  "@timestamp": "2026-06-09T01:48:30.117Z"
}

Prebuilt Elastic rule: Successful SSH Authentication from Unusual User

Hunt guidance

Field names depend on the gateway and how its logs are shipped, so check your data view first. Start with successful remote sign-ins: event.category: "authentication" and event.outcome: "success", grouped by user.name and source.ip. Then compare each account's addresses and countries with its usual ones. Look for an account signing in from two distant places within a short time, sign-ins from hosting providers rather than home connections, a burst of failures before a success, and sign-ins for accounts whose owners are on leave. The prebuilt rule named on this page reads Linux remote shell sign-ins, not a VPN or gateway's own logs, so for gateway sign-ins this hunt is the detection.

Ruling out legitimate activity

Travel, mobile networks and personal VPN services all change where a sign-in appears to come from. Check with the account's owner or their manager, compare the device the session reports with the person's usual one, and look at what the session did inside the network. An unusual sign-in followed by ordinary work is usually the person; one followed by discovery is not.

Telemetry needed

The log events that help detect this technique, from the Telemetry reference: which log source to collect, which event in it, and how to enable each one.

References

Practice it

No range covers this technique yet; the write-up above landed first. Ranges are added continuously; the ones live today are on the training ladder.