Malware of the Day – IPv6 Address Aliasing

What is Malware of the Day?

 

Lab Setup

Malware: Custom Go-based C2

MITRE Tactics: TA0011 Command and Control, T1017.110 Application Layer Protocol: Web Protocols, T1571 Non-Standard Port

Traffic Type: HTTP/1.1

Connection Type: TCP

C2 Platform: Custom Go-based C2

Origin of Sample: Active Countermeasures Threat Hunting Lab

Host Payload Delivery Method: ELF binary

Target Host: [2604:a880:4:1d0::6a26:c000] (Ubuntu)

Adversary Host: [2604:a880:800:14::ae20:d000] (Ubuntu)

Beacon Delay: 10s

Jitter: 10s

Data Jitter: 1000 bytes

 

 

Malware of the Day Mission

To identify and share examples of post-compromise network activity in order to better detect and respond to potential network threats. Specifically we are looking for Command and Control (C2) communication channels used by attackers to obtain intelligence, issue commands, and exfiltrate data through a compromised host or hosts.

 

Preface: The Threat Hunting Mindset

As threat hunters, we approach our work with the mindset of a detective, maintaining an open and unbiased perspective to ensure that all potential evidence is considered and interpreted objectively. Our investigation begins when we discover a piece of evidence that suggests something might be amiss. From this point, we employ a variety of supportive tools to either refute or strengthen our case.

The process of threat hunting involves layering evidence, gradually increasing the probability of a compromise as we gather different, independently verified pieces of information. Each new piece of evidence adds to the overall picture, allowing us to build a stronger case. Our ultimate goal is to construct a case that is sufficiently solid to inform the Incident Response team of a probable compromise.

Throughout the investigation, it is crucial to remember the golden rule of threat hunting: never cross the active-passive line. This means that we must use all the tools and techniques at our disposal in a manner that does not alert the intruder to the fact that they are being investigated. By maintaining a passive approach, we can gather the necessary evidence without compromising the investigation.

By adhering to this mindset and methodology, we can effectively investigate potential compromises, providing valuable insights and enabling our organization to respond to threats in an effective manner.

 

Background

The introduction of IPv6 brought with it a wealth of new features over its predecessor, IPv4. One of the most interesting of these features is its flexibility in address assignment, which allows for a concept known as IPv6 aliasing. Aliasing is essentially the ability for a host to assign multiple IPv6 addresses to itself, all of which can then be used interchangeably.

Unlike IPv4, where aliasing (via multiple IPs) often requires additional configuration or virtual interfaces, IPv6 makes this process seamless and native to the protocol. This means a single host can have multiple IPv6 addresses that all correspond to it, and it can use any of them to communicate over the network. All of these addresses can coexist on the same interface, and the host can respond to traffic sent to any of them.

 

How Does IPv6 Aliasing Work?

IPv6 aliasing is possible because of the fundamental characteristics of the protocol itself:

Large Address Space:

The IPv6 address space has approximately 3.4 x 10³⁸ possible addresses, which is, for lack of a better word, really large. So large in fact that we could assign an IPv6 address for every atom on the planet, and still have plenty left over. Because of this a single host usually receives not an IPv6 address, but an entire subnet. This allows it to dole out any address from that subnet to itself.

Stateless Address Autoconfiguration (SLAAC)

SLAAC allows a host to generate their own addresses without requiring the involvement of a DHCP server. This autonomous mechanism allows for plug-and-play connectivity for IPv6 devices with minimal administrative overhead.

No Need for NAT

NAT (Network Address Translation) was introduced because we ran out of public IPv4 addresses. It solves this issue by allowing multiple private hosts to share a single public IPv4 address by mapping internal traffic to external addresses. However, with IPv6, since there is no more shortage, there’s no more need for NAT. As a result, IPv6 supports multiple globally routable addresses per host without requiring any special configuration.

Multiple Addresses per Interface

IPv6 is designed to support multiple addresses on a single interface natively. The operating system and network stack handle this seamlessly, allowing the host to send and receive traffic using any of its assigned addresses.

So we know now what IPv6 aliasing is, and how it’s made possible, which beckons – why do we care about this from a threat hunting POV?

 

Why Is This a Big Deal?

Command-and-control (C2) traffic often communicates outbound to multiple servers or redirectors. Doing so “dilutes” the traffic, making it harder to detect. It’s easier to spot a single host communicating heavily with one server than communicating lightly with multiple servers. This distribution helps maintain stealth.

Using multiple redirectors also introduces opportunities for different types of rotational strategies, making further obfuscation possible. By varying the manner in which communication targets transition, attackers can make it more difficult for defenders to identify and correlate malicious activity.

With IPv4, setting up such an infrastructure is harder and more costly. It requires extensive configuration, virtual interfaces, or the use of multiple redirector hosts. This increases time, cost, and complexity, as well as the risk of failure.

