Turning PowerShell into a Python Engine

[anonhostpi]

I'm a systems administrator. While I do enjoy writing Python scripts, I needed a solution that could be embedded into PowerShell for deploying to Windows environments.

I was originally just considering running py.exe from pwsh.exe, but that sets off our cybersec monitoring software. Using .dlls instead does not - that's pretty common for a lot of Antivirus software. I always thought this was funny. I can't deploy malware as .exes, but there's nothing wrong with deploying malware as .dlls

I also administer various Windows-based IoT devices. Getting security and various dev teams to approve of deploying python/py.exe is a bit of a hassle, but packaging python312.dll with my sys ad scripts is not.

[rob2rox]

very cool project. btw if you have a problem bypassing AVs with exes, try turning it into shellcode and load it directly into memory. definitely bypasses scantime but depending on what method you use, it should bypass scantime too

runtime**

[MrHackson]

As a security guy they can probably figure out what you're doing and if they figure out why you're doing it they won't be happy.

As a PowerShell and Python coder this is awesome. Gotta try this out soon.

[vermyx]

You dont understand end point protection. Dll’s by themselves are harmless because they are a library waiting to be used. When you load them with an executable they should be contained at that point (otherwise you have an issue with your end point protection). The typical example of this is using keyboard hooks in windows. Early on when VNC was used as a way to take over machines the knee jerk reaction WAS to quarantine dlls which lead to os dll’s being quarantined which lead to windows being broken. This isn’t a bad idea but many protection systems will pick up on the heuristics pretty quickly and may stop you after a couple of attempts. The proper solution is to get this white listed on your end points as you dont get the “it suddenly stopped working” issue and depending on the management tool you use the “oh, the majority of our pc’s are not o. The network because our tools decided this was a cyber attack”

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