Microsoft Defender XDR is expanding in the full attack stage. With the new Deception capability in Microsoft Defender XDR, it is possible to detect attackers early in the kill chain and disrupt advanced attacks.

Deception is a new feature for Microsoft Defender for Endpoint part of Defender XDR and is now in public preview. The new feature uses machine learning to autogenerate and deploy authentic decoys and lures into your environment. The real power is that no additional deployment of sensors is required and it is fully integrated into the XDR experience.

Important: Deception is currently in public preview available.

Blog information:

Blog published: 16 January, 2024
Blog latest updated: 16 January, 2024

What is deception in Defender for Endpoint?

Deception is a built-in capacity in Microsoft Defender for Endpoint. Deception technologies create an artificial cyber-attack surface within your network that consists of fake credentials/ hosts and decoys that look like high-value assets. The ultimate goal is to deceive attackers and lead them into sensitive credentials/ hosts.

When the deception assets are used it will lead to detections into the Defender XDR portal. It can lead to early signs of the attack chain during the credential theft and discovery phase. Attackers commonly use LSASS and local DNS cache dump/ documents to find interesting hosts and credentials.

Image source: Microsoft

When using deception the following is good to know before starting. In general, there are two items part of the Deception feature (Decoys and Lures).

  • Decoys: “fake” assets that trigger an alert when an attacker interacts with the assets, such as a user and host.
  • Lures: are digital breadcrumbs that lead attackers to decoys and make them look more authentic, such as batch files/ file locations and more

Prerequisites

For the Deception capability, the following prerequisites are important. Currently, the feature is supported for Windows Endpoints only.

Defender must be the primary EDR solution since Defender for Endpoint must be able to deploy the lures:

  • Defender for Endpoint is the primary EDR solution
  • Automated investigation and response is configured and enabled
  • Devices are joined or hybrid joined in Microsoft Entra ID
  • PowerShell is enabled
  • Deception has been supported since Windows 10 RS5 and later

When PowerShell is restricted it will give possible conflicts with the deployment of the Lures. When the Decoys are not deployed, check the PowerShell configuration.

More information: Manage the deception capability in Microsoft Defender XDR | Microsoft Learn

How to enable deception

The deception capability is part of Defender XDR and can be enabled via security.microsoft.com. By default, the feature is turned off. To turn the feature on, follow the steps below:

  • Select Settings > Endpoints.
  • Under General, select Advanced features.
  • Look for Deception and toggle the switch to On.

Important: When enabling the deception feature it will automatically enable a default rule. The default rule is enabled by default and deployed to all Windows client devices. When a small scoped test is required with a couple of endpoints it is recommended to disable the default rule and use a custom deception rule with a configured scope or change the scope of the default rule.

The deception feature can be configured via Settings -> Endpoints -> Deception. The rule with the name “Default Rule” is generated by default.

Important: Lures are only planted on Windows clients defined in the scope of a deception rule. However, attempts to use any decoy host or account on any Defender for Endpoint onboarded client raises a deception alert. It can take a couple of hours before the configuration is deployed to machines.

Create and modify deception rules

The deception feature can be configured via Settings -> Endpoints -> Deception. The rule with the name “Default Rule” is generated by default. In the configuration, it is possible to change existing rules and configure new rules.

To create a new rule select Add Deception Rule

The wizard starts with the name and Lures type. There are two different types of Lures:

Basic lures – planted documents, link files, and the like that have no or minimal interaction with the customer environment.

Advanced lures – planted content like cached credentials and interceptions that respond or interact with the customer environment. For example, attackers might interact with decoy credentials that were injected in responses to Active Directory queries, which can be used to sign in.

Recommended is to configure both Basic and Advanced in the rule creation, which brings ultimate flexibility during the creation of lures.

Scope

In the scope wizard it is possible to scope the lures to All Windows client devices or Devices with specific tags. The tag capability works based on the Defender for Endpoint tagging mechanism, any configured tag can be selected in the wizard.

Personally; In larger production environments I would recommend starting with a selected scope based on a specific tag. With this, there is less risk across all devices.

Decoys

During the setup Defender XDR will automatically generate decoys. Decoys are nonexistent accounts and hosts.

The generation of decoys is based on ML. Using sophisticated ML models, Defender for Endpoint automatically creates assets based on the existing onboarded machines and detected user name conventions.

In this advice; my recommendation is to review the ML generation and create a new custom rule matching the naming convention when needed. The goal of deception is to match the company name convention and avoid too many non-company related names since too many fake accounts can be detected easily by attackers and make them suspicious. In some cases, the default ML-generated list is already sufficient with proper decoys and a good naming convention.

Custom decoy (account and host) can be created via the wizard. Host decoys can be configured with an IP of a honeypot VM. With a static IP address, attackers are led to an existing “honeypot” device.

Lures

Lures can be configured via the following two ways:

  • Use autogenerated lures
  • Use custom lures only

Lures are digital breadcrumbs that lead attackers to decoys and make them look more authentic, such as documents, batch files, and more.

For the initial configuration, it is advisable to start with the autogenerated lures – the custom lures only feature can be used to define lures that look more authentic based on organizational criteria

Deployment

When the lures are configured, and the rule is configured/ deployed the Lures are successfully created. It will take some time before the Lures are deployed to the scoped endpoints. The status “In Progress” indicates the deployment is still in progress. (It can take some hours before the decoys are deployed across the targeted endpoints).

When the rule is successfully deployed it will show the status On with a count of devices. This indicates the rule is successfully enabled.

With the use of the Export to CSV button, it is possible to confirm if the lures are correctly planted on the endpoint/ devices.

Part of the CSV is more information. Select the deception rule and click export to CSV. As a result, the CSV contains all the information including the deployed endpoints.

Result of the CSV file: With the deployment status and device ID it is possible to track whether the decoy is correctly enabled for which specific device. It will show the decoy/ lure type and decoy entity path.

When the deployment is failed it will show the deploymentstatus Failed with additional comments.

Where are the decoys located?

All decoys are planted on the scoped MDE devices and not planted in the Active Directory or Azure Active Directory. More detailed entity path locations are visible via the export CSV method as already explained in the previous step. For the fake credential type, there are various other locations where the credentials are located and planted.

Since this blog is publicly available – I will not share the actual location where the decoys are visible, and what it looks like from the end-end user’s devices. Since the real power of deception is based on visibility, and how it looks like normal/ used accounts.

Test and simulate

Simulation of alerts based on the deception accounts is possible via various methods.

When a decoy is targeted (e.g. by Red Team or Bad Actors by lateral movement, an Incident with the tag (deception) is created in Microsoft Defender XDR.

Good to know – all alerts related to the deception feature are tagged with the tag “Deception” in the Microsoft Defender XDR portal.

Simulate alert for host

An RDP (Remote Desktop Protocol) session to a discovered device results in an error but is enough to trigger the alert in Defender XDR. RDP to one of the hostnames; and the alert with the name: Connection attempt over RDP to a deceptive host will show in the portal.

Simulate alert for user

When using the deceptive user decoys during a sign-in to any MDE-covered devices in the tenant, it will lead to the following alert visible in Defender XDR: Sign-in attempt with the deceptive user account.

Conclusion

Deception is a great new feature as part of the Defender XDR solution. It will increase the detection of attacks launched during the early stages. It is good to see the deception feature is powered by existing agents and is running without any additional sensors or separate agents installed on endpoints.

Sources

Microsoft: Manage the deception capability in Microsoft Defender XDR

Microsoft: Microsoft Defender for Endpoint deception | Ninjashow