Is that true, that default deny security solutions can stop the EternalBlue & DoublePulsar attacks?

[AtlBo]

But keep in mind, for true zero days, a Windows patch simply does not exist, and as we all witnessed in the EB/DP attack, there is no guaranty that an anti-exploit can mitigate this attack either.

Must know if this is a reference to the video which was intended to show a test of EMET's capabilities for potentially mitigating such an attack. VS blocked the payload in the video I have seen, but EMET in the same video was 100% not enabled to protect against an attack against LSASS.exe. That application is an IT tool meant to be configured and deployed by a professional according to specific standard requirements. where more serious protection is required. At its defaults it covers very few processes, including these:

Recommended Software.xml: Enables mitigations for Microsoft Internet Explorer, WordPad, applications that are part of the Microsoft Office suite, Adobe Acrobat, Adobe Reader, and Oracle Java.

Popular Software.xml: Enables mitigations for other common applications.

I have a doubt whether EMET 5.5 set to cover lsass.exe would block EB/DP at the memory level, but the original video is not proof that it would not. If there has since been a test where lsass.exe was added to the list of protected processes, OK, the point is valid, and EMET doesn't necessarily at least block EB/DP. Otherwise, the test should be rerun correctly and recorded or claims that point to the notion that EMET could not block EB/DP should stop. JMO.

 

[danb]

Of course it would be better to stop EB, no one has denied that.

But just because EB cannot be stopped, that does not mean that it is acceptable for its payload to load / install its malicious tools.

 

[danb]

Must know if this is a reference to the video which was intended to show a test of EMET's capabilities for potentially mitigating such an attack. VS blocked the payload in the video I have seen, but EMET in the same video was 100% not enabled to protect against an attack against LSASS.exe. That application is an IT tool meant to be configured and deployed by a professional according to specific standard requirements. where more serious protection is required. At its defaults it covers very few processes, including these:



I have a doubt whether EMET 5.5 set to cover lsass.exe would block EB/DP at the memory level, but the original video is not proof that it would not. If there has since been a test where lsass.exe was added to the list of protected processes, OK, the point is valid, and EMET doesn't necessarily at least block EB/DP. Otherwise, the test should be rerun correctly and recorded or claims that point to the notion that EMET could not block EB/DP should stop. JMO.

That is the cool thing about testing and making a video... if someone has a recommendation on how to improve the test, you can retest and see the result. Having said that, if you look at any of the AV test lab results, they usually state that all the software is tested in default settings, unless the vendor recommends specific settings.

But I do appreciate your point... EMET is designed to be configured properly. But then again, if it would just protect all system processes like VS out of the box, it would not have that problem, right? .

I believe I reran the EMET test with lsass protected, and I believe it was the same result. I really do not remember, but I could test it again, it would only take a few minutes. I think a few people mentioned that if EMET protected lsass, there might be some system stability issues.

 

[Deleted member 178]

Sure, you can replace DP with a different payload, but there is a heck of a chance it will be blocked as well.

DP wasn't blocked to install, because it was run at kernel level, it was the reverse-TCP connection it tried to create which is blocked. important difference.

But if DP is blocked from performing its one objective, what makes you think for a second that a different payload would not have the same result?

DP objective is just to inject code into a process (No home user security product could stop that. ) and then spawn another process for various task.
However based on how the spawned process is and used , security softs may stop it as VS/ERP did.
dont mix DP and the process it creates. they are different things.

But just because EB cannot be stopped, that does not mean that it is acceptable for its payload to load / install its malicious tools.

it doesn't matter Dan, who cares of the further stages if the fist one is successful. In a security point of view, once the first stage of an attack is successful , better reformat; i don't waste my time blocking the rest.
No way i let my system with a breach even if the breach was contained to some level.

Compromised system = system owned = i dont live with a system owned. period.

 

[danb]

Did VS stop the breach / data exfiltration? Was the attacker able to steal the "YummyChicken" recipe?

 

[Deleted member 178]

Did VS stop the breach / data exfiltration? Was the attacker able to steal the "YummyChicken" recipe?

data exfiltration, yes VS did ( the breach is EB), i never denied this, did VS stop DP to inject code into lsass.exe? no and that was the DP first action: inject code into lsass.exe > code force lsass.exe to create a task which is to make a connection to the attacker.
VS blocked the task , not the code injection.
now let say VS is disabled by the user for any reason, the connection will complete.

no home user application control can block the code injection. period !

