B (3:17)

So very interesting targeting of European government and military organizations. We have this attributed at the moment to Russia. Nexus espionage actor ankh5837, you mentioned sort of the novel aspects of, of RDP here. Before we get into that, can you just, you know, high level. When we typically see RDP used in cyber espionage or other types of activity, how is it being leveraged by adversaries?

A (3:43)

Right. So as far as I've seen, right, the RDP or the Remote Desktop Protocol, it's a legitimate protocol provided by Windows and Microsoft. And normally the way I've seen it being abused in the past is that you have credentials and you kind of get this interactive access onto a victim's machine with the help of those credentials, or you trick a user to giving someone full access to your desktop in like a GUI like format. And then, you know, then whatever the threat actor feels like doing, they can do a lot of things. They can coax you to doing a lot of things. So, but more of just focusing on the fact that I either trick you to give me full GUI access to your system or I have credentials and I kind of RDP into your system and then do what I will with it. Right? And so that was a lot of, you see a lot of like, kind of support scams where similarly you can use things like TeamViewer and those kind of tools, those kind of interactive tools to control a target system. That's what we've usually seen or I've personally seen the remote test or protocol being used. So it's a legitimate functionality that gets misused normally in like a social engineering kind of context, but also just with, as a lateral movement technique with valid credentials, that's normally how I've seen RDP being used. And that was not the case in this situation.

B (5:06)

So maybe describe for us a little bit what was sort of the early indications that the adversary in this campaign was doing something a little bit more, more novel with their leveraging of RDP.

A (5:18)

Back when this campaign started. I remember that the Computer Emergency Response Team of Ukraine initially posted about this. And what kind of triggered us was that there was this mass sending of emails with DOT RDP File attachments as part of it. And initially when I personally saw that, I'm like, huh, what is a dot RDP file? I don't know what that is. And when we looked into that, then we found out, okay, this looks like naturally it has something to do with the RDP protocol. But then as we started looking into it, we noticed that this is not your regular interactive session that you gain over a victim. I guess the novel part of it started with us just noticing that this weird attachment style of RDP files are being sent out to mass scale victims. And so initially that triggered me of like, what is a RDP file? And then we thought, all right, well it's still rdp, we know what RDP is. And then the next step was as part of the kind of phishing lure that was in the content of the email. What they were saying is, well, this attachment file is actually an application that you run on your machine. And that's when things started to get a little bit novel. Because the way I know RDP is that it's interactive access attacker, gains access to your system, can gooey around like as if they were on your physical machine and then do whatever they want. But in this case, they were talking about an application. And what was interesting was as part of the phishing law, they, they specifically said, please don't enter any personal data. This is, this is just an application that we're gonna run to, I don't know, like we're testing before we roll out this zero trust architecture policy around different organizations. And so it was, it was being, it was being marketed as an application that you run on your machine. And that's where things didn't add up. We're like an RDP file and an application. What's the play here? And so that initially that was the novel thing that prompted us to look into this, because that is not what I've seen with rdp. With rdp it's like full desktop access. But this application style thing, that was something that was new and prompted us to kind of dig into it.

B (7:27)

So there's still some mysteries as to what specifically they were presenting the users as an application. And then there's some other sort of mysteries around again, the particular way they were leveraging rdp. But maybe going into, as you start to research this more, there's a file mapping component that they were employing. There's this sort of being able to present a particular application to the end user, maybe go into these other aspects of the campaign.

A (7:55)

