Hi everyone,

I’m investigating a Purple Knight finding called “Abnormal Password Refresh” (SI000098) and I’m trying to understand the detection and how to investigate the accounts it identifies.

Tiltle :- Purple Knight SI000098 (Abnormal Password Refresh) – How do you investigate the flagged accounts?

In our previous Purple Knight scan, the finding showed 6 accounts. In the latest scan, it shows 3 accounts.

I’m trying to understand:

1. Why exactly does Purple Knight flag an account for Abnormal Password Refresh?
2. What could cause an account to appear in one scan and disappear from the next scan?
3. How can I determine what actually changed between the two scans?
4. How do I identify which of the remaining accounts are genuinely suspicious versus legitimate administrative activity?
5. What evidence should I collect to determine the root cause?

What I understand so far

The Purple Knight report says:

“This indicator looks for user accounts with a recent pwdLastSet change without a corresponding password replication.”

The report also says that one possible legitimate scenario is when an administrator enables “User must change password at next logon” and later clears that setting. This can cause pwdLastSet to change even though the user's password was not actually changed.

I reproduced this scenario in an isolated lab:

Create test user ↓ Enable "User must change password at next logon" ↓ User does NOT log in/change password ↓ Clear the checkbox ↓ pwdLastSet changes ↓ unicodePwd-related replication metadata does not have the corresponding new change ↓ Purple Knight flags the account 

In my lab, Purple Knight subsequently reported:

Found 1 user(s) with a mismatch between pwdLastSet and unicodePwd.

So I understand one possible legitimate cause.

My problem is production

In production, there are hundreds/thousands of users, so I don't think an administrator is manually checking and unchecking this option for every affected user.

The latest/previous Purple Knight results give accounts with information similar to:

Ignored | ObjectGUID | EventTimestamp | SamAccountName | DistinguishedName FALSE | ... | 09/05/2026 ... | user1 | CN=... FALSE | ... | 08/19/2026 ... | user2 | CN=... FALSE | ... | 08/20/2026 ... | user3 | CN=... 

Some accounts are normal employees and some are in O365/NonEmployees or service-account-related OUs.

What I want to understand

If Purple Knight detects:

pwdLastSet → recent change but corresponding password replication/change evidence doesn't match 

What are the possible real-world causes besides an administrator manually changing the ADUC checkbox?

Could this be caused by:

• Helpdesk password resets?
• Automated IAM/provisioning systems?
• Scripts?
• Account onboarding/offboarding processes?
• Password policy operations?
• Replication-related situations?
• Something else?

And, most importantly:

How should I investigate the 3 remaining accounts?

For example, should I correlate the Purple Knight EventTimestamp with Windows Security events such as:

• 4723 – password change attempt
• 4724 – password reset attempt
• 4738 – user account changed

and then correlate those events with AD replication metadata such as:

• pwdLastSet
• unicodePwd
• Version
• LastOriginatingChangeTime
• LastOriginatingServer

?

Also, if the audit logs were not enabled at the time of the original event, what other evidence can be used to determine why the mismatch occurred?

Finally, if a previous scan had 6 accounts and the new scan has 3, what is the recommended way to determine why those 3 disappeared from the finding? Is there a way in Purple Knight to identify the condition that cleared, or should I compare the two reports and investigate the affected accounts individually?

I’m looking for a defensive investigation approach, not exploitation instructions.

Any guidance from people who have worked with Purple Knight / AD password auditing would be greatly appreciated!

Environment: Windows Server Active Directory / Domain Controllers + Semperis Purple Knight
Purple Knight version: 5.0.2506.11001 (Community Edition)

I'm mainly looking for guidance on how others investigate this indicator in a real AD environment. Specifically: 1. What are the common legitimate causes of this mismatch? 2. How can I determine what changed between two Purple Knight scans? 3. What evidence can be used to determine whether a flagged account is simply an administrative/workflow issue or requires further investigation? 4. If Security auditing was not enabled at the time, what other evidence would you normally check?