SMB.Attack.Bruteforce

[itman 1,659]

Taking a different approach, let's review what Eset considers a brute force attack:

Quote

Brute-force attack protection blocks password-guessing attacks for RDP and SMB services. A brute-force attack is a method of discovering a targeted password by systematically trying all possible combinations of letters, numbers, and symbols. To configure the Brute-force attack protection, in the main program window, click Setup > Advanced setup (F5) > Network protection > Network attack protection > Brute-force attack protection.

Enable Brute-force attack protection – ESET Endpoint Security inspects network traffic content and blocks the attempts of password-guessing attacks.

https://forum.eset.com/topic/30860-smbattackbruteforce/

Next, let's review the Eset default rules in regards to brute force attacks:

Quote

Managing Brute-force attack protection rules

 

https://help.eset.com/ees/9/en-US/idh_config_epfw_brute_force_attack_protection.html?idh_config_epfw_brute_force_attack_rules.html

Notice that the logon "Max. attempts" setting in regards to SMB brute force attack is 3.

Next, refer to the last log screen shot posted. The vast majority of Occurrences show a count of 1.  This for me would be indicative of a user on the local network trying to access another device; perhaps by mistake. The log instance with a count of 41, which is the only instance greater than 7, would be more indicative of a malicious brute force attack.

As @Marcos has repeatedly requested, you need to determine the source of this user account, svk\dkpdkk, and the local user associated with it. Then interrogate that user as to his network access activities.

Edited March 5, 2022 by itman

[itman 1,659]

On 3/5/2022 at 9:38 AM, itman said:

you need to determine the source of this user account, svk\dkpdkk, and the local user associated with it.

Elaborating, log onto the device associated with IP address, 172.17.5.68. If this user account, svk\dkpdkk, cannot be determined to be associated with a valid user, delete the account, which I assume to be named svk.

 

Edited March 6, 2022 by itman

[itman 1,659]

I again draw reference to this screen shot: https://forum.eset.com/topic/30860-smbattackbruteforce/?do=findComment&comment=147595 . Note the "NTLMSSP_AUTH" references.

This article may be of interest:

Quote

What is old is new again: The Relay Attack

The NTLM (NT Lan Manager) relay attack is a well-known attack method that has been around for many years. Anybody with access to a network is able to trick a victim, intercept NTLM authentication attempts, relay them and gain unauthorized access to resources. This attack is widely used in penetration testing and red team exercises alike to gain an initial foothold in Active Directory environments in a few short minutes.

A number of patches were released, and too much time has passed since the first days of the protocol. With the added security mechanisms in signed NTLMv2 and with the implementation of Kerberos, this attack seemed a thing of the past. However, it’s pretty much still relevant in organizations with AD environments. Why? Because most of them still use NTLM for authentication, either NTLMv1 or unsigned NTLMv2, especially in support of backward compatibility. Furthermore, newly revealed vulnerabilities continuously increase the attack vectors and make the technique more attractive again. For example, during the last year a couple of vulnerabilities were reported by Preempt (here and here) that create the ability to bypass some security measurements in the protocol like the SMB session signing (CVE-2019-1019) or the Message Integrity Code.

https://www.secureauth.com/blog/what-is-old-is-new-again-the-relay-attack/

-EDIT- If IP address, 172.17.5.69, is an AD domain controller, this would pretty much cinch that you are being subjected to a relay attack.

Plus, the source of the attack is originating from the device associated with IP address, 172.17.5.68. Assume this device is compromised; possibly a backdoor installed, allowing the attacker remote access to it.

Edited March 6, 2022 by itman

[peteyt 393]

As mentioned is your windows update up to date as stuff suggests that it isn't. As Itman mentioned, Eset will block attacks that try to use vulnerabilities, but to actually properly prevent them, you need to make sure you are fully patched.

Please confirm this

[itman 1,659]

Another article in regards to a recent NTLM Relay attack:

Quote

Microsoft warns of credential-stealing NTLM relay attacks against Windows domain controllers

Microsoft is sounding an alert about a threat against Windows domain controllers that would allow attackers to capture NTLM (NT LAN Manager) credentials and certificates. In an advisory released last Friday, the company warned of an attack dubbed PetitPotam, which could be used against Windows domains controllers and other Windows servers.

Most versions of Windows server are affected by this flaw, including 2005, 2008, 2008 R2, 2012, 2012 R2, 2016 and 2019. In a support document, Microsoft explained that your organization is potentially vulnerable to PetitPotam if NTLM authentication is enabled on your domain and you use Active Directory Certificate Services (AD CS) with Certificate Authority Web Enrollment or Certificate Enrollment Web Service. If you fit that category, Microsoft offers a few recommendations.

The preferred solution is to disable NTLM authentication on your Windows domain, a process you can implement by following the steps described on this Microsoft network security page.

If you can’t disable NTLM on your domain due to compatibility reasons, Microsoft suggests disabling it on any AD CS Servers in your domain, which you can do through Group Policy. If necessary, you can add exceptions to this policy. Alternatively, disable NTLM for Internet Information Services (IIS) on AD CS Servers in your domain that run Certificate Authority Web Enrollment or Certificate Enrollment Web Service services.

https://www.techrepublic.com/article/microsoft-warns-of-credential-stealing-ntlm-relay-attacks-against-windows-domain-controllers/

Also of importance:

Quote

To prevent NTLM Relay Attacks on networks with NTLM enabled, domain administrators must ensure that services that permit NTLM authentication make use of protections such as Extended Protection for Authentication (EPA) or signing features such as SMB signing,

It is also noted that Eset has an IDS mitigation, disabled by default, to enforce the above:

 

Edited March 6, 2022 by itman

[Paneliya Mehulkumar 0]

On 3/5/2022 at 5:44 PM, Marcos said:

Asking again, what is the account svk\dkpdkk which is performing the brute-force attack?

it' it admin account and we already disable it before collecting the last logs.

[itman 1,659]

10 hours ago, Paneliya Mehulkumar said:

it' it admin account and we already disable it before collecting the last logs.

Did the Eset SMB brute force alerts stop after this account was disabled?

[Paneliya Mehulkumar 0]

2 minutes ago, itman said:

Did the Eset SMB brute force alerts stop after this account was disabled?

No

[peteyt 393]

33 minutes ago, Paneliya Mehulkumar said:

No

Can you confirm your windows is up to date with latest Windows updates and patches? This has been mentioned a few times but didn't see any replies so apologies if it has been answered

[itman 1,659]

Quote

If IP address, 172.17.5.69, is an AD domain controller, this would pretty much cinch that you are being subjected to a relay attack

Is the above true? That is 172.17.5.69, is an AD domain controller.

Edited March 7, 2022 by itman

[kemot 0]

Hello.

Try this - it solved same issue for me.

SMB.Attack.Bruteforce for me was shared printer, and "attacks" was every 15min checking printer connection from other PC which had this printer added by share.

As soon as we removed the shared printer - the problem ceased to occur. 

[kemot 0]

1 hour ago, kemot said:

Hello.

Try this - it solved same issue for me.

SMB.Attack.Bruteforce for me was shared printer, and "attacks" was every 15min checking printer connection from other PC which had this printer added by share.

As soon as we removed the shared printer - the problem ceased to occur. 

ps. I forgot to mention that driver of shared printer need to be removed too, on pc which is "attacking".