My first critical alert

19.10.2025

While poking around in the Wazuh dashboard today, I suddenly noticed my first critical alert!

I was really excited, my SIEM is working, the Wazuh dashboard had a bright red number 1 saying "critical severity"

I found the log that triggered the critical severity rule and started investigating.

Here's a snippet of it:

  },
      "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"
      ]
      

It looks like the alert is of an initial access attempt using a shellshock attack. It seems they're sending http Get requests to try and launch some sort of .sh script and maybe forwarding it to this strange bang2012@tutanota.de address.

I began my first incident response. This is where I realize I didn't even have a gameplan on what to do in these kinds of situations. My first instinct was to check the CVE to get an idea of what I'm working with.

Here's what CVE.org says about this CVE:

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka "ShellShock."

Next I copied and pasted the logs into ChatGPT and asked to guide me through a full incident response. I wanted to be really sure this attempt didn't go through.

Here's how it suggested I respond:

• I immediately created a rule that blocked the malicious IP address in both UFW and Ubiquity.
• I then made a "forensics" folder and exported all relevant logs:

sudo tar -czf forensics-logs-$(hostname)-$(date +%s).tgz /var/log/apache2 /var/log/auth.log /var/log/syslog /var/www /etc /home /root

• Then I checked for any shells, downloaders, or network listeners using:

ps auxf | egrep 'wget|curl|sh|rondo|/bin/bash' || true

• I discovered my new favorite fish-flavored command → ss -tunap. This command allows me to quickly see detailed information about all TCP and UDP sockets.
• Then I used grep to pull out any logs related to the incident:

          sudo grep -n "124.198.131.83" /var/log/apache2/* || true
          sudo grep -n "rondo.qre.sh" /var/log/apache2/* || true
          sudo grep -n "rondo.qre.sh" /var/log/apache2/* -R || true

• No logs returned any noticeable successful connections. Looks like a false alarm, but we've proven that no one has been able to get in (hopefully).

Since nothing really stood out with the above commands, I thought it would be a good idea to establish a baseline to compare against for future incidents. I documented them all into a document named "baseline" for future reference

It looks like having an extremely minimal attack surface has saved me so far. I don't have PHP, javascript, mysql, or any fancy modules running on this website. Yet.

This incident gave me some good hands on incident response experience, some useful commands to understand more deeply, and also reminded me that I need to harden my Apache server and disable any unnecessary modules.

This project is really coming together and starting to feel like actual security work. Hopefully my AI generated incident response plan was alright. I'll need to formalize a process and see what the industry standard is.