Summary4 min read

SANS Stormcast Podcast Summary – March 18, 2026

Main Theme

This episode, hosted by Johannes B. Ullrich, covers three timely security topics:

The real-world behavior and security implications of IPv4-mapped IPv6 addresses,
A new blog by Paul Asadoorian and Reynaldo Vazquez Garcia on vulnerabilities in low-end IP KVM devices,
A DNS-based covert channel bypass identified in AWS Bedrock sandboxes.

Key Discussion Points

1. IPv4-Mapped IPv6 Addresses: Practical Notes and Security Considerations

Overview: Johannes discusses a phenomenon observed when reviewing proxy requests in a honeypot: IPv4-mapped IPv6 addresses unexpectedly appearing in network traffic.
- These addresses are primarily an OS-level construct, designed to allow IPv6-only software to communicate over IPv4 when needed.
- Normally, these addresses should not appear "on the wire", but some tools (e.g., wget, modern browsers) handle and translate them without issue.
Possible Abuses:
- Attackers sometimes use odd representations for IP addresses (octal, integer formats) to obscure their intentions—IPv4-mapped IPv6 could be another variant of this obfuscation.
- Johannes clarifies that this obfuscation method doesn't pose a significant additional threat but serves as a reminder about string versus integer IP handling.
  
  "Yet another reminder that you probably shouldn't deal with IP addresses just as a string. Well, look at the nature of the IP addresses. If it's IPv4, it must be a 32 bit unsigned integer. So treat them like that and that usually gets you out of trouble."
  — Johannes B. Ullrich [01:45]
Technical Quirk:
- Tools behave inconsistently: ping6 doesn't handle these addresses (it only sends IPv6 packets), while others like wget or browsers will work seamlessly.
Recommendation:
- Proper IP type handling (treating IPv4 as a 32-bit unsigned integer) prevents obfuscation-based issues.

2. IP KVM Device Vulnerabilities: Blog Review

Blog Release:
- Paul Asadoorian and Reynaldo Vazquez Garcia (Eclipsium) examined vulnerabilities in affordable IP KVM devices ($25–$100 range) and published their findings.
Main Findings:
- Contrary to expectations, no widespread or severe vulnerabilities found, though some issues stood out:
  - One vendor had a remote code execution (RCE) vulnerability and has not yet released a patch.
  - Other vendors had relatively minor faults, like a lack of brute force protection, but are actively patching.
- The security landscape of low-end IP KVMs appears more promising than much of the broader IoT market.
  
  "I was actually a little bit almost surprised. The positive side, that they didn't for the most part find any sort of, you know, huge vulnerabilities... That part of market doesn't seem to be as desolate in some ways as the rest of the IoT device market."
  — Johannes B. Ullrich [02:48]
Security Reminders:
- Inadequate brute-force prevention is highlighted as a concern due to most devices relying on simple username/password credentials.
- Encouraged mitigation: apply released patches promptly.

3. AWS Bedrock Agent DNS Covert Channel Vulnerability

The Problem:
- With the rise of AI agents, securely executing auto-generated code is a challenge. AWS Bedrock offers a sandboxed "interpreter" for code evaluation.
- The sandbox intends to isolate code and minimize risk, but BeyondTrust researchers found the sandbox still permitted DNS traffic.
Attack Route:
- This access allows DNS to be leveraged as a classic covert channel for data exfiltration or sandbox escape—contradicting the purpose of sandboxing.
  
  "Turns out this is not quite true. Beyond Trust found that the agent inside the sandbox is still able to send and receive DNS traffic. So this way DNS can be used as the good old covert channel."
  — Johannes B. Ullrich [04:05]
AWS Response:
- The vulnerability was responsibly disclosed and AWS has since deployed fixes.
Broader Context:
- Sandboxing is a work-in-progress, with current designs often forcing trade-offs between utility and genuine security isolation.

Notable Quotes & Moments

"[These IPv4-mapped IPv6 addresses] should never be seen on the network. They're really sort of more an internal operating system construct..."
— Johannes B. Ullrich [00:30]
"Attackers often use odd IP formats in obfuscation. This is really just another way to sort of encode an IP address as a string."
— Johannes B. Ullrich [01:23]
"One vendor is... problematic as there appear to be no patches forthcoming to address these vulnerabilities. The other vendors...are coming up with patches if they haven't already been released."
— Johannes B. Ullrich [03:03]
"With that you now gain that access to the sandbox and also outbound from the sandbox. That isn't supposed to happen."
— Johannes B. Ullrich [04:27]

