GHOSTWORKER: a stealth UniFi gateway implant that phones home over Google's DNS

§ 01. What we walked into

The bypass required a single unauthenticated request and returned the controller’s complete user account list. Among those accounts were two unauthorized Ubiquiti “support” administrators. After obtaining root-level access to the appliance, we identified additional evidence of compromise: an unrecognized binary in /bin that was not associated with any installed package, configured for persistence across reboots, disguised as a kernel thread, and communicating externally over DNS-over-HTTPS (DoH). We refer to this implant throughout the report as GHOSTWORKER.

Our investigation confirmed three distinct findings, which are intentionally treated separately in this report. First, the device is vulnerable to a maximum-severity authentication bypass that CISA has identified as actively exploited; we validated the vulnerability using a non-destructive test. Second, the gateway had already been compromised before our assessment began. The controller’s own databases contain evidence of rogue administrator accounts and operator activity dating back to mid-June 2026. Third, a custom implant was present on the appliance, with mechanisms for reboot persistence and process concealment.

We have not established that exploitation of the authentication bypass and deployment of GHOSTWORKER were performed by the same threat actor. Where the available evidence supports only an analytical inference rather than a confirmed finding, this distinction is stated explicitly.

§ 02. How the bypass works

UniFi OS puts an authentication gateway in front of its internal services and lets a few public routes through without a login. The gateway decides whether a route is public by reading the raw request URL. nginx, behind it, routes on the decoded URL. Those two do not have to agree. A URL that starts with the public prefix /api/auth/validate-sso/ but contains encoded ../ sequences passes the gateway's public check, then decodes into a protected /proxy/<service>/… path and reaches the backend with no authentication. That mismatch is CVE-2026-34908 (broken access control) and CVE-2026-34909 (path traversal), the pair Ubiquiti describes in SAB-064 and Bishop Fox walks through in its writeup.

Here is the whole thing in two requests, sent over a raw TLS socket so the ..%2f survives instead of being normalized away by an HTTP client.

The bypass handed back seven local user records – usernames, email addresses, and the field names api_keys, nfc_token and password_revision. It also reaches write endpoints as an admin: a PUT to the owner account changed a profile field and it stuck, so we put it back. A PUT that sets x_password on a super-admin, followed by a normal login, gave us a working session – and from there, full control of the console's SSH settings.

§ 03. One of US (becoming part of a botnet)

Ubiquiti published security advisory SAB-064 on 21 May 2026 addressing CVE-2026-34908, CVE-2026-34909, and CVE-2026-34910. Each vulnerability was assigned a CVSS score of 10.0 and, when chained, could allow an unauthenticated remote attacker to obtain root-level access to affected UniFi systems.

Bishop Fox subsequently demonstrated the complete exploit chain against UniFi OS Server 5.0.6. Ubiquiti addressed the vulnerabilities in UniFi OS Server 5.0.8, including unifi-core 5.0.153. The affected-product list published by Ubiquiti includes the UDM, UDM-Pro, UDM-SE, and UDM-Pro-Max, including the model deployed in the client environment.

On 23 June 2026, CISA added all three vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog, confirming that exploitation had been observed in the wild. Contemporary reporting associated some early exploitation with Mirai/Gafgyt-family botnet activity and described attackers creating unauthorized administrator accounts on compromised UniFi devices.

This activity is relevant to the present investigation because we independently identified rogue administrator accounts on the affected gateway. The overlap is consistent with publicly reported post-exploitation behavior; however, it does not by itself establish that the same campaign or threat actor was responsible for this compromise.

§ 04. A binary that no package owns

With the SSH password set through the bypass and the box rebooted – the client signed off on it – root SSH worked.

uid=0(root) gid=0(root) groups=0(root)
Linux UDM-Pro 4.19.152-ui-alpine … aarch64 GNU/Linux
eth8  UP  <wan-ip>/28 (WAN)   br0  192.168.1.1/24 (LAN)   uptime: up 2 min

The first thing that stood out was a file in /bin:

# dpkg -S /bin/unifi_updater
dpkg-query: no path found matching pattern /bin/unifi_updater

Legitimate UniFi binaries all belong to a package. This one did not. It was 4,097,312 bytes, owned by root, and set to run at every boot from root's crontab:

