Detecting T1585 Establish accounts

How T1585 Establish accounts shows up before an intrusion

For a SOC lead, the first thing to accept is that T1585 Establish accounts happens largely outside your network. Under the Resource Development tactic (MITRE ATT&CK tactic TA0042), an adversary creates accounts on services it controls so it can support later operations, such as sending lures, hosting staging content, or impersonating staff. It sits before Initial Access in the intrusion lifecycle, so the victim usually sees it only when those accounts touch the organization: an email from a new sender domain, a profile posing as a supplier, or a cloud identity appearing in a sign-in log. The visible signal is thin, so detection work starts with deciding which of those touchpoints you can observe at all.

ATT&CK splits T1585 into three sub-techniques. Social Media Accounts covers profiles on public platforms built to look like your company, a recruiter, or a known contact. Email Accounts covers mailboxes registered with services the adversary controls, used to send phishing or receive replies. Cloud Accounts covers identities created in cloud or software services, which can host content or gain trust in a tenant through guest or collaboration features. Each sub-technique leaves different traces, so a rule built on your email gateway will not see a fake professional profile. For each one, decide which data you can actually see, such as mail gateway logs, DNS and web content feeds, brand monitoring, and cloud sign-in and invitation logs.

This page targets Enterprise ATT&CK version 20.0, released on October 13, 2026. Technique and sub-technique mappings can change between releases because MITRE can rename, deprecate or revoke entries, so any detection you write should record the version it was built against. Confirm the current names in the MITRE ATT&CK updates page before you map alerts to them. Ask your detection engineering team to tag each analytic with its ATT&CK ID and version, so a later release does not quietly break coverage.

Which telemetry reveals establishing accounts

This table compares the telemetry that can reveal T1585 activity, the signal each source offers, and the open-source path into a monitoring pipeline. Treat each row as a starting point for a detection strategy, then confirm the data component mapping for the ATT&CK version you target. The main takeaway is that network content gives the most direct perimeter visibility, while social media signals usually arrive from outside your own logs.

Data component	Signal to look for	Open-source collector	Confirm before relying
Network Traffic Content (DC0085)	Outbound sign-up and verification traffic to public platforms from hosts with no business reason to register	Zeek HTTP and TLS logs, Suricata alerts, forwarded through Security Onion	Current DC0085 mapping to T1585 and each sub-technique in the enterprise-attack 20.0 STIX bundle
Social Media	Public profiles using organization names, brands or staff names created outside approved channels	Threat intelligence and OSINT feeds ingested into Wazuh or another SIEM index	Whether the mapping in your ATT&CK version names Social Media as a data component or a source
Sub-technique activity at the perimeter	Repeated account creation from one source, or sign-ups where user agent and geolocation do not match	Zeek conn and HTTP logs, correlated with proxy logs in Wazuh	Which sub-technique behaviors your collectors can actually see at your egress points
Proxy and DNS context	Sign-up domains first seen shortly before account creation attempts (illustrative pattern)	Zeek DNS logs and Security Onion dashboards for correlation	Log fields available from your resolvers and proxies at your current retention settings
Version drift	Detections that stop matching after a data component is reclassified in a new release	Version-pinned detection repository with a STIX-based mapping check	Mapping changes in each release, including v20 and any later version you adopt
Log retention	Enough history to link an account creation event to later activity in the same time window	Wazuh indexer and Security Onion storage, sized to your event volume	Retention requirements from your internal policy and any compliance framework you are preparing for

Detection logic for establishing accounts, described in words

T1585 Establish Accounts covers an adversary creating personas and accounts on services they can later use to support operations. The detection ideas below share one principle: start from the defender's own domains, brands and service contacts, then look for new, unexpected and clustered account activity against that baseline. Each card names the tuning levers and the false positive sources to expect before alerts reach an analyst.

New registrations against brand names

