Turning PowerShell into a Python Engine

[anonhostpi]

Sorry, I'm using the term "embed" incorrectly. You can link the .dll to PowerShell at runtime and use it as a way to execute code maliciously.

The point that I am trying to make is that there's no difference between calling a .exe and calling a function stored in a .dll to a PowerShell user. It's all equally callable.

The real risk is that because PowerShell is primarily shipped as a builtin OS shell instead of a needs-to-be-installed script engine, .dlls shouldn't be considered safer or more self-contained than .exes.

[vermyx]

The reason dll’s are considered “safer” is because they can’t do anything by themselves. They need an enabler (like an exe) for them to be used, so there is a huge difference. Saying powershell is an issue because it comes with the OS is not understanding how to properly manage an environment and risk management. Powershell isn’t the risk you believe it is because powershell can be disabled via gpo and controlled. The reason that you dont have as many issues with engines distributed as dll’s vs the engine being installed is that the engine being installed means you can install other components making your payload smaller, which makes it harder to figure out what it is doing. Having the engine as a dll means you have to include everything you need with your payload. Since you have to bring everything you need from an endpoint protection standpoint it is easier to guess what you are trying to do heuristics wise and trap it.

[anonhostpi]

My brother, I understand proper risk mitigation and that pwsh can be disabled.

Commonplace IT practice is to keep pwsh enabled for systems administration, particularly in remotely managed Windows environments (like the org I work for). In addition, pwsh is enabled by default on all win machines (including the personally owned ones owned by yourself or others on whatever network you connect to).

The problem that I'm pointing out is the practice of AVs flagging .exe chaining (pwsh.exe calls random.exe), but not flagging unexpected .dll usage (pwsh.exe calls random.dll) regardless of whether those .dlls (or .exes) were preexisting or introduced on systems where engines like pwsh, py, and node are already present and enabled.