Eric Brown: 0:05

You're listening to the Audit presented by IT Audit Labs.

Mathew Wold: 0:16

I'm sure some of this stuff is maybe pretty common sense, but we'll just touch on it anyways, just to make sure that everybody's on the same page, you know. So just a little agenda here. Just we're going to talk about unquoted service paths, a demonstration of that vulnerability, and how the Cortex XDR unquoted service path was really discovered and what we did with it. So discovered and what we did with it. So you know, just deep diving into unquote service paths here. What is it? Why is it dangerous? How do you find these things? And then you know how do you remediate it. So those would kind of be the four things that we cover over the next couple of minutes here.

Mathew Wold: 1:02

So I think the best thing to do is just kind of start and, you know, talk about what is a service. You know, essentially it's a background application that runs usually when the computer starts up, but that's not always the case. Some services, can, you know, be designed so that way they have to be manually started. So in this case, you know, we're really looking for services that auto start when the computer starts, and the interesting thing about that is when they're started they're usually run with elevated permissions so that way they can do whatever they need to do. And that's part of what makes them dangerous is because they have those permissions and you know we can use them to exploit the machine and, to you know, do a whole bunch of nefarious things if we wanted to.

Mathew Wold: 1:48

And so you know, with services comes service paths. So most of those service paths can be found, you know well, in the registry at this location. You know the control set, 001 services. So if you're kind of looking for those, that's where they would be, and services only need to be quoted if there's space in the path. So a lot of cases there isn't a space In this example here. You see, it's just, you know system root system 32, and you know it's essentially the principal service and you know you won't find that quoted because there's no spaces in that image path and so it's not vulnerable.

Kyle Rosendahl: 2:31

So just to clarify, like a service path would be the. It would be like the path on the machine where the actual executable is found. I guess you're here on it, but it would be kind of that directory structure where it's saved on the computer and where it's pointing that application to. Is that right?

Mathew Wold: 2:51

Right, yep, and we see that here in this example. In this case this is a Windows Media Player, and so you can see the path to the executable. Is right here. It's this C program files, windows Media Player, and then you know the name of the executable. Is right here, it's this C program files, windows Media Player, and then you know the name of the executable. So in this case, because there are spaces in this file path, you know Microsoft has quoted this, and so when it goes to run, you know it just runs this entire path.

Mathew Wold: 3:21

If it wasn't quoted, what would happen is the computer would go through these folders and so essentially it would start at the very beginning and it would look at C program files and it would ask is the application I'm trying to run programexe? And because there isn't a programexee there, it moves on to the next folder structure, and so then that goes to the windows media player. So then it starts with c program files windowsexe and if there's nothing there, then it goes to windows mediaexe, and if there's nothing there, then it goes to the next folder structure, and and so until it finally hits something that's there, and so anywhere along this path. If this was unquoted and we had, you know right, access to any of these folders. You know that's where we could drop the malicious code or executable into. You know, do whatever we wanted. So it kind of makes sense. I explained that.

Kyle Rosendahl: 4:28

Okay, on these, yeah, no, I think you did a good job on that. What is it about the spaces that causes Windows to have problems with it, and would it happen if it were similar on like a Linux or a Mac OS box, if they had running services like this?

Mathew Wold: 4:44

Yeah, that's a great question. So you know, the space in that folder structure is really where Windows stops to check to see if you know that, if that's the executable that it's looking for because it doesn't know what it's looking for it's just going through these folders and hitting these spaces and then checking to see if there's something that's actually there. Yeah, and so here I just added a slide here for what an unquoted service path would look like in the registry. So here you can see that this is for the test VM box that I set up, you know, so that way we could kind of demo it. This is from that box and so you can see. You know the spaces in the folder structure and how you know this image path isn't quoted, so it's it's vulnerable. Just making sure that you know.

Mathew Wold: 5:42

We kind of cover the the basis on. You know what's needed to exploit this. You need to have an unquote service path. It needs to be in a folder structure where you can have right access to it, and then you need to be able to get some sort of executable malicious file in there. So yeah, I think we're going to take a look at some stuff that you can do with that next here, and this is dangers of unquoted services. So what can you do with it? It seems like maybe it's not really a big deal when you know, when you just think about quotes, you know you're missing some quotes. But at the end of the day, you know you can do privileged escalation. So you can take just a standard user account and you can, you know, escalate that into a privileged account. You could drop ransomware there. So that way, you know, when the computer boots it executes, you know, some sort of ransomware package you could do malware and through you know, like Metasploit, you could do some sort of reverse shell and export data. So you know it's a pretty big deal.