Compare newly observed account registrations on external services with your organization's domain names, executive names, product names and common misspellings, using the Social Media and Network Traffic Content telemetry you already collect. Tune the match on fuzzy string distance and on whether the registration uses your corporate email domain or a lookalike. Expect false positives from legitimate vendor sign-ups, partner portals and marketing agencies that create accounts in your brand name, so maintain an allowlist owned by the brand team. Express the logic as a Sigma rule for log sources you ingest, or as a Wazuh rule that correlates decoded events, and version it against the ATT&CK release you target.

Spikes in account creation

Alert when many accounts are created from one source address, one autonomous system or one user agent within a short window, measured against a baseline for that source. Tune the window length, the count threshold and the minimum number of distinct target services before a rule fires. Expect false positives from marketing automation, bulk SSO onboarding after a merger, and scheduled contractor provisioning, so suppress known identity provider and provisioning service addresses by name. This logic belongs in a Sigma correlation rule over authentication or proxy logs, with a Wazuh frequency rule as an alternative when events are already decoded on the manager.

First-seen service contacts

Flag outbound connections from managed endpoints to account-creation or social platforms that no host in your estate has contacted before, using Network Traffic Content from Zeek or Suricata metadata. Tune the look-back period for what counts as first seen and restrict the rule to hosts that have no business reason to reach social platforms, such as servers and privileged workstations. False positives come from new SaaS adoption, browser updates and vendor integrations, so review the first-seen list with the business owner before escalation. Carry the logic as a Suricata or Zeek script rule, with a Sigma rule for proxy logs as a parallel check.

Dormant accounts that become active

Track accounts tied to your domains or brands on external services that remain dormant for a long period and then show new activity, such as profile edits, follows or messages to employees. Tune the dormancy period and the type of activity that counts as a change, and exclude accounts that the organization created itself. Expect false positives from employees who reuse corporate email addresses for personal services and from accounts claimed through legitimate partner programs. Record the rule as a Sigma rule where the platform exports audit logs, and keep the watchlist of owned identifiers in a version-controlled file so the detection can be reviewed.

How to validate that the detection fires

This sequence proves that a detection for T1585 Establish Accounts fires on the expected evidence, reaches an analyst, and is understood well enough to tune. It turns a rule that looks correct on paper into a measured result the team can defend to auditors and leadership.

Define the account establishment scenario
The detection owner and a threat intelligence lead agree, in writing, which sub-technique the lab will represent (social media, email accounts or web services) and at what level of intent the scenario operates. The scenario is described as a set of observable outcomes, such as a new account appearing on a monitored platform or a registration event crossing a monitored boundary, rather than as operator steps. The step closes when the scenario document is signed off and names the ATT&CK version it targets, for example v20.0 as released by MITRE.
Map each expected signal to a data source
The team lists which telemetry should carry evidence for the scenario, including Network Traffic Content for traffic-level indicators and Social Media data where the platform and legal review allow it. For each signal, they record the log source, the field or data component expected to hold the evidence, and the expected alert severity. This turns the test into a checklist that can be verified after the run. The step is complete when every expected signal has an owner and a documented source.
Agree the expected alert outcome before testing
Before the scenario runs, the detection engineer, SOC lead and cyber range coordinator record what should happen: which Sigma or Wazuh rule should fire, which Security Onion or Zeek data should support it, what the analyst ticket should contain, and what counts as a miss. Writing the expectation first prevents the team from redefining success after seeing results. The step closes with a dated, versioned expectation record stored with the detection code.
Run the scenario inside the private range
The range operator executes the agreed scenario in the isolated cyber range, with logging enabled on all in-scope sources and a recorded start and stop time. Activity stays within range-owned identities and infrastructure, and the operator logs each scenario event against the expectation record. The step is done when the run is complete, the raw logs are preserved unaltered, and the operator has confirmed the scenario matched the documented intent.
Confirm the alert reaches the analyst queue
The SOC analyst on shift checks whether the alert appears in the case management or ticketing queue with the fields the playbook requires. The team measures the delay between the first logged event and the alert's arrival, and confirms that routing, severity and enrichment behaved as documented. Silent failures, such as a rule that matches but never forwards, are recorded as defects. The step closes when the alert is either confirmed in the queue with its timestamps or logged as a missed detection.
Record timing, false positives and gaps
The team compares observed results with the expectation record and logs three categories: latency between event and alert, benign events that also triggered the rule (false positives), and scenario events that produced no evidence (gaps). Each item gets an owner and a tuning or telemetry action. The team should ask the platform and sensor owners to confirm which fields are retained and for how long in their own environment. The step closes with a signed results record linked to the detection's ATT&CK technique and version.
Retest after tuning and retain the evidence
After any rule change, the team reruns the same scenario unchanged so results are comparable, and confirms that tuning did not remove the expected alert. The evidence package, including the scenario record, expectation, raw logs references, alert screenshots or exports and results record, is stored under change control. Compliance and audit contacts can use this package as readiness evidence, although only an independent auditor can issue an assessment conclusion. The step is complete when the retest matches the expectation or a documented exception is approved.

