SANS Stormcast Tuesday, March 17th, 2026: Proxy URLs; Local Network Address Restrictions; Advanced Phishing

Summary

---

SANS Stormcast – March 17, 2026

Host: Johannes B. Ullrich
Episode Theme: Proxy URL Attacks, Local Network Address Restrictions, and Advanced Phishing Tactics

---

Episode Overview

In this episode, Johannes B. Ullrich discusses three critical topics shaping the current cybersecurity landscape:

• Recent attacks leveraging poorly secured proxy URLs to access cloud metadata services.
• New local network address restrictions in Microsoft Edge (and Chromium browsers) aimed at curbing server-side request forgery (SSRF).
• A sophisticated phishing campaign that exemplifies both attacker creativity and the persistent challenges for defenders.

---

1. Proxy URL Attacks Targeting Cloud Metadata ([00:18])

Key Discussion Points

• Observed Attack:
  Recent honeypot attacks targeted URLs beginning with “proxy,” an approach commonly abused to force web servers to act as proxies for internal network access.

  • Example: Attackers focus on IP 169.254.169.254 – a link-local address used by cloud providers to host metadata service APIs (commonly providing instance details, sometimes credentials).

• Server-Side Request Forgery (SSRF):
  If a web server is misconfigured to act as an open proxy, attackers can exploit it to reach sensitive internal resources.

• Obfuscation Techniques:
  Attackers use IPv4-mapped IPv6 addresses (e.g., all zeros, FFFF, then the target IPv4 in hexadecimal: A9FE... for 169.254.169.254) to evade detection and filters.

Notable Quote

"They're essentially attempting to use your web server as a proxy to reach internal IP addresses... this is an IPv4 link-only address, typically sort of not seen in a normal network, but it is used by cloud providers for metadata services."
— Johannes Ulrich [00:28]

Recommendations ([01:30])

• Secure Proxy Configurations:

  • Restrict what addresses proxies can reach, especially blocking all unnecessary internal addresses such as metadata endpoints.
  • Carefully configure web application firewalls to prevent SSRF attacks.

• General Guidance:

  • No one-size-fits-all proxy filter—review the necessity and configuration of any proxy endpoints in your applications.

---

2. Local Network Address Restrictions in Microsoft Edge and Chromium ([02:01])

Key Discussion Points

• Feature Introduction & Purpose:
  Microsoft Edge (since version 1.4.3, with updates in 1.4.6) includes a security feature that restricts websites from making network requests across defined trust zones (public Internet, private non-routable addresses, and loopback addresses).

• Why It Matters:
  Helps prevent browser SSRF attacks—e.g., a public website attempting to interact with 127.0.0.1 or 169.254.x.x via the user's browser.

• Recent Updates:

  • Admins and developers can now configure allow-lists for URLs that may need to cross these boundaries (e.g., for testing or legitimate development workflows).
  • The ability to suppress pop-ups or warnings for known, controlled cases simplifies automated testing and development.

Notable Quote

"Essentially, you're not allowed to cross over between those three zones... If you're loading a public website from a public IP address, it's not allowed to request resources from a 10 IP address or, or a 127.0.0.1 address or one of these 169.254 IP addresses."
— Johannes Ulrich [02:42]

Advice

• Be aware of this feature and ensure allow-lists are tightly scoped for development needs only.

---

3. Sophisticated Phishing Attack Case Study ([03:32])

Key Discussion Points

• Attack Description:
  A phishing campaign targeting a European security vendor used several layered evasion techniques:

  • Open Redirect Abuse:
    Leveraged an open redirect on a Cisco website to bypass email security checks (the first redirect leads to a legitimate site, making the URL appear safe to automated scanning).
  • Multiple Redirection Steps:
    1. Cisco open redirect → 2. API email provider → 3. Actual phishing site.
    • This chain further thwarts security controls that scan only the initial or final destination.
  • Sender Spoofing and Fake DKIM:
    Used a misconfigured mail server to relay the attack, spoofing the sender and faking DKIM signatures, increasing likelihood of delivery and trust.

• Why It's Effective:

  • The attack exploited weaknesses outside the immediate control of the target (third-party infrastructure, misconfigured servers).
  • Visual cues for phishing were subtle—e.g., a suspicious captcha on the fake login page that might not register as malicious for most users.

• User Awareness:
  While technical and automated controls are crucial, user awareness remains a critical backstop—especially for sophisticated spear-phishing scenarios.

Notable Quote

"What often distinguishes the more sophisticated attacks... is really more that you know how much care the attacker is paying to make the attack look good."
— Johannes Ulrich [04:13]

"I think where I personally would have probably sort of gotten a little bit suspect of the entire email is when they had, like, the captcha then protecting the login page. That captcha didn't look right to me. But these are very subtle hints that many users probably won't identify necessarily as malicious."
— Johannes Ulrich [05:10]

---

Timestamps Recap

• [00:18] Attacks on Proxy URLs and Cloud Metadata Exploitation
• [02:01] Microsoft Edge Update: Local Network Access Restrictions Explained
• [03:32] Analysis of an Advanced Phishing Campaign with Technical Evasion Tactics

---

Summary Takeaways