Mathew Wold: 7:02

So how do you discover Uncoded Service Paths? You know, I think one of the best ways to do this here is using vulnerability management software like Rapid7's Inside VM or Nessus. They'll both, you know, look for these vulnerabilities and report back on them. If you don't have access to something like that, you can always manually search using the WMIC service, and that's one of the things that we're going to look at here in finding these, you know. So if you have just a couple of machines, you could do that, you know, I suppose you could script something to look at a few different machines across the network. But if you have a lot of machines, probably some sort of vulnerability management software is the best way to go.

Mathew Wold: 7:45

And, like I said, how do you remediate unquoted service paths? You just need an administrator account, using a couple of computers, jumping into the registry as an admin, opening it up with administrative privileges and then just editing that service path by wrapping it in quotes. That's all it takes. It's pretty straightforward. If it's a piece of commercial software, my recommendation would be to reach out to that manufacturer and to, you know, let them know that there's a, there's an issue here with the uncluttered service path. Uh, so that way they can remediate it and, you know, release an update, um, or maybe even, uh, you know, patch it in some form or fashion, um, so that's, I think that's the easiest thing to do for that.

Mathew Wold: 8:36

And so you know, at this point I'm just going to do a quick demonstration, so we'll walk through the steps on how to do it, but just as a little guide, here's what we're going to do. So, on this machine, we're just going to check the privileges to see what kind of privileges this user has. We're going to check for the unquoted services. We're going to check the folder access to make sure that we can write to one of the folders in that path. Then we're going to build that payload and then we're going to exploit it. So pretty straightforward, and these are the tools that we're going to use. So the net user command is to check those privileges, wmic command to check if there's anything that's unquoted, this ICACLS command to see what folders we have write permissions to. And then we'll build the payload with PowerSploit and that is going to be the PowerUp module.

Kyle Rosendahl: 9:31

So essentially your virtual machine here that you've put together, it would be simulating just a workstation within a business with just a standard user account on it where we're working here, correct?

Mathew Wold: 9:46

It would yep. And so the other thing, that in this environment, windows Defender has been essentially shut down. Windows Defender has been essentially shut down, you know. So in a real environment you're going to have to get around Windows Defender or some sort of antivirus software, you know. I think the thing to remember is every environment is different, you know. So just because something works in one environment doesn't mean it's going to work exactly the same way in another. And you know the processes and how you move forward through that environment is, you know, going to be different.

Mathew Wold: 10:22

So you know, this is basically just, you know, a little proof of concept. You know, just to kind of show you, you know the basic how-to, I guess. Sure, cool. So here we just have this regular user account. This user account is called Elliot, and so I think what we do first is we just check to see what permissions Elliot has, and so you can see, just so I can remote into it. It has remote desktop and user, so there's no administrative functionality here at all. That's the goal is to get into the admin.

Kyle Rosendahl: 11:06

And so if you were let's say, not Elliot, you're Matthew and you compromised Elliot's account and you're sitting here on this box you could have done that through anything like a phishing campaign, or I mean, it wouldn't have to be Elliot doing this. This could be an attacker using Elliot's user account to run this exact same scenario in a real environment.

Mathew Wold: 11:29

Absolutely. Yeah. Yeah, that's a great point. However, I, as the attacker, you know, through phishing or some sort of other exploit, get access to the box. This is the jumping off point. Then Gotcha Cool.

Kyle Rosendahl: 11:43

So now we can. Continue.

Mathew Wold: 11:46

Okay, so now we see that Ellie is just a standard user and we're just going to look to see if there's any vulnerable services, and so we're going to use this WMIC service command. And so essentially, what we're going to do here is we're going to have WMIC service, which is a command line utility that's used to interface with the Windows management instrumentation. We're going to utilize this to basically dump out a name, a path name, display name and the start mode, which should be auto, right, because that's really what we're looking for. And then from there it gets piped into the fine string. So it's going to ignore case, it's just looking for anything, any services that are set to auto run, and then it's going to basically it's looking for anything that has spaces in the service name, in the service path. So that's what this part of the command is, and then from there, as long as it meets this requirement, then it's going to move on and it's going to push that into this next part of this find string, and so it's going to ignore case sensitivity again. And then it's looking for the slash fee is anything that's not wrapped in quotes. So looking for services that auto start, looking for services that contain spaces and then from there looking for anything that doesn't contain quotes. That's the breakdown of how that command works. So from there it finds this vulnerable service, which is called some vulnerable service. It's set to auto start and then this is where that service lives. This is what we're going to be after.