Timestamps for Key Segments

IPv4-mapped IPv6 Discussion: 00:20–02:10
IP KVM Device Vulnerabilities: 02:10–03:35
AWS Bedrock DNS Covert Channel: 03:35–04:50

Conclusion

Johannes delivers another concise, informative overview of current security topics, emphasizing practical takeaways: treat IP addresses with care in code, act fast on vendor advisories/patches, and remain skeptical about cloud sandboxes' ability to fully isolate risky code—especially as AI agents proliferate.

Loading summary

Transcript1 lines

[00:05]
A
Hello and welcome to the Wednesday, March 18, 2026 edition of the SANS United Storm Center's Stormcast. My name is Johannes Ulrich, recording today from Jacksonville, Florida and this episode is brought to you by the Sans Edu Creative Certificate program in penetration testing and ethical hacking. Today I took a little bit closer look at the IPv4 mapped IPv6 addresses. That's something came up yesterday when I looked at these proxy requests in our honeypot and just to see a little bit, you know, how they work and how they're being used. Now really these addresses should never be seen on the network. They're really sort of more an internal operating system construct to allow essentially IPv6 only software to still communicate via IPv4. But yes, they are still somewhat usable. Now I did a quick test here with ping 6. Ping 6 does not work because, well, even if it would convert it to IPv4 as it should, ping6 only sends IPv6 packets. And that of course will not work. But other tools like for example wget or your browser will happily accept these mapped addresses. They'll Translate them to IPv4 and basically then communicate over the network just using the IPv4 address. Not sure if there's really sort of a security problem here with this. It could be abused for some kind of obfuscation. Like you often see people use odd IP addresses like octal formats or just the long integer format in order to obfuscate IPv6 addresses. This is really just another way to sort of encode an IP address as a string in that sense and probably doesn't really add any additional threat. Yet another reminder that you probably shouldn't deal with IP addresses just as a string. Well, look at the nature of the IP addresses. If it's IPv4, it must be a 32 bit unsigned integer. So treat them like that and that usually gets you out of trouble. And Paul Assadorian as well as Reynaldo Vazquez Garcia did publish a blog post for Eclipsium outlining some of the vulnerabilities they found in these cheap low end IP KVM systems. We talked about them before. These are sort of, these anywhere between sort of 25 and $100 IP KVM systems that have become quite popular in the past. And I wrote in the past also about how to better secure them. I was actually a little bit almost surprised. The positive side, that they didn't for the most part find any sort of, you know, huge vulnerabilities. There's vendor that is labeled here where they had a Remote code execution vulnerability. That vendor is also in so far problematic as there appear to be no patches forthcoming to address these vulnerabilities. The other vendors there were some vulnerabilities definitely should be fixed, like for example brute force prevention was missing for some of them. That's of course a problem with devices like this. There are pretty much secured with username and password and also something that's not that terribly hard to do for a device that really only has sort of one real user. But the other vendors are coming up with patches if they haven't already been released. So insofar that part of market doesn't seem to be as desolate in some ways as the rest of the IoT device market. The one problem that's coming up with the recent craze about AI agents is the problem that, well, how do you allow an agent to securely execute code that they created? One solution of course is sandboxing and AWS does offer the bedrock agent core interpreter. That's a sandbox where basically interpret the code that the agent wrote and then, well, basically run it. Now this sandbox is supposed to be isolated and with that limit sort of the exposure to the outside world and any attacks. Well, turns out this is not quite true. Beyond trust found that the agent inside the sandbox is still able to send and receive DNS traffic. So this way DNS can be used as the good old covert channel. That's really sort of what in some cases I almost feel the DNS was intended to be. And with that you now gain that access to the sandbox and also outbound from the sandbox. That isn't supposed to happen. That's sort of why you originally used the sandbox. They have reported this to AWS and AWS has deployed respective fixes. But yet another example where you have to be careful. And in general the idea of sandboxing agents is still sort of, I think, at least under development in the sense that it's really hard to have a useful agent and not give it access to anything. So the sandboxes, even if you pre populate them with data or so you want the agent to act on, are usually somewhat limited in their functionality. Well, and that's all that we have time for today. So thanks for listening, thanks for liking, thanks for subscribing, thanks for watching and as always, special thanks for leaving good comments in your favorite podcast platform and talk to you again tomorrow. Bye.