Opening process handle to SCM for admin check (Pwn3d!) leading to EDR blocks

[Mercury0]

Please Describe The Problem To Be Solved

The check_if_admin function opens a process handle to SCM which appears to be signatured behavior for response action from certain EDR solutions. Ideally this check could be refactored to avoid inadvertent account lockout during AD engagements.

(Optional): Suggest A Solution

Instead of SCM interaction, what if the function were to instead check whether the user is permitted to mount the C$ SMB share, which would seemingly indicate they have admin privileges.

[NeffIsBack]

Sounds like a good idea! Gonna test that. Do you have 1-2 AVs where this would make a difference?

[Mercury0]

Afraid not, but without naming the specific EDR vendor I can say it is one of the top 3 and related to their identity-based threat coverage. This detection was first observed March 2024.

[Marshall-Hallenbeck]

@Mercury0 is there a reason you can't name a specific vendor?

[Mercury0]

@Marshall-Hallenbeck I didn’t want to originally so they don’t locate this thread and accordingly update their signatures, but I’m referring to CrowdStrike

[Marshall-Hallenbeck]

If we change it they'll probably signature it within a week anyway lol

[NeffIsBack]

Is it that suspicious to connect to C$? I could imagine that it could be a stealthier/better way of detecting privileges. We would need to test it against AVs

[mpgn]

Checking via SCM is the best way and the safest, other methods can lead to false positive or false negative.

As for crowdstrike, I now they are monitoring the project as i've already play cat and mouse game with them and I didn't expect less. Lot of option are already blocked by the edr (sam, lsa, -x etc etc). I don't think NXC is good agains EDR and I don't think the goal is to avoid detection as this is more the job a proper C2 like Bruteratel etc

[aconite33]

Checking via SCM is the best way and the safest, other methods can lead to false positive or false negative.

As for crowdstrike, I now they are monitoring the project as i've already play cat and mouse game with them and I didn't expect less. Lot of option are already blocked by the edr (sam, lsa, -x etc etc). I don't think NXC is good agains EDR and I don't think the goal is to avoid detection as this is more the job a proper C2 like Bruteratel etc

@mpgn agreed with the point of NetExec is not to bypass EDR. I will say we use NetExec as part of some of our TTPs and being able to quickly and accurately identify where we have local admin is definitely an added benefit.

We've played alot of cat and mouse with CS as well and we've noticed that, by default, NetExec will get caught out of the gate due to Impacket using improper signatures of Windows Protocols (e.g., Using NTLM over Kerberos). In particular with @Mercury0 's request, having options for checking for local admin would be an excellent addition.

For @NeffIsBack point about if C$ is flagged by EDR's, it's not specifically flagged. It's all dependent on how you mount the share. I've tried to fight this with impacket's repository multiple times where they won't change certain flags on TGT's which are finger printed because they don't confirm to Windows normal operation procedures.

While not 100% accurate, being able to have READ access on C$ is a fairly high indicator that you do have local administrative rights on the system. Other options that also validate that are local admin is if you have the ability to remotely start the Windows Registry, or modify a registry key in HKLM. However these would more than likely be tracked as a TTP of NetExec.

So, all this wall of text to say, if there could be a flagged option for checking for local admin on C$, knowing it could produce false positive, still would allow for bypassing EDR detection.

[Marshall-Hallenbeck]

Personally I see READ permissions on C\C$ without admin rights a bunch, so it's definitely not a good check replacement for admin.

[aconite33]

Personally I see READ permissions on C\C$ without admin rights a bunch, so it's definitely not a good check replacement for admin.

I'd be curious on how often you see C$ in particular. I have seen C in general, but C$ more than likely denotes Admin access. READ/WRITE I would assume would be high true positive rate of Admin access.

[Marshall-Hallenbeck]

Personally I see READ permissions on C\C$ without admin rights a bunch, so it's definitely not a good check replacement for admin.

I'd be curious on how often you see C$ in particular. I have seen C in general, but C$ more than likely denotes Admin access. READ/WRITE I would assume would be high true positive rate of Admin access.

In the test I did just last week I saw 2 hosts with it. I'll have to pay attention more about how often I see it, but it's definitely not super rare.

[mpgn]

One possibility is to add a flag "--no-admin-check" and you can create your own custom module that will check if the user is admin for you. In this way you evade the EDR with your custom check and the flag, netexec doesn't have to implement a new "admin" check :)

[Mercury0]

I understand that C$ mount permission does not always indicate Admin privileges, but perhaps it could serve as a presumptive check where a modest amount of accuracy is exchanged for a stealthier medium in EDR environments. Ability to READ/WRITE to C$ for a non-Admin user would confer broad filesystem access that could contribute towards locating a privilege escalation vector.

Maybe something like:

# regular check
nxc winrm 1.1.1.1 -d test.com -u fox -H e52c19cefd8f9456d79cd22651c191e8

SMB 1.1.1.1  445    TEST01      [*] Windows 10.0 Build 17763 (name:TEST01) (domain:test.com)
WINRM   1.1.1.1  5985   TEST01      [+] test.com\fox:e52c19cefd8f9456d79cd22651c191e8 (Pwn3d!)

# stealth
nxc winrm 1.1.1.1 -d test.com -u fox -H e52c19cefd8f9456d79cd22651c191e8 -stealth

SMB 1.1.1.1  445    TEST01      [*] Windows 10.0 Build 17763 (name:TEST01) (domain:test.com)
WINRM   1.1.1.1  5985   TEST01      [+] test.com\fox:e52c19cefd8f9456d79cd22651c191e8 (C$ access!)

[Mercury0]

Closing issue as I feel the current consensus is this functionality should be part of a custom module, not core NetExec.

Thank you to everyone who chimed in.