SMB : SMB: User Password Brute-force Attempt

[soporteseguridad]

Hi,

my customer had a problem with this threat. They have a internal app which was failing when palo alto updates changed the action to reset-both. Customer told me that this problem started last 15/06 but i went to the PA updates mails and i didnt see anything about changing the action for this threat (SMB: User Password Brute-force Attempt ID 40004)

In default action we can see alert but PA is doing "reset both"

Whats happening??

[reaper]

did you make sure the rule is set to action 'default'? If it is set to anything else, the default action of the threat will be ignored.

[BPry]

My appologies, I didn't look at the threat-id very close and mistook it for a error that we were having earlier. 

1) Make sure that your Vulnerability Protection Profile isn't changed from the default action.

2) In the meantime you might want to setup a rule that allows the application connection from Trust users to that specific IP address with everything except a Vulnerability Protection Profile to mediate the issue for the time being. If I would have to guess though your Protection Profile is set to something other then default. 

It might be a good idea to have your programmers look at the application though. It sounds like if someone enters in the wrong password then the application is rapidly trying to login without a pre-defined wait period between authentification tries. Unless this is happening everytime a user logs in but I imagine it would be a more pressing issue if they physically could not access the application. 

[soporteseguridad]

Hi,

This is our config:

I dont see what it can be wrong.

[reaper]

Hi

the action of your rule "deny high" is set to 'block' instead of 'default', this will override all default actions and will block every high and critical (even if the default action is alert)

additionally, the 'enable' checkbox for threat exceptions is checked for threat 40004 which means it would need to override the policy action with it's own action. in this case allow

can you make sure that policy has been properly committed and verify the logs the customer is seeing are being interpreted correctly ?

because threat 40004 is set to 'allow' it should be totally ignored and not logged. if you do see this threat in the logs, they may be hitting a different vulnerability profile (the default one maybe?) or the policy may not have been committed properly (try commit force)

hope this helps

[soporteseguridad]

Hi,

The profile they use is IPS_ALERT_ALL. You can see the config above. They changed the action alert fot the threat "SMS Brute force" to allow, because firewall was dropping the packets in a internal app.We dont know why suddenly FW started to detect this threat in a normal traffic. What "SMB BRUTE force" detects), how many tries per time in order to detect it as threat???

[reaper]

I'm not sure what the exact parameters are but this signature should be unchanged since 2010 (check out threatvault )

Maybe some software was updated on the customer's network that caused a certain event to increase in frequency, triggering the signature? you could try setting up a packetcapture to see what is going on exactly

[s.williams1]

How can you setup a packet capture on just that vulnerability threat?

[reaper]

@s.williams1 you can't

packetcapture is enabled|disabled on the profile level

If you create a security policy exclusively for application 'smb' and give it it's own security profile with packetcapture enabled, you'd only capture packets related to smb

[s.williams1]

Are you sure? If I go the Exception area and search for code 40004 I can select packet capture on that one only. 

[reaper]

@s.williams1 you're right! i forgot about the exceptions

enable an exception, enable the pcap, done ! 🙂