<span id="hs_cos_wrapper_post_body" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_rich_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="rich_text" ><p style="font-weight: bold;"><span style="font-weight: normal; background-color: transparent; font-size: 1em;">By now, pretty much everyone in tech (and security of course) has heard about the critical Log4j security flaw. With Google, </span><span style="font-weight: normal; background-color: transparent; font-size: 1em;">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 <a href="https://threatpost.com/third-log4j-bug-dos-apache-patch/177159/" rel="noopener" target="_blank">the new CVE-2021-45105</a>) pose a threat to hundreds of millions of user devices.</span></p> <p style="font-weight: bold;"><span style="font-weight: normal;"><span style="background-color: transparent;">Vulnerabilities</span><span style="font-weight: normal;"> 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? <span style="font-weight: bold;">This is where proactive threat protection comes in.</span></span></span></p> <p style="font-weight: normal;"><!--more--></p> <p style="font-weight: normal;">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 <span style="font-weight: normal;">zero-trust based mentality might seem harsh, but the reality is - <span style="font-weight: bold;">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?</span></span></p> <p style="font-weight: normal;"><span style="font-weight: normal;">On top of that, many IPs are abused on an ongoing basis for malware. If they already have a <a href="/blog/the-power-of-ip-reputation-a-private-layer-apt29-love-story" rel="noopener" target="_blank">bad reputation</a>, why not block them from the get go? Let's take the IP 157.245.108[.]125 as a use case.</span><span style="font-weight: normal;"></span></p> <p style="font-weight: normal;"><span style="font-weight: normal;"><img src="https://www.threatstop.com/hubfs/log4jip.png" alt="log4jip" width="998" loading="lazy" style="width: 998px;"></span></p> <p style="font-weight: normal; font-size: 12px;">Image: <a href="https://www.virustotal.com/gui/ip-address/157.245.108.125/detection" rel="noopener" target="_blank">VirusTotal</a></p> <p>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 <a href="/check-ioc" rel="noopener" target="_blank">CheckIOC tool</a>, we have blocked over 180 communication attempts from this IP to our customer networks&nbsp;in the last week alone.</p> <p style="font-weight: normal;"><span style="font-weight: normal;"><img src="https://www.threatstop.com/hubfs/log4jcheckip.png" alt="log4jcheckip" width="906" loading="lazy" style="width: 906px;"><span style="font-size: 12px;">Image: <a href="/check-ioc" rel="noopener" target="_blank">ThreatSTOP CheckIOC</a></span></span></p> <p style="font-weight: normal;"><span style="font-weight: normal;">ThreatSTOP also allows users to <a href="/blog/block-crimea-itar-ofac-ip-address-geo-list" rel="noopener" target="_blank">block traffic from countries</a> 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. </span><span style="font-weight: bold;">Using a low-trust, high-protection approach is what lets ThreatSTOP block the biggest, baddest attacks for users </span><a href="http://threatstop.com/blog/block-threats-before-famous" rel="noopener" target="_blank" style="font-weight: bold;">before they become famous</a><span style="font-weight: bold;"> (like SolarWinds).</span></p> <p style="font-weight: normal;">So blocking Log4j IOCs isn't going to make your systems immune to its vulnerabilities (if you haven't <a href="https://www.google.com/search?q=log4j+patch&amp;rlz=1C1GCEU_enIL970IL970&amp;oq=log4j+patch&amp;aqs=chrome..69i57j0i512l9.5233j0j7&amp;sourceid=chrome&amp;ie=UTF-8" rel="noopener" target="_blank">patched</a>, 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.</p> <p style="font-weight: bold;"><em>To all our readers - Happy Holidays and stay safe!</em></p> <p style="font-weight: normal;">&nbsp;</p> <div> <p><em>Ready to try ThreatSTOP in your network? Want an expert-led demo to see how it works?</em></p> </div> <aside></aside></span>