Sure, yeah. So I think the two Most interesting things, and these are, by the way, legitimate functionalities of the remote desktop protocol, just parts of it that maybe we're not that well versed with. But the two functionalities particularly was something we called remote apps, and a remote app was essentially the application that they were talking about. The second part is resource redirection, and that's the file mapping part of it that you just mentioned, Luke. And so with the remote app part of it, essentially what it allows is that rather than showing your whole desktop, the computer that you are establishing the RDP connection with, instead of the whole desktop, you just present one application of it. So I could pick an application like, I don't know, Ms. Paint, right, The Microsoft Paint application. I could say that establish this RDP connection, but don't show the person my entire desktop. Just show them this one application on my desktop. So essentially nothing's actually being sent onto your system or put onto your system in terms of a Ms. Paint executable. But rather, once the connection is set up, it is just visually presenting you with an application off of my desktop and almost kind of cloning or mirroring how that application, how that application behaves between the victim and the attacker machine. So that's what was remote app in this context and how it was used. The other side of it is what we call resource redirection. And once again, these are legitimate functionalities offerings that the RDP protocol gives or offers. And with resource redirection, what happens is when you establish that RDP connection, you can choose to map several resources between the client, in this case the victim, and the server computer, in this case the attacker. And a few of those resources, for example, are file systems. So what that means is that if I'm a victim and I click on this RDB file and it's got resource redirection enabled on it, which it did in this case, my files, and that is in the case of a Windows machine, your C drive, D drive, all of those file systems, they essentially become accessible to the server that I'm making the RDP connection to. So someone on the other side could easily just open up their Windows Explorer, and then they would see all of my mapped file systems on their system, and they can browse it, they can copy from it, they can write to it, and all of this just happens seamlessly behind the scenes, just something that the RDP protocol allows. And so in this particular situation, what was happening was the users were coaxed to click on this RDP file, saying that this would run an application that would kind of test this zero trust architecture policy sort of thing that this email was claiming to roll out. Right. And in the process, what it would do is that it would establish a connection with an attacker controlled RDP server, present an application to the user. It doesn't copy any application by default onto the system, but it just presents an application that's on the attacker's machine. And we don't know what that application is because, like I said, it exists on the attacker control machine. Right. So it presents an application, but at the same time it also maps the victim's file drives to the attacker's file system. And that means they can do any kind of read and write operation that they'd like on the victim's file system. And while the victims all, you know, seamlessly in the back end being kind of, so to say, distracted by whatever application the attacker chooses to put in front of them, those were the two things that we saw in this case.

B (11:32)

So the resource redirection piece of this, that makes sense from what a cyber espionage threat actor would be interested in doing. Essentially allowing them to access or even exfiltrate data files on a victim system. The remote apps component, I know we don't know specifically how they were leveraging that. One can imagine some scenarios in which, you know, for example, presenting an application that looks like a VPN and getting the victim to enter in their credentials, or any other application that would require the victim to enter in credentials. Any other sort of ideas of how they may have been leveraging that remote apps functionality? Again, we don't know specifically what was presented to these victims, but any guesses of what other sort of scenarios a threat actor like this might try to employ this for?

A (12:21)

Yeah, yeah, sure. It's, it's just such a, in a way, it's such a beautiful technique because of the number of things that one can do using this and the lack of, the lack of visibility that we would have over what was actually done, just because everything's on the attacker server. So we can't really say for sure. And that's, that's the issue with this. But in terms of what they could have done, well, if I was an adversary, what I could do is I could either present an application that resembles a phishing page particular to their organization. Right. So I could steal creds off of it, or on the other side, I could also, I don't know, masquerade an application to look like it was just, I don't know, an error box on your victim machine to say that, oh, something didn't run, right. But, hey, we can fix this. Go into this folder on your system and run this application, and it'll fix everything. And so, and what that application could be would be an application that I, as an attacker, place on the victim machine when that. When that connection is being set up. Because while we're presenting this remote app, we also have file system access. And so while me, as an attacker, cannot run a file directly on a victim machine, as a result of this technique, I could always place a file on the victim machine and then via the remote app, coax them in some way to run it. Those are a few ways I can think of abusing this functionality. One more thing, which I forgot to mention, but I think is very vital, is file system mapping. That's one kind of resource that can be redirected between the victim and the attacker server, but there are many other kinds. And another one which is particularly interesting is the clipboard. So a victim's clipboard, at least in this campaign, gets fully mapped onto the attacker's machine. And so that means that as long as that RDP connection is active, right, as long as that remote app is presented to the user, maybe they open the connection and minimize the application, continue going by that day. All that time, while that RDP connection is active, anything that the victim copies onto that clipboard gets sent to the attacker machine via rdp. And that could be even passwords. It could be other sensitive things. So as part of that, maybe as part of the remote app, you could just ask a user to, I don't know, open some sensitive document and then just copy that content somewhere. By just doing a copy operation, the attacker is then fed with all of that information. So really, the creativity of what's possible once this RDP session is established is. Is a lot of things. And yeah, I think aside from clipboards, there are several other resources that can get mapped. Things like printers, keyboards, mice, serial ports, even things like hardware keys like Yubikeys and Google Titan keys. Those can also get forwarded between the RDP sessions. So audio devices even. Right. One thing that was particularly interesting with the clipboard mapping was that if you have a virtual machine, like if I'm a victim and I have a virtual machine that I use to do my work, because, I don't know, I believe it's safer or something. But the clipboard between my host machine and the virtual machine are mapped to each other were I to open this RDP file in my virtual machine, because my clipboard from my host machines mapped to My virtual machine, even that content, my clipboard content from my host machine, would get sent over the RDP connection. So it's very interesting. I think the range of resources that get redirected, combined with this fact that an attacker could present any application that they like to coax the user to run something, to coax the user to input their credentials for phishing, to coax the user to just copy something on their clipboard. Right. All of those just present a range of options for the attacker. And interestingly enough options that because everything honestly happens on the attacker server and it's just presented to the user, it becomes very, very challenging for us to figure out what happened and let alone detect it.

