Excel macro testing

See here for this Excel macro bypassing SRP:
http://ssj100.fullsubject.com/t313-bypassing-srp#2507

See here for some information on the modified Excel Macro (digitally signed and able to run PE executable code directly in memory):
http://ssj100.fullsubject.com/t313p45-bypassing-srp#2639

In the next post, I'll be doing some testing against various anti-malware mechanisms.

Windows XP, SP3, 32-bit:

1. SRP (setup as described here: http://www.mechbgon.com/srp/ ): BYPASSED
This (modified) POC should bypass AppLocker on Windows 7 Ultimate too.

2. Faronics Anti-Executable 2: BYPASSED
Finally the indomitable Faronics Anti-Executable 2 is bypassed! This is even on highest settings with everything checked.

3. COMODO Internet Security Premium 5.0.163652.1142 (default configuration): BYPASSED
Even when I disable the sandbox and set Defense+ to "Paranoid Mode", it is completely bypassed - "cmd.exe" and "regedit.exe" (completely foreign code) are happily running with no alerts from COMODO.

4. Online Armor Premium 4.5.1.431 (default configuration): BYPASSED
Not a peep from Online Armor.

5. Malware Defender 2.7.2.0001 (default configuration): BYPASSED
To be honest, I'm really not sure what configurations can be applied to block this Macro running PE executable code inside the memory of a trusted process. Anyone have any ideas from a Classical HIPS point of view?

6. Sandboxie 3.50: CONTAINED
Our first success comes from none other than Sandboxie! Both processes ("cmd.exe" and "regedit.exe") are confirmed sandboxed by this:

And sure enough, terminating (or deleting) the sandbox results in the processes being stopped dead and/or wiped.
Just a note that Sandboxie's start/run restrictions are bypassed here, which is not surprising given the results above!

7. DefenseWall 3.09: CONTAINED
Clicking on the "Stop Attack" button terminates the foreign code. Everything appears to run "Untrusted". Another success!

8. GeSWall 2.9.1 Professional: CONTAINED
Everything appears to run "Isolated". Clicking on the "Terminate" button stops everything cold.

9. Returnil Virtual System 2011 Version 3.2.10857.5462-REL7: BYPASSED
The anti-execution component of Returnil, which performed well against the DLL exploits, unfortunately fails this completely.

10. AppGuard 1.4.7: BYPASSED

11. PE GUARD 2.2.1: BYPASSED

12. Prevx 3.0.5.220: BYPASSED

13. Mamutu 3.0.0.18: BYPASSED

14. BluePoint Security 1.0.50.99: BYPASSED
It's a pity Zero_One no longer visits this forum (or at least he appears not to). This is probably the second or third bypass of BluePoint Security that I've personally come across in the last year or so, and as far as I know, only one of these have been fixed.

15. ProcessGuard 3.500: BYPASSED
I'm not sure why I'm still testing such old and unsupported software, but I'm pretty sure some people still use this. Anyway, bypassed again.

Clearly, the "Trusted Computing" school fails once again. I think we are going to see some more of this really soon.

ssj100 wrote:7. DefenseWall 3.09: CONTAINED
Clicking on the "Stop Attack" button terminates the foreign code. Everything appears to run "Untrusted". Another success!

I have one problem with this result. The tester already knows it's bad code; he/she will always click the "block" or "stop" button. But how would the user know it is an attack? What are the symptoms?
P.S.: Nice MS backdoor mechanism too (the "Current Directory Failure" I mean). I would surely like to see the names and social security numbers of those, who worked on it.

Paul

p2u wrote:Clearly, the "Trusted Computing" school fails once again. I think we are going to see some more of this really soon.

Not too sure - this POC is at least a year old. Although I'm not sure how long it's been publically available.

p2u wrote:

ssj100 wrote:7. DefenseWall 3.09: CONTAINED
Clicking on the "Stop Attack" button terminates the foreign code. Everything appears to run "Untrusted". Another success!

I have one problem with this result. The tester already knows it's bad code; he/she will always click the "block" or "stop" button. But how would the user know it is an attack? What are the symptoms?

Exactly right. But at least the REAL system isn't being (irreversibly) damaged. So for example (presumably), the malware would fail if it tried to delete the C: drive or install a rootkit etc. This is why the result is accurate (in my opinion) - I didn't say it was "blocked". I said it was "contained". However, I suppose logging malware would still generally be able to achieve its goal - for example, I doubt DefenseWall would be able to block a keylogger running purely in memory (and "hidden" inside another process).

Regardless, this is another reason why I prefer Sandboxie - it's so easy to minimise the risk of being logged by malware by terminating/deleting all sandboxes before doing eg. online banking in a fresh sandbox.

p2u wrote:P.S.: Nice MS backdoor mechanism too (the "Current Directory Failure" I mean). I would surely like to see the names and social security numbers of those, who worked on it.

Sorry, I don't understand this.

ssj100 wrote:

p2u wrote:P.S.: Nice MS backdoor mechanism too (the "Current Directory Failure" I mean). I would surely like to see the names and social security numbers of those, who worked on it.

Sorry, I don't understand this.

http://www.binaryplanting.com/
In the beginning, researchers thought, that the .lnk "vulnerability" was only about LoadLibrary calls, but now it turns out that all functions/methods in all languages (including macros, VBScripts, JScripts and shell scripts) that load libraries or launch executables can be a source of binary planting, even if the user has so-called "secure" low privileges. Add to the problem that security providers blindly trust the info they get from the system ("This is really cmd and it's all right, you better believe it"). This brings back memories of the WMF "vulnerability". This cannot be a bug; it's design. but you'll never be able to prove it.
And this brings us to another, more serious problem. It's no longer about just getting malware on our personal computers at home and hopefully cleaning it out of the work station, or about simply reverting the system state to a healthy one. I wonder how long we will be drinking clean water, traveling safely, etc. since so much in our lives depends on computer technology...

Paul

It's okay p2u, we'll be blowing ourselves up in no time, so we won't need to worry anymore haha. Also don't forget about 2012 - the world is ending some time in December of that year right?

More seriously, that WMF "vulnerability" was one of the "best" exploits I've ever read about - the user didn't even need to open the malicious file to get infected. In fact, in some settings, the user didn't even need to browse the file to get infected.

From my testing and experiences, I think virtualisation technology may be the second best line of defense against these malware. The best line of defense is of course a good "security approach" (which includes using the stuff between our ears).

ssj100 wrote:The best line of defense is of course a good "security approach" (which includes using the stuff between our ears).

If you are talking about the ears of those who care and frequent security forums to share experience, then there is still some hope left, yes.

Paul

how about manually sticking excel in comodo sandbox and trying to run it them?

Hi ssj, any chance you could send the poc my way so I can test on my AppLocker setup?

In the case of Returnil, after the AE component is bypassed does the real system gets affected?

languy99 wrote:how about manually sticking excel in comodo sandbox and trying to run it them?

Sure, I'll try that later.

wat0114 wrote:Hi ssj, any chance you could send the poc my way so I can test on my AppLocker setup?

Sure, I'll PM it to you soon. I just tested it myself on Windows 7 Ultimate and AppLocker is bypassed. It's no surprise - there's no way AppLocker (or perhaps any Classical HIPS for that matter) can block this, as it's running executable code within "EXCEL.EXE" (which is of course allowed to run).

Maples wrote:In the case of Returnil, after the AE component is bypassed does the real system gets affected?

I don't think the REAL system would get affected, but it's hard to know, as this is simply a POC - it doesn't try to do anything malicious. But regardless, that's not really the point. The point is that Returnil's "anti-executable" function got bypassed.

I'd just like to make a few quick (theoretical) points here. Some people may say that disabling Macros (or at least having the warning pop-up) is at least some form of mitigation.

While that may be true, consider the following points:
1. What if the user regularly used Macros and decided to allow this to run or had Macros enabled by default?
2. The exploit demonstrated here is a POC. This POC doesn't have to use Macros:
http://ssj100.fullsubject.com/t313p15-bypassing-srp#2522
3. Therefore any program vulnerability could be taken advantage of in this way. And there will be no "Macro warning".

languy99 wrote:how about manually sticking excel in comodo sandbox and trying to run it them?

Okay, I just tested this with the latest CIS (5.3). By running "EXCEL.EXE" as Untrusted in the sandbox, I can't even load the Macro. I don't consider this a pass, as the foreign executable code wasn't directly blocked. All CIS did was prevent the Macro from running in the first place - this is already achieved by default without any security software.

EDIT: got the same issue as above by running "EXCEL.EXE" as Restricted. When I run it as Limited, CIS is bypassed.

ssj100 wrote: I just tested it myself on Windows 7 Ultimate and AppLocker is bypassed. It's no surprise - there's no way AppLocker (or perhaps any Classical HIPS for that matter) can block this, as it's running executable code within "EXCEL.EXE" (which is of course allowed to run).

Hi ssj,

is this actually disabling AppLocker to bypass it, just as it does to SRP? I ran this, enabled Macros (using Excel 2010) and I could launch Regedit and the command line form the spreadsheet, so it seems to be a bypass, I guess, but Applocker still functions normally afterward blocking any unauthorized executables on my machine. Is there something else I'm missing? Thanks in advance.

wat0114 wrote:is this actually disabling AppLocker to bypass it, just as it does to SRP? I ran this, enabled Macros (using Excel 2010) and I could launch Regedit and the command line form the spreadsheet, so it seems to be a bypass, I guess, but Applocker still functions normally afterward blocking any unauthorized executables on my machine. Is there something else I'm missing? Thanks in advance.

This Excel Macro does not disable AppLocker. In fact, this particluar Excel Macro does not disable SRP either (I have a separate one that does, thanks to Didier Stevens).

However, the point is that foreign executable code is launched - this code could be malicious to start with (eg. keylogging), and therefore it would not require any further code that SRP or AppLocker might block.

ssj100 wrote:I'd just like to make a few quick (theoretical) points here. Some people may say that disabling Macros (or at least having the warning pop-up) is at least some form of mitigation.

While that may be true, consider the following points:
1. What if the user regularly used Macros and decided to allow this to run or had Macros enabled by default?
2. The exploit demonstrated here is a POC. This POC doesn't have to use Macros:
http://ssj100.fullsubject.com/t313p15-bypassing-srp#2522
3. Therefore any program vulnerability could be taken advantage of in this way. And there will be no "Macro warning".

A few points on this (highly) theoretical issue:
* Remember that this is a targeted attack. The attacker even knows the exact versions of system modules. I think that in such cases there is NO defense. The attacker will also know what protection you use and will bypass that (no doubt in my mind that it is possible; don't ask me how right now; I would have to use a debugger with Sandboxie, but I don't have the time nor the wish to look for such 'vulnerabilities'.)
* The only one to allow using macros on a workstation would be a KNOWLEDGEABLE administrator. Tolerance should be ZERO in this respect. You know now how to restrict that for limited users through HKLM. [http://support.microsoft.com/kb/910817]
* We've been through this before: blocking access to cmd, regedit, scripting host, runas and the works is done for a reason.

Paul

p2u wrote:* Remember that this is a targeted attack. The attacker even knows the exact versions of system modules.

No, that's not correct (at least I don't think so). There are two different Excel Macros here - one that disables SRP, while one doesn't. The one that doesn't simply runs foreign PE executable code in the memory of a trusted process. The "exact versions of system modules" are not needed.

p2u wrote:I think that in such cases there is NO defense. The attacker will also know what protection you use and will bypass that (no doubt in my mind that it is possible; don't ask me how right now; I would have to use a debugger with Sandboxie, but I don't have the time nor the wish to look for such 'vulnerabilities'.)

Given that it doesn't need to be a targeted attack, this isn't quite right.

p2u wrote:* The only one to allow using macros on a workstation would be a KNOWLEDGEABLE administrator. Tolerance should be ZERO in this respect. You know now how to restrict that for limited users through HKLM. [http://support.microsoft.com/kb/910817]
* We've been through this before: blocking access to cmd, regedit, scripting host, runas and the works is done for a reason.

I'll make sure to remember to ask you (or hire you!) when I need help setting up a workstation.

By the way, with this exploit, cmd and regedit are already built into the Excel macro, so blocking the system's cmd and regedit processes won't prevent an attacker from launching it.

Sorry. I completely mixed up the macro tests.
As a rule you can say:
This is by design. It is not like injecting foreign code into something. The system is supposed to work like this. Macros are supposed to do what is given and the system is supposed to execute that, and there's virtually nothing you can do about it. That's why we have these rules with strict Macro settings. If the admin sets the Macro settings to 'High', then the executables can only run from trusted folders and this exploit won't work. That's about the only defense you have. You can't protect a user from him/herself. Neither can you protect the system from itself.

Paul

No worries, I realise that I didn't explain well exactly which POC I tested.

Regardless of whether it's by design or not, this could be yet another attack vector that could be used against the unsuspecting home user. And if/when the appropriate vulnerability is found in eg. Firefox, Opera, IE, Chrome, this attack vector (which won't have to involve macros) could be used to bypass just about every security software out there.

ssj100 wrote:No worries, I realise that I didn't explain well exactly which POC I tested.

Regardless of whether it's by design or not, this could be yet another attack vector to the unsuspecting home user. And if/when the appropriate vulnerability is found in eg. Firefox, Opera, IE, Chrome, this attack vector (which won't have to involve macros) could be used to bypass just about every security software out there.

