SCCM Management Point and Distribution Point relay attacks implementation #1832
Conversation
|
Hi @q-roland, I'm currently testing this PR against https://docs.ludus.cloud/docs/environment-guides/sccm/ . So far it's going pretty well. As you mentioned #1790 features a similar implementation, which you used for inspiration as well. Do you see any other improvement that could be integrated from that PR? |
anadrianmanrique
added
the
waiting for response
… ; update requirements.txt
|
Hi @anadrianmanrique, Regarding PR #1790, I do not have additional elements to integrate here (not much code was actually ported from PR #1790, since the attack implementation itself is replicating SCCMSecrets. The inspiration was rather on the integration with ntlmrelayx) Do not hesitate if you have any other question or request! |
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/requestHTTP 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-clientnameallows customizing the client name used for the registered device. It defaults to the currently relayed account for stealth purposes.The
--sccm-policies-sleepallows 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
devicesubdirectory (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$/Datalibendpoint of a Distribution Point. This will first allow to index the files stored on the Distribution Point, by browsing theDatalibHTTP file directory structure. Once indexing has been performed, it will download the files with specific extensions.The
--sccm-dp-extensionsallows customizing the extensions to look for. Providing an empty string will only perform indexing, nothing else.The
--sccm-dp-indexfiletakes 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.jsonfrom the loot directory) avoids indexing files again.The
--sccm-dp-filestakes 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
Datalibindexing 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.jsonandindex.txtfiles, representing an index of available files on the Distribution Point (the.txtfile has a human-readable format mimicking the Unixtreecommand). 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.