This would incur an added cost in licensing and possibly hardware but this would also be the cleanest way to do it. Also on the security side this would be safer than escalating a legacy ActiveX app on the secure client.

Having multiple instances of IE running remotely on Windows Server and then served using Citrix or something similar should work as well if you don't need full VM isolation between clients, and I've seen this used in real companies with legacy apps that can't run on the standard employee machines. Again though this has a licensing cost.

https://techcommunity.microsoft.com/t5/ask-the-performance-t...

https://learn.microsoft.com/en-us/previous-versions/windows/...

Given that Windows 11 isn't that different from Windows 10, I assume the app compatibility toolkit can be coaxed to work.

Or, more excitingly, probably more versatile in the longer term, and a pile of hacks upon hacks, it might be possible to run in the browser with the likes of jslinux + wine.

eg. https://github.com/lrusso/WinAppRunner or https://github.com/DustinBrett/daedalOS

If you get that working, that'd be really exciting.

I wonder whether you cannot use Windows user permission ACLs. They are pretty fine grained. Might be hard to find the right set of permissions, but for me this sounds the more relevant place compared to PAM.

If this is also some ancient Windows version, such as w2k, I would isolate the overall machine and stick with admin permissions.

Since you're just being squeezed to get through another day, why not P2V into VMs stripped of domain privileges - sounds like its all Windows - and use something like a remote access product to control and record entry?

Let's assume you're broke and it's just the wild west over there in terms of processes and maturity, uh, you could P2V into Hyper-V or Proxmox, remove domain membership and all other accounts, leaving just the credentials needed to make the app work. You could go down the RD access route (blegh), but I'd probably go for something prebuilt and cheap like Splashtop to auth with MFA and permit a basket of users to connect to the VM(s) while recording all sessions. Hopefully there's some kind of EDR agent compatible with the guest OS in the VM to have some telemetry what's going on in there.

But the root of the problem is that someone failed you, politically.

Software for running VMs is free.

> Giving users local admin rights is a massive security risk we can't take.

Sounds like you made your endpoints into pets and bastions, that's an architecture that is guaranteed to fail. Work towards a design where the endpoint no longer matters.

I would look into:

- creating an account to run the apps you need, giving the user the password to this account, or create a shortcut to execute the browser with "runas"

Now here my ideas break down, but I think you could get far with:

- For that account, (log in as it, open IE), and configure the "secure zone" / "internet zone" as "insecure". Allow all active X components to load.

- As an admin: 1) Start/go into "Component services" (run: "DCOMCNFG") 2) Right-click "my computer" -> properties: 3) "Edit default" for both activation and access permissions and for both default and limits: 3.1) Give the new user basically all privileges. 3.2) Review if the process now works with the lower privileged user. 3.3) Reduce privileges as far as possible until the process breaks. Stop there. 4) Consider that "Remote launch" and to a lesser extent "remote access", exposes the computer to remote control _if_ the credentials for the user with those privileges are leaked. 5) Consider if this is worth the risk, if yes, leave the configuration. You're done :)

Some unconnected suggestions: - The page that loads the active X will have a number of GUIDs in them, those are the COM classes that back the active X objects (just DCOM objects). You can look those up in the registry to find the implementing .dll files, paths, etc. etc.

- You _can_ whitelist / safelist individual COM / ActiveX packages if you need to but I've forgotten the exact way to do this, and also what exactly it allows you to do ;). You may find: https://github.com/tyranid/oleviewdotnet useful to research this, it has a tab for "pre approved objects", I think if you get your ActiveX's in that list they'd be able to run under the user you need to. If you can access the HTML page you need to open which loads the ActiveX components, you can search for the CLSIDs in that tool, and perhaps figure out where they are. I'm 90% you can move the CLSIDs to a registry key to put them on the safe list, perhaps that's already enough to bypass the "local admin required".

You may be able to do the launch permissions per com object in `DCOMCNFG`.

> 2) When dealing with hostile ActiveX components, are there specific legacy behaviors (beyond obvious file/registry Access Denied) I should be looking for in my Procmon captures?

If you mean, _abused_ ActiveX components, not much you can do. Obviously yes, access to registry, etc. But if the attacker gets to a point they can load _arbitrary_ dcom objects and talk to them, it's game over, that's RCE.

If you mean, how to find which COM objects I need to allow. Better luck with `oleviewdotnet` I think. And open that page and look for the CLSIDs to know where to start. You can search in the registry and oleview to find them once you have the CLSIDs (guids).

> 3) How do you isolate this kind of hardcoded legacy requirement when there is zero budget for commercial enterprise tools?

I assume you are on a much older version of windows? Xp? 2000?, Then I'm not sure.