Mathew Wold: 13:47

Then, from here, we need to find somewhere in this directory structure we're going to need to have write permission so that way we can drop the malicious payload into there. So now what we're going to do is we're going to use the icacles command to search for that. So you could start from C colon up, you could start from C subfolder back down, it doesn't really matter. You're just going to check this structure, just to kind of as you go here. So then you know when we check using icackle. So just so, I guess we're all on the same page. Icackles is a command line utility that's used to modify ntms, ntfs, file system permissions, and so there's a lot of things that you can do with this, but for our need we just want to check the permissions. So that's all we're going to do here. But you could use it for other things if you, you know, had administrative privileges.

Kyle Rosendahl: 14:47

So yeah, I was just gonna say if you could just pause quick and then I mean just tell us kind of, what we're looking at here is to use the command here on the program files directory, the command here on the program files directory. You see there ntservice slash trusted installer, colon F right, colon CI, io. You know what exactly are we looking at here? I guess built-in users, because Elliot would be in that group. Can you explain kind of what the output is of this and what it is we're looking for here? And maybe you're getting to that?

Mathew Wold: 15:20

So you know these would be like the groups that we have. And then, well, here's the groups. And then you know we're looking for like built-in users right here. You know we're looking for anything that has a W in it for write permissions.

Kyle Rosendahl: 15:39

Okay, and right now? Right now they have like RX, what? What does that mean in this directory?

Mathew Wold: 15:45

Yeah, and so I believe that's read and executable. Okay, so we don't. Yeah, we don't have any. Any write permissions in here.

Kyle Rosendahl: 15:53

Gotcha, so they could look at a program here in program files. They could execute something from this file, but they couldn't rewrite a program that's sitting in this directory Right Got it, that's correct.

Mathew Wold: 16:06

Yep. And so here we know that we don't have any write permissions, so we're going to have to go to the next level, which is the a subfolder, you know. So we can just move to that one. And so here you know, as we saw before, elliot's part of built-in users, and this one does have the W, the write permission. So you know, Elliot can write anything that they want into this A subfolder folder, so they have right access into that. And then if we just, you know, we know that this is a spot that we can attack now, but if we just wanted to keep going down the line here, you know, we could check. You know, the B subfolder, and then you know, here's built-in users. So again, there's no write permissions here. So not vulnerable in this process. So it looks like the only one that we're going to be able to use is this ASUB folder.

Kyle Rosendahl: 17:05

And is it pretty common for, like, at the root program files you don't have write access. Then you do have write access and then you don't. Is that usually just a mistake in the person who wrote the program? Is that a mistake in somebody administering the system? I mean, because here obviously it's going to be an issue with with this service. Um, I guess, as you're talking about the remediation, is that that a common thing that happens, or is that just kind of a misconfiguration on one end or the other?

Mathew Wold: 17:42

Yeah, that would be a misconfiguration in when this, so I guess I'm just going to. I didn't really want to do it this way. I was off before and got turned back on, so I guess I'm just going to return it back off.

Kyle Rosendahl: 17:59

Simulating that the attacker somehow figured out a way to bypass the threat. Detection and prevention. Because, there's ways to do that. It's just that we're not going through all those additional steps here. We're just simulating that they found some sort of other exploit to turn this off on their own and then try to get up to local admin.

Mathew Wold: 18:22

Right, yeah, and I think things like the AMSI bypass. You know if you can use that to power shell into running enough that you can send it a command to turn off Defender. We've done that in a lab environment before and that's worked. It's a little cumbersome but it does work after a lot of trying.

Kyle Rosendahl: 18:46

Okay.

Mathew Wold: 18:47

So yeah, so there, now we're able to import this module, and from here, what we're going to do, do and I'll break down this command when I paste it in here so we're going to write this service binary from import mod, from this power up module, and so the name of it is going to be some vulnerable service, because that's the name. What we're going to do is we're going to feed, write service binary, the username of the account that we want to, you know, escalate into the administrators group, and so, you know, we put the name of the workstation and, you know, slash, you know our user here. So that way we feed it the whole thing, and then, you know, all we do is just let it do its thing, and so, you know, it'll kick out this executable. And so if we just jump right into this folder that I was in, so here's that service right here, and so now what you would do is you would, you know, just copy this, and then you'd bring this over into that folder that we have write access into, and so let's just go over here, and so here's where we would drop it. And so I already have this other one staged, just to make sure we didn't have any issues.

Mathew Wold: 20:23

