Criminals frequently elude law enforcement by committing their crimes in multiple jurisdictions. When seeking to bring these criminals to justice, law enforcement agencies must share information and work to eliminate jurisdictional gaps that can hinder investigation and prosecution.
You have these same types of “jurisdictional gaps” in your IT environment, and cybercriminals take advantage of them to evade detection and complicate investigation efforts. “What?! How absurd!” I hear you protest. “There’s no one telling me where and what I can look at.” Let me explain …
In cyberspace, you now have several different attack surfaces. Whereas your data and applications previously resided on-premises behind your enterprise firewall, today they are dispersed across your corporate network, the public cloud, and SaaS providers—your modern attack surfaces . In the old world, you had a fairly defined perimeter to guard. Today, the perimeter is identity and access management.
Once they acquire credentials (EA Games is the latest exhibit to show how this happens, even with MFA), attackers cross the boundaries of your attack surfaces with ease while you are left trying to correlate the data after the fact, piecing together the story of what happened.
How did hackers break into EA and steal all that source code? A stolen cookie purchased for $10 gave them access to Slack, then social engineering got them an MFA token to access network resources. Basically: https://twitter.com/thegrugq/status/563964286783877121
— thaddeus e. grugq (@thegrugq) June 12, 2021
Finding Cloud Cybersecurity Gaps
For example, imagine that an attacker gets hold of some long-term keys that were copy-pasted in Slack, and that they use those credentials to log into a company AWS account. They use a trusted Amazon machine image (AMI) to launch an EC2 instance running an Ubuntu server. This server mounts an AWS S3 bucket containing sensitive data, and the Ubuntu OS software utilities have access to that data.
Next, the attacker launches a script that invokes a curl executable, invoking a DNS lookup to a known-malicious domain. The EC2 instance establishes a TCP/IP socket with a known-malicious IP address. The curl executable then establishes an HTTP TLS connection that matches JA3/JARM signatures and, finally, exfiltrates a file from the S3 bucket.
In the above scenario, consider the ease with which the attacker moves across “jurisdictional boundaries” in the IT environment—from the cloud control plane to the machine operating system. To understand the context and severity of the attack, you need to correlate AWS API-based data with what’s going on inside the EC2 instance.
For the AWS API-based data (the cloud control plane), you need:
- The details about the IAM account that the attacker used
- The details of the EC2 instance they launched
- The configuration information and access information about the S3 bucket where the data was stored
- CloudTrail activity, which captures details about:
- The user connecting with certain IAM credentials
- That they an EC2 instance from a trusted AMI
- That the EC2 instance runs the Ubuntu operating system, which is actually doing something malicious
For what was going on inside the Ubuntu virtual machine (the data plane), you would want to see:
- Process events showing that a curl command had been launched
- The process hierarchy showing:
- The shell that was created due to SSH login with a terminal
- Subsequently, the terminal was rooted all the way up to the initd process
- When the socket connection was established, and:
- The reputation of the IP address for the connected socket
- The reputation of the DNS domain, HTTPS URL, and HTTPS JA3/JARM signature
- Additionally, if a file was copied to a certain location before it was transmitted, you would want to know if the creation of the file was based on a certain folder location, which might be a leading indicator of malicious activity
Close The Gaps In Your Cloud Security
Enter cloudquery. Released by Uptycs as an extension to the open-source osquery project, cloudquery enables detection and investigation scenarios that correlate telemetry from your cloud provider APIs and system internals. Cloudquery also makes it easy to ensure compliance and perform audits of your cloud infrastructure configurations.
The security community embraced osquery as a way to gather and normalize telemetry from endpoints running macOS, Linux, and Windows in the form of SQL tables. Now cloudquery does the same for cloud logs so that security teams can ask questions and get answers about their cloud infrastructure: useful during investigations and also for simplifying tasks like auditing configurations.
Uptycs security engineer Eric Kaiser presented Structured Security Analytics for Cloud Workloads at the SANS CloudSecNext Summit 2021, explaining how cloudquery and osquery work together to close the visibility gap between the data plane and control plane in the cloud.
Since then, Eric has distilled an introduction to cloudquery into an on-demand training resource, Simplifying cloud infrastructure security with cloudquery: an introduction to structured security analytics for multi-cloud environments.
Uptycs closes visibility gaps for faster detection and investigation
Uptycs provides you with the comprehensive visibility needed to understand what’s happening at the data plane and control plane. As your modern attack surfaces proliferate and grow, you need to be able to correlate your security telemetry from all those various sources. This equips you to track down and halt attacker activity wherever it occurs.