Heartbreaker-Denouement

Description

Your digital forensics expertise is critical to determine whether data exfiltration has occurred from the customer’s environment. Initial findings include a compromised AWS credential, indicating a potential unauthorized access. This investigation follows from a customer report of leaked data allegedly for sale on the darknet market. By examining the compromised server and analyzing the provided AWS logs, it will not only validate the customer's breach report but also provide valuable insights into the attacker's tactics, enabling a more comprehensive response.

Files

└─$ 7z x HeartBreakerDenouement.zip -p'hacktheblue'
└─$ find . -maxdepth 2
.
./AWS
./AWS/ap-northeast-1
./AWS/ap-northeast-2
./AWS/ap-south-1
./AWS/ap-southeast-1
./AWS/ap-southeast-2
./AWS/ca-central-1
./AWS/eu-central-1
./AWS/eu-north-1
./AWS/eu-west-1
./AWS/eu-west-2
./AWS/eu-west-3
./AWS/me-south-1
./AWS/sa-east-1
./AWS/us-east-1
./AWS/us-east-2
./AWS/us-west-1
./AWS/us-west-2
./uac-uswebapp00-linux-20240313145552.tar.gz
└─$ find . -empty -delete
└─$ mkdir uac-uswebapp00 && tar -xvzf uac-uswebapp00-linux-20240313145552.tar.gz -C uac-uswebapp00
└─$ find ./uac-uswebapp00 -maxdepth 2
./uac-uswebapp00
./uac-uswebapp00/bodyfile
./uac-uswebapp00/bodyfile/bodyfile.txt
./uac-uswebapp00/bodyfile/bodyfile.txt.stderr
./uac-uswebapp00/chkrootkit
./uac-uswebapp00/chkrootkit/chkrootkit_-n_-r.txt.stderr
./uac-uswebapp00/chkrootkit/chkrootkit_-n_-r_-x.txt.stderr
./uac-uswebapp00/hash_executables
./uac-uswebapp00/hash_executables/hash_executables.md5
./uac-uswebapp00/hash_executables/hash_executables.sha1
./uac-uswebapp00/hash_executables/list_of_executable_files.txt
./uac-uswebapp00/live_response
./uac-uswebapp00/live_response/containers
./uac-uswebapp00/live_response/hardware
./uac-uswebapp00/live_response/network
./uac-uswebapp00/live_response/packages
./uac-uswebapp00/live_response/process
./uac-uswebapp00/live_response/storage
./uac-uswebapp00/live_response/system
./uac-uswebapp00/live_response/vms
./uac-uswebapp00/uac.log
./uac-uswebapp00/uac.log.stderr
./uac-uswebapp00/[root]
./uac-uswebapp00/[root]/etc
./uac-uswebapp00/[root]/home
./uac-uswebapp00/[root]/lib
./uac-uswebapp00/[root]/root
./uac-uswebapp00/[root]/run
./uac-uswebapp00/[root]/tmp
./uac-uswebapp00/[root]/var

Tasks

Task 1. What type of scanning technique was used to discover the web path of the victim's web server? Specify the name of the corresponding MITRE sub-technique.

Examining the access log of apache2, we can see same filenames with different extensions:

https://attack.mitre.org/tactics/TA0043/arrow-up-right

Writeup.png

The attacker used Active Scanning method and was bruteforcing directory path, so Active Scanning: Wordlist Scanningarrow-up-right

circle-check

Task 2. It seems a web request possibly could have been rerouted, potentially revealing the web server's web path to the Threat Actor. What specific HTML status code might have provided this information?

301 Moved Permanently - HTTP - MDN Web Docsarrow-up-rightRedirections in HTTParrow-up-right

circle-check

Task 3. What was the initial payload submitted by the threat actor to exploit weakness of the web server?

Filter out status code that start with 4, server error indicates that attacker's action was unsuccessful. wb-loanapp-tracker get's lots of request after successful redirect request, but method is POST and we can't see what was sent.

Writeup-1.png
circle-info

Looking into the error.log we can identify what the attacker submitted. First malicious input is file:///etc/passwd

circle-check

Task 4. What is the name of the vulnerability exploited by the Threat Actor?

