attack detection

[Miguel Martinez]

Hi guys

im trying wazuh right now i set a stack of the latest version "3.10.2"  and everything seeems to go perfect..... i download install and configure the client in a windows machine perfect there im logging data and everything seems to be fine...... but i lunch an attack to the windows host and i cant get any logs of it only show a few login fails but i can complete the attack without issue and didn't recieve any alert of it could i be missing something?

[Juan Pablo Saez]

Hi Miguel,

What kind of attack are you using? Is it an RDP attack?

Maybe it's useful for you to install a NIDS such as Suricata to provide additional insight into your network security in a way that is highly complimentary to the HIDS functionality in Wazuh. As additional documentation, you can read our Detect an RDP brute force attack document and see how Wazuh detects and alerts on each login failure.  Anyway, when we know what kind of attack you're using, we can discern what's going on.

Please, let us know. Greetings,

JP Sáez

[Blason R]

What if there are other attacks - Like Ransomware or APT like attack where wmi or powershell or winrm is being used to launch the attack or carrying lateral movement. Do I need sysmon as well to capture such incidents?

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/843ece8a-1fd8-4686-b9f9-a58623762e1c%40googlegroups.com.

[Juan Pablo Saez]

Hi again Blason, it's nice to see you here.

Let's look at Wazuh's capabilities in the cases you mentioned:

• Protection against ransomware:
• The Ransomware tracker is a dedicated ransomware MISP website with ransomware related IP, DNS, and URL blacklists. These feeds can be used to craft CDB lists useful against ransomware.
• Virustotal Integration: You can use FIM + Virustotal integration to check for ransomware and other malware on your USB devices and hard disks.

• In ATP attacks context:
•  while Eventchannel records and forwards WMI events to the Wazuh manager to be checked against the Wazuh WMI event rules, tracking the WMI events through Sysmon can be really useful due to its extended information. 
• SCA and Rootcheck modules allow detecting vulnerable or non-secure WinRM settings. This way you can prevent the WinRM abuse phase. Monitoring WinRM events with Sysmon will provide you with another tool to detect weird stuff on your systems.
  
• Our ruleset includes rules for PowerShell events and we are extending these rules.
• Virustotal integration is useful again here.

In conclusion, Wazuh and Sysmon complement each other when it comes to ATP. WMI, WinRM and PowerShell rules can be correlated to detect such attacks.

Greetings, Juan Pablo Sáez

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.

[Blason R]

Great and thanks again for your help and answer.

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/843ece8a-1fd8-4686-b9f9-a58623762e1c%40googlegroups.com.

--

You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/142b7249-49ce-4a88-bbd6-1e3589daed1f%40googlegroups.com.

[Miguel Martinez]

I use ransomware on the attack

[Miguel Martinez]

Thanks for your answer ....but how can we add this feeds? also is there any kind of rule that we can use to implement active response on that matters thanks again

[Juan Pablo Saez]

Hi again Miguel,

Well, then maybe the Virustotal integration is useful in that particular case. Could you check if your receive alerts when using the ransomware inside a directory monitored by FIM and Virustotal?

Also, if you give me more details and context about your use case, I can recreate the environment and provide better guidance.

Greetings, JP Sáez

[Miguel Martinez]

Hi again Juan 

Im using two ways with ransonware and also using the eternalblue  alone, when i run the eternalblue exploit it give me some login fails with a level 10 alert but not an insight of what going on just the failed login attempts ..... i dont have virustotal integrated ..... i thought that the app have some predetermined signatures feeds to detect the attacks but im seem to be wrong there.  "by the way im new to the wazuh scene so stupid questions alert here " :)  

[Juan Pablo Saez]

Hello Miguel,

First of all, don't worry about your questions, the community comes first for us. Tomorrow I will reply you with some ransomware related example use cases. We'll also discuss active response use in cases as the eternalblue one.

Welcome to the Wazuh community. Greetings, 

JP Sáez 

[Blason R]

My two cents would be to start Process level auditing using GPO policies which will log all the processes executed at Desktops. Since wazuh is collenting eventchannel EvntID 4688 shows very descriptiove and important information.

