Nessus triggers the same Shellshock-Attack Mails/Alerts hundred times daily

[Andrehens Chicfici]

Hey,

I am using nessus to test our network. This results in getting hundred of mails/alerts daily from the same host:

Rule 31168 and 31169 with the description "Shellshock Attack detected" from 0245-web_rules.xml out of the /ruleset/rules path get triggered hundreds of time which look like:

<rule id="31168" level="15">
    <if_sid>31108</if_sid>
    <regex>"\(\)\s*{\s*\w*:;\s*}\s*;|"\(\)\s*{\s*\w*;\s*}\s*;</regex>
    <description>Shellshock attack detected</description>
    <mitre>
      <id>T1068</id>
      <id>T1190</id>
    </mitre>
    <info type="cve">CVE-2014-6271</info>
    <info type="link">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271</info>
    <group>attack,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SI.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>

AND

<rule id="31169" level="15">
    <if_sid>31108</if_sid>
    <regex>"\(\)\s*{\s*_;\.*}\s*>_[\$\(\$\(\)\)]\s*{</regex>
    <description>Shellshock attack detected</description>
    <mitre>
      <id>T1068</id>
      <id>T1190</id>
    </mitre>
    <info type="cve">CVE-2014-6278</info>
    <info type="link">https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6278</info>
    <group>attack,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SI.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>

I didn't touch those two rules, they're native wazuh rules.

Why is it sending the same 2 alert more than 100 times every day? And how can I make it send just one time. And is there a fix? I mean yeah, nessus is trying shellshock attacks. But I am doing it on purpose. But Why just one host gets triggered. And I don't want to ignore it to get alerts about a real shellshock attack attempt.

I found another similar post here which recommends just setting the rule level to 0. That is not a solution in my eyes.

https://groups.google.com/g/wazuh/c/t-epCxHOtnk/m/uPRhBly4AgAJ

Cheers

chic

[hasitha.u...@wazuh.com]

Hi Andrehens,

Please allow me some time; I’m currently looking into this and will get back to you with an update as soon as possible.

[hasitha.u...@wazuh.com]

Hi Andrehens,

I believe we can create a custom rule to exclude alerts from that Nessus log source. Could you please share sample logs related to both rules? This will help us check if it's possible to exclude these events based on the log source.

There is an option to use the ignore attribute in the rule tag. However, in your case, you shouldn't use it to overwrite rules and avoid alert floods during specific times, because doing so would also exclude real attacks. The best option is to review the sample logs that trigger those alerts and create a custom rule with level 0 to silence them instead.

Example:

1. <rule id="100200" level="0">
2.     <if_sid>31168</if_sid>
3.     <regex>\.+192.168.8.100\.+</regex>
4.     <description>Legitimate Shellshock attack detected from Nessus.</description>
5. </rule>

If the Nessus IP address appears in the log, you can write a regex to match it. If the log decodes the IP address, you can use the <field> tag in the rule instead. However, we need to review the sample logs to provide you with the proper solution.

Ref:
Wazuh Regex
Custom rules
Rule syntax

[Andrehens Chicfici]

Hey,

thanks for the fast help!

I reviewed my logs like you said and now I understand WHY it is triggering so often. It tries every string and then of course triggers the two rules. I get alerted via mail and that doesn't contain the  full_log. 

The logs say:

RuleID 31168:

192.168.8.100 - - [10/Feb/2026:21:08:12 +0000] "GET / HTTP/1.1" 200 11272 "-" "() { ignored; }; echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6271_rce Output : $((74+75))\""
192.168.8.100 - - [10/Feb/2026:21:08:11 +0000] "GET /zabbix/index.php HTTP/1.1" 200 6361 "-" "() { ignored; }; echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6271_rce Output : $((74+75))\""
192.168.8.100 - - [10/Feb/2026:21:08:11 +0000] "GET /xampp/cgi.cgi HTTP/1.1" 301 584 "-" "() { ignored; }; echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6271_rce Output : $((29+68))\""
192.168.8.100 - - [10/Feb/2026:21:08:11 +0000] "GET /wwwboard.cgi HTTP/1.1" 301 582 "-" "() { ignored; }; echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6271_rce Output : $((29+68))\""
192.168.8.100 - - [10/Feb/2026:21:08:11 +0000] "GET /wwwadmin.cgi HTTP/1.1" 301 582 "-" "() { ignored; }; echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6271_rce Output : $((29+68))\""

