I see.  I'm on an older version of OSSEC still (2.8) - do the newer Windows 
decoders pull the user name out in Phase 2?

It might be difficult to detect a bad password against multiple accounts 
with the tools that I know about within OSSEC.  The frequency and timeframe 
are really the only two values that you can tweak.  And it's probably easy 
enough to just slow down your scan to avoid detection, such as I see with 
the slow scans against our firewalls that go undetected by OSSEC.  And on 
the other hand, it's probably easy enough to pull out the data you want if 
they're attempting user/pass combos as fast as the network can handle it.

While out of scope of the OSSEC conversation, are there other 
countermeasures you can add?  Implement 802.1x?  Turn up threshold on 
account lockouts?  Even if you area able to detect account spraying, is 
someone watching the alerts?  Will it matter 8, or 16 hours later after 
they've been able to successfully login?  I realize in 1000s of AD 
accounts, aggressive account lockouts can create a helpdesk headache.  I 
have no idea about your environment, so apologies in advance.  These are 
just things that come to mind :)



On Friday, January 11, 2019 at 10:01:51 AM UTC-8, Bruce Westbrook wrote:
>
> I'm actually looking for both instances -- instances where there are X 
> number of failed logons to Y+ number of legitimate accounts (purpose of 
> rule #100440) and X number of failed attempts to logon to non-existent 
> accounts (rule #100445).  The sub status in those rules are indicative of 
> either a bad password or a non-existent account.
>
> Unfortunately keeping a white-list of accounts is not feasible with 
> thousands of user accounts which are in a constant state of flux.
>
> A little more background -- this initially stemmed from a recent 
> penetration test we had where we found we were unable to detect their 
> password spray attack against legitimate accounts.  I'm now trying to 
> create an alert within OSSEC for this type of thing.  Alternatively I may 
> have to look at what I can do within Splunk (the backend of my OSSEC).
>
> On Fri, Jan 11, 2019 at 11:56 AM Brent Morris <brent....@gmail.com 
> <javascript:>> wrote:
>
>> Bruce - Do the password spraying attacks have correct user names?  Or do 
>> they have mostly incorrect user names and occasionally get lucky?
>>
>> One approach would be to create a list of correct user names and block 
>> attackers when they type in an incorrect user name.  I've done something 
>> like this on URLs, so external connections to a blacklist of URLs will 
>> cause an active response.
>>
>> On Wednesday, January 9, 2019 at 12:27:27 PM UTC-8, Bruce Westbrook wrote:
>>>
>>> I'm looking for a way to detect password spraying of accounts, but 
>>> without triggering a bunch of false positives from normal user 
>>> fat-fingering activity.  Before I begin rebuilding the wheel, has anyone 
>>> already built solid password spraying detection rules that they can share?  
>>> At this point it's just for Active Directory but the same logic may be 
>>> ported to other areas like web logs.
>>>
>>> Otherwise, I'm stuck with trying to get OSSEC to understand how to 
>>> detect bad passwords against multiple/different accounts.  There isn't a 
>>> way that I know to do a "NOT same_user" for multiple matches, so my testing 
>>> still ends up triggering for bad passwords on just one account.  Here's my 
>>> working example so far:
>>>
>>>   <rule id="100440" level="10" frequency="9" timeframe="3600">
>>>     <if_matched_sid>18130</if_matched_sid>
>>>     <same_source_ip />
>>>     <regex>Status:\t*\s*0xc000006d\t*\s*Sub Status:\t*\s*0xc000006a
>>> </regex>
>>>     <description>ALERT: Probable password spraying</description>
>>>   </rule>
>>>
>>>
>>>   <rule id="100445" level="10" frequency="4" timeframe="3600">
>>>     <if_matched_sid>18130</if_matched_sid>
>>>     <same_source_ip />
>>>     <regex>Status:\t*\s*0xc000006d\t*\s*Sub Status:\t*\s*0xc0000064
>>> </regex>
>>>     <description>ALERT: Probable account enumeration attempt
>>> </description>
>>>   </rule>
>>>
>>>
>>> While these do trigger for bad passwords against multiple accounts, they 
>>> also trigger for just a single account with multiple bad passwords being 
>>> keyed by a legitimate user.  How can I tell OSSEC to match only when it 
>>> sees a bad password against multiple different accounts?  Basically, <! 
>>> same_user />?
>>>
>>> Thoughts / suggestions?
>>>
>>> -- 
>>
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "ossec-list" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to ossec-list+...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to