and i i say doesn't matter the connection is blocked, what matter is that was EB was bocked ? no , some this is THE breach, and what come after is pointless to debate. reformat is the only way, that is it.

 

[danb]

data exfiltration, yes VS did ( the breach is EB), i never denied this, did VS stop DP to inject code into lsass.exe? no and that was the DP first action: inject code > code create a task to make a connection to the attacker.
VS blocked the task , not the code injection.
now let say VS is disabled by the user for any reason, the connection will complete.

no application control can block the code injection.

I was always under the impression that a breach is when data is exfiltrated, or some other damage is caused by an attack.

"A data breach is an incident in which sensitive, protected or confidential data has potentially been viewed, stolen or used by an individual unauthorized to do so. Data breaches may involve personal health information (PHI), personally identifiable information (PII), trade secrets or intellectual property."

What is data breach? - Definition from WhatIs.com

But the good news is, we now finally agree!!!

VS stopped this "thingy".

 

[Deleted member 178]

I was always under the impression that a breach is when data is exfiltrated, or some other damage is caused by an attack.

"A data breach is an incident in which sensitive, protected or confidential data has potentially been viewed, stolen or used by an individual unauthorized to do so. Data breaches may involve personal health information (PHI), personally identifiable information (PII), trade secrets or intellectual property."

What is data breach? - Definition from WhatIs.com

But the good news is, we now finally agree!!!

VS stopped this "thingy".

can you stop playing on words , you quoted DATA breach, not SYSTEM breach. we talk about SYSTEM breach (aka EB and DP) not DATA breach (which in our case is an attacker collecting datas via the reverse-TCP connection).
yes VS blocked ONLY the DATA breach, not SYSTEM breach. you can't say because product X blocked DATA breach , that the SYSTEM breach is nullified and everything is fine !

Does blocking a keylogger to call home means the keylogger disappeared from the system? HELL NO ! Come on gimme a break !

If you are happy to live with a SYSTEM breach, good for you , but not me !

so VS statement is " guys we have system breach, but everything is Ok, because our datas are not collected, keep going, no need to worry , we are good !"

That is your point? seriously?

 

[AtlBo]

I believe I reran the EMET test with lsass protected, and I believe it was the same result. I really do not remember, but I could test it again, it would only take a few minutes. I think a few people mentioned that if EMET protected lsass, there might be some system stability issues.

I've had it protected for I believe over a year on W7 with no issues to date (see Event Viewer pic below dated January after a clean installation of Windows 7). Don't know if there could be some issues that I don't know about, but I use the PC for just about everything. All the mitigations I am using for Windows 7 were tested and have been on at least since January, except a few new ones that have been added like Windscribe. In the larger pic, you can see all the mitigations I have added to the defaults. I had to back off of some specific protections for applications/Windows to function properly. The fresh installation in January followed an installation where EMET was installed and a number of Windows processes covered. I believe lsass.exe was one of them going back some time.

It was you who thought it would be brilliant to test EMET on W7. Noone asked you to volunteer to test to see how it would perform against EB/DP. Personally, I'm not going to volunteer, and I'm not going to hate myself over that. I have too much respect for the scientific method to jump into testing of any kind. Then again, I don't own a security software company. If I did I would be interested to at least know. I mean I'm interested and I don't even own a company. That said, I know you are probably correct to state that it probably wouldn't block the exploit. Still, it would drive me bonkers to find out if I did own a security company, since W10 wasn't prone to the attack, and it does have the mitigations in place. For me, it wouldn't be a comparison of applications, just a test for knowledge sake.

At any rate, it's not prudent for anyone to use that video as justification for the claim that EMET's mitigations would not work. To make that claim honorably, lsass.exe would have to configured in EMET so that Windows would still function and then would have to be tested for a time to make sure as I did to set it up on this PC. Then the test could be run. Or you could just use the settings in the pic and see if they work for you in a VM.

Not asking for a retest. Just saying that it's not noble to overstate claims about what products can't protect that haven't been tested in a fair and genuine way. OOB settings may be justified for some. In this case, that's not what EMET is. BTW, is your product "Always ON" OOB? If I recall it was tested in the Always on state. Not that it wouldn't have worked anyway. I don't know. I do know what anyone using the free MS app EMET will have to go through to configure it successfully. I did that myself.

Overall, VS is not going to need mitigations to be a successful enterprise, even for the long term. Not sure I understand why "it does what it does" isn't good enough a way to think of the program. I mean, AI is getting better or seems to be. It's blocking ransomware. So it doesn't block low level memory exploitation. Does it have to be the tool for that?

 

