Home
Story
Log4j update: more crime, and a Five Eyes advisory.
Log4j update: more crime, and a Five Eyes advisory.
N2K logoDec 22, 2021

More criminal attacks exploit Log4j vulnerabilities, and the Five Eyes issue a joint alert on how to handle Log4shell and other issues related to Log4j. For a guide to all our coverage of Log4shell, click here.

Log4j update: more crime, and a Five Eyes advisory.

Criminal organizations continue to make hay of the Log4j vulnerabilities. The latest campaign to surface, Venture Beat reports, is using TellYouThePass, an older strain of ransomware that's been seen used mostly against Chinese targets, and that had been relatively inactive until Log4Shell gave it fresh impetus. It now joins Khonsari and Conti.

Banking Trojans are also joining ransomware in the criminal exploitation of Log4Shell. Cryptolaemus confirms seeing the Dridex banking Trojan delivered as the payload of a Log4j exploit. BleepingComputer reports that the familiar Dridex and Meterpreter malware strains have now been observed hitting vulnerable systems. Dridex, it's worth noting, has also served as a precursor to ransomware attacks.

The Five Eyes issue a joint alert on "Log4j-related vulnerabilities."

CISA this morning announced, in conjunction with its domestic and international partners, Alert (AA21-356A) Mitigating Log4Shell and Other Log4j-Related Vulnerabilities:

"The Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), National Security Agency (NSA), Australian Cyber Security Centre (ACSC), Canadian Centre for Cyber Security (CCCS), the Computer Emergency Response Team New Zealand (CERT NZ), the New Zealand National Cyber Security Centre (NZ NCSC), and the United Kingdom’s National Cyber Security Centre (NCSC-UK) are releasing this joint Cybersecurity Advisory (CSA) to provide mitigation guidance on addressing vulnerabilities in Apache’s Log4j software library: CVE-2021-44228 (known as “Log4Shell”), CVE-2021-45046, and CVE-2021-45105. Sophisticated cyber threat actors are actively scanning networks to potentially exploit Log4Shell, CVE-2021-45046, and CVE-2021-45105 in vulnerable systems. According to public reporting, Log4Shell and CVE-2021-45046 are being actively exploited."

The advice falls into three categories:

  • "Identifying assets affected by Log4Shell and other Log4j-related vulnerabilities, 
  • "Upgrading Log4j assets and affected products to the latest version as soon as patches are available and remaining alert to vendor software updates, and
  • "Initiating hunt and incident response procedures to detect possible Log4Shell exploitation."

The advice is comprehensive, specific yet brief enough to be readily actionable. The government partners also, in view of the urgency of dealing with Log4j issues, list a number of private sector resources they think organizations would do well to consult. For identifying vulnerable assets, they offer the following list:

For threat hunting and incident response, the government partners suggest these private-sector resources:

And they provide points-of-contact organizations can use to get official help:

  • "U.S. organizations should report compromises to CISA and the FBI. 
  • "Australian organizations can visit cyber.gov.au or call 1300 292 371 (1300 CYBER 1) to report cybersecurity incidents. 
  • "Canadian organizations can report incidents by emailing CCCS at contact@cyber.gc.ca.
  • "New Zealand organizations can visit NCSC.govt.nz to report incidents. 
  • "UK organizations can report a significant cyber security incident at ncsc.gov.uk/report-an-incident (monitored 24 hrs) or, for urgent assistance, call 03000 200 973." 

Update on the Belgian MoD hack.

Belgium's Defense Ministry told VRT Monday that it sustained an attack via Log4Shell vulnerabilities. The Ministry said the incident began last Thursday, and that, while it's been working to contain the exploitation and keep networks running, some portions of its networks have been unavailable. The Ministry's Facebook page yesterday posted a note telling inquirers not to expect full service from its sites yet. "Because of technical problems, we are unable to process your requests via www.mil.be or answer your questions via Facebook. We are working on a solution and thank you for your understanding."

SC Magazine points out that, while Belgium's Ministry of Defense may be the first prominent government victim of Log4Shell exploitation, such exploitation could reasonably be expected to be inevitable, and it's likely that more official bodies will be hit using such exploits.

