GitHub Repository Owners Targeted By Data-Stealing Malware (threatpost.com)

"Phishing emails zeroing in on developers who own Github repositories were infecting victims with malware capable of stealing data through keyloggers and modules that would snag screenshots," writes ThreatPost. An anonymous reader quotes their report: Researchers at Palo Alto Networks this week said that in mid-January, an unknown number of developers were targeted with emails purporting to be job offers. The attachments instead carried malicious .doc files containing an embedded macro. The macro executed a PowerShell command that would grab malware from a command and control site and execute it... [Senior threat researcher Brandon] Levene said it's unknown how widespread the January campaign was or why developers were targeted, but given the vast number of projects hosted on the platform, it would likely be an attractive target for either criminals and nation-state attackers.
Levene said the PowerShell script drops a binary named Dimnie, which has been around since 2014 but before January targeted primarily Russian-speaking targets. Someone who received two different emails said they appeared to be hand-crafted, according to Ars Technica, and referenced data changed that same day. They believe this suggests "a focused campaign explicitly targeting targets perceived as 'high return investments,' such as developers (possibly working on popular/open source projects)."

Comments

Re:Darwin at work, I guess.

[Blade]

Maybe I misread TFA but where does it mention mail agents automatically executing the macros? I assume the mails were hand crafted, to encourage the recipients to open the attachment, and that the mail agents were irrelevant?

Devs

[castus]

The attachments instead carried malicious .doc files containing an embedded macro.

I hope most devs know better than to open a .doc from some stranger on the internet.

Re:Devs

[Blade]

Hope away. I'm sure plenty haven't got a clue.

Re:Devs

[lucasnate1]

I think that it's insane that they have to know it. We are not afraid of opening .txt files, why should something more structured be that different?

Re:Devs

[Anonymous Coward]

We are not afraid of opening .txt files

We are not?

Re:Devs

[Anonymous Coward]

Many trojans were distributed as resume.txt.exe at one point, so you really did have to be afraid of opening ".txt" files since the Windows default at the time would hide the .exe... unless of course you were one of the people who understood the risk. Is this insane? Well yes... Microsoft should've never hid the extension by default. The fault is entirely theirs. Just like how the fault is entirely theirs that a .doc file has a built-in control language easily used to contain a malicious payload.

Simple solution is not to use the programs that execute the malicious code while reading a document, but this falls under 'having to know it' and isn't a good solution for the commons.

Re:Devs

[gatkinso]

As a general rule: I don't open stuff from email, regardless of who sent it.

Re:Devs

[religionofpeas]

But do you open stuff you get somewhere else ? e-mail is just a medium.

Re:Devs

[lucasnate1]

Text documents should not be executed, that's my point.

Re:Devs

[fuzzyfuzzyfungus]

Because one aspect of the 'more structured' is a handy mechanism for executing code on your system if you open it. If text editors habitually executed any shell scripts included in .txt files; we'd be nervous about those as well. Greater complexity is hardly completely safe, since it makes implementation of software capable of opening the file more complex; but that's a comparatively minor difference of degree compared to the difference between files types where automatic execution is a feature and ones where it's a bug.

Re:Devs

[Anonymous Coward]

As a general rule: I don't open stuff from email, regardless of who sent it.

Yes, that's because you don't have a job.

Those of us with actual paying jobs don't have the luxury of not opening e-mail attachments.

Re:Devs

[ctilsie242]

This makes me wonder why we have not moved back to a Harvard architecture for fundamental computing. The #1 way that the bad guys get in is that data gets executed somehow, be it HTML, Flash, or anything winding in documents. Having separate data and code spaces would stop this line of attack cold.

Re:Devs

[Dutch Gun]

When your "data" contains interpreted scripting bytecode, there's not much of a distinction there. A Python interpreter is just "reading" a Python script, right? No execution permissions required, but it can still be dangerous. Ever since document formats like Word, PDF, or even HTML put embedded scripting inside, any document you open could be just as dangerous as an executable file.

Re:Devs

[ctilsie242]

If I have to open an attachment, it goes in a VM with no virtual adapters. If it is a Trojan and craps all over the VM, oh well. I just roll back the snapshot.

Re:Devs

[lucasnate1]

It's more than just scripting code. We can also use emulators to run code of old games WITHOUT having to worry about it somehow downloading things from the internet. The problem is that code in docs is allowed to do way too much.

Re:Devs

[AHuxley]

Well AC how far up a different network can an attachment be looked at without the infection spreading?
Perhaps consider any attachments on a safer computer and see whats in the file before it gets to a computer/network thats vital?
Lots of strange OS exist, lots of different file systems. Some of them should be able to network and display an attachment.

Re:Devs

[AmiMoJo]

To be fair, most people don't understand file extensions and they are a shitty way of determining the content of the file. The problem is, Microsoft hid them and didn't replace them with anything better.

I've had one of these phising emails just now. Had my correct name and address in it. I guess with all the data leakage such things are bound to get and be sold for pennies if you have ever bought anything online. I just wish I had started adding random letters to my address earlier so I could trace the source of the leak.

Re:Devs

[Eravnrekaree]

But then they find a way to break out of the VM

Re:Devs

[Eravnrekaree]

Not really necessary at the CPU level, a good OS can allow you to do a RBAC rule that will block any file from being executed in a user writeable directory. It should be up to the OS to provide a complete security model. The thinking of putting overly complex security models into the CPU is wrong. This is because if a bug slips in its harder to update the CPU. The CPU has basic page functionality, NX bits, privelege levels adn so on that provide the basic tools needed for the OS to implement any security model needed.

