Edge appliances are now identity risk

Microsoft’s incident write-up shows an exposed F5 BIG-IP edge appliance becoming the entry point for Linux access, SaaS compromise, and identity abuse.

2026-05-28 GIGATAP Team #security
#edge appliance#security operations#identity security

Edge appliances are now identity risk

Source: Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/2026/05/22/from-edge-appliance-to-enterprise-compromise-multi-stage-linux-intrusion-via-f5-and-confluence/

Microsoft’s write-up is useful because the first visible move was not exotic. An exposed F5 BIG-IP edge appliance was used as the path into a Linux host, and the intrusion then moved through internal reconnaissance, SaaS exposure, and identity abuse.

That is the real operational point. An edge appliance is no longer just a network boundary. In many enterprise environments it holds or reaches credentials, certificates, session material, authentication tokens, directory integrations, cloud links, and identity-provider trust. Once that device is compromised, the attacker is not merely “inside the network.” They may be inside the trust graph.

Microsoft describes a multi-stage Linux intrusion that began with an internet-facing firewall appliance, pivoted to an internal Linux host over SSH, then reached a vulnerable Atlassian Confluence server and used credentials for relay-style authentication attacks against Active Directory. The source does not give every exploit detail in the collected material, and that matters. The lesson is not a single magic CVE. It is the chain.

What changed#

Microsoft’s case centers on an F5 BIG-IP load balancer identified as an Azure-hosted appliance running BIG-IP Virtual Edition version 15.1.201000. Microsoft notes that this version reached end of life on December 31, 2024.

That detail is not trivia. End-of-life edge infrastructure is a high-value entry point because it remains exposed while losing the security margin that comes from current support and patch flow. Maintenance windows, change freezes, template drift, and cloud deployment inertia all create the same practical failure: a trusted appliance stays online after its risk profile has changed.

In the incident, the threat actor established SSH access to a Linux server from the F5 device using a privileged account. Microsoft says the actor maintained that level of access through the observed activity without setting up explicit persistence. That is a sharp signal. If an over-privileged account already gives stable sudo access, the attacker may not need noisy persistence.

The actor then performed broad discovery. Microsoft describes file enumeration, internal subnet scanning, service discovery, and scripted Nmap use. The scan pattern was horizontal first, then vertical: identify connected assets, then inspect open services on those targets.

The actor also used gowitness to inspect HTTP and HTTPS services found during scanning, including screenshots and service filtering. Where Windows servers were found, the actor tried common NTLM-based lateral movement techniques with open-source tools. Microsoft says those initial attempts were unsuccessful.

The attacker then downloaded a custom scanning tool from an external IP address listed in Microsoft’s write-up and used it for reconnaissance of web infrastructure. The tool appears to have interacted with applications and mobile-related services used by the organization, likely to understand access controls and reachable systems.

During that internal discovery, the actor identified a Confluence server with unpatched vulnerabilities, according to Microsoft’s summary. The collected source text cuts off before the full Confluence section, so the responsible reading is limited: Microsoft connects the appliance-to-Linux path with later SaaS/application compromise and credential abuse, but the excerpt here does not preserve every step.

Why this edge appliance case matters#

The strongest lesson is about monitoring bias. Edge appliances are externally exposed, highly trusted, and often weakly monitored compared with endpoints. Linux systems and network devices may sit outside the richest EDR coverage. SaaS platforms and identity systems may be logged, but not correlated tightly with appliance activity.

That gap gives the attacker room to move between domains. A firewall or load balancer can become the initial foothold. A Linux host can become the working platform. A Confluence server can become the credential source. Active Directory can become the blast radius.

This is why the phrase “edge appliance” understates the risk. These devices often sit at the junction of network access, application delivery, certificate handling, VPN or proxy behavior, and identity integration. They are operational shortcuts by design. The same shortcuts become attack paths when support status, credentials, or visibility fail.

