Malicious MS Office Macro Creator

Evil Clippy is a tool for creating malicious Microsoft Office macros:

At BlackHat Asia we released Evil Clippy, a tool which assists red teamers and security testers in creating malicious MS Office documents. Amongst others, Evil Clippy can hide VBA macros, stomp VBA code (via p-code) and confuse popular macro analysis tools. It runs on Linux, OSX and Windows.

The VBA stomping is the most powerful feature, because it gets around antivirus programs:

VBA stomping abuses a feature which is not officially documented: the undocumented PerformanceCache part of each module stream contains compiled pseudo-code (p-code) for the VBA engine. If the MS Office version specified in the _VBA_PROJECT stream matches the MS Office version of the host program (Word or Excel) then the VBA source code in the module stream is ignored and the p-code is executed instead.

In summary: if we know the version of MS Office of a target system (e.g. Office 2016, 32 bit), we can replace our malicious VBA source code with fake code, while the malicious code will still get executed via p-code. In the meantime, any tool analyzing the VBA source code (such as antivirus) is completely fooled.

Tags: malware, Microsoft, mitigation

Posted on May 8, 2019 at 6:03 AM • 14 Comments

Comments

TimH • May 8, 2019 10:47 AM

I always disable macros for Office and Acrobat.

I understand that spreadsheets can use macros usefully… but why oh why does anyone think its sensible to be able to run code, let alone by default, in documents like Word, PP, PDF which are for reading?

martin • May 8, 2019 11:25 AM

Gotta haz muh features.

Complexity will be the end of us.

Jordan • May 8, 2019 11:33 AM

TimH: Because you have a structured document template where you want to have inputs in one place drive content in another place. Think spreadsheet-like relationships, but flowed into text and with text flowing around it. (By default? Probably not. Read-only? Probably not. But sometimes? Yes.)

AlexT • May 8, 2019 11:50 AM

ok my comment will be brief: wow!!

is there any to disallow this optimisation and for recompile before running any vba?

Drone • May 8, 2019 12:27 PM

@AlexT said: “is there any to disallow this optimisation and for recompile before running any vba?”

Ummm… Linux + Libre Office?

albert • May 8, 2019 1:41 PM

“…If the MS Office version specified in the _VBA_PROJECT stream matches the MS Office version of the host program (Word or Excel) then the VBA source code in the module stream is ignored and the p-code is executed instead. …”

Sounds tailor-made for someone who wants to avoid anti-virus s/w and run their own code. Doesn’t sound like a feature; sounds like a back door.

When VBA first hit the market, I recall a guy who called it Virus Bearing Application, or something similar.

. .. . .. — ….

Denton Scratch • May 9, 2019 4:54 AM

The term “p-code” doesn’t refer to “pseudo-code”. It’s real code. It’s not bogus. There is no sense in which it is “pseudo”.

The term “pseudo-code” refers to any of a number of different notations such as “structured English”, used to quickly sketch out the shape of a program without bothering about the syntactical niceties of any particular language.

The term “p-code” derives from the UCSD Pascal compiler, which compiled down not to machine code, but to a portable interpreted code. This was known as p-code, and could run on any machine for which there was a p-code interpreter (a virtual machine, in effect).

Java works in much the same way; the compiler produces not machine code but “bytecode”, which supposedly runs anywhere where you have a JVM. But UCSD Pascal got there about three decades earlier.

I don’t know whether Microsoft themselves refer to VBA object code as “p-code” or “pseudo-code”; if they do, then they is ignorant. But I suspect the problem is simply that the author of the blackhat article is not a native English speaker (I think he is Dutch), and probably was not born yet when UCSD Pascal was a thing.

albert • May 9, 2019 12:52 PM

@Denton Scratch,

Well stated.

Visual Basic and MS C, used to compile to native code (of the Windows OS). IIRC, MS decided to make VB, C, and C# ‘compile’ to p-code. The purpose was to allow the use of one interpreter for all three languages.

In a sense, all languages that require compiling or some other treatment are “pseudo code”, since they cannot be executed by the OS as entered. VB is tokenized by the editor before it can ‘run’, so it can be executed immediately, or compiled for later use. I’m not sure about other interpreted languages.

I guess the era of converting a language to native code is ending.

. .. . .. — ….

Denton Scratch • May 9, 2019 4:15 PM

@albert

Well, it is a bit moot what is meant by “compiling to native code”. You refer to code than can be executed “by the OS”. That phrase highlights the fact that whatever object code is generated, it will likely depend on some library code that is OS-dependent.

I would generally prefer to think of “native code” as what used to be called machine-code: code that could be executed directly by the hardware, without the help of any extra software. “Native” in that context can be taken to mean that if you are a different design of hardware, then you can’t execute that native code. That is, it’s not a matter of what OS is being considered.