# /var/spool/cron/crontabs/root  (installed Sat 27 Jun 2026 20:50:49)
@reboot sleep 60 && /bin/unifi_updater

§ 05. One byte of anti-analysis

As found, the file breaks the usual tools – file, readelf, capa and stock YARA all call it "ELF 64-bit MSB, unknown arch 0xffffb700." One byte does that. EI_DATA, the fifth byte of the ELF header, records byte order, and it is set to 0x02 (big-endian) on a file whose fields are actually little-endian. The tools trust the flag, swap the machine-type bytes b7 00, and read a machine that does not exist. The ARM64 kernel ignores EI_DATA, so the file still runs. Set that byte back to 0x01 and it reads normally.

§ 06. GHOSTWORKER Static Analysis

Static analysis of the GHOSTWORKER binary identified functionality consistent with persistent gateway compromise, command-and-control, credential collection, host reconnaissance, and follow-on payload delivery.

Taken together, these capabilities are particularly significant because the implant was deployed on a network gateway. The device occupies a privileged position through which substantial network traffic passes, while GHOSTWORKER contains functionality to exploit that position: it can establish external command-and-control, retrieve additional payloads, manipulate firewall behavior, profile the local environment, and collect credentials exposed in accessible traffic.

Process Masquerading and Detection Opportunity

This provides a useful detection discriminator. Legitimate kworker processes are kernel threads and therefore do not execute from a conventional executable file on disk. GHOSTWORKER, by contrast, merely adopts the appearance of a kernel worker while remaining backed by a user-space executable.