• Harden any proxy functionality on your web servers—review configurations for SSRF vulnerabilities, especially concerning cloud instance metadata endpoints.
• Familiarize yourself with local network address restriction features in modern browsers; adjust allow-lists and warnings judiciously for development environments.
• Technical defenses can be bypassed through sophisticated phishing methods—user vigilance and education remain crucial, particularly for high-value or spear-phishing targets.

---

End of summary. For further questions or discussions, Johannes invites listeners to contact the podcast via the SANS Internet Stormcenter contact form.

Transcript

[A]

Hello and welcome to the Tuesday, March 17, 2026 edition of the sans Internet Stormcenters Stormcast. My name is Johannes Ulrich and today I'm recording from Jacksonville, Florida and this episode is brought to you by the Sans Edu Graduate Certificate Program in Cloud Security. In diaries today I wrote up some attacks that I observed this weekend against our honeypots that hit a URL starting with proxy. Now this URL prefix is often used, well as the name implies, for proxies, and that's how the attacker is attempting to use the URL. They're essentially attempting to use your web server as a proxy to reach internal IP addresses. Now the particular IP address they're looking for here is 169-254-16-9254. This is an IPv4 link only address, typically sort of not seen in a normal network, but it is used by cloud providers for metadata services. So each virtual host that you're setting up can reach an API at that IP address that then provides the host with specific configuration option including credentials. And that's exactly what they're looking for here. So kind of a server side request for Chariot hack. But of course if they find an actual full proxy at that URL, then these attacks are a lot simpler. There are also some interesting sort of obfuscation techniques. For example, they're using these IPv4 mapped IPv6 addresses that are starting with all zeros FFF and then the last 32 bits are just the IPv4 address they are reaching, which here, because it's hexadecimal, is then A9 feature A9 FE. So what should you do here? Well, definitely make sure if you are running proxies on a web server or if you have anything like the old sort of course proxies or so set up for cross origin requests. Make sure you properly secure them. Web application firewalls sometimes are configured badly here as well and make sure they cannot reach that 169-254-169254 address, or any other address for that matter that you want them to reach. So I wouldn't really go here for a particular filter for this proxy. Like I said, it may be something that you need for some applications, but be careful how this particular proxy is configured. And then we got a new version of Microsoft Edge version 1.4.6. This version tracks the respective changes in chromium and of course Chrome and other Chromium derived browsers will see the same changes. The reason I mention it at this time, I usually don't mention these updates. So there's no security vulnerability being addressed here, but it's a security feature that I think is often overlooked that has been introduced in version 1.4.3 that gets sort of a couple adjustments here and that's local network access restrictions. The problem is actually something related to the prior stories where we have these proxies or well really server side request forgery where you can trick a web browser to request resources from a third party site. So what local network access restrictions does is that there are three different zones defined public IP addresses, these non routable IP addresses and loopback IP addresses like 127.0.0.1 and essentially you're not allowed to cross over between those three zones. So if you're loading a public website From a public IP address, it's not allowed to request resources from like a 10 IP address or, or a 127001 address or one of these 169254 IP addresses. Now what the latest change does is it actually allows you sort of administratively to configure some settings to set up certain allow Lists of URLs that are allowed to violate this policy. This can be useful for developer purposes. Now typically users would get in some cases like pop up warnings and the like, but you can essentially disable those warnings to allow for easier automated testing and in general to easier test a website or develop a website that may still run on a local system and be using the loopback IP address, but is sort of part of a larger website that you're working on. Interesting feature, local network access and restrictions and definitely something that you sort of should be aware of. And we got an interesting story that I think makes a good sort of case study when it comes to a little bit more sophisticated phishing attacks and well, where user education may actually still be important. I have talked bad about user education in the past and the limits of it. But yes, it does provide sort of a final barrier of entry for some of the more sophisticated phishing attacks where sadly a lot of the automated and technical controls are fixed. This particular example targeted a European security vendor. It was written up by specopsoft. The attack itself, I think all the different pieces of it are not really all that terribly sophisticated. What often distinguishes the more sophisticated attacks as from the sort of more random attacks is really more that you know how much care the attacker is paying to make the attack look good. In this particular case they're actually using an open redirect at a Cisco website in order to bypass any kind of Cisco email security gateway. They're then redirecting to another valid attack, an API email provider. Next, they're then going on in the third step to the actual phishing website. So that way the email gateway first of all sees a valid URL that directs to a valid URL and, well, then they're sort of stopping, checking. Also, the sender is spoofed, but a DKIM is here faked by basically just using a misconfigured mail server that allowed them to relay this email. So all of these things like these open redirects and the misconfigured mail server is all sort of out of the control of the target. These are third parties they interact with or even don't interact with. And that then leads to the executive, in this case, receiving the phishing email that will then attempt to steal Microsoft credentials. I think where I personally would have probably sort of gotten a little bit suspect of the entire email is when they had, like, the captcha then protecting the login page. That captcha didn't look right to me. But these are very subtle hints that many users probably won't identify necessarily as malicious. Well, and this is it for today. So thanks for listening, thanks for liking, and thanks for subscribing to this podcast. And as always, talk to you again tomorrow. Bye.