In this article, we will expose the cyber-resilience challenge of Entra ID, explain why native features are incomplete and present the result of a PoC conducted on an open-source tool, Microsoft 365 DSC, to backup and recover Entra ID’s data.

The challenge of cyber-resilience in managed Cloud services

With Entra ID, the directory management strategy is in line with the Cloud paradigm. It means that the various network, storage, computer, OS and application layers are handled by Microsoft, leaving the customer to focus solely on his identity data.

This fundamental difference has an impact on the resiliency of the service. Indeed, the creation of snapshots to back up the integrality of the system, which is a common practice on AD, is not native on a managed service such as Entra ID. Thus, in order to face a disaster recovery scenario linked to malicious activities, we can only rely on native Microsoft functionalities: the identity lifecycle model, RBAC administration model and import/export capabilities.

The incomplete soft delete model

To ensure resilience, Cloud services are widely using a soft delete mechanism. Its main purpose is to recover data in the event of an accidental deletion. For example, in Azure Recovery Service Vault, the soft delete is the last safeguard in the event of intentional or unintentional deletion of the vault. Combined with immutability parameters, the vault cannot be erased regardless of admin permissions.

In Entra ID, the concept of soft delete exists but is insufficient to ensure data resilience for two reasons. On the one hand, there is neither role distinction between soft-delete and hard-delete nor Recovery role, i.e. the permissions required to delete an object are sufficient to allow for permanent deletion. On the other hand, the life cycle of objects in Entra ID (create, manage, delete) is governed by the same role:

• The role User Administrator can both create and hard-delete a user
• The role Cloud Application Administrator can register an application, configure all aspects of the application and hard-delete the application
• The role Cloud Device Administrator can add a device, configure all aspects of the device and unregister a device

The impact of a deletion on Entra ID

This design makes the User Administrator, Privileged Authentication Administrator, Cloud Application Administrator, Application Administrator, Cloud Device Administrator, Intune Administrator and Windows 365 Administrator roles all the more critical, as their compromise can lead to the permanent loss of identity data. The impact of such a deletion can be a loss of access to applications and data, a loss of permissions, and an inability to administrate.

Although the deletion of hybrid users synchronized with an on-premise AD is reversible, information such as role assignment will be lost, threatening the rights and access model. This is not the case for Cloud identities, which are generally part of the Control Plane. As part of the Enterprise Access Model, the Control Plane includes the most sensitive access, leading to a global compromise of an Information System.

In a disaster recovery scenario, some assets are more critical than others and should be backed up as a priority. These include:

• Control Plane users, groups and roles assigned
• Enterprise Applications (service principals) with critical permissions over Azure or Microsoft 365
• Administrative workstations

Comparison of backup open-source methods

To reduce the likelihood of Entra ID malicious data loss risk, the implementation of a backup solution seems essential, at least for the Control Plane in order to maintain control over your Information System and rebuild. We have therefore analyzed 3 open-source methods for ensuring data backup:

• Microsoft Graph PowerShell: this is the PowerShell library for Microsoft Graph APIs. You can build your own script(s) to export and import Entra ID objects attributes that fit with organization needs
• Microsoft Entra Exporter: this is a PowerShell module that export a local copy of some Entra ID attributes (Users, Applications, Service Principals, Roles, etc.) into JSON file
• Microsoft 365 Desired State Configuration (DSC): this is a PowerShell module for declarative configuration, deployment and management of Microsoft 365 services

Backing up Entra ID objects with Microsoft 365 DSC

In this part, we will explain how we tested the open-source solution Microsoft 365 DSC and share the results and conclusions we got.

Our PoC

Microsoft 365 DSC enables the management of the configuration and state of Microsoft 365 services following a declarative approach. By defining the desired state rather than specific steps, it simplifies the management of complex cloud configurations and ensures consistency across the environment.

In the context of a PoC, the test population deployed in our test tenant is as follows:

• 30 Cloud Only Users (randomly generated by Microsoft as part of the test’s tenant creation process)
• 10 Security Groups (randomly assigned to Users)

The purpose of this PoC is to identify the benefits and limitations of the solution through a series of tested and documented uses cases:

The process required configuring a service account with the right permissions (User.ReadWrite.All, Group.ReadWrite.All) in Entra ID to interact with Microsoft Graph API for data export and import.

These permissions enabled the service account to retrieve the necessary configuration and data from Entra ID and later re-import it.

Result of the PoC Microsoft 365 DSC

