Excel macro testing
Page 1 of 3 • Share •
Page 1 of 3 • 1, 2, 3
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.
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.
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
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.
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.
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
Clearly, the "Trusted Computing" school fails once again. I think we are going to see some more of this really soon.
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
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?ssj100 wrote:7. DefenseWall 3.09: CONTAINED
Clicking on the "Stop Attack" button terminates the foreign code. Everything appears to run "Untrusted". Another success!
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- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: Excel macro testing
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:Clearly, the "Trusted Computing" school fails once again. I think we are going to see some more of this really soon.
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).p2u wrote: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?ssj100 wrote:7. DefenseWall 3.09: CONTAINED
Clicking on the "Stop Attack" button terminates the foreign code. Everything appears to run "Untrusted". Another success!
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.
Sorry, I don't understand this.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.
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
http://www.binaryplanting.com/ssj100 wrote:Sorry, I don't understand this.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.
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
p2u- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: Excel macro testing
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).
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).
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
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.ssj100 wrote:The best line of defense is of course a good "security approach" (which includes using the stuff between our ears).

Paul
p2u- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: Excel macro testing
how about manually sticking excel in comodo sandbox and trying to run it them?
languy99- Valued Member
- Posts : 54
Join date : 2010-07-20
Re: Excel macro testing
Hi ssj, any chance you could send the poc my way so I can test on my AppLocker setup?
wat0114- Advanced Member
- Posts : 152
Join date : 2010-05-11
Re: Excel macro testing
In the case of Returnil, after the AE component is bypassed does the real system gets affected?
Maples- New Member
- Posts : 1
Join date : 2010-12-22
Re: Excel macro testing
Sure, I'll try that later.languy99 wrote:how about manually sticking excel in comodo sandbox and trying to run it them?
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).wat0114 wrote:Hi ssj, any chance you could send the poc my way so I can test on my AppLocker setup?
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.Maples wrote:In the case of Returnil, after the AE component is bypassed does the real system gets affected?
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
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".
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".
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
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.languy99 wrote:how about manually sticking excel in comodo sandbox and trying to run it them?
EDIT: got the same issue as above by running "EXCEL.EXE" as Restricted. When I run it as Limited, CIS is bypassed.
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
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- Advanced Member
- Posts : 152
Join date : 2010-05-11
Re: Excel macro testing
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).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.
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.
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
A few points on this (highly) theoretical issue: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".
* 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- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: Excel macro testing
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:* Remember that this is a targeted attack. The attacker even knows the exact versions of system modules.
Given that it doesn't need to be a targeted attack, this isn't quite right.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'.)
I'll make sure to remember to ask you (or hire you!) when I need help setting up a workstation.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.
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.
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
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
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
p2u- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: Excel macro testing
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.
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.
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
I'm very concerned about PowerShell. The problem is that it can't be removed without removing the Service Pack it came with.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.

Paul
p2u- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: Excel macro testing
You can block it though right? I'm glad I'm still on Windows XP regardless haha.
_________________
Sandboxie + LUA + SRP + DEP + SuRun
Windows Firewall + NAT Router + IPSec (on-demand)
VirtualBox (on-demand)
Drive SnapShot (on-demand)
ssj100- Administrator
- Posts : 1389
Join date : 2010-04-14
Re: Excel macro testing
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?ssj100 wrote:You can block it though right?
Paul
p2u- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: Excel macro testing
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- Advanced Member
- Posts : 152
Join date : 2010-05-11
Re: Excel macro testing
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.
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.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)?
Paul
p2u- Valued Member
- Posts : 211
Join date : 2010-12-14
Re: Excel macro testing
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

wat0114- Advanced Member
- Posts : 152
Join date : 2010-05-11
Page 1 of 3 • 1, 2, 3

» DataDriven from Excel in C# with NUnit
» selenium with database testing
» do not run browser, when start selenium testing
» New user extenstion for browser related testing.
» How smartgwt widgets recognize?
» selenium with database testing
» do not run browser, when start selenium testing
» New user extenstion for browser related testing.
» How smartgwt widgets recognize?
Page 1 of 3
Permissions in this forum:
You cannot reply to topics in this forum