AD Shared Account Attribution: Qualify the Logon Evidence

What AD Shared Account Attribution Must Establish

AD shared account attribution starts with a distinction: a directory account is a security principal, while an operator is the person using it. An account called shared-support may deserve review, but its name does not prove that several people know its credentials. A logon under that account can establish account use without identifying the person behind it.

Treat a naming finding as an investigation queue. For each selected account, establish its owner, actual purpose, authorized users, dependent systems, and available logon evidence. Keep the directory observation, authentication evidence, and human attribution as separate conclusions. A legitimate service dependency and an unattributable human session require different responses even when they use the same account name.

Our account classification, ownership, and expiry review covers how to resolve generic names and account purpose. This guide adds the evidence contract for attributing activity: which identity each Windows event describes, where to correlate it, and what remains unknown before retirement.

How the Qualification Process Works

1. Build a case record for each account

Record the account's domain, SAM name, SID, current enabled state, collection time, accountable owner, and intended use. List known services, scheduled tasks, applications, administrative workflows, and recovery requirements. An owner is responsible for resolving the case; ownership alone does not establish who performed a particular logon.

Ask the owner which people can obtain or use the credentials and through which access paths. Separate documented authorization from observed use. If the owner says only one person uses the account, retain that statement as an assertion to check against evidence. If nobody can identify the owner, keep the case open with a named person responsible for the next investigation step.

Review disabled accounts too. The detector includes matching disabled users, so its count is not a count of active shared sessions. Preserve historical evidence where available and verify dependencies before deciding whether a disabled object can be retired. A current directory state does not establish what happened during an earlier investigation window.

2. Define the evidence boundary before searching

Identify the initiating workstations or management hosts, destination servers, and relevant time interval. Verify which of those systems generate and forward the required Security events. Both event pages place the events under Audit Logon. Collection from domain controllers alone does not establish coverage of every destination session or initiating process.

For the wider audit-policy and event inventory, use our Active Directory monitoring event and collection guide. In this case, the operational question is narrower: can the team retrieve the evidence for this account, on these hosts, during this interval, with the identity fields preserved?

Document local retention, forwarding gaps, parser behavior, access limitations, and clock alignment before drawing a negative conclusion. Preserve the original event XML or an equivalent lossless record alongside normalized fields. A SIEM column named Account can conceal whether the parser selected Subject or Target; validate that mapping against the event itself.

Detection: Separate 4624 and 4648 Identities

3. Read the successful session on the destination

Microsoft's event 4624 reference defines it as creation of a logon session on the computer accessed. Its Subject describes the account reporting or invoking the logon; New Logon describes the account for which the session was created. Do not attribute the session to a person by reading Subject alone.

Keep these event fields separate in the case record:

For example, Logon Type 3 describes a network logon, 4 a batch logon, 5 a service logon, and 10 a remote interactive logon. These descriptions help test whether observed use fits the owner's declared purpose. They are not human-attribution verdicts: a network session can be initiated by automation, and a service session does not identify the person who configured it.

The 4624 reference also explains that address, port, and workstation availability depends on authentication context and protocol. An empty source field should remain empty in the evidence record; do not fill it from another event merely because the account name matches. The shared account's SID identifies that principal, not which of its possible users acted.

4. Read explicit credentials without swapping the identities

Microsoft's event 4648 reference describes a process attempting a logon with explicitly supplied credentials. This also occurs during routine activity, including scheduled tasks and RUNAS. Its Subject is the requesting account; Account Whose Credentials Were Used is the credential identity. Those can be different accounts.

A 4648 record with a named Subject and a shared Target is useful evidence of that named security context requesting use of the shared credentials. It does not independently establish the person controlling the context. It also describes an attempt; do not turn it into a successful destination logon without supporting evidence. The event's XML lists target name, domain, and GUID; do not assume it supplies a target SID just because a normalized schema has a column for one.

5. Correlate within the correct host and session

Start from the relevant host, timestamp, and identity section. Microsoft's Logon ID correlation guidance limits uniqueness to one computer between reboots. Keep Logon ID joins within that host and boot interval, not across the domain. For an initiating 4648, look for the corresponding local 4624 session using the 4648 Subject logon context and the 4624 New Logon context. Joining Subject to Subject indiscriminately answers a different question.

Preserve both 4648 GUIDs. Microsoft's references describe same-computer 4624/4648 correlation when the relevant GUID is available. Neither a Subject GUID nor a credential GUID should be selected automatically just because a parser renamed both to one generic field. Establish which session the proposed match represents and retain the basis for that decision.

