<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>route53 on Oleksandr Kulbida</title>
    <link>https://okulbida.com/tags/route53/</link>
    <description>Recent content in route53 on Oleksandr Kulbida</description>
    <generator>Hugo -- gohugo.io</generator>
    <lastBuildDate>Fri, 03 Apr 2026 00:00:00 +0200</lastBuildDate><atom:link href="https://okulbida.com/tags/route53/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>GuardDuty, phishing URLs, and SSRF: what DNS alerts really mean</title>
      <link>https://okulbida.com/posts/guardduty-phishing-url-resolution-ssrf/</link>
      <pubDate>Fri, 03 Apr 2026 00:00:00 +0200</pubDate>
      
      <guid>https://okulbida.com/posts/guardduty-phishing-url-resolution-ssrf/</guid>
      <description>Click to enlarge      GuardDuty screams about a phishing domain. The node looks fine — no malware, no stolen creds. Often the real story is simpler: your app looked up a URL someone pasted in a message, and that hostname is on a threat list. The alert is still “true” (DNS to a bad name happened), but it is not a hacked cluster.
The uncomfortable part: if you resolve or fetch any user URL with no checks, you also open the door to SSRF — for example a link to 169.</description>
    </item>
    
  </channel>
</rss>