As a result of these tests, we were able to gather conclusive information on the solution’s benefits and limitations. On the positive side:

• Granular Configuration Selection: The solution allows precise targeting of configurations for backup, enabling users to select specific settings.
• Recovery without deletion: During recovery, current users and groups are retained, preventing accidental deletion.
• Overwrite of Outdated Attributes: Backed-up attributes replace the old ones.
• Language of the Data Storage: Data is stored in JSON format, making it easy to manipulate and modify backup files.
• Automation Capabilities: Once the necessary tools are installed, the solution is easy to automate.
• Monitoring and Alerts: Microsoft 365 DSC can be used to monitor data consistency and receive alerts in the event of suspicious changes
• Snapshot Versions management: It enables easy maintenance and administration of multiple snapshot versions
• Detailed Logging Functionality: It offers the possibility to generate highly detailed logs, providing records of all operations for enhanced oversight.

Despite these advantages, the study revealed several limitations:

• Incomplete Data in Backup: The backup process does not capture all attributes, leading to potential loss of important information.
• Backup Size Limit: The backup size is capped at 11MB, which may be insufficient for larger configurations or datasets.
• Deactivation Status Not Captured: Snapshots do not store deactivation statuses for users, potentially re-enabling disabled users during recovery.
• Unencrypted Data and Credentials: Security concerns arise from data and credentials being stored unencrypted, posing risks to sensitive information.
• Object IDs’ Loss: During imports, object IDs are lost, causing recreated objects to have new IDs, which can lead to duplicate entries in subsequent imports.
• Privileged Service Principal: The service principal involved has elevated privileges, increasing the risk of security vulnerabilities if not properly managed.

It is important to note that this tool does not really support “restoration” as it is possible to re-create objects, but it does not ensure service restoration and continuity. The reason being that it currently cannot restore links between new ID objects and applications, which is an issue native to Entra ID.

Our opinion about Microsoft 365 DSC

Microsoft 365 DSC is a great tool when it comes to basic uses and documentation as it is simple to use and to deploy on test environments. It is also quite efficient as a monitoring tool thanks to its version control and detailed logs. However, it is not adapted to large environments because of the limited scalability, the poor user experience and security issues related to configurations and credentials. It can also lead to inconsistencies or duplication as object IDs that can be referenced elsewhere are unrecoverable.

Additional solutions may be required such as scripting for handling configuration files and ensuring the consistency of the modifications, as well as well-defined encryption and backup processes. Therefore, we recommend always carefully evaluating the specific needs, planning additional developments and mainly using the solution for supervision and testing purposes.

Given the limitations of Microsoft’s open-source tools, it could be worthwhile to explore what third-party vendors, such as Semperis or Quest who are pure players on the subject, have to offer. These alternatives might address some of the challenges related to scalability, reliability and security, providing options that better suit larger environments. It is important to remain open to these possibilities and evaluate them based on the specific requirements of your organization.

Cet article Resilience Entra ID est apparu en premier sur RiskInsight.

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. 

1. 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. 
2. 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. 

1. 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.   
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.   

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. 

Cet article Deceptive Security: the solution for effective detection in the cloud? – Deceptive use example in AWS cloud  est apparu en premier sur RiskInsight.

Today, cyber-attacks are part of our daily lives, and are becoming increasingly numerous and sophisticated.  

Simultaneously, we are moving towards Information Systems 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 corporation to expand their capabilities, however it also the surface area and risks of attack.  

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 will show you how to develop and evaluate your decoy strategy. In the second article, we’ll present a practical example of deceptive security in AWS. 

Develop and evaluate your deceptive strategy  

Ambitions of Deceptive Security 

Deceptive Security in a nutshell 

“Deceptive Security” (referred to as “Deceptive” in the rest of this article), or “digital decoying“, is a cyber-defense technique that deals with the intrusion of attackers into an IS (Information System). It works by setting up traps and/or decoys in an IS. These are designed to imitate legitimate technology, so as not to be identified as security systems/measures.  

This method makes it possible to detect intrusions by generating alerts, to prevent damage to the actual infrastructure and to observe the practices used by the attacker.  

Before delving into the details of this subject, we recommend reading the article “Deceptive Security : comment arroser l’arroseur ? “, which describes the main concepts of “Deceptive Security“.  

The main objectives of Deceptive 

The use of Deceptive on an IS can have several objectives:  

•  Detect an intrusion  
•  Distract the attacker  
•  Analyze the techniques used in the attack 

This technology can be used at different levels of maturity, depending on the needs identified.   