The case also weakens a common defensive assumption: that failed lateral movement means containment is working. Microsoft notes that initial NTLM-based attempts were unsuccessful, but the actor kept working. They scanned more, shifted tooling, and looked for web infrastructure and application weaknesses. A blocked technique is not a stopped intrusion if the operator still has privileged Linux access.

For security operations teams, this is the part to take seriously. The attack did not need one clean line from perimeter to domain compromise. It used available trust. That makes it harder to detect with controls that watch only one layer.

What to check before acting#

Start with inventory, not panic. The practical question is whether your exposed edge appliance fleet is current, supported, monitored, and mapped to the identities it can use or reach.

Check the F5 angle if it applies to your environment:

  • Identify internet-facing BIG-IP and BIG-IP VE deployments.
  • Confirm versions and support status, especially cloud images created from old ARM templates, Terraform modules, or copied deployment patterns.
  • Review whether any BIG-IP instance is running end-of-life software.
  • Verify management access exposure, SSH access paths, and administrative accounts.
  • Check whether appliance logs are retained and searchable in the same workflow as endpoint, identity, and cloud logs.

Then check the trust graph around the appliance:

  • Which privileged accounts can authenticate from it?
  • Does it store or access certificates, tokens, service credentials, or directory integrations?
  • Can it reach internal Linux hosts, management networks, Confluence, CI/CD systems, or identity services?
  • Are sudo rights on reachable Linux systems narrow and justified?
  • Are authentication events from edge devices treated as high-signal events or as routine noise?

For Linux hosts, look for evidence that matches the behavior pattern rather than only known malware. Microsoft’s source highlights hands-on-keyboard SSH access, scripted Nmap scanning, gowitness use, wget downloads from external infrastructure, and reconnaissance of web services. Those are operational behaviors. They may matter more than a single file hash.

For Confluence and similar internal applications, patch state is only one part of the check. Review exposure from internal Linux systems, credential storage, service accounts, plugin risk, and logs around unusual authentication or enumeration. If an internal application can become the bridge between host access and identity compromise, it belongs in the same investigation path as the edge device.

What not to overclaim#

Do not reduce this incident to “F5 was vulnerable” or “Confluence was vulnerable.” Microsoft’s framing is broader: internet-facing edge devices are increasingly used as initial access points, and compromise can cascade through Linux hosts, SaaS applications, cloud workloads, and identity systems.

Also do not assume the collected excerpt proves a specific exploit path for every stage. It names the F5 BIG-IP VE version and its end-of-life status, describes SSH access from the device, and outlines reconnaissance and later application/identity abuse. The excerpt does not preserve all technical details from the full Microsoft post.

There is another boundary worth keeping. Open-source tools appear in the activity, including Nmap and gowitness, and Microsoft references common NTLM lateral movement tooling. That does not make open source the problem. The operational issue is that common tools blend into real admin environments unless security operations can tie usage to context: who ran it, from where, after what authentication path, and against which assets.

That distinction matters for open source security work too. The useful response is not to treat public tooling as suspicious by default. It is to make security artifacts operational: inventory, versioning, provenance, logging, and repeatable checks. We have argued the same point in related work on OpenSSF signals and package test coverage: artifacts only help when teams can act on them in production. See also: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational and https://gigatap.top/en/articles/100-package-test-coverage-is-the-point-not-the-slogan

Practical takeaway#

Treat every exposed edge appliance as both infrastructure and identity risk. If it is trusted enough to route traffic, terminate sessions, hold certificates, or reach internal services, it is important enough to monitor like a crown-jewel system.

The minimum operational checks are clear: supported versions, tight admin access, searchable logs, mapped trust relationships, constrained sudo paths, current internal application patching, and identity telemetry that can follow the chain across network, Linux, SaaS, and Active Directory.

The attacker path Microsoft describes is not rare because it is complicated. It is dangerous because it uses the enterprise as built.