At this point, no one in the security space is a stranger to the Log4J JNDI vulnerability. It caused notable noise in the industry and ruined more than a few holiday plans. At its core, Log4J is an injection vulnerability allowing attackers to exploit systems via remote code execution. In the public cloud domain (specifically AWS), this can manifest as an attacker extracting secrets stored in environment variables. In addition to statically stored secrets, our Security Research team at Vectra recently highlighted methods to use the Log4j injection vulnerability to extract temporary credentials from the largest attack surface in AWS—the EC2 Instance.
By now, you can find numerous articles discussing how to secure an organization against the Log4j vulnerability to limit the blast radius of a related compromise—from installing patches to rotating credentials. However, it’s important to understand that there are some challenges with only relying on these means for remediation. Including:
- Not all systems can be patched quickly, leaving a window of exposure. It takes time to deploy patches, and in many cases there will be dependencies on vendors or service providers that are outside of the control of IT.
- There will be a next time. The Log4J exploit certainly won’t be the last we encounter. Simply relying on limiting the blast radius affords attackers too much time within environments to infiltrate sensitive assets and cause havoc.
- Once the attacker is in, patching the points of initial compromise won’t help a whole lot. The attacker can extract different credentials, progress through machines, establish command and control channels through servers, containers or serverless code and negatively impact organizational assets, services, and data leading to business disruption and sensitive data loss.
Over-reliance on patches and post-compromise restoration has led to the SOC constantly playing catch up to the exploit of the day. What is required in addition to patching, is the ability to quickly detect attacker progression once in, providing resilient protection no matter what the next exploit is.
Detecting Attack Progression in Cloud is a Hard Problem to Solve
Tracking entity behavior and identifying changes made to a cloud environment is extremely difficult to perform in real time. What’s more, it can be nearly impossible to tell the difference between a regular user with credentials from a malicious attacker using the same compromised credentials.
But Worry Not, We Have Some Good News—Vectra Detect for AWS Has You Covered
Detect for AWS uses security-led AI to detect attacker behavior in the AWS Control Plane. For example, Vectra will fire the 'AWS Suspicious Credential Usage' when EC2 instance credentials are used outside the AWS IP space. This facilitates the identification of stolen credentials (from remote code execution using Log4J) being used to access resources. Within the perimeter, Detect continuously monitors accounts and services across regions to promptly identify malicious attacker behavior across the cloud kill chain (discovery, lateral movement and exfiltration). Examples of attack paths an attacker may take, include:
- Accessing and modifying AWS Lambda functions to perform actions that benefit the attacker. Detect identifies and highlights occurrences of lambda hijacking.
- Various privilege escalation techniques including creation of new user profiles to maintain persistence. Detect identifies the behavior associated with granting admin privileges and monitors creation of new user profiles.
- Spinning up AWS resources in unmonitored regions and exposing resources to the public. Detect would trigger alerts showing activity in previously unused regions and call attention to instances where resources are exposed to the outside world.
From modification of resources to attempts at privilege escalation and exfiltration from data stores, Detect ensures coverage without blind spots. Using Vectra’s security-led AI, Detect attributes all actions to a principal even if they act through a chain of assumed roles to gauge whether the activity and therefore the principal, should be deemed malicious. This means a SOC analyst doesn’t have to waste time identifying the principal that was compromised.
Additionally, using the Instant Investigations feature, Detect provides critical context into the actions being performed by the highlighted principal around the time of the suspicious activity. This includes, amongst other valuable insights, the services used, history of roles assumed and the regions in which the principal was active. Believe it or not, this information that traditionally took hours to figure out is now available at the click of a button using Instant Investigations!
As cloud footprints grow exponentially, attackers need only a single opening to infiltrate cloud environments and create backdoors to establish persistence. Log4J is not the first, and certainly won’t be the last in the broad gamut of vulnerabilities attackers exploit to compromise cloud footprints. Infrastructures are incredibly complex encompassing dozens of services that in modern DevOps pipelines, are in constant flux. As speed and agility increase, so does the risk of introducing security issues. Early identification of these attack vectors is pivotal in mitigating risk and facilitating sagacious response strategies. In today’s world where cloud deployments are growing at a never-before-seen pace, the importance of equipping the SOC with the right tools cannot be overstated and Detect makes a formidable addition to the SOC’s arsenal. Sounds exciting? Learn more about Detect and sign up for a free trial.