Live data from Hacker News

Python malware on the rise

cyborgsecurity.com

41–50 of 70 posts

Re: Python malware on the rise

#41
post #39

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…

Author here: I've seen your guides before, they're really great! I'd say my article looks at the difficulties, but also the great benefits malware authors have by writing in Python. > Packaging with PyInstaller to create a single (but large) executable is easy and helps avoiding detection as the interpreter is embedded in the PE If you look down further in the article it explores detecting PyInstaller generated execu…

You’re totally right about Yara. Unfortunately I skimmed through the article pretty fast before commenting as I was on a rush when I read it and missed this part. Just finished a second read, great article and well detailed. But my point about detection is more about the good old VirusTotal submission.

As for Nuitka, I was not able to make it work but I will try again. The alternative I also tried in the past was using Cython to generate C code then compile it but because it requires packaging Python std libs Dlls it was too much trouble and I ran into crashes when running.

I also had bad experiences when using packers because they have a tendency to trigger AV detection just for being packers, like ASProtect. Python malware is definitely a topic that deserves more in depth dive.

Good work!

Re: Python malware on the rise

#43
post #22

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…

The article has nothing to do with package management though.

Yes, but malware isn’t limited to windows executables. Note that the article doesn’t call out methods of ingress—these tend to vary a lot depending on who or what an attacker is targeting.

Re: Python malware on the rise

#46

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

I do not see Powershell in there either, and we are aware of the exponential growth of the language for writing malware.

Re: Python malware on the rise

#47

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 n…

Interviewed someone last night for my podcast who has written some python malware tools, and there's enough stuff out there to where you can't exactly call it a new concept.

Link? :-)

Re: Python malware on the rise

#48
post #47

Earlier quoted context omitted.

Interviewed someone last night for my podcast who has written some python malware tools, and there's enough stuff out there to where you can't exactly call it a new concept.

Link? :-)

From the user's submissions, I would assume https://www.symbolcrash.com/podcast/ (but I don't know if the episode is released yet)

Re: Python malware on the rise

#49
post #21

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

Audit hooks have a different use case. Here, in this article, we see described a way to package up the interpreter as part of the payload. This is very traditional malware, they 'bring their own binary' so to speak.

A much more modern, and statistically far less common approach (say, top 15% of malware), wants to bring less to the system. Instead, they leverage existing mechanisms for execution - some of this is covered in LOLBAS (Living of the Land Binaries and Scripts).

Interpreters such as Powershell, bash, Python, ruby, even perl, are used by attackers to run their payloads.

There are a number of advantages. For one thing, if you're monitoring the system for new binary executions, it'll appear as just a Python interpreter - often quite normal on a number of systems. You also don't need to set any sort of execution rights, or drop executable files - just a regular, plain old python file.

But the downside is now you're using the system's interpreter, and you have to follow the interpreter's rules. Powershell really kicked this approach off since it was a favorite of malware authors, and Python followed suit with this. As a much newer implementation, with 3.8 being an extremely recent release, it's not so surprising that there are bypasses. Still, you'd be surprised how few attackers will take the time to do so (and how few orgs will monitor their Python interpreters anyways).

Re: Python malware on the rise

#50

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 n…

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.

It used to be that malware authors (virus writers in particular) were characteristically more "hardcore" than the average developer, as in preferring native code (even handwritten Asm) and clever optimisations to make their software smaller and more "tricky", for lack of a better term. But that was when it was as a whole not as commercialised, so it's not so surprising to see that aesthetic disappear with increasing commercialisation.

It's the other guy's CPU, after all

...and that might be why malware was initially more optimised than average; it spreads more easily when it's tiny and fast, doing its thing without being noticed, than if it causes a noticeable increase in system load that will prompt further investigation and lead to its discovery.

I wonder when we'll see Electron being used for malware...

Post reply on HN