Podcast Detail

SANS Stormcast Tuesday, June 2nd, 2026: Netlogon Exploit; Unidentified RAT; Windows Netlogon Exploited; RedHat npm Affected; Dashlane Bruteforce Attach

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/9954.mp3

Podcast Logo
Netlogon Exploit; Unidentified RAT; Windows Netlogon Exploited; RedHat npm Affected; Dashlane Bruteforce Attach
00:00

My Next Class

Click HERE to learn more about classes Johannes is teaching for SANS

Podcast Transcript

 Hello and welcome to the Tuesday, June 2nd, 2026
 edition of the SANS Internet Storm Center's Stormcast. My
 name is Johannes Ullrich, recording today from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Creative Certificate Program in
 Cybersecurity Engineering. In the diaries today, we have a post
 by Brad talking about a new RAT, a remote access tool that
 Brad found. Now, in the end, this particular infection ends
 up with NetSupport RAT. And it starts out with sort of a
 standard click-fix campaign. But in the middle, there is an
 interesting RAT that really shows some odd behavior. For
 example, it uses HTTP over port 443. And then it also
 uses just data over port 443. That's not TLS. It uses some
 kind of custom encoding. So nothing that Brad really sort
 of found being written up to before. Definitely something
 that also I don't remember seeing particular, seeing just
 HTTP over port 443. Not really sure why, if that's supposed
 to basically fit in with other HTTPS traffic. These days, the
 bad guys pretty much use HTTPS exclusively, just like anybody
 on the internet. So if anybody has any insight here for Brad,
 please let us know. And the Belgium Center for
 Cybersecurity is warning that vulnerability that Microsoft
 patched in May, that's the Windows Netlogon vulnerability,
 is already being exploited. Haven't seen anything official
 from Microsoft, but they may be busy consulting with their
 lawyers about this. So assume it's being compromised. Make
 sure you are patched in order to exploit this vulnerability.
 And hacker would actually have to connect to port 389 to the
 LDAP port. There is an plausible exploit, I should
 say, that's posted to GitHub. I haven't tested it yet. As
 always, be very, very careful with anything like that. Who
 knows whether that's an actual exploit or just a fake one.
 I'm not going to link to it either for that particular
 reason. But yes, assume the compromise is happening out
 there. And hopefully, well, you have halfway sane firewall
 configurations that would at least not allow any external
 access to any of the ports being used by Netlogon And
 the Bini Shai Hulot or Team PCP snowball keeps on rolling,
 keeps getting bigger. The latest victim is Red Hat. And
 over 30 packages that were published officially by Red
 Hat as part of its Red Hat Cloud Services scope for NPM,
 well, have been compromised and have been infected with
 the usual credential stealer. Of course, probably leading to
 even more compromises next week. These packages were
 published via GitHub Actions and that uses OpenID Connect
 for publication. So most likely this means that the
 particular CI CD pipeline being used for these packages
 was compromised. And there's of course always a chance that
 other software that is published by Red Hat or such
 may be affected in this overall scenario. And password
 manager Dashlane had apparently some problems with
 brute force attacks the last couple days. Now, some users
 interpreted as Dashlane being breached. That appears not to
 be the case. According to Dashlane, what happened was
 that there were fairly aggressive and intense brute
 force attacks against Dashlane users. Dashlane did lock some
 of these accounts, which was best practice after a number
 of failed logging attempts. And that essentially resulted
 in a denial of service against a large number of Dashlane
 users. Big problem here, of course, with these password
 managers that they sort of are all into the cloud sync model
 where you have to authenticate in order to sync your password
 via their proprietary solution. That, of course, is
 particularly susceptible to these kind of denial of
 service attacks where the central hub that's been used
 to authenticate users is no longer reachable because they
 locked your account. I would expect Dashlane by now to have
 unlocked any affected accounts like one workaround here to
 avoid sort of widespread denial of service attacks in
 these situations is to essentially automatically
 unlock accounts after borrowing for a particular
 account ceased. Hope that's the case here for Dashlane
 users. But again, not a breach of Dashlane at this point.
 It's really just an attack that they mitigated by locking
 accounts. Well, and this is it for today. So thanks for
 listening. Thanks for liking. Thanks for subscribing. Hope
 to see some of you at Science Fire again. And we'll talk to
 you again tomorrow. Bye.