Every now and then, a security team uncovers something only the Internet Engineering Task Force (IETF) can fully explain. During a review of network activity, our team noted unusual outbound web traffic from our network. Our investigation took us from checking a simple IPv6 address to researching the IETF’s Request for Comments. What we found along the way demonstrates why monitoring for anomalous IP addresses is important for every organization.
The traffic was routed to an IPv6 address containing ::ffff: followed by 32 bits. Fortunately, open-source tool CentralOps helps identify this odd IPv6 activity, even going so far as to reference the RFCs explaining the basis for the activity. As it turns out, this is an example of an IPv4-mapped IPv6 address, and its structure is shown in the following figure:
RFC 4291 notes that an IPv4-mapped IPv6 address is one of two types of IPv6 addresses with embedded IPv4 addresses. An IPv4-mapped IPv6 address is used to represent IPv4s as IPv6s. The example mentioned above is used when applications support both IPv4 and IPv6 (pictured below).
Understanding unusual IPv6 activity is not just academic. This past February, Cloudfare discovered and patched a bug associated with embedded IPv4 addresses. A researcher “was able to use DNS entries based on mapped addresses to bypass some of our [Cloudfare’s] controls and access ports on the loopback address or non-routable IPs.”
As all cybersecurity gurus say, understanding networking is essential for proper cybersecurity analysis and response. When reviewing network connections in your organization, keep an eye out for unusual or distinctive network activity. The interaction between IPv4 and IPv6 architecture protocols can lead to interesting findings.
Don’t discount the utility of open-source tools to help identify any unusual traffic on your network. The adoption of IPv6 has led to some interesting interactions between the new protocol and its predecessor, IPv4, and there are all sorts of free resources available to help you understand what’s happening in your network. CentralOps and RFCs just might have the unnoticed details that explain what you’re seeing.
