Sixt.com and Breitling.com Abused by Malware: Inside a Covert C2 Operation

In March 2018, cybersecurity company Darktrace revealed an unusual malware operation that exploited the reputations of two internationally recognized brands to conceal malicious network communications. Instead of using obviously suspicious website addresses, the malware impersonated the hostnames of Sixt, a German car rental company, and Breitling, a Swiss luxury watch manufacturer, while sending HTTP requests to attacker-controlled servers.

The incident demonstrated how cybercriminals can manipulate seemingly ordinary web traffic to disguise command-and-control (C2) communications. By making malicious requests appear associated with legitimate commercial websites, the attackers attempted to bypass domain reputation systems, security filters and conventional network monitoring.

The investigation began when Darktrace detected abnormal activity on a customer's laptop. The device was generating repeated HTTP requests to suspicious domains, followed by hundreds of POST requests using the hostnames sixt.com and breitling.com. Further investigation revealed that the requests were not reaching the legitimate websites but were instead being directed to separate IP addresses associated with the attacker's infrastructure.

The malware also used Domain Generation Algorithms (DGAs), unusual browser identification strings, suspicious PHP endpoints and encoded HTTP request data. These techniques suggested that the attackers had developed a communication mechanism intended to remain undetected for an extended period.

Darktrace reported that its behavioral detection system identified the activity without relying on previously known malware signatures or domain blacklists. The affected device was subsequently isolated by the security team.

Although the incident dates back to 2018, its underlying techniques remain relevant to modern cybersecurity. It illustrates why organizations must examine actual network destinations and communication behavior rather than assuming that traffic is safe simply because it contains a recognizable domain name.

The Darktrace Investigation: How the Malware Was Discovered

The incident was documented by Max Heinemeyer, then Global Field CISO at Darktrace, in an article published on March 6, 2018, titled How Malware Abused Sixt.com and Breitling.com.

According to the investigation, Darktrace identified an advanced malware infection on a customer's device during February 2018.

The infected laptop began communicating with external destinations in ways that differed significantly from its established network behavior.

The initial activity involved requests to unusual domains that appeared to have been generated automatically. Subsequent traffic analysis revealed repeated communication with several suspicious destinations and the use of legitimate commercial hostnames to disguise the requests.

What made the incident particularly interesting was the apparent sophistication of the communication strategy.

Rather than relying on one fixed command-and-control server, the malware combined dynamically generated domains with requests that appeared to involve established commercial websites.

This created multiple layers of deception and made the communication more difficult to identify through conventional domain-based security controls.

Darktrace's analysis showed that the laptop was not behaving like a normal web-browsing device. Its requests were automated, repetitive and directed toward network destinations that did not match the apparent websites identified in the HTTP traffic.

Why the Attackers Chose Sixt.com and Breitling.com

The choice of sixt.com and breitling.com was central to the malware's concealment strategy.

Sixt is an internationally recognized vehicle rental company headquartered in Germany, while Breitling is a Swiss luxury watch manufacturer with an established global presence.

Both companies operated legitimate websites with established domain reputations.

By using these names in HTTP requests, the attackers attempted to make their malware traffic resemble ordinary browsing activity.

A security system examining only the requested hostname might initially consider the communication less suspicious than requests to randomly generated or previously identified malicious domains.

The attackers were effectively exploiting the trust associated with legitimate commercial brands.

However, there was a fundamental discrepancy between the apparent destinations and the actual network connections.

The malware used the legitimate hostnames but directed the requests to different IP addresses controlled by the attacker.

Were Sixt.com or Breitling.com Hacked?

Darktrace explicitly stated that it found no public evidence indicating that either sixt.com or breitling.com had been compromised in connection with the incident.

The companies' domain names were being impersonated within malicious HTTP requests. This did not mean that their websites, hosting infrastructure or DNS systems had necessarily been breached.

This distinction is essential when interpreting cybersecurity incidents involving domain impersonation.

A legitimate domain appearing in malicious network traffic does not automatically mean that the domain owner has been hacked or participated in the attack.

In this case, the abuse occurred at the application-layer request level, where the malware manipulated the hostname information associated with its HTTP communication.

