---
{
  "title": "Internal Spearphishing",
  "summary": "Internal spearphishing sends deceptive messages through already-accessed internal accounts or systems.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1534"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1534: Internal Spearphishing",
      "url": "https://attack.mitre.org/techniques/T1534"
    }
  ],
  "editorialVersion": 2
}
---

## A familiar sender can still deliver deception

Internal spearphishing sends targeted deceptive messages through an account or system already accessed inside an organization. The apparent internal origin can make a request seem more credible and may bypass assumptions that suspicious messages always arrive from outside.

The technique does not mean the genuine account owner intended the message. Investigators should distinguish the account used to send it from the person controlling that account or device at the time. A real sender address is not proof that the business request is legitimate.

## A colleague requests an unusual sign-in

In a fictional academy, staff receive a message from a known coordinator asking them to open a new document portal. One recipient reports that the destination requests credentials unexpectedly. The responder preserves the message, destination information, and relevant sending and authentication records.

The coordinator may have shared a legitimate new service, or their account may be under unauthorized control. Contact them through a separate trusted channel and compare the message with approved work. Do not use the potentially compromised conversation as the sole verification route.

The team identifies recipients and reviews interaction evidence where available. Delivery, opening a message, following a link, submitting credentials, and executing content are distinct stages. Avoid declaring every recipient compromised solely because the message reached them.

## Investigate the sending access

Review account sessions, application grants, mailbox rules, device evidence, and other relevant access paths. The message may have been sent through a normal client, an API, or another compromised internal system. The available records determine which explanation can be supported.

[[phishing]] explains the deceptive request. [[valid-accounts]] describes genuine credentials under unauthorized control, while [[email-collection]] may be relevant if mailbox information helped tailor the message.

Preserve useful records promptly and handle recipient information appropriately. Broadly redistributing the malicious link in internal notices can create further exposure; communicate the identifying details safely.

## Contain and communicate

Restrict the abused access as justified, coordinate removal or warning actions with mail administrators, and support affected users without blame. Review whether recipients exposed credentials or created sessions that need separate recovery.

For practice, compare an approved internal announcement with a fictional message sent from a compromised colleague's account. Identify the business verification, sender-session, destination, and recipient-action evidence needed for a decision. Explain how the impact statement changes when only delivery is known versus confirmed credential submission. [[incident-response]] coordinates the case, and [[incident-reporting]] keeps the account owner and unauthorized actor distinct.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]
- [[input-capture]]