I keep getting smb://41.242.56.55/BruteForce connection block messages, anyone know how i can stop this from happening
Thank You Carl
I keep getting smb://41.242.56.55/BruteForce connection block messages, anyone know how i can stop this from happening
Thank You Carl
Hi Carl, post a screenshot.
Also read: https://www.abuseipdb.com/check/41.242.56.55
and here: https://phoenixnap.com/kb/prevent-brute-force-attacks
polonus
@carloshax
Use “Attachments and other options” link under the text box to add screenshot to your message.
Some people do not wish to click on unknown web links to view them as external content.
Hi carloshax,
rocksteady is right here, some folks may frown on the use of url shortener-links for obvious reasons.
Especially as they are given as “live” links.
polonus
Thank you attachment added
Hi Carl, that’s the new Remote Access Shield. Read here: https://forum.avast.com/index.php?topic=235069.0
Hello Carl,
Thanks for the report.
The new version of the Remote Access Shield scans not only incoming RDP connections, but also incoming SMB connections. SMB protocol is another common attack vector.
As polonus posted:
The IP address appears to belong to an attacker that tried to use the open SMB port on your computer (used by Windows to read and write files and perform other service requests to network devices) to gain access to it using a brute force attack - multiple consecutive connections with commonly used login credentials. When Avast detects multiple unsuccessful SMB connections over a period of time, it triggers the brute force attack detection and blocks the IP from future attempts.
Hi All,
I am also getting repeated notices of AVAST blocking a connection from a Samba connection which it identifies as an internal (I think) IPv6 address. For example, in the attached screen shot, the attacks were coming once every second, hundreds of times. This goes on for hours each day. You will see in the snippit that all the attacks were blocked by AVAST, but then at 2:47:39 AVAST “Allowed” a SMB connection from another IPv6 address and the log stops at that time (it is now 5:04 PM). You will also see in the upper right hand corner that the “All” tab lists 4832 attacks, but only 4561 blocked attacks.
Could someone tell me is this some kind of an attack, or is the AVAST Remote Access Shield just recording as a false positive some routine network activity. Thanks.
Read here for instance: https://tsplus.me/ip-addresses/ which local-link addresses should be whitelisted.
But what we want to hear here is an answer from avast team.
polonus
Thanks polonus.
But why would my PC network be using IPv6 local link addresses to communicate with each node in the network? Wouldn’t it be a IPv4 169.254 address? And why would AVAST detect the internal address as a brute force attack and block it? And then permit it? Avast definitely needs to answer because it appears this is an AVAST only issue and doesn’t involve my network.
Hello 4ahobbs,
I don’t know why your PC network uses IPv6 local link addresses to communicate with each node in the network.
Our brute force detection blocks IP addresses that attempt multiple connections unsuccessfully in a short time. Therefore Avast blocked connections from one address (it tried to connect unsuccessfully multiple times - meaning it’s possible it was a brute force attack trying different passwords for example), but didn’t block connections from the other (its connection was successful).
As for why an internal address would be doing this - either this could be a misconfigured device trying to connect with wrong credentials (but in that case it’s strange that it tries so many connections), or it could be infected with malware and trying to gain access to other devices.
It’s likely not an Avast issue - as far as I know, none of the Avast versions attempt multiple SMB connections for any reason. To find out the reason why this is happening, you would need to investigate the device that initiates the connections. And either fix its configuration, ask the device’s manufacturer why this is happening, or, in case it is infected with malware, remove the malware.
If you have any more questions, please feel free to ask them here.
Hi Jakub and Anyone else in the Forum,
In response to your reply–I have two questions:
Is there a way for me to print a log file of these blocked and allowed attacks in the Remote Access Shield? They come every second and from the same IPv6 source and AVAST blocks them. Then a few from come from a different IPv6 source and AVAST allows them. so viewing them as the 12 lines that AVAST displays is not helpful to see a pattern.
I am not familiar with IPv6 addresses. How can I possibly determine which device is initiating these attacks and eliminate it? Are there specialized AV programs which would permit me to determine that (like freefixer etc.).
Thanks.
Hello 4ahobbs,
Inside the log, just search for “SMB”. The individual entries will look like this:
[2020-10-09 10:25:13.779] [info ] [nsf_rdp_mim] [ 4564: 8640] RdpFilterCtx.NewConnection [proto:SMB,ip:[10.187.43.140],port:51041,conn_id:164107]
[2020-10-09 10:25:13.909] [info ] [nsf_rdp_mim] [ 4564: 8640] RdpFilterCtx.ConnectionBlocked [proto:SMB,ip:[10.187.43.140],port:51041,status:[SMB:BruteForce],conn_id:164107]
Here you can find the time, protocol, source IP address and port, connection ID (used to follow the logs related to a single connection), status (reason for blocking the connection).
Another program I’d recommend if you are proficient with packet analysis is Wireshark. It can be set to scan all communication on your port 445 (the SMB port) and you can inspect the packets in its UI. As the username is sent in plaintext during the SMB authentication, you can view it and it might give you some insight into what is causing this. Screenshots of setting up Wireshark and of a captured failed authentication attempt are included.
The provided examples/screenshot use IPv4, but it should be similar when IPv6 is used.
Hi Jakob,
Thanks for the tools, but I am not proficient in packet analysis. I did download my logs and I have hundreds, maybe a thousand, of SMB entries, with the status [SMB:BruteForce] going back to October 26, 2020. The entries run 10 or so a minute. All the blocked entries have a link-local IPv6 address. All of the allowed entries also have a link-local IPv6 address.
I have eight PC’s on my network, and all of them, including the one detecting the Brute Force attack were set to not allow remote connections to this computer. I also have Malwarebytes Premium and that software did not detect any attack.
This leads me to believe that AVAST is giving me false positives from my internal network. Should I send the Avast Remote Access logs to Avast to take a look? Should I disable IPv6 on all the computers in the network? I’m not sure if that will affect anything since I only use IPv4 addresses to my knowledge. Thanks.
Hello 4ahobbs,
It is of course possible that the detections are false positives. It might be different devices than PCs - for example a music/video player that automatically tries to connect to your shared folders using SMB and then lets you play music or videos from your PC.
I’m afraid we won’t be able to tell any more from the logs than you. As I wrote, you can try to find the device from which the connections originate using Avast WiFi Inspector. Then it should be easier to figure out what is going on. You just click WiFi Inspector → Network Scan. When the scan is finished, click a discovered device and it will show you its address.
In case the detections are false positives, we are working on a GUI feature you’ll be able to use. It lets you hide detections from a specified address, as this is a common issue.
Hi Jakub,
I SOLVED the issue, and yes, AVAST is at fault for providing false positives with its latest update. This is for AVAST Program Version 20.9.2437 (build 20.9.5758.615). Here’s a short recap of what we were discussing. Just after an October AVAST update, I started getting second by second notifications from the Remote Access Shield feature that a BruteForce attack was being made. The notifications appeared to be in waves with some being blocked and others allowed, but always a connection attempt going in bursts of seconds, then ceasing after a while, then resuming again. All the IP Addresses were in IPv6 and not IPv4. I’ve never dealt with IPv6 addresses so I could not identify the origin and tell you whether the IP addresses were internal in my network or from the outside. I did tell you that it was unlikely that I was receiving an attack from the outside since all the PC’s on the network had Remote Desktop turned off. What I did to understand what was going on was to download a demo copy of Net Scan Tools Pro and look at the Network Neighbors table. The Network Neighbors table is like an IPv4 ARP cache but for IPv.6. I never knew that. From the Network Neighbors table, I was able to identify the MAC addresses of the IPv6 addresses recorded by AVAST. I then used Angry IP Scanner to identify and correlate the MAC addresses with IPv.4 addresses, which allowed me to identify the sources of the “attacks”. The so-called “attacks” were merely the 5 PC’s on my network coming on and off of the network at different times of the day. This flaw is more annoying than debilitating, but is should be corrected by AVAST. Thanks.
I’ve had the Omni Hub for over a year now and during the past few months I’ve started getting alerts on my desktop about RDP Brute Force threats.
It lists the “URL” as rdp://192.168.0.69/BruteForce. This is the local IP address of the Omni Hub.
Why am I getting this message on my Windows 10 laptop with the IP address of my Omni Hub? I have the Avast Omni application installed on all the machines on my network.
Is this a problem that needs to be fixed? If so, then how do I fix it.
Thanks, Richard
Hi Richard16,
Question here: Is Remote Desktop Service allowed?
The alert could then be because of some form of penetration hacking being performed.
This could be by a botnet, compromised Polycom device or illegal use of a penetration test tool
Students for instance may use this for illegal purposes yes also on Omni Hub:
also read: https://github.com/AzizKpln/Bruter19
So not all detections can be explained away as false positives.
polonus