CubePilot Drone Maker Hit by DNS Hijacking and Rogue Certificates

An Australian company that builds flight controllers for drones has told its customers to assume their passwords are compromised. CubePilot confirmed that an attacker seized its domain records on 24 July, and the DNS hijacking diverted traffic to systems the intruder controlled. Anyone who logged into a company service that day may have handed their credentials straight to the attacker.

The CubePilot DNS hijacking has taken several systems offline. It also left an open question about the firmware the company published during the attack window.

How the CubePilot DNS hijacking attack worked

Domain name system records act as the address book of the internet. They tell a browser which server to contact when someone types a web address. An attacker who controls those records can point a legitimate domain at any server they choose. Visitors see the address they expect, but their traffic travels somewhere else entirely.

That is exactly what happened here. The incident placed the attacker between users and the company's own services. From that position, intercepting logins, delivering malware, and running phishing pages all become straightforward.

The company has not disclosed how the attacker reached its DNS settings. Registrar account compromise, stolen credentials, and social engineering all remain plausible, but nothing is confirmed.

Valid certificates removed the usual warning signs

Redirecting traffic is only half the job. A browser normally objects when a site presents a certificate that does not match its domain. That warning stops most people before they type anything.

The attacker never faced that obstacle. They obtained TLS certificates covering every cubepilot.org subdomain. Users who landed on the fraudulent infrastructure saw a working HTTPS connection and a padlock in the address bar. Nothing on screen suggested they were anywhere other than the real site.

So the CubePilot DNS hijacking cleared both hurdles at once. The company has been direct about the consequence. Credentials entered on any of its services on 24 July may have reached the attacker, including those for the customer portal and the community forum. Anyone reusing those passwords elsewhere should change them now.

CubePilot's response to the DNS hijacking

CubePilot regained control of its domains on 24 July, the same day the attack began. It revoked the fraudulently issued certificates, preserved forensic evidence, and notified the relevant providers. The company also reported the incident to the Australian Cyber Security Centre and to law enforcement.

Several systems remain down. OEM services, the community forum, and the documentation portal are all offline. The company pulled its ERP portal as a precaution while the investigation continues.

CubePilot has committed to contacting affected parties directly once its investigation confirms the scope. Until then, users active on 24 July should assume their password reached the attacker.

Firmware downloads remain under review

The CubePilot DNS hijacking left one question that matters more than the rest. The company is still evaluating the firmware images it published during the attack window. It has advised users not to flash anything downloaded on 24 or 25 July until those checks finish. Firmware obtained before 24 July remains safe to use.

That distinction carries weight because these are not desktop applications. CubePilot designs autopilots and navigation hardware for aircraft that fly over people, property, and open terrain. Tampered firmware on that class of device creates physical risk, not only data exposure.

Fraudulent payment requests are already a concern

CubePilot has also warned clients about invoice fraud. Anyone receiving a payment request that appears to come from the company should hold off. The safer route is a phone call to a known contact for confirmation.

The warning fits a familiar pattern. Attackers who gain visibility into a company's traffic often follow up with financial fraud. Harvested credentials, intercepted messages, and knowledge of pending orders give them enough material to write a convincing invoice.

Why this particular target stands out

CubePilot builds navigation systems for UAVs used in surveying, search and rescue, agriculture, defense, and government work. That customer base spans commercial operators and state agencies. The company has also publicly backed Ukraine, and its products reached the country through an Australian government assistance package.

Nobody has linked the CubePilot DNS hijacking to a named threat actor, and the company has not speculated publicly. Still, the target profile deserves attention. Suppliers to defense and government programs draw interest that ordinary hardware vendors do not.

Domain records are a soft target

DNS infrastructure sits outside the systems most security teams watch closely. Records live with a registrar or a DNS provider, often behind a single account with thin oversight. That account becomes a single point of failure for every service the domain touches.

Registrar locks and multi-factor authentication on provider accounts raise the cost of an attack considerably. Certificate Authority Authorization records limit which authorities can issue certificates for a domain. Certificate Transparency monitoring adds a further layer, because it surfaces newly issued certificates within minutes.

The CubePilot DNS hijacking succeeded because it stripped away every signal users rely on. The address was correct and the padlock was there. Everything looked right, and none of it was.

For anyone who signed into a CubePilot service on 24 July, one action still matters most. Change that password, and change it everywhere else it was reused.