Add Support for The Use of WildCard Characters

[Chainski]

Install.exe was executed before adding these registry values using Powershell

These PowerShell commands create a new registry key named $77test under HKLM:\Software, then adds a new registry value named r77 with the value calc.exe under that key. Finally, it retrieves the value of r77 from the $77test registry key.

However After running Install.exe with wildcards * in the command

If I use wildcards in the commands, an error is triggered. Integrating support for wildcard characters might resolve this issue and allow for successful retrieval of the registry value. It would be highly beneficial if you could replicate this scenario, as it would facilitate the inclusion of wildcard functionality in future updates.

[bytecode77]

Is this an issue where the * character causes PowerShell to malfunction once r77 is installed, or are you suggesting to hide registry value by name using wildcards (*)?

I'm guessing that the registry key $77te*t does not actually exist, but the wildcard is a feature by powershell to kind of "search" for registry keys, is that correct?

[Chainski]

Is this an issue where the * character causes PowerShell to malfunction once r77 is installed, or are you suggesting to hide registry value by name using wildcards (*)?

* character causes PowerShell to malfunction once r77 is installed.

I'm guessing that the registry key $77te*t does not actually exist, but the wildcard is a feature by powershell to kind of "search" for registry keys, is that correct?

No $77te*t actually exists but using wildcards triggered the error. Instead of specifiying the exact registry path I used *

[bytecode77]

I can confirm that when r77 is installed, wildcard searches behave differently. When you look at ProcessMonitor, you will see that RegOpenKey is used when accessing a key directly. However, when using wildcards, Powershell is doing a RegEnumKey on the parent registry key. The result set doesn't contain the "$77..." child key, therefore Powershelll cannot find it.

Notably, r77 does not forbid direct access to hidden entities. Otherwise, it would be impossible for r77 to maintain itself. However, when enumerating a directory or registry key like you did, the hidden entries won't show.

Why do you need to access a registry key by a wildcard?

[Chainski]

I can confirm that when r77 is installed, wildcard searches behave differently. When you look at ProcessMonitor, you will see that RegOpenKey is used when accessing a key directly. However, when using wildcards, Powershell is doing a RegEnumKey on the parent registry key. The result set doesn't contain the "$77..." child key, therefore Powershelll cannot find it.

Notably, r77 does not forbid direct access to hidden entities. Otherwise, it would be impossible for r77 to maintain itself. However, when enumerating a directory or registry key like you did, the hidden entries won't show.

Why do you need to access a registry key by a wildcard?

Repeatedly executing identical commands especially with powershell could eventually trigger antivirus products, so incorporating wildcard support might offer a workaround for bypassing AMSI detection.

[bytecode77]

I assume you're talking about AMSI within your Powershell process - or in general, not the AMSI bypass of the r77 startup routine?

If so, then that's an interesting thought... Why not just hook AmsiScanBuffer to always return AMSI_RESULT_CLEAN. That way, after r77 is installed, AMSI would be simply disabled. I've added this to the feature list, because I think that this would be generally appreciated.

Will let you know when there's a release. However, I still didn't understand why you would use Powershell to explicitly search for hidden entries by basically iterating over registry keys. Or do you assume that somebody else uses Powershell and offend AV by triggering AMSI?

[bytecode77]

So, the new version 1.5.2 implements a systemwide AMSI bypass by hooking AmsiScanBuffer in every process, not just during the startup. Meaning, that any injected process will no longer communicate with the AV through AMSI.

That should eliminate the possibility of Powershell sending binaries found in the registry to the AV. As for your bug report, it can't be addressed directly, because the wildcards you enter in Powershell simply execute a different feature than the full paths.

[Chainski]

I assume you're talking about AMSI within your Powershell process - or in general, not the AMSI bypass of the r77 startup routine?

If so, then that's an interesting thought... Why not just hook AmsiScanBuffer to always return AMSI_RESULT_CLEAN. That way, after r77 is installed, AMSI would be simply disabled. I've added this to the feature list, because I think that this would be generally appreciated.

Will let you know when there's a release. However, I still didn't understand why you would use Powershell to explicitly search for hidden entries by basically iterating over registry keys. Or do you assume that somebody else uses Powershell and offend AV by triggering AMSI?

I'm referring to the amsi.dll loaded into the PowerShell process upon startup. I've observed some changes your code, indicating that amsi.dll shouldn't pose an issue with version 1.5.2, as you previously mentioned that AmsiScanBuffer is hooked in every process when Install.exe is executed. The PowerShell commands I utilized earlier haven't been flagged, so there's no immediate need to incorporate support for wildcards. However, it might be considered for future updates. Thank you for your help.