[...]

RuleID 31169:

192.168.8.100 - - [10/Feb/2026:21:08:11 +0000] "GET / HTTP/1.1" 200 11272 "-" "() { _; } >_[$($())] { echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6278 Output : $((97+45))\"; }"
192.168.8.100 - - [10/Feb/2026:21:08:11 +0000] "GET /zabbix/index.php HTTP/1.1" 200 6361 "-" "() { _; } >_[$($())] { echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6278 Output : $((97+45))\"; }"
192.168.8.100 - - [10/Feb/2026:21:08:11 +0000] "GET /xampp/cgi.cgi HTTP/1.1" 301 584 "-" "() { _; } >_[$($())] { echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6278 Output : $((73+7))\"; }"
192.168.8.100 - - [10/Feb/2026:21:08:11 +0000] "GET /wwwboard.cgi HTTP/1.1" 301 582 "-" "() { _; } >_[$($())] { echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6278 Output : $((73+7))\"; }"
192.168.8.100 - - [10/Feb/2026:21:08:11 +0000] "GET /wwwboard.cgi HTTP/1.1" 301 582 "-" "() { _; } >_[$($())] { echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6278 Output : $((73+7))\"; }"

[...]

So I guess your solution with the subrule might work:

1. <rule id="100200" level="0">
2.     <if_sid>31168</if_sid>
3.     <regex>\.+192.168.8.100\.+</regex>
4.     <description>Legitimate Shellshock attack detected from Nessus.</description>
5. </rule>

Am I able to get both sids in one rule divided by comma? Like:

1. <rule id="100200" level="0">

1.     <if_sid>31168,31169</if_sid>

1.     <regex>\.+192.168.8.100\.+</regex>
2.     <description>Legitimate Shellshock attack detected from Nessus.</description>
3. </rule>

Will try that and see if it triggers tonight...

cheers

chic

[Andrehens Chicfici]

Hey,

so I reviewed the reports. It DID work and stopped triggering 100+ events from the same host with this rule:

1. <rule id="100200" level="0">

1.     <if_sid>31168,31169</if_sid>

1.     <regex>\.+192.168.8.100\.+</regex>
2.     <description>Legitimate Shellshock attack detected from Nessus.</description>
3. </rule>

BUT

there were still 4 events from two other hosts with that ruleID that triggered. The scan was from the same sourceIP. But why did't the rule work then?

192.168.8.100 - - [11/Feb/2026:17:05:56 +0000] "GET / HTTP/1.1" 200 10982 "-" "() { _; } >_[$($())] { echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6278 Output : $((3+32))\"; }"
192.168.8.100 - - [11/Feb/2026:17:08:36 +0000] "GET / HTTP/1.1" 200 189 "-" "() { _; } >_[$($())] { echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6278 Output : $((2+52))\"; }"
192.168.8.100 - - [11/Feb/2026:17:05:56 +0000] "GET / HTTP/1.1" 200 10982 "-" "() { ignored; }; echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6271_rce Output : $((44+29))\""
192.168.8.100 - - [11/Feb/2026:17:05:56 +0000] "GET / HTTP/1.1" 200 10982 "-" "() { _; } >_[$($())] { echo Content-Type: text/plain ; echo ; echo \"bash_cve_2014_6278 Output : $((3+32))\"; }"

Cheers

chic

[hasitha.u...@wazuh.com]

Hi Andrehens,

Earlier, I shared an example, and you can achieve this using the same approach.

The reason it was not working is because of the regex. Your log sample starts directly with the IP address, so you don't need to add \.+ before the IP in the regex pattern.

For example, you can write it like this:

1. <rule id="100200" level="0">
2.     <if_sid>31168,31169</if_sid>

1.     <regex>192.168.8.100\.+</regex>

1.     <description>Legitimate Shellshock attack detected from Nessus.</description>
2. </rule>

The <srcip> field does not support regex patterns. You can only specify a direct IP address in the <srcip> tag.

However, if you receive multiple source IPs that you want to exclude from these rules, then you can use multiple srcip tags to specify those IPs.

