SANS Stormcast Friday, May 30th 2025: Alternate Data Streams; Connectwise Breach; Google Calendar C2;

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

previous

Alternate Data Streams; Connectwise Breach; Google Calendar C2;

00:00

iTunes

MP3 Download

RSS Feed

Google

Podbean

Amazon Echo

YouTube

Spreaker

Spotify

Discussion

Login here to join the discussion.

Podcast Transcript

 Hello and welcome to the Friday, May 30th, 2025 edition
 of the SANS Internet Storm Center's Stormcast. My name is
 Johannes Ullrich and this episode brought to you by the
 SANS.edu graduate certificate program in incident response
 is recorded in Jacksonville, Florida. And today's diary
 comes again from one of our undergraduate interns. And
 well, it's a good summary of alternate data streams,
 basically what they are, how to defend against them, how
 they're being used offensively. Keep in mind that
 alternate data streams aren't always malicious. There are
 some normal occurrences of alternate data streams. Well,
 that's why they exist in the first place. They were really
 initially sort of meant to sort of annotate files. So one
 way how they're being used, for example, is as part of the
 mark of the web to basically define a certain file was
 downloaded from the Internet. And then you may find
 additional details like, for example, the URL that it is
 being downloaded from. Anyway, if you're not that familiar
 with alternate data stream, it's a real good primer here
 on what they can do and how to better understand them. And
 ConnectWise published an advisory stating that they
 have been breached. The problem with this is that,
 well, one of their problems, Screen Connect, was apparently
 affected. Now, they're stating only a small number of
 customers were affected. But this is really sort of a
 current trend where these remote access tools are often
 being compromised to then gain access to victims' systems. I
 talked yesterday about some of the issues with MSPs. And
 there we had simple help as sort of the entry vector. Of
 course, the more traditional tools like RDP and such are
 also at the top of the list of what attackers are looking
 for. Only a one-paragraph advisor here from ConnectWise
 with not a lot of details. So don't really know exactly how
 many customers or how the bridge exactly evolved or how
 you could figure out whether or not you are affected. They
 are supposed to reach out to affected customers. And
 Google's threat intelligence group has a nice write-up
 about APT41 and what they're up to these days. That's sort
 of one of the, I would say, older at this point,
 established APT groups commonly associated with
 China. And one of the new tricks they're using is to use
 Google Calendar as a command and control channel. In order
 to do that, they set up zero -minute events. So it's not
 really that visible at the specific date. And then just
 basically exfiltrate data as nodes to that date. This is
 the typical difficult-to -detect kind of command
 control channel. It's just sort of mixed in with all the
 other traffic that you probably are seeing to Google.
 Also, the rest of the infrastructure is pretty much
 in Cloudflare, another provider that's used for a lot
 of normal traffic. So really difficult to distinguish them.
 Probably your best bet is, well, trying to detect these
 odd calendar events if you have any visibility into that.
 Or then, of course, just look for data volume. And yes, the
 initial spear phishing email. But, well, they have their own
 sort of usual difficulties in actually detecting them
 proactively. Don't read too much into the details of the
 indicators of compromise being shown here. Like, for example,
 the exact date being used for these calendar invites. That's
 going to change if probably has already changed. So
 that'll only help you find some of the older attacks, not
 anything current. Well, and it's Friday again. So we do
 have yet again another Sanson EDU student to talk about some
 of our research projects. Oren, could you introduce
 yourself, please? Oren, could you introduce yourself,
 please? My name is Oren Miskin. I live in Houston,
 Texas. I've been in the industrial control system,
 cybersecurity realm for probably 20 years, starting
 off as an electrician, actually, on a nuclear
 aircraft carrier with the Navy. And I kind of worked my
 way up the Purdue model, I like to say, until eventually
 I was running an OT security program for a large drilling
 contractor, oil drilling here. And that's what brought me to
 Houston. And then I got sick of making an honest living and
 I moved to consulting. So I worked at EY for a few years
 and now I'm at GuidePoint Security. I'm really liking
 it. Yeah. And your paper was also the industrial control
 systems. As I said, some people are worried about the
 lights coming in the morning. I'm more worried about my
 coffee maker. But so what was the paper about there? So the
 paper, after working in industrial control system
 security on the blue team and the red team, what I noticed
 is there's a lot of concentration on finding
 targets once they're inside the OT network. So OT cares
 about the OT network. IT cares about the IT network. And
 never the two meet. And what I noticed, though, working on
 these red teams, especially at GuidePoint where I'm at now,
 is there's a lot of activity that happens on the IT side
 that I think was really useful to be able to catch attacks
 before they hit the OT network. And that means if you
 can catch them in IT, it's much cheaper to respond to,
 less disruptive, much safer, less risk of causing an
 industrial incident. And that's what the paper is
 about. It's finding ways to, using deception, to trick
 attackers into revealing themselves in the IT network.
 And then you can block them before they ever touch your OT
 network. Yeah. A little bit like shifting left in the ICS
 world. Is this sort of... Exactly. Yeah. The earlier we
 get it, the faster, the cheaper we can remediate it.
 Is the IT network interesting because that sort of really
 connects your network to the internet? So that's the
 exposure? Yeah. I think like a typical attack chain is
 somebody in the IT network gets phished. And now they
 have credentials in the IT side. And they start
 enumerating the IT network users and groups. And they
 discover OT resource or paths to OT from the IT network.
 Usually the compromise of OT network starts in IT. So they
 get in the IT network and they start looking around for
 systems that can get them to IT and users and juicy files
 like, you know, turbine safety specifications or, you know, a
 contamination spill response plan. And they exfiltrate
 these things. And we've seen it over and over again in
 these attacks. They exfiltrate them and then use them later
 in the attack. And deception, how does that fit in? Like I
 use it, of course, heavily for research purposes. But how do
 you sort of make that work in your networks? So I got turned
 on to this by John Strand's YouTube videos. And what he
 does is he sets up, let's say, the three deception tactics I
 focused on was deceptive files, users and systems. So
 first of all, you should segment your OT network from
 your IT network. So you don't have OT. You have OT in its
 own boundary that access is controlled in and out of. So a
 user on the IT side should not be able to manipulate things
 on the OT network. Well, once you have that in place and the
 attackers are looking for systems and resources in OT,
 you could place fake systems, fake users and fake files that
 look really juicy to the attackers. And when they
 interact with them, it raises an alert. So in the research,
 I said I had a fake file that said remote access
 instructions. And this is a typical thing. We were just on
 an assessment a few weeks ago and found a file that's
 something like how to enroll in multi-factor for OT. And so
 the red team I was with, of course, they got super
 excited. And you could see their faces light up like, oh,
 we found something. And they downloaded that file. And so
 my research says you could do the same thing, but just the
 file is not legitimate. And when somebody accesses this
 file, then it sends you an alert. And I think what John
 Strand was saying is if you only have that on a few files
 that normal people wouldn't access, but an attacker
 searching the file system for strings, searching the file
 system for interesting things to them might trip over this
 and let you know they're there. And I think that's
 really the hard part with this deception techniques. You want
 the attacker to find them, but you don't want the false
 positives from some regular user who just forgot how to
 enroll in two-factor authentication, doing sort of
 a random search on the file system and coming across that
 file. How do you balance that? Any tricks here that you
 learned? And the paper focused on small organizations. So I
 was figuring if you have a small organization of like 100
 people or something like that, the engineers that are going
 to be accessing the areas that I think pretty, you could tune
 out the noise pretty quickly. Like people that are working
 in these systems would may trigger it once or twice, but
 after a while, they'll know that's the decoy and they
 won't touch it. But if you had a large multinational
 industrial organization, I could see that being a huge
 challenge. Yeah, it may actually help. I always think
 that deception is a little bit overlooked because it doesn't
 create false positives. Most of our security controls, they
 kind of show value by ever so often triggering alerts. And
 if you have a control like deception, it never triggers
 anything. I guess that reminds me that it's still working if
 you get these false positives ever so often. Yeah. Any then
 tips how you react, how you respond to this? Yeah, that's
 the main benefit is that you get to respond to this while
 they're still in the IT network so that you can eject
 them from the IT network. Because once they're in OT,
 now you have to worry like if they compromise the OT user
 and you boot that OT user, is that user logged into some
 processes that will affect operations? Or if you stop
 processes, it can get complicated and takes longer
 and more risky to respond. But yeah, responding to these
 incidents in the IT side, one important thing to add is
 sharing it with the community. So once you discover some
 actor searching for OT systems in your IT side and you get
 some intelligence on that, you could share it with the
 information sharing agencies like the Water ISAC or the
 Power ISAC. And if they're sharing with you, then it
 builds like a community defense. And all this is
 before the OT network is even reached, which is really good.
 But yeah, tuning is probably the most challenging part of
 this. There's dealing with those false positives, maybe
 dealing with scanning tools that touch every file. Or I
 could see that being an issue. But once an alert is
 triggered, it seems like the response is much simpler than
 if it were a legitimate attack on the OT side. But the
 challenge is, of course, merging the two security
 teams, IT and OT, to communicate and respond
 effectively. That's the main challenge, I think. Yeah, and
 I'm not sure if the Windows or IT response teams like that,
 you call their life easy. But it's probably easier than
 doing the same thing in OT, where you have much less
 access and the tools and such for systems. I don't think
 their life is easy at all. So there's a lot of action going
 on in the IT side. But for an OT incident specifically, they
 have a lot of pressure. Yeah, great talk to you. Great
 paper. And the link to the paper will be in the show
 notes. Any final words, anything you're working on
 right now that people may be interested in? So, yeah, I'm
 doing my new research I'm trying to work out is
 discovering dual home systems in OT. So this is another
 thing I see a lot in assessments is people having a
 system that has one leg in the IT network and one leg in the
 OT network. And it's really hard to find these because our
 tools only monitor the OT network. And so how do you
 find that second network card that's attached to another
 network, maybe even the Internet? Interesting. So
 thanks for joining me here. And thanks for listening. And
 hope everybody has a good weekend and talk to you again
 on Monday. Bye.