[danb]

can you stop playing on words , you quoted DATA breach, not SYSTEM breach. we talk about SYSTEM breach (aka EB and DP) not DATA breach (attacker collecting datas via reverse-TCP connection).
yes VS blocked DATA breach, not SYSTEM breach. you can't say because product X blocked DATA breach , that the SYSTEM breach is nullified and everything is fine ! come on gimme a break !

If you are happy to live with a SYSTEM breach, good for you , but not me !

so VS statement is " guys we have system breach, but everything is Ok, because our datas are not collected, keep going, no need to worry ! "

That is your point? seriously?

I cannot seem to find a definition for "cybersecurity system breach"... all the ones I am finding point to a data breach.

If you can find a great definition for "cybersecurity system breach", please post it.

You said "If you are happy to live with a SYSTEM breach, good for you , but not me !".

Umbra, EB was not blocked either way. But that does not mean that it is not vital to stop DP from loading its malicious tools, and finishing the data breach. Keep in mind... DP was an NSA hacking tool that they used to spy on citizens, which included a large tool set, which VS blocked. I know I have mentioned this before, but I think it was important to bring this up again.

In this tool set, there is a command named "Download", and it allows you to exfiltrate data from the target machine to the attacker machine. Since VS blocked the complete tool set, it completely blocked access to the Download tool and all of the other tools.

That tool set could have included an "Encrypt" command as well, which would have been the worst ransomware attack in history... which VS would have blocked, since it blocked DP's tool set.

 

[Deleted member 178]

I cannot seem to find a definition for "cybersecurity system breach"... all the ones I am finding point to a data breach.

If you can find a great definition for "cybersecurity system breach", please post it.

Are you kidding me ? stop playing words games with me.

A system breach is when a system was compromised by an attack , the attack being a malware, exploit, etc...
Spotting a system breach takes defensive and offensive strategies

This all you can do to to contradict me, really? even a noob can understand that.

You said "If you are happy to live with a SYSTEM breach, good for you , but not me !".
Umbra, EB was not blocked either way. But that does not mean that it is not vital to stop DP from loading its malicious tools, and finishing the data breach. Keep in mind... DP was an NSA hacking tool that they used to spy on citizens, which included a large tool set, which VS blocked. I know I have mentioned this before, but I think it was important to bring this up again.

Again i dont care of the other stages, if first one is successful (which is EB).
If you can't stop EB , you won't stop its variations which may directly do nasty stuff without the need of DP or a reverse connection, got it ?

Stop trying to make VS look better that it is, it is so obvious than it is hilarious and pathethic...
VS is good at what it does, which it is not stopping kernel exploit and in-memory attacks. So just live with it , instead of pushing this debate to a nonsense .

 

[danb]

It was you who thought it would be brilliant to test EMET on W7. Noone asked you to volunteer to test to see how it would perform against EB/DP.

Hehehe, dude, I hate to do this to you, but here you go...

AltBo said: I'd love to see a test of EMET against EB/DP if anyone finds time for one.

EMET 5.5 and Eternal Blue/Double Pulsar

And here is my response: EMET 5.5 and Eternal Blue/Double Pulsar

So it turns out, you are the one who requested the test, and I thought it would be a great idea to run the test, that way I could show some of the hacker tools in action, like the Download tool, without it making it appear that I was picking on a competitor. If I would have stolen the YummyChicken recipe when testing one of the other products, it would have looked like I was just rubbing salt in the wound. That was the whole purpose of the test, and I even stated that before I even ran the test... it allowed me to demonstrate some of the hacker tools without making it look like I was picking on a competitor.

I cannot remember if I tested EMET with lsass protected or not, but I would be happy to retest if anyone wants me to.

Keep in mind, a lot of security vendors jumped on the WannaCry bandwagon, and exploited this unfortunate outbreak by including marketing claims about WannaCry on their website (and other places like advertisements)... all for a quick buck. VS did not do this. VS does what it says it does. Nothing more, nothing less.

 

[danb]

Are you kidding me ? stop playing words games with me.

A system breach is when a system was compromised by an attack , the attack being a malware, exploit, etc...
Spotting a system breach takes defensive and offensive strategies

This all you can do to to contradict me, really? even a noob can understand that.


Again i dont care of the other stages, if first one is successful (which is EB).
If you can't stop EB , you won't stop its variations which may directly do nasty stuff without the need of DP or a reverse connection, got it ?