So much of the code we use nowadays comes from libraries, that it really doesn’t matter much whether the rest of it is machine-code or some kind of intermediate code like p-code or bytecode. Also, hardware is so fast, there’s not much advantage in compiling to machine-code (it’s cheaper to just add a few more cores).

Actually, even back in the days of Burroughs COBOL, I was shown how to hack the sixth pass of the compiler (who’s output was a kind of intermediate code) to create programs that couldn’t be expressed in COBOL. You’d then run the seventh pass manually. You could do things like write device drivers in COBOL. Nuts!

A90210 • May 9, 2019 4:37 PM

Is it safe to assume that both iOS & macOS apps (not 3rd party (or non-Apple) apps) are safe from this kind of stuff?

How about Libre Office? Libre Office with macros disabled?

How might, or which, Linux or Linux apps might be at risk?

How about Windows, but not using Microsoft Office?

A90210 • May 9, 2019 5:06 PM

MS Office and OSX

https://cyber-itl.org/2017/01/04/to-upgrade-or-not-a-look-at-office-2016-for-osx.html

“… When we looked at scores for OSX applications, the Microsoft Office 2011 suite was at the bottom of its category, and the accompanying Microsoft AutoUpdate application was at the bottom of the whole OSX environment. Since then we’ve been asked how Office 2016 stacks up in comparison, and it provides an excellent example of hidden benefits of an upgrade, as it has a much better risk profile than the 2011 suite.

Where the 2011 suite was mostly 32 bit files, largely without ASLR, the 2016 had all 64 bit files, all with ASLR. Stack guards are now consistently employed, and function fortification is used in 58% of the files, as compared to 5% before. The main applications (e.g. Word.app, Excel.app, etc.) were at the bottom of the pack in the 2016 suite, meaning that these had not improved by much, but the overall score distributions, which take into account all of the binary applications and the libraries against which they are linked, improved greatly. …”

https://theintercept.com/2016/07/29/a-famed-hacker-is-grading-thousands-of-programs-and-may-revolutionize-software-in-the-process/

“… Things like ASLR [address space layout randomization] and having a nonexecutable stack and heap and stuff like that, those are all determined by how you compiled [the source code],” says Sarah. “Those are the technologies that are really the equivalent of airbags or anti-lock brakes [in cars]. They’re the things that make software better than it used to be.”

Modern compilers of Linux and OS X not only add protective features, they automatically swap out bad functions in code with safer equivalent ones when available. Yet some companies still use old compilers that lack security features.

The lab’s initial research has found that Microsoft’s Office suite for OS X, for example, is missing fundamental security settings because the company is using a decade-old development environment to build it, despite using a modern and secure one to build its own operating system, Mudge says. Industrial control system software, used in critical infrastructure environments like power plants and water treatment facilities, is also primarily compiled on “ancient compilers” that either don’t have modern protective measures or don’t have them turned on by default.

Asked about the findings, a Microsoft spokesperson would only say, “We are focused on security as a core component in the software development process. We developed and are committed to the Security Development Lifecycle, and continue to lead the industry in creating the most secure products across all platforms. …”

Clive Robinson • May 9, 2019 9:03 PM

@ Bruce,

Evil Clippy is a tool for creating malicious Microsoft Office macros

Do you remember a time before the anoying “Microsoft Office paper clip”?

Back when the first known example of a Mirosoft Office macro-virus was actually shipped from Microsoft on their CD’s. But only had a comment as a payload?

Nearly a quater of a century ago back in 1995,

https://www.trendmicro.com/vinfo/us/security/news/cybercrime-and-digital-threats/20-years-of-macro-malware-from-harmless-concept-to-targeted-attacks

Bottomless Feeder • May 10, 2019 6:03 PM

This is a strange article, in my eyes, because these ms macro attacks have been everpresent since the 1990s early days of ms macro-involved “word processing”. It goes back to the days when ms files revealed (if checked by the inquisitive) entire directory trees of the end users, exposing user names, and implied structures of the C:\ drives.

I even tried it myself when an internet penpal of mine emailed me a document and I scanned it, found out their username as appeared on their hard drive, and sent them back a message tipping them off that I knew their system username (which looked a lot like a personal sirname, just like Apple (store) Inc. still tries to do to users today).

This is old news, in a way. Or you could just say that it’s merely Micro$oft still up to it’s old tricks of exploitation and never-ending security holes guaranteed ad nauseum ad infinite.

albert • May 12, 2019 12:06 PM

@Denton Scratch,
Guess I’ve been away too long:)

IIRC, VB relied solely on the MS API set, and if there was an MS API function that wasn’t in the VB set, there was a way you could still use it in your program. I forget the details.

BTW, it was also possible to use assembler in VB (#asm, perhaps?) Crazy? Yes.
I never used it.

. .. . .. — ….

Malicious MS Office Macro Creator

Comments

Leave a comment Cancel reply