Just in time for the holiday season, and at a time when cybercriminals are generally most active, industry experts discovered a critical vulnerability in a software commonly used by companies. The software, Apache Log4j, is a popular Java library for logging in applications. The vulnerability enables a remote attacker to take control of a device, potentially enabling cybercriminals the opportunity to steal sensitive data and deploy ransomware.

To combat this potentially devastating operational and legal outcome, IT security teams have been feverishly implementing patches to fix this vulnerability.  Over the holidays, network scanners everywhere have been abuzz, searching for unpatched vulnerable systems. However, many organizations have found that they lack full inventories of all the software they use, making patching difficult and a never-ending game of whack-a-mole. Further, vendors and cloud-service providers are still struggling to issue fixes to all of their software products.

To add to the feeling of exhaustion and discontent, researchers say this flaw has been around for years, some estimate back as far as 2015. According to the US Cybersecurity and Infrastructure Security Agency (CISA) director Jen Easterly, the vulnerability is already being used by a “growing set of threat actors.” As such, industry experts expect that this incident will follow a pattern like the recent Hafnium attacks, where the whack-a-mole approach proved far from sufficient.

In the recent Hafnium attacks, where cybercriminals exploited vulnerabilities in Microsoft Exchange, cybercriminals engaged in large scale exploits of this zero-day to obtain initial access across a large footprint of organizations. In that case, web shells were deployed and exploited months later, frequently ending in file exfiltration and then ransomware. As such, while many companies patched their systems, the patching was insufficient because it occurred after the attackers established their persistence.

The key failure in the Hafnium story is that many organizations focused solely on patching their systems and failed to further investigate for signs that the attackers were already present.  Such indicators include, for example, Cobalt Strike beacons, strange DNS requests and other possible instances of C2 (command and control) activity. Unfortunately, for victims of the Hafnium attacks, the results were costly.  Accordingly, the key to respond to the Log4J cybersecurity vulnerability is to actively look now for tell-tale signs that attackers are present, as part of a more comprehensive approach to cybersecurity.

What should my organization consider implementing going forward?

Government cybersecurity agencies in the United States, Canada, the United Kingdom, Australia and New Zealand (collectively known as the “Five Eyes”) issued a joint cybersecurity advisory on Wednesday, December 29th to provide guidance on addressing Log4j vulnerabilities.  From a technical perspective, they recommend an organizations plan addresses each of the following technical three (3) elements[1]:

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

From a non-technical perspective, this past week, the UK’s National Cyber Security Centre likewise issued guidance for board members of medium to large organizations. In particular, they asked organizational leaders to consider the following questions[2]:

  1. What is our plan for responding to this incident? Who is leading on our response? Do they have prerequisite resources and experience to execute the plan?
  2. How will we know if we’re being attacked, and can we respond? Is there evidence of prior exploitation of this vulnerability?
  3. What percentage visibility of our software/servers do we have? Do we have an adequate inventory of assets to allow quicker identification next time?
  4. How are we addressing shadow IT/appliances? And any Bring Your Own (BYOD) Devices and applications?
  5. Do we know if key supply chain providers are covering themselves adequately?
  6. Does anyone in our organization develop Java code? If so, how will people report issues they find to us?
  7. When did we last check our business continuity plans (BCP), disaster recovery and crisis response?
  8. How are we preventing technical teams from burning out?

If the answers you receive are not inspiring confidence, then an organization’s leadership may seek to supplement its internal capabilities with outside experts. While every entity’s cybersecurity needs are different, organizations should ensure that it has implemented at least the following as part of its comprehensive approach to answer these questions and mitigate its risk of a cybersecurity incident.

  1. Conduct a Cybersecurity Risk Assessment (“Assessment”). In general, the purpose of an Assessment is to identify cybersecurity vulnerabilities in an organizations policies, procedures, and IT environment and to provide remediation strategies as appropriate. For the Log4J cybersecurity vulnerability, an Assessment may identify exploit attempts and secondary attackers’ actions, which include deploying crypto miners, ransomware, botnet activity and commodity malware deployment. As best practice, Assessments should be conducted by an independent IT Security firm, at the direction of counsel, to protect the Assessment’s findings under Privilege.
  2. Prepare a Written Cybersecurity Policy. A written cybersecurity policy sets forth an organization’s policies and procedures for the protection of its information systems, particularly its sensitive business information. The cybersecurity policy should address key areas of concern, to the extent applicable, such as data governance and classification, customer data privacy, and vendor and third-party service provider management. To instill a “tone from the top” culture, the cybersecurity policy should be approved by a senior officer or the organization’s board of directors.
  3. Develop or update your Incident Response Plan (IRP). Many industries and jurisdictions require organizations to have a policy addressing how the company with effectively respond to a cybersecurity incident, like a largescale exploit of the Log4J cybersecurity vulnerability. An IRP sets forth the key steps that organizations need to immediately take during a cyber-incident. For example, an IRP will set forth reporting escalation procedures, alternative communication plans and will create a response team of stakeholders and outside experts to assist with the response.
  4. Ensure your personnel are adequately trained. Organizations should provide regular training for all personnel based upon the risks identified in the Assessment. Given that a common method of attack is through email phishing or downloads from malicious websites, an effective defense mechanism is to train your personnel on the basics of cyber-hygiene. Likewise, your response team should conduct at least yearly exercises to practice its response in accordance with the IRP. Having a well-trained Incident Response Team in place prior to an attack, positions organizations to efficiently act in a measured, calm, and unified manner.

The Log4j vulnerability is a significant event with major ramifications. History shows that inaction now leads to potential compromise later with devastating operational and legal impacts. The time to act is now. For that reason, there is no better time to ask and respond to this question:  Is my organization ready to respond to the Log4J Cybersecurity Vulnerability? 


For more information on cybersecurity related topics such as the one discussed here, please contact one of the following authors listed here.

Colin Jennings

Partner, Cleveland

T +1 216 479 8420

E colin.jennings@squirepb.com

Ericka Johnson

Senior Associate, Washington DC

T +1 202 457 6110

E ericka.johnson@squirepb.com

Michael McAndrews

CTO, PacketWatch


[1] Adapted from: https://www.cisa.gov/uscert/ncas/alerts/aa21-356a

[2] Adapted from: https://www.ncsc.gov.uk/blog-post/log4j-vulnerability-what-should-boards-be-asking