We are introducing new Corporate Identity SSO options to make platform access easier, more secure, and better aligned with how customers already manage user authentication.

Many organisations already rely on Google Workspace, Microsoft Entra ID, Okta, or another corporate identity provider to manage access across business applications. With Corporate Identity SSO, users can sign in to ThreatDefence using their existing corporate account, reducing the need for separate local credentials and simplifying access management for customer teams.

This control is intentionally simple: deploy decoy identities, ensure they have no legitimate operational use, monitor them continuously, and alert when they are accessed or targeted. It is not a replacement for preventative identity controls, but it provides a strong detection layer for activity that may indicate account discovery, password spraying, Kerberoasting, credential misuse, or post-compromise reconnaissance.

Global SSO with Google and Microsoft

Users now are able to sign in using their corporate Google Workspace or Microsoft account.

This provides a simple sign-in option for organisations already using Google or Microsoft as their primary identity provider. It also helps reduce password fatigue and makes it easier for users to access the platform through familiar authentication flows.

Available sign-in options will include:

• Sign in with Google
• Sign in with Microsoft

When a user signs in with Google or Microsoft for the first time, ThreatDefence needs to confirm that the corporate identity belongs to the same person as the existing account.

To complete this process, the user will receive a verification email to their registered ThreatDefence email address.

The email will explain that someone is trying to link their ThreatDefence account with a Google or Microsoft account. If the request was initiated by the user, they can confirm the link by clickingthe verification link in the email. For security reasons, the verification link expires after 5 minutes.

Once the accounts are linked, the user will be able to sign in to ThreatDefence using their corporate Google or Microsoft account.

Why This Matters

Corporate Identity SSO with Google and Microsoft helps customers improve security and usability at the same time.

For users, it creates a simpler login experience because they can access ThreatDefence using their existing Google Workspace or Microsoft work account.

For administrators, it aligns platform access with the identity controls already managed in Google Workspace or Microsoft Entra ID, including MFA, conditional access, account disablement, and internal joiner / mover / leaver processes.

For security teams, it reduces reliance on standalone ThreatDefence credentials and helps ensure access to the platform follows the customer’s existing Google or Microsoft identity policies.

Customer Control

Customers who do not want global Google or Microsoft sign-in enabled will be able to disable the option.

1. The workstation requests a Ticket Granting Ticket from the domain controller.
2. The domain controller issues the Ticket Granting Ticket and a session key.
3. When the user accesses a domain-integrated resource, the workstation requests a service ticket.
4. The domain controller issues the service ticket and associated session key.
5. The workstation presents the service ticket to the resource server.
6. The resource server validates the ticket and grants access.

The same mechanisms used for legitimate authentication can be abused for privilege escalation and lateral movement. An attacker with access to a standard domain account may enumerate accounts with Service Principal Names and request Kerberos service tickets for those accounts. The attacker can then extract ticket material and attempt to crack it offline to recover the service account password, especially if the password is weak or reused.

A typical Kerberoasting flow is:

1. The attacker uses a valid domain account to request a Ticket Granting Ticket from the domain controller.
2. The domain controller issues the Ticket Granting Ticket.
3. The attacker requests a service ticket for an account with a Service Principal Name.
4. The domain controller issues the service ticket.
5. The attacker extracts the ticket material and attempts to crack it offline.

This behaviour can often be reconstructed from Windows security events and SIEM telemetry. The challenge is that this telemetry does not automatically prove malicious activity. Kerberos service ticket requests are completely normal in Active Directory. A real service account may legitimately receive authentication activity from multiple systems, applications, or users. In larger environments, the SOC must correlate the source user, source host, target account, service name, ticket options, encryption type, expected access patterns, and related endpoint or network activity before determining whether the event is suspicious.

Common Kerberoasting detections usually look for patterns such as:

• high-volume service ticket requests from one user or host;
• requests for rarely used Service Principal Names;
• requests from users that do not normally access those services;
• service ticket requests from unusual workstations;
• use of weaker encryption types;
• unusual activity involving privileged or high-value service accounts.

These detections are useful, but they can still be noisy in real environments because legitimate administrative tools, applications, scanners, and business systems may produce similar patterns.

With honeytokens in place, detection becomes more direct. A high-confidence alert can be generated when a domain controller records a Kerberos service ticket request, authentication attempt, or other account interaction involving a honeytoken identity. Unlike a normal service account, there is no expected business process to explain the activity, so the event can be treated as suspicious immediately and prioritised for SOC investigation.

The key event source is usually Windows Security Event ID 4769, which records Kerberos service ticket requests. Important fields for investigation : include

How to Enable Honeytokens

In the Customer Portal, go to Deployment → Honeytokens to view instructions on how to enable the feature.