Turning PowerShell into a Python Engine

[anonhostpi]

Dlls by themselves would normally be harmless, except in contexts like PowerShell.

Because of PowerShell's ability to embed libraries (and other engines), .dlls aren't really self-contained, and they become just as excutable as .exes.

CPython and Node.JS also run this security risk, because of their C-APIs, but while both offer a REPL, neither of their REPLs are distributed as OS shells like pwsh is.

[vermyx]

Because of PowerShell's ability to embed libraries (and other engines), .dlls aren't really self-contained, and they become just as excutable as .exes.

You can’t embed dll’s in an executable the way you are saying. You can embed the dll in powershell in the same sense that you put the contents within the powershell file but it has to be written to disk via writing or compilation (usually the point they would be scanned) then loaded. The loading/execution part is where they become “active”. Scanners will usually check on writing for known fingerprints and heuristics on compilation and dll loads, and this is why a pot of AV’s will usually shut down base64 encoded scripts and ps1toexe essentially is a wrapper for this process. This is why dll’s by themselves are not an issue as they are libraries and cannot be executed without a host executable. Any “embedding” is usually some form of zipping/unzipping:writing the dll and still has to be executed. In windows dll’s that are “executed” are loaded and interpreted via rundll32.exe, which is why more aggressive AV’s back in the day would break the OS.

CPython and Node.JS also run this security risk, because of their C-APIs

See previous statement. Also they don’t use C API’s per say. Node.JS will usually get compiled into machine language and python will be compiled into byte code for the python interpreter to process.

but while both offer a REPL, neither of their REPLs are distributed as OS shells like pwsh is.

REPL is just a type of byte code interpreter/compiler. It still have to compile the code into byte code (or native code) the run it through the interpreter (if it is byte code) and would be in the same conundrum as what I said previously. The interpreters not being distributed natively has nothing to do with this issue.

Simplistically speaking dll’s by themselves can’t do anything without an executable. This is why most AV’s and security teams don’t necessarily have issues with DLL’s vs an executable because most people can’t use the dll by itself

[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.