B (16:39)

Well, I think, you know, hearing you describe this, it's very clear that both of these components within rdp, but especially taken together by a very entrepreneurizing, entrepreneurial threat actor, can present, you know, through leveraging social engineering and then the capabilities within this, a range of different ways to go about compromising a victim machine. I wonder, because of that, you know, getting now into more of the sort of detection challenges here, given that this is a very low signature technique, what are some of the ways organizations can combat this type of activity? Look for this, harden against it. What are some of your thoughts kind of coming out of the investigation here of things that a defender can take to kind of make this more difficult for an adversary to leverage?

A (17:30)

Yeah, that's a good point. I think from a hardening perspective, there are a couple of group policies that you can enable on a Windows system that would disable the things like resource redirection to ever happen on a victim machine. And a lot of those times these policies are kind of not configured by default. And so you would have to explicitly go in there and configure them to say that do not allow something like drive redirection. You can go quite granular as to what type of resource you would like to prevent redirection of. Right. And if you know in your organization that's not something that you, that you would normally use, maybe your IT support team, which would normally be the team that would use these kind of functionalities, they are not, they have that they have other tools that they would leverage to do this kind of remote support, and you don't really need to have this enabled via rdp, then it would be great to kind of just go in and disable that. So even if you were targeted, you can't have this attack execute because it's disabled by policy. I think on the resource redirection Side that's something that can happen on the remote application side and just the remote connection side, the RDP connection side. One thing which I think was interesting as part of this attack, and then I'm going to come to the defensive side of it is these.rdp files were signed using a certificate that was also used for the domain that the connection was then made to. And why an attacker would sign these RDP files is so that normally when you, when you try to open up a RDP connection and it's an unsigned kind of connection, you get this little warning box on the top that says that, you know, this, this, this could be an untrusted connection or we don't fully trust the, the publisher of this, of this file. And that shows up as a yellow warning box by default. Windows, right. One would one in this case the file was signed largely to prevent that pop up for come from, from showing. And so it just looked like a regular run this application kind of, kind of pop up box, which is what I assume the adversary would would want because they were saying that this is just an application. That's how their lure was working. Right. And so to make it less suspicious, the sim the file was signed and it was signed with the certificate that was used for the domain that this connection then went to, which is slightly interesting and not so common behavior. And one way that you can combat this is again within the group policies. There are certain policies which are again listed in the blog that allows or disallows.rdp files being run from unknown publishers. Right. So ideally what you could do is that you could turn on that policy and say you can run a dot RDP file in my environment, but only if it's signed by a certificate that we know about. And there are two distinct policies that can allow that. One of them that says don't run unknown publishers and then another one that you can configure as to what are your known publishers. So then the next time say you don't know in your organization if you're ever going to use RDP files, you don't want to disable it altogether. But you do know that if we use it, we're going to use it from certificates that belong to organization, you can configure the group policy to say that these are the certificate authorities that my organization trusts. Do not run any other RDP files that aren't signed with exactly this publisher. So that's one way we can combat this. And then we already spoke about the resource redirection part so that's more on the policy side of things. In general, if you feel like dot RDP files are not something that your organization would ever use, let alone send over email, it might be worthwhile considering disabling RDP file as an extension type at all within emails. So that's something else that's more on the hardening side. One of the kind of hunting techniques that we advocated for within the blog was normally if this delivery method of RDP files is via emails, you get an email, it has an attachment in it. Normally you would just double click the attachment and run it. When you double click attachments on emails, they get stored in particular known almost temporary folders within a machine, a Windows machine, and you can actually look for dot RDP files within those directories. And that's kind of like a retroactive thing. If you know that or you suspect you could have been targeted by this campaign, that could be an interesting thing to look for, kind of retroactively hunt for. Because normally those folders also get cleared out over time because they are kind of temporary folders. You're not explicitly saving the attachment on your system, but you're just running it directly from an email. So those regexes provided some patterns that you can kind of retroactively hunt through to find that, hey, someone executed this.rdb file directly from their email and then kind of look into it from there. Again, if that is something that's, that's something that's, that's not common within your environment. I think on the other side, on a more from a detection perspective, normally when an RDP connection happens, there are a bunch of files that get written onto the victim system. So right now I'm just focusing on what happens in an environment that we control. So we don't control the attacker's machine, but we do have some visibility over a victim machine. And I like to focus on what happens on that system that could indicate that such a technique or such trade off had occurred on the system. One of them is that you can look for file creation events that spawn from the MSDSC binary, which is related to the Microsoft RDP protocol. And unfortunately that kind of activity, file rights that originate from that process, is not super uncommon because during the regular, even a completely benign connection of rdp, which could be normal in an environment, there's a bunch of files that get written in a few locations, file locations that we've mentioned in the blog. But if you know what those files are, as well as what pattern they normally naming pattern, they go with and which location they happen in. If you could look for file creation events that excluded those, you could potentially find evidence of manual writing of files onto the system. So like we mentioned before, Luke, if we were covering that scenario where an attacker places a file on your system and then via the remote app coaxes you to run it, you could potentially find that using, using a detection like this. So the only hard part is you got to get away from all the regular benign noise that this kind of activity displays. So those are a few ways I think that we can battle this kind of technique. Aside from, I think the blog has a couple of Yara rules that is focused on looking for dot RDP files or RDP configuration files that allow for remote app execution, that allow for resource redirection, that are signed by. In this case, a let's encrypt certificate was used. So that's another detection that we've gotten there. So we've got a combination of things that you can use to retroactively hunt for this activity, things that you can use to harden your environment against future such activities. And yeah, also things to look for in the future when we want to detect this kind of activity.