But what we would do is now, because the b subfolder is in here, what we would do is we would just name this bexe, since that's what um windows is going to try to run, because it's you know, it's a b space subfolder. So it's going to first try to run b and then you know Bexe. And if that weren't here, it would just go to B subfolder, you know, and just keep moving on. But it's going to find Bexe here, and then it's just going to say I found Bexe, I'm done looking and I'm you, I'm just moving on to the next thing. So we have that. So then now, if we were the attacker, we would just reboot this system and then when Windows starts and it goes to run that service, it hits Bexe, loads that or launches that malicious code, and then we should get administrative privileges. So that's what I'm going to do now. Virtual machine does take a few minutes to reboot, so we'll have to find something else to discuss for the next couple of minutes here.

Kyle Rosendahl: 21:35

Yeah, so just to confirm that bexe that was already there in the folder that was created using the exact same command correct that you just ran. You just did it prior to this to just make sure that you had it there. Um, right, and then the powerupexe um or the powerup powershell module that you used, the ps1 that's going to, when it restarts, it's going to auto run this bexe program that you created and it's going to add the local user account that only had user permissions to the local administrators group here on this system. Is that right?

Mathew Wold: 22:15

yeah, so you know, before he only had access to remote desktop and just the users group. And yeah, when, when this reboots and it runs Bexe, it should take Elliot and elevate them into the administrators group. Gotcha Cool? Yeah, so that's the hope, and when we did this in the lab a bunch of times it worked flawlessly, so it should work great again.

Kyle Rosendahl: 22:45

Yeah, and so I mean, as we're still sitting here waiting for it to wake up as a blue team defender looking to detect whether this type of stuff is going on in your environment. Obviously the first thing you want to look for is, you know, with those tools you mentioned, do you have an unquoted service path vulnerability? Good, first thing to look for, or run those commands to search for your running services yourself. If you're looking for somebody who may have already executed it, or you're looking for you know past forensics evidence during an attack, what types of things in your SIM tool and your other locations should you be searching for to see, like, is this the way that they got local admin on my machine? Or you know what sort of alerts can you create based on commands that the attacker might be running?

Mathew Wold: 23:38

Yeah, you know, I think you know a good precursor, you precursor to the attack and getting alerting, probably looking for any time that the WMIC service get name is run, probably somebody maybe looking to exploit that. Maybe looking to exploit that. Yeah, definitely any sort of PowerShell commands, especially like the PowerSploit one, the writing, the service binary, that would be a good indicator. That I mean, that would be a fantastic indicator. Okay, cool, Okay, so we're back indicator. Right, you know so.

Kyle Rosendahl: 24:24

Okay, cool, Okay. So we're back in the system Fully already set.

Mathew Wold: 24:41

So now, now, when you look at it, see now Elliot has is in the administrators group and so you know now, at this point, elliot's an administrator. So you know, if we go look at that as well, I mean there he is, or they are along with everybody else. So you know, now Elliot's free to. You know, install software, maybe pivot into other machines, try to remote desktop into something else. You know the sky is really the limit for the Elliot account here.

Kyle Rosendahl: 25:21

Cool yeah for the Elliot account here, cool yeah. So theoretically in that Bexe they could put whatever software they want whether they wanted it to be ransomware or malware or something like this to get them into the local admin. But by kind of elevating permissions like this, now he has full opportunity to install additional things, move laterally, even modify group memberships, modify file permissions, things like that. Now he's kind of got keys to the kingdom here on at least this system and can hopefully use that to bounce higher. Is that technically typically kind of the goal with doing that with a local admin? Yeah, awesome, yeah. No, that's great demonstration, really informative, really good to see it just function all the way through, even though we had one little hiccup with, uh, with, windows defender. Yeah, um, but that thing's always getting in the way no matter where you're working, so cool. Did you have anything else on the slideshow that you want to go back to before we kind of open it up to the rest for questions?

Mathew Wold: 26:27

Yeah, just so, here we are, congrats, we're system administrators now on this, on the system, and so you know, I think that really goes into the next part, which is, you know that Palo Alto Cortex XDR service path that was found. We want to just talk about that for a few moments. But one of the really interesting things is it was originally discovered by the Rapid7 Inside VM tool. Like I said before once, I saw that I was just kind of shocked that. You know, I was actually seeing. You know something from Palo Alto. You know that was unquoted. You know, obviously a huge oversight on their part. But you know, immediately, you know, we took it into, you know, a virtual environment and tried to figure out, you know, if it was a problem in our environment or if it was a problem with that installer. So we installed it into a virtual machine that wasn't even on our network and, sure enough, the same thing happened it was installed as unquoted and so from there we tried to exploit that further and we had a little bit of trouble with it.

