For the past three or four days I am suddenly getting “SMB:CVE-2017-0144 [Expl] nsa:cve-2017-0144_EternalBlue” every few minutes on one machine out of the 120 machines I have Avast Business Pro on. All of these alerts reference difference smb IP addresses. I’m running a full scan now on that machine.
Can anyone tell me what this is?
Thanks.
Well thank you.
However, we don’t normally run the Windows firewall on these machines. I think the next step is to disconnect the user’s VPN and see if the alerts still appear. That will tell me whether I can block this on the router.
But really, what avast should do is check to see if the relevant SMB patch is installed on the machine and if it is, then all of these events are essentially false positives and it should stop issuing these alerts every few minutes.
You’re welcome.
That is a highly dangerous idea you have there. The definition of a false positive is NOT whether or not it was prevented. If I launch an EternalBlue exploit attack against a invulnerable host and trip an IPS alert, it’s still a genuine attack. It just happens to be an attack that was prevented. A false positive in this case would be Avast! detecting an attempt to exploit EB when it wasn’t an EB attack. Any kind of hardware firewall on-site (FortiGate, Palo Alto, Checkpoint, etc)?
It’s possible Avast! made a change to their signature and has started detecting solely NULL Authentication sessions (the beginning stage of EB Attack), but I find this unlikely. There are well-established signatures to detect and prevent an EB Exploit. Either way, the device in question should be looked into. If you have 119 devices not saying a damn thing about EB, and one device suddenly starts complaining of EB, something is misconfigured, or the machine is compromised and attempting to move laterally in your network.
PS: I’ve done a lot of SMB reconnaissance in target networks. I’ve never not once seen an AV detect NULL Authentication as an EB exploit, so I doubt it’s that. (I have set off alerts for EternalBlue… but that’s because I’m actually beating the shit out of some poor old server still vulnerable to it.)
No router under my control in this case; the user is working at home. The alerts still occur when not connected to our VPN, so I can’t do anything with our router to block this.
For some reason I can’t turn on the machine’s firewall as local admin; it says it’s under control of our system administrator. I am the system admin and I haven’t done anything globally to turn off the firewall, I don’t think. I may have done some some GPO to stop Win 10 boxes from complaining about the firewall being off, since that’s the only way to stop that in Win 10, but if I did it was long ago and I don’t remember. But this is a Win 7 box. I can’t currently log in to the machine as a DA because I have no cached profile on it and the machine can’t connect to the VPN until I’m logged in. I may be able to execute a PS script to do it via our asset management system.
In any case I’ve suddenly stopped receiving the alerts, though I don’t know if that just has something to do with the time of day. Last one was 2:56 pm EDT yesterday.
BTW—When I purchased the avast Business Pro system I thought I purchased an anti-malware system to block attacks on individual machines by means of email, websites, or external media, not a firewall system to monitor ports and do “perimeter security”. I used to be able to specifically turn off the Avast firewall feature in the 8.x version. Now there’s no way to control it that I can find in the On-Premise Console. I dislike it when vendors change important aspects of the functionality of a product without notifying me and giving me an opportunity to make my own decisions about it.
The fact that Avast was blocking an alleged EternalBlue attack from something that is NOT on the machine every few minutes is not useful information to me, and it is extremely disruptive to the user. (I scanned the machine with Avast, and I hope to God that the Avast scan would actually detect the source of this behavior if it was on the machine, since it’s so annoyingly adept at detecting the behavior when it occurs–in fact I got several of those popups DURING the scan, identical, except for source IP, to those that had been appearing prior to the scan, yet the scan reported no detections when it completed.) Criminals constantly hit random ports attempting to do something nasty; thousands of times a day. I don’t need to hear about it every time they do that. EternalBlue is no better and no worse than any other kind of attack. This strikes me as more of an effort at marketing–whereby Avast announces that it stops EternalBlue–than as something useful.
What Is EternalBlue and Why Is the MS17-010 Exploit Still Relevant?
https://www.avast.com/c-eternalblue
Thank you. I was aware of all of that previously. That article is, of course, Avast marketing. And it clearly says that a successful attack starts by dropping something on the machine. Avast didn’t detect anything on that machine, it was just annoying the user and me with constant alerts of port hits–something it doesn’t do for the vast multitude of other things that also hit ports these days. The machine is patched and the article also says clearly that a patched machine is not in danger from EternalBlue. Therefore, as I said previously, if Avast is going to insist on putting out alerts for this specific kind of port hit, then it should at least stop doing so when it knows the machine is patched. And since Avast can read the registry it can make that determination very easily.
Much of this I guess is because of:
For instance on my relatively new Router there is a USB port, that enables saving of files, etc. on that USB, which can be available to other devices on that network. To be able to do this it used the SMB1 communication that is vulnerable to exploit. Windows 10 actually disables this SMB1 communication. But I guess it doesn’t stop people trying.
Remote Access Shield? I don’t see such a thing in the list of shields in my On-Premise Console (version 7.29.666). Is it only a cloud console thing perhaps?
Hi Dave, I may correct you, Avast detects/blocks it since 2017 - without RAS.
But not the SMB check that has only recently been included (where I didn’t know).
So my confusion lies in that, as a Windows10 Home user I don’t have the OS Remote Connection functionality nor the Remote Access Shield.
RAS is a paid feature, but Avast will still protect you against EternalBlue, even in the free version.
But is it available in the On-Premise Console? I don’t see it there as an option.
Nope, it’s currently only available in the cloud console.
So I realized I had stopped getting alerts because the machine in question was turned off. When the user started it again today I started getting email alerts from the console …for a while. Then they stopped. However, I’m logged in remotely to the machine and the Avast pop-ups are still appearing there.
Looking on the console, there have been no detections reported for almost an hour and a half.
To make it even more mysterious, the console can no longer send email; the test fails. Nothing about the SMTP settings have been changed. The email server is an internal server on my network; nothing about it has changed either and I can still use it to send ordinary email.
I rebooted the console server; no change.
So what’s wrong now?
Oh, this is beautiful.
I realized that the machine in question wasn’t connected to the VPN, so it could not talk to the on-premise console. So I started the VPN on that machine.
I also realized I had five logged-in instances of the console open–apparently, though some of them may have timed out. I closed them all and logged into the console again, where I received two new alerts from the affected machine, a couple minutes apart.
I also received two email alerts of these new detections. I ran the email test in the console after each one, and it STILL failed, both times.
So I have to conclude that the email test is buggy.
Turning on the machine’s firewall has stopped these pop-ups. Since the machine was patched, rendering the port probes ineffective, I contend that these highly annoying alerts are false-positives that Avast could easily prevent by reading the registry or the version number of the relevant .sys file. Because Avast does not do this, I spent several hours of my, and my consultant’s, time to address this. I am not happy.