Vigilance in Action: Monitoring Typosquatting Domains
Cado researchers detected a typosquatting domain mimicking their corporate site, part of a broader campaign targeting tech companies. The malicious domain redirected to the legitimate one, and an accompanying fake X (Twitter) account was created. Cado took swift action, informing staff, blocking emails, and reporting the domain for suspension.
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Allan Carchrie
Lead Solutions Engineer
Share
21
Aug 2024
Introduction
In today's digital landscape, cybercriminals are constantly devising new and innovative ways to infiltrate and compromise corporate systems. One such tactic is called typosquatting: the registration of domains that closely resemble a real organization in order to trick users into visiting a fraudulent website. Before any damage could be done, researchers at Cado Security Labs (now part of Darktrace) recently discovered a domain that bore a striking resemblance to the Cado corporate domain during a routine check. In this blog, we will discuss how this domain was identified, and the steps taken following discovery.
Look and you shall find
Monitoring for spoofed domains is a function that helps a threat intel team detect malicious actors preparing their infrastructure for their campaigns. This early detection can prevent potential attacks and protect an organization's reputation and assets from harm.
At Cado Security (now Darktrace), this issue is proactively addressed using a tool called “ dnstwist “ - a powerful domain generation and lookup tool that helps identify domains that could be used as part of phishing attacks. For example, using the corporate domain, cadosecurity.com, dnstwist generated nearly 9,000 permutations of the Cado domain and attempted DNS resolutions of them.
Not if, but when..
During a routine check, Cado discovered that just three days prior, a domain had been registered that contained a character substitution similar to what is seen for typosquatting attacks, highlighting that a potential threat was emerging.
Typosquatting attacks are typically done by deliberately including typos, numbers, or symbols in the domain name that a user might accidentally type or with a quick glance might consider to be legitimate. This might involve adding an extra character, such as "Cadosecurityy.com," or replacing a letter with a similar-looking number or symbol, like "Cado5ecurity.com" or "Cad0security.com" (using a zero instead of the letter 'O'). Another variation of typosquatting is the homoglyph or homograph attack, which uses characters (or glyphs) from other scripts that are very visually similar to register domains that may fool a user. For example, using Cyrillic characters mixed with Latin characters, an attacker might create a domain like "Сadosecurity.com," where the 'C' is replaced with its Cyrillic counterpart, which looks almost identical.
Once this domain was identified, it was quickly discovered that connections to the malicious domain were being redirected to Cado’s legitimate domain. This redirection indicates that the threat actor behind this activity was likely intending to imitate the domain, potentially as part of a future phishing attack.
Upon further investigation, Cado found that this malicious domain was registered through “Apiname” and resolved to IP address 94[.]154[.]35[.]15. Open Source Intelligence analysis revealed that not only was the domain being mimicked, but also several other tech companies' domains have been targeted in a similar fashion. This suggests that it was created as part of a broader campaign to target a large number of brands. Where possible, the affected companies were notified prior to this blog being released.
The threat actor also created an X (formerlyTwitter) account as Cado with the typo’d domain mimicking our own X account and in one instance, they had taken it as far as purchasing a Gold Checkmark, adding followers, and following people related to Cado, in order to create a sense of authenticity.
Figure 1: Fake Cado Security account created by threat actor using typo'd username
Figure 2: Fake Cado Security account profile created by threat actor using typo'd username
As seen with the other tech related companies that were also victims of the same domain registration typo activity, Cado found the threat actor had also created X accounts for some of those companies as well.
Actions speak louder than words
When Cado identified that the malicious domain was redirecting to its website, the following proactive actions were taken:
Informed all staff about the current situation and reminded them of the actions they should take. Fostering a security-conscious culture where everyone plays their part in defending against cyber threats is key for a business’ cyber security posture. Ensure your cyber security training is always updated to reflect the latest threats, and that staff are briefed on a routine basis. By investing time and resources into employee cybersecurity education, businesses can significantly reduce the risk of a breach, protect sensitive information, and maintain smooth operations.
Searched for any emails originating from the malicious domain, and implemented alerting and a block for future emails. By doing so, threat actors were unable to send malicious content or phishing attempts to staff inboxes. This step not only protects team members, but also limits the potential damage caused by any malicious emails.
Reported the activity to the DNS registrar who subsequently suspended the domain. By taking this action, not only was the issue addressed at hand, but it also contributed to the overall security of the internet by having a potentially malicious domain taken offline.
Additional typosquatting domains identified
Where possible the organizations included below have all been alerted regarding these fraudulent domains.
URLs
biaizetech[.]com
cadosecurlty[.]com
changeliy[.]com
ciickup[.]com
elliptlc[.]com
miikroad[.]com
ogiivy[.]com
q0nt0[.]com
raiiwayapp[.]com
scrlb3[.]com
sh0rtcut[.]com
slgmaprime[.]com
slnglegrain[.]com
spndesk[.]com
twinmotlon[.]com
tlnulti[.]com
0penraven[.]com
IP addresses
94[.]154[.]35[.]15
The key takeaway
This discovery underscores the importance of staying vigilant and proactive in protecting against such potential threats. It also highlights the need to monitor domain registrations, especially those that closely resemble our own, as well as staying abreast of the latest cybersecurity trends and best practices. By being aware of these potential risks and taking adequate measures to secure our domains, teams can collectively work towards mitigating the impact of such activities on organizations and the broader tech industry.
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Cloud has changed everything, but investigations haven’t kept up. With breaches hitting cloud data and attackers moving faster than ever, legacy forensics are too slow, too manual, and too fragmented. It’s time for a cloud-first approach: automated, unified, and built for today’s speed of attack.
Unpacking the Salesloft Incident: Insights from Darktrace Observations
Darktrace identified anomalous activity within its customer base linked to a supply chain attack exploiting Salesloft integrations in August 2025. Learn about the campaign and how Darktrace detects and responds to such threats using AI-driven threat detection and Autonomous Response capabilities.
How Organizations are Addressing Cloud Investigation and Response
The importance of cloud investigation and incident response are compounded by an expanded attack surface in the cloud, lack of advanced tooling to upskill teams, and increasing regulatory pressure from compliance regulations. This blog dives into these challenges and explores potential solutions for security teams attempting to secure their cloud environment
Cloud adoption has revolutionized how businesses operate, offering speed, scalability, and flexibility. But for security teams, this transformation has introduced a new set of challenges, especially when it comes to incident response (IR) and forensic investigations.
Cloud-related breaches are skyrocketing – 82% of breaches now involve cloud-stored data (IBM Cost of a Data Breach, 2023). Yet incidents often go unnoticed for days: according to a 2025 report by Cybersecurity Insiders, of the 65% of organizations experienced a cloud-related incident in the past year, only 9% detected it within the first hour, and 62% took more than 24 hours to remediate it (Cybersecurity Insiders, Cloud Security Report 2025).
Despite the shift to cloud, many investigation practices remain rooted in legacy on-prem approaches. According to a recent report, 65% of organizations spend approximately 3-5 days longer when investigating an incident in the cloud vs. on premises.
Cloud investigations must evolve, or risk falling behind attackers who are already exploiting the cloud’s speed and complexity.
4 Reasons Cloud Investigations Are Broken
The cloud’s dynamic nature – with its ephemeral workloads and distributed architecture – has outpaced traditional incident response methods. What worked in static, on-prem environments simply doesn’t translate.
Here’s why:
Ephemeral workloads Containers and serverless functions can spin up and vanish in minutes. Attackers know this as well – they’re exploiting short-lived assets for “hit-and-run” attacks, leaving almost no forensic footprint. If you’re relying on scheduled scans or manual evidence collection, you’re already too late.
Fragmented tooling Each cloud provider has its own logs, APIs, and investigation workflows. In addition, not all logs are enabled by default, cloud providers typically limit the scope of their logs (both in terms of what data they collect and how long they retain it), and some logs are only available through undocumented APIs. This creates siloed views of attacker activity, making it difficult to piece together a coherent timeline. Now layer in SaaS apps, Kubernetes clusters, and shadow IT — suddenly you’re stitching together 20+ tools just to find out what happened. Analysts call it the ‘swivel-chair Olympics,’ and it’s burning hours they don’t have.
SOC overload Analysts spend the bulk of their time manually gathering evidence and correlating logs rather than responding to threats. This slows down investigations and increases burnout. SOC teams are drowning in noise; they receive thousands of alerts a day, the majority of which never get touched. False positives eat hundreds of hours a month, and consequently burnout is rife.
Cost of delay The longer an investigation takes, the higher its cost. Breaches contained in under 200 days save an average of over $1M compared to those that linger (IBM Cost of a Data Breach 2025).
These challenges create a dangerous gap for threat actors to exploit. By the time evidence is collected, attackers may have already accessed or exfiltrated data, or entrenched themselves deeper into your environment.
What’s Needed: A New Approach to Cloud Investigations
It’s time to ditch the manual, reactive grind and embrace investigations that are automated, proactive, and built for the world you actually defend. Here’s what the next generation of cloud forensics must deliver:
Automated evidence acquisition Capture forensic-level data the moment a threat is detected and before assets disappear.
Unified multi-cloud visibility Stitch together logs, timelines, and context across AWS, Azure, GCP, and hybrid environments into a single unified view of the investigation.
Accelerated investigation workflows Reduce time-to-insight from hours or days to minutes with automated analysis of forensic data, enabling faster containment and recovery.
Empowered SOC teams Fully contextualised data and collaboration workflows between teams in the SOC ensure seamless handover, freeing up analysts from manual collection tasks so they can focus on what matters: analysis and response.
Attackers are already leveraging the cloud’s agility. Defenders must do the same — adopting solutions that match the speed and scale of modern infrastructure.
Cloud Changed Everything. It’s Time to Change Investigations.
The cloud fundamentally reshaped how businesses operate. It’s time for security teams to rethink how they investigate threats.
Forensics can no longer be slow, manual, and reactive. It must be instant, automated, and cloud-first — designed to meet the demands of ephemeral infrastructure and multi-cloud complexity.
The future of incident response isn’t just faster. It’s smarter, more scalable, and built for the environments we defend today, not those of ten years ago.
Darktrace's latest investigation uncovered a novel campaign that blends traditional malware with modern devops technology.
At the center of this campaign is a Python-based command-and-control (C2) framework hosted on GitHub CodeSpaces. This campaign also utilizes a Python based spreader with a multi-stage Docker deployment as the initial access vector.
The campaign further makes use of a Go-based Remote Access Trojan (RAT) that implements a RESTful registration and polling mechanism, enabling command execution and communication with its operators.
ShadowV2 attack techniques
What sets this campaign apart is the sophistication of its attack toolkit.
The threat actors employ advanced methods such as HTTP/2 rapid reset, a Cloudflare under attack mode (UAM) bypass, and large-scale HTTP floods, demonstrating a capability to combine distributed denial-of-service (DDoS) techniques with targeted exploitation.
With the inclusion of an OpenAPI specification, implemented with FastAPI and Pydantic and a fully developed login panel and operator interface, the infrastructure seems to resemble a “DDoS-as-a-service” platform rather than a traditional botnet, showing the extent to which modern malware increasingly mirrors legitimate cloud-native applications in both design and usability.
Analysis of a SadowV2 attack
Initial access
The initial compromise originates from a Python script hosted on GitHub CodeSpaces. This can be inferred from the observed headers:
User-Agent: docker-sdk-python/7.1.0
X-Meta-Source-Client: github/codespaces
The user agent shows that the attacker is using the Python Docker SDK, a library for Python programs that allows them to interact with Docker to create containers. The X-Meta-Source-Client appears to have been injected by GitHub into the request to allow for attribution, although there is no documentation online about this header.
The IP the connections originate from is 23.97.62[.]139, which is a Microsoft IP based in Singapore. This aligns with expectations as GitHub is owned by Microsoft.
This campaign targets exposed Docker daemons, specifically those running on AWS EC2. Darktrace runs a number of honeypots across multiple cloud providers and has only observed attacks against honeypots running on AWS EC2. By default, Docker is not accessible to the Internet, however, can be configured to allow external access. This can be useful for managing complex deployments where remote access to the Docker API is needed.
Typically, most campaigns targeting Docker will either take an existing image from Docker Hub and deploy their tools within it, or upload their own pre-prepared image to deploy. This campaign works slightly differently; it first spawns a generic “setup” container and installs a number of tools within it. This container is then imaged and deployed as a live container with the malware arguments passed in via environmental variables.
Figure 1: Attacker creates a blank container from an Ubuntu image.
Figure 2: Attacker sets up their tools for the attack.
Figure 3: Attacker deploys a new container using the image from the setup container.
It is unclear why the attackers chose this approach - one possibility is that the actor is attempting to avoid inadvertently leaving forensic artifacts by performing the build on the victim machine, rather than building it themselves and uploading it.
Malware analysis
The Docker container acts as a wrapper around a single binary, dropped in /app/deployment. This is an ELF binary written in Go, a popular choice for modern malware. Helpfully, the binary is unstripped, making analysis significantly easier.
The current version of the malware has not been reported by OSINT providers such as VirusTotal. Using the domain name from the MASTER_ADDR variable and other IoCs, we were able to locate two older versions of the malware that were submitted to VirusTotal on the June 25 and July 30 respectively [1] [2]. Neither of these had any detections and were only submitted once each using the web portal from the US and Canada respectively. Darktrace first observed the attack against its honeypot on June 24, so it could be a victim of this campaign submitting the malware to VirusTotal. Due to the proximity of the start of the attacks, it could also be the attacker testing for detections, however it is not possible to know for certain.
The malware begins by phoning home, using the MASTER_ADDR and VPS_NAME identifiers passed in from the Docker run environmental variables. In addition, the malware derives a unique VPS_ID, which is the VPS_NAME concatenated with the current unix timestamp. The VPS_ID is used for all communications with the C2 server as the identifier for the specific implant. If the malware is restarted, or the victim is re-infected, the C2 server will inform the implant of its original VPS_ID to ensure continuity.
Figure 4: Snippet that performs the registration by sending a POST request to the C2 API with a JSON structure.
From there, the malware then spawns two main loops that will remain active for the lifetime of the implant. Every second, it sends a heartbeat to the C2 by sending the VPS_ID to hxxps://shadow.aurozacloud[.]xyz/api/vps/heartbeat via POST request. Every 5 seconds, it retrieves hxxps://shadow.aurozacloud[.]xyz/api/vps/poll/<VPS ID> via a GET request to poll for new commands.
Figure 5: The poll mechanism.
At this stage, Darktrace security researchers wrote a custom client that ran on the server infected by the attacker that mimicked their implant. The goal was to intercept commands from the C2. Based on this, it was observed initiating an attack against chache08[.]werkecdn[.]me using a 120 thread HTTP2 rapid reset attack. This site appears to be hosted on an Amsterdam VPS provided by FDCServers, a server hosting company. It was not possible to identify what normally runs on this site, as it returns a 403 Forbidden error when visited.
Darktrace’s code analysis found that the returned commands contain the following fields:
Method (e.g. GET, POST)
A unique ID for the attack
A URL endpoint used to report attack statistics
The target URL & port
The duration of the attack
The number of threads to use
An optional proxy to send HTTP requests through
The malware then spins up several threads, each running a configurable number of HTTP clients using Valyala’s fasthttp library, an open source Go library for making high-performance HTTP requests. After this is complete, it uses these clients to perform an HTTP flood attack against the target.
Figure 6: A snippet showing the fasthttp client creation loop, as well as a function to report the worker count back to the C2.
In addition, it also features several flags to enable different bypass mechanisms to augment the malware:
WordPress bypass (does not appear to be implemented - the flag is not used anywhere)
Random query strings appended to the URL
Spoofed forwarding headers with random IP addresses
Cloudflare under-attack-mode (UAM) bypass
HTTP2 rapid reset
The most interesting of these is the Cloudflare UAM bypass mechanism. When this is enabled, the malware will attempt to use a bundled ChromeDP binary to solve the Cloudflare JavaScript challenge that is presented to new visitors. If this succeeds, the clearance cookie obtained is then included in subsequent requests. This is unlikely to work in most cases as headless Chrome browsers are often flagged, and a regular CAPTCHA is instead served.
Figure 7: The UAM bypass success snippet.
Additionally, the malware has a flag to enable an HTTP2 rapid reset attack mode instead of a regular HTTP flood. In HTTP2, a client can create thousands of requests within a single connection using multiplexing, allowing sites to load faster. The number of request streams per connection is capped however, so in a rapid reset attack many requests are made and then immediately cancelled to allow more requests to be created. This allows a single client to execute vastly more requests per second and use more server resources than it otherwise would, allowing for more effective denial-of-service (DoS) attacks.
Figure 8: The HTTP2 rapid reset snippet from the main attack function.
API/C2 analysis
As mentioned throughout the malware analysis section, the malware communicates with a C2 server using HTTP. The server is behind Cloudflare, which obscures its hosting location and prevents analysis. However, based on analysis of the spreader, it's likely running on GitHub CodeSpaces.
When sending a malformed request to the API, an error generated by the Pydantic library is returned:
This shows they are using Python for the API, which is the same language that the spreader is written in.
One of the larger frameworks that ships with Pydantic is FastAPI, which also ships with Swagger. The malware author left this publicly exposed, and Darktrace’s researchers were able to obtain a copy of their API documentation. The author appears to have noticed this however, as subsequent attempts to access it now returns a HTTP 404 Not Found error.
Figure 9: Swagger UI view based on the obtained OpenAPI spec.
This is useful to have as it shows all the API endpoints, including the exact fields they take and return, along with comments on each endpoint written by the attacker themselves.
It is very likely a DDoS for hire platform (or at the very least, designed for multi-tenant use) based on the extensive user API, which features authentication, distinctions between privilege level (admin vs user), and limitations on what types of attack a user can execute. The screenshot below shows the admin-only user create endpoint, with the default limits.
Figure 10: The admin-only user create endpoint.
The endpoint used to launch attacks can also be seen, which lines up with the options previously seen in the malware itself. Interestingly, this endpoint requires a list of zombie systems to launch the attack from. This is unusual as most DDoS for hire services will decide this internally or just launch the attack from every infected host (zombie). No endpoints that returned a list of zombies were found, however, it’s possible one exists as the return types are not documented for all the API endpoints.
Figure 11: The attack start endpoint.
There is also an endpoint to manage a blacklist of hosts that cannot be attacked. This could be to stop users from launching attacks against sites operated by the malware author, however it’s also possible the author could be attempting to sell protection to victims, which has been seen previously with other DDoS for hire services.
Figure 12: Blacklist endpoints.
Attempting to visit shadow[.]aurozacloud[.]xyz results in a seizure notice. It is most likely fake the same backend is still in use and all of the API endpoints continue to work. Appending /login to the end of the path instead brings up the login screen for the DDoS platform. It describes itself as an “advanced attack platform”, which highlights that it is almost certainly a DDoS for hire service. The UI is high quality, written in Tailwind, and even features animations.
Figure 13: The fake seizure notice.
Figure 14: The login UI at /login.
Conclusion
By leveraging containerization, an extensive API, and with a full user interface, this campaign shows the continued development of cybercrime-as-a-service. The ability to deliver modular functionality through a Go-based RAT and expose a structured API for operator interaction highlights how sophisticated some threat actors are.
For defenders, the implications are significant. Effective defense requires deep visibility into containerized environments, continuous monitoring of cloud workloads, and behavioral analytics capable of identifying anomalous API usage and container orchestration patterns. The presence of a DDoS-as-a-service panel with full user functionality further emphasizes the need for defenders to think of these campaigns not as isolated tools but as evolving platforms.
uint16(0) == 0x457f and (2 of ($string*) or 2 of ($symbol*) or any of ($code*))
}
The content provided in this blog is published by Darktrace for general informational purposes only and reflects our understanding of cybersecurity topics, trends, incidents, and developments at the time of publication. While we strive to ensure accuracy and relevance, the information is provided “as is” without any representations or warranties, express or implied. Darktrace makes no guarantees regarding the completeness, accuracy, reliability, or timeliness of any information presented and expressly disclaims all warranties.
Nothing in this blog constitutes legal, technical, or professional advice, and readers should consult qualified professionals before acting on any information contained herein. Any references to third-party organizations, technologies, threat actors, or incidents are for informational purposes only and do not imply affiliation, endorsement, or recommendation.
Darktrace, its affiliates, employees, or agents shall not be held liable for any loss, damage, or harm arising from the use of or reliance on the information in this blog.
The cybersecurity landscape evolves rapidly, and blog content may become outdated or superseded. We reserve the right to update, modify, or remove any content without notice.
.avif)
wg.jpg)
.jpg)