1. <rule id="100200" level="0">
2.     <if_sid>31168,31169</if_sid>

1.     <srcip>192.168.8.100</srcip>
2.     <srcip>192.168.8.101</srcip>
3.     <srcip>192.168.8.103</srcip>

1.     <description>Legitimate Shellshock attack detected from Nessus.</description>
2. </rule>

If you have more than 5 or you have to maintain more then you can use the CDB list.
For example:
Create the CDB list file on the Wazuh manager, run the following command:
vi /var/ossec/etc/lists/legitimate-IPs
192.168.8.100:
192.168.8.101:
192.168.8.102:
192.168.8.103:
....
....

Save and exit the file.

Edit the Wazuh manager configuration file:
vi /var/ossec/etc/ossec.conf

Add the following line inside the <ruleset> block:
<list>etc/lists/legitimate-IPs</list>

Save the file and restart the Wazuh manager:
systemctl restart wazuh-manager

Create a custom rule using the CDB list. You can now use the CDB list to determine whether the srcip value is legitimate or not.
Example custom rule:

1. <rule id="100200" level="0">
2.     <if_sid>31168,31169</if_sid>

1.    <list field="srcip" lookup="address_match_key">etc/legitimate-IPs</list>

1.     <description>Legitimate Shellshock attack detected from Nessus.</description>
2. </rule>

You can refer to the Wazuh rules syntax and CDB list documentation for more details.

Let me know if you need further assistance on this.

[Andrehens Chicfici]

Hey  Hasitha

I changed my regex by removing the \. in front of the IP address. But I still don't get why it triggered. It seemed that it was kind of working before with that regex.

It was the same source ID because my nessus always scans from the same IP. The only difference in the events was the host that triggered.

cheers

chic

[hasitha.u...@wazuh.com]

Hi Andrehens,

Could you share a bit more detail about the issue? It's a bit strange that the first rule worked but the second one isn't, especially since the log you shared seems to match the last rule I provided.

To get to the bottom of this, we need to check the actual log sample that Wazuh is processing through its analysis engine. It would help if you could pull the relevant logs from the archives.json file so we can take a closer look at what's coming through.

By default, archive logs are disabled due to high storage consumption. Edit the /var/ossec/etc/ossec.conf file and add this:

1. <ossec_config>
2. <global>
3. <logall_json>yes</logall_json>
4. </global>
5. </ossec_config>

Save the file, then restart the manager again: systemctl restart wazuh-manager

This will log all events to /var/ossec/logs/archives/archives.json, so you can see everything your manager is picking up.

Check the Archive Logs: Now, let’s look for related logs in the archive: cat /var/ossec/logs/archives/archives.json | grep keyword

Replace keyword with sample log unique content.

Warning Keeping <logall_json>yes</logall_json> on can fill up your disk fast! Once you’re done troubleshooting, set it back to no in /var/ossec/etc/ossec.conf and restart the manager: systemctl restart wazuh-manager.

The only difference in the events was the host that triggered.

Please explain this further because we can basically use the <hostname> tag to define the agent names to trigger the rule for specific agents.
For example:

1. <rule id="xxxxx" level="0">
2.     <if_sid>xxxxx</if_sid>
3.     <hostname>agentname1|agent_name2</hostname>
4.     <description>Test agents</description>
5. </rule>

Ref: https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#rules-hostname
If you are mentioned in this way, then you can use hostname tag to use the rule for specic agent, if not please share more details regarding this.

 
Let me know if you need further assistance on this.

[Andrehens Chicfici]

Hey Hashita

Here are three .json-Files: The first one is the one that gets suppressed which was triggering hundreds of times. The second and third one are still triggering once or twice per scan.

