I think a lot of people will read 'python malware' and assume packages; that's not what this is about.

A lot of exploits are two-stage. Stage one is usually the vulnerability, usually written in C given the low-level and tightly controlled instructions required. The exploit breaks security to run an executable or otherwise gain control. Stage two is usually downloading a python executable to grab the goods.

There's nothing especially sinister about the selection of Python for this case over other interpreted languages. Malware authors are just regular developers - they don't want to spend hours trying to hack together a C binary to dump a database when six lines of Python will do it. Python just runs on a lot of platforms, has a lot of mature drop-in libraries, and decent documentation. They use it for the same reason we use it.

The article just makes it sound like malware developers are using modern packaging tools to turn that two-stage exploit into a single-stage. That doesn't strike me as particularly surprising. Teams tend to gravitate towards specializing in one tool when they can. I'd obviously prefer to write a bunch of python than do the same in C, when performance isn't a huge concern (It's the other guy's CPU, after all).

Just seems like a minor observation, rather than some doom trend.

The article mentions that Python malware comes with difficulties but in my experience it has the advantage to be an easy and simple way to write reliable malware. Packaging with PyInstaller to create a single (but large) executable is easy and helps avoiding detection as the interpreter is embedded in the PE (I never went in depth on this topic but it would be interesting to check out).

Shameless plug; I wrote a few popular articles on 0x00sec about Python malware on Windows just to show how simple and easy it is to build either using ctypes to call WinAPI functions or using pywin32 wrapper which makes the whole thing a lot faster.

See part 1 here https://0x00sec.org/t/malware-writing-python-malware-part-1/...

Definitely not the way to go if you have limited memory and need to write tiny shell code but it’s good enough for a stage 2 payload.

This is a very interesting article, and it is somewhat surprising to see Python entering the malware space more in recent years. Other compiled languages with sophisticated runtimes and cross platform support fit in quite well (Go especially) but to see Python is quite interesting. I guess these actors are at a point where they can churn it out relatively quickly, and are not too worried about the code being reversed rather trivially.

What I'd want to learn more about is whether or not these Python samples tend to be very large (in terms of actual code, and not just language internals/pyinstaller/boilerplate). I expected the real life samples to be smaller than some of the larger botnets and the like written in these compiled languages, but some of the ones you go in depth on are somewhat surprising.

I was going to mention Python 3.8's audit hooks[1] as a possible way to catch some of these issues, (like web requests, for example) but when I went to Google to find the link, it also came up with an article explaining how to bypass the audit hooks[2]...

[1] https://docs.python.org/3/library/audit_events.html

[2] https://daddycocoaman.dev/posts/bypassing-python38-audit-hoo...

OT: Those graphs* are interesting in that the spikes for Java/C++ seem to align with fall/spring school semesters, and Javascript tends to invert that pattern and have a spike during the summer (internships? personal summer projects?).

* https://www.cyborgsecurity.com/wp-content/uploads/2020/07/py...

This seemed to be more about how to compile/decompile and obfuscate Python code then anything about malware. The two examples were the ability to take screenshots and make web requests were the only two actual potential malware related topics, but even those are fairly basic concepts that have a huge range of applications outside malware. These things are also fairly trivial in most even slightly mature languages.

The section on eval was a little more interesting but still nothing special.

Personally, and this is just my probably uninformed opinion, the biggest thing about Python that makes it useful for malware is its huge, mostly uncurated repository of libraries and addons that are easy to install and use without ever looking at it. This aspect of Python seems likely the most appealing for would be malware writers. The ease of making malicious code widely available without a lot of scrutiny.

This article lost me, what really confuses me is exceptions in malware with obfuscated code example (I would not call this obfuscated code) and "import cv2" example, does malware installs open-cv library on windows in background ? (this simply does not compute)

Is it just me, or does this read like a friendly howto for a would-be python malware author?

This has been the case for some time. PowerShell is an even more popular malware interpreter because it is already on the target and its obfuscation options are numerous.

Python is very versatile from a malware perspective, especially toward anything *nix since python is always pre-installed. There are tons of pip packages that can be used to the bad guy's advantage that they don't have to rewrite themselves (e.g. keyloggers, video camera related packages. All they need to do is have a way to deploy it and receive the data, then it's just a matter of hiding the communication. Building loaders, reverse shells and bypassing AV is hell of a lot easier in Python as well.

See PupyRAT, a full-on multi-os admin tool mainly written in Python (2 unfortunately, also it's buggy and outdated), it's a great example. They use a C wrapper around their remote admin tool that is written in Python. Their (C) loader downloads the provided Python payload from an http link, stores it in a specific memory address that gets executed right after. Because it's in memory, it doesn't touch the disk, Unless you are using the Windows payload (which provides multiple options to hide the program using a set of windows' exploits).

If it weren't for your examples, I wouldn't have believed blackhats would waste time using Python. It seems like it would be easier to defend against Python malware isn't precompiled, and if it is precompiled, we're just back to hand analyzing trojans at the assembly level. When you said that SeaDuke was cross-platform, isn't that a huge problem that could easily be detected since the attacker requires target-side interpretation? E.g., more security built into Python about how it is invoked: requiring user interaction to determine whether the user is running something.

The article is totally mistitled. It refers to Python being used to create Windows malware using compilers, instead of using C or somethign else.

Packages are not targeted for now.

Fascinating read. I almost passed up on this article.

Python’s eval() function reminds me almost of Lisp’s eval/apply feature, which is supposedly at the heart of what makes Lisp so special.

I imagined building a program, that I could teach, to eventually write its own programs. But, I figured I would output it to a separate file, and run that file instead.

Most of the exploit scripts are written in python. Easy string manipulation and third party packages (angr, ctftools etc)

One issue is Anki's shared add-ons - https://ankiweb.net/shared/addons/2.1. They're written in Python, and can potentially be malware. Is auditing them the only way?

https://youtu.be/56ciki25j2I presentation at the local hacker connlastvywar on how simple it is to write some shitty but functional malware in python.

geared towards someone who has never coded before

SCYTHE's in-memory client loads an in-memory CPython interpreter/runtime, even, so you do not even have to compile .py to an exe to run on Windows, for example.

Python is the new VB. Popular and easy to learn.

Does anyone have suggestions for example python malware code for reading?

Fortunately, MSFT hasn't purged all of the cool RAT projects from GitHub but I'm curious if anyone here has suggestions.

I'm not a security researcher but I've always found the more nefarious uses of software clever and interesting.

nice

It's a well known problem that many languages (Python, Ruby, Node) have notoriously insecure trust chains in their dependency management frameworks. If more malware is hitting the Python ecosystem, I think it's just a matter of time until someone manages to publish a tainted version of `requests` or some similarly popular Python lib.

I know for a fact a lot of cybersecurity automation mind share is in Python. Curious to see if this new wave of Python malware will make it into any big cybersecurity vendors. I've performed due diligence on a number of cybersecurity vendors that I wouldn't qualify as having good security posture for stuff like this.