How the Malware Manipulated HTTP Hostnames

The central technical mechanism involved the separation between the IP address used to establish a network connection and the hostname included in an HTTP request.

To understand the attack, it is necessary to examine how conventional HTTP communication works.

When a browser accesses a website, it generally resolves the domain name through DNS, obtains an IP address and establishes a network connection to the destination server.

For HTTP/1.1 communication, the request typically includes a Host header identifying the website being requested.

A simplified legitimate request might look like this:

GET / HTTP/1.1 Host: sixt.com User-Agent: Mozilla/5.0 Accept: text/html

The Host header tells the web server which hostname the client intends to access. This is particularly important because multiple websites can operate on the same IP address using virtual hosting.

However, the hostname in an HTTP request does not independently prove that the connection has reached the legitimate owner of that domain.

A client can establish a TCP connection to one IP address while sending an HTTP request containing a different hostname.

This is precisely the distinction exploited by the malware.

The Difference Between the Host Header and the Destination IP

In the Darktrace incident, the malware used sixt.com and breitling.com as the apparent HTTP hostnames while sending requests to separate attacker-controlled IP addresses.

The result was a mismatch between the identity suggested by the HTTP request and the actual network destination.

For example, a request could conceptually resemble:

POST /generated-endpoint.php HTTP/1.1 Host: sixt.com User-Agent: Mozilla/5.0 Content-Type: application/x-www-form-urlencoded [encoded request data]

Although the request identified sixt.com, the underlying connection was directed to the IP address 184.105.76.250.

Likewise, requests using breitling.com were directed to 64.71.188.178.

These were not the legitimate destination addresses associated with the two commercial websites on non-infected devices.

The distinction explains why simply checking the hostname was insufficient to identify the true destination of the communication.

What About HTTPS and TLS?

The original investigation described HTTP POST requests and identified the application-layer hostnames and destination IP addresses.

It should not be assumed that the exact same technique would work identically against every modern HTTPS connection.

HTTPS introduces TLS encryption, and the client may also send a Server Name Indication (SNI) during the TLS handshake to identify the intended server.

Modern security systems can correlate several elements, including:

• Destination IP addresses.
• DNS resolution history.
• TLS SNI information, where visible.
• TLS certificate details.
• HTTP Host or HTTP/2 authority information, where inspection is available.
• Connection timing and traffic patterns.

Encrypted Client Hello (ECH) can also reduce the visibility of certain TLS handshake information.

Consequently, modern detection strategies need to combine available network metadata with endpoint telemetry and behavioral analysis rather than depending on one protocol field.

Attacker-Controlled IP Addresses Behind the Fake Hostnames

Darktrace identified three particularly important IP addresses during its investigation.

The first two addresses were associated with the disguised communications using the commercial hostnames.

The third address hosted several suspicious domains generated through the malware's Domain Generation Algorithm.

Darktrace also observed that all three IP addresses belonged to the same autonomous system, AS6939, operated by Hurricane Electric.

This infrastructure overlap provided an additional clue because the apparently unrelated destinations were associated with the same network operator.

However, an important technical distinction must be maintained: sharing an autonomous system does not prove that an organization owns or controls all the IP addresses within it. Autonomous systems can contain address space belonging to different customers and hosting arrangements.

The significance of the finding came from the combined evidence: suspicious HTTP behavior, mismatched hostnames and IP addresses, repeated communication and shared network infrastructure.

Domain Generation Algorithms: How the Malware Created Changing Domains

Another important component of the malware was its use of Domain Generation Algorithms, commonly known as DGAs.

A DGA is a mechanism that automatically generates domain names according to a predefined algorithm.

Malware authors use DGAs to avoid depending on a single permanent command-and-control domain.

Instead of configuring every infected device to communicate with one fixed hostname, the malware can generate numerous potential domains based on information such as dates, counters, pseudo-random values or other algorithmic inputs.

The attacker can register selected domains and configure them to point toward the command-and-control infrastructure.

This makes it more difficult for defenders to disrupt the communication by blocking a single domain.

Domains Identified in the Investigation

