Installation failed due to PS execution together with WDAC (Windows Defender Application Control)

[Dazzler5052]

Hi AdvancedInstaller community,

we are facing issue where we are unable to install msi application created with Advanced Installer. Problem occurs when there is WDAC used in production and during installation there is powershell script execution.

The installer and powershell script are both signed and the certificate is added to WDAC policy file (added also Advanced Installer certificate).

I did some tests and e.g. if I convert the powershell script to exe file via ps2exe command, the the script/exe is executed correctly but not sure how exactly ps2exe works I would suppose it just encapsulate into exe and in the inner parts it still invoke pure PS.

I've also tried to put the certificates directly into computer cert store (Trusted Root Certification Authorities and Trusted Publishers) but I got the same result.

I always get error:

Code: Select all

Property(C): POWERSHELL_EXECUTION_LOG = C:\Users\User\AppData\Local\Temp\pss3FFE.ps1 : Cannot dot-source this command because it was defined in a different 
language mode. To invoke this command without importing its contents, omit the '.' operator.
    + CategoryInfo          : InvalidOperation: (:) [pss3FFE.ps1], NotSupportedException
    + FullyQualifiedErrorId : DotSourceNotSupported,pss3FFE.ps1

Does anyone have any experience with this? The only possible solution for me now is to disable Script enforcement in WDAC which is not what I want. I also tried to use WDAC Wizard tool to parse events that happened during the audit mode but after disabling audit mode, I get the same result.

I attached a sample aip project + policy...To setup the environment (Win 11), you need to unzip binary policies and set them via citool --update-policy $file...

I already checked this but this is probably related only to the installer execution (which itself works ok except for the PS): viewtopic.php?t=51147

Thank for help

[Catalin]

Hello and welcome to our forums,

I have to admit that I might not be the most experienced when it comes to WDAC. So far, the solution I've found to be able to run MSI packages was to have the certificate installed on the machine.

Please allow me some more time to test and investigate this and I will followup as soon as I will have more information.

P.S.: from my understanding, the script execution works fine manually and it only fails when launched from the MSI package?

Best regards,
Catalin

[Dazzler5052]

Thanks for quick response. Take your time.

Yes, I cannot execute the powershell when executing from msi but looks like only if it goes directly through the powershell runner dll. If I execute the powershell through the run app custom action powershell.exe -f file.ps1 it is executed well.

It's a quite pain in the ass the WDAC I'm trying to make it work for 2 days already but I came with nothing unless turn on disable script enforcement in WDAC which helps.

I think the key to make it work is this page: https://learn.microsoft.com/en-us/windo ... nforcement
Especially this section:

Validation for signed scripts is done using the WinVerifyTrust API. To pass validation, the signature root must be present in the trusted root store on the device and your WDAC policy must allow it. This behavior is different from WDAC validation for executable files, which doesn't require installation of the root certificate.

But even though I put the cert to the store and to WDAC it didn't help.

Tip: You can use WDAC wizard which quite simplifies work with the WDAC policy.

Edit note: I'm not sure if it's possible but it seems to me there must be some unsigned element in the chain that executes the powershell script during installation and therefore WDAC restricts execution of the powershell script. In my case, my script were signed also I put AI and my generated certificate into trusted cert store and WDAC but still no success.

[Catalin]

Hello,

So I've tested and investigated this, but unfortunately I wasn't able to get to the bottom of it just yet.

At least for now, we have the ps2exe workaround which seems to be working fine.

I will continue my investigations and will let you know if I will be able to find anything useful.

Thank you for your understanding and patience on this!

Best regards,
Catalin

[Dazzler5052]

Thanks for updating the status. I understand this is not so easy to solve it or investigate it if it's even possible.
I will be looking forward for next news about the progress.

[Catalin]

Hello,

As promised, I'm coming back with a followup, although it is not a positive one.

Unfortunately, I wasn't able to overcome this (I've been testing this a lot since my last message) - which means we're left with your ps2exe workaround.

Thank you for your understanding!

If you have any other questions, please do not hesitate to contact me and I will gladly assist.

Best regards,
Catalin

[Dazzler5052]

Thank you for your answer though it's not positive. If I'm right with PS2EXE workaround, I cannot use setting MSI properties through the PS script, right? As I guess it is running in a different context.

[Catalin]

Hello,

You are always welcome!

If I'm right with PS2EXE workaround, I cannot use setting MSI properties through the PS script, right?

To be quite honest with you, I am not sure whether this is possible or not as I've never tested it this way. I would assume you are right as the "Run PowerShell script file" custom action is no longer used and we use a "LaunchFile" instead to launch our EXE.

Best regards,
Catalin

[TonyG]

Hi, i'm facing the problem as described before that WDAC is blocking a custom action with an inline powershell script which normally unpacks the powershell script in C:\Windows\SystemTemp\scr****.ps1 <=> Because WDAC doesn't allow temporary files running from C:\Windows\SystemTemp, the Custom Action with Inline Powershell script doesn't run. Besides default WDAC only allows known (whitelisted) scripts running in Constraint Mode and not in Full Language Mode which is needed in this case.

The suggestion I read is to convert the Inline Powershell Script to an exe with ps2exe (https://github.com/MScholtes/PS2EXE)
Is this the only way to deal with WDAC security ? That would mean that we can't use powershell script with WDAC security ?
That would seriously limit the possibilities of Advanced Installer Custom Actions.

Has someone already found a solution to keep using powershell scripts (inline or fysical .ps1) in Custom Actions which are allowed by WDAC ?
Converting all powershell scripts to exe and not being able to use powershell would seriously limit the packaging solutions.

If anyone knows a solution with description if how to setup the Custom Actions with powershell, please let me know, thanx.

[Catalin]

Hello Tony and welcome to our forums,

Indeed, WDAC seems to have become a realy headache when it comes to PS scripts.

I have two suggestions:

1. try to change the launching folder of the PowerShell script, as well as make sure that the script is digitally signed.

Screenshot_27.png (25.54 KiB) Viewed 3010 times

2. use a .ps1 file instead of an inline script and launch it via a "Launch File" custom action that launches PowerShell.exe. Something like this:

Code: Select all

powershell.exe -ExecutionPolicy Bypass -File "C:\Program Files\MyApp\myscript.ps1"

Could you please try these and let me know if any of those help?

Best regards,
Catalin

[TonyG]

Hi Catalin, thanks for your reply.
We will try the suggested solutions and test the results with WDAC.

We are already testing with .ps1 files instead of inline scripts, but we also have to test with another launching folder.
The powershell inline script is signed, because the option "Digitally sign the script" is on with the Inline Powershell Script

With the .ps1 file we don't have a signed file yet, the .ps1 is not signed by a trusted certificate.
Maybe we need to buy a certificate for that, but first we are trying without a certificate.

If we find a working solution we will post it on this location.

Best regards, Tony

[Catalin]

You are always welcome, Tony!

And thank you for your followup on this. Sure, if you find a solution, please share it with us as that will help further users facing a similar scenario.

Having my fingers crossed for you.

Best regards,
Catalin