A process displaying a [kworker/*] name should therefore be treated as suspicious if:

• /proc/<pid>/exe resolves to an executable file;
• /proc/<pid>/maps shows a conventional user-space executable mapping;
• the process maintains external network connections;
• the process has a normal command line or executable inode inconsistent with a kernel thread.

§ 07. Command-and-control over DoH

It does not beacon to an IP. It sends DNS-over-HTTPS to Google's public resolver – POST /dns-query to Host: dns.google on 8.8.8.8:443 – with its data packed into DNS names by that %s%c%08lx.%s%d builder, under a domain the operator controls. On the wire it is one more HTTPS connection to Google: no plaintext DNS to log, no unusual destination to flag. Every request carries a fake desktop-Chrome user agent (…rv:129.0… Chrome/129.0.0.0).

The crypto is what says this is not off-the-shelf. Three PEM blocks are baked into the binary:

• a self-signed CA certificate, CN=linfosyshosting.nl, valid 2020-07-17 to 2030-07-15;
• the private key that matches it – we confirmed the modulus;
• a separate 3072-bit RSA public key for verifying commands and encrypting what goes out.

Carrying the server's own private key means the channel is pinned and mutually authenticated: the implant only talks to something that holds this key. That protects the operator, and it gives defenders an exact thing to match on.

§ 08. The Linfosys infrastructure

The TLS certificate associated with GHOSTWORKER identifies the hostname linfosyshosting.nl. We resolved the domain using passive sources only and did not initiate any connection to the suspected command-and-control infrastructure. Passive DNS associated the hostname with 185.206.140.190.

RIPE registration and routing data show a consistent relationship between the hostname, the hosting network, and the DNS infrastructure used by the implant.

The infrastructure exhibits multiple points of naming consistency. The certificate hostname, DNS-tunnel nameservers, and network registration all contain the Linfosys identifier. Available registration data also indicate that both the certificate identity and relevant network registration pre-date this incident by several years, dating to approximately 2020.

Operator Access Infrastructure

The UniFi controller's admin_activity_log recorded administrative access from several external hosting-provider addresses during the compromise period:

Attribution Limitations

We do not attribute this activity to a named individual or to Linfosys BV.

The fact that RIPE records the C2 address space under the Linfosys name establishes a registration and routing relationship only. It does not establish who operated the GHOSTWORKER infrastructure. Plausible explanations include a customer using the network, a reseller or downstream operator, compromised infrastructure, or infrastructure intentionally selected because its naming and registration would appear legitimate.

The certificate itself also contains identity information that appears unreliable. Its organisation field identifies “Piratpartiet,” while other subject attributes combine geographic information from multiple unrelated jurisdictions. We therefore assess the certificate identity fields as likely fabricated or intentionally misleading and assign them no attribution value.

The strongest infrastructure finding is consequently not the nominal identity in the certificate, but the repeated technical correlation between the Linfosys-branded hostname, authoritative DNS infrastructure, and the autonomous system hosting the suspected C2.

§ 09. Someone was already inside

The controller's databases show an intrusion that started before we did. Two super-admin accounts were added outside the normal flow – unifi_support (17 June 2026) and supports_unifi_system (9 July 2026), both copying Ubiquiti's support naming, the same trick as the implant's filename. Neither shows up in the unique_logins table, which lists exactly one real user ever logging in. They were added directly, not logged into.

One pairing is hard to read as coincidence. supports_unifi_system was created at 19:56:12 UTC on 9 July, and a login from 185.44.78.8 lands at 19:56:18 – six seconds later. The implant's crontab was written 61 seconds after that same address's last admin-panel action on 27 June. We rank what we know by how sure we are:

• Confirmed. The device is vulnerable to the bypass and we used it. Two support-lookalike super-admins were added directly and tie to outside IPs. A header-tampered AArch64 implant with @reboot persistence, a [kworker] disguise, DoH C2, and an embedded certificate plus its private key was on the gateway. The certificate, its nameservers and its hosting network all carry the Linfosys name, and all date to 2020.
• Likely. It is one intruder, not several: the same primary IP covers the implant install and the admin logins, and the naming trick is consistent. Whoever it is knows the work – DoH tunnelling, a pinned certificate, a kernel-thread disguise and header tampering are well past botnet-grade tooling. The most probable story is an established operator using a fresh, actively-exploited bug against a device that happened to be exposed.
• Unproven. We cannot tie this to Linfosys the company. We did not watch the initial break-in. And we did not recover the beacon interval or the command set, because that needs running the sample, which we avoided so we would not touch the C2.

§ 10. Indicators of compromise

Everything below was seen during the assessment, with public registry data added where noted. We are holding back the client's live secrets and both private keys.

§ 11. What to look for

The bypass is easy to test, and the implant leaves cheap things to check. On UniFi, and on Linux edge devices generally:

• Test the bypass. If GET /proxy/users/api/v2/users returns 401 but the same path behind /api/auth/validate-sso/..%2f..%2f..%2f returns 200, you are exposed. Patch, and get the management interface off the public internet.
• Do not assume patching cleans up. After patching, check local admins for accounts added out of band – ones missing from unique_logins, especially support lookalikes – and compare admin_activity_log source IPs against your real admins.
• Look for the unpackaged binary. Anything in /bin or /sbin that dpkg -S cannot account for is worth a second look, and so is any @reboot cron entry that launches one.
• Look for the disguise. A process called [kworker/*] whose /proc/<pid>/exe resolves to a real file is not a kernel thread. Check for /var/tmp/a.tmp too, and for ELF files with EI_DATA=0x02 that still run.
• Watch outbound DoH from network gear. A gateway sending application/dns-message to a public resolver is the odd one out. Block or watch linfosyshosting.nl, *.linfosys.{nl,eu,com}, 185.206.140.190 and AS61351.
• If you find any of it, treat the device as fully compromised. Isolate it, keep the binary and logs, rebuild from clean firmware, and rotate every secret it held. Deleting the file is not enough.

§ 12. Why this matters

Edge gateways are easy to overlook. They face the internet, they are usually last in line for patches, everything behind them trusts them, and when they run a full software stack, one root compromise gives up the Wi-Fi key, the RADIUS secret, the controller databases, the video system, and a clear view of everything passing through.

There is nothing exotic in this case. A maximum-severity, publicly-disclosed, already-exploited UniFi bug sat exposed on an old console, and by the time a scheduled test reached it, someone had planted admin accounts and a root implant. The point is the timing: once a bug like this lands on the KEV list, the gap between disclosure and compromise for an exposed device is weeks, not months, and "we'll patch next cycle" is a bet you can lose before the cycle comes around.

We ran this as an authorised test and are publishing the attacker's indicators in full, so others can check their own estates for the same operator. If you run an internet-facing gateway, the fastest useful thing you can do today is the two-request test above – and then go looking for a [kworker] that owns a file.