Keysight operates a global honeypot network to track malicious activity trends on the Internet under the direction of our Application and Threat Intelligence (ATI) Research Center. We started to observe the first Log4Shell activity around 6:00AM UTC on Friday, December 10th, and since then we’ve been analyzing activity to better understand the tactics, techniques, and procedures (TTPs) used by attackers and help protect our customers.
A Log4Shell attack is conducted in two primary stages involving multiple hosts. In the first stage, a connection is made to a web server, and in the HTTP connection a string is sent which gets logged. This string triggers a vulnerability in the Log4j Java logging code which causes the victim web server to download a binary from a second server, and that binary is executed on the victim web server with the privileges of the web application. Note that after the malicious binary is executed on the victim system, the sky is basically the limit – additional software can be downloaded and executed. This means it can move laterally, etc. Those results will vary widely by malware campaign.
What does this mean for Enterprise IT? Log4j usage is widespread, with billions of Java-enabled systems out there. It’s trivially easy to exploit, and we saw immediate and increasing activity as soon as Proof of Concept code was released.
Here are key strategies to better protect your organization in both the short and long term.
1. Update your Web Application Firewalls (WAFs) and other perimeter devices immediately to help stop both inbound and outbound Log4j attacks; inbound to protect your servers, and outbound in case you have systems unknowingly belonging to a botnet. This may provide some short-term protection until you’re able to upgrade all of your systems. But be aware that there will be a race between bad actors and security vendors to improve and overcome obfuscation, so this is probably a partial and temporary fix. Use a breach and attack simulation tool like Keysight’s Threat Simulator to evaluate your WAF/NGFW protection against Log4j attacks.
2. Update both external- and internal-facing systems, in that order. Any exposed IP address is currently being bombarded with Log4Shell connection attempts. But once an attacker has gained any foothold, whether through a Log4Shell attack against an external-facing server or any other mechanism, they will proceed to target internal systems.
3. Look at every device on your network to check update status. This means every server, printer, and anything else that will accept an inbound TCP connection (especially a web connection) – and contact the vendor to check on updates for Log4j. Java is popular on devices such as mobile phones, Blu-ray players, printers, network appliances, and everything else. If you can live without something for a few days, turn it off until you’re able to get info from your vendor.
4. Monitor your network activity. Look for unexpected outbound connections, particularly from those accessible from the Internet. Zero-trust would of course be ideal in this situation, but if you can’t do a complete Zero-trust implementation then disable all outbound communications from Internet-facing devices which are not critical. Even if you have a vulnerable system to which someone can pass a malicious JNDI command, but the malware fetch is blocked, this will provide some protection.
5. Consider geoblocking to minimize your risk. If you have device such as a NGFW or Threat Intelligence Gateway (like Keysight’s ThreatARMOR) which can implement geoblocking, do it. Block both inbound and outbound connections to countries which aren’t critical to your business. If you see connections being blocked you can investigate them and whitelist as you have time, but this is the time to minimize risk.
6. Update all of your servers to Log4j 2.15.0. All of them. Because if you have a vulnerable server, it will be found.