# A Drone Autopilot Maker Got Its Domain Hijacked — and the Firmware Question Is What Should Keep You Up at Night
When the attacker took control of cubepilot.org on July 24, they didn't just redirect some web traffic. They walked into the digital front door of a company whose hardware guides UAVs used in Australian defense operations, Ukrainian battlefields, and agricultural fields across six continents — and they did it with a valid TLS certificate on every single subdomain.
That's not a phishing page. That's a trusted HTTPS connection to attacker-controlled infrastructure, indistinguishable from the real thing.
## What Actually Happened
CubePilot, the Australian maker of the Cube series autopilot controllers, confirmed that an unknown attacker seized control of its primary domain's DNS records sometime on July 24, 2026. For a window that day, traffic headed to CubePilot's OEM portal, community forum, and documentation platform was silently redirected to infrastructure the attacker controlled.
The mechanism that made this dangerous wasn't just the DNS hijack itself — it was what came next. The attacker rapidly obtained TLS certificates covering every cubepilot.org subdomain. This is the part of the disclosure that deserves more attention than it's getting.
In the certificate transparency ecosystem, anyone can request a cert for a domain they demonstrably control. Once an attacker controls your DNS, they control your domain. And once they control your domain, they can pass DV (domain validation) checks that certificate authorities use to issue HTTPS certificates. The whole trust chain — the padlock, the "Secure" indicator, the green bar some users still look for — becomes a weapon.
Users visiting CubePilot services on July 24 would have seen no browser warning. No red flag. Just a normal-looking HTTPS session, potentially handing over credentials to people they'd never heard of.
## What Was at Risk
CubePilot's disclosure is appropriately blunt: "Credentials entered on any of our services on 24 July may have been captured — the portal and the forum included." The company is telling users who reused those passwords anywhere else to change them now.
But the credential risk, while serious, isn't the most concerning part.
CubePilot has explicitly flagged firmware integrity as an open question. Any firmware images downloaded on July 24 or 25 should not be flashed onto hardware until the company completes its safety checks. Firmware obtained before July 24 is currently considered clean.
Think about what that means in practice. CubePilot's autopilot controllers — the Cube Orange, Cube Black, and their variants — run on drones doing precision agriculture, search and rescue, mapping, and military reconnaissance. If an attacker had positioned tampered firmware on CubePilot's download infrastructure during that window, the blast radius isn't a compromised login — it's a compromised UAV with corrupted flight software, potentially carrying sensors or payloads in environments where failure isn't just embarrassing.
The company hasn't confirmed firmware was tampered with. But the fact that they're checking tells you they can't rule it out.
## The Payment Fraud Vector Nobody Is Talking About
Buried at the bottom of CubePilot's advisory is a line that signals the attacker may have had broader ambitions than credential harvesting: clients who receive payment requests claiming to come from CubePilot should not act on them and should verify by phone with their usual contact.
This is business email compromise (BEC) logic applied to a DNS hijack. If the attacker had access to CubePilot's OEM portal and ERP infrastructure — even briefly, even read-only — they now have a customer list, outstanding invoices, and enough context to craft convincing payment redirection fraud. CubePilot's CEO, Philip Rowse, took the ERP portal offline as a precaution, which suggests the company is taking seriously the possibility that financial data was accessible.
## The Ukraine Connection and What It Implies
CubePilot has publicly backed Ukraine's defense effort. Its hardware has been delivered to the country, including through formal Australian government assistance. The company's products are documented in open-source Ukrainian military UAV configurations.
That context matters when attributing motivation to this attack. DNS hijacking requires either compromising the registrar account, exploiting a registrar vulnerability, or social engineering the registrar's support function. It's not a trivial attack — it takes planning and specific targeting. Opportunistic credential harvesters don't usually pursue small Australian drone hardware companies.
Nation-state or hacktivist groups with interest in Ukrainian defense supply chains, on the other hand, have both motive and demonstrated capability for exactly this type of infrastructure attack. CubePilot has reported the incident to the Australian Cyber Security Centre and law enforcement. Whether attribution follows is another question.
## What This Means for Defenders in the Supply Chain
CubePilot's response — revoking fraudulently issued certificates, preserving forensic evidence, coordinating with the ACSC, taking services offline — is the right playbook. But this incident surfaces a structural problem that good incident response can't fully fix after the fact.
Registrar-level controls matter more than most security programs treat them. Registry lock (also called "domain lock" or "super lock" depending on the registrar) prevents DNS record changes without out-of-band confirmation. It's available from most serious registrars and is specifically designed to stop this attack. Multi-factor authentication on registrar accounts and monitoring DNS records for unexpected changes via services like DNSWatch or similar should be baseline hygiene for any company with operational infrastructure.
Certificate transparency monitoring is underutilized. Services like crt.sh log every TLS certificate issued publicly. Monitoring your own domains in CT logs catches fraudulent certificate issuance within minutes of it happening — not after users have already been redirected.
Firmware signing and verification is the answer the drone industry hasn't fully implemented. If CubePilot's firmware images were cryptographically signed with an offline key, and autopilot hardware verified that signature before flashing, a compromised distribution channel wouldn't matter. The firmware would fail verification and refuse to install. This is not exotic technology — it's what secure boot on servers has done for years.
---
## HackWire Analysis
The CubePilot incident is a clean case study in why "trust the padlock" is outdated security advice — and why the defense industrial base, including its supply chain vendors, is increasingly attractive to sophisticated attackers.
What makes this incident worth tracking beyond the immediate disclosure: CubePilot sits at an interesting intersection of commercial availability and defense utility. Cube autopilots are open-source-adjacent, widely documented, and show up in both hobbyist builds and military UAV platforms. That dual-use profile means attackers can study the hardware and software in public forums, map the customer base from conference talks and press releases, and target the vendor knowing their reach extends into defense supply chains.
The DNS hijack technique itself is not new — it was used against Brazilian banks in 2017 in a brazen full-domain takeover and has appeared in nation-state playbooks targeting government contractors. What's changed is the normalization of wildcard certificate issuance through automated CAs, which means the attacker's window to create a convincing fake is shorter but more capable than ever before.
The buried story in this disclosure is firmware. Nobody is covering the supply chain angle seriously. If even a handful of UAVs operating in sensitive environments flashed a tampered image on July 24-25, the full consequence of this attack won't be clear for months — or until something fails in the field. Security teams protecting vendors in the defense supply chain should look at this incident and immediately audit whether their registrar accounts have registry lock enabled and whether their firmware distribution pipeline can detect unauthorized modifications.
CubePilot appears to be handling this well. The question is whether the broader drone manufacturing ecosystem learns from it before someone with worse intentions, and better operational security, tries the same thing.
— HackWire Editorial
---
## Related Coverage