Data exfiltration is defined as when an unauthorized person extracts data from the secured systems where it belongs and moves it to insecure or unauthorized systems. Data exfiltration on the cloud could therefore mean the unauthorized movement of data from cloud resources. This is a result of a violation of basic cybersecurity practices.
Malicious actors can exfiltrate data from cloud drives if data is uploaded to insecure or misconfigured resources. Another concern is when a user provides extensive access permissions to cloud-based storage, exposing data to unauthorized parties.
Employees, system administrators, and trusted users are examples of authorized individuals.
Organizations must incorporate security awareness and best practices into their culture to limit the danger of data exfiltration.
They must assess the hazards of all interactions with computer networks, devices, applications, data, and other users on a regular basis.
Periodic audits may also be implemented by organizations to ensure that best practices are being followed.
Data exfiltration results in security data breaches that may have multiple consequences. They include but not limited to;
- Loss of Intellectual property and other sensitive information
- Expensive incident response process.
- Information misuse or abuse
- Loss of client’s trust
- Lawsuits and other legal issues
Exfiltration on S3
S3, the Amazon Simple Storage Service, is an essential data repository for most organizations.
With more sensitive data flowing into S3 buckets every day, AWS offers well-established best practices for securing that data. However, managing and protecting sensitive data in flexible data repositories like S3 raises important questions for security:
- Access control: Can you manage access consistently across S3 and other types of repositories for your team and the applications they use?
- Monitoring: Can your security and compliance teams know who’s got access to your S3 buckets, and what actions they’re taking?
- Auditability: Can you report to your users in detail about how you’re protecting their S3 data, and can you assure them of exactly who has access—and who’s had access—to their private data that they’ve entrusted to you?
Data stored on S3 can mistakenly be exposed to the internet due to misconfigurations.
when an S3 bucket is misconfigured, hackers might be able to:
- list the data it contains (that is, folders and files);
- download data, including recursive downloads to copy entire folders;
- replace data; and
- delete data
With the everyday evolution in security, offensive security experts have developed tools that if abused could help hackers exfiltrate data from S3 storages. This will happen due to a Broken Level Object Authorization flaw, that is, where access control measures have been poorly implemented.
Data exfiltration in S3 will occur when the READ permission in a bucket has been set to a world level. This means that an S3 bucket has been configured to allow anonymous users to read the contents of a bucket.
How to find S3 buckets of a target application:
There are multiple ways to find an associated Amazon s3 bucket of the target application.
- Using Google dorks to find s3 buckets
site: s3.amazonaws.com <site.com>
- Use of CLI tools from Github for bucket enumeration and listing assets.
Some of these tools include;
To check for misconfiguration of Amazon S3 buckets (ACLs) permission you need to install AWSCLI
You then have to configure it by adding your AWS account credentials, that is, Client ID and Client Secret.
The next thing is checking for misconfigurations, which if present, will lead to data exfiltration.
How to list the permissions of a misconfigured Amazon S3 Bucket.
aws s3api get-bucket-acl — bucket <bucket-name>
How to list the contents of a misconfigured Amazon S3 Bucket.
aws s3 ls s3://<bucket-name>
- If the bucket has misconfigured ACL permissions,you can use this command to download data from an S3 bucket to your local system. (Bley-Vroman)
aws s3 sync s3://<bucket>/<path> </local/path>
- EC2 Metadata IP. AWS provides instance metadata for EC2 instances via a private HTTP interface only accessible to the virtual server itself. While this does not have any significance from an external perspective, it can however be a valuable feature to leverage in SSRF related attacks. The categories of metadata are exposed to all EC2 instances via the following URL: http://169.254.169.254/latest/meta-data/
- Attackers may stumble on leaked AWS Client ID and Client Secret Keys on Github, Gitlab. If an attacker gets access to the keys associated with an Amazon Relational Database (RDS) and takes snapshots of these resources, they can deploy a new RDS database based on the snapshot. And when they do that they get to reset the passwords associated with the database. So now they’ve got access to all of your data without actually having to have the passwords required on the RDS instance. It’s the same case with the EBS (Elastic Block Store) snapshot. For example, assuming they’re able to create an SSH key pair in your account, they could launch a new instance from the snapshot and assign their key pair to the instance, giving them full access to the data of the original instance. If they can’t create SSH keys in your account, they might try to mount the snapshot to an existing instance they can already access. (D’Aquino)
- EC2 instances running data storage services like Elasticsearch and MongoDB, which by default don’t have any credential requirements to interact with the data store also adds up one of the common issues that lead to data exfiltration. If the security groups are not set up properly you can inadvertently expose, for example, the Elasticsearch port (9200) out to the Internet. If that happens, you can bet that somebody is going to find it and dump its entire data set. It’s become so common that adversaries have gone through the trouble of creating ransomware that fully hijacks the data store and encrypts the data within it(D’Aquino). To find publicly exposed Elasticsearch databases, an attacker will use the following dork on Shodan;
- Application abuse. A crafty attacker will bang on a web application long enough to find a vulnerability that they can use to exfiltrate data from the system. This technique is very effective because most web applications need access to some degree of sensitive data in order to be of any use. A good example is the Facebook Data breach where three software flaws in Facebook’s systems allowed hackers to break into user accounts. (D’Aquino)
Exfiltration on GCP
Google Cloud Platform (GCP), offered by Google, is a suite of cloud computing services that runs on the same infrastructure that Google uses internally for its end-user products, such as Google Search, Gmail, file storage, and YouTube.(WIkipedia)
Google Storage is a service offering through GCP that provides static file hosting within resources known as “buckets”. They are similar to the AWS S3 buckets.
Google storage buckets can be enumerated using a tool known as;
GCPBucketBrute. It allows you to check every discovered bucket for what privileges you have on that bucket so you can determine your access and if the bucket is vulnerable to privilege escalation.
Google storage buckets can be accessed from the terminal using the gsutil command.
One of the ways the gsutil command helps in data exfiltration is by enabling the transfer of data from the cloud to the local machine.
Data exfiltration event categories on GCP
- Outbound mail.
In this scenario, actors use authorized telecommunications infrastructure, such as business email or mobile devices, to transmit sensitive data from secure computer systems to untrusted third parties or insecure private systems. The sensitive data can be transmitted as plain text in an email or text message, or attached as a file. This method is often used to exfiltrate the contents of organization emails, calendars, databases, images, planning documents, business forecasts, and source code
- Uploads to external services.
the data to a third-party through a web browser client or other unmonitored software. Sophisticated malicious actors may be able to pass small amounts of sensitive data, like user credentials or encryption keys, as URL parameters to specialized web applications.
- Rogue administrators.
Malicious or compromised administrators will have sufficient permissions to perpetrate any of the scenarios discussed in this document, and furthermore have the greatest ability to obliterate logs and evidence of their actions.
- Employee terminations.
Employees are more likely to engage in data exfiltration when they anticipate imminent termination.
Because of the flexibility, cost savings, and power of public cloud infrastructure, heightened attention and innovative methods to data security are required.
Using methods, you may architect your organization’s policies and implementations to account for the environment. You can use the following techniques:
- Minimize the “blast radius” of data exfiltration events through compartmentalization of data.
- Create redundancy and approvals in system administrator workflows to increase accountability.
- Use granular permissions and grant access to sensitive data only to those whose job function requires it.
- Use logging to increase the transparency into the access and movement of data in your organization.
- Restrict and monitor ingress and egress to machines in your organization using networking rules, identity and access management (IAM), and bastion hosts.
- Create a baseline of normal data flows, such as amounts of data accessed or transferred, and geographical locations of access against which to compare abnormal behaviors.
- Control privilege to keep insider risks, both benign and malignant, under control.
- That means only granting the bare minimum of privilege; dynamically controlling privilege so that when an employee’s reason for accessing a sensitive system no longer exists, they lose access; and systematically revoking privilege for former employees from the moment their employment ends, rather than waiting a week or two to clean up old accounts.
It’s a difficult task to prevent and mitigate data extraction tactics. You must contend with potential attackers as well as possibly negligent staff. However, if you take a complete cybersecurity approach, you’ll have a good chance of overcoming these obstacles.