How to separate benign registrations from hostile ones

Analysts can only judge a new account or domain registration once they know what the organization expects to see. Before tuning any T1585 Establish accounts detection, build an enrichment layer that answers three questions for every hit: who owns the brand or domain name, whether the registrar or platform is on the approved vendor list, and whether the registration matches a known business activity. In practice this means maintaining a named owner for each protected brand and domain, an approved vendor register that security and procurement both sign off, and a list of marketing, legal and product teams that legitimately create social or third-party accounts. Feed these lists into your SIEM as lookup tables so that a Wazuh or Security Onion alert carries the owner and business justification with it.

Identity and HR feeds add the second layer. Single-event alerts are noisy because a new account on a social platform or a lookalike domain can be routine for a communications team and hostile for everyone else. Correlate the registration event with the SSO directory, so that an account created by a user who joined last week, has no approved request ticket and is outside the team's normal registration rate gets escalated, while a registration matching an open change request closes automatically. Baseline the normal registration rate per team and per brand over a period you choose, then alert on deviations rather than on every event. Correlate across sources only when a single signal is ambiguous, for example a lookalike domain that also resolves to new infrastructure or a brand-impersonating account that also posts links to a recently registered domain.

Before committing to a rule set, confirm which telemetry your environment actually produces. Ask your domain monitoring provider, social platform administrators and identity team which fields are available, how long they are retained, and whether they can be joined on a common key such as user, team or brand. The detection strategies for Resource Development in the ATT&CK knowledge base reference data components such as Domain Registration and Network Traffic Content, but coverage depends on your subscriptions and logging configuration, so verify each one. Record the ATT&CK version your rules target, since mappings can change between releases, and test each enrichment join in a private cyber range before relying on it in production.

Pre-compromise mitigation M1056 and related controls

ATT&CK maps the Pre-compromise mitigation (M1056) to this technique group because adversaries build their accounts on infrastructure and services outside your environment, where your direct controls stop. The cards below are preventive measures that shrink the value of those accounts to an adversary and give you earlier warning when they appear.

Monitor brand and domain abuse

Adversaries often create accounts that imitate your organization, staff or products on public platforms. Set up recurring searches for your brand names, executive names and look-alike domains across the services your customers use most. Decide in advance who reviews the results, how takedown requests are filed and which platforms you will report to. Confirm with your program owner that this watch list is reviewed on a set schedule and not only after an incident.

Govern approved external accounts

Keep a register of every account your organization holds on external services, including social media, code hosting, file sharing and vendor portals. Record the owner, the shared mailbox or group that controls recovery, the multi-factor method in use and the date of the last access review. Accounts with no named owner are the ones most likely to be taken over and reused. Ask whether your register is built from identity records or from manual lists that drift over time.

Track organizational identities on public services

Staff work email addresses are frequently reused to sign up for public services, which can make those services look like your own. Use your identity provider or directory to identify which corporate addresses appear on external sign-ups, and set a policy on whether staff may use work addresses for third-party services. Where a service is approved, require that it is linked to a managed group rather than a single personal inbox. Confirm the scope of this control with your HR and legal teams before you begin.

Control domains and certificates you own

Domains registered under your organization's name are a common foundation for accounts an adversary presents as legitimate. Maintain an inventory of registered domains, their registrars, the contacts on each record and the expiry dates. Watch certificate transparency logs for certificates issued to your names so that unexpected issuance is noticed quickly. Confirm with your domain administrator that registrar lock and two-person change approval are enabled for critical domains.

