Part 2: Predator vs Wazuh SIEM

Welcome to Part 2 of the Predator vs SIEM series. This time, we will be looking at Wazuh. This is a different story—Wazuh was able to fire off high-level alerts using only the default rules. Let’s take a look on what it detected by reviewing the following image.

The first rule that detected Predator as suspicious is “Executed suspicious process with right-to-left override character in binary file, possible malicious file masquerading,” specifically rule ID 92064. Subsequent alerts continued, likely because Wazuh flagged Predator as a suspicious process and continued to monitor and report its activities. In the next testing iteration, I will spawn a new Predator instance without using the RTLO method to see if Wazuh can detect it without triggering these alerts. Remember, most people don’t pay attention to file extensions. If a file has a PDF or any well-known document icon, people are likely to click on it. This also depends on the social engineering tactics that an adversary may deploy, such as in a phishing email, to convince the victim to open the attachment.

Here are some additional rules that Wazuh alerted on: we observed network connections being created, executable files being dropped, and several alerts on command shell execution. This is great! Out of the box, Wazuh can detect Predator. However, this definitely motivates me to improve Predator's evasion capabilities. As mentioned above, I’ll run another attack simulation without using the RTLO technique. Additionally, this gives me an idea to look for or create a rule for the ELK Stack (see part 1 of this series) to detect RTLO suspicious binaries, as this seems trivial to implement.

For the second test, I spawned a new instance of Predator using the Biogenesis tool. By the way, this spawning tool uses a genome.txt file, which essentially contains the base DNA (code) of Predator. With Biogenesis, I can configure an instance of Predator, add necessary API keys such as AI and Discord keys, and define the capabilities of the malware—in this case, a Discord C2 capability.

Continuing with the second iteration of the test, I created an instance of Predator without manipulating the executable name using RTLO or Homoglyph methods. This approach should prevent Wazuh from triggering the previous alerts related to RTLO and the alerts that followed.

I then executed Predator, and once again, Microsoft Defender did not detect it as malicious. Notice that the file is named acrobat.exe, with no manipulation of the file name as mentioned above.

Predator successfully connected to Discord, and I subsequently executed some commands for demonstration. Notice the decryption key in the chat prior to Predator connecting; this key is used to decrypt the prompt that will be sent to the AI for the Discord C2 capability code, which constitutes the malicious payload.

Now, let’s take a look at what Wazuh was able to detect against the modified version of the Predator.

Examining these alerts in the above image, we now see fewer high alerts, only ones pertaining to “Executable file dropped in folder commonly used by malware”. This is an improvement because this alert generates a lot of false positive where I’ve seen legitimate Microsoft system binaries behaving the same way as the Predator, therefore, an inexperience analyst may overlook at this alert and see that it’s a acrobat.exe and move on. An experience or curious analyst would investigate further. Below, you see what I’m saying, a Microsoft System32 binary triggering the same rule as Predator but it’s a legitimate behavior since I’m using a clean instance of a Windows 2019 virtual machine and the binary path is located at C:\Windows\system32\, where Microsoft essential system files and libraries lives in order for the Windows operating system to function properly.

Furthermore, based on the Wazuh default alerts, we no longer see the suspicious RTLO binary alerts and the subsequent alerts such as suspicious binary created network connection and suspicious process commands. These alerts were triggered previously and were classified as level 15 high or critical alerts which would definitely grab the analyst’s attention. However, low-level 3 and 4 alerts were triggered but usually these alerts are not a high priority and often ignored. See the image below for these low-level alerts.

In my opinion, the second version of Predator is an improvement and has the potential to evade detection, at least circumventing the attention of junior analysts and first-tier monitoring teams. This is where threat hunting becomes crucial. For organizations with the necessary budget and maturity, employing a proactive defensive approach through threat hunting is highly recommended when combating malware like Predator.

During this exercise, I aimed to threat hunt by examining all of Predator’s activities in the Wazuh logs, not just the alerts. However, I noticed that my default Wazuh installation was not logging all events like my other SIEM, the ELK Stack. This prompted me to research how to enable comprehensive logging in Wazuh.

So upon further digging, to enable all logging events, you have to edit the /var/ossec/etc/ossec.conf file and set the following fields to “yes”.

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>yes</logall>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>

Also, edit the Filebeat configuration file /etc/filebeat/filebeat.yml and change the value of archives: enabled from false to true:

archives:
  enabled: true

Make sure to restart the respective services for the changes to reflect on the Wazuh platform.

systemctl restart wazuh-manager

systemctl restart filebeat

By following these steps, Wazuh will archive all logs, including those that do not match any alert rules. These logs will be stored in the archives.log and archives.json files located in the /var/ossec/logs/archives/ directory on the Wazuh server. You can then query and visualize these logs on the Wazuh dashboard, allowing you to see all events, not just alerts.

That's all I have time for today. I hope you've enjoyed this article and found it helpful. If my schedule permits, I'll write Part 3 soon, revisiting the ELK Stack to implement a custom rule for detecting ROTLO binaries, which this technique was used in the first Predator version. I'll conduct tests using this detection method and provide my feedback. Stay tuned!