A GUID containing only zeros is unavailable evidence, not a common session shared by every record carrying zeros. Across initiating and destination hosts, build a timeline from account/domain, target host, available source context, and timestamps. Label that association as contextual when no reliable session link exists. Never equate identical hexadecimal Logon IDs on two machines.

6. Record confidence and conflicting explanations

Use explicit confidence categories as a review convention, not a Microsoft scoring system. Account use can be confirmed while human attribution remains unresolved. Keep separate columns for those conclusions rather than assigning one reassuring score to the entire case.

Independent evidence might be an individually authenticated access gateway or credential-checkout record, if the organization has one and its timestamps and identities can be verified. A roster, IP address, or owner's recollection alone is weaker evidence. Record alternatives such as scheduled automation or another person controlling the initiating session; document why the retained explanation is better supported.

This is an investigation workflow, not a query reported as executed. No host or SIEM test was run for this guide. Validate field mappings and correlations with controlled, authorized activity before relying on them operationally.

Remediation: Restore Accountability Before Retirement

7. Replace shared human access with nominative access

For human workflows, plan access through individual operator identities and verify that records preserve the individual identity through the privileged action. Changing shared-support to a personal-looking name does not create accountability. Confirm who can obtain credentials, how access is approved, and how access can be removed when a person's role changes.

For automation, document the workload and its owner separately from human operators. Review migration options with the application team rather than forcing an interactive identity design onto a service. The aim is to remove unnecessary credential sharing while preserving legitimate dependencies and a reviewable access trail.

If an immediate replacement is impossible, document a temporary exception with an owner, approved purpose, authorized users, permitted hosts, compensating evidence, expiry, and migration milestone. An exception with no usable attribution trail should say so explicitly. A future expiry does not make today's ambiguous session attributable.

8. Disable only a reviewed identity

Before retirement, obtain the owner's dependency assessment, check recovery arrangements, preserve investigation records, and agree on validation and rollback responsibilities. Decide separately whether evidence supports a compromise response. A naming finding alone does not establish compromise or justify an estate-wide credential operation.

For an ordinary account approved for retirement, the following is an adaptation of the documented parameters in Disable-ADAccount. The DN and writable domain controller are illustrative; verify both before use. These examples require the ActiveDirectory module and directory permissions and were not executed for this article.

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -WhatIf

-WhatIf previews the operation; it does not test whether an application will break. After the dependency review and approved change window, the corresponding targeted action is:

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Do not pipe every naming match into a disable operation. Verify the resulting directory state and dependent workflows after the approved change. Deletion needs a separate retention and recovery decision; neither a low detector count nor an event-free interval supplies that authorization.

9. Close with the decision the evidence supports

Answer three questions for every account: which hosts and audit policies supplied the required evidence; whether an independent nominative operator identity exists; and which dependencies require a temporary exception before removal. If an answer is missing, retain the unresolved question, responsible owner, and next review date.

Close with a concrete outcome: human access replaced, workload dependency migrated, unnecessary identity disabled, or temporary exception retained. Attach the confidence rationale and evidence gaps. A completed review should explain both the operational decision and the limits of any historical attribution claim.

How EtcSec Detects This

The etc-collector check SHARED_ACCOUNT is a Medium-severity Accounts finding. At collector commit 0423094759d50002457031317098417993e19510, Detect() in public/internal/audit/detectors/ad/accounts/patterns/shared-account.go:45 checks collected users' SAMAccountName against four case-insensitive prefixes:

(?i)^shared
(?i)^common
(?i)^generic
(?i)^guest-

These are product naming heuristics. shared-support and CommonDesk match; my-shared-support does not match ^shared because the prefix is anchored at the beginning. The check does not include service/svc prefixes, examine password knowledge, or determine how many people use an account.

Each matching user is added once, then the inner pattern loop stops. Count is the number of matching collected users, including disabled accounts: there is no enabled-state filter. When details are requested and matches exist, the finding includes affected user entities. The function returns a finding even when Count is zero.

The LDAP provider supplies directory users and attributes, not the 4624/4648 event history or an operator identity. This Detect does not correlate sessions, prove credential sharing, evaluate independent attribution records, or verify an approved retirement. A positive result opens the qualification process above; a zero count establishes only that no collected name matched these expressions, not that all account use is attributable.