Darktrace identified three suspicious domains associated with the infection:

• tequbvchrjar.com
• jckdxdvvm.com
• cqyegwug.com

All three domains were hosted on 66.220.23.114.

The infected laptop initially made HTTP requests to tequbvchrjar.com.

Over the following two days, it generated several hundred HTTP POST requests involving this domain and the other two generated hostnames.

The pattern indicated automated communication rather than ordinary browsing.

Why DGAs Make Malware Harder to Block

Traditional domain-based security controls often rely on known indicators of compromise.

If malware repeatedly contacts a fixed domain, security teams can identify and block that destination.

DGAs make this approach less effective because the malware can generate new candidate domains as older ones are blocked.

Depending on the implementation, hundreds or thousands of possible domains may be generated over a specific period.

Defenders must therefore identify the algorithmic patterns or behavioral characteristics associated with the generated domains rather than relying exclusively on a static list.

In the Darktrace case, the suspicious domain names were only one part of a much larger behavioral pattern that included repeated POST requests, unusual User-Agent strings and abnormal connection destinations.

HTTP Beaconing: How the Malware Maintained Contact With Its Operators

Darktrace identified the repeated network requests as beaconing.

In cybersecurity, beaconing describes recurring communication between an infected device and external infrastructure controlled by an attacker.

The malware periodically contacts its command-and-control server to receive instructions, report information or transmit collected data.

Beaconing is a common characteristic of remote access malware, botnets, information stealers and other malicious programs.

Depending on its implementation, the communication can occur at fixed intervals, follow variable timing or become active only during certain periods.

The Communication Pattern Observed by Darktrace

The investigation revealed several hundred HTTP POST requests over approximately two days.

The activity followed a relatively steady pattern during afternoon and evening hours when the laptop was being used.

This was important because the communication was not simply a single suspicious connection.

It was a repeated process involving the same unusual destinations and request characteristics.

Darktrace's analysis showed that the device's communication pattern differed significantly from its normal browsing activity.

For network defenders, repeated connections to unfamiliar external destinations can be an important warning sign, particularly when the requests contain unusual application-layer information.

Five Internet Explorer User-Agent Strings on a Chrome Laptop

One particularly unusual finding involved the User-Agent strings included in the HTTP requests.

A User-Agent is an HTTP field that identifies information about the client software making a request.

It commonly includes details about the browser, operating system and compatibility information.

In the investigated incident, the malware used five different Internet Explorer User-Agent strings.

However, Darktrace's previous observations showed that the laptop normally used Google Chrome.

This discrepancy was significant because the suspicious requests did not match the device's established browsing profile.

There are legitimate situations in which different applications use different User-Agent strings. Automated software, compatibility tools and enterprise applications can generate requests that do not resemble ordinary browser activity.

However, in this case, the unusual User-Agent strings appeared alongside DGA domains, repeated beaconing and mismatched hostnames and destination IP addresses.

The combination strengthened the suspicion that the requests were generated by malware rather than by the user's normal browsing activity.

Suspicious PHP Endpoints and Encoded POST Requests

Further investigation revealed that the malware sent requests to suspicious PHP endpoints.

Darktrace reported that the servers consistently returned HTTP status code 200, indicating that the requests had received successful HTTP responses.

However, a successful HTTP response does not establish that the destination is legitimate or that the requested operation is harmless.

In malicious command-and-control communication, an attacker-controlled server can deliberately return ordinary HTTP responses to avoid attracting attention.

Darktrace also downloaded packet capture data, commonly known as PCAP, to inspect the suspicious traffic more closely.

The POST request data appeared to be encoded.

The requests used the application/x-www-form-urlencoded content type, a format commonly encountered in conventional web applications but also used by malware to transmit information through HTTP requests.

This illustrates why network defenders cannot classify traffic as safe simply because it uses standard web protocols and familiar content types.

How the Malware Changed Its Communication Infrastructure

Darktrace's research suggested that similar malware had circulated since at least the end of 2016.

Earlier samples exhibited comparable communication patterns involving sixt.com and breitling.com.

However, the 2018 version appeared to have evolved.