Re:Devs

[Eravnrekaree]

The code should go into a sandbox, or not be run at all. A sandbox is an option both OS level, and the interpreter. Running code without that in a DOC file IS nuts. Reducing the kernel attack surface like Chrome has done is one tactic that can be used, using a controller/controllee sandbox. Its not rocket science. Its just plain incompetence to not do this.

Re:Devs

[Eravnrekaree]

It should be pointed out x86-64 has security facilities that are equivalent to a harvard architecture, protection levels, setting pages with read/write/execute bits and so forth, as with the NX bit. The problem here is Word, and the security profiles at the OS level that allow scripts to access the filesystem. A harvard architecture would introduce inefficiencies in memory and bus utilization without giving you anything that you cant get with page tables and privilege levels on

Re:Devs

[Eravnrekaree]

Step one would be to disallow any execution of files in the user writeable directories. But this does not fix the problem of the interpreter. One way might be to develop a RBAC profile or a program with an interpreter like Word, allowing it some access to configuration values it needs, but requiring user confirmation before any other file access, or restricting file access to a certain directory. The problem is differentiating between good accesses such as to a document the User wants to load, and malicious accesses. These problems can also be solved in Word itself by running all scripts in both an interpreter security profile and in a seperate process controlled by OS level RBAC. But with Word, you cant trust it to get this right or to do it at all. Unfortunately warning a user before a file is accessed by Word is imperfect since users tend to ignore such warnings. Running seperate instances of word in each their own sandbox which gives it access to just one document file is another solution to this.

Re:Devs

[dinfinity]

To be fair, most people don't understand file extensions

There is no cure for stupid. I do agree with you that Microsoft has exacerbated it starting with Windows 95 by hiding the file system as much as possible, though.

and they are a shitty way of determining the content of the file.

Extensions are a great way to quickly denote the type of a file. They are portable across all file systems and platforms, short and recognizable by convention, and for the most common files generally unique enough. The fact that 'gif' and 'mp3' are commodity terms nowadays speaks to the power of file extensions.

Don't get me wrong: I'm not saying they are perfect. But they are actually pretty damn effective.

Re:Devs

[Eravnrekaree]

One could use something like RBAC to give interpreter just the permissions they need, something like AppArmor, AppArmor or maybe some kind of solution could probably lock the interpreter out of trying to read a file from the users home directory. Part of the problem is the same file access calls are used by python to both access data it needs and to access the script to run. The interpreter may need to access some data out of the home directory. An interpreter based policy seems to be one of the few ways the problem can be sealed, to tell the interpreter to not execute files in the home directory. Otherwise, the user can be warned before a user directory file is accessed, or a runtime RBAC profile could be generated with access just to the user directory data file the interpreter will need. Unfortunately none of these are really perfect.

Re:Devs

[goose-incarnated]

This makes me wonder why we have not moved back to a Harvard architecture for fundamental computing. The #1 way that the bad guys get in is that data gets executed somehow, be it HTML, Flash, or anything winding in documents. Having separate data and code spaces would stop this line of attack cold.

How would this help email .doc(x) attacks? The malicious code is stored in data memory, the word.exe program executes in executable memory. The word.exe program then interprets the data and does a malicious action.

Seems appropriate.

[Gravis Zero]

If you're still using Windows after everything Microsoft has done, you clearly like the abuse, so this is just one more thing for you suffer through.

Re:Seems appropriate.

[doom]

es, that's what I was thinking: these are carefully crafted attacks against high-value targets... who are still using Microsoft products?

Spam filtering 101...

[Pascoea]

From the link in the article:

From: zayavka@bsme-mos.ru
Subject: question
Hey. I found your software is online. Can you write the code for my project? Terms of reference attached below. The price shall discuss, if you can make. Answer please.

Sorry, that doesn't pass the smell test. It reeks like a phishing attempt. 1) Unsolicited e-mail. 2) Broken English. 3)Request to open attachment. 4)Vague subject. 5) Sketchy e-mail address.

Zero sympathy for people who fell for this. Nerds should know better.

The worst smell of all

[SuperKendall]

No way am I working for someone that still uses Word or sends anything in .doc format.

Really?

[Pope Raymond Lama]

Windows Based GitHub Repository Owners Targeted By Data-Stealing Malware -
Here, I fixed the title for you.

Only if they use Microsoft Windows

[najajomo]

"Phishing emails zeroing in on developers who own Github repositories were infecting victims with malware capable of stealing data through keyloggers and modules that would snag screenshots,"

Read vs. Execute vs. Interpret

[DrYak]

This makes me wonder why we have not moved back to a Harvard architecture {...} Having separate data and code spaces would stop this line of attack cold.

The problem is that the vast amount of modern thing isn't code that is executed as-is on the CPU,
the vast majority of modern apps are written in some high-level extremely abstract language that gets interpreted.

(That includes executable script portion on most web pages and macros embed in nearly every modern format - including docx - with maybe the exception of a few plain boring image formats)

So either you end up with code running in code space that reacts and changes behaviour (interprets scripts) based on data located in the data space.
Or you need to consider nearly everything as code, including .docx files, and only consider data a few.
Like the README file and... huh... that's about it.

(For fuck's sake, even some text/image formats like Post-Script are turing complete).

Libreoffice

[Eravnrekaree]

What about LibreOffice? Does it run code in document files/allow them access to the system?

Prevent Powershell virus with one weird trick

[MrKaos]

Set-ExecutionPolicy AllSigned