You can create the dashboards like Powershell commands are getting executed, WinRM or WMI or netsh commands are being fired.

Refer to MITRE ATT&CK for crafting dashboards or anyways sysmon is the best tool.

--

You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/f7976fcb-12d3-4302-9906-88df9210b9c5%40googlegroups.com.

[Juan Pablo Saez]

Hello again Miguel,

• While Wazuh doesn't have Eternalblue explicitly related rules, the Suricata NIDS is really easy to integrate with Wazuh and has attack signatures to detect the EternalBlue exploit, the DOUBLEPULSAR plugin and :
  Suricata Attack signatures for Eternalblue
  
  

  
  

  # EternalBlue Signature matching potential NEW installation of SMB payload

  alert tcp $HOME_NET any -> any any (msg:”EXPLOIT Possible Successful ETERNALBLUE Installation SMB MultiplexID = 82 – MS17-010″; flow:from_server,established; content:”|FF|SMB|32 02 00 00 c0|”; offset:4; depth:9; content:”|52 00|”; distance:21; within:23; classtype:trojan-activity; sid:5000072; rev:1;)# EternalBlue signature matching return signature for connection to pre-installed SMB payload

  alert tcp $HOME_NET any -> any any (msg:”EXPLOIT Successful ETERNALBLUE Connection SMB MultiplexID = 81 – MS17-010″; flow:from_server,established; content:”|FF|SMB|32 02 00 00 c0|”; offset:4; depth:9; content:”|51 00|”; distance:21; within:23; classtype:trojan-activity; sid:5000073; rev:1;)

  
  # Signature to identify what appears to be initial setup trigger for SMBv1 – MultiplexID 64 is another unusual value

  alert tcp $HOME_NET any -> any any (msg:”EXPLOIT Possible ETERNALBLUE SMB Exploit Attempt Stage 1/2 – Tree Connect AndX MultiplexID = 64 – MS17-010″; flow:to_server,established; content:”|FF|SMB|75 00 00 00 00|”; offset:4; depth:9; content:”|40 00|”; distance:21; within:23; flowbits: set, SMB.v1.AndX.MID.64; classtype:trojan-activity; sid:5000074; rev:1;)

  
  

  # Signature triggers on Trans2 Setup Request with MultiplexID – 65 – Another unusual MID – Only triggers if 64 was seen previously.

  alert tcp $HOME_NET any -> any any (msg:”EXPLOIT Possible ETERNALBLUE SMB Exploit Attempt Stage 2/2 – Trans2 SUCCESS MultiplexID = 65 – MS17-010″; flow:to_server,established; content:”|FF|SMB|32 00 00 00 00|”; offset:4; depth:9; content:”|41 00|”; distance:21; within:23; flowbits:isset, SMB.v1.AndX.MID.64; classtype:trojan-activity; sid:5000075; rev:1;)
  
  Suricata Attack signatures for DOUBLE PULSAR
  
  

  alert tcp any any -> $HOME_NET 445 (msg:”DOUBLEPULSAR SMB implant – Unimplemented Trans2 Session Setup Subcommand Request”; flow:to_server, established; content:”|FF|SMB|32|”; depth:5; offset:4; content:”|0E 00|”; distance:56; within:2; reference:url,https://twitter.com/countercept/status/853282053323935749; sid:1618009; classtype:attempted-user; rev:1;)

  alert tcp $HOME_NET 445 -> any any (msg:”DOUBLEPULSAR SMB implant – Unimplemented Trans2 Session Setup Subcommand – 81 Response”; flow:to_client, established; content:”|FF|SMB|32|”; depth:5; offset:4; content:”|51 00|”; distance:25; within:2; reference:url,https://twitter.com/countercept/status/853282053323935749; sid:1618008; classtype:attempted-user; rev:1;)

  
  

  alert tcp $HOME_NET 445 -> any any (msg:”DOUBLEPULSAR SMB implant – Unimplemented Trans2 Session Setup Subcommand – 82 Response”; flow:to_client, established; content:”|FF|SMB|32|”; depth:5; offset:4; content:”|52 00|”; distance:25; within:2; reference:url,https://twitter.com/countercept/status/853282053323935749; sid:1618010; classtype:attempted-user; rev:1;)
  
  

  
  

  Suricata Attack signatures for WannaCry

  
  

  
  

  alert udp $HOME_NET any -> any 53 (msg:"wCry Ransomware - Termination URL Call"; content:"|01 00 00 01 00 00 00 00 00 00|"; offset:2; depth:10; content:"|29|iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea|03|com|00|"; distance:0; fast_pattern; classtype:trojan-activity; sid:5000090; rev:1;)

  
  

  alert udp $HOME_NET any -> any 53 (msg:"wCry Ransomware - Termination URL Call"; content:"|01 00 00 01 00 00 00 00 00 00|"; offset:2; depth:10; content:"|29|ifferfsodp9ifjaposdfjhgosurijfaewrwergwea|03|com|00|"; distance:0; fast_pattern; classtype:trojan-activity; sid:5000091; rev:1;)

  
  

  alert udp $HOME_NET any -> any 53 (msg:"wCry Ransomware - Termination URL Call"; content:"|01 00 00 01 00 00 00 00 00 00|"; offset:2; depth:10; content:"|29|ayylmaotjhsstasdfasdfasdfasdfasdfasdfasdf|03|com|00|"; distance:0; fast_pattern; classtype:trojan-activity; sid:5000092; rev:1;)

  
  

  alert udp $HOME_NET any -> any 53 (msg:"wCry Ransomware - Termination URL Call"; content:"|01 00 00 01 00 00 00 00 00 00|"; offset:2; depth:10; content:"|29|iuqssfsodp9ifjaposdfjhgosurijfaewrwergwea|03|com|00|"; distance:0; fast_pattern; classtype:trojan-activity; sid:5000093; rev:1;)

  
  

  # This domain needs to remain UNSINKHOLED - Worm will propagate if sinkholed.

  alert udp $HOME_NET any -> any 53 (msg:"wCry Ransomware - Activation URL Call"; content:"|01 00 00 01 00 00 00 00 00 00|"; offset:2; depth:10; content:"|29|ayylmaoTJHSSTasdfasdfasdfasdfasdfasdfasdf|03|com|00|"; distance:0; fast_pattern; classtype:trojan-activity; sid:5000094; rev:1;)
  
  
• When the alerts above trigger, our Suricata rules also trigger delivering the alert to the Wazuh Kibana app for easy visualization:
  This particular rule triggers on suricata alerts. 
  
  <rule id="86601" level="3">

          <if_sid>86600</if_sid>

          <field name="event_type">^alert$</field>

          <description>Suricata: Alert - $(alert.signature)</description>

          <options>no_full_log</options>

  </rule>

I hope this example offers a bit of insight into ransomware and Eternalblue Wazuh powered detection. If you need help to configure Wazuh to your needs, please, let us know.

PD: Blason, it's great to read your views, thanks for being here!

Greetings, JP Sáez

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.

[Blason R]

Hey Juan,

One more thing probably I can suggest or not sure if this is already collecting the logs about Autoruns.

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/f7976fcb-12d3-4302-9906-88df9210b9c5%40googlegroups.com.

--

You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/68689d5b-5d0b-41d9-a9df-6116add8af06%40googlegroups.com.

[Miguel Martinez]

Hi Blason

Thanks for you guys hel and interest .... I don't know if I understand well... so you mean that I can create a policy to collect the process logs of the windows machines but not in wazuh just on the elk stack ?

[Miguel Martinez]

Thanks again Juan

I have been extremely busy the last few days and couldn't check the group out 🤯.... so basically you recommend to implement or pair wazuh with an IDS for better visibility ... this might work on some scenarios but it could be a pain in others... let's said I got a wazuh stack running on a place and I have the NIDS there but got a few spread host on different places that I can't had an NIDS in that case I loose the visibility and the possibility of log the event.

[Rick Gutierrez]

hi, very interesting and this example, I'm looking for the same thing with wazuh and kibana - elasticsearch

--

rickygm

http://gnuforever.homelinux.com

[Miguel Martinez]

Hi Rick

Welcome to the discussion I'm glad me, my ignorance and short knowledge captivate your attention on this topic stay tune for more of my crazy questions 👍

[Rick Gutierrez]

El El dom, oct. 6, 2019 a la(s) 10:10 p. m., Miguel Martinez <miguel.a....@gmail.com> escribió:

Hi Rick

Welcome to the discussion I'm glad me, my ignorance and short knowledge captivate your attention on this topic stay tune for more of my crazy questions 👍

I am also new to wazuh and kibana, but I think the people of wazuh are doing a great job and with leaps and bounds, long live to wazuh!!

--

rickygm

http://gnuforever.homelinux.com

[Juan Pablo Saez]

Hello everybody, I'm sorry for my absence in the last few days.

Thanks for you guys hel and interest .... I don't know if I understand well... so you mean that I can create a policy to collect the process logs of the windows machines but not in wazuh just on the elk stack ?

Miguel, I think Blason refers to use windows Audit Process tracking to log all the processes activity at monitored machines. You can enable it through the GPO editor:

With the Audit process tracking enabled, events as program activations, processes exit, handle duplication, and indirect object access will be forwarded to Wazuh to be checked against its ruleset. i,e, Process creation will generate 4688 ID events as Blason said above. Wazuh can evaluate these events with its ruleset and you can also extend it with your own custom rules for your use case.

 

so basically you recommend to implement or pair wazuh with an IDS for better visibility ... this might work on some scenarios but it could be a pain in others... let's said I got a wazuh stack running on a place and I have the NIDS there but got a few spread host on different places that I can't had an NIDS in that case I loose the visibility and the possibility of log the event.

 Pairing Wazuh with Suricata can provide you with useful network information, and I agree, some use cases can be more difficult to cover and you could need to create a really custom security stack. In spread hosts scenario you should forward the activity from all your nodes(at least the most sensible ones) to control all inbound and outbound traffic. If you join this journey count with us to set up your stack.

Thanks to all for the positive feedback and great attitude. Community comes first!

Best regards, JP Sáez

[Miguel Martinez]

Hi Juan 

I get that part of the policy what i dont understand was the creation of dashboards for it ..... or the available dashboards on wazuh can handle that ?

On the suricata side i was looking foward to make this kind of deployment didnt know that was that easy..... on the example you send they use logstash it is necessary to use logstash ?.....also can you elaborate a lil bit on why should suricata be installed on both ends "just want to understand better the setup since it require more procesing power to run this kind of deploy"

On other note if i use cdb lists how can it help me improve discovery and incident response ..... or it just can be use to block or ban the blacklist address ....i will need to create a rule to check out the address that match and create a response based on that? im correct   

hooo @blason you make me look at mitre attack framework in a way i neve imagine now im searching like crazy to found ways and try to collect more info you kill me with that one. im hooked with it.... just for referense how that have help you collect more data also if you can give me some real life examples that you have manage or deploy on wazuh ill really appreciate it.  

[Juan Pablo Saez]

Hi again Miguel,

I get that part of the policy what i dont understand was the creation of dashboards for it ..... or the available dashboards on wazuh can handle that ?

Currently, there is no specific windows auditing dashboard:

• Using the proper filters in the discover section can give you good information about the rule or group of rules associated with the audit windows events. 
• Also, if you don't want to type these filters every time you need to visualize a certain group of alerts, you should create a dashboard containing a group of filters and a visualization.

On the suricata side i was looking foward to make this kind of deployment didnt know that was that easy..... on the example you send they use logstash it is necessary to use logstash ?.....also can you elaborate a lil bit on why should suricata be installed on both ends "just want to understand better the setup since it require more procesing power to run this kind of deploy"

• Logstash isn't mandatory, in the example I posted above Logstash is used to add GeoIP data to alerts and this is out of the Suricata scope. 
• About Suricata being installed on both ends, it depends on the traffic you want to monitor and your infrastructure. Depending on this, maybe you can monitor all your networks from one machine using promiscuous mode in network iface or maybe you cant. After installing Suricata you just need to monitor its output logs through Wazuh localfile blocks.
  
  

On other note if i use cdb lists how can it help me improve discovery and incident response ..... or it just can be use to block or ban the blacklist address ....i will need to create a rule to check out the address that match and create a response based on that? im correct   

CDB lists are used to check if the event data contains any blacklist/whitelist value and generate alerts(and maybe launch an active response script) when an event contains/doesn't contains a certain attribute value). As you say above, you should create some custom rules to use CDB lists on it. You have an example here.

PD: Wazuh will support MITTRE in upcoming releases. Stay tuned!

Best regards, JP Sáez

[Miguel Martinez]

Hi again Juan

Currently, there is no specific windows auditing dashboard:

• Using the proper filters in the discover section can give you good information about the rule or group of rules associated with the audit windows events. 
• Also, if you don't want to type these filters every time you need to visualize a certain group of alerts, you should create a dashboard containing a group of filters and a visualization.

Thanks for clarify 

• Logstash isn't mandatory, in the example I posted above Logstash is used to add GeoIP data to alerts and this is out of the Suricata scope. 
• About Suricata being installed on both ends, it depends on the traffic you want to monitor and your infrastructure. Depending on this, maybe you can monitor all your networks from one machine using promiscuous mode in network iface or maybe you cant. After installing Suricata you just need to monitor its output logs through Wazuh localfile blocks.

Thanks for clarify this one too currently trying the suricata integration and it seems like its working like charm i got to keep running test on it.

(Stupid question alert 1) It is possible to create active response rules based on the suricata rule set ? 

 

CDB lists are used to check if the event data contains any blacklist/whitelist value and generate alerts(and maybe launch an active response script) when an event contains/doesn't contains a certain attribute value). As you say above, you should create some custom rules to use CDB lists on it. You have an example here.

Thanks Juan really appreciate your help and dedicated time..... (stupid question alert) it is necessary to have the cdb list on both the manager and the agent? or it just run on the manager side ?........"  just clarifying for the use of the active response on them"  

 

PD: Wazuh will support MITTRE in upcoming releases. Stay tuned!

This is amazing next release will be a great one very nice features coming.... Thanks for the info 

[Juan Pablo Saez]

Hello Miguel,

There is no stupid question here, the community comes first.

It is possible to create active response rules based on the suricata rule set ? 

• Yes, totally. Custom or default Active-response scripts can be tripped by a specific Suricata alert, or by the Suricata rules group. Here you can check our default Linux and Windows Active-response scripts. 
• Maybe you want to check our Blocking attacks with Active-response document for an example of IP blocking through SSH rules and active response.

it is necessary to have the cdb list on both the manager and the agent? or it just run on the manager side ?

• As the agents just forward events, CDB lists should be only on the manager side, preferably in /var/ossec/etc/lists . It's the manager the one that checks these events against the rules and CDB lists.
• If you want to launch an active-response script trough an agent, that agent should have a script copy.

Ask us for whatever you need. So often happens with Wazuh, every answer begs more questions.

Best regards, JP Sáez

[Miguel Martinez]

Thanks again Juan 

It is possible to create active response rules based on the suricata rule set ? 

• Yes, totally. Custom or default Active-response scripts can be tripped by a specific Suricata alert, or by the Suricata rules group. Here you can check our default Linux and Windows Active-response scripts. 
• Maybe you want to check our Blocking attacks with Active-response document for an example of IP blocking through SSH rules and active response.

Ok ill try that one in a few  

it is necessary to have the cdb list on both the manager and the agent? or it just run on the manager side ?

• As the agents just forward events, CDB lists should be only on the manager side, preferably in /var/ossec/etc/lists . It's the manager the one that checks these events against the rules and CDB lists.
• If you want to launch an active-response script trough an agent, that agent should have a script copy.

I try this one and it fails lol ....... i think something goes wrong on my side i crate a rule based on the cdb lists guide you send me but is not working  im assuming i need a decoder but i got not idea how to make it  ...... with the purpose of testing i blacklisted one of my local ip address but i didn't get the  alert 

This is my rule is the same in the example ..... btw is there a log i can look to test and figure this kind of rules ?

group name="attack,">

    <rule id="100100" level="10">

      <if_group>web|attack|attacks</if_group>

      <list field="srcip" lookup="address_match_key">etc/lists/blacklist-alienvault</list>

      <description>IP in black list.</description>

    </rule>

</group>

thanks again Juan really appreciate  it 

[Miguel Martinez]

i think i sort of figured the rule out

rule run fine did i still need the decoder 

testing the rule 

192.168.0.134 - - [09/Jun/2017:11:17:03 +0000] "POST /command.php HTTP/1.0" 404 464 "-" "Wget(linux)"

**Phase 1: Completed pre-decoding.

       full event: 'ipaddress - - [09/Jun/2017:11:17:03 +0000] "POST /command.php HTTP/1.0" 404 464 "-" "Wget(linux)"'

       timestamp: '(null)'

       hostname: 'localhost'

       program_name: '(null)'

       log: 'ipaddress - - [09/Jun/2017:11:17:03 +0000] "POST /command.php HTTP/1.0" 404 464 "-" "Wget(linux)"'

**Phase 2: Completed decoding.

       decoder: 'web-accesslog'

       srcip: 'ipadress'

       protocol: 'POST'

       url: '/command.php'

       id: '404'

**Phase 3: Completed filtering (rules).

       Rule id: '100100'

       Level: '10'

       Description: 'IP in black list.'

**Alert to be generated.

[Blason R]

Sorry Folks - Its been crazy last 10 days or so hence couldnt reply to the forum.

For us we are extensively using eventID 4688 to capture the commands executed on endpoints and yes IDS would be handy but you need lot of fine-tuning else it will be too noisy.

--

You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/b2903116-4147-4665-86fb-85223e8c2891%40googlegroups.com.

[Juan Pablo Saez]

Hi again,

Miguel 

i think i sort of figured the rule out
rule run fine did i still need the decoder 
testing the rule  

• Seems like your rule syntax is correct and ossec-logtest confirms that the rule operates well. At least for now, you don't need additional decoders. 
• Decoders tell Wazuh how to parse an event so its extracted fields can be later checked against the rules. While the vanilla Wazuh decoders cover a quite large range of event formats, sometimes you should modify an existing decoder or create a new one for a certain event format. Let me know if you find events that aren't generating alerts and we'll work with you in custom decoders/rules.

Let us know how your settings refining is going.

Blason

I think collecting every process start event from every Windows endpoint can be overwhelming until you get the correct trimmering. With the right tuning you will reduce the noise to a fraction. Are you using a CDB based process whitelist?


Greetings, JP Sáez

To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.

[Juan Pablo Saez]

Hi again Miguel,

I'm copying here your message to continue the conversation through the public discussion:

Hi again Juan 
I test the configuration trying a brute Force attack with one of the black list IP address but the alert bring me a different rule Id 5712 to the one that I create 100100 did wazuh has a brute Force rule by default ? ....... the level is correct the attack is the correct one but not the ID

I test the configuration trying a brute Force attack with one of the black list IP address but the alert bring me a different rule Id 5712 to the one that I create 100100 did wazuh has a brute Force rule by default ? 

Wazuh has an SSH brute force attack default rule(5712) ready to alert from this kind of attacks:

  <rule id="5712" level="10" frequency="8" timeframe="120" ignore="60">

    <if_matched_sid>5710</if_matched_sid>

    <description>sshd: brute force trying to get access to </description>

    <description>the system.</description>

    <same_source_ip />

    <group>authentication_failures,pci_dss_11.4,pci_dss_10.2.4,pci_dss_10.2.5,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_SI.4,nist_800_53_AU.14,nist_800_53_AC.7,</group>

  </rule>

This rule triggers when, in a 120 seconds time range, the rule 5710(sshd: Attempt to login using a non-existent user) trips 8 times. Seems like your ssh brute force attack triggered the 5710 rule multiple times and then the 5712 was triggered.

On the other hand, you could point your rule to an existing one using the <if_sid> option

<rule id="100100" level="10">

 <if_sid>XXXXXX</if_sid>

 <list field="srcip" lookup="address_match_key">etc/lists/blacklist-alienvault</list>
<description>IP in black list.</description

I hope it helps.

Greetings, JP Sáez