Before A Stolen Password Becomes An Attack: Identity Protection With Group-IB XDR

Intended readership: CISOs, Heads of SOC, security operations teams, identity and access management teams, government and agency security teams, MSSPs

Available in: Group-IB XDR Console

An employee’s account can look entirely ordinary in Active Directory while its credentials circulate in criminal markets. The password meets your complexity requirements, the permissions match the employee’s role, and your team has seen no suspicious activity. An attacker with those credentials may be preparing to gain access, however — or looking for a way to move further through a network they have already entered.

For your SOC, the challenge is knowing which accounts attackers could use and acting before they use them. Group-IB XDR connects your Active Directory inventory with Group-IB Threat Intelligence to identify accounts with compromised credentials. Analysts can review the findings and reset affected passwords directly from the Console, without waiting for suspicious activity to trigger an investigation.

Keep reading to learn which accounts need your attention and how to act on the findings.

What stolen credentials could give an attacker

The criminal who steals a password may never use it. Credentials collected by an infostealer or a phishing page can be packaged and sold to another attacker, who assesses what access they might provide.

Group-IB’s research into The Gentlemen identified approximately 14,700 compromised FortiGate devices available to its affiliates. The group’s administrator recommended selecting devices integrated with Active Directory through LDAP, where compromised VPN accounts could provide opportunities for privilege escalation.

For a domain account, the opportunity depends on its permissions and the surrounding controls. Credentials may help an attacker gain initial access where remote access is available and authentication controls permit it. Once inside, an attacker may use another employee’s account to reach additional systems or, if the account has elevated privileges, gain greater control.

A compromised credential therefore matters at several stages of an attack. Identifying the affected account and resetting its password can reduce the opportunity for misuse while the team investigates the compromise.

The Verizon 2026 DBIR found that, among ransomware victims with an associated credential or infostealer event, half had such an event within the 95 days before being publicly identified as a ransomware victim. That finding does not establish when attackers first gained access. It does show why evidence of credential compromise deserves attention before ransomware makes an incident public.

Figure 1. Credential compromise before public identification as a ransomware victim, and where Group-IB XDR helps you act first.

Gartner predicts that by 2027, AI agents will reduce the time it takes to exploit account exposures by 50%. As attackers move faster, knowing which accounts are exposed and acting before they are used, becomes more important.

A compliant password can still be stolen

Password policies establish requirements for a credential. They cannot, on their own, establish whether it remains secret.

In the Active Directory assessments reported in the Verizon 2026 DBIR, the median share of accounts failing minimum password complexity requirements was below 1%, while the median share using passwords found in breach data was 4%. A password can satisfy your policy and still appear in data available to attackers.

​​Figure 2. Median account shares across assessed organizations

Endpoint and sign-in telemetry help teams identify suspicious activity already occurring within their environments. External credential intelligence adds evidence of compromise that may be available before an attacker attempts to use the account. That compromise is not always visible in public listings. Brokers sell high-value access to ransomware operators through private channels more and more often, making threat intelligence with visibility into these communications essential for identifying compromised credentials.

The next step is connecting that evidence to your organization. Analysts need to identify the affected account, understand its role and group memberships, and decide what to do. Gartner’s 2026 Predicts: Identity and Access Management highlights the visibility gaps left by isolated IAM tools and the need to bring identity information together.

Group-IB XDR makes that connection in the Console, linking external compromise intelligence to the domain accounts your team manages.

Finding the accounts attackers could use

Setup starts in the Group-IB XDR Console, where a guided wizard generates a preconfigured collector package. Installed on a Windows host inside your domain, the collector reads Active Directory over LDAP or LDAPS and synchronizes account and computer details with the Console.

For a cloud-hosted Console, the collector provides the connection to your on-premises directory through an encrypted channel. It needs network access to both Active Directory and the Console; you do not need to install it on every employee’s device.

The integration imports two types of information:

• Computers appear as assets, with details such as hostname, operating system, domain, and IP addresses resolved through DNS.
• User accounts appear in the internal employee inventory, with name, primary email, department, job title, and AD group membership.

After the initial import, incremental synchronization keeps the inventory current as directory information changes.

Group-IB XDR continuously checks imported accounts against Group-IB Threat Intelligence for evidence of compromise. When a match meets the alerting criteria, including how recently the compromise occurred, an alert appears in the XDR Console, linked to the affected account. This shows which accounts attackers could use to gain access, without waiting for suspicious activity inside the network.

The analyst can then review the finding alongside the account’s directory context, rather than manually matching a threat intelligence finding to a separate list of employees. This brings the evidence of credential compromise and the account’s business context together to inform the response.

Figure 3. External compromise intelligence becomes an account-level finding your SOC can act on.

Putting the finding in context

Alongside the compromise finding, the Console presents possible attack scenarios informed by Group-IB Threat Intelligence reports and previous incidents. These illustrate how compromised domain credentials could support initial access, lateral movement, or privilege escalation.

The scenarios help analysts consider the potential consequences of the compromise. They describe possible developments but they do not establish that those actions have occurred or map a confirmed route through the customer’s environment.

Combined with the account’s directory details, this information gives the analyst context for assessing the finding and deciding whether to reset the password.

Make the stolen password worthless

Once an authorized analyst decides a reset is required, they can initiate it directly from the Console. Group-IB XDR generates a random password, sets it in Active Directory, and retains no copy.

The employee regains access through your organization’s administrator-led process. Security and identity teams agree in advance who can initiate resets and how employee access will be restored.

The analyst reviewing the alert can reset the affected password without opening a ticket for another team to perform the reset. This shortens the time between finding a stolen password and making it useless to attackers.

This is preemptive action. If the password has not been used yet, the reset makes it worthless before the attacker can use it. Gartner calls this kind of action ‘deny’, one of the ways preemptive cybersecurity stops attacks before they launch or succeed. It adds to detection and response, and does not replace them

The reset replaces the compromised password. The investigation continues to establish how it leaked, whether it was used, and whether further containment is needed. Existing sessions or other access established by an attacker may require separate action.

Figure 4. Reset workflow. The analyst reviews the findings and resets the password, and an administrator helps the employee regain access.

Your SOC can act on evidence that an account’s password is in criminal hands, without waiting for a malicious login. If the password has not been used yet, the reset is preemptive: it stops the attack before it starts. Meanwhile, analysts investigate whether it has already been used.