{"id":22490,"date":"2024-02-16T17:55:48","date_gmt":"2024-02-16T16:55:48","guid":{"rendered":"https:\/\/www.riskinsight-wavestone.com\/?p=22490"},"modified":"2024-02-16T17:55:50","modified_gmt":"2024-02-16T16:55:50","slug":"deceptive-security-the-solution-for-effective-detection-in-the-cloud-deceptive-use-example-in-aws-cloud","status":"publish","type":"post","link":"https:\/\/www.riskinsight-wavestone.com\/en\/2024\/02\/deceptive-security-the-solution-for-effective-detection-in-the-cloud-deceptive-use-example-in-aws-cloud\/","title":{"rendered":"Deceptive Security: the solution for effective detection in the cloud? \u2013 Deceptive use example in AWS cloud\u00a0"},"content":{"rendered":"\n

Today, cyber-attacks are part of our daily lives, and are becoming increasingly <\/span>common <\/span> and sophisticated.\u00a0\u00a0<\/span>\u00a0<\/span><\/p>\n

Simultaneously, we are moving towards Information Systems<\/span> that are<\/span> built on an ever-increasing diversity of environments, thanks in particular to the <\/span>Cloud,<\/span><\/b> which is now an integral part within corporate Information Systems. This enables <\/span>corporations <\/span>)<\/span> to expand their capabilities, however it <\/span>is <\/span>also the surface area\u00a0<\/span> for <\/span>risk<\/span> of attack<\/span>s<\/span>.\u00a0\u00a0<\/span>\u00a0<\/span><\/p>\n

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.\u00a0\u00a0<\/span>\u00a0<\/span><\/p>\n

This raises questions about the use of <\/span>proactive strategies<\/span><\/b>, such as <\/span>Deceptive Security<\/span><\/b>, to stay one step ahead of attackers. Particularly in the context of Cyber-Resilience<\/span>;<\/span> how can this kind of technology be used in both a traditional and a cloud environment?\u00a0\u00a0<\/span>\u00a0<\/span><\/p>\n

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?\u00a0<\/span><\/i>\u00a0<\/span><\/p>\n

We will answer these questions in a <\/span>mini-series of 2 articles<\/span><\/b>. In the first article, we showed how to develop and evaluate your decoy strategy. In the second article, we\u2019ll present a practical example of deceptive security in AWS. <\/span>\u00a0<\/span><\/p>\n

\u00a0<\/p>\n

Initial assumptions and choice of scenario\u00a0\u00a0<\/span>\u00a0<\/span>\u00a0<\/span>\u00a0<\/span><\/h2>\n

Thanks to Wavestone’s expertise and the resources shared by our CyberLab, we have designed a simple scenario to illustrate the use of decoys <\/span>in an AWS Cloud environment<\/span><\/b>. 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.\u00a0<\/span>\u00a0<\/span><\/p>\n

As in the previous scenarios, <\/span>where we used Deceptive <\/span><\/b>Security <\/span><\/b>for the detection of attackers already introduced into the IS<\/span><\/b>, the aim is once again to avoid attracting opportunistic attackers to our network with a “search” Deceptive<\/span> Security<\/span> 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 <\/span>in<\/span>to <\/span> the network.<\/span>\u00a0<\/span><\/p>\n

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 <\/span>this asset can turn to the advantage of attackers<\/span><\/b> in the event of unintentional exposure of resources<\/span>,<\/span> 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 <\/span>in <\/span>poorly hardened accounts and subscriptions, whose administration too often obeys rules that are still informal.\u00a0 <\/span>\u00a0<\/span><\/p>\n

The attack scenario<\/span><\/b> and associated luring will therefore be based on the principle of linking two AWS accounts<\/span><\/b>, 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.<\/span>\u00a0<\/span><\/p>\n

\u00a0<\/p>\n

Luring scenario\u00a0<\/span>\u00a0<\/span><\/h2>\n

Description of the scenario\u00a0\u00a0<\/span>\u00a0<\/span><\/h3>\n

Let’s assume that <\/span>an unauthorized user has gained access to an EC2 machine<\/span><\/b> (domainIntegrated-EC2) within the test account (initial infection). After an initial successful connection,\u00a0<\/span> they <\/span> attempt<\/span> to access commonly used resources such as Amazon Simple Storage Service (Amazon S3), or <\/span>tries to elevate <\/span><\/b>their <\/span><\/b> privileges<\/span><\/b> by assuming other roles (role chaining) related to the role to which <\/span>they have <\/span> access.\u00a0<\/span>\u00a0<\/span><\/p>\n

This lateral propagation scenario is a common attack technique in cloud environments<\/span><\/b> 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).<\/span>\u00a0<\/span><\/p>\n

As illustrated below, <\/span>lateral propagation attacks take advantage of weaknesses in the customer’s security controls<\/span><\/b>, such as misconfigured authorizations or the application of too-weak authentication mechanisms, to gain unauthorized access to other resources in the environment.<\/span>\u00a0<\/span><\/p>\n

\"\"
Scenario from the attacker’s point of view<\/span><\/i>\u00a0<\/span><\/p>\n

\u00a0<\/span><\/p>\n

0. After compromising a “domainIntegrated” EC2 machine, the attacker discovers that it has a role associated with it (“Semi-Admin-role”): <\/span>\u00a0<\/span><\/p>\n