The technology can be used to meet many of the needs mentioned above, but the key is to determine our requirements for this technology in advance. If we restrict the needs for detection, it should be noted that the configuration, deployment and maintenance of Deceptive will be far less complex than if we push the possibilities of this technology to the maximum (e.g. setting up complex scenarios to lure the attacker and strategic analysis of his actions).

The benefits of Deceptive 

Why Deceptive ? 

As discussed in the introduction, today’s cybersecurity challenges are fueled by the need to detect and react to growing attacks.  

Deceptive does not replace existing standard cybersecurity solutions. Being a more complex tool, it acts as a complement to cover all types of attack, including the most sophisticated.  

This technology is not designed to prevent an attack, but to alert security teams, minimize the effects of the attack and observe the intruder’s modus operandi (“Detect, Distract & Analyze”). 

Honeypot VS Honeytoken 

Presentation of concepts 

Depending on the needs and how they are to be used, different types of decoys exist. Whatever the case, they take on the appearance of attributes that make up our Information System.  

The best-known decoys are “honeypots”. These are servers or workstations that imitate real machines on the network. There’s also what’s known as a “honeynet”: a network of servers.   

Another type of decoy is of growing in popularity. This is a decoy that hides directly on a system. These are generally represented by documents or other files whose role is to trigger an alert when someone comes to interact with them. Finally, we have “honeytokens”, which are data, information, often secrets or keys used to access a dummy resource on the IS (a honeypot, for example). 

A fundamental difference 

Traditionally, honeypots enable the observation and understanding of an attacker’s actions, as well as detecting an intrusion. The difficulty in this case is to configure a decoy that is attractive and credible enough for the attacker to fall into the trap, without delivering information that could compromise a component of our real infrastructure.  

However, honeytokens can be more complex and enable the creation of a finer and more credible decoy. Without honeytokens, the probability of trapping an attacker is lower, and analysis results are not always reliable. The honeytoken’s dependence on its environment makes it more attractive in comparison to a honeypot, which represents no more than a trap with no possibility of subsequent escalation. For honeypots to be effective, we recommend deploying one or more complete honeynets, however it is important to consider the cost of such an infrastructure.  

Cloud technology development 

Today, the challenge for the most mature Deceptive solution vendors is to develop specific services in the Cloud.  

Indeed, companies are increasingly using the Cloud to extend their storage, deploy virtual machines, containers and so on. This provision of services is very popular and effective, but at the same time, the interest of cyber-attackers is growing. Templates, or default configurations, make life easier for businesses, but can increase cybersecurity risks. Even though many Cloud providers are making great strides in this area, default configurations don’t always comply with IT security guidelines.  

The Cloud is therefore a new playground for cyber-attackers. That’s why we’re focusing today on adapting our knowledge of Deceptive to protect Cloud environments and services too.  

Overview of the main publishers on the market 

It’s important to note that Deceptive is not reserved for overly complex applications. There are all kinds of offers on the market. Some companies offer services that enable you to obtain a complete off-the-shelf tool, while others focus on customization, lure quality and therefore the possibility of using their tool to create your own lures (configuration and maintenance not managed by the solution itself).  

Here’s an overview of the main publishers and their solutions:   

For some, the current trend is to join forces with other tools or integrate their solution with an EDR (Endpoint Detection and Response) to increase the effectiveness of the technology and meet market needs.  

As mentioned above, the challenge that some have chosen to tackle is to adapt to a Cloud environment. For example, solutions such as “Attivo Networks”, acquired by SentinelOne, are developing Cloud AWS offers that propose the creation of decoys linked to the service (e.g.: EC2, S3, AWS access keys, etc.).  

How to build and place decoys? 

Deceptive strategies 

Once you’ve familiarized yourself with this technology and all the possibilities it offers, it is worth asking yourself the question, what strategy or strategies you should adopt with regard to the number of traps and/or decoys to be implemented, and where they should be placed in the IS.  

To adapt to different use cases, 3 strategies stand out, responding to distinct needs: 

Indeed, the Deceptive strategy to be adopted is often tailor-made according to the IS infrastructure and, above all, according to the priorities and objectives defined beforehand.  

By way of example: if you need to enrich your detection technologies within your IS, it may be worthwhile to study the strategy of “mass deployment” of decoys. The aim is to create a phantom IS, thereby increasing the likelihood of the cybercriminal falling into a trap that will trigger an alert to the security teams.  

PARCS matrix 

