SCCM Management Point and Distribution Point relay attacks implementation #1832
+854
−2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request offers an implementation of NTLM relaying attack vectors targeting the HTTP endpoints of SCCM Management Points (for secret policies dumping) and Distribution Points (for sensitive package files retrieval).
To this end, two new attacks related to SCCM are implemented, along with some options for each of them.
SCCM Policies attack: targeting the Management Point for secret policies retrieval
This SCCM policies attack will attempt to relay the NTLM authentication data of a domain account (ideally a machine account) to the
/ccm_system_windowsauth/request
HTTP endpoint of a Management Point. It will then register a device in order to retrieve a list of policies. It will then parse this list of policies to extract secret ones and deobfuscate their protected blobs. Note that the proposed implementation is not limited to the NAA policy, but will retrieve all secret policies (including Collection Variables).The
--sccm-policies-clientname
allows customizing the client name used for the registered device. It defaults to the currently relayed account for stealth purposes.The
--sccm-policies-sleep
allows customizing the time to wait after registration. It may be interesting to raise its default value of 180 seconds to wait for the device to be added to collections on SCCM's side.NOTE: when relaying an existing machine account in order to register a new device and dump secret policies, it may be possible that the relayed machine account is already associated with an SCCM device. In this case, the machine will temporarily have the wrong device certificates. It will however automatically re-register itself when needing to interact with SCCM.
The policies retrieval attack saves the certificate/private key generated during device registration, so it can be reused (for instance with SCCMSecrets.py - it may be useful if we did not wait long enough for the device to be added to collections) - it is however only possible before the legitimate device re-registers itself and overwrites our certificate.
The advantage of performing secret policies dump while relaying a machine account already associated with an SCCM device is that we will be able to dump the secret policies of this device's collection (and not only default collections).
This attack writes the results in an output directory composed of the
device
subdirectory (containing device certificate, GUID, name), the raw/json representation of the full policies list, and a subfolder per secret policy. In the secret policy subfolders, the secret policy is written, as well as the cleartext of every deobfuscated secret blobs.SCCM Distribution Point attack: targeting Distribution Points to retrieve sensitive package files
The SCCM Distribution Point attack will attempt to use the relayed NTLM data to authenticate to the
/sms_dp_smspkg$/Datalib
endpoint of a Distribution Point. This will first allow to index the files stored on the Distribution Point, by browsing theDatalib
HTTP file directory structure. Once indexing has been performed, it will download the files with specific extensions.The
--sccm-dp-extensions
allows customizing the extensions to look for. Providing an empty string will only perform indexing, nothing else.The
--sccm-dp-indexfile
takes the path to an index file already produced by an SCCM Distribution Point attack. This is useful if you have indexed files of a Distribution Point in a previous attack, and you realized that you want to download files with other extensions. Specifying an existing index file (index.json
from the loot directory) avoids indexing files again.The
--sccm-dp-files
takes the path to a file containing a list of URLs, one by line, to be downloaded from the Distribution Point. This is again useful if you already ran an SCCM Distribution Point attack, and want to download specific files that seem interesting - without downloading all files with a similar extension. Providing this option will not trigger file indexing.NOTE: I am aware of another pull request that was recently submitted to fetch files from the Distribution Point (#1790). Kudos to ar0dd, I used some elements from his pull request and indicated it in the produced SCCM DP attack file. I however chose a different approach in order to index files from the Distribution Point. Indeed, ad0dd relied on file signatures to find out what files are hosted on the Distribution Point. On my recent SCCM lab environment, it seems like these file signatures are not available by default. I thus chose the
Datalib
indexing method instead (that is also the default method ofsccm-http-looter
), which seems more reliable. I also added some more options regarding file download.Similarly to the SCCM Policies attack, the output is written to a directory. It contains the
index.json
andindex.txt
files, representing an index of available files on the Distribution Point (the.txt
file has a human-readable format mimicking the Unixtree
command). Then, a subfolder is created for each package. The downloaded files are stored in these package subdirectories.The tests regarding this pull request were mainly performed on SCCM version 2403 (5.2403.1171.1000). The source code is heavily inspired by the SCCMSecrets.py tool (https://github.com/synacktiv/SCCMSecrets/), which I also authored.