 Let's welcome Christopher on and he is a first-time speaker, so everybody knows what that means Good evening everyone So I'm here to talk about a CCM a couple of passwords that it stores How to get them from different attack of perspectives and a little bit of my story and figuring out how this all works So I started my career in cyber security around eight years ago as a penetration tester with an interest in Internal infrastructure testing quickly pivoted to doing some red teaming as well And part of that skill set was needing to develop the ability to attack 80 and After doing a couple of assessments in that line. I realized that Oftentimes 80 security isn't necessarily controlled by 80 itself It's controlled by the configuration of large-scale enterprise solutions like SCCM so My story with SCCM started in a client engagement where a client had configured it to use network boot So for the uninitiated like I was at the time This is what that looks like if we connected to the same network as a SCCM server that's Set up for network boot. We can prompt to do a network boot It'll get an IP address figure out where the network boot server is and then start downloading an OS image That it's going to boot into After it's done downloading that OS image it proceeds to boot it and At the end of this boot process We end up in something called a Windows pre-installation environment. So WinPE It's a stripped-down version of Windows that has like the bare minimum libraries No Explorer and it can run things like a configuration manager client like this one At the end of it's set up. We get prompted with this password screen So if we look at the screen, it's asking us for some random password on that client engagement that I was on The only thing the client gave me was the password for the screen So put in the password click through a couple of dialogue boxes and I ended up with a VM There was domain joined that had all of the clients security software and software installed This kind of blew my mind at the time because I knew that if I'm ending up with a domain joined machine Then there has to be some domain crades somewhere that are doing the domain joining So I chatted to the client. We figured that let's go searching for the crades. See what the crades are and That's where the journey began So one of the first things that we discovered is in a lot of these Windows PE environments if you press F8 It will pop a system shell now That's more or less useful depending on which part of the deployment process you're in But it gives you the ability to interact with the environment and run tools One of the interesting things that you can do once you have this command show though is you can dump out the environment variables So after you start an operating system install You can write a vb script file that dumps out the environment variables and one of the really interesting ones is underscore sms ts reserved one and reserved two Those are the network access account crades that the Windows PE environment uses to talk to the SCCM server and download the software that it's going to install So this is stuff like the operating system image and the individual software packages they need to get installed This however is not the set of crades that are used to domain join the machine. So we carried on our search and Eventually after interrupting and install midway and mounting it in a different VM Figured out that in If you look at the unattended dot XML file after you've started an operating system deployment in the C Windows Panther unattended folder You actually find the domain joining crades that this machine is going to use to domain Yeah, to join to the domain That was really interesting in this specific client's estate because it ended up being that these Credentials had workstation administrative access to the to all the workstations and laptops Across their entire 80 environment, which was a big deal for them. They had spent a lot of effort trying to harden their 80 Over the years we've seen this kind of story repeated So I've pulled the network access account on certain clients and in one estate It ended up having SCC Administer of access to the SCCM servers itself And then we could do some lateral movement and credential credential theft to get domain administrative access in other states It's actually configured as domain admin out of the box. So Kind of the TLDR of this is there was sufficient evidence to figure out that these kinds of credentials that are exposed to the pixie boot environment a Lot of times have quite privileged access over the active directory environment that they're in So they're kind of like a worthwhile target going for and it's worth understanding how to pull those credentials consistently So that was my target. I knew what I wanted to go after and It is The specific thing that we're looking at here is Microsoft endpoint configuration manager or SCCM or system center configuration manager or config manager in this talk You're gonna hear me use all of those terms. They refer to the exact same product. It's it's basically a Software management product developed by Microsoft that is used to deploy update Manage and manage software on workstations and servers across an estate It's used to patch all kinds of machines from the most critical domain controllers and exchange servers to every single employee workstation and laptop So probably the most important thing that we need to know going into this is What kind of credentials are we targeting? We've already talked about two kinds of the network access credentials and the domain joining credentials But I've actually found three locations Where credentials can be configured where those credentials will be pushed down to configuration manager clients So the first is the network access account Again, this is used primarily by Windows PE because it's not domain joined So it needs some sets of credentials to talk to SCCM to download software There's a lot of recent research that's come out on how to pull those credentials And I'm going to in this talk add kind of the operating system deployment and pixie deployment method of pulling these credentials to the to the current view in order to properly understand the second place that credentials can be configured We need to understand how task sequences work In SCCM. So task sequences are ultimately a set of instructions that allows us to take a blank machine and apply certain steps to it in order to make a Domain join machine that has a bunch of software installed So inside a network boot environment the task sequence selection screen is effectively the what what is shown in the screenshot here and Practically speaking in real-life environments each of the different types of machines that you want to build will end up having a Unassociated task sequence that those task sequences are made up of task sequence steps That define the order in which you need to do operations in order to get a working machine out one of the steps is To domain join the machine This is actually called apply network settings and there's a nice convenient box Inside the configuration manager console where you can set these credentials There's also additional places where these credentials can be configured So I'm just going to run through them really really quickly So one of the features that SCCM Supports is the ability to make a new reference image That reference image needs to be written to some kind of network share in order to save it and In order to write to a network share. You obviously need credentials. So it allows space for those credentials to be configured The second place where you can configure credentials is that when you build a machine You can obviously set the local admin password of the machine. This happens before any software is installed So laps would take precedence of the over over this since it would happen after the machine is built You can run arbitrary commands as any domain user But then you have to provide the credentials for that domain user and lastly you can connect to an arbitrary Network folder in order to pull files down if that's part of you building a new machine and As part of that you need to provide the credentials that you're going to use to connect to that network folder and Lastly In order to understand the third place that I found credentials you need to understand how collections work in configuration manager so Collections are a concept where we want to apply certain settings to an entire group of machines rather than to machines Individually so what we can do is we can create a collection of those machines Add all the machines that we want to apply these settings to to that given collection and then apply things like task sequences To the collection now collections have an interesting feature called collection variables these are effectively environment variables where you can specify a Name and a value for that collection variable and these get pushed to all of the machines that are in a given collection Now there's nothing specifically requiring these career these collection variables to store passwords But interestingly enough SCCM treats it as if it's sensitive, so it still encrypts it It's possible to use these for credentials if they are a if they exist and they're configured it's worth pulling them down to see if there is anything sensitive in them and The last thing before we dig into how things Work and how pixie boot a how pixie boot in configuration manager works is some terminology So as we have discussed something like a task sequence needs to pull down software from a server In order to apply it to this machine that you want to build that software whether it's an operating system image whether it's an MSI whether it's an exe installer is what is known as content Content is downloaded from a specific server role in SCCM called distribution points a Configuration manager client like the one that we saw running inside the windows PE environment has to authenticate to the distribution point in order to prove that it has the Authorization I guess to access the content that it's trying to access similarly in terms of Other things that a client needs to do it might have a bunch of configuration settings that it Uses to control which software packages it decides to download and Those configuration settings are what's known as a policy So policies are not downloaded from distribution points. They're downloaded from a different SCCM server all called a management point again The configuration manager client needs to authenticate to the management point to prove that it is authorized to ask for the policies that apply to it All right, now that we've covered all of that How does network booting actually work in configuration manager? so One bit of context that's kind of useful to understand is that network booting and configuration manager is actually part of a broader Set of functionality the configuration manager supports called operating system deployment operating system deployment mostly is made up of a task sequence that is aimed at deploying a new OS to a machine and The policy settings that are needed in order to make sure that that task sequence applies successfully There's multiple ways to kick this off The video that we saw in the beginning was using network boot in order to kick off operating system deployment But you can actually make ISO files or WIM files or a USB drive That has an s3 files on that you can boot off of in order to start a new operating system deployment What's important to note about this is regardless of what method you use to start your operating system deployment All of them boot into a Windows PE environment run a configuration manager client and then start to talk to SCCM to figure out what to do Okay, so how does network booting work? Well first, let's say we have a blank machine that doesn't have an OS on it We plug it into the network and the first thing that we're going to do is we're going to press the key that makes the machine Ask for a network boot. It's going to do a DHCP request to figure out its IP address and to figure out where the network boot Server is it's then going to after it identifies where that network boot server is It's going to make it a specific DHCP request to that DHCP server To tell it hey, I'm a pixie client. I want to figure out what's going on Please tell me what I need to download in order to boot successfully and then after it gets that information from In this case a distribution point distribution points are responsible for running pixie as well After gets an information from a distribution point It will then use TFTP in order to download the files and kick off the operating system deployment method So once we get all of that done We'll boot into an environment. It will run a configuration manager client and the configuration manager client will ask for some kind of password Okay, so what's this password for it's not a username and a password. It's just a password So what is being protected with this password? Well if we investigate what's going on on the SCCM server when it receives that Specific DHCP request from the client. It turns out that there's a specific folder Reminstall SMS temp and inside that folder specific files are being generated. So we see two files at Dot file and a dot BCD file the BCD file is your standard boot configuration file that Tells the pixie client how to boot the image that it received But the file file is actually quite interesting This is what is known as a media variables file and it actually Contains all of the configuration information I guess that the client is going to be configured with so that it can authenticate later on to SCCM turns out the password is being used to derive a key that is used to encrypt this file We can confirm that that's kind of what's going on because using our nice command show that we have Inside the WinPE environment we can start to analyze the files that are included So WinPE is Windows running inside a RAM disk. It actually uses the X drive by default or at least SCCM WinPE does and Inside there inside that that specific drive. There is a Configuration manager specific folder called SMS that contains all of the binaries and Configuration data that this WinPE environment needs in order to successfully boot and continue the operating system deployment method Inside one of the bin folders There's a config file called TS boot shell that I and I and that defines the first command That's run inside WinPE. So we see that there's a reference to something called TSM bootstrap and this is The what the configuration manager client is inside a WinPE environment So that screen that we see that's asking for a password is the executable TSM bootstrap.exe And we can see that it's called with reference to a different configuration directory X SMS data inside that folder. There's a file called variables.dat which Suspiciously looks the same as that .var file that we saw earlier and It turns out that this executable does all that DHCP stuff pulls the .var file over TFTP and renames it variables.dat. So the password we type in the screen is then used to try and decrypt variables.dat Alright, so we know how it works at a high level. How do we turn this into an actual attack? Well, the first thing is we know that The password is used to Try and decrypt this media variables file So we need to get our hands on this file because we need to use the contents of that file For any kind of attack that we want to perform I've written a Set of Python tooling called pixie thief that I'm planning on releasing sometime this weekend That implements all of these DHCP requests that are needed in order to first find where a pixie server is and then prompt the configuration manager server in order to Generate this media variables file and find the location of it so that we can download it over TFTP It looks like this So if I run this video, yes, that worked properly We can see that there's there's kind of like two main steps here We issue a DHCP discover request to find the location of an SCCM server specifically a distribution point and then once we figure out where the distribution point is we issue a Specific request to that server in order to generate the media variables file and find out where it is stored on disk How does this work? Okay, first thing we need to start off with is with that DHCP discover This is a very general thing, but a if you try and Prompt for a network boot what is effectively happening is you're issuing a DHCP discover request with the HCP options 66 and 67 so you're asking for those options if that environment is set up to support pixie boot The main DHCP server will point you at the pixie boot server in DHCP option 66 in the response Once you have the location of that folder you can then talk to a port on that folder that sets aside specifically for pexi Support four thousand and eleven So we generate another DHCP request, but this time it's a request packet not a discover packet and we provide the options 93 250 and 60 inside our own request that identifies us as a client that is attempting to do a pixie boot The only really weird option there is DHCP option 250. It's a random binary string Looking up the documentation. This is like a Microsoft specific thing where they identify the architecture of the machine That's asking for the network boot. I Haven't actually run into any issues the very first DHCP request packet that I captured has worked on every single SCCM server that supports pixie boot that I've run into But yes, if theoretically it only supports x64 or x86 The string would need to the string would be set to different values in order to match the architecture of the machine That's asking for network boot Right, so if we provide Correct information and SCCM likes it then inside the response we get a DHCP option 243 which is another random binary string or hex string Now this hex string is kind of special because there is a field a portion of it that is Demarcated it starts off with a hex byte zero one and then a length identifier and then following that is the actual Location of the media variables file on the TFTP. So if the DHCP server likes If the SCCM server likes our DHCP request It'll actually tell us where the media variables file is in this portion of DHCP option 243 Right, so that allows us to use any TFTP client to download it because we know where it is and Then we can move on to the next step now The important thing is we can't really use a password as it is in order to attempt to decrypt the file There has to be some kind of key derivation that's going on so in addition to writing Python tooling to prompt the SCCM server into giving us the media variables file I've also just written a custom hash cat module that implements the key derivation so that we can perform a password guessing attack against it I decided to use Hash cat because I like GPU support and hash cat seemed pretty Far along in that space. So I went with it It looks like this. So first obviously we need to start off with getting the data into hash cat So my Python tooling can extract the portion of the media variables file. That's kind of the header so we can confirm that the Encryption is what we expect because we can check certain bytes in the header to make sure that it matches what we're what we're looking for And then the last portion of this String is effectively some of the encrypted data to jump a little bit forward The media variables file is effectively just an XML document So we actually know the Beginning of the string. It's always going to be constant So because we have known plain text when we developing a hash cat module we can work We can treat it as a hash because we can take our key that we derive Encrypted and then compare that encrypted value to the known The known value here and if that matches it means that the key that was derived was from the same password So we figure out the password Okay, so we have this data and we need to feed it into a hash cat. So I just write it to a file and Then I start running hash cat I'm gonna skip ahead because like it takes a while to initialize But when it actually starts running the attack What I've done here is I've run my hash cat module using rock you it doesn't really matter the the module supports all kinds of Cracking options you can crack with the rules you can crack with Dictionaries you can do a brute force attack all of that kind of works Sorry, I didn't want to do that. Let me skip forward again tab Just struggling with PowerPoint media Okay, so Yes, we can run through rock you dot txt with the known password at the end of the file it cracked successfully If we do a benchmark of the same hash cat module, we can see that this is running at about three giga hashes a second It's not the fastest thing in the world. It's definitely not cracking at the rate of an NT hash It's not md4, but it is still pretty fast. It's about 50 percent faster than Cracking an NT LM challenge or NT LM V2 challenge response So if it's a weak password, it's probably gonna fall and you can actually crack using Dictionaries pretty fast How did I figure out how all of this works? Well, there's one thing to note Which is SCCM is probably one of the most logged pieces of software in the world So both on the server side and on the client side Everything that each of those pieces of software is doing is being logged if we dig around the when PE environment Inside see windows temp SMS tears log We find a text file that contains the log of what the client is trying to do Looking through that at some point. There's a entry called Loading media variables from X SMS data variables dot that which is exactly what we're looking for We know that it's trying to decrypt that and exactly after that it logs are called to crypt decrypt So crypt decrypt is a function in the windows crypto API that is Used in order to Yeah, attempt to decrypt the file. So we know that it's using Windows crypto It's using crypto API in order to attempt to decrypt this file Now because we have this shell we can actually inject custom software inside the when PE environment So I used x64 debug loaded it on a random CD The CD drive is accessible within the when PE environment So we can actually run x64 debug and since we know that we're running TSM bootstrap dot exe We debug TSM bootstrap dot exe and we can search for all inter modular calls Here highlighted in red is effectively a series of inter modular calls where it seems to be Setting up and initializing the crypto functions then calling them deriving a key and destroying what it's initialized So that looks like roughly what we're looking for So how does it work? Well, if we actually debug these individual calls to try and identify what's going on one thing that will notice Is that when crypt create hash is called the second function the second parameter that is passed to it Is the hex value 8004 if we look at the function definition of Crypt create hash in the Windows documentation the second argument is an algorithm identifier and 8004 corresponds to a shaw one hash so We're creating a shaw one hash of The actual password that we're passing in so the argument to crypt create hash is the password that we typed into that box In this case. I typed a so we see a as the there's a pointer to a string value So we're hashing a with shaw one and then we're calling crypt derive key using that hash The second argument to crypt derive key here is 6 6 0 e the Windows API functions are actually pretty consistent. So it turns out that Crypt derive key the second argument is also an algorithm identifier and if we go look up that algorithm identifier It is a it is telling us that we're deriving a key for an a s 128 Encryption encrypted value okay, so We have an idea of what's what it's doing, but we don't really know what crypt arrive key does in order to get its key Turns out if you just scroll down in the documentation Microsoft was kind enough to actually document exactly how the key derivation works So We take our shaw one hash do a bunch of stuff to it, and then we get an a s 128 key out What the hash cat module involved doing was re-implementing this in open cl Hash cat is great. It has some really nice standard Cryptographic functions built into the libraries that it provides so we can actually use all of those standard Libraries in order to perform the same actions that are documented here And then at the end we'll get a key that again we can encrypt a known value Compare that to the data that we provided in and if it matches then we know that we've guessed the password If we've guessed the password, we've guessed the key which means that we can decrypt Our variables dot that file that we were going for in them Yeah, that we were going for so which are the important variables that we want to pull out of this well They're highlighted in red the most important is Not the one that's highlighted there. It's SMS TTS media pfx, which is a public private key pair that is Effectively the certificate that the client uses to authenticate itself to the management point in order to pull down policies That pfx as most pfx's are is password protected There is a value called SMS media good. Let me actually just highlight this laser pointer Okay, I think you can see that yeah, so SMS media good, which is a string value That is used to encrypt this pfx So the first 31 characters of the media good is used to encrypt the pfx and then lastly There is a value called SMS TSM P that points at the media Sorry the management point that we need to talk to in order to pull down the policies So we have at this point all of the information that we need to actually successfully start communication with SCCM because we have the Certificate we have the server we need to talk to and we have the password for the certificate Okay So how does client comes work? well Let's go back to Our password screen that we started off with One good way to figure out what's going on here is to actually start using Wireshark to monitor the HTTP traffic that's passed between our configuration manager client and the server So we type in the known password what we see then is this HTTP request This is a CCM post to CCM system request With a request assignments XML message this request assignments XML message is Effectively the client asking for hey, I'm a configuration manager client. Please tell me what policies I need to install This request is actually authenticated by a bunch of signatures. We see client token signature We see CCM client ID signature and we see CCM client timestamp signature all of these if they are provided are kind of verified by the SCCM server to make sure that they check out Okay, so assuming that all works We will receive from the SS SCCM server a reply assignments XML document And that contains a bunch of policies with some URLs that point to where we can download the policies that our configuration manager That our SCCM client should apply Now we already discussed this there's actually three policies that we're specifically interested in because we know that they result in passwords ending up in our client task sequences Network access again config and collection settings so we can filter our reply assignments XML document to kind of figure out These are the sensitive policies that we're interested in let's go download those and if we actually download one of them We again need to authenticate. There's some signatures here, but the data that we received back is an encrypted blob That is used in all that is encrypted using the certificate that we already have Okay, so we have a high-level picture of how it works. How can we use it to pull out passwords? Well like this So Because we have our media variables file We can take our media variables file take the password that we cracked and provide it to Pixie thief It's able to then issue requests to the well generate the signatures that we need to authenticate issue Requests to SCCM to pull first the assignments that it needs to apply and then the policies The specific policies that we're interested in and then after it receives those policies Sorry, let me just skip forward It is then able to take those policies and decrypt them in order to get the clear text passwords that are stored within those policies Okay, so the key bit to understand here is how does the signature work because that's really the thing that's stopping us from doing this Just out of hand Turns out that if we go using x64 debug if we go on an active debugging spree We can see that crypt sign hash from crypto API is used to generate these hashes These signatures so we have some kind of known value like for example, let's take CCM client ID It's provided to us in the media variables. We take that value We sign it using the pfx value We provide both of them to the SCCM server and because it also has a copy of the certificate It can verify that the signature is legitimate Okay, so that's how we authenticate now. How do we decrypt these encrypted policies? well again if we go on an active debugging spree we figure out that The Yeah, that binary blob is encrypted using crypt encrypt message which we can decrypt with crypt decrypt message using the certificate That leaves us with a plain text Policy xml that will be dependent on the specific Policies that we're looking at most of these will just be clear text at this point But if they can contain passwords SCCM isn't done with the encryption yet So in this case I've highlighted the value here TS underscore sequence It's marked as secret and that means that they've implemented some kind of obfuscation to make sure that we can't just read it outright It starts off with the hex value eight nine one three zero zero zero zero which will be relevant later on Which is why I'm telling you now But effectively again if we go in this active debugging spree we'll figure out that This string is actually just triple there's encrypted with a key that's inside that hex string So we can pull the key decrypt the value and get the clear text task sequence Once we have the clear test task sequence things start to make a lot more sense If we look in the configuration manager console There's a bunch of steps in each task sequence for the steps that can contain passwords We actually just get the straight clear text passwords here So in this case I've highlighted the domain joining credentials that are associated with the apply network settings task sequence step Okay Now the interesting thing is that I've discussed how to do this when a password is required But you don't necessarily need a password So if we look at the specific place in SCCM in the SCCM console where you set up Pixie you can untick the box that says require password. So when you boot into it the The configuration manager client just tells you this media is not password protected click next How does that work? Well, if you encounter an environment that has this setup We can actually just go from the first step all the way to decrypting variables because there's no password to protect it. We can pull We can pull the key. I'll explain how and then we can just immediately decrypted and get clear text creds out now the Secret here is essentially in that response to the specific DRCP message that we send to the SCCM server I already said there's a portion that starts with zero one that points us at our encrypted media variable file the mere the media variable Media variable file is still encrypted in the case where we don't require a password But the key is actually sent as part of the ATP option 243 in a portion that starts with zero two so zero two a length field And then we have an encrypted key now SCCM at least encrypts it because it realizes this is being sent over the network So we don't want to expose the media variables file straight off the bat But we can't really do much to prevent this from being Decrypted because the client still needs at some point to access it and there's no real secret involved here So it turns out that there's another layer of Obfuscation and going on an active debugging spree. We can find a function called extract password inside TS pixie dot DLL Inside that function. There is a call to decrypt buffer that references a hard-coded key Inside the the same file and then refers to this DHCP option Portion that we just discussed so it turns out that this is Encrypted using the hard-coded key there So what we do is we take the DHCP option turn 43 pause out that second option Decrypted using the hard-coded key and then we have a random key that is used to encrypt our media variables file But because it's being sent in that DHCP response This is easy to do straight off the bat once you know what's happening Okay, so now we've run through everything that can happen with network booting But if you remember in the beginning OSD isn't just network booting It does include media files that we can use in order to initiate operating system deployment. How does that work? so Inside the configuration manager console you can take a task sequence and generate a Media file that is used to initiate this OSD method There's three main types Stand-alone media bootable media and pre-stage media Pre-stage media is a file that we can ship off to a laptop manufacturer so that when The laptop comes up it will attempt to contact our specific SCCM server and complete the installation Bootable media is effectively an ISO file or a USB that will just boot into a WinPE environment and start a client like we've seen already and Stand-alone media is probably the most interesting one where it is designed to not use network communications at all But still complete an operating system deployment so it needs to package all of the software and all of the Policy settings on to that ISO file in order to be able to do it completely offline If we look at the contents of these files, so I went and I generated one of each If we look at it, we actually see a lot of similarities with our RAM disk. That's sitting inside WinPE so There is an SMS folder inside that SMS folder There's a data folder and for both the bootable media and the pre-staged media There is just a variables dot that file and then a configuration file our TSM bootstrap.ini. That's just Telling us how to run the client in the first place If we look at the standalone media, there is also an additional file called policy.xml That contains all of the policies that this media needs to apply in order to successfully deploy the laptop Okay, so how do we do how do we turn this into creds? So I'm going to talk about Standalone media primarily because that's the interesting one that has the new file it turns out that both bootable media and pre-staged media have a certificate inside their variables dot that file and We can use that certificate to perform the exact same attack as we would once we Obtained that certificate from a pixie perspective Okay, so in the case of a stand alone fire standalone media farm we can take if we know the password again We can perform cracking if we need to because the variables dot that file for media file is generated in the exact same way As it would be for pixie farm we can generate Once we know the password we can provide the password to pixie thief it can derive the key and decrypt both the policy and variables dot that files and Then we're because all of the policies are sitting inside that policy xml file It works exactly the same as if we were operating in a pixie environment Again with our media files We can also choose to not set a password if we don't set a password. There's just a static string So we can take the static string derive a key from it Use that to decrypt the policy and the media variables file and then we are off to the races. We can decrypt our Policies now the important thing to note actually for standalone media is unlike the When a password is set. There's a different key that is used for the policy dot xml and for the variables dot that We use our password to all we always use the password to decrypt variables dot that But inside in the case of a standalone media that doesn't have a password We take the sms media good from that variables dot that file and use that to derive a new key that's used to Encrypt the policy farm Okay, so at a high level Breedable media pre-stage media we get a certificate. We use the certificate pull policies Get crates if we are on a standalone media. We have to decrypt that policy dot xml file somehow How do we turn this into a realistic attack? Well, if we're sitting in an environment where we can do a pixie boot What we need to do is we need to prompt for pixie boot find out where the SCCM Server is get our hands on that media variables file and once we have the media variables file crack the password if there is a password or use the The key that was sent to us to decrypt it if we crack the password We can then use the certificate and get all the credits if we have low-privileged domain credentials We have a number of other options available to us. We can actually I Showed you the folder remain stalled SMS temp that in general is actually a share on the SCCM Server that all domain users can read So even if you're not in the position to prompt the SCCM server for a pixie boot You can use credentials to go look at the contents of SMS temp And if there's a variables file in there you can download that file and attempt to crack it In on the other side of things obviously these media files are files that are lying around somewhere on the network If we can find those files we can attempt to again crack if there's a password set if there isn't a password set We just use the default string and cool We have the certificate or we have the Decrypted policy that gives us the credentials that we want Okay, is there any post exploitation potential with us turns out that there is If we have administrative access over the SMS SMS server the SCCM server we can actually ask for specific registry keys And the certificate that we're looking for is actually just stored as a registry key that we can access remotely So we can pull the identity GUID which again is used to encrypt the certificate We can pull the the certificate bytes try and import it use this the password to decrypt it and cool We have the set that we need in order to persistently be able to Do this going into the future now the reason this is useful for Post exploitation is because it's actually a really nice persistence technique if credentials are stored within task sequences The network access account collection variables You can reset all of the passwords across the entire active directory domain if you're updating the passwords in SCCM to make sure that it's still Functional the certificate will work to get those credentials after the fact Another thing that's kind of interesting is that if we look at the SMS DP identity Key and the the value reserved one I mentioned earlier at Anything that starts with eight nine one three zero zero zero zero is probably just using obfuscation So it turns out that the actual pixie password is also stored Inside this registry value So we can just feed it through the same de obfuscation function Get the clear text password and again nice persistence technique because even if you're recovering the domain You're probably not resetting the pixie password, so you can use this to perform the exact same attack And lastly Can we get credentials on endpoints? How does this work? Okay, so The really well-known method is to pull the network access account the network access account and most SCCM Configuration options are stored inside the WMRC database on a given host So if we ask for the CCM network access account class We can see the network access account password and the next network access account username These are marked as policy secrets And if we look at the actual data that is being protected It's actually protected just using DP API. There's a lot of tools now that can decrypt us Benjamin Dalpy actually released ages ago like about a year over a year ago He built this functionality into Mimicat so that it can decrypt that specific DP API blob recent research from spectops Subatomic has built SCCM decryption of that that specific information into sharp DP API and I'd say one of the most interesting pieces of recent research is by Adam Chester Where he's looked at how to register an arbitrary certificate for a new domain joined machine Into SCCM so that we're able to perform those HTTP requests in order to pull policies So all of these is targeted towards getting the network access account But if you remember I said there's three places that we can pull creds So it turns out the collection variables can also be pushed to endpoints So if we query instead of CCM network access account if we query CCM collection variable We can pull the collection variables. These are also marked as policy secrets. So we can decrypt it using DP API as well and Task sequences might be pushed to endpoints. So if we query CCM underscore task sequence There's a value called TS underscore sequence. That is also a Policy secret and is also encrypted using DP API. Okay, so Let's tie everything together. We've talked about a whole bunch of ways to pull out credentials What are the issues? Well The very first issue is the fact that Credit the accounts configured in SCCM might be overly permissioned So right in the beginning I discussed how the network access account can be domain admin Or it can have administrative access over the SCCM server. At the end of the day This is just an account that is used to download software off the SCCM server It doesn't need privileges. It needs the ability to log on to an HTTP endpoint It should only have those privileges. Never mind the fact that you don't even need a network access account anymore And that applies to every place where you can configure credentials in configuration manager the Microsoft Documentation on how to configure these accounts is really good. I've put the link to the page that discusses this in detail here Read it. It's really good at informing you how to configure these accounts so that it doesn't contribute towards a privilege escalation vector Another issue is that we often have entire teams that are dedicated to setting up SCCM So because they're responsible for setting up all of the accounts that SCCM uses They might set the same password So we might use different accounts that are even Appropriately permissioned, but if we're taking our administrative account for SCCM and setting the same password as the network access Account that is exposed in this way. We can just attempt to use that password to Gain access to the admin account and if they were set the same cool. We have access to the admin Lastly We often see that an account configured in SCCM is used for multiple purposes So it is pretty well-defined. You can set a domain joining credential a network access account a Set of credentials that's used to connect to a network folder all of these are really well-defined and The problem comes in when we decide we don't actually want to use different accounts for this So we'll create one account that fulfills all these roles What you're really doing there is you adding additional permissions to accounts that don't need them and If you compromise that you compromise all of the roles that that account is being used for not a great idea Okay key takeaways Configuration manager super powerful. There's a reason it's used so widely I think patch management on Windows Estates is actually pretty painful without using this So it's gonna stick around for a while as long as on site AD is still a thing Configuration manager is probably gonna be a thing We've seen here that operating system deployment is viable for attacking corporate networks So if we guess the password We can get the certificate we can pull the policies if the accounts are badly configured We're going to get sensitive credentials and that's going to allow us to privilege escalate in the environment It's a really really really good idea to set a password and to set a strong password and to make sure that you're following Good password practices something like using an enterprise password manager here Where the creds are rotated every now and then and everybody that needs access to these media passwords can actually access those Passwords is probably a good idea If this password is guessed obviously that certificate is compromised and these certificates generally at least have a lifetime of around two years And it's very probably the most important thing is we should make sure that the Specific accounts that are being pushed to endpoints do not have elevated privileges associated to them None of the accounts that we've spoken about that you can get access to need admin access to anything. They don't Do not put them inside these policies because they are exposed not just to pixie Clients but also to every client if you configure task sequences for example on Windows endpoints If you want some more information, I've written up a lot of the stuff around the HTTP communications at my company's website MWR cyber sec Go have a read at my blog post Again, the tool is Going to be released on my company's github. I'm not there yet planning to release it this weekend If you want to know exactly when it comes out feel free to follow me on Twitter or follow my company and That's it. I'm done