IPv6 makes this process much easier. A single command can add a new IPv6 alias, allowing a C2 agent to communicate outbound to many different addresses. This flexibility makes it harder to detect and trace the traffic, as it appears to originate from multiple sources rather than a single point.

Additionally, many threat hunters are still not fully familiar or comfortable with IPv6. This can lead to IPv6 traffic being overlooked or ignored during investigations. Ironically, this lack of familiarity makes IPv6 an attractive target for C2 communication, as attackers can exploit this gap in visibility to operate more stealthily.

 

Scenario and Setup

In a recent security incident at John Doe Inc., our team discovered that a threat actor had compromised one of their publicly-facing Ubuntu servers (2604:a880:4:1d0::6a26:c000). The attackers exploited an unpatched vulnerability to deploy a sophisticated command and control (C2) agent from their custom framework.

This framework was designed to evade detection in two key ways. First, it used custom code that lacked known signatures detectable by security tools. Second, it operated exclusively over IPv6, communicating with a single host (2604:a880:800:14::ae20:d000) disguised behind five different IPv6 addresses.

To further conceal their activities, the attackers engineered their framework to send multiple consecutive requests to the same address before switching to another—mimicking legitimate traffic patterns and making detection more difficult. From this compromised position, they intercepted network traffic to gather intelligence as part of a targeted campaign.

The breach was only identified after users reported persistent performance issues with the Ubuntu server. Our investigation revealed a critical configuration error: a former employee of John Doe Inc. had incorrectly configured RITA/AC-Hunter’s IPv6 subnet settings.

This oversight happened because IPv6 traffic doesn’t use Network Address Translation (NAT). Unlike IPv4 connections, where internal traffic would show as communication between a private internal IP and a public destination, IPv6 traffic appears as direct communication between public addresses even when captured on local interfaces. We thus have to also add our public IPv6 address space to our internal subnet.

 

Results

Once we corrected this configuration issue, five suspicious connections immediately became apparent – see Images 1 – 5 below.

 

 

 

 

 

Even though none of these connections had an exceptionally high threat score, ranging from 83.50 to 87.60, the fact that these connections all resolved directly to IPv6 addresses seemed suspicious. On closer inspection, we also noticed that the addresses were remarkably similar, with only the last digit differing between them.

Using the IP resolution service whatismyipaddress.com, we learned that these addresses are all on the Digital Ocean network – see Image 6 below.

 

While this could indicate legitimate background services, since the host being investigated was itself part of the Digital Ocean network, it’s also well known that threat actors favor placing virtual cloud hosts between themselves and targets to create a layer of separation. Subscription services like Digital Ocean can be treated as disposable resources by attackers – cheap to acquire, and easy to dispose of once compromised.

We then decided to use AC-Hunter to investigate further.

 

AC-Hunter

We quickly identified all 5 the connections in our Beacon module inside of AC-Hunter – see Images 7 – 11 below.

 

 

 

 

 

As can be seen in the connection histograms, all 5 connections displayed the same essential pattern – see Image 12 below.

 

We can see that the vast majority of the connections occurred at 10-second intervals—giving us a clear indication that this was an application not being used by a human. To be clear: this does not conclusively prove malicious behavior since background services could also be using a timed communication pattern.

Another interesting observation is the clusters of shorter connection periods stretching all the way to 4663 seconds. If we assume for the moment that this communication is controlled by a C2 framework, then this pattern would make complete sense within the context of multiple addresses being used as targets. These time gaps essentially represent the periods when other addresses were being used before returning to this specific address.

Looking at the data size histogram also provided an interesting result – see Image 13 below.

 

As we explored extensively in our previous blog article (Measuring Data Jitter Using RCR), as well as Malware of the Day report (Merlin C2 Data Jitter), a packet size histogram showing such a uniform distribution typically indicates the presence of intentional manipulation of packet sizes through the introduction of payload jitter. This further reinforces our suspicions that these connections may indeed be involved in unauthorized communication.

The hourly connection graphs (Images 7-11, bottom) present an interesting deviation from our expected compromise pattern. In typical C2 traffic scenarios, we would expect to see a relatively flat distribution line across hourly periods. This is because even when attackers implement jitter to vary their communication patterns, these variations typically average out when aggregated on an hourly basis – see Image 14 below.

 

 

Suspected IPv6 Aliasing

The fact that all five destination IPv6 host addresses differed only in their final digit—coupled with the striking consistency in their histograms and per-hour connection graphs—led us to hypothesize that the application might not be communicating with five distinct hosts. Instead, it could be interacting with a single host configured with five IPv6 aliases.

