Podcast Detail

SANS Stormcast Monday, February 16th, 2026: Graph Generator; nslookup and clickfix; Chrome 0-Day; TURN Threats

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9810.mp3

previous
Podcast Logo
Graph Generator; nslookup and clickfix; Chrome 0-Day; TURN Threats
00:00

Podcast Transcript

 Hello and welcome to the Monday, February 16th, 2026
 edition of the SANS, Internet Storm Sonners Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. and this episode is brought to you
 by the SANS.edu Graduate Certificate Program in Cyber
 Defense Operations. In diaries we had one by Russ McRee from
 Friday about graph generators and APTs and how to automate
 creating these graphs with AI. There's a relatively new tool
 by Robert McDermott that Russ used for this diary and it
 also solves a couple different problems. First of all, often
 when you're looking at sort of threat intelligence, it comes
 in unstructured forms. Yes, there are probably more
 standards we need, but quite often you have articles and
 such that do describe particular threat. They may
 mention indicators of compromise and such. They may
 mention IP addresses, host names, and then also like what
 these systems are, who they belong to. And where this gets
 then really powerful is where this tool not only extracts
 these indicators, but it also then creates graphs displaying
 the relationship between them. I can see this in particular
 useful for the largest of aggregations of reports to
 sort of find a common sources of attacks, but also attack
 attribution. This may be helpful if you're into this
 kind of things. So certainly interesting tool and works
 here as Russ describes on commodity hardware. You don't
 need anything sort of special AI, but relatively modest, my
 opinion, laptop does work to create these graphs rather
 quickly. And Microsoft's threat intelligence team
 published a quick social media post about a new variety of
 the famous click fix attack that they're seeing. So click
 fix, the victim is being tricked into copy pasting a
 string from what looks like captcha into a command prompt
 and executing them. Now, a lot of defensive techniques then
 focus on sort of these living of the land binaries that are
 being executed here. What's sort of different here is that
 they're actually then retrieving the next level
 PowerShell script via NS lookup. And also the NS lookup
 kind of is a little bit tricky here. So the NS lookup is for
 example.com, which of course is the test domain and
 commonly considered harmless, but they're sending the
 request to a custom DNS server that will then return a CNAME,
 basically another host name. And that host name is the
 PowerShell script that's then being executed. Quite often
 when you're looking for DNS anomalies, you're looking
 basically for odd host names that people are looking up.
 And in this case, it will really just be initially at
 least the example.com. The odd CNAME coming back would
 certainly be a tip off then. And then of course, maybe if
 you're seeing any lookups then for the A record for that
 particular PowerShell script, that would certainly trigger
 some alerts. Also because the name being looked up here is
 fairly long and has odd characters in it. But probably
 the best sort of defensive technique here is to just
 eliminate lookups to unauthorized DNS servers,
 internal users should look up via an authorized recursive
 name server or forwarding name server that will then forward
 queries to both for example, a provider like Cloudflare or
 some filtering service like OpenDNS. And Google released a
 new version of Chrome on Friday. This version fixes one
 vulnerability, use after three vulnerability in cascading
 style sheets that is already being exploited in the wild or
 at least an exploit has been cited in the wild. So
 definitely keep Google Chrome updated as usual. Restart it
 once a day in at least once a week. Double check that you're
 running the latest version. And we have a good article by
 Sandro Gauji summarizing some of the issues with turn
 servers. And I don't really see people talk much about it.
 So that's why I add this as a reminder here. Estan, turn are
 both protocols meant to allow media streaming across NAT.
 Estan usually just helps you set up the connection, but
 then the connection works directly sort of end-to-end
 through NAT. Now if Estan doesn't work, then you can use
 turn, which also release the media traffic through a server
 that is reachable by both sites. The problem with this
 is that you're essentially introducing these proxies,
 these turn servers that can be used to more or less proxy a
 wide range of traffic and often sort of the inherent
 access control in these servers isn't all that great.
 They're really sort of focusing on making things
 work, which then often leads to abuse of these servers, in
 particular if they're hosted inside your infrastructure. So
 definitely something to be aware of and be cautious of
 that you are not really relaying here any traffic that
 you don't intend to relay. And yes, this is sort of a good
 sort of review of the different issues that can show
 up with turn. 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.