Set a review cycle for mapping coverage

The M1056 mapping shows which technique groups the mitigation is associated with, but it does not state how well your controls perform against them. Treat the mapping as a starting point and test each control against your own environment and threat model. Record which controls you rely on for T1585 and which are only partly in place. Confirm that your mapping names the ATT&CK version you target, because releases can rename or revoke techniques.

Triage and response when an account alert fires

When an alert indicates that an account or service may have been established to support an adversary, the first decision is ownership. Confirm whether the account, handle, mailbox or service tenant belongs to the organization by checking your asset inventory, your identity provider and the registrations held by your communications, marketing and procurement teams. Many alerts for look-alike accounts are triggered by brand monitoring that cannot see internal records, so an unclaimed match should be treated as external until proven otherwise. Record who checked, what they checked and when, because that record will matter if the case goes to legal review or a regulator. Next, examine the identity and domain records behind the account: registration details for linked domains, the display name and profile history, and any contact addresses or payment references that reference your staff or brands. Ask whether any internal user has created, used or been named in the account, including through a personal account on the organization's behalf. Those answers decide whether this is an external impersonation case, an unsanctioned internal account, or a compromised employee identity that also needs incident handling.

If the account impersonates the organization, its executives or its customers, escalate to your incident response lead, legal counsel and the communications team at the same time, since each function holds a different constraint on what can be said and by whom. Preserve evidence before anything is changed: capture the public pages, profile content and URLs, and keep the timestamps and collection method documented. Containment then follows the provider's process. Prepare a takedown request to the service provider that identifies the impersonated brand, the specific URLs or account identifiers, and the evidence of ownership, and confirm the provider's current reporting channels and documentation requirements before submission, since these vary by platform. For domains, coordinate with the registrar and your legal team on abuse reporting, and agree in advance who may approve a public statement. Track each request in your case system, and set a review date to confirm removal rather than assuming the first request succeeded. Finally, feed confirmed findings back into your brand monitoring and detection rules so the next alert is triaged faster.

How to rehearse T1585 detection in a private cyber range

The range should be an isolated network that mirrors the telemetry paths your production environment uses, but nothing in it should touch live services or real third-party platforms. Route endpoint and server logs into Wazuh or into the Security Onion stack, and place Zeek or Suricata sensors on the segments where outbound web and DNS traffic would be visible. A sandboxed external-service simulator stands in for public platforms, so that account creation events can be generated and observed without contacting anyone outside the range. Keep the sensor placement documented, because a rehearsal only tests what the sensors can actually see.

Isolated segment: Use a dedicated network with no default route to production or the internet, and enforce it at the firewall, not only by convention.
Log pipeline: Confirm that Wazuh agents or the Security Onion ingest path forward events with timestamps synchronized to one time source.
Network sensors: Position Zeek or Suricata where the simulated account sign-up traffic crosses the boundary, and record which fields each sensor emits.
External-service simulator: Host a sandboxed sign-up and login service that returns realistic-looking responses within the range only.
Baseline capture: Record normal traffic for a period before injects begin so that analysts can separate noise from the exercise.

Before the first exercise, check that each sensor logs what the detection analytics expect, using test traffic you generate yourself.

Questions SOC leads and detection engineers ask about T1585

Is Social Media telemetry available in our stack for detecting T1585?

Usually not out of the box, so confirm it before you plan the detection. Social Media telemetry for T1585 means monitoring public platforms for accounts that impersonate your organization, staff or brands. Most SIEM and EDR products do not ingest this natively, so you will typically need a monitoring service, a brand-protection feed or a scheduled collector that your team operates. Ask your vendor exactly which platforms, fields and retention periods are covered, and whether alerts can be forwarded into Wazuh or your existing SIEM with stable identifiers. Where no feed exists, document the gap as a known limitation and compensate with Network Traffic Content and DNS-based indicators.

How do we map detection rules to ATT&CK v20.0 without losing track of changes?