If this were true, it would explain why the per-hour connection graphs for each address appeared inconsistent on their own. Each graph would essentially represent just one piece of a five-part puzzle. To test this theory, we aggregated the results by combining all five graphs into a single composite graph using Photoshop. You can see the outcome in Image 15 below.

 

As we can see, combining the graphs paints a completely different picture. It now reveals the classic “flat top” pattern (i.e., low hourly variation) that we expect to see in command-and-control (C2) communication.

At this point, we can confidently conclude that we are most likely dealing with a compromise. With this evidence, we can now notify the Response team to take over.

 

Conclusion

The discovery of IPv6 aliasing in this custom C2 framework highlights the possibility to exploit the inherent flexibility of IPv6 for stealth and evasion. By leveraging multiple IPv6 addresses on a single host, attackers can distribute their traffic across seemingly distinct endpoints, making it harder to detect and correlate malicious activity. This case underscores the importance of understanding IPv6’s unique features and their potential misuse in modern cyberattacks.

This incident also demonstrates the critical role of robust network analysis tools like RITA and AC-Hunter in uncovering sophisticated threats. By visualizing connection patterns, packet sizes, and temporal behaviors, we were able to piece together the true nature of the traffic.

The attackers’ use of IPv6 aliasing also serves as a reminder that threat actors are increasingly exploiting gaps in defenders’ familiarity with newer technologies. While IPv6 adoption continues to grow, many security teams still prioritize IPv4 in their monitoring and detection strategies. This oversight creates an opportunity for attackers to operate under the radar, using IPv6’s capabilities to their advantage. As such, it is imperative for defenders to expand their visibility into IPv6 traffic and develop detection methodologies tailored to its unique characteristics.

Finally, this investigation reinforces the importance of a proactive and adaptive approach to threat hunting. Attackers are constantly evolving their tactics, and defenders must remain vigilant for both known and novel patterns of malicious behavior. Tools like AC-Hunter provide the technical foundation for detecting anomalies, but it is the human analyst’s ability to interpret these findings and connect the dots that ultimately leads to successful threat identification and mitigation.

As the threat landscape continues to evolve, so too must our strategies for defending against it. By combining advanced analytical tools with a deep understanding of emerging technologies and attacker techniques, we can stay one step ahead in the ongoing battle to secure our networks.

 

C2 Simulation Application

We are happy to make the tool used to generate this traffic available to you here, full instructions are available in the accompanying README file. Note that even though the tool is “toothless” (i.e. not capable of actual action on the endpoint) it should still only ever be used in controlled environments with proper authorization.

We encourage you to use this tool to run your own simulations, generate traffic, and analyze it using RITA and AC-Hunter. We believe that getting direct, hands-on experience is the best way to improve as a network threat hunter.

 

Capture Files

PCAPs

Because… PCAPs, or it didn’t happen. 😊

The following PCAP files are packet captures taken from the same lab environment over a 24-hour time frame. The files were generated using Wireshark from the target host and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The PCAPs are safe, standard PCAP files and do not include any actual malware.

IPv6 Aliasing C2 24 Hour Capture
ipv6rotation.pcapng
File Size: 172.2MB
SHA-256 Hash: EBE5B64A955F07AF44165A6B6F4A3185121824020F5D3497E60E43608DA1E771

 

Zeek Logs

If you are an AC-Hunter user, we are providing the 24-hour Zeek logs for you to import directly into AC-Hunter. The following Zeek Logs have been taken from the same lab environment over a 24-hour time frame and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The Zeek logs are safe, standard log files and do not include any actual malware.

Importing Zeek logs into AC-Hunter example:

ssh into your AC-Hunter or RITA server and upload all the Zeek logs contained in the zip file below (all files that have the ‘.log’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/zeek_ipv6rotation/

Then run the following command:

For AC-Hunter v6.x and RITA v4.x and earlier:

rita import /tmp/zeek_ipv6rotation/*.log zeek-ipv6rotation

For RITA v5.x+:

rita import --logs=/tmp/zeek_ipv6rotation/*.log --database=zeek-ipv6rotation

You will now have a new database in the AC-Hunter UI/web interface or RITA CLI titled “zeek-ipv6rotation” you can select and view.

 

IPv6 Aliasing C2 24 Hour Zeek Logs
zeek_ipv6rotation.zip
Size:  2.9MB
SHA256 Checksum: 7D08C1FE12BF86F5294709849D2ED57F809E729ACA297D5A659A3C15C2E06E49

 

 

Resources

Bill Stearn’s Fireside Friday webcast: IPv6 for IPv4 Users

 

Discussion

Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?

You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.

 

 

A huge thanks to Bill Stearns, Keith Chew and Chris Brenton for allowing me the opportunity to contribute to this awesome initiative, as well as their guidance, helpful feedback, and for being a couple of stand-up gents.

Live long and prosper!