How T1589 gather victim identity information shows up before an intrusion
Reconnaissance is often invisible until it is late, and T1589 Gather victim identity information is one of the steps where that gap matters most. In this technique, an adversary collects identity details such as credentials, email address formats, employee roles and authentication configuration so it can plan later access. This page targets MITRE ATT&CK Enterprise version 20.0, where T1589 sits under the Reconnaissance tactic (TA0043) and has 3 sub-techniques. The tactic's purpose, as ATT&CK describes it, is to gather information the adversary can use to plan future operations, and identity data is among the most useful inputs to that planning.
For a SOC lead, the practical point is that this activity usually happens outside your environment. Much of the collection draws on information already exposed to the public, such as published staff names, role titles, the naming pattern behind mail addresses, and public-facing sign-in pages that reveal which identity provider or single sign-on configuration is in use. Some of it can also arrive as direct contact with staff, for example messages that ask employees to confirm details. Because most of this occurs before any login attempt, the first evidence often sits in your own identity logs, mail gateway records or web server logs rather than in an intrusion alert. Confirm with your identity provider and mail platform which of these sources you retain and for how long, since that retention sets how far back you can investigate.
Which telemetry reveals T1589 and which open-source tool collects it
This table maps each data source to the T1589 behavior it can reveal and the open-source collector that gathers it. Read it as a starting point: Network Traffic Content is the primary source, while application and response logs add context where the victim's own services are exposed. Confirm each data component mapping against the ATT&CK version your detection library targets, because v18 changed data components.
| Data component | Signal to look for | Open-source collector |
|---|---|---|
| Network Traffic Content (DC0085), primary | Inbound requests to public identity-related endpoints, such as sign-in, password reset, account lookup or directory-style pages, arriving in patterns that enumerate many names or addresses from one source | Zeek for protocol-level HTTP and DNS logging, Suricata for rule-based alerts on request patterns, both collected in Security Onion |
| Network Traffic Content (DC0085), primary | Outbound or inbound DNS and HTTP content that references staff naming conventions, email formats or employee directories being queried from unfamiliar sources | Zeek DNS and HTTP logs, Suricata DNS and HTTP alerts, indexed in Security Onion for hunting |
| Application Log Content (DC0038), supporting | Repeated failed or unusual lookups against the victim's own sign-up, account recovery or profile features, including many distinct identifiers tried in short windows | Wazuh agents forwarding web server and application logs, with Wazuh rules for threshold and frequency patterns |
| Application Log Content (DC0038), supporting | Account existence responses being probed through login or reset forms, visible as differing status codes or messages across many accounts | Security Onion ingest of web application logs, correlated with Zeek HTTP records |
| Response Content (DC0104), supporting | Responses returned by the victim's public services that reveal whether an identity exists, such as differing error text or redirects | Zeek HTTP response fields, Suricata content matching on defined response patterns, reviewed in Security Onion |
| Network Traffic Flow (DC0078), context | Bursts of connections from a single source across many victim-facing endpoints, useful for confirming that content signals reflect a sustained pattern | Zeek connection logs and Wazuh network alerts where host-level data is available |
How the 3 T1589 sub-techniques differ for detection engineers
The three sub-techniques differ mainly in where they leave traces, so detection engineers should plan one data source per sub-technique. Credential gathering happens largely outside your environment, but its results appear inside it: a leaked password reused against your sign-in endpoints, a spike in authentication failures from addresses with no prior history, or password reset requests for accounts that never used them. Start by confirming that your identity provider, VPN and remote access logs, and web application authentication logs retain events long enough to correlate with breach notification feeds. This sub-technique needs the most tuning, because routine failed logins from mobile users and password managers can resemble the same pattern. Check the MITRE ATT&CK technique page for the authoritative sub-technique names before you write rules.
Email address gathering leaves its clearest trace at the mail edge. Harvesting often appears as a burst of recipient checks for addresses that do not exist, which shows up in SMTP session logs as rejected recipients and in a rising count of non-delivery reports. Confirm whether your gateway records rejected recipient attempts by source, and whether it rate limits or delays those sessions. This sub-technique also needs careful tuning, since misdirected mail, marketing list cleanups and bounced newsletters can produce similar rejection patterns. Build a baseline by sender domain and time window before setting thresholds. Review any public contact forms or password reset flows as well, and confirm whether they return different responses for valid and invalid addresses.
Employee name and role gathering is the hardest of the three to observe from inside your environment. Most of the material is public, such as staff pages, conference listings and professional networking profiles, and none of it crosses your logs. Your visibility comes from repeated automated lookups of staff directories, profile pages or organization chart endpoints, and from the social engineering that follows, which often arrives as phishing or pretext calls. Ask web and application owners which pages expose names and roles, and whether those pages log lookups with enough detail to separate a person from an automated client. Plan detection around the follow-on activity as well, and feed the findings into user awareness training so staff recognize pretexts that use publicly known roles.
Detection ideas for T1589 that SOC teams can tune
Each card describes one detection idea in words: the logic, the baseline it should be compared against, the thresholds to tune, and the benign activity most likely to fire it. Write every idea as a Sigma rule, store the rules in version control next to the log source configuration they depend on, and tag each rule with the ATT&CK version it targets.
Repeated unauthenticated identity lookups
Alert when one source address sends many unauthenticated requests to identity-disclosure endpoints such as account existence checks, password reset responses, profile lookups or public directory search. The baseline is the normal rate of these requests per source per hour, measured over several weeks. Tune the threshold on distinct account identifiers queried rather than raw request count, because a single user refreshing a page should not trigger it. Expected false positives include password reset campaigns run by the help desk, HR portals that enumerate staff for onboarding, and vulnerability scanners on an approved schedule. Exclude those sources by address and time window, and record each exclusion with an owner and a review date.
Unusual directory lookup volume
Alert when an authenticated account issues directory queries, such as LDAP searches for users, groups or email attributes, at a rate far above its own historical baseline. Build the baseline per account and per role, since a recruiter, an IT administrator and a service account behave very differently. Look at breadth as well as volume: a search that returns hundreds of distinct user objects in a short window is more telling than many searches for one known person. Expected false positives include address book synchronization, mail client refreshes, identity governance scans and new applications being onboarded. Confirm each service account's expected query pattern with its owner before setting thresholds.
Unusual mailbox lookup volume
Alert when a single mailbox or application identity queries the global address list, calendar free-busy data or mailbox metadata for many distinct recipients in a short period. The logic is a count of distinct recipient objects per identity per hour, compared against that identity's usual range. Watch for spikes that follow a password or credential change, because that combination often signals an account being used by someone other than its owner. Expected false positives include mass mail merges, shared mailbox administration, migration tooling and scheduled reporting jobs. Keep a register of these jobs so analysts can close alerts quickly without suppressing the identity entirely.
Public profile scraping from one client
Alert when a single client fingerprint or address requests many employee profile pages, org chart fragments or bio pages from public-facing sites in a short period. Use web server or application logs as the source and compare the count of distinct profile paths against a normal visitor pattern for the site. Recruiter activity and search engine crawlers are the main sources of benign noise, so allowlist known crawler identities only after verifying their address ranges with the operator. Treat this as a low-severity signal on its own and raise priority when it is followed by lookups of the same names in internal identity logs.
Correlated identity discovery chain
Correlate low-severity identity alerts over a longer window, grouping events by source address, user agent family and targeted identities. The rule fires only when at least two of the earlier detections touch overlapping identities within a defined period. Choose the window with the SOC team after reviewing a month of historical alerts, not from a default value. This reduces alert fatigue from any single noisy source and keeps the per-detection thresholds loose enough to avoid missing slow activity. Document which alerts feed the correlation and who approves changes to the grouping keys.
Rule lifecycle and version control
Store every Sigma rule in a Git repository with one file per detection, a header naming its ATT&CK technique and version, and a test case that shows a sample log line matching or not matching the logic. Changes go through a pull request reviewed by a detection engineer and a SOC analyst. Convert Sigma to the query language of the SIEM in the build pipeline so the deployed rule always matches the reviewed source. Record suppression lists in the same repository, so every exclusion has a history. Review each rule when ATT&CK releases rename or deprecate techniques, since ATT&CK can change technique mappings between versions.
How to validate that the T1589 detection fires
This sequence confirms that the T1589 detection responds to a scoped, approved emulation of identity gathering, and it produces a dated record of what fired, what did not, and where coverage is thin. The output is evidence a CISO or detection lead can review before relying on the rule.
Pin the ATT&CK version and sub-techniques
Before any test is planned, the detection lead records the ATT&CK version the rule maps to and lists the three T1589 sub-techniques in scope: Credentials, Email Addresses and Employee Names. Confirm the version against the MITRE ATT&CK updates page, since releases can rename or revoke techniques. The step is done when the version, the sub-techniques and the detection strategy IDs are written into the test plan and signed off by the detection owner.
Agree the emulation scope in writing
The security team, system owners and, where applicable, the cyber range provider agree in writing which lab or range segment will host the emulation, which accounts and data sets are involved, the time window, the named operators and the stop conditions. Use test identities and synthetic records only, never production personal data. The step closes when the approved scope document is filed with the test plan and every operator has acknowledged it.
Record expected log events per sub-technique
For each sub-technique in scope, the detection lead writes down what the telemetry should contain if the activity happens: which data components are expected to show it (for example Network Traffic Content or Application Log Content, depending on the rule), which source systems should log it, and which fields the rule keys on. This expectation list is the baseline the results are judged against. The step is complete when each in-scope sub-technique has at least one expected event and one named source.
Run the approved emulation
Trained operators perform the agreed activity in the lab or range, following the scope document and the sequence in the test plan, with an observer logging start and end times for each action. Operators do not improvise beyond the agreed steps, and any unexpected system impact triggers the stop conditions. The step is done when the operator log, the observer log and the scope document all reflect the same sequence.
Confirm the rule fires and the alert is triaged
The analyst checks the SIEM or alerting platform for each expected event, comparing the detection rule ID, the alert timestamp, the source host and the alert status against the operator log. Where a rule fires, the analyst confirms it reached the triage queue and was assigned a status. The step closes when every in-scope sub-technique has a recorded result of fired, partially fired or not fired.
Measure and document coverage gaps
The detection lead compares each expected event with what was actually logged and alerted, and classifies every gap: missing telemetry, a rule that did not match, an alert that was suppressed, or a log that arrived too late to be useful. Each gap gets an owner and a remediation item in the backlog. The step is complete when a gap register exists for this test cycle and the results are reviewed with the detection owner.
Record the evidence set for review
For each test run, record the timestamp of each action, the originating source, the rule ID and version, the alert status, and analyst notes explaining any decision. Store the operator log, the scope document, the alert exports and the gap register together so an internal reviewer or external assessor can trace the result. The step is done when the evidence set is complete and a retest date is set for any gap that was not closed.
Preventive controls that reduce T1589 exposure
T1589 depends on identity data that the victim exposes before any intrusion begins, so most preventive work happens outside the detection stack. The cards below separate reducing public identity exposure from the supporting mitigations ATT&CK maps to Reconnaissance, and each one names a check a team can run in its own environment.
Reduce public identity exposure
Pre-compromise (M1056) is the primary ATT&CK mitigation for T1589 and covers actions taken before an adversary reaches the target. For identity data, this means inventorying which employee names, job titles, email formats, usernames and profile pages are published on corporate sites, press releases, job postings and public code repositories. Review that inventory with HR, communications and legal, and remove or generalize what is not needed. Confirm the mapping on the ATT&CK page for T1589.
Monitor for leaked identity data
Pre-compromise also covers watching for identity data that already appears in third-party sources, such as breach corpora, paste sites and professional networking pages. Assign an owner to review results on a set schedule and document who decides whether a finding needs action. Credential-related findings should go to the identity team for password resets or session revocation. The output of this review feeds the exposure inventory above, so the two controls should be run together.
Limit identity details in public code
Developer repositories, container images, build logs and documentation often expose internal usernames, email addresses, service account names and team structures. Set Software Configuration (M1054) controls so that repositories and published artifacts are scanned for personal identifiers before release, and keep internal account names out of public examples. Teams should confirm with their ATT&CK mapping that M1054 applies to T1589 in their version of the matrix.
Audit identity disclosure in web and content
Audit (M1047) applies where an organization reviews its own published material on a regular basis. For T1589, an audit can check whether staff directories, org charts, contact pages and document metadata reveal names, roles or account formats. Document the audit scope, the reviewer and the remediation path so the results are repeatable. Ask whether the audit covers files published by partners and contractors on the organization's behalf.
Train staff on public profile exposure
User Training (M1017) is listed for Reconnaissance techniques generally, and its relevance to T1589 is mainly indirect. Staff who publish profiles, speak at events or post about their roles can reveal identifiers that adversaries then correlate. Short guidance on what to avoid sharing, such as account naming conventions and internal system names, gives employees a practical check. Confirm in the ATT&CK page whether M1017 is mapped to the sub-techniques you plan to cover.
What the SOC does when a T1589 alert fires
The first decision on a T1589 alert is whether the activity is legitimate, because identity gathering looks much like ordinary business. Confirm the source before anything else: a partner's integration, a security researcher's disclosed testing, an internal scan or a monitoring service can all query identity-related content on public sites and produce the same signal. Check the requesting address against your asset inventory, your partner list and any authorized testing calendar, and ask the owner of the suspected system to confirm whether the activity was expected. Record the outcome as either authorized, unexplained or suspicious. Only the last two categories move on to the steps below. Because T1589 is usually an early signal, the aim is to judge what an adversary could do next with any identities they have collected, not to treat the alert as an intrusion in itself.
For anything not cleared, look for follow-on use of the identities that the activity may have exposed. In your identity provider, review sign-in events for the affected accounts over the period around the alert, paying attention to failed attempts against many accounts from a single source, password reset requests, and sign-ins from unfamiliar locations or devices. In mail logs, look for login alerts, unusual message rules, and spikes in messages to or from the exposed addresses, since phishing for information (T1598) often follows identity collection. Confirm which log sources actually cover your identity provider and mail platform in your Wazuh or Security Onion deployment, because a gap in collection will look like a clean result. Note the exact time window and sources you checked so the review can be repeated.
Then decide what to do with the exposed identities. If follow-on authentication attempts or credential reuse appear, reset affected passwords, revoke sessions and tokens, and enforce multifactor authentication for those accounts. If nothing suspicious appears but the identities are sensitive, such as privileged accounts or staff in finance and administration, add them to a watchlist for a defined period and keep the alert rule active. Open a case record that states the alert, the source assessment, the identities reviewed, the log sources and time window, the decisions taken and the owner of each follow-up action. Ask your SOC lead to confirm the retention period for that record and the criteria for closing it. Retain the case so that a later incident involving the same identities can be linked back to this early signal.
Rehearsing T1589 detection in a private cyber range
The range should be a private, isolated copy of the parts of the environment that T1589 detections depend on: identity services, mail services and the log pipeline that carries their events to the monitoring platform. Many teams build it with a Wazuh or Security Onion stack, which can receive events from identity and mail sources and hold them for analysis. Keep the range separate from production networks and confirm in writing who owns each component before any test traffic is generated.
- Sample identity service: Deploy a directory service populated with synthetic users, groups and attributes that resemble, but do not copy, production records.
- Sample mail service: Run a mail system with synthetic mailboxes so that lookups against published address formats can be logged and reviewed.
- Log forwarding: Configure agents or syslog forwarders so authentication, directory query and mail events reach the monitoring stack with their original timestamps and source fields intact.
- Time synchronization: Confirm that every range component uses the same time source, because alert windows are only meaningful when event times line up.
- Access control: Limit range access to named staff and record every change to the configuration.
Before testing starts, check that each log source reports the fields your T1589 analytics expect, and that the range has no path to production systems.
Injects are scripted events that the exercise team runs against the range. Agree the full list of injects in advance, label each one with the ATT&CK sub-technique it is meant to exercise, and record the expected detection outcome for each. Use a mix of benign and suspicious patterns so the team measures false positives as well as missed detections. Every inject should be reviewed against the written scope before it runs.
- Benign baseline: Routine directory lookups by a service account, a help desk search for a colleague and a mail client autocomplete, all expected to produce no high-severity alert.
- Suspicious lookups: Bursts of directory queries from one host across many accounts, or repeated mail-address validation attempts in a short window, expected to raise a named alert.
- Format-probing pattern: An illustrative sequence where several non-existent addresses are checked in a single session, to test whether the analytic groups related events.
- Out-of-hours activity: The same suspicious pattern run at an unusual time, to confirm the rule does not depend on business hours alone.
- Scripted timing: Exact intervals and volumes are set during planning, and the injects are executed by a named operator from a predefined runbook.
Record each inject's start and end time so that results can be matched to the monitoring platform's timeline.
A successful rehearsal shows that the right alert fires inside the window agreed in planning, carries enough context for an analyst to act, and reaches the response team through a documented handoff. Measure results against the expected outcome for each inject rather than against a general sense that the exercise went well. Findings that show a gap are useful, so record them without assigning blame.
- Timely alert: The expected rule fires within the agreed window after each suspicious inject, and benign injects produce no high-severity alert.
- Correct enrichment: The alert shows the source host, account, time range and the number of distinct targets, so an analyst can judge the activity without querying raw logs.
- Accurate mapping: Each alert is tagged with the ATT&CK technique and sub-technique it was written for, and the version of ATT&CK used is recorded.
- Documented handoff: The analyst records triage notes and passes the case to response staff through the agreed ticket or channel, with the handoff time captured.
- Lessons logged: Missed injects, noisy rules and unclear runbook steps are recorded as tuning actions with named owners.
After each exercise, check whether the same results would hold if the data volume rose to production levels.
How to score a T1589 exercise and turn results into detection work
Scoring a T1589 exercise means comparing what the adversary emulation actually did against what your stack alerted on, step by step. Before the range run, write down the expected alert for each action in the scenario, such as the Wazuh rule, Suricata signature or Zeek log entry you expect to fire when identity-related requests reach your monitored services. After the run, mark each expected alert as detected, missed (a false negative) or detected under a different rule than planned. Also record every alert that fired without a matching action in the scenario (a false positive) and note the time gap between action and alert, because a correct alert that arrives after the window your SOC relies on still counts as a gap.
Turn each gap into one of three work items. A missed alert where the telemetry exists usually points to a Sigma rule that is too narrow, a field name that differs between log sources, or a threshold that suits the lab but not production. A missed alert where the telemetry does not exist points to a new data source, such as application logs from a service that today only writes to a local file. A false positive usually needs a documented exclusion tied to a known business process, not a blanket suppression. Confirm each change against the Sigma and Wazuh rule syntax and version your team uses, and record the owner and the expected outcome for each item.
Re-run the same scenario after every change, using the same seed data, the same accounts and the same time window, so that differences in results come from your tuning and not from the exercise. Pin the ATT&CK version in the exercise record, for example Enterprise ATT&CK 20.0, and the STIX bundle you mapped against. Technique and sub-technique names can change between releases, so a rule mapped to T1589 under one version needs a check before it is compared with results under another. Ask your range provider to confirm in writing which ATT&CK version, rule set and log sources were in scope, so the scorecard can be audited later.
Common questions from SOC leads about detecting T1589
Can T1589 be detected from internal telemetry at all?
Only in part, and the answer depends on what your organization can see. T1589 covers gathering identity information such as employee names, email addresses and credentials, much of which is collected from outside your environment, so no internal sensor sees the collection itself. Internal telemetry can still reveal use of that information: directory query patterns that enumerate accounts, authentication failures against names that appear in exposed lists, and mail gateway activity aimed at harvested addresses. Before you promise coverage to leadership, confirm with your identity, directory and mail teams which of these logs you retain today and for how long.
How do you separate reconnaissance from normal identity lookups?
Look at volume, breadth, sequence and source rather than at any single lookup. Normal help desk and HR activity touches a few known accounts from managed workstations during business hours. Reconnaissance tends to enumerate many identities in a short window, often from unfamiliar hosts or service accounts that rarely query the directory. Build baselines per role from identity provider and directory logs, then alert on deviations such as one account querying far more objects than its peers. Record each tuning decision in your Sigma or Wazuh rule metadata so analysts can explain why an alert fired and why another was suppressed.
Which data components should you prioritize for T1589?
Start with Application Log Content (DC0038) from identity providers, directory services and mail gateways, because it records who queried what and when. Add Network Traffic Content (DC0085) where encrypted or cleartext protocol content is visible at your sensors, and Network Traffic Flow (DC0078) to track volume and source patterns across time. ATT&CK's detection mappings for Reconnaissance techniques most often reference these components alongside Response Content (DC0104). Check the exact mapping for T1589 and its sub-techniques in the enterprise-attack 20.0 STIX bundle, because the components linked to a single technique can differ from the broader Reconnaissance set.
How should a SOC handle ATT&CK version changes in detection content?
Pin every detection to a named ATT&CK version in its metadata, so a future change never silently alters what a rule claims to cover. MITRE's recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. v18 replaced the detections in technique pages with detection strategies and analytics, and it deprecated data sources in favor of data components, so older rule references may need rewriting. Releases can rename, deprecate or revoke techniques, so compare the STIX bundle for each new version against your register, re-map affected rules and retest them before you change the version tag.
How do you test T1589 detections without touching production identity systems?
Replay the behavior in a private cyber range that mirrors your identity provider, directory and mail stack, populated with synthetic accounts and seeded data. Emulate the observable pattern, such as a burst of directory queries from one source across many synthetic identities, and keep intrusive tooling out of live directories entirely. Record the expected alert, the time to alert and the analyst action taken, then confirm the event reached your SIEM with the fields your rule depends on. Flag range accounts so they are excluded from business reporting, and tell the on-call team when a drill window opens so responders do not treat it as a live incident. Illustrative example: a range with a few dozen seeded users and one scripted enumeration window per test run.
What evidence should you keep for an audit of T1589 detection?
Keep a detection register that lists each rule, its ATT&CK technique and sub-technique IDs, the ATT&CK version it targets, the data sources it reads and a named owner. Retain rule version history, dated cyber range test records, sample alerts, tuning decisions and links to the response runbook. Add evidence that identity and mail logs were retained and available during the test windows, since an assessor will ask whether the detection could have fired at all. DeployOpen can prepare and organize this evidence as part of an engagement, but independent auditors and certification bodies issue any opinion or certification. Ask your assessor early which artifacts they expect in what format.
How DeployOpen builds T1589 detections and range exercises
A fixed-scope T1589 engagement starts with written scope, not with tooling. DeployOpen first confirms which ATT&CK version the client's detection library will target, since releases can rename, deprecate or revoke techniques and sub-techniques, and the ATT&CK updates pages list the release dates the team checks against. The team then inventories which telemetry the client actually collects for T1589 and its three sub-techniques, focusing on Network Traffic Content (DC0085) and, where the client has them, application and web logs. Any data source that is missing or only partly collected is recorded as a gap with an owner, so the scope reflects what the SIEM can really see. Deliverables, timelines and exclusions are agreed in writing before work begins.
With scope and data confirmed, DeployOpen writes Sigma rules for the client's SIEM and translates them into the client's query language, then tunes them against a baseline of normal traffic. Tuning covers the usual sources of false positives in identity-related lookups, such as legitimate directory queries, approved HR or marketing tooling and vulnerability scanners, and each exclusion is documented with its justification and an expiry or review date. Rule logic, field mappings and log source assumptions are kept under version control so the client can see exactly what changed between releases. Ongoing tuning and rule updates for later ATT&CK versions can be placed under a retainer rather than assumed as one-time work.
Validation happens in a private cyber range, where DeployOpen plans a purple team exercise with the client's detection and response staff. The plan defines the activity categories to simulate, the expected log entries and alerts for each, the roles of the people observing and responding, and the stop conditions. After the exercise, the team records which detections fired, which did not, and why, then feeds the results back into rule changes. DeployOpen prepares this evidence (rule versions, test records, gap reports and tuning decisions) for the client's compliance assessments, but it does not issue audit reports or attestations; independent auditors and certification bodies make those determinations.