In the at the end of error.log we see request input are different server and the attacker navigates up to /latest/meta-data/iam/security-credentials/EC2DatabaseConnection. What's odd is that path used doesn't belong to server (3.144.237.152) rather it's on different server (169.254.169.254). There are some 404 errors indicating incorrect movement of attacker, but at the end it's successful. Attacker was making request server (3.144.237.152) to a different server (169.254.169.254) most likely internally to leak the information.

circle-check

Task 5. At what time (UTC) did the Threat Actor first realize they could access the cloud metadata of the web server instance?

Entries which access metadata:

It seems like when SSRF was successful the attacker realized what could have been done, after that almost each path is successful request.

Check timezone of machine:

So no need to change timezone since it's already UTC.

Answer: 2024-03-13 14:06:21

Task 6. For a clearer insight into the Database content that could have been exposed, could you provide the name of at least one of its possible tables?

I was able to find mysql_history for the user on server

circle-check

Task 7. Which AWS API call functions similarly to the 'whoami' command in Windows or Linux?

GetCallerIdentityarrow-up-right: Returns details about the IAM user or role whose credentials are used to call the operation.

circle-check

Task 8. It seems that the reported compromised AWS IAM credential has been exploited by the Threat Actor. Can you identify the regions where these credentials were used successfully? Separate regions by comma and in ascending order.

First find the trace of attacker in AWS:

Get files that made GetCallerIdentity call

Inspect the file:

From HTB it was suggested to use this script for parsing AWS files: philhagen/sof-elk/supporting-scripts/aws-cloudtrail2sof-elk.pyarrow-up-right

Let's focus on IP and filter out any error codes that indicate unsuccessful commands:

circle-check

Task 9. Discovering that the compromised IAM account was used prior to the web server attack, this suggests the threat actor might have obtained the public IP addresses of running instances. Could you specify the API call the could have exposed this information?

Get command names that were ran:

The compromised account is most probably the user/devops-ash:

describe-instancesarrow-up-right - Describes the specified instances or all instances.

circle-check

Task 10. Looks like the Threat Actor didn’t only use a single IP address. What is the total number of unsuccessful requests made by the Threat Actor?

To find the malicious IP knowing the previous IP characteristics wasn't enough. Let's do some statistics and find source IPs with errors:

The first IP (35.169.66.138) is already known, but 34.202.84.37 IP is new. Because it's known that malicious user used different IP it's safe to say in this case that second IP is them too.

The total unsuccessful request count:

circle-check

Task 11. Can you identify the Amazon Resource Names (ARNs) associated with successful API calls that might have revealed details about the victim's cloud infrastructure? Separate ARNs by comma and in ascending order.

So filter logs based on malicious actors IPs, then filter out any unsuccessful actions, then filter for any verb that gets you information and finally get unique arn names.

The prefix aws:ec2-instance in an Amazon Resource Name (ARN) typically refers to an IAM role that is automatically assigned to an EC2 instance, often when that instance needs to access AWS services or resources (e.g., to upload logs to S3, read from DynamoDB, etc.). These ARNs are not associated with individual users but rather with the specific EC2 instances themselves hence they are filtered out.

circle-check

Task 12. Evidence suggests another database was targeted. Identify all snapshot names created. Separate names by comma and in ascending order.

circle-check

Task 13. The Threat Actor successfully exfiltrated the data to their account. Could you specify the account ID that was used?

If we filter for attacker IP and then get all events that are not descriptive we are left with 3 events.

We also know that the attackers created database snapshots, but no GetObject event indicates they didn't directly download it. The ModifyDBSnapshotAttribute suggests that they changed something and then created snapshots.

modify-db-snapshot-attributearrow-up-right - Adds an attribute and values to, or removes an attribute and values from, a manual DB snapshot.

To share a manual DB snapshot with other Amazon Web Services accounts, specify restore as the AttributeName and use the ValuesToAdd parameter to add a list of IDs of the Amazon Web Services accounts that are authorized to restore the manual DB snapshot. Uses the value all to make the manual DB snapshot public, which means it can be copied or restored by all Amazon Web Services accounts.

The attackers added themselves to shared AWS accounts who can access the taken snapshot.

circle-check

Task 14. Which MITRE Technique ID corresponds to the activity described in Question 13?

T1537arrow-up-rightTransfer Data to Cloud Accountarrow-up-rightAdversaries may exfiltrate data by transferring the data, including through sharing/syncing and creating backups of cloud environments, to another cloud account they control on the same service.

circle-check

Last updated