The challenge when talking about Deceptive, and more specifically about lures, is to answer the questions: What is a good lure? How do you create a good lure? Where to place it? How many to place? etc.  

The article “ HoneyWISE : stratégie d’exploitation d’honeytokens en environnement Active Directory ”, written by Augustin TOURNYOL-DU-CLOS and Nathan FAEDDA, proposes a decoy strategy against certain attacks in a specific context: AD (Active Directory). We’ll also look at honeytokens in comparison with honeypots in the rest of this article.  

The objective of this study was to simply test the implementation of decoys within the AD and to measure their effectiveness using the “PARCS” matrix.  

PARCS was born on the basis of 5 criteria, originally conceived in the context of an AD environment but applicable to all environments:  

When designing a decoy, it’s a good idea to prepare a PARCS to check your thinking and ensure that it matches your expectations. It is also important to take into consideration minimum requirements illustrated by these 5 criteria: Relevance, Risk, Credibility, Attractiveness and Scalability.  

The objective of this matrix is to determine a balance between importance and priority based on these criteria’s (Is the lure’s attractiveness important in my use case? Do I need a scalable solution? How scalable? etc.).  

Example of PARCS use: Kerberoasting scenario “Stealing or falsifying Kerberos tickets” 

Perhaps the best way to illustrate the PARCS matrix presentation is with an example from the “ HoneyWISE ” article.  

The AD attack called Kerberoasting is, “[…] in synthesis, the offline brute force (no logon failure) of a Kerberos ticket receiving the secret of a service account, without having to send a single packet to this service or even being the local administrator of the compromised workstation”.  

“Kerberoasting […] hijacks the native operation of Kerberos in order to carry out an attack. This hijacking takes place on steps 3 and 4 of the Kerberos authentication process, as shown in the following diagram”: 

For this attack case, Augustin TOURNYOL-DU-CLOS and Nathan FAEDDA propose in their article to deploy a honeytoken against Kerberoasting (see part 2.3 “Description of detection scenarios” – scenario 2).  

Here is the result, through PARCS, of the study of this type of honeytoken in the context of a Kerberoasting scenario (16/20): 

• Pertinence (efficiency): 4/4 
  • «  The alerts generated by this honeytoken are reliable. In fact, as soon as a TGS ticket is requested to access an unused and non-existent service, it becomes clear that a malicious action is underway. » 
• Attractivité (attractiveness): 3/4 
  • «  The attractiveness of this token lies in the fact that carrying out the attack does not require any privileges, and can potentially gain privileges while being silent (generation of traffic deemed legitimate). Provided that the account chosen to lure the attacker appears privileged and managed by a user (so that the password is likely to be simple), this honeytoken is highly attractive. » 
• Risque (risk): 4/4 
  • « In our example, a 64-character password has been defined, which cannot be broken in a reasonable time. » 
• Crédibilité (credibility): 3/4 
  • «  Subject to the choice of account name and attributes according to the production context in which it is deployed, since the attack is based on normal Kerberos operation, it should come as no surprise that it can be carried out. Credibility is therefore high. » 
• Scalabilité (scalability): 2/4 
  • «  The decoy account can be deployed automatically on several domains using scripts. However, for an effective lure, contextualization remains essential and will be the major obstacle to effective mass deployment. The cost of providing this contextualization and keeping it up to date must therefore be taken into account.  » 

To conclude, Deceptive Security solutions must be considered on a case-by-case basis. It is imperative to determine in advance the objectives to be prioritized, the strategy to be adopted, the scope to be covered, and so on.  

In certain situations, especially for companies with mature IT security systems, it may be appropriate to implement Deceptive Security solutions. This is to be applied in addition to standard minimum security tools such as firewalls, antivirus, intrusion detection and/or prevention systems, etc. The aim is to cover all types of cyberattack (“0-day” type, with no known pattern).   

This technology can be difficult to implement for smaller companies, as they may not have the essential security tools in place by default, nor the resources to configure (e.g., design decoys, create strategies and scenarios) and maintain such a solution (e.g., dedicated maintenance teams).  

Today, the market is expanding, mainly around detection thanks to Deceptive, but not exclusively. For the time being, however, vendors’ interest in building deceptive solutions is focused on traditional environments. Solutions for Cloud AWS, Azure, etc., are still underdeveloped. 

Thanks to Augustin TOURNYOL DU CLOS for his contribution to this article.

Cet article Deceptive Security: the solution for effective detection in the cloud? – your luring strategy.  est apparu en premier sur RiskInsight.