Today, cyber-attacks are part of our daily lives, and are becoming increasingly common and sophisticated.
Simultaneously, we are moving towards Information Systems that are built on an ever-increasing diversity of environments, thanks in particular to the Cloud, which is now an integral part within corporate Information Systems. This enables corporations ) to expand their capabilities, however it is also the surface area for risk of attacks.
Conventional intrusion detection and protection techniques already exist and are developing exponentially. These are effective against the most common attacks, however are not always adapted to the specificities of the Cloud.
This raises questions about the use of proactive strategies, such as Deceptive Security, to stay one step ahead of attackers. Particularly in the context of Cyber-Resilience; how can this kind of technology be used in both a traditional and a cloud environment?
When should Deceptive Security techniques be used? Are Deceptive Security solutions in the Cloud being developed today? Are there any specific strategies to consider in a Cloud environment as opposed to a traditional one?
We will answer these questions in a mini-series of 2 articles. In the first article, we showed how to develop and evaluate your decoy strategy. In the second article, we’ll present a practical example of deceptive security in AWS.
Initial assumptions and choice of scenario
Thanks to Wavestone’s expertise and the resources shared by our CyberLab, we have designed a simple scenario to illustrate the use of decoys in an AWS Cloud environment. The example detailed below is inspired by a CTF (Capture The Flag) scenario designed by the CyberLab team to illustrate the lateral propagation of an attacker.
As in the previous scenarios, where we used Deceptive Security for the detection of attackers already introduced into the IS, the aim is once again to avoid attracting opportunistic attackers to our network with a “search” Deceptive Security approach. We therefore assume an initial infection of some kind, which is highly probable (all the more so in poorly controlled Cloud environments), and concentrate on detecting the intruder as it is being deployed into the network.
Applying this approach to an AWS environment is no innocent matter. One of the benefits of the Cloud lies in its simplified identity management and easy delegation of access, but this asset can turn to the advantage of attackers in the event of unintentional exposure of resources, or the creation of dangerous links between zones of different security levels. There is no shortage of hardening and prevention measures, generously promoted by Cloud providers themselves, but these vulnerabilities remain in poorly hardened accounts and subscriptions, whose administration too often obeys rules that are still informal.
The attack scenario and associated luring will therefore be based on the principle of linking two AWS accounts, here conceived as a production environment and a less critical development environment. We’ll place ourselves in a scenario where an approval relationship is used to propagate from the development account to the production account, via the endorsement of a cross-account role.
Luring scenario
Description of the scenario
Let’s assume that an unauthorized user has gained access to an EC2 machine (domainIntegrated-EC2) within the test account (initial infection). After an initial successful connection, they attempt to access commonly used resources such as Amazon Simple Storage Service (Amazon S3), or tries to elevate their privileges by assuming other roles (role chaining) related to the role to which they have access.
This lateral propagation scenario is a common attack technique in cloud environments due to the nature of their architecture and the cloud computing responsibility model, where the customer is responsible for securing their applications, data and access control (while the provider ensures the security of the underlying infrastructure).
As illustrated below, lateral propagation attacks take advantage of weaknesses in the customer’s security controls, such as misconfigured authorizations or the application of too-weak authentication mechanisms, to gain unauthorized access to other resources in the environment.
Scenario from the attacker’s point of view
0. After compromising a “domainIntegrated” EC2 machine, the attacker discovers that it has a role associated with it (“Semi-Admin-role”):
Enumeration of EC2 machine domainIntegrated
It then lists the rights of the “Semi-Admin-Role”:
Enumeration of Semi-Admin-Role rights
First, this role has modification privileges on a resource in the “AWS – SHARED” account: it can assume (sts:assumeRole) and modify (iam:UpdateRole) a role called “LambdaAuto”. He can then assume (by “role chaining”, step 5 in the diagram above) another role called “SecurityAudit” in a different account, called AWS MASTER.
The attacker also realizes that they can directly assume another role (“IAM-RO-Role”) in the AWS – MASTER account. This latter role attracts particular attention, as the MASTER account’s name suggests a much greater scope of action than the simple SHARED account, and the IAM-RO-Role role suggests an extended scope of vision over the account’s resources.
- The attacker assumes the “SemiAdmin-role”, which then allows them to assume the “IAM-RO” role and attempt other actions that will enable them to analyze their field of vision.
- Indeed, after assuming the “IAM-RO” role, he proceeds to an IAM enumeration where they becomes aware of the roles and users in their field of vision:
List of roles in the field of view of the IAM-RO role
List of users in the field of view of the IAM-RO role
The “SecurityAudit” role in particular attracts their attention thanks to the privileges that this name suggests and the role description, which provides information on these privileges:
SecurityAudit role description
However, the attacker only has read access to the resources listed. They will therefore look to see if any of these resources can be written to from the SHARED account, where they have high privileges. For example, if certain MASTER account roles can be endorsed by SHARED account roles:
List of roles that can be assumed from an external account (here the SHARED account)
The attacker investigates the approval relationship of the “SecurityAudit” role, which authorizes an endorsement by the “LambdaAuto” role of the SHARED account.
0. Back on the SHARED account, all the attacker has to do is check that the other counterpart of this approval relationship, i.e. that the “LambdaAuto” role does indeed authorize the “SecurityAudit” role’s endorsement in its approval policy. This is not the case, but the “SemiAdminRole” role allows it to configure this authorization.
1.Once the “LambdaAuto” role approval policy has been modified, it can now assume the “LambdaAuto” role.
2. Then they take on (by role-chaining) the role of “SecurityAudit”, the real decoy.
Role chaining of the attacker
After attempting to take on the “SecurityAudit” role, from which they hope to gain the privileges of a security auditor (announced in step 1), the attacker in reality finds themself without any real powers, for example :
Example of denied access from the SecurityAudit
Creating lures
The diagram below shows how decoys are added at different stages of the attack and how they are configured by the defender:
Scenario from the defender’s point of view
0.The “Semi-Admin-Role” is the entry point into the decoy scenario. It can therefore be associated with any resource likely to be compromised (here the EC2 “domainIntegrated”) to redirect the attacker to the decoys.
No alerts are configured at this level, as the Semi-Admin role’s connection to all SHARED account resources makes it likely that unintentional endorsements will be triggered, resulting in false-positive alerts.
- Once the IAM-RO role has been assumed, the attacker is then invited into an account entirely dedicated to luring and familiarising themselves with the surrounding resources, gaining a complete overview of all the account’s roles and users.
- By populating the attacker’s field of vision not only with the main “SecurityAudit” decoy, but also with other dummy roles and users, we ensure that the account’s appearance appears credible and that our key decoy, the SecurityAudit role, is not isolated.
We thus add to the account :
- Users : different user names attracting the attacker.
- The “LambdaFunction” role: this role is created to simulate a Lambda function that calls on AWS services.
- The “LogsAndS3Bucket” role: a role created to facilitate access to logging services and S3 storage resources within the account.
- The “taskExecutionRole”: the task execution role that can be used for different purposes and services associated with the account.
3. The “SemiAdminRole” role has deliberately been configured with permission (iam:UpdateRole) on the “LambdaAuto” role, enabling it to modify this role and thus add the approval relationship to the “SemiAdminRole” role. For monitoring purposes, an initial alert can be triggered at this level when the “LambdaAuto” approval relationship is updated, enabling the “SemiAdminRole” to assume it.
4. The “LambdaAuto” role is deliberately created as the gateway to the “SecurityAudit” role, once its approval relationship has been modified using the privileges of the “SeminAdminRole” role.
5. The “SecurityAudit” role is deliberately configured with an approval relationship authorizing the “LambdaAuto” role of the SHARED account to assume it.
6. At this stage, the attacker had assumed that they would be granted security auditor rights. However, a very restrictive Security Control Policy (SCP) was applied, granting them no privileges on the account.
The policy prohibiting all actions from the Security-Audit-Role
Alerting chain
An alerting chain in the AWS cloud refers to a means of communicating notifications or alerts generated by AWS services to users or teams responsible for managing these services, enabling them to take rapid action to resolve problems and minimize service interruptions.
To set up an alerting chain, you first need to configure AWS services to generate alerts when certain events occur, such as, a server down or an application exceeding a specific CPU usage threshold. Once these alerts have been generated, they can be sent to the appropriate alerting chain according to the notification preferences configured by the user or the team responsible for managing the service.
In order to detect the attacker, we use the following AWS services to create the alerting chain:
- CloudTrail l to track actions performed on the compromised AWS account;
- EventBridge to detect any “AssumeRole” event of the “SecurityAudit” role and trigger an alert ;
- Simple Notification Service (SNS) to send the alert by e-mail with the information gathered during the attack.
Illustration of the alerting chain
Alerting chain creation steps :
Cloudtrail configuration
The first step in creating an alerting chain on AWS is to enable CloudTrail (if not already activated) in your AWS account. CloudTrail logs all activity and API calls in your account, which can be useful for security, compliance and troubleshooting purposes.
Based on the logs generated in CloudTrail, we’ve created an EventBridge rule that sends notifications to the SNS service whenever the “SecurityAudit” role is assumed (event type: AssumeRole).
Creation of an EventBridge rule
A rule monitors specific types of events, and when a corresponding event occurs, it is routed to the service associated with the rule and handling the event (in this case, the SNS service).
The event model detects all events of the “AssumeRole” type occurring in the account used and triggers the alert. In order to avoid false positives when triggering alerts, we have refined the event model to be as accurate as possible for the events we are interested in.
This means including relevant fields, such as event source, detail type or specific values, to refine the matching criteria. This reduces the risk of unrelated events triggering the rule.
The event model detecting all “AssumeRole” events on the “SecurityAudit” role
The Eventbridge service must therefore first be linked to the SNS target. 
The target related to the EventBridge rule
SNS rubric configuration
At this stage, an SNS topic is created and linked to a subscription of an e-mail endpoint authenticated later. The SNS topic will be the target of the EventBridge rule. Once the topic has been created, the e-mail subscription is carried out by selecting the e-mail address as the protocol (endpoint) where the alerts are to be received.
Other targets than e-mail could be considered for receiving alerts (ServiceNow, SIEM, etc.).
Details of the SNS rubric
Alert customization
EventBridge’s Input Transformer function was used to customize the content of the alert, so that only the most important elements were displayed.
It allows you to customize the text of an event before it is transmitted to the target. This is achieved by defining JSON variables to reference values in the original event source.
Input transformer configuration
In our case, the variables listed below will constitute the alert message:
Input transformer creation
Input model
The input model will use the variables defined previously within the final alert message:
Input model creation
Once the “SecurityAudit” role has been endorsed, an alert is sent to the endpoint created:
Example of e-mail alert content
Cost of the AWS services used
AWS offers a pay-per-use approach to pricing its cloud services. With AWS, you only pay for the services you need, as long as you continue to use them, without a long-term contract. You only pay for the services you use, and if you stop using them, you won’t be charged any additional costs or termination fees.
The services deployed in this scenario are not intended to be used except in the event of an intrusion or security incident. The associated costs are therefore negligible.
Decoy evaluation with the PARCS matrix
Several criteria can be used to evaluate a lure, and here are the results of our analysis based on the PARCS matrix:
- Pertinence (efficiency) : 4/4
« Various approaches can be adopted to effectively spot the initial compromise of an EC2 instance and the lateral propagation of an attacker. In our context, depending on the resources at our disposal, one possible strategy is to monitor operations by analyzing logs, which will enable malicious actions to be detected. These observations could then be used to generate alerts for administrators. For example, an alert could be triggered in the event of an intrusion attempt via a brute force attack on the RDP service of EC2 instances within our AWS environment, thanks to GuardDuty.
In addition, it would be possible to use a combination of AWS services such as CloudTrail and EventBridge to establish detection rules and automate interventions in response to specific activities, including those related to cross-account access, and create detection rules that monitor all endorsement events to trigger actions in the event of corresponding events. »
- Attractivité (attractiveness): 4/4
« The decoy is distinguished by a dedicated account, significantly increasing its power of attraction. By having access to the metadata of all the resources within their reach, the attacker can also verify various levels of privilege, which substantially enhances credibility. Thanks to the ability to visualize the dates and times of the last uses of resources in their field of vision, they can deduce that these resources are rarely used. With this in mind, a lambda function is implemented to automate the execution of various resources or their authentication, thus guaranteeing proof of recent use. »
- Risque (risk): 4/4
« The authorization granted to the IAM-RO role only confers IAM privileges to the attacker in the context of a purely fictitious account. Thanks to appropriate configuration of the upstream SCP, any attempted actions by the Security-Audit role will also be thwarted. The only elements deliberately introduced in a real environment are the Semi-Admin and Lambda-Auto roles, which are subject to stringent policies preventing any assignment of rights or privileges in the event of attempted malicious use. These policies include read-only access (IAMReadOnlyAccess) and a restriction preventing any modification of account role authorizations, as defined by the SCP. »
- Crédibilité (credibility): 3/4
« The credibility of the decoy may be called into question by the resources available to it and potential limitations, such as an Inline Policy that restricts permissions and possible actions. It’s important to take these factors into account, as they can create doubts in attackers and compromise the decoy’s effectiveness. It is therefore crucial to put in place measures that make the decoy as realistic and convincing as possible, ensuring that it has access to the relevant resources and authorizations to create a credible scenario. »
- Scalabilité (scalability) : 3/4
« Depending on the size of an infrastructure, it may be possible to implement fluid deployment and maintenance of components, thanks to the use of automated scripts empowered to perform operations on resources. However, careful monitoring of all resources is essential to consolidate security in the face of possible attacks, and to ensure rapid reaction to defend an extended perimeter.»
In conclusion, implementing such a Deceptive Security scenario in the Cloud, offers an approach to improving its overall security. It helps restrict an attacker’s ability to explore and propagate across the network, by presenting deceptive paths, delaying their progress and enabling faster detection and response. Decoys, which resemble attractive targets, divert attackers’ attention and resources away from real assets, increasing the chances of early detection.
In addition, alert mechanisms play a crucial role in providing rapid information on potential intrusions to security teams, enabling rapid incident response and limiting the impact of attacks.
Combining these defence strategies strengthens the overall security posture of Cloud environments, improves their resilience in the face of constantly evolving cyber threats, and guarantees the integrity and confidentiality of sensitive data.
By using these deceptive security measures, companies can strengthen their defence against cyberattacks. However, it is important to note that Deceptive Security does not replace existing standard cybersecurity solutions, and that protection against cyberattacks requires the use of complementary security techniques for optimal defense.
ANNEX – AWS Services
Definitions from source : AWS documentation → docs.aws.amazon.com.
SCP – Service control policies : Service control policies are a type of policy that enable central control of authorizations. This ensures that broad guidelines are followed for all AWS accounts in the organization.
EC2 – Elastic Compute Cloud : AWS EC2 allows you to rent servers (EC2 instances) to best meet your workload needs.
STS – Security Token Service : AWS STS enables you to request temporary security credentials for AWS resources. This makes it possible to grant temporary access to resources via API calls, the AWS console or the AWS CLI (Console Line Interface).
Please note: Each STS token has a lifecycle, defined when it is created, of between 15 minutes and 36 hours.
CloudTrail : AWS CloudTrail is a service that records the actions performed by an AWS user, role or service.
Fonction Lambda : The Lambda function is a service for executing code.
SNS – Simple Notification Service : Amazon SNS is a web service for managing the sending of messages (SMS, e-mail, HTTP.S, etc.).
Thanks to Charles BULABULA for his contribution to this article.