{
  "_index": "wazuh-alerts-4.x-2026.02.10",
  "_id": "k8hiSZwBN0Z6RfBLOPbP",
  "_score": null,
  "_source": {
    "input": {
      "type": "log"
    },
    "agent": {
      "ip": "192.168.180.11",
      "name": "Host-1",
      "id": "098"
    },
    "manager": {
      "name": "wazuh"
    },
    "data": {
      "protocol": "GET",
      "srcip": "192.168.8.100",
      "id": "200",
      "url": "/"
    },
    "rule": {
      "firedtimes": 72,
      "mail": true,
      "level": 15,
      "pci_dss": [
        "11.4"
      ],
      "tsc": [
        "CC6.1",
        "CC6.8",
        "CC7.2",
        "CC7.3"
      ],
      "description": "Shellshock attack detected",
      "groups": [
        "web",
        "accesslog",
        "attack"
      ],
      "mitre": {
        "technique": [
          "Exploitation for Privilege Escalation",
          "Exploit Public-Facing Application"
        ],
        "id": [
          "T1068",
          "T1190"
        ],
        "tactic": [
          "Privilege Escalation",
          "Initial Access"
        ]
      },
      "id": "31168",
      "nist_800_53": [
        "SI.4"
      ],
      "info": "CVE-2014-6271https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271",
      "gdpr": [
        "IV_35.7.d"
      ]
    },
    "location": "/var/log/apache2/access.log",
    "decoder": {
      "name": "web-accesslog"
    },
    "id": "1770757699.8379852916",
    "full_log": "10.126.0.24 - - [10/Feb/2026:21:08:12 +0000] \"GET / HTTP/1.1\" 200 11272 \"-\" \"() { ignored; }; echo Content-Type: text/plain ; echo ; echo \\\"bash_cve_2014_6271_rce Output : $((74+75))\\\"\"",
    "timestamp": "2026-02-10T22:08:19.631+0100"
  },
  "fields": {
    "timestamp": [
      "2026-02-10T21:08:19.631Z"
    ]
  },
  "sort": [
    1770757699631
  ]
}

------------------------

{
  "_index": "wazuh-alerts-4.x-2026.02.11",
  "_id": "w92qTZwBN0Z6RfBLV881",
  "_score": null,
  "_source": {
    "input": {
      "type": "log"
    },
    "agent": {
      "ip": "192.168.180.15",
      "name": "Host-2",
      "id": "100"
    },
    "manager": {
      "name": "wazuh"
    },
    "data": {
      "protocol": "GET",
      "srcip": "192.168.8.100",
      "id": "200",
      "url": "/"
    },
    "rule": {
      "firedtimes": 1,
      "mail": true,
      "level": 15,
      "pci_dss": [
        "11.4"
      ],
      "tsc": [
        "CC6.1",
        "CC6.8",
        "CC7.2",
        "CC7.3"
      ],
      "description": "Shellshock attack detected",
      "groups": [
        "web",
        "accesslog",
        "attack"
      ],
      "mitre": {
        "technique": [
          "Exploitation for Privilege Escalation",
          "Exploit Public-Facing Application"
        ],
        "id": [
          "T1068",
          "T1190"
        ],
        "tactic": [
          "Privilege Escalation",
          "Initial Access"
        ]
      },
      "id": "31168",
      "nist_800_53": [
        "SI.4"
      ],
      "info": "CVE-2014-6271https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271",
      "gdpr": [
        "IV_35.7.d"
      ]
    },
    "location": "/var/log/apache2/access.log",
    "decoder": {
      "name": "web-accesslog"
    },
    "id": "1770829533.5531114965",
    "full_log": "10.126.0.24 - - [11/Feb/2026:17:05:56 +0000] \"GET / HTTP/1.1\" 200 10982 \"-\" \"() { ignored; }; echo Content-Type: text/plain ; echo ; echo \\\"bash_cve_2014_6271_rce Output : $((44+29))\\\"\"",
    "timestamp": "2026-02-11T18:05:33.228+0100"
  },
  "fields": {
    "timestamp": [
      "2026-02-11T17:05:33.228Z"
    ]
  },
  "sort": [
    1770829533228
  ]
}

---------------