The earlier samples also used domains such as:

• carvezine.com
• sievecnda.com

Darktrace did not observe DGA domains in those earlier versions.

Another important difference involved the PHP request paths.

Earlier PHP Endpoint Structure

The 2016 samples used paths that followed a format similar to:

/[DGA-string]/index.php

Because index.php is a common endpoint in web applications, defenders could use its appearance as one of several indicators when investigating suspicious traffic.

Modified PHP Endpoint Structure

In the later version, the malware used dynamically generated PHP filenames instead:

/[DGA-string].php

This modification reduced the usefulness of security rules that monitored only the fixed index.php path.

It also demonstrated that malware developers were adapting their communication methods in response to existing detection techniques.

The change is a clear example of why static indicators of compromise can become outdated as malware evolves.

Was the Malware Razy or Nymaim?

Darktrace investigated whether the infection might have been related to previously documented malware families.

Open-source research indicated that samples exhibiting similar communication behavior had been circulated since late 2016.

Some security researchers had associated earlier samples with Razy and Nymaim.

However, Darktrace emphasized that the available research was limited and that both malware families were relatively generic.

The company did not establish a definitive attribution for the infection it investigated.

Consequently, it would be inaccurate to describe the incident as a confirmed Razy or Nymaim attack.

The more defensible conclusion is that the 2018 infection shared characteristics with earlier malware samples, including the abuse of sixt.com and breitling.com as apparent HTTP hostnames.

Attribution requires stronger evidence, such as code similarities, distinctive execution behavior, infrastructure relationships and reliable forensic analysis.

Why Traditional Security Controls Failed to Identify the Communication

The incident illustrates several limitations associated with conventional security monitoring.

Many security systems historically relied heavily on known malicious indicators, including domain blacklists, IP reputation databases and malware signatures.

These methods remain useful, but attackers can change their infrastructure and modify their communication patterns.

Domain Reputation Can Be Misleading

A domain name may have a positive reputation while appearing in a malicious request.

Security systems that focus only on the hostname may fail to identify a connection directed toward an unrelated attacker-controlled IP address.

IP Blacklists Can Become Outdated

Attackers can move command-and-control infrastructure between IP addresses, hosting providers and autonomous systems.

A blacklist may identify yesterday's infrastructure but fail to recognize a newly established server.

Static URL Signatures Can Be Modified

The malware's transition from index.php endpoints to dynamically generated PHP filenames demonstrated how quickly fixed URL indicators can lose their value.

Standard HTTP Traffic Can Carry Malicious Data

HTTP POST requests, encoded form data and successful status codes are all common in legitimate web applications.

Their presence alone does not establish malicious behavior.

Defenders need to understand the wider communication context.

How Darktrace Detected the Malware Through Behavioral Analysis

One of the most important aspects of the incident was Darktrace's use of unsupervised machine learning to detect abnormal network activity.

Instead of depending exclusively on predefined malware signatures, the technology established a baseline of normal communication behavior within the monitored environment.

It then identified deviations from that baseline.

In this case, the system identified several abnormalities:

• The laptop communicated with unfamiliar DGA domains.
• It generated hundreds of repeated HTTP POST requests.
• It used five Internet Explorer User-Agent strings despite normally using Chrome.
• It sent requests using well-known commercial hostnames without conventional browsing behavior.
• The destination IP addresses did not match the legitimate websites.
• The requests followed repeated beaconing patterns.
• The traffic included encoded POST data and suspicious PHP endpoints.

These characteristics were collectively inconsistent with the laptop's established behavior.

Darktrace generated alerts, enabling the security team to investigate the device and isolate it from the network.

Why Behavioral Detection Is Different From Signature Detection

Signature-based detection identifies threats through known patterns.

For example, an antivirus product may recognize a malicious executable through its file hash or identify network traffic through a previously documented signature.

Behavioral detection instead focuses on what a device actually does.

Even if malware changes its filename, domain or IP address, it may continue exhibiting unusual communication patterns.

This provides an additional opportunity for defenders to detect previously unknown or modified threats.

However, behavioral detection is not a replacement for endpoint protection