\"\"\u00a0
Enumeration of EC2 machine domainIntegrated<\/span><\/i>\u00a0<\/span><\/p>\n

It then lists the rights of the “Semi-Admin-Role”:<\/span>\u00a0<\/span><\/p>\n

\"\"\u00a0
Enumeration of Semi-Admin-Role rights<\/span><\/i>\u00a0<\/span><\/p>\n

First, this role has <\/span>modification privileges <\/span><\/b>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.\u00a0<\/span>\u00a0<\/span><\/p>\n

The attacker also realizes that <\/span>they <\/span> can directly assume another role<\/span><\/b> (“IAM-RO-Role”) in the AWS – MASTER account. This latter role attracts particular attention, as the MASTER account’s name suggests a <\/span>much greater scope of action<\/span><\/b> than the simple SHARED account, and the IAM-RO-Role role suggests an extended scope of vision over the account’s resources.<\/span>\u00a0<\/span><\/p>\n

\u00a0<\/span><\/p>\n

    \n
  1. The attacker assumes the “SemiAdmin-role”, which then allows <\/span>the<\/span>m <\/span> to assume the “IAM-RO” role and attempt other actions that will enable <\/span>them<\/span> to analyze <\/span>their<\/span> field of vision.<\/span>\u00a0<\/span><\/li>\n
  2. Indeed, after assuming the “IAM-RO” role, he proceeds to an IAM enumeration where <\/span>they<\/span> becomes aware of the roles and users in <\/span>their<\/span> field of vision:<\/span>\u00a0<\/span><\/li>\n<\/ol>\n


    \"\"<\/span><\/p>\n

    List of roles in the field of view of the IAM-RO role\u00a0<\/span><\/i>\u00a0<\/span><\/p>\n

    \"\"<\/span><\/p>\n

    List of users in the field of view of the IAM-RO role\u00a0<\/span><\/i>\u00a0<\/span><\/p>\n

    The “SecurityAudit” role in particular attracts <\/span>their<\/span> attention thanks to the <\/span>privileges<\/span><\/b> that this name suggests and the role description, which provides information on these privileges:\u00a0<\/span>\u00a0<\/span><\/p>\n

    \"\"<\/span><\/p>\n

    SecurityAudit role description<\/span><\/i>\u00a0<\/span><\/p>\n

    However, the attacker only has read access to the resources listed. <\/span>They <\/span> will therefore look to see if any of these resources can be written to from the SHARED account, where <\/span>they<\/span> have<\/span> high privileges. For example, if certain MASTER account roles can be endorsed by SHARED account roles:\u00a0\u00a0<\/span>\u00a0<\/span><\/p>\n

    \"\"<\/span><\/p>\n

    List of roles that can be assumed from an external account (here the SHARED account)<\/span><\/i>\u00a0<\/span><\/p>\n

    The attacker investigates the approval relationship of the “SecurityAudit” role, which authorizes an endorsement by the “LambdaAuto” role of the SHARED account.<\/span>\u00a0<\/span><\/p>\n

    \u00a0<\/span><\/p>\n

    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.<\/span>\u00a0<\/span><\/p>\n

    1.Once the “LambdaAuto” role approval policy has been modified, it can now assume the “LambdaAuto” role.<\/span>\u00a0<\/span><\/p>\n

    2. Then <\/span>they <\/span> take<\/span> on (by role-chaining) the role of “SecurityAudit”, the real decoy.<\/span>\u00a0<\/span><\/p>\n

    \"\"<\/span><\/p>\n

    Role chaining of the attacker<\/span><\/i>\u00a0<\/span><\/p>\n

    After attempting to take on the “SecurityAudit” role, from which <\/span>they<\/span> hope<\/span> to gain the privileges of a security auditor (announced in step 1), the attacker in reality finds <\/span>themself<\/span> without any real powers, for example :<\/span>\u00a0<\/span><\/p>\n

    \"\"<\/span><\/p>\n

    Example of denied access from the SecurityAudit\u00a0<\/span><\/i>\u00a0<\/span><\/p>\n

    Creating lures<\/span>\u00a0<\/span><\/h3>\n

    The diagram below shows how decoys are added at different stages of the attack and how they are configured by the defender:<\/span>\u00a0<\/span><\/p>\n

    \"\"<\/span><\/p>\n

    Scenario from the defender’s point of view\u00a0<\/span><\/i>\u00a0<\/span><\/p>\n

    \u00a0<\/span><\/p>\n

    0.The “Semi-Admin-Role” is the <\/span>entry point<\/span><\/b> 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.<\/span>\u00a0<\/span><\/p>\n

    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.<\/span>\u00a0<\/span><\/p>\n

      \n
    1. Once the IAM-RO role has been assumed, the attacker is then invited into an account entirely dedicated to luring and <\/span>familiarising<\/span> themselves <\/span> with the surrounding resources, <\/span>gaining a complete overview of all the account’s roles and users.<\/span><\/b>\u00a0\u00a0<\/span>\u00a0<\/span><\/li>\n
    2. 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.\u00a0\u00a0<\/span>\u00a0<\/span><\/li>\n<\/ol>\n

      We thus add to the account :\u00a0\u00a0<\/span>\u00a0<\/span><\/p>\n