On July 24, CubePilot, an Australian designer of flight controllers for drones and unmanned aerial vehicles (UAVs), suffered a sophisticated DNS hijacking attack that allowed a threat actor to intercept traffic destined for internal systems and obtain valid TLS certificates for every subdomain under cubepilot.org. The breach, which the company disclosed in a security notice on its website, exposed users who visited CubePilot’s portal or community forum on that day to potential credential theft, malware delivery, and phishing — all behind a facade of legitimate HTTPS connections. The incident underscores a growing threat vector targeting critical infrastructure and defense supply chains, as CubePilot’s products are used in surveying, agriculture, search and rescue, and, notably, government and defense applications, including support for Ukraine.
How the DNS Hijacking Attack Worked and What It Means for Users
Domain Name System (DNS) hijacking is a technique in which an attacker gains unauthorized access to a domain’s DNS settings and redirects traffic intended for a legitimate website to a server under the attacker’s control. In CubePilot’s case, the attacker seized control of the cubepilot.org domain on July 24, altering DNS records so that users trying to reach services such as the community forum, documentation portal, or authentication systems were instead directed to malicious infrastructure. Because the attacker also procured TLS certificates — through the Domain Validation process, which requires only proof of control over the domain — every subdomain of cubepilot.org appeared to have valid HTTPS connections. Visitors saw the familiar padlock icon in their browsers, providing a false sense of security while their credentials, session tokens, and other sensitive data were captured.
“The certificates obtained by the attacker covered every cubepilot.org subdomain, so credentials entered on any of our services on 24 July may have been captured — the portal and the forum included,” CubePilot stated in its announcement. The company warned users who reused passwords across other platforms to change them immediately, as the credential harvesting could lead to account takeovers on unrelated services.
What Is DNS Hijacking and Why Is It Dangerous?
DNS hijacking occurs when an attacker modifies the DNS records of a domain — typically through compromised registrar credentials, insecure DNS provider accounts, or social engineering — to point domain names to malicious IP addresses. When a user types a legitimate URL, the DNS system resolves it to the attacker’s server instead of the real one. Because the attacker can also obtain valid TLS certificates through automated certificate authority (CA) challenges that verify domain control, the connection appears fully secure. The result is a man-in-the-middle scenario that bypasses traditional browser warnings and can capture login credentials, API keys, financial data, or deliver malware through seemingly authentic downloads. Unlike phishing via deceptive URLs, DNS hijacking exploits the trust placed in the domain name itself, making it especially insidious for enterprises and users who rely on known addresses.
Timeline of the Incident and CubePilot’s Response
According to the company’s status update, the attacker gained control of the cubepilot.org DNS settings on July 24. Within hours, CubePilot detected the anomaly and acted swiftly: by the end of that same day, it regained control of its domains, revoked all fraudulently issued TLS certificates, preserved forensic evidence, notified relevant domain registrars and certificate authorities, and reported the incident to the Australian Cyber Security Centre (ACSC) and law enforcement.
CubePilot also took precautionary measures, taking offline its OEM services, community forum, and documentation portal to prevent further exposure. Philip Rowse, CubePilot’s CEO, stated on LinkedIn that the company’s ERP portal was also disconnected as a safety measure while the investigation continued. The company committed to notifying any affected entities directly where confirmed impact is identified through its ongoing probe.
What Users Should Do If They Visited CubePilot Services on July 24
CubePilot advises any user who accessed the portal, forum, or other cubepilot.org subdomains on July 24 to consider their credentials compromised. The most critical step is to change the password used on CubePilot services immediately — and to change the same or similar passwords on any other accounts, since credential stuffing attacks often follow such data captures. Users should also enable multi-factor authentication where available, monitor for suspicious activity, and be cautious of any unexpected communications purporting to be from CubePilot. The company specifically warned clients not to act on any payment requests received in the wake of the incident without verifying them over the phone with their usual contact.
Firmware Integrity Concerns and Risk of Compromised Downloads
Beyond credential theft, the DNS hijacking attack raises serious questions about the integrity of firmware and software images that may have been downloaded during the compromise window. CubePilot confirmed that it is evaluating all firmware images that were available on its services between July 24 and 25, and advised users not to flash any images downloaded during that period until checks confirm their safety. Firmware obtained before July 24 is currently considered safe to use. This caution is warranted: if the attacker had replaced a legitimate firmware image with a malicious version, drones equipped with that firmware could become remotely controllable, have their navigation data intercepted, or be rendered inoperable — with potentially catastrophic consequences in defense or search-and-rescue operations.
The company has not yet disclosed whether any firmware tampering occurred. Given that the attacker had full control over DNS and could serve malicious content, the risk is non-trivial. CubePilot’s ongoing investigation will need to verify the cryptographic signatures and hashes of all published images against known-good versions.
CubePilot’s Role in Defense and the Geopolitical Dimension
CubePilot, headquartered in Australia, is a key player in the UAV components market. Its “autopilots” and navigation hardware are used in a wide range of applications — from commercial surveying to military reconnaissance. The company has publicly expressed support for Ukraine in its war against Russian aggression, and its products have been included in Australian government aid packages delivered to Ukraine. This context makes the DNS hijacking especially sensitive. State-aligned threat actors have a history of targeting companies that supply defense technology to Ukraine, and DNS attacks have been a staple of hybrid warfare. While CubePilot has not identified the perpetrator, the timing and nature of the attack suggest a deliberate operation aimed at compromising the supply chain or harvesting intelligence on Ukrainian drone operations.
Even without geopolitical attribution, the incident highlights the vulnerability of small-to-medium enterprises that support critical infrastructure. CubePilot is not a giant corporation with a dedicated security operations center; it is a specialized engineering firm whose core competence is hardware and embedded software, not cybersecurity. Attackers recognize this asymmetry and increasingly target suppliers as entry points into larger ecosystems.
DNS Hijacking: A Growing Threat That Bypasses Traditional Defenses
CubePilot’s attack is far from isolated. DNS hijacking has been used in high-profile campaigns, including the 2019 attack on the Israeli cybersecurity firm Check Point, the 2020 SolarWinds-related domain compromises, and numerous financial institution breaches. The technique is especially attractive because it evades endpoint detection tools — the traffic goes to a legitimate-looking address over HTTPS, and no malware needs to be installed on the user’s device for the initial data capture.
Recent trends show that threat actors are increasingly targeting DNS providers and domain registrar accounts, often using credential theft or social engineering to bypass multi-factor authentication. For organizations without robust domain security controls — such as registry locks, DNSSEC (DNS Security Extensions), and strict registrar account protections — a single compromised password can lead to total domain takeover. CubePilot has not detailed whether DNSSEC was in place, but its ability to regain control within hours suggests some level of monitoring and incident response capability.
How Organizations Can Defend Against DNS Hijacking
To mitigate the risk of DNS hijacking, organizations should implement a layered approach: use domain registrars that offer registry lock services, requiring out-of-band verification (such as phone calls or physical tokens) for any changes to DNS settings; enable DNSSEC to cryptographically sign DNS records, making it harder for attackers to serve forged responses; employ account hygiene with strong, unique passwords and hardware-based multi-factor authentication for all DNS management accounts; monitor certificate transparency logs for unauthorized TLS certificate requests; and maintain offline backups of DNS zone files for rapid recovery. Additionally, organizations should have a pre-authorized incident response plan that includes immediate domain lock down, certificate revocation, and communication channels with providers and law enforcement.
For CubePilot customers, the immediate practical steps are clear: change passwords, enable MFA, verify firmware integrity before use, and treat any unsolicited payment requests as suspicious until confirmed.
The Strategic Implications for the Drone Industry and Supply Chain Security
The CubePilot incident serves as a wake-up call for the broader UAV and autonomous systems industry. As drones become integral to defense, infrastructure inspection, and precision agriculture, the security of their software supply chain is paramount. A compromised flight controller firmware could turn a drone into a weapon, a surveillance tool for adversaries, or simply a destructive projectile. The attack also exposes the vulnerability of smaller firms that are nodes in larger supply chains — governments and prime contractors must consider mandating cybersecurity standards for all vendors, not just those with large IT departments.
CubePilot’s transparency in the aftermath — publishing a detailed security notice, taking services offline proactively, cooperating with national cybersecurity authorities — is commendable. However, the incident also reveals gaps in the security posture of even well-regarded engineering firms. The ability of an attacker to obtain TLS certificates for all subdomains in under a day suggests that automated validation at certificate authorities is still too permissive when domain control is transiently compromised. Calls for shorter certificate lifetimes and more robust domain validation checks may gain momentum.
What Happens Next for CubePilot and Its Users
CubePilot has pledged to notify affected parties as its investigation confirms the scope of the breach. The company is likely working with forensic analysts to determine whether any data exfiltration occurred beyond credential capture, and whether firmware images were tampered with. Users should expect an updated advisory once the firmware integrity checks are complete. The company’s ERP and portal services will remain offline until the investigation concludes and a safe restoration plan is in place.
For the broader community, this incident reinforces the need for domain-level security hygiene and constant vigilance. DNS hijacking is not a new attack, but its combination with subdomain-wide TLS certificate fraud makes it increasingly difficult to detect. The best defense is a proactive one — securing domain registrars, monitoring DNS changes in real time, and educating users that the presence of a padlock icon is no guarantee of a server’s legitimacy when the domain itself has been hijacked. CubePilot’s experience is a stark reminder that in today’s threat landscape, even a trusted domain can become a trap.