Tag every rule with the technique ID, sub-technique ID, data component and the ATT&CK version it was written against. MITRE publishes ATT&CK content in STIX 2.1 bundles, one per domain and version, so you can diff the enterprise bundle for v20.0 against the version you used before. Record the detection strategy identifiers and analytics your rule implements, not only the technique name. Keep the mapping in version control next to the rule so a reviewer can see what changed. Review the mapping each time you adopt a new release, because releases can rename, deprecate or revoke techniques.

How should we handle sub-technique changes between ATT&CK releases?

Treat sub-technique changes as a scheduled review item rather than an emergency. When a release adds, renames or deprecates a sub-technique under T1585, your mapping file should flag the affected rules automatically from the STIX diff. Then decide per rule whether it still matches the new definition, needs a new analytic, or should be retired. Keep old identifiers in the mapping for historical alerts so past investigations remain searchable. Confirm the current sub-technique list in the official ATT&CK technique page for the version you target before changing any coverage claim.

How do we measure detection quality for T1585 in a cyber range?

Measure whether the expected alert fired, how long it took, and whether the analyst could act on it. Build a small set of scripted scenarios in the private range, such as a lookalike domain registration or a cloned profile, and record the ground truth timestamp for each step. Score each run on detection, time to alert and the completeness of the fields the analyst needs. Repeat runs after every rule change to catch regressions. Keep the results as evidence, but present them as results from your range, not as a general measure of coverage in production.

How do we avoid alert fatigue from brand monitoring?

Route brand-monitoring findings into a separate queue with their own severity model, and only page on confirmed impersonation of executives, payment flows or customer-facing domains. Brand monitoring produces many low-confidence matches, so set thresholds on similarity, age of the registration and whether the content mimics your login or support pages. Add an enrichment step that checks whether the domain resolves, serves a certificate or appears in your own allow list. Review false positives weekly and tune on evidence. Agree with legal and communications who handles takedown requests before the first alert arrives.

Can our own team run this detection, or do we need outside help?

Your team can run it if it already operates a SIEM, handles threat intelligence and has time to maintain rules. The work breaks into a few parts: selecting and integrating the telemetry, writing and testing rules, building range scenarios, and running response playbooks. Each part can be done in house or scoped separately. DeployOpen plans, implements and supports self-hosted open-source platforms inside your own environment and runs security testing and private cyber ranges, but it does not issue audit reports or certifications. A fixed-scope engagement sets deliverables in writing before work starts, and ongoing tuning can be covered by a retainer.

Which telemetry should we confirm first for Network Traffic Content?

Confirm that your sensors can see the traffic you need to inspect, with the right retention and time synchronization. Network Traffic Content for T1585 usually comes from full packet or protocol-level metadata captured by Zeek or Suricata at egress and at the points where your users and services connect out. Check whether TLS content is visible or only metadata, because that changes which indicators you can match. Verify that your sensor logs reach the SIEM with consistent fields and that retention covers the lookback window your analysts need for investigations.

How DeployOpen builds T1585 detections and range exercises

DeployOpen approaches T1585 Establish accounts as a fixed-scope engagement inside the client's own environment, with detection logic written for the ATT&CK version the client targets. The work moves from a written scope to tested detections, documented handover and optional ongoing support.

How we scope

Agree in writing which T1585 sub-techniques and telemetry sources are in scope.
Confirm which data components and log sources the client can actually collect today.
Name the ATT&CK version the detections target, since releases can rename or deprecate techniques.

How we build

Map candidate analytics for account creation signals on open-source platforms such as Wazuh and Zeek.
Write Sigma-format rules describing the detection logic, then tune them against the client's baseline.
Test detections in a private cyber range before they reach the production monitoring stack.

How we hand over

Deliver rule documentation covering the data source, expected false positives and triage steps.
Provide a validation record showing which test scenarios fired each rule and which did not.
Run a walkthrough with the analysts who will operate the detections and the response runbook.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Ongoing support, rule updates and continuous testing are available as a retainer.
Ask for the retainer terms and review cadence in the written quote before engagement begins.

T1585 Establish accounts