Stop trying to make VS look better that it is, it is so obvious than it is hilarious and pathethic...
VS is good at what it does, which it is not stopping kernel exploit and in-memory attacks. So just live with it , instead of pushing this debate to a nonsense .

I was simply asking for a definition of "cybersecurity system breach", because I am not familiar with that term, so I wanted to see the definition to ensure that I use it correctly in the future. Anyway, the link you provided did not offer a definition of "cybersecurity system breach", so I will continue to look for one, so I will know exactly what it means. If you find a definition first, please let me know!

Everyone understands that VS blocked DP hacker tools, which was the entire objective of the EB / DP attack.

I find it very difficult to believe that you do not think it is vital to stop the data breach... but I have no choice but to take you at your word.

 

[AtlBo]

You are the one who requested the test, and I thought it would be a great idea to run the test, that way I could show some of the hacker tools in action, like the Download tool, without it making it appear that I was picking on a competitor.

Yes, but that wasn't my point. I wasn't asking you to volunteer or anyone else. I was checking to see if someone was as interested in whether EMET contained the same mitigations that blocked EB/DP in W10 (if it was mitigations...don't think anyone knew at the time what stopped EB/DP in W10). I thought someone might be interested in that kind of test who hadn't thought of the angle. Noone thinks of testing EMET, but it seemed to me like maybe here was finally a good reason. None of that was directed at anyone in particular.

Anyway, the crux of my point is, you didn't even test EMET's mitigations AT ALL. You would have had to do as I mentioned above to have protected lsass.exe with EMET. Your video test proved nothing. Also, let's face the facts. At least two people, including myself have explained that you didn't test EB/DP against EMET with lsass.exe protected. O/C I was especially interested considering I had been protecting lsass.exe for probably a year prior to the attack. I'm still interested.

I wouldn't ask anyone to test. Rarely would I bring up an idea for a test, but this one seemed to me too good to pass on. I was super curious to know if anyone was interested as I was to see if the mitigations in EMET (some in 10 at the time too), may have been what protected W10. For me, that seemed like a worthwhile thing to see for knowledge sake. Then again, testing is difficult and dangerous on a number of levels. Yet I am o/c well aware I that there are testers here, and sometimes I ask them if they have considered an angle on a test that I think might interest them to consider. Only if I think they might find value in the test.

Obviously, in no way do I ever expect anyone to see it my way about what to test who actually do the work. Of course not. So, the original "I'd love to see" statement I made was only a pointer to a different way of thinking about testing EB/DP. I don't consider that a request in the context it was intended.

All said, If you want to test this for your own reasons do it. If there isn't anything in it for you, don't. I'm not going to hold that against anyone ever.

 

[danb]

I have too much respect for the scientific method to jump into testing of any kind.

Since we are on the topic, it might be a good time to mention my experience with the scientific method.

I have a B.S. in a scientific / engineering discipline from the University of Kansas, and I have a Masters (M.S.) degree as well.

When I finished college, I worked in three different labs for around 5 years, where I gained tons of experience with testing practices and the scientific method.

That is why I feel completely comfortable running tests… I am well trained with the scientific method.

Keep in mind… it is not a valid argument to say “the test that Dan performed is invalid”. Simply tell me what I need to do to improve the validity of the test, and I will retest. This actually happened for a couple of the tests a couple of weeks ago. Because of my respect for the scientific method, I do not mind retesting, if someone can make a suggestion on how I can improve the test.

So people should not say “that is an invalid test”. People should say, “Dan, how about you make this adjustment, and then retest.” And since it is easy to create a video, it all works out pretty well.

 

[danb]

Yes, but that wasn't my point. I wasn't asking you to volunteer or anyone else. I was checking to see if someone was as interested in whether EMET contained the same mitigations that blocked EB/DP in W10 (if it was mitigations...don't think anyone knew at the time what stopped EB/DP in W10). I thought someone might be interested in that kind of test who hadn't thought of the angle. Noone thinks of testing EMET, but it seemed to me like maybe here was finally a good reason. None of that was directed at anyone in particular.

Anyway, the crux of my point is, you didn't even test EMET's mitigations AT ALL. You would have had to do as I mentioned above to have protected lsass.exe with EMET. Your video test proved nothing. Also, let's face the facts. At least two people, including myself have explained that you didn't test EB/DP against EMET with lsass.exe protected. O/C I was especially interested considering I had been protecting lsass.exe for probably a year prior to the attack. I'm still interested.

I wouldn't ask anyone to test. Rarely would I bring up an idea for a test, but this one seemed to me too good to pass on. I was super curious to know if anyone was interested as I was to see if the mitigations in EMET (some in 10 at the time too), may have been what protected W10. For me, that seemed like a worthwhile thing to see for knowledge sake. Then again, testing is difficult and dangerous on a number of levels. Yet I am o/c well aware I that there are testers here, and sometimes I ask them if they have considered an angle on a test that I think might interest them to consider. Only if I think they might find value in the test.

Obviously, in no way do I ever expect anyone to see it my way about what to test who actually do the work. Of course not. So, the original "I'd love to see" statement I made was only a pointer to a different way of thinking about testing EB/DP. I don't consider that a request in the context it was intended.

All said, If you want to test this for your own reasons do it. If there isn't anything in it for you, don't. I'm not going to hold that against anyone ever.

The problem is that a lot of people install EMET and are not aware that they have to change the settings in order for it to do what they want it to do.

But that was not the point of my test... I just wanted to run the test so I could demonstrate some of DP's tools. We can retest, just tell me exactly how you want me to configure EMET, and I will retest. Problem solved.

 

[danb]

And not only that... but how many people protected lsass.exe with EMET when EB was a zero day?

 

[Deleted member 178]

I was simply asking for a definition of "cybersecurity system breach", because I am not familiar with that term, so I wanted to see the definition to ensure that I use it correctly in the future. Anyway, the link you provided did not offer a definition of "cybersecurity system breach", so I will continue to look for one, so I will know exactly what it means. If you find a definition first, please let me know!

I told you already, if you can't understand what is a breach...you have to go school again...

Breach = "a gap in a wall, barrier, or defense."
System breach" = breach in the defense of the system, so hard to understand what i meant ?

You preferred i use "System security breach" or "system compromised" instead , don't tell me you can't associate 2 words together so i have to write the full sentence...? i dont think so...

Everyone understands that VS blocked DP hacker tools, which was the entire objective of the EB / DP attack.

yes only the hacker's tools availability, i never denied this, i said it from the very start.
but the EB attack still succeeded, DP is still installed by EB, DP is still injecting code into lsass.exe (unlike what you pretended before ),
I am satisfied you finally understand now what VS exactly did.

I find it very difficult to believe that you do not think it is vital to stop the data breach... but I have no choice but to take you at your word.

blocking a data breach is useless if the system is breached from the start, your blocking will be potentially defeated in some point later.
I do all i can to prevent my system to be compromised in the first place.
No SYSTEM breach = no DATA breach. period.
if i'm compromised , i reformat. period.

We use anti-exe/SRP to prevent droppers to execute malicious payload, if we block the dropper to execute the payload, why should we care what the payload will do?
That is the whole point of what i say. Blocking the first stage is vital, the rest become pointless if you block it.
If you can't block the first stage , you have to rethink you security setup and your own behavior.

 

[danb]

I told you already, if you can't understand what is a breach...you have to go school again...

Breach = "a gap in a wall, barrier, or defense."
System breach" = breach in the defense of the system, so hard to understand what i meant ?

You preferred i use "System security breach" or "system compromised" instead , don't tell me you can't associate 2 words together so i have to write the full sentence...? i dont think so...


yes only the hacker's tools availability, i never denied this, i said it from the very start.
but the EB attack still succeeded, DP is still installed by EB, DP is still injecting code into lsass.exe (unlike what you pretended before ),
I am satisfied you finally understand now what VS exactly did.



blocking a data breach is useless if the system is breached from the start, your blocking will be potentially defeated in some point later.
I do all i can to prevent my system to be compromised in the first place.
No SYSTEM breach = no DATA breach. period.
if i'm compromised , i reformat. period.

We use anti-exe/SRP to prevent droppers to execute malicious payload, if we block the dropper to execute the payload, why should we care what the payload will do?
That is the whole point of what i say. Blocking the first stage is vital, the rest become pointless i you block it.

I have known from the beginning that VS blocked DP's malicious tools... this information was provided in the empirical evidence the moment I ran the test.

I agree, it would be even better to block EB in the first place... but when EB was a true zero day, pretty much nothing blocked it. Even today, very few security products block EB. But for me, blocking DP's malicious hacker tools is better than not blocking them... that way, you can at least prevent the data breach.

 

[Deleted member 178]

The problem is that a lot of people install EMET and are not aware that they have to change the settings in order for it to do what they want it to do.

in EMET all 3 protections must be enabled and the list of apps properly edited. EMET is like the SRP of memory.
Those users you mentioned are noobs trying to play with what they can't understand. so obviously they fail.