New Linux Botnet Exploding Log4J, DNS Tunnelling Used To Conceal Comms Traffic

By   ISBuzz Team
Writer , Information Security Buzz | Mar 17, 2022 06:43 am PST

A new Linux botnet, named B1txor20 was found exploiting Log4J, targeting Linux systems and infecting dozens of vendors who are using the vulnerable Apache Log4j logging library. The botnet uses the exploit to steal sensitive information, install rootkits, create reverse shells and act as web traffic proxies. What makes this bot unique is that it was using DNS tunnelling to conceal its communication traffic – an old but reliable technique.

Subscribe
Notify of
guest
1 Expert Comment
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Michael White
Michael White , Technical Director and Principal Architect
March 17, 2022 2:43 pm

Sometimes, when planning remediation, security experts will consider ‘is an exploit available?’ when making their determination as to what level of urgency to assign. This illustrates that the exploit authors gain sophistication over time. So, it’s no longer just a question of is there an exploit, but rather how sophisticated has the exploitation become. To me, this looks like a renewed second wave of exploitation. It may even build on from here, and perhaps become easier and easier to achieve nefarious outcomes.

It’s interesting to note as well that this targets not just X86 devices as seen in PC’s and servers, but also ARM – so devices which are perhaps embedded IoT products, or maybe even mobile phones. We are always reminded that Java runs anywhere – and on billions of devices. The consequence of that portability is likely to be widespread exploitation of this flaw.

Since these embedded systems are likely to be much harder to patch and keep up to date, this exploitation campaign could be running for a very long time and cause sleepless nights for a lot of enterprises. Without SBOM information for all the network-connected systems, the initial inventory itself will be a massive undertaking. Whilst it is clear log4j is far from over, we really need to be planning for the next log4j type event. Because there will be more. And the answer to that is to get enterprise SBOM initiatives established and to start requiring this information from vendors.

Last edited 2 years ago by Michael White

Recent Posts

1
0
Would love your thoughts, please comment.x
()
x