I'm very concerned about PowerShell. The problem is that it can't be removed without removing the Service Pack it came with.

Paul

You can block it though right? I'm glad I'm still on Windows XP regardless haha.

ssj100 wrote:You can block it though right?

I disabled EVERYTHING in the Windows components section. But disabling is not the same as removing. When I was on XP, I noticed more than once that stuff that was disabled (services to close ports, for example) was enabled again with every new update and turned my computer back into the dangerous beacon it is by default. The same goes for all of Microsoft's "Trusted" partners; disable javascript in Adobe Reader, for example (a good mitigation for most exploits against that PDF Reader) and it's there again with every udate. Set your Flash Player Settings in the online Flash Manager; as soon as you get an update, you'd better check them again and again. Sick! Same with QuickTime Player, Real Player, all those very popular applications that want to make a buck by exposing the poor user to advertisers, trackers, etc., thus creating the channels for drive-by downloads. That's when I started removing services and applications instead of disabling functionality. That's also why I don't have ANY plugins in my browser; all removed, not disabled. If THEY don't know how to behave with all their Opt-Out schemes, what other choice does one have?

Paul

ssj100 wrote:
This Excel Macro does not disable AppLocker. In fact, this particluar Excel Macro does not disable SRP either (I have a separate one that does, thanks to Didier Stevens).

