[BUG] An exception occurred while trying to decrypt policy response about sharpsccm HOT 17 CLOSED

I tested this in two labs today and a colleague's testing was successful as well, so I merged this fix into main in PR #48. Thanks again for the report!

from sharpsccm.

Also it's absolute madness how many reports I get on that account having SCCM admin privs... it's like mailing your house keys to everyone in your city.

from sharpsccm.

unfortunately, I have the same problem :(

from sharpsccm.

Hey, sorry for the massive delay, but I finally have time to work on this next week and have the same issue in one of my labs, so I think I should be able to figure it out.

from sharpsccm.

Thank you, @Mayyhem . Much appreciated.

In my case, the local commands worked perfectly, which allowed to extract the NAA account, which has local admin privileges on the SCCM main box :)

Not sure, how much different info I would get from the 'get secrets', but it would be great to check.

thanks again for great tool!

from sharpsccm.

Eyyyy that's awesome to hear it worked well for you and you were able to get on the site server @0xElessar, thanks for sharing! It's very likely the info would be the same from get secrets, but there are cases when it wouldn't match, like if a secret had been added to your machine by the server but the machine hadn't fetched policy since the change. The get secrets command is useful when you don't have local admin privileges but can create a machine account. If you're not admin and can't create a machine account, check out fortra/impacket#1425.

from sharpsccm.

Eyyyy that's awesome to hear it worked well for you and you were able to get on the site server @0xElessar, thanks for sharing! It's very likely the info would be the same from get secrets, but there are cases when it wouldn't match, like if a secret had been added to your machine by the server but the machine hadn't fetched policy since the change. The get secrets command is useful when you don't have local admin privileges but can create a machine account. If you're not admin and can't create a machine account, check out fortra/impacket#1425.

Fantastic. Thank you. Great to know!

from sharpsccm.

Just wanted to post an update. I see this issue in my lab running ConfigMgr 2303 on one system but not others and don't see it at all in another lab running 2309. I have not been able to identify the root cause and resolve it yet, but I will keep you posted.

from sharpsccm.

I think the issue may be fixed in https://github.com/Mayyhem/SharpSCCM/tree/2.0.4, so check that out if you need a quick fix, but I need to do further testing before merging into main. I think maybe in some cases the same certificate can be used for signing and encryption and in some cases it can't.

from sharpsccm.

Thank you, @Mayyhem . I will check that as soon as possible.

UPDATE: unfortunately, the new version kills my beacon for some reason (event viewer reports unhandled exception in the decompressXMLNodes). Running through a beacon, is the only way for me to check.

from sharpsccm.

@0xElessar Thanks for checking it out! I'll run it through beacon next chance I have and see if I can reproduce and fix the issue you're seeing. Really appreciate you putting an extra pair of eyes on this!

from sharpsccm.

My pleasure @Mayyhem. To be honest, I don't think this is a beacon fault. I used Brute-Ratel C2 in this case. But I am suspecting the SCCM config on the customer site is unusual/old, which triggers the exception in the decompressXMLNodes function/method. This exception was clearly logged in the Application Event Log. If you don't mind checking the exception handler in this function, that would be great :) Thank you for the tool, again! Extremely helpful.

from sharpsccm.

@0xElessar does running SharpSCCM with the --debug option provide any additional details in the full stack trace, or is that not possible before the agent crashes? Is dropping the binary to disk out of the question?

Another idea I have is to compile the version of SharpSCCM just before Carsten implemented the built-in NAA decryption (where DecompressXMLNodes was introduced) to see if there are issues (https://github.com/Mayyhem/SharpSCCM/blob/54aaccdfeeca92b5264f2c1fc244c9368fdfd040/lib/MgmtPointMessaging.cs). Recovered credentials can be deobfuscated using https://github.com/Mayyhem/SharpSCCM/tree/main/DeobfuscateSecretString.

from sharpsccm.

I will take a look at implementing better exception handling as well, although I'm not sure how to get the output needed to fix the issue before the agent crashes. I could probably create a branch that just dumps the XML and skips the rest of the function so we can see if it's compressed in some unexpected way? If we can get the XML that decompression fails on, I should be able to debug more thoroughly on my end.

from sharpsccm.

@Mayyhem , I really appreciate your effort here. Big thank you! I will come back to that environment in a few weeks and will make more tests definitely. For now, I don't have access unfortunately. I think the SharpSCCM crashes first, because I could find the application crash in the Event Log (with references to the decompressXMLNodes). I will use the --debug option next time I run it definitely.

EDR is running there, so dropping the binary will be challenging and require additional time to implement some obfuscation. :/

from sharpsccm.

As long as stealth isn't a huge issue, I could write a stub that only includes the code necessary to request and dump the XML pretty quickly, which would be unlikely to trigger default EDR detections. When you're back in the environment, please let me know and I'd be happy to troubleshoot further if you have the time. I'm also available as Mayyhem on the BloodHoundGang Slack if you want to chat in real time. Thanks for all your help!

from sharpsccm.

Thank you, @Mayyhem . Much appreciated. I will do that :)

from sharpsccm.