Cloud Hosting

More and more organizations utilize cloud technology for applications, file storage, and more. However, if an attacker compromises a cloud environment, organizations may not know how to investigate those technologies, or may not even be logging the evidence that could allow the organization to identify what an attacker did.

This blog post describes a hypothetical scenario of a cloud platform compromise with multiple components that would require investigation. Each component is an example of a real intrusion tactic that Mandiant has investigated across various cloud platforms, sometimes with logs available and sometimes without logs available.

For each part of the compromise, we provide recommended logging configurations and investigation processes organized into cloud technology themes that group cloud services from Google Cloud Platform (GCP), Amazon Web Services (AWS), and Microsoft Azure together:

After reading through this scenario, you should be able to:

While we review many concepts, there are some limitations to be aware of in the scope of this post:

The attacker gained access to the Cloud Email platform through a credential stuffing attack against a cloud administrator account. Once the attacker found a valid password, the attacker authenticated with those credentials and the Cloud Email platform asked them which type of multi-factor authentication (MFA) process they preferred. The attacker chose the push option, which sent an approval request to the legitimate user. The administrator user deals with push authentication requests throughout the day for various services and mistakenly accepted the authentication request, which provided initial access to the attacker.

Once the attacker identified the cloud administrator credentials and authenticated, they logged in to the Cloud Management Console to identify other applications that the user could access.

The attacker identified that the cloud administrator account had access to the Cloud Authentication Services application and authenticated to it. In the Cloud Authentication Services application, the attacker changed the privileges of the cloud administrator to the highest global administrator account privileges available and removed the multi-factor requirement.

While in the Cloud Management Console, the attacker identified that the organization uses a custom Cloud Application. The attacker accessed the Cloud Code Repository with the global administrator account and identified the Cloud Application source code hosted there. The attacker accessed the code and identified plain-text hard-coded credentials for an application service account.

While in the Cloud Authentication Services application, the attacker identified that the Administrator had access to the Cloud Logging platform. The attacker authenticated to the Cloud Logging platform and searched logs for keywords related to plain-text credentials. The attacker exported logs that contained those keywords, particularly database user credentials.

The attacker returned to the cloud Authentication Service application and performed reconnaissance on systems and users. The attacker exported all environment objects including systems and accounts.

Next, the attacker pivoted to the Cloud Virtual Machine infrastructure and created a templated virtual machine. The attacker assigned the virtual machine to the application service account previously identified in the application source code. The attacker configured the Cloud Networking rules to allow remote desktop protocol (RDP) access from the internet. The application service account did not require MFA for any authentication activity because of its intended use. The attacker logged on to the virtual machine through RDP from their command and control (C2) server.

While logged on to the newly created virtual machine, the attacker identified a database server based on the hostname SQLDB01. The attacker moved laterally from the virtual machine they created to the database server via RDP using the application service account.

The attacker connected to the database, which utilized a Cloud Database Service backend, using the database user credentials previously identified in logs and explored the data by enumerating the table schema and running select * queries.

While logged on to the attacker-created virtual machine, the attacker also performed internal reconnaissance to identify other systems of interest. The attacker scanned the network for other systems using custom port scanning utilities that searched for open SSH, RPD, and SMB ports.

The attacker identified a network-shared file server that hosted files on a Cloud File Storage solution. After enumerating files stored on the network share, the attacker copied files to their C2 system using a bulk network file transfer utility.

While accessing the file server, the attacker also decided to stage further backdoors in trojanized files that are likely to be opened by users.

While logged on to cloud email for the administrator account, the attacker browsed through the last several days of messages. The attacker looked at email folders named finance and hr and downloaded attachments from sent messages.

The attacker shared the uploaded trojanized backdoor file through the collaboration platforms file sharing service with 20 users.

Several users messaged the administrators account and asked questions about errors opening the new document they downloaded through the collaboration platform based on an automated file shared email link. The attacker replied to tell the users the document is legitimate.

Finally, in an attempt to delay detection, the attacker created a mailbox rule to automatically delete replies to the compromised file share email.

The aforementioned hypothetical scenario took place in a matter of several days, reflecting how quickly the threat actors moved in the real scenarios this one is based on. In these cases, information security teams commonly have only a few medium priority alerts fire that go unnoticed due to the abundance of alerts feeding from their tools.

