Safeguard
Application Security•

Fake Accounts and Personas: Defending Against T1585

MITRE T1585 covers adversaries building fake personas and accounts for social engineering and infrastructure. Understand it and learn what to monitor.

Safeguard Security Team
6 min read

Establish Accounts (T1585) is a resource development technique with the PRE tag. It has three sub-techniques: Social Media Accounts, Email Accounts and Cloud Accounts.

Where Compromise Accounts takes over an existing identity, this technique builds a new one from scratch. The effort can be patient. A persona may need history, friends and a face before it is useful.

How attackers use it

MITRE says adversaries may create and cultivate accounts with services and use them to build a persona that supports operations. Persona development consists of public information, presence, history and appropriate affiliations. The material can be on social media, a website or other public sources that can be checked for legitimacy during an operation.

For operations that use social engineering, the persona may matter a great deal. Personas may be fictitious or impersonate real people. They may exist on one site or on many. MITRE names Facebook, LinkedIn, Twitter, Google, GitHub and Docker Hub as examples. Making a persona look real may need extra material: filled-in profile information, a social network, or photos.

Accounts can also serve other purposes:

  • Email accounts, which may be used directly for phishing for information or phishing.
  • Free services, such as trial periods, which may be abused to acquire infrastructure for malicious purposes.

The page covers the details in each sub-technique. In short: social media accounts build trust with targets, email accounts send the messages and acquire other resources, and cloud accounts supply storage and compute.

A key point for defenders is that the accounts are real accounts, on real services, created through normal sign-up. They do not break any rule until they are used.

How to detect it

MITRE's detection advice mixes network and social signals.

  • Consider monitoring social media activity related to your organization. Suspicious activity may include personas claiming to work for your organization, or recently created or modified accounts making numerous connection requests to accounts affiliated with your organization.
  • Monitor and analyze traffic patterns and packet inspection for protocols that do not follow expected standards and traffic flows, such as extraneous packets that do not belong to established flows, or anomalous syntax or structure.
  • Consider correlating with process monitoring and command lines to detect anomalous process execution and command line arguments tied to traffic patterns, for example files that do not normally initiate connections for the protocol in question.

The first bullet is the one most teams can act on. Someone claiming to work at your company who does not appear in your directory is a signal. So is a profile created last month that sent connection requests to your whole engineering team.

Practical ways to collect that signal, as general practice:

  • Ask staff to report odd connection requests and messages, and tell them where to send them.
  • Search professional networks regularly for your company name as an employer and compare against HR records.
  • Keep the report channel simple. A reply to a security mailbox is enough.
  • Track which reported accounts reappear. Persona accounts often target several people over time.

How to reduce the risk

MITRE lists one mitigation, Pre-compromise. It explains that the technique cannot be easily mitigated with preventive controls, since it is based on behavior outside enterprise defenses. You cannot stop someone from creating an account on a public service.

What you can change is how well your people and processes handle a stranger who looks credible. These are general practices.

  • Train staff to treat new, unsolicited connection requests and messages with care, especially when they ask for information about internal systems.
  • Establish verification steps for requests that come from a new contact, such as a call-back on a number you already hold.
  • Limit what employees reveal in public profiles about internal tools, project names and org structure.
  • Give employees a simple way to report suspected fake personas and make sure someone acts on the report.
  • For developer platforms, review new contributors and new accounts before giving them access to private projects.

For code hosting and package registries, fake accounts can also publish look-alike packages. An inventory of your dependencies, with the publisher visible, helps you spot a package from an unknown account. Safeguard offers a free in-browser dependency scan at https://gold.safeguard.sh/scan. No login is needed, the file never leaves your machine, and it handles up to 100 dependencies.

Teams often ask where to begin, since the technique lives outside the network. Start with three small habits.

First, make reporting easy. A staff member who gets a strange connection request should know the one address that takes the report, and should hear back. People stop reporting when nothing happens.

Second, agree on verification for new contacts. If someone you have never met asks about internal tools, or sends a file, confirm who they are through a channel you already trust before you reply. A call to a main switchboard number, or a message through the company directory, is enough.

Third, review who may join your private projects. Persona accounts on developer platforms ask to contribute or to join discussion. Requiring a sponsor for every new collaborator takes a minute and removes a path.

Record what you learn. When a fake persona is reported, keep the profile address, the photos and the text it used. Personas are reused across targets, and your record helps the next person who sees it.

Check your own environment

  • Search a professional network for your company as an employer. Does the list match your staff directory?
  • Is there a documented way for staff to report a suspicious contact? Does it reach a person?
  • Do you know which public profile fields reveal internal tools or reporting lines?
  • For code hosting: who can add collaborators to private repositories, and is it logged?
  • Linux or macOS, read-only: git log --format='%an <%ae>' | sort | uniq -c | sort -rn | head lists commit authors in a repository, which helps you spot an unfamiliar contributor.

Quick check

Why do adversaries invest time in personas?

For social engineering, a believable persona with history and connections builds trust with targets.

Which three sub-techniques make up T1585?

Social Media Accounts, Email Accounts and Cloud Accounts.

What social signal does MITRE suggest watching?

Personas claiming to work for your organization, and recently created or modified accounts making many connection requests to accounts affiliated with your organization.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.