Mathew Wold: 27:48

I think one of the big things is Defender. Again, defender kicked in as soon as Palo wasn't running and that caused a little bit of an issue. But one of the interesting things was that when you try to exploit this service path, and so you know for us we drop stuff into you know the program files directory. And so we just named our malicious code programexe, and we also made our payload from Metasploit's MSF Venom. And that had a really unique effect on exploiting the vulnerability. Because what we found is if we just dropped a text file called programexe without any code inside of it, when the computer booted it freaked out and it just didn't know what to do. So of course it stopped loading the service, the size serverexe, and so we were able to work in the system as if Cortex wasn't running at all. But we weren't able to uninstall Cortex or do do anything else. We're just able to work as if the cortex wasn't even there.

Mathew Wold: 29:10

And then when we added the, the metasploit msf venom executable windows defender actually just, you know, did what it was supposed to do and just completely ate that malicious code. But along with it, because the Palo Alto software had tried to load that MSF Venom application Defender, ate the Palo Alto piece of the software as well. And that piece of software that it completely ate was the administrative application that prevents tampering. So the anti-tampering part of the Cortex XDR once, once defender ate that, then you could just go into um programs, and you know programs, and you could just completely delete, uh, cortex xdr altogether. And so you know, at that point you know, we could have continued to try to um, you know, get around defender, and put some other payloads in there or try to um elevate the permissions, but at that point we had seen enough. You know, that was a pretty big deal. So, right, you know, that's when we sent it over to palo alto gotcha okay.

Kyle Rosendahl: 30:35

So in exploiting what we just did on the Palo Alto software, it essentially failed to start, which then kicked off Defender turning on because normally it would be disabled with the other XDR in place and then Defender deletes what it sees as a malicious program trying to interrupt the Palo Alto service. But then in doing that Palo Alto never gets to start because it tried to start and then you're left with a broken Palo Alto piece of software on the workstation and then all you'd have to do is bypass Defender and take another action to kind of escalate privileges and then you're running without any endpoint protection. Is that a good summary of what you just described?

Mathew Wold: 31:22

Yeah, that's a great summary. Yeah, okay, I mean we could just break it with a text file and it was just crazy to see that it was that easy, just to break it.

Eric Brown: 31:51

That's awesome Want security leadership without the headcount. As an extension of the team, it Audit Labs will provide the experts to guide and counsel your company. We will start by creating a custom security program that caters to your industry while providing transparency and remediation to improve cyber posture while reducing risk. Contact IT Autolabs to find out more. Contact IT Autolabs to find out more. So you found this and then did you report it to Palo Alto.

Mathew Wold: 32:44

Yeah. So once I found it myself and another security engineer dug into it and just wanted to make sure that we were seeing what we were actually thinking we were seeing before we went and cried wolf or something. And then, once we realized that we could break in, completely, remove Cortex from the system, yeah, we wrote up the proof of concept and sent it over to Palo Alto. Cool, is it fixed? Now it is. Yep. They sent out an updated version of Cortex I think it's 7.7.1, and it does remediate that and, yeah, it works great.

Eric Brown: 33:20

So was it present in all of the versions before 7.71, or did it just somehow get missed in an update?

Mathew Wold: 33:31

Yeah, so that's a great question. We did go back and we loaded a previous version of Cortex-XDR and that one was quoted, so somewhere in 7.70, it just got missed. You know, just a configuration oversight, and yeah, so anybody who was using 770 for a while there all had unquote service paths.

Kyle Rosendahl: 34:10

Cool and Kyle, I know as part of your work you look for vulnerabilities in people's environments. Is this one of the things that you look for Typically? This is kind of one of those low-hanging fruits that shows up in Windows systems. Just based on the way that Windows interprets strings right, especially path strings, it can be good. In a lot of I know, ctfs it's a pretty common thing to throw in there because it's a pretty standard type exploit that you'll run. I think companies are getting smarter with it.

Kyle Rosendahl: 34:41

But I think to Wold's point. All it takes is somebody to forget to put in a couple quotation marks when they're programming the package and it can get out there and it still plagues the world. I mean, the only way to really fix it would be to edit the way that Windows reads a string literal and what it interprets as a delimiter between strings, because it sees that space as that. I don't see that happening anytime soon. So either making your entire path have zero spaces in it and just ignore it altogether, or just make sure you're always quoting things in Windows strings is about the only way that you can 100% guarantee that you're going to fix it.

Eric Brown: 35:24

Thank you for listening to the Audit by IT Audit Labs.