Since the 1990s, the federal government has been issuing guidelines and recommendations for security via their 800-Series Special Publications. While some of those guidelines became mandates, things have largely inched forward, instead of making any dramatic leaps. OMB’s new memorandum M-22-09, “Moving the U.S. Government Towards Zero Trust Cybersecurity Principles,” is changing this pattern, and setting deadlines for implementation across the government.

In January 2022, Microsoft disclosed a remote code execution vulnerability for Internet Information Server (IIS) identified as CVE-2022-21907, which they have subsequently reported as wormable. Through Microsoft, Corelight Labs was able to review a proof of concept for an attack against the vulnerability. This blog presents an open source detection method that Corelight Labs is releasing to detect exploit attempts of CVE-2022-21907.

Last week I had the privilege to be in Washington, DC talking to a group of defenders. I heard a clear pattern of words: “data-driven,” “telemetry-first,” and “visibility”.

We have published an initial blog on the Log4j exploit and a followup blog with a second detection method for detecting the first stage of exploits occurring over LDAP. Today, we will discuss a third detection method, this one focused on the second-stage download that happens after the first stage completes. In this case, the JVM will download additional Java code payloads over HTTP.

We recently discussed some methods for detecting the Log4j exploit, and we’ve now developed another method that everyone running Zeek® or a Corelight sensor can use. Our new approach is based on the rarity of legitimate downloads of Java via LDAP. Zeek does not currently have a native LDAP protocol analyzer (though one is available if you are running Spicy). This will not stop you from detecting this exploit downloading Java over LDAP, though. To see how, read on.

Security workers across the world have been busy since last Friday dealing with CVE-2021-44228, the log4j 0-day known as Log4Shell, that is already being heavily exploited across the Internet. Given the huge number of systems that embed the vulnerable library, the myriad ways that attackers can exploit the vulnerability, and the fact that automated exploitation has already begun, defenders should expect to be dealing with it for the foreseeable future.