This isn't really what you're asking for but is virtualization possible on the client side? Either through direct virtualization on the client PC or using VDI. Basically IE and Windows with admin rights would run in a restricted VM devoted solely to that app, with the VM restricted from network access outside of connections to the legacy server and any management/etc. requirements.
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.
If it runs the business, go talk to whoever failed the politics and didn't get the necessary investments to get back on track for the long term by rebuilding this in a modern stack. How are conversations about enterprise risk not happening here?
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
> 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.
This isn't really what you're asking for but is virtualization possible on the client side? Either through direct virtualization on the client PC or using VDI. Basically IE and Windows with admin rights would run in a restricted VM devoted solely to that app, with the VM restricted from network access outside of connections to the legacy server and any management/etc. requirements.
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.
If it runs the business, go talk to whoever failed the politics and didn't get the necessary investments to get back on track for the long term by rebuilding this in a modern stack. How are conversations about enterprise risk not happening here?
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
> 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.
FINALLY some sane answer instead of moaning about politics and investments etc.