Lockdown eclusion for one specifig *.exe

Are you able to post a couple of 911 Application Event log entries for the detections? 

There is a filter called "HitmanPro.Alert Events" for convenience. 

Maybe copy the full details of a couple:

Paste that to a new text document and share those.

Thanks.

Thank you for the fast reply.

I uploaded two 911 Events from the event log. 

www.dropbox.com/.../AMq-5PTeF3icp5f8bXvMID8

The "Process based thumbprint" - 50f95a287eb578ff8490ffb403b2a58b2661fa39c0013d923bd046d55641ed1e, is the same for both detections, I assume that is the same for all? Using that will exempt the process WorkspacesDesktop.exe from Lockdown mitigations. 

Downloading an exe via the browser (Edge in this case) and running looks a bit dodgy I suppose when it starts launching PowerShell.

The primary detection ID/thumbprint is changing, I suspect due to the command line changing:

- powershell.exe -NoProfile -NonInteractive (New-Object -ComObject shell.application).NameSpace('C:\Users\MMustermann\Workspaces\Workspace2').Self.InvokeVerb('pintohome')

- powershell.exe -NoProfile -NonInteractive (New-Object -ComObject shell.application).NameSpace('C:\Users\MMustermann\Workspaces\OP Test WS').Self.InvokeVerb('pintohome')

This is the type you can add the Process thumbprint.



Does that stop them?

Thanks.

Thank you so far for the hint with the thumbprint ID. I added it to the exclusions and will inform the users they should try again. 

I scrolled through my already 20+ made Lockdown exclusions made from the event log for the WorkspaceDesktop.exe and checked the thumprint IDs. It seems they have all a different ID. 

50830b925fa20346b3b4e9b0081280422087af9c3683eaec33e2f4ab54787832

550b1d86669304ee0af520cbb57e394cb5255ae22d6c549703d5d4e8ad71e434

6200c7e16f06dbfd828f75b5c48b27d9f6493fad3cac30f5fae2bfbc78e1b945

68e193a03f2ba4d5e6a9af2afcc463e071759d90147c2feed76967b399ed3cd2

6a2070ff401bd4f3cd90dc200008be7ae8d50209c32f525e13cfff4bf0c2a8fe

7ef4c48eee345d89995cb61e7743bb416aef26d0d045e1f3ed6905b0e7d0e1d4

95b2264d8d5561912c2d430073c92a122a27918070eb8bd5e04fe66535ba8c62

9bae38edf79ecf4f3596c5b48beb2a9fcd8e045166578347323b9dedd6e15efc

9d16ce5698b270ae3031482ac031c86f2a2438f0f948281f693538576de33b9c

aa3ac52e0f3de6104b72d2f358ea0f0de227658d33195cda6abe5b34340113e8

a4beecb6a33fdac1d48e4da1e219c30a57ce8f0611157bc381b01e590628c8e2

a82833ada5afeaf96314606051676d8f294004173d5b970c2162bb8d885d7e8f

bf9a9ed224663882ccee645574c8c108891b92a00970ad2bc002846df91946a1

and so on. 

Is there really no way to simple exlude the WorkspaceDesktop.exe from the detection ?

My exlusion list looks something like this and this cant be the solution :D 

I can see why the primary thumbprint, which is passed up to the exclusion workflow is different. 

Out if interest, If you go to this exclusion type:

Can you find the application in that list, if so you can disable "Lockdown New File" mitigation for it?

The other option, is to prevent the DLL being injected into the process:
C:\Program Files\CONTACT Workspaces Desktop\bin\WorkspacesDesktop.exe
alltogether.

E.g.

or using the variable for program files.  Just type a $ and it will show the available ones.

Thank you again for the help.

The Application was not in the list but I entered it manually with $programfiles variable and without. 

I have the feeling that this is/was the solution.

I will again tell the users to test again and than I will wait. 

If the error is not appearing again, I will come back and mark your reply as solution  

Thank you again for the help.

The Application was not in the list but I entered it manually with $programfiles variable and without. 

I have the feeling that this is/was the solution.

I will again tell the users to test again and than I will wait. 

If the error is not appearing again, I will come back and mark your reply as solution