<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Java on Cliff Hults</title><link>https://www.haguest.com/tags/java/</link><description>Recent content in Java on Cliff Hults</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 Cliff Hults</copyright><lastBuildDate>Thu, 16 Dec 2021 14:59:43 -0500</lastBuildDate><atom:link href="https://www.haguest.com/tags/java/index.xml" rel="self" type="application/rss+xml"/><item><title>Log4j Scanning and Detection</title><link>https://www.haguest.com/posts/2021-12-16-log4j/</link><pubDate>Thu, 16 Dec 2021 14:59:43 -0500</pubDate><guid>https://www.haguest.com/posts/2021-12-16-log4j/</guid><description>&lt;p>Lately, everyone has been talking about Log4Shell (CVE-2021-44228) and likely, if you&amp;rsquo;re reading this, you&amp;rsquo;re looking for info for what to do. Most people attempted to utilize &lt;a href="https://log4shell.huntress.com/" target="_blank" rel="noreferrer">Huntress&amp;rsquo;s Log4Shell detection tool&lt;/a> to show connections to a LDAP server they were hosting. Some people had issues with this as it was overburdened with requests (rightfully so) or didn&amp;rsquo;t want to, or aren&amp;rsquo;t allowed to send outbound traffic to a server they didn&amp;rsquo;t own. At our organization, we were part of the latter group. In order to comply with our rules, we needed to find a reliable way to scan our devices for the vulnerability and look for requests to a domain that we owned.&lt;/p></description></item></channel></rss>