B (25:13)

And we'll include a link in the show notes to that blog, which is out now, good resources in there and more stuff that we didn't even get a chance to get into. But kind of tying this together and zooming out a little bit, putting this in context from other campaigns that we're seeing from other threat actors. You know, reading this blog made me think of that the M trends from last year where we talked about the trend of evasion of detection, right? More threat actors putting more care and effort into using more novel techniques to make intrusions into organizations that fall outside of traditional security detection visibility. When you think about this particular technique and even this actor, but the technique overall and even some of the other components of, you know, the mass emailing component that sort of began this whole operation, the various ways that RDP was leveraged. What are some of the ways you think that this could evolve going forward in the future? What are some of the ways that is this a trend that you expect to see more threat actors leverage? How do you think about this kind of going forward?

A (26:17)

Oh, definitely. I think threat actors would love to stay in spaces that either we as defenders have low visibility into just because we've never needed visibility into those areas in the past, or even better, just functionalities that are native to a system, functionalities that are less known to folks and hence have Less coverage or less likelihood for coverage, both from a visibility as well as a detection standpoint. So I would like to think, and this is the kind of trend we've seen depends upon the threat actor. Right? But then you want to. When you think about threat actors, what do you want to do? You want to achieve your goal, and then you want to. You want to achieve your goal without being stopped, at least before you've achieved it. Right. Some are a little bit more stealthier than others. Some don't care. As long as they're. They're quick and fast to hit their objective, they're happy with that. But in doing so, they would like to focus on areas that would likely not stop them from achieving their objective. And those areas are normally areas that have less visibility or no visibility. You look at things like network devices, like routers and stuff. Why do threat actors expose that? Because they know that we lack the kind of visibility in those areas. At the same time, you hear a lot of these things, like living off the land binaries, bring your own drivers, all of these areas that are common or normal to see in a system. Right. And they use it in a slightly different way in order to achieve their objectives, because they know it's going to be. We might have visibility in that area, but spotting the needle in the haystack within that is not easy. And so we've seen attacks like this. We. I think we're also. There's going to be no shortage of such. Of such techniques being abused in the future. And for us, I think what's important is the first step towards even being able to detect this is just knowing that such a thing exists. Like, I, for example, did not know that RDP had these abilities and that this was legitimate functionalities that were in this case, just creatively utilized by an attacker to. To achieve that objective. And then aside from that fact. Well, yes, because it's legitimate. And I think it was kind of like a perfect storm here because this was one of those kind of rarer sides of the technique to witness. And over and above that, just an area that, in general, I would think that we don't have that much visibility into. So you put those two together, and that's like the perfect area or the perfect way that a threat actor could kind of get to the objective when they utilize techniques like this. So, yeah, in short, I think we've seen it before. We're seeing it right now, and we're going to continue to see it in the future. And that's why podcasts like this blogs like this that talk about just this attack and this tradecraft kind of like tradecraft intelligence and how it works, it not only brings light to this topic and helps people know that hey, such a thing exists. The next time we see this, we should not be surprised that RDP has these functionalities that it can be misused this way. But we should also know where to look when we suspect that such a thing can happen. And that's where just, you know, maybe we don't have that much of as much detection coverage around this technique as we would hope. But by knowing that such a thing exists, knowing the ins and outs of what an attacker is even capable of doing by abusing this technique, we stand a better chance at making kind of educated guesses in the future where we don't have visibility. But we know that oh, this technique works in this way. So if we're seeing this kind of activity, they probably went and did this next and we have that little next step to look at. And I think that's one way that we battle this kind of uphill battle of visibility and just not having not not knowing about certain techniques or seeing the abuse of common techniques that are, that are difficult to distinguish between good and bad.

