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
Python malware on the rise
51–60 of 70 posts
Re: Python malware on the rise
#52I 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 "t…
Like all software, you choose the language / platform depending on your business goals. Want it to be hidden for ages and slowly leak data? Write in optimised C to minimise footprint. Quick break in and grab everything? Pick your favourite and fastest language to code in.
Re: Python malware on the rise
#53The 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…
> If you look down further in the article it explores detecting PyInstaller generated executable using simple YARA rules.
Which can be easily patched out with a simple sed rule as it just uses a text search of the binary.
Re: Python malware on the rise
#54The 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.
Re: Python malware on the rise
#55Earlier quoted context omitted.
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)
Yep, planning on editing it tomorrow
It's with Josh Pitts, author of this tool [1] and another payload that caused lots of go projects to be eaten by Kaspersky [2]
Re: Python malware on the rise
#56This 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. Th…
I think your last point and the article's points reflect two different contexts though. One is attacking python software with malicious libraries, while the article's context is python being used to attack any system, even systems that don't have an interpreter installed. That being said, the security of PyPi and python packaging in general is certainly another interesting topic. I like to think that so far it hasn't…
PyPI's architecture isn't meaningfully different than npm's. Npm has seen more high profile incidents because:
1. Packages tend to be smaller, and the transitive dependency trees of projects corresponding larger. This means there are more single points of failure.
2. More people are using it.
Python, and for that matter most language package ecosystems, have the same problems as js, but many of them have gotten away with it for a bit longer due to (lack of) scale.
Re: Python malware on the rise
#57The 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.
Author here. Wasn't my intention to mislead, but I also don't think the article is mistitled. What would have been a better name? This article is about actual Python malware that would affect an endpoint like a remote access trojan (RAT). If the article was about malware within the Python package index, I would have named it "Malicious Python packages within PyPI on the rise!" It could also be a confusing professional domain interlap, as I exist typically within the security world.
Re: Python malware on the rise
#58I 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…
Author here. Thanks for reading & the feedback. I'll try to unpack some of this.
> 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.
This seems like a gross oversimplification & commonly incorrect. Often times a "stage one" vulnerability to gain initial access would be network code written in a high level language such as Python or Ruby (see Metasploit). And an executable payload to interact with the system would be generally written in a compiled language like C or C++. My article is detailing the uncommon rise of interpreted languages (especially Python) being used over the past ~5 years as malware dropped on an endpoint in an attack.
> Just seems like a minor observation, rather than some doom trend.
I wouldn't say this is a minor observation or a "doom trend." I'd say it's a very interesting and insightful observation that is worth keeping an eye on. Malicious actors are no longer operating in a world of slow endpoints and lack of resources. They instead are operating in a world of high-speed internet, very fast endpoints, and have a rich ecosystem of open-source tools at their disposal.
I find it highly interesting that malicious code written in interpreted languages, bundled with their interpreters into an executable, are finding their way into the arsenal of high-tier malicious threat actors over the past few years. Just as the web browser is slowly eating away at the operating system, interpreted languages are slowly eating away at compiled languages in a variety of domains- including malware.
Re: Python malware on the rise
#59[deleted]
Re: Python malware on the rise
#60OT: 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 noticed the same thing and wrote essentially the same comment before I noticed yours. There's also a bit of a peak in Javascript during winter break, which is when some schools do "externships."