{
  "_index": "wazuh-alerts-4.x-2026.02.11",
  "_id": "m92sTZwBN0Z6RfBLyfhI",
  "_score": null,
  "_source": {
    "input": {
      "type": "log"
    },
    "agent": {
      "ip": "192.168.180.20",
      "name": "Host-3",
      "id": "099"
    },
    "manager": {
      "name": "wazuh"
    },
    "data": {
      "protocol": "GET",
      "srcip": "192.168.8.100",
      "id": "200",
      "url": "/"
    },
    "rule": {
      "firedtimes": 2,
      "mail": true,
      "level": 15,
      "pci_dss": [
        "11.4"
      ],
      "tsc": [
        "CC6.1",
        "CC6.8",
        "CC7.2",
        "CC7.3"
      ],
      "description": "Shellshock attack detected",
      "groups": [
        "web",
        "accesslog",
        "attack"
      ],
      "mitre": {
        "technique": [
          "Exploitation for Privilege Escalation",
          "Exploit Public-Facing Application"
        ],
        "id": [
          "T1068",
          "T1190"
        ],
        "tactic": [
          "Privilege Escalation",
          "Initial Access"
        ]
      },
      "id": "31168",
      "nist_800_53": [
        "SI.4"
      ],
      "info": "CVE-2014-6271https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271",
      "gdpr": [
        "IV_35.7.d"
      ]
    },
    "location": "/var/log/apache2/access.log",
    "decoder": {
      "name": "web-accesslog"
    },
    "id": "1770829693.5566474166",
    "full_log": "10.126.0.24 - - [11/Feb/2026:17:08:39 +0000] \"GET / HTTP/1.1\" 200 189 \"-\" \"() { ignored; }; echo Content-Type: text/plain ; echo ; echo \\\"bash_cve_2014_6271_rce Output : $((80+68))\\\"\"",
    "timestamp": "2026-02-11T18:08:13.951+0100"
  },
  "fields": {
    "timestamp": [
      "2026-02-11T17:08:13.951Z"
    ]
  },
  "sort": [
    1770829693951
  ]
}

cheers

chic

[hasitha.u...@wazuh.com]

Hi Andrehens,

Based on the sample log you shared, it looks like the log starts with the Nessus IP. If that's the case, you can use this regex pattern:
<regex>10.126.0.24\.+</regex>
If the Nessus IP appears somewhere in the middle of the log instead, you'd use:
<regex>\.+10.126.0.24\.+</regex>

If you're not sure whether the IP always starts the log or might appear in the middle, you can combine both patterns using the | operator (which means "or"):
<regex>10.126.0.24\.+|\.+10.126.0.24\.+</regex>

I tested this with the sample logs you provided, and it matches correctly since the IP does appear at the start. But if you want to be safe and cover both scenarios, the combined pattern will work.
Here's an example of how to set up your custom rules:

1. <group name="legitimate_web">
2.  
3.   <rule id="100201" level="0">
4.     <if_sid>31168</if_sid>
5.     <regex>10.126.0.24\.+|\.+10.126.0.24\.+</regex>

1.     <description>Legitimate Shellshock attack detected from Nessus.</description>
2.   </rule>
3.  

1.   <rule id="100200" level="0">

1.     <if_sid>31169</if_sid>
2.     <regex>10.126.0.24\.+|\.+10.126.0.24\.+</regex>

1.     <description>Legitimate Shellshock attack detected from Nessus.</description>
2.   </rule>

1. </group>

Replace these with the custom rules you've already created for rules 31168 and 31169.
The custom rule file is located at: /var/ossec/etc/rules/

After adding the rules, restart Wazuh and test them using:
/var/ossec/bin/wazuh-logtest

If you have additional IPs that are legitimate and need to be whitelisted, you can add them to the same regex using the | operator:
<regex>10.126.0.24\.+|\.+10.126.0.24\.+|xx.xx.xx.xx\.+|\.+xx.xx.xx.xx\.+</regex>

Ref:
Wazuh Regex
Custom rules
Rule syntax

Additionally, I believe you have changed the scrip which is shown in the log before shared with me.

data": {
      "protocol": "GET",
      "srcip": "192.168.8.100",
      "id": "200",
      "url": "/"
    },

Because the log has this IP 10.126.0.24, and the srcip field decoded as 192.168.8.100(which is not in the log sample). I believe you have tried to mask the srcip field. We recommend always trying to mask the sensitive data before sharing. 

Let me know if you need further assistance on this.

[Andrehens Chicfici]

Hey Hasitha,

yeah I tried to mask my srcIP too lazy...

Maybe I found the reason. The rule was duplicated. So the wrong one was used. My bad.

Will report if anything significant changed.

[hasitha.u...@wazuh.com]

Hi Andrehens,

That's okay, let me know if you need any further help with this, and we can look into it more. Thanks!