Windows Defender Attack Surface Reduction

[sk]

When the “Block process creations originating from PSExec and WMI commands” ASR rule is enable, this breaks BatchPatch (as expected)

Are there plans to move away from PSExec?

Reference:
https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/attack-surface-reduction

[doug]

In the future we might provide other options. For now if you want to keep that rule enabled you should consider whitelisting psexec and psexesvc, or have a look at this link which provides instructions for modifying the remote service name, which might enable you to leave everything else as-is: what-to-do-when-psexec-is-blocked-by-your-anti-virus-software

[wteunissen]

Today my security officer did sent me this link showing that it is not safe to use PsExec in our company:

https://medium.com/tenable-techblog/psexec-local-privilege-escalation-2e8069adc9c8

Do you know how to protect our servers?

[doug]

Hello – Thank you for sharing that posting. The simplest thing you can do right now to mitigate this issue is under ‘Tools > Settings > Remote Execution‘ set a value for ‘Use PsExec -r switch‘. When you enter a custom value in this field, the PsExec remote service and named pipe are created with that custom name instead of the default name, PSEXESVC. In this way a malicious user pipe squatting on your target servers as \PSEXESVC won’t have any impact on you because your pipe will be created as \YourCustomName. The malicious user would have to know/guess your custom pipe name in advance in order to cause trouble, which would be very unlikely and require the attack to be targeted at you specifically instead of just a generic attack.

We don’t know at this time when Microsoft will address the issue directly in the PsExec code (they apparently did suggest that they will release an update to PsExec to resolve this, though it’s unclear when), so we are also discussing adding an additional safety measure to BP soon that would enable you to add a pseudorandom number/string to your custom name so that every single action would get a unique remote service and pipe name. This would virtually eliminate any possibility for casual exploitation by making the pipe name even more unguessable, thus further reducing the possibility of any pipe squatting on that name. And we will additionally be considering other possibilities moving forward as well.

One other option you could consider for the time being is you could use PaExec instead of PsExec. We don’t know at the moment if PaExec is technically susceptible to the same kind of pipe squatting attack, but we do know that PaExec already adds a pseudorandom number to its remote service and pipe name, which means that if it were similarly vulnerable, the random pipe name would successfully mitigate the issue by virtue of it being unguessable in a casual attack, as described above. The main downside to PaExec is that if you are specifying alternate credentials for any row in the BP grid, these credentials are *obfuscated* when sent over the network using PaExec but not fully *encrypted* like they are when using PsExec. Realistically, while encryption would certainly be best, lack of encryption in this case is actually not necessarily as bad as it sounds, assuming you are operating on a switched network, but it’s definitely still something to consider if you use alternate credentials. More is explained here about why unencrypted credentials may not be as bad as it sounds, when using a switched network. To be very clear though, we always recommend using encryption whenever possible when passing credentials over a network. The article merely highlights that in some use cases there may be an acceptable risk to the user choosing an unencrypted approach.

Our recommendation is to continue using PsExec but to specify a custom service name as described at the top of this posting. We expect to release an update pretty soon that will further improve upon the custom service name setting by enabling the ability to also append a pseuodrandom number/string to it for each connection, as mentioned previously. However, if you decide you want to use PaExec, then under ‘Tools > Settings > Remote Execution‘ you’ll set a custom path under ‘Use psexec custom filepath‘ and have that filepath point to the location of your paexec.exe. If you choose to use paexec instead of psexec, then you’ll need to uncheck the box for ‘Use PsExec -r switch‘, otherwise it will throw an error when you try to perform any actions that utilize it.

[doug]

Looks like on January 11 2021 PsExec version 2.3 was released. However, we don’t know at the moment if it fixes the issue, though we assume there is a good chance that it does. Also, in our initial test, and confirmed by one other user, PsExec 2.3 seems to not work properly. In BP it produces ‘Error 1611:233 Failure’. We don’t know yet if all BP users would experience this or only some. We are investigating. Not yet sure what to make of it.

[doug]

Interestingly, in testing we just discovered that while psexec.exe v2.3 throws the aforementioned error on our test machines, psexec64.exe v2.3 does not have the same issue.

[wteunissen]

We tested with the custom service name and that works fine.
Later this month i will try the new psexec64.exe.

[doug]

Thanks. Also just FYI for anyone else who reads this thread, the 64/32 bit weirdness appears to be a bug in the new version 2.3 of PsExec. At the moment it seems that you have to use the 64 bit version for 64 bit targets, and the 32 bit version for 32 bit targets. We believe this is not a “feature” but rather is a bug, so we are anticipating a fix/update from Microsoft/Sysinternals.

[doug]

On January 12 2021 another PsExec update was published that fixes the 32/64 bug, so now the standard psexec.exe (32 bit version) works as expected.

[doug]

FYI we discovered that the Jan 12 PsExec update still has a couple of other bugs, so I’d suggest holding off on it still.

[doug]

OK so where things have been left is that PsExec v2.32, which is the current/new release, will work the same as previous versions of PsExec, when using SYSTEM remote execution context. However, when using ‘Elevated token’ in conjunction with alternate credentials in PsExec v2.32, you also have to now additionally use the -i (interactive) switch. In the next release of BP we will add this option as well.

Microsoft appears to be considering this change intentional, and not due to a bug after all. It’s unclear at this time if they will be making any additional changes in the near future, but all signs point to this being where things will be left, at least for now. It does not appear that they plan to release an update to replace v2.32 any time in the very near future.

[doug]

They released PsExec v2.33 yesterday (March 23, 2021). We believe the issue is now properly resolved in this version.

Thanks.

[Author]

Posts