In this scenario, suspicion started when several helpdesk team members realized they had separate reports of users who had suspicious files shared with them. The helpdesk team escalated to Information Security per their documented processes and the Incident Response (IR) team started an investigation into the cloud file sharing platform associated with the file sharing.

The IR team quickly realized that the default logging available with their lowest cost license subscription recorded many useful logs such as:

Unfortunately, the investigation could not answer the question did the attacker access any email messages or synchronize any mailboxes? due to the default logging levels. The IR team also realized they were lucky the incident was detected relatively quickly because the default license subscription only stored logs for 90 days with their Cloud Logging platform.

After a post-mortem review several months later, the organization realized the IR team only reviewed collaboration platform authentications and did not cross reference against domain authentication logs. This meant that the internal team never identified that the attacker compromised the cloud infrastructure platform and performed follow-on activities such as creating and accessing a VM, elevating to domain administrator privileges, and interacting with file servers. They focused only the collaboration platform because the initial incident identification occurred after the sharing of files on the Collaboration Cloud File Sharing platform. The investigation had to be reopened several months later when evidence had started to disappear from Cloud Logging sources.

As the scenario demonstrates, attackers have a wider surface area to persist and steal data because of the adoption of cloud infrastructure and collaboration platforms. The move to these cloud platforms brings useful functionality and security features, but configuring everything correctly can be overwhelming for a team that is new to the technology.

Not only are there many access, permission, and protection configurations to consider, but teams should also make sure that they would be able to fully investigate various attacks that could happen by storing the correct logs.

Understanding what technologies your organization uses and performing threat modeling is one way to make sure you have these logs and investigative processes set up should you need to investigate.

For details on how Mandiant can assist with your cloud security, please check out the following resources:

The following attack path diagram visualizes how the actor accessed a wide range of cloud platforms from outside a standard perimeter in this scenario. The actor also used cloud technologies to interact with systems in the non-cloud environment as well through connections and integrations.

The following checklist is designed to be copied or printed for your cloud infrastructure logging review efforts. The provided logs are example categories of commonly utilized event logs for forensic investigations.

Reference Number

Technology

Log Type

1.1.1

Cloud Virtual Machines

Configure system event logs to follow standard endpoint logging policies for authentication, user activity, and privileged account use.

1.1.2

Cloud Virtual Machines

Log virtual machine management actions such as Start, pause, backup, snapshot, create, delete, and command executions etc.

1.1.3

Cloud Virtual Machines

Forward system logs to a log management platform or SEIM as part of standard polices and processes.

1.2.1

Applications or Functions

Log web server access to application including source IP address, protocol used, request parameters, response status, user agent, referrer, and response size. Ensure that source IP address is not overwritten by proxy or load balancer technology.

1.2.2

Cloud Applications, Containers, and Functions

Log creation, modification, and access to application code.

1.2.3

Cloud Applications, Containers, and Functions

Record successful and failed authentication activity including source IP address.

1.2.4

Cloud Applications, Containers, and Functions

Log application user activity including user account, information viewed, actions performed, and sensitive data accessed.

1.2.5

Cloud Applications, Containers, and Functions

Forward system logs to a log management platform or SEIM as part of standard polices and processes.

1.3.1

Cloud Database Services

Log database user authentication and source network address.

1.3.2

Cloud Database Services

Log data access including source network address and user.

1.3.3

Cloud Database Services

Log data modification and deletion including source network address and user.

1.3.4

Cloud Database Services

Forward system logs to a log management platform or SEIM as part of standard polices and processes.

1.3.5

Cloud Database Services

Log errors and long running queries, which could be indicative of data transfer or reconnaissance.

1.4.1

Cloud File Storage

Log user authentication.

1.4.2

Cloud File Storage

Log file creation, modification, upload, and deletion events with user account, IP address, and timestamp.

1.4.3

Cloud File Storage

Log file download events with user account, source IP address, and timestamp

1.4.4

Cloud File Storage

Log location, folder, and file permission changes.

1.4.5

Cloud File Storage

Log API access to file storage locations, folders, and files.

1.4.6

Cloud File Storage

Log file and directory listing metadata view.

1.4.7

Cloud File Storage

Turn on alerts for suspicious activity, including malware and mass downloads, if available.

1.5.1

Cloud Authentication Services

Log user authentication with timestamp, username, and source IP address.

1.5.2

View post:
Cloudy with a Chance of Bad Logs: Cloud Platform Log ... - Mandiant