Tomorrow, I will join a meeting where I’m expected to contribute, amongst others, to a discussion on the impact of IPv6 on threat intelligence. To prepare for that I started putting together some thoughts & ideas on the topic, and I even thought I might share this in a post (the one you read right now ;-), not least to, maybe, stimulate a discussion.
I don’t know much about threat intelligence so it might happen that, at times, I use some misguided terms or I expose a (too) naïve understanding of some concepts. Happy to be corrected in one way or another.
As a starting point, let’s assume that there’s a threat actor which in turns perform some threat action, over an IP based network (otherwise the above question just wouldn’t make sense ;-), namely over the Internet.
Let’s further assume that the following can be part of a related threat intelligence process:
- detection there’s a threat action going on.
- understand the nature of the threat, incl. the target(s), the threat actor’s objectives, the technical means used etc.
- identify the threat actor and/or be able to correlate actions amongst threat actors, identify groups etc.
- [strictly speaking not part of ti, but potentially important as well:] initiation of mitigations (e.g. blocking of source IP addresses of threat actors).
Let’s have a quick look where IPv6 can play a role in one of those.
Detection of a Threat Going On
On a technical level some of the following can be involved:
- attack signatures (e.g. used by an IDS).
- being able to constitute a “session” (individual IP[v6] packets being part of a bigger thing going on).
- correlation of various things happening on the network, maybe supported by a tool like a SIEM.
As for signatures: as we’ve shown here many signature based approaches to detect badness in network traffic may have a much harder time in an IPv6 setting.
As for “constitution of a session”: this might be much harder in an IPv6 network as well, due to the multitude of addresses an individual system may use in parallel or sequentially during a short period of time. A little anecdote here: I just recently was involved in a troubleshooting scenario where in an environment consisting of Windows based machines and Apple Macbook systems, only the Mac systems could (seemingly) properly perform DNS resolution. It turned out that the Linux based resolver not only had a static IPv6 address but the respective interface had also performed SLAAC and in the course of that one had generated even a temporary address. After receiving the DNS requests on the static address the system responded with the temporary address (supposed to be used for outbound connections, right?) which ofc meant that the destination address of the initial DNS query and the source address of the corresponding DNS response packet did not match. The Mac happily accepted the answer whereas the Windows systems discarded it. I won’t judge/comment on the individual systems’ behavior but instead I’d just like to make clear that the idea of a “session” based on a clear (and constant) understanding of the addresses in use by end points might not hold in the IPv6 world, even in “benign scenarios”.
As for the contribution of a SIEM: last time we briefly looked at some, which is two years ago (in the course of the RISC project), there was a lack of IPv6 capabilities of/in major SIEM products, but this might have changed in the interim. Dear vendors, feel free to jump in if you think your $SOLUTION (contributing to threat intelligence) has decent IPv6 support.
Understanding the Nature of a Threat
This might involve:
- machine based analysis steps.
- human analysis.
The first one might be (currently) more difficult in an IPv6 world, for a variety of reasons:
- lack of IPv6 maturity/”understanding” of/by the components involved.
- an actual ongoing threat (read: attack) might use both IPv4 and IPv6 simultaneously (for different steps of an overall chain of steps, or just in a randomized manner, for obfuscation purposes) which in turn might render gathering the full picture more difficult.
Human analysis might be harder as well as most analysts will not have, as of May 2016, vast experience with IPv6.
And, of course, there might be completely new types of attacks (e.g. resource depletion by means of NDP packets wasn’t available/known in the IPv4 world) which both automated engines or human analysts might not be familiar with/prepared for.
Identification of Threat Actor(s) / Attribution
Once an individual IP address is considered a relevant bit of information in this context, much will change with IPv6. For example it might happen in the near future that every host in a Wifi network gets an own, full /64 prefix (see this Internet-Draft).
Now this would mean that a malicious/infected endpoint in a public Wifi network can show up with 2^64 potential IPv6 source addresses, and evidently a human attacker sitting somewhere, at a laptop during his day shift in a tower building in some emerging market, can do the same. Clearly both attribution and blocking on anything less/smaller than a /64 don’t make much sense then.
These were some unordered, early thoughts on the the impact of IPv6 when it comes to detecting and understanding network based threats (which might be part of “threat intelligence” or not ;-). Last but not least let me state the other protocols can have similar effects as I myself discussed earlier and Kate Pearce will lay out in much more detail in her upcoming Black Hat talk.
Happy to receive feedback on any channel.
Everybody have a great weekend
Enno