By now, pretty much everyone in tech (and security of course) has heard about the critical Log4j security flaw. With Google, Apple, Amazon, IBM, Oracle, and Cisco using the Apache Log4j logging library, as well has many other popular companies and services, the zero-day vulnerabilities (CVE-2021-44228, CVE 2021-45046, and the new CVE-2021-45105) pose a threat to hundreds of millions of user devices.

Vulnerabilities like these are discovered every once in a while, and after them come a tsunami of panic and patches. But what about preparing your network on a whole other layer, so that your network can't even be reached for attackers to exploit the vulnerability in the first place? This is where proactive threat protection comes in.

When attackers try to scan your network, breach your network, or download malware - they have to be coming from somewhere. So much of the internet is abused for cyber attacks, yet most corporate networks still choose to trust almost all of the internet by default. Protective DNS uses a different angle: first trust no one, and then let in those with a solid reputation. A zero-trust based mentality might seem harsh, but the reality is - there only a few thousand or so internet destinations your employee devices should be communicating with while at work, so why are you letting their machines accept traffic from billions of addresses across the internet?

On top of that, many IPs are abused on an ongoing basis for malware. If they already have a bad reputation, why not block them from the get go? Let's take the IP 157.245.108[.]125 as a use case.


Image: VirusTotal

The IP, a payload for Log4j attacks, is clearly malicious. Four security vendors have flagged it, as well as various security researchers in the community. At ThreatSTOP, we've been monitoring this IP for two years already based on its past bad activity. It has been in our CINS Army threat target, meaning customers were already protected from Log4j payloads coming from 157.245.108[.]125 even before the vulnerabilities were uncovered. As shown in our CheckIOC tool, we have blocked over 180 communication attempts from this IP to our customer networks in the last week alone.

log4jcheckipImage: ThreatSTOP CheckIOC

ThreatSTOP also allows users to block traffic from countries that there's no reason their machines should be talking to. In addition to ITAR and OFAC blocklists, users can block specific countries like India - where this IP is located. This IP is among many Log4j indicators of compromise (such as 128.90.61[.]199 and 157.90.35[.]190) that have been showing blocked hits in our systems, from attempts to attack customer networks. Using a low-trust, high-protection approach is what lets ThreatSTOP block the biggest, baddest attacks for users before they become famous (like SolarWinds).

So blocking Log4j IOCs isn't going to make your systems immune to its vulnerabilities (if you haven't patched, now's the time), but it is going to ward off any attempts to invade your network - right at the gateway. If attackers can't get in in the first place, they won't be able to exploit any current and upcoming vulnerabilities - and you won't be forced to leave your holiday dinner to go handle a cyber breach.

To all our readers - Happy Holidays and stay safe!


Ready to try ThreatSTOP in your network? Want an expert-led demo to see how it works?