B (30:13)

I said that was going to be the last question, but I actually had a thought as you were talking there, going back to earlier when, you know, I think in the blog it references the mass emailing component of that and I'm just curious your thoughts about. There's many aspects of this campaign in this activity that are very stealthy and that the threat actors, you know, employing essentially a living off the land technique to maintain that stealth with some likely user interaction as part of that. But I'm curious how you see that mass emailing component factoring into this. You know, we're kind of zooming out to the whole attack life cycle because that component seems a lot noisier given the fact that it's sort of mass and potentially affords more opportunities for initial detection. So I'm curious just how you think about, you know, the majority of what we're talking about in this blog, but then also the fact that this was kind of sent out as part of a mass phishing campaign.

A (31:04)

Yeah, you know that that's an interesting part. So we saw this kind of mass email campaign going out and if you read other blogs on this topic, like I think it was trend that covered this topic a little, they went a little bit deeper into the domains that were used by these threat actors. When were they set up? And things like that. And then they found evidence of this kind of infrastructure being set up all the way back to August last year, when we only saw the attack back in October. So one can speculate that for them to go out in this kind of loud fashion with the mass emails, like, let's face it, if you send out a mass email that's like this and you target the organization that you target, you're going to come to light. People are going to post about it. Blogs like this are going to be written, researchers are going to jump into it. But looking at it, when you think that there's already been a lot of setup that went on with this months before, one can't help but wonder, well, what happened between the time when this infrastructure was stood up to when it actually came to light, or when they chose in a way to expose themselves by going mass email style? Right. And so that's an area. That's still a question, Luke. So we don't know what happened there, but it makes me question that was this. That the objective was, or the large part of the objective of the operation of threat actors was already achieved when they went all out, big bang, or was it always part of the plan to execute the full operation in this way? Those are still questions we don't have answers to, unfortunately. But it does make you wonder.

B (32:43)

Yeah, another. Another mystery as part of this operation. I just, I thought it was an interesting juxtaposition and certainly maybe if it was at a stage where they thought that some of that infrastructure was burned or parts of this operation previously had been burned, going out with one last blast, you know, you're probably increasing your odds that someone in one of the targeted organization is going to click on and execute, you know, that component of the operation. But I just thought that was an interesting juxtaposition between these aspects of the campaign.

A (33:13)

Yeah, 100%. It could have also been that whatever this operation was of the threat actors, maybe it was already done, maybe it was already achieved. And then at the end they said, well, we've stood up all these things. We've achieved our mission. What else can we squeeze out of this? Can we squeeze some credentials, can we squeeze some more access to some systems out of it that we use for our next campaign? And then just like we don't care if we get detected at that point, let people know that this is how we're doing. It could have been that too. Who knows?

B (33:41)

Well, it's a very interesting story. It's a very interesting blog, Rohit, thank you for your time today. As I mentioned, we'll include a link in the show notes. Some of those other aspects and things that we didn't get to in this podcast will also be included on that blog. So please go check that out. And Rohit, thank you for your time today and the excellent work on this blog.

A (34:01)

Thanks a lot. Yeah, I'm excited to see how the community reacts to this and thanks for having me here, Luke.

B (34:05)

Take care.

A (34:06)

Cheers.