Like so many out there I use WordPress to power this site. WordPress is a very popular CMS to power everything form simple blogs and personal websites to complex webshops. This also makes it very popular among blackhats as a target for malicious attacks.

So when you have a WordPress site you better look at securing it! If you don’t it just a matter of time before you are compromised. Use a strong password, always install updates to the cms and it’s plugins and themes and be carefull what plugins and themes you use. Second there are some good plugins to enhance the security of your WordPress installation.

One of these is Sucuri. It offers you a site checkup that checks your installation and can report everything that is off, like files that have been altered compared to the default version, or settings that are ‘off’. Also it can provide you with a site audit that informs you off site authorisation attemps (succesfull or not!) and other important events like plugin updates or installation. Last you can optionally use their WordPress firewall offering to further protect your website. This is a payed extra, but the plugin is fully functional if you just use its basic features.

In this post I will focus on the audit part. Back in the day the author of the plugin made a modified version of the good old Ossec HIDS, to offer next level monitoring of the audit file Sucuri makes. All of this is ancient history but the github repo is still there. Now I use Wazuh personally, which is a very powerfull SIEM offering and is based on Ossec originally and still uses many off its principles and inner workings.

So this got me going, what if I could ingest Sucuri‘s audits into Wazuh to keep an eye on what it monitors 🙂 In the end the github repo mentioned above provided me with a good starting point. In the end all that was needed were some slight modifications to the decoder and rules that the github repo provided to get everything compatible with the latest Wazuh version.

<!-- WordPress AuditLog
  -  Examples:
  -  2015-12-11 23:51:54 WordPressAudit example.com admin@example.com : Error: 127.0.0.1; User authentication failed: mdmpieqhfj
  -  2015-12-12 17:01:59 WordPressAudit example.com admin@example.com : Notice: 127.0.0.1; User authentication succeeded: admin
  -->
<decoder name="wordpressaudit">
  <prematch>^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d WordPressAudit </prematch>
  <regex offset="after_prematch">^\S+ \S+ : (\w+): (\S+); </regex>
  <order>action, srcip</order>
</decoder>

<decoder name="wordpressaudit-login">
  <parent>wordpressaudit</parent>
  <prematch offset="after_parent">^\S+ \S+ : \w+: \S+; User authentication succeeded:</prematch>
  <regex offset="after_parent">^\S+ \S+ : (\w+): (\S+); User authentication succeeded: (\w+)$</regex>
  <order>action, srcip, user</order>
</decoder>

<decoder name="wordpressaudit-generic">
  <parent>wordpressaudit</parent>
  <prematch offset="after_parent">^\S+ \S+ : \w+: \S+;</prematch>
  <regex offset="after_parent">^\S+ \S+ : (\w+): (\S+); </regex>
  <order>action, srcip</order>
</decoder>

<group name="syslog,wordpress,">
  <rule id="100002" level="0">
    <decoded_as>wordpressaudit</decoded_as>
    <description>WordPress messages grouped.</description>
  </rule>

  <rule id="100003" level="5">
    <if_sid>100002</if_sid>
    <match>User authentication failed</match>
    <description>WordPress authentication failed.</description>
    <group>authentication_failed,</group>
  </rule>

  <rule id="100004" level="3">
    <if_sid>100002</if_sid>
    <match>User authentication succeeded</match>
    <description>WordPress authentication succeeded.</description>
    <group>authentication_success,</group>
  </rule>

  <rule id="100005" level="3">
    <if_sid>100002</if_sid>
    <match>Warning: Comment flood attempt</match>
    <description>WordPress Comment Flood Attempt.</description>
  </rule>

  <rule id="100006" level="7">
    <if_sid>100002</if_sid>
    <match>File modified:</match>
    <description>WordPress file modified.</description>
    <group>syscheck,</group>
  </rule>

  <rule id="100007" level="7">
    <if_sid>100002</if_sid>
    <match>New file added: </match>
    <description>WordPress file added.</description>
    <group>syscheck,</group>
  </rule>

  <rule id="100008" level="3">
    <if_sid>100002</if_sid>
    <match>Post (private to published);</match>
    <description>WordPress post published.</description>
    <group>syscheck,</group>
  </rule>

  <rule id="100009" level="3">
    <if_sid>100002</if_sid>
    <match>Post was uPdated; identifier</match>
    <description>WordPress post updated.</description>
    <group>syscheck,</group>
  </rule>

  <rule id="100010" level="3">
    <if_sid>100002</if_sid>
    <match>Plugin updated</match>
    <description>WordPress plugin updated.</description>
    <group>syscheck,</group>
  </rule>

  <rule id="100011" level="7">
    <if_sid>100002</if_sid>
    <match>Warning: IDS:</match>
    <description>Attack against WordPress detected.</description>
  </rule>

  <rule id="100012" level="10">
    <if_matched_sid>100003</if_matched_sid>
    <same_source_ip />
    <description>Multiple WordPress authentication failures.</description>
    <group>authentication_failures,</group>
  </rule>

  <rule id="100013" level="6" frequency="2" timeframe="28800">
    <if_matched_sid>100004</if_matched_sid>
    <same_user />
    <different_srcip />
    <description>Multiple successful logins from same user and different srcip.</description>
    <group>behaviour_anomaly,</group>
  </rule>

</group>

And finally you need to point your Wazuh-agent to the Sucuri audit log file and configure it as a syslog file. That’s it, you can now monitor everything Sucuri logs in Wazuh! For example plot its logs on a map to see where the evil people that try to login to your WordPress site are coming from 😀