However, the point is that foreign executable code is launched - this code could be malicious to start with (eg. keylogging), and therefore it would not require any further code that SRP or AppLocker might block.

Okay I see. One thing I'd like to check later today, and maybe you know already, if I restrict cmd.exe and regedit with AppLocker from user accounts, will this poc still launch them? Also, would this Excel poc work if it tried to launch an AppLocker-unauthorized, malicious process such as a keylogger (this one I can't test)? Thanks again, this is an interesting thread.

wat0114 wrote:if I restrict cmd.exe and regedit with AppLocker from user accounts, will this poc still launch them?

I don't see ssj100 on the forum right now, so I'll take the liberty of answering your questions. What I understand from ssj100's description is that the "cmd" and "regedit" that are launched through this exploit have already been built into this Excel macro, so blocking the system's cmd and regedit won't stop them. As a matter of fact, it's enough to indicate "cmd" in the code and the system will search for that in the Current Directory first and map it into memory. If "cmd" is there (may be a renamed keylogger or a rootkit), it will be conveniently launched without delay; no security checks - nothing.

wat0114 wrote:Also, would this Excel poc work if it tried to launch an AppLocker-unauthorized, malicious process such as a keylogger (this one I can't test)?

I'm afraid we have to assume the worst (ANYTHING can launch through similar exploits) since the system does not differentiate between good and bad. If the keylogger you are talking about is built into the Macro, it's safe to assume that the one who launches it will be in big, big trouble.

Paul

p2u wrote:
I don't see ssj100 on the forum right now, so I'll take the liberty of answering your questions. What I understand from ssj100's description is that the "cmd" and "regedit" that are launched through this exploit have already been built into this Excel macro, so blocking the system's cmd and regedit won't stop them. As a matter of fact, it's enough to indicate "cmd" in the code and the system will search for that in the Current Directory first and map it into memory. If "cmd" is there (may be a renamed keylogger or a rootkit), it will be conveniently launched without delay; no security checks - nothing.

This, being built in to the macro, makes sense to me the way you describe it. I remember seeing the cmd console and regedit console come up "looking different" than what I'm used to seeing, and even remember seeing the cmd console with the author's name on it.

I'm afraid we have to assume the worst (ANYTHING can launch through similar exploits) since the system does not differentiate between good and bad. If the keylogger you are talking about is built into the Macro, it's safe to assume that the one who launches it will be in big, big trouble.

Paul

I've got a much better understanding of this now. This certainly does look to be potentially devestating for those who launch it. As ssj alludes to, testing it sandboxed or virualized might be the best and maybe only way to kow if it's safe or not. From my own standpoint, I'd make sure I obtain it from a source I can trust before even thinking about launching it. Thanks for your help