The Register quotes Belgium's Centre for Cyber Security (not a Ministry of Defense organization) as saying, with what the Register suspects is some interagency Schadenfreude, "Companies that use Apache Log4j software and have not yet taken action can expect major problems in the coming days and weeks." NATO, whose headquarters are in Brussels, didn't respond to the Register's inquiry about whether the Atlantic Alliance's networks were affected.

L'Avenir's take is that the incident was both foreseeable and, probably, preventable. The publication notes that the attack occurred four days after CERT-be issued its own version of the warning most national cybersecurity authorities shared, urging a prompt upgrade to Log4j version 2.17.0 or later.

There's no attribution, so far, of responsibility for the incident. Both nation-state intelligence services and criminal organizations have exploited vulnerabilities in Log4j. Threatpost, for example, has an account of the attack chain the Conti ransomware gang is using to take advantage of Log4Shell.

Hack DHS bounty program expanded to include Log4j vulnerabilities.

US Secretary of Homeland Security Mayorkas tweeted his Department's expansion of its bug bounty program to include Log4j: "In response to the recently discovered log4j vulnerabilities, @DHSgov is expanding the scope of our new #HackDHS bug bounty program and including additional incentives to find and patch log4j-related vulnerabilities in our systems."

Put a bouncer on the rope line, and other industry advice on dealing with Log4j vulnerabilities.

Some industry perspective on treating a server as if it's Studio 54. Nigel Thorpe, Technical Director at SecureAge, wrote with advice on securing servers:

“Software is complex. That's why there will always be vulnerabilities. The log4j vulnerability illustrates why organizations cannot just rely on cybersecurity training and on tools that look for code, patterns and behavior that we already know is malicious. After all, until recently everyone thought that log4j was just a neat way for services to log their actions. Now we know that unpatched, log4j provides a way for cybercriminals to get their malware into systems.

"All the affected services run on servers that are tightly controlled. Sure, their customers probably click on malicious links on a regular basis, but the servers themselves should be tightly wrapped up. So why continue to try and identify the potentially infinite universe of malware when we know precisely what is authorized to run on these servers? Why not simply allow all the known, approved processes to execute, and block everything else?

"All malware has to execute so that it can achieve its aims, whether it's data theft, opening a backdoor or scrambling all your data. And we know that all malware should be blocked. So let's put some simple, pragmatic controls in place. It's like a bouncer at a club, 'You're not on the list so you're not coming in.'”

Mike Saxton, Chief Technologist at Booz Allen and Director of Federal Threat Hunt and Digital Forensics and Incident Response (DFIR) explains that the Log4j vulnerability shows the importance of adopting a move to persistent threat hunt operations.

“CISA is urging organizations to be on heightened alert for cyberattacks during the holidays, as malicious actors seek to exploit vulnerabilities while security teams are short staffed. And, CISA released an Emergency Directive for all federal civilian organizations to implement mitigation steps for the Log4J vulnerability, ahead of 12/23 and 12/28 deadlines. Here are some actions organizations can take in the short and long-term to mitigate the impact of Log4J and prevent future attacks.  

He recommends immediate action on some short-term steps:

"Most immediately, organizations must establish and see through a plan that begins with the following: 1) Implementing sensor blocks; 2) Disabling Log4J; 3) Identifying and patching vulnerable versions; 4) Disabling JNDI lookups; 5) Disabling remote codebases; 6) Performing scan with updated vulnerability management templates; 7) Performing searches and analysis of all security logs for evidence of enumeration or compromise; 8) consolidating, Communicating, and Disseminating updated threat intel associated with Log4j; 9) Tracking all remediation and mitigation efforts and tasks; 10) Continuing to apply up-to-date blocking measures; 11) Monitoring LDAP traffic; and, 12) Moving vulnerable systems behind additional firewalls. This list may seem overwhelming, but it should be viewed as a template rather than a checklist that organizations can follow."

Looking farther out, Saxton has other recommendations:

"In the long-term, organizations should move to a persistent threat hunt model and take the position of ‘assumed breach’ of vulnerable assets. Specific steps they can take include: 1) Continue to monitor java application and LDAP logs; 2) Understand and hypothesize log4j exploitation as an attack vector to get a foothold; 3) Continue to search for all running Java instances; and, 4) Monitor for Cobalt strike, or other adversary TTP, known indicators of compromise. Finally, organizations should be cautious to still monitor for other vulnerabilities, such as the Microsoft Active Directory vulnerability, while attention is on Log4J.”