F5 BIG-IP compromise let attackers pivot from Linux to Confluence and Active Directory

Microsoft says a threat actor used a compromised F5 BIG-IP edge appliance as the starting point for a multi-stage intrusion that reached Linux systems, an internal Atlassian Confluence server, and Active Directory. The incident shows how one exposed appliance can give attackers a trusted path into systems that are not directly open to the internet.

The attack began after the actor established SSH access to a Linux host from a network device identified as an F5 BIG-IP load balancer, according to Microsoft Defender Security Research. Microsoft traced the source to an Azure-hosted BIG-IP Virtual Edition appliance running version 15.1.201000.

That detail matters because BIG-IP 15.1.x reached end of life on December 31, 2024, according to an F5 support notice. Unsupported edge devices receive no normal security maintenance, which makes them dangerous assets when they sit between the public internet and internal services.

How the attack moved through the network

After gaining SSH access to the Linux host, the attacker used a privileged account and kept hands-on keyboard access during the operation. Microsoft said the actor did not need obvious persistence because the account already provided broad access.

The attacker then scanned internal subnets with Nmap, looked for open services, and used gowitness to capture screenshots of HTTP and HTTPS services through a SOCKS5 proxy. The activity helped the actor map systems that normal perimeter controls would not expose to the public internet.

Where Windows servers appeared, the actor tried common NTLM-based lateral movement tools, including netexec, smbclient, rpcclient, ldapsearch, Kerbrute, and Responder. Microsoft said those first attempts failed, but the attack continued.

Stage	What happened	Why it matters
Initial access	SSH access came from an F5 BIG-IP load balancer	A trusted edge device acted as the bridge into the network
Reconnaissance	The actor scanned Linux and Windows systems	Internal assets became visible after the first foothold
Confluence compromise	An internal Confluence server with unpatched flaws was exploited	Internal-only applications still created serious risk
Identity attack	Stolen credentials supported Kerberos relay activity	The intrusion crossed into Active Directory abuse

Confluence became the next target

The attacker later downloaded a custom scanning tool from the command-and-control address 206.189.27[.]39. Microsoft detected the tool as HackTool:Linux/MalPack.B, and said it probed the organization’s web applications and mobile services to understand access controls.

That reconnaissance exposed an internal Atlassian Confluence server with unpatched vulnerabilities. Atlassian maintains a public list of Atlassian security advisories, including Confluence security fixes, but Microsoft’s incident report did not name the exact Confluence CVE used in this case.

Once inside Confluence, the actor pulled credentials from configuration files, including server.xml and confluence.cfg.xml. Those credentials then gave the attacker a path toward Windows infrastructure, showing how an internal collaboration system can become a bridge into identity systems.

Active Directory abuse raised the impact

The stolen credentials helped the actor attempt relay-style authentication attacks against the Windows environment. Microsoft said the activity included Kerberos relay attacks and exploitation of CVE-2025-33073, a Windows SMB Client improper access control vulnerability.

The campaign shows why patching only internet-facing apps does not solve the whole problem. The Confluence server was not public, but it became reachable after the attacker used the edge appliance and Linux host as stepping stones.

Microsoft Defender for Endpoint blocked repeated payload drops on the Confluence host where real-time protection was enabled. On other Linux systems, limited protection gave the attacker more room to run scripts, scanners, and public offensive tools.

Why edge appliances need Tier-0 treatment

Firewalls, VPN gateways, and load balancers often hold certificates, session data, routing visibility, authentication tokens, and directory integrations. That makes them more than network equipment. They can become identity assets when attackers compromise them.

In this incident, Microsoft’s report frames the BIG-IP device as a trusted entry point rather than a standalone server compromise. The lesson for defenders is clear: internet-facing appliances need strict lifecycle management, centralized logging, and fast patch governance.

Organizations still running F5 BIG-IP 15.1.x should prioritize replacement or upgrade planning because that branch is no longer supported. Teams should also restrict appliance management access to known administrative networks and monitor for SSH logons that originate from network infrastructure.

• Inventory every internet-facing firewall, VPN gateway, load balancer, and reverse proxy.
• Track end-of-life dates for appliance software, not only operating systems.
• Restrict management interfaces by IP range and administrative role.
• Enable detailed logging for SSH, management-plane access, and appliance-originated connections.
• Patch internal apps with the same urgency as public-facing systems.

What admins should do now

Security teams should treat the incident as an attack-chain problem, not a single-product issue. The path touched edge infrastructure, Linux, internal web apps, Windows authentication, and Active Directory.

Microsoft recommends reducing NTLM use where possible, enforcing SMB signing, enabling LDAP signing and channel binding, and using Extended Protection for Authentication on relevant services. The CVE-2025-33073 record also points admins toward vendor guidance for the Windows SMB issue.

Atlassian customers should review Confluence security updates and make sure internal servers do not lag behind because they lack internet exposure. Attackers only need one internal foothold to reach them.

Priority	Action	Goal
High	Upgrade or retire unsupported BIG-IP versions	Remove exposed security debt
High	Patch Confluence and other internal web apps	Block lateral RCE paths
High	Enforce SMB and LDAP signing	Reduce relay attack success
Medium	Limit SSH trust and privileged sudo access	Reduce blast radius after appliance compromise
Medium	Hunt for suspicious appliance-originated SSH activity	Find hidden entry points faster

The incident also gives defenders useful detection clues. Microsoft published indicators including the command-and-control address 206.189.27[.]39 and hashes tied to the custom scanner, network scanning script, Kerbrute, gowitness, and an NTLM relay script.

The bigger warning is broader than F5 or Confluence. Attackers increasingly look for weak links between trusted systems. Once they cross that line, internal tools, cached credentials, and old authentication settings can turn one appliance compromise into an enterprise identity incident.

FAQ