Discussion

mordechai9000: Could you maintain a VM or other environment dedicated to running the client through RDP or Guacamole or something like that? I think that would mitigate the security risk, somewhat, since there would be nothing else on the system to compromise. It might be practical to force the VM to restore a baseline snapshot after the user logs off, or during a scheduled daily downtime.

ktpsns: If you run the ancient software on modern Windows, you might consider windows sudo, which is a thing nowadays.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.

oneplane: Run it in a restricted VM, which is not joined to AD and cannot talk to it either. PAM will not save you, either will Airlock Digital or something like ATP or anything else like it.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.

sevenf0ur: Maybe wrap the web page by using a legacy WebBrowser control, publish your own executable and grant admin rights on it. Maybe someone out there has already done this for their own weird activex use case.

SCHiM: > 1) Are there any reliable open-source PAM alternatives or privilege elevation tools for Windows that handle this "per-app" scenario effectively?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.

stop50: How much would it cost to rewrite the client tools as an intermediate solution and in the long term to replace the something that can withstand the load?

Servant-of-Inos: That's a valid point, but the scale makes it far from trivial. We are talking about the energy sector here, it's high-stakes and high-load. The current backend isn't just a simple SQL instance; a standard MySQL/Postgres setup would likely choke under the sheer volume of real-time sensor data coming in every few seconds.Rewriting the client isn't just a matter of "money", it's about finding specialized engineers who understand these specific industrial protocols and high-throughput architectures. In our field, "intermediate solutions" can take years to certify and deploy. That’s why we’re forced to maintain this legacy IE/ActiveX stack in a secure way while we evaluate long-term infrastructure overhauls.

brudgers: If it isn't about money, you can find people who can do the work because they have direct relevant experience with similar projects.And that's what your company needs. Because your questions suggest that your team has a very very long way to go relative to understanding the technology to a bet-the-business level.

Servant-of-Inos: You are absolutely right. From a strategic and business standpoint, hiring a specialized engineering firm to overhaul this is the only correct long-term move. I entirely agree.However, I'm the systems administrator tasked with keeping the lights on and securing the endpoints today. I don't control the hiring budget, the strategic roadmap, or the checkbook. My immediate goal is practical risk mitigation: stripping local admin rights from standard users to secure our network, while keeping this legacy ship afloat until management approves that multi-year overhaul. Hence my current trench warfare with Procmon and shims.

tosti: You could try wine, failing that it might be possible to run the software in reactos. Would be cool to have reactos actually running in the energy sector. Especially if there's a big reactor going on.Like others said ITT, a VM to remote in would be the best bet. Local admin can escalate to domain admin. One process as local admin is practically the same as plain local admin. And not just because MSIE is vulnerable.A networked KVM solution could also work. There's various vendors for that and basically you just shelve a few spare boxes and have them run just the one thing you need. Make sure to have a firewall between the boxes and the rest of the network to isolate only required subnets from everything else.Good luck.