Why T1534 internal spearphishing starts from a trusted sender
A message arrives from a colleague's mailbox or an internal system account. It references a shared project, a payroll cycle or a document review, and nothing about it looks unusual. For a SOC lead, the difficulty with T1534 Internal spearphishing is that the message may never cross the perimeter gateway at all, because it originates inside the organization. In MITRE ATT&CK, this technique sits under the Lateral Movement tactic (TA0008), where the adversary is trying to move through your environment. ATT&CK identifies technique pages with IDs of the form T####, and this page targets Enterprise ATT&CK 20.0, so detection mappings written for it should name that version explicitly.
T1534 usually appears after an attacker already has a foothold. A compromised endpoint, a stolen session or a valid mailbox credential gives the adversary a sender that recipients already trust. From there, the attacker uses that identity to reach other people, who are more likely to open attachments, follow links or approve requests. The technique is therefore a bridge between a single compromise and a wider spread, which is why it is often reviewed alongside credential and session techniques in the same pillar. Confirm with your own incident records how often internal messages followed an earlier endpoint or identity compromise in your environment, since that pattern is the strongest reason to monitor internal mail as closely as inbound mail.
The practical decision is where to look. Internal mail flow, mailbox rule changes, sign-ins to the sending account from unfamiliar hosts and outbound messages that break an account's normal recipient pattern all carry signal. Ask your mail platform and identity provider team which of these events they already retain, for how long, and whether they reach your SIEM. The gap between those answers and what this page recommends will shape the first detection work in your environment.
Which telemetry reveals internal spearphishing
This table maps each data component relevant to T1534 Internal Spearphishing to the signal it gives, the open-source collector that can supply it, and what to confirm in your own environment. Read each row as a source you need to collect before the detection can work. The main takeaway is that mail-platform audit logs carry much of the signal for Office Suite and SaaS, so they must be confirmed early.
| Data component | Signal for T1534 | Open-source collector | Confirm in your environment |
|---|---|---|---|
| Process Creation (DC0032) | Mail client or browser spawning unexpected child processes, such as script hosts or archive utilities, shortly after a user opens a message | Wazuh agents on Windows, Linux and macOS endpoints, or Velociraptor artifacts for on-demand collection | Whether endpoint process auditing is enabled on mail workstations and that command-line arguments are captured |
| Network Traffic Content (DC0085) | Internal mail or collaboration traffic carrying links or attachments that point to unfamiliar hosts or newly registered domains, sent from an internal account | Zeek for protocol logs and Suricata for signature and content matching on internal segments | Whether east-west mail traffic is visible to sensors, and whether TLS inspection or metadata-only capture applies |
| Logon Session Creation (DC0067) | A logon from a recently created or dormant account immediately before a burst of outbound internal messages from a different user | Wazuh collection of Windows security logs and Linux authentication logs | Whether logon events are forwarded centrally and whether account creation and dormancy data is available to correlate |
| Application Log Content (mail platform) | Message send events from an internal account with unusual sending patterns, new forwarding rules, or messages sent outside normal hours for that user | Mail-platform audit logs forwarded to Wazuh or a SIEM through the vendor's API or export feature | Which Office Suite or SaaS mail audit events are retained, for how long, and whether message-level metadata is included |
| Command Execution (DC0064) | Script interpreters launched from user profile paths following an internal message open, indicating a lure was executed | Velociraptor hunts for execution artifacts, paired with Wazuh command logging where supported | Whether command logging is enabled and whether the collector can run hunts on the affected endpoints without disrupting users |
Detection ideas for internal spearphishing on each platform
Internal spearphishing (T1534) lands in a mailbox that already trusts the sender, so the strongest signals come from what happens around the message: a sender account that behaves differently after a logon, mailbox configuration changes, link reputation, and what an opened attachment does next. Each idea below pairs the detection logic with thresholds to tune and the benign activity that will trigger it. Rules can be written in the Sigma format and tested against the ATT&CK version your team targets.
Sender behavior change after logon
Compare each internal sender's recent sending pattern with a baseline built over several weeks: message volume, recipient count, time of day and whether messages go to people the account has never contacted. Flag a sharp rise in new recipients within a short window after a new logon from an unfamiliar host or location. The logon is the trigger, not the message, so join Logon Session Creation events to mail audit logs. Tune thresholds per role, since finance and executive assistants legitimately send in bursts. Common false positives include shared mailboxes, scheduled mail merges, bulk notifications from ticketing tools and help desk staff resetting access for other users.
New inbox rules or forwarding
Alert when an internal account creates or changes an inbox rule that forwards, deletes or moves mail, especially when the change follows a sign-in from a new device or a password reset. Pair the rule creation with messages sent from that account in the same session, because a compromised sender often adds rules to hide replies. Check the rule's target: forwarding to external domains or to a folder that the user rarely opens is more suspicious than a personal sorting rule. Expect false positives from assistants managing delegated mailboxes, mail client migrations, and automation that files vendor invoices.
Internal messages with rare links
Inspect URLs in internal mail for domains registered recently or rarely seen in your environment. An internal sender should seldom link to a domain outside your known set, so a first-seen domain in a message from an internal address deserves review, particularly when it appears alongside a request to sign in or approve something. Use your secure email gateway or mail logs as the source and compare against a threat intelligence or domain age feed you control. Expect noise from newly launched SaaS tools, marketing links in newsletters sent internally, and document sharing services that create unique subdomains.
Office apps spawning unexpected children
On Windows, watch for document viewers and office applications launching command interpreters, script hosts or unsigned binaries from user profile folders. On macOS and Linux, look for office suites or PDF readers starting shells or network utilities. The parent-child relationship is the signal, so collect Process Creation events with parent image, command line and user context, and compare them against a list of known-good child processes for each application. Expect false positives from macros used for legitimate reporting, printer drivers, security software that scans attachments and updater processes.
Attachment opens followed by network calls
Correlate an attachment opened from an internal message with outbound network connections from the same host within a short window. Network Connection Creation records and DNS logs can show an endpoint reaching a previously unseen destination shortly after a document is opened. Tune the window and the destination allowlist to your environment, and exclude known update and collaboration endpoints. Validate the detection by confirming that the time between open and connection is captured consistently across Windows, macOS and Linux sensors. Expect false positives from cloud document editors, browser-based preview tools and endpoint agents phoning home.
How to validate the internal spearphishing detections
This sequence proves that the T1534 Internal Spearphishing detections fire on the telemetry they claim to use, in a private cyber range with an approved test mailbox. It produces a dated, versioned evidence record that shows what was tested, what passed, and how false positives are tracked over time.
Define the emulation scenario and goal
The detection owner and the cyber range lead agree on one scenario goal: an internal message sent from a test account to a test mailbox that asks a recipient to take an action, followed by a simulated follow-on step. The scope names the ATT&CK version under test (Enterprise ATT&CK 20.0), the target platforms (for example Linux, macOS, Office Suite and SaaS), and the approved test mailbox and accounts. Nothing outside the range is touched. The output is a signed scenario sheet that the team can point to later.
Map expected telemetry to each scenario step
For every step in the scenario, write down the telemetry that should appear and where it should land in the stack. Typical sources include Process Creation on endpoints, Network Traffic Content for message or web traffic where your sensors can see it, and Logon Session Creation when the scenario involves a new session. Note which data components the detection strategy references, and where a source is absent or partial in your environment. The output is an expected-telemetry matrix that the analyst can check against.
Set pass criteria before the run
Agree the pass criteria in writing before anyone runs the scenario. Pass criteria should state which alert or rule must fire, on which host or mailbox, within the time window the team defines, and whether the alert carries the fields needed for triage. Also state what counts as a partial pass, such as telemetry present but no alert. Writing these down first keeps the result honest. The output is a pass-criteria table reviewed by the detection owner.
Execute the emulation in the range
A trained operator runs the approved scenario inside the cyber range, following the scenario sheet and logging each step with a start and end time. The operator does not adjust the scenario mid-run to make a rule fire. A second person observes and records anything unexpected. The output is a timestamped run log that ties each action to the host, account and mailbox involved.
Record alerts and evidence
Collect the alert IDs, timestamps, rule name and rule version, the ATT&CK version (20.0), the telemetry sources that contributed, and screenshots or exports of the raw events. Store them in a single evidence folder with the scenario sheet and run log. Compare recorded results to the pass criteria and mark each step as passed, partial or missed. The output is a validation record that an internal reviewer or an external assessor can trace from scenario to alert.
Re-run after every rule change
Any change to the rule logic, thresholds, field mappings, log source configuration or ATT&CK mapping triggers a re-run of the affected steps. Record the new rule version and compare results with the previous run. If the ATT&CK version changes, check the technique and detection strategy references against the new release before re-running, because releases can rename or deprecate techniques. The output is a regression result that shows whether the change improved, degraded or left coverage unchanged.
Track false positive rates over time
Tune the detection against benign internal messaging and administrative activity from the same platforms, then log every alert that fires without a matching test action. Track the count, the cause, the rule version and the tuning change that followed. Review the trend at a cadence the owner sets, and confirm the review method with the SOC lead rather than assuming a standard figure. The output is a false positive register that links each noisy pattern to its fix and to the run that verified it.
How internal mail, identity and endpoint logs connect
A detection engineer for T1534 Internal spearphishing needs to join four kinds of evidence into one chain: the authenticated sender session, the message event in the mail or SaaS audit log, the endpoint process that opens the content, and any follow-on network connection. No single source proves the technique. A message from a compromised internal account looks like normal mail until the sender session, the delivery record and the endpoint activity are tied together by time, user identity and message identifier. Decide early which identifier carries across sources (user principal, mailbox ID, message ID or host name), because a chain that cannot be joined on one key will produce alerts that analysts cannot close.
The data components that ATT&CK most often references for Lateral Movement techniques are Process Creation (DC0032), Network Traffic Content (DC0085), Logon Session Creation (DC0067) and Network Connection Creation (DC0082). They map naturally to the links in this chain, but the reader should confirm which of these sources their platforms actually expose. Office Suite and SaaS audit logs vary in the message and sender fields they record, endpoint telemetry depends on the agent and operating system, and some network content is only visible at specific sensor points. Build a table of available fields per platform before writing any correlation rule. Where a field is missing, record that gap as a known limitation rather than assuming coverage.
ATT&CK v18, released October 28, 2025, replaced the detections in technique pages with detection strategies (DET IDs) and analytics, and made major updates to data components. Any mapping you write should name the ATT&CK version it targets, such as v20 for the STIX bundle used here, and record the DET and DC identifiers from that version. Re-check the mapping when a new release lands, since the ATT&CK updates page lists renames, deprecations and revocations that can change which data components a detection depends on.
Preventive controls that reduce internal spearphishing
Internal spearphishing succeeds when a compromised or careless internal account can send trusted mail and get a user to open a link or macro. The mitigations below reduce how far one account can reach and how much unsafe content users can run, so detection has less room to miss.
Privileged account management
Mail-enabled and administrative accounts are the most valuable senders for T1534 Internal spearphishing, because recipients trust mail that appears to come from IT or a manager. Limit who holds those roles, separate day-to-day mailboxes from admin identities, and review standing rights each quarter. Confirm which accounts can send to all staff or to distribution lists, since those are the ones an attacker would target first.
Audit of internal mail and admin actions
Audit (M1047) makes the internal mail trail usable for detection. Turn on logging for message sends, forwarding rule changes, and mailbox permission changes, and forward those events to your SIEM. Without these records, an internal phishing message looks like ordinary traffic, and analysts cannot reconstruct which account sent what to whom.
User account management
Account lifecycle controls decide how long a compromised internal identity stays useful. Disable dormant mailboxes, remove access for leavers and contractors promptly, and require re-approval for shared or service mailboxes. Check that disabled accounts also lose send rights and active sessions, since a stale account that still sends mail is a common gap.
Password policies and reset controls
Password Policies (M1027) limit how easily a mail account can be taken over and then used to send internal lures. Set length and reuse requirements that match your identity provider's guidance, and enforce multifactor authentication on mail and webmail access. Confirm that password resets for executive and shared mailboxes trigger an out-of-band check.
Network segmentation for mail and collaboration tiers
Network Segmentation (M1030) restricts which hosts can reach mail servers, collaboration platforms and user workstations directly. Place mail relays and their admin interfaces in separate zones, and limit workstation-to-workstation traffic. Segmentation does not stop a trusted mailbox from sending a lure, but it limits which systems a follow-on session can reach.
Disable or remove unsafe macro and link features
Disable or Remove Feature or Program (M1042) removes behavior that makes internal lures effective. Turn off automatic macro execution for documents received by mail, block or rewrite links that open unknown file types, and remove legacy scripting components that are not needed. Test each change with business users first, because macro-based workflows often break quietly.
What the SOC does when an internal spearphishing alert fires
The first decision when an internal spearphishing alert fires is whether the sending session is genuine, and the SOC analyst should not answer that question from the mailbox itself. A message from a colleague's account can originate from a stolen session, so the analyst asks the account owner to confirm the message through a separate channel such as a known phone number or an in-person check, never by replying to the suspicious thread. While that check runs, the mail administrator preserves the original message with headers, attachments and links, and the identity owner exports the sign-in and mailbox audit records for the sending account before any retention window or log rotation removes them. Confirm in your own environment which mailbox audit and sign-in logs are retained, for how long, and whether the export can be made without changing the record.
Next, the SOC analyst checks for changes that let an attacker keep control or hide activity: inbox rules that move, delete or forward mail, new forwarding addresses, added delegates, and newly registered mail or authentication methods on the sending account. Any of these changes raises the case from a single phishing message to an account compromise, and the incident commander should be told at that point. The analyst then scopes the campaign by searching for the same sender, subject, link or attachment hash across all recipient mailboxes, and by listing which recipients opened the content, clicked the link or entered credentials, based on the mail gateway and sign-in data available. Recipients who interacted with the content are the priority for a credential reset.
The identity owner resets credentials for the sending account and for any recipient whose sign-in or click evidence shows exposure, and revokes active sessions and tokens for those users. A reset is justified by evidence of interaction, not by the mere receipt of a message. Once access is contained, the SOC hunts for follow-on lateral movement from the sending and exposed accounts, looking at new sign-ins from unfamiliar hosts or networks, remote logons, and use of administrative tools in the hours after the first click. The incident commander closes the case only when the mail administrator confirms that the malicious items are removed, the identity owner confirms that sessions and rules are clean, and the findings are recorded for the next detection tuning cycle.
Rehearsing internal spearphishing detection in a private cyber range
The detection team needs a range that mirrors the mail and identity path an internal message takes, but that is isolated from production users and external mail flow. Build a segregated mail environment with its own domain, a small set of seeded test identities that map to roles similar to your finance, HR and IT helpdesk groups, and realistic but synthetic internal conversations so that message volume, reply chains and attachment types resemble normal traffic. The point is to test the telemetry pipeline itself, not the mail server's ability to block content. Illustrative scenario: a test account sends a request for a document review to a second test account, and the team checks whether the Process Creation, Network Traffic Content and Logon Session Creation records arrive in the Wazuh or Security Onion pipeline with the fields the detection logic depends on.
- Seeded identities: Create accounts with known owners, reporting lines and typical sending patterns so that analysts can judge whether a sender behaves out of character.
- Pipeline under test: Verify that endpoint, mail gateway and identity logs reach the SIEM with consistent timestamps, user names and host identifiers.
- Known-good baseline: Record normal internal message and link patterns before injecting anything, so false positives can be measured.
- Controlled injections: Place pre-approved test messages with links or attachments that the detection team scores, without using live malicious content.
- Mapping check: Confirm each detection maps to the ATT&CK version your team targets, since technique and data component names can change between releases.
Before the exercise, confirm with your mail and identity vendors which fields their logs expose, because not every platform records sender-side context the same way.
The response team rehearses triage and containment once an internal message is suspected. Injects are scripted events delivered during the exercise that force decisions. Illustrative inject one: a staff member reports a message from a colleague asking them to open a shared file outside normal workflow. Illustrative inject two: the colleague's mailbox shows signs of a compromised sender account, such as sign-ins from an unexpected location in the identity logs. Illustrative inject three: an inbox rule that forwards or hides messages appears in the mailbox during the exercise. Each inject should be timed so the team must decide what to preserve, who to notify and whether to suspend the account, and each should be logged with the time it was delivered.
- Reported message: Check whether the reporting channel, triage queue and ticket owner are clear, and whether the analyst asks for the original message with headers.
- Compromised sender: Test whether the team can revoke sessions, reset credentials and review recent sign-ins without disrupting the wider test environment.
- Inbox rule discovery: Confirm that analysts know how to list, review and remove rules, and how to check whether forwarding affected other recipients.
- Communication: Rehearse who informs the business owner, the legal contact and the help desk, and what the approved message to staff says.
- Evidence handling: Require the team to export mailbox audit entries and preserve messages before any cleanup.
Confirm your incident response runbook and mail platform audit retention with the platform owner before scheduling injects.
Good detection in the range means the team raises an alert or ticket that identifies the sender, recipient, time and the reason the message stood out, and does so within the response window your organization has agreed. Good response means containment decisions follow the runbook, evidence is preserved before changes are made, and affected users receive clear guidance. Teams should not judge success only by whether an alert fired. A noisy alert that analysts close without investigation is a finding, as is a missed inject that the detection logic should have caught. Scoring should reflect both the technical outcome and the quality of the handoffs between detection and response.
- Detection quality: The alert identifies the internal sender, the suspicious action and the supporting telemetry, and does not depend on a single field.
- Triage speed: Analysts classify the event against the runbook and state their confidence and open questions.
- Containment accuracy: The team limits actions to the affected account and avoids disrupting unrelated mailboxes.
- Communication clarity: Staff messages are accurate, short and free of technical detail that could help a real attacker.
- False positive control: Benign internal test traffic is labeled and tuned so the next exercise measures new gaps.
Ask whether each scored behavior can be repeated in a later exercise, so improvements can be measured against the same scenario.
The after-action review turns the exercise into durable improvements. Record what was injected, when, what each team observed, what they did and what the logs show. Keep the record in a form that can be compared across rehearsals, using the same scenario identifiers and ATT&CK version reference each time. Separate detection findings, such as missing fields or delayed ingestion, from response findings, such as unclear ownership or delayed revocation. Each finding should have an owner and a retest step. Store the timeline and log extracts with the exercise artifacts so auditors and internal reviewers can see how the controls were tested.
- Inject timeline: Log each inject's delivery time, the first observed signal and the first human action.
- Telemetry evidence: Keep the log excerpts that prove whether the pipeline delivered the expected records.
- Decision log: Note who decided to suspend an account, reset credentials or notify staff, and the reasoning given.
- Gap register: List each missed detection, unclear step or tooling issue with severity, owner and target retest.
- Retest plan: Schedule the same inject set after fixes so improvement is measured, not assumed.
Agree with your compliance and audit contacts which exercise records they need to retain, and confirm the retention period with them rather than assuming one.
Questions SOC leads ask about detecting T1534
How do I separate internal spearphishing from ordinary internal file sharing?
The separation rests on intent signals, not on the fact that a message came from inside the company. Ordinary file sharing usually comes from known collaborators, uses expected sharing links, and fits the sender's normal patterns, while internal spearphishing tends to show a sender account that behaves unusually, a message that asks for credentials, an authentication step, or a link to an unfamiliar destination. Start by baselining who normally sends internal links and attachments, then score deviations such as first-time sender-recipient pairs, lookalike display names, reply-chain hijacking, or links that resolve outside expected domains. Treat the score as a triage aid, and confirm each case with the recipient and the account owner before closing it.
Which logs do I need from Microsoft 365 or Google Workspace mail?
You need mail flow and message trace records, sign-in and authentication logs, mailbox audit records, and URL or attachment verdicts from your mail security layer. Mailbox audit events show rule creation, forwarding changes, and message access, which are often the first sign that a message was used after delivery. Confirm with your tenant administrator which log categories are licensed and retained in your subscription, how long they are kept, and whether they are forwarded to your SIEM, such as Wazuh or Security Onion, through an API connector. Field names differ between Microsoft 365 and Google Workspace, so map each source to the ATT&CK data components you target before writing rules.
Can Sigma rules express internal spearphishing logic?
Sigma can express parts of the logic, mainly the event conditions that are stable across log sources, such as a mail rule that forwards to an external domain or a sign-in that follows an unusual message action. Sigma is less suited to baseline comparisons, first-seen relationships, and reply-chain analysis, which usually need a SIEM correlation or an analytic that keeps state. Write the Sigma rule for the single-event signal, then add a correlation or enrichment step in your SIEM for the context. Keep a note of which logsource fields the rule depends on, because a rule that works for one mail platform may need a separate version for another.
How should I handle shared mailboxes in detection logic?
Shared mailboxes break assumptions that per-user baselines rely on, because many people send from the same identity and the sender profile looks noisy. Build a separate baseline for each shared mailbox, keyed on the mailbox identifier, and record which human users are delegated to act on it. Alert on changes to delegation, new forwarding rules, and sign-ins from new locations on the shared identity, since those are the actions that matter most. Review the list of delegates with the mailbox owner each quarter, and document the owner so triage has a named contact.
How do I know which ATT&CK version a detection rule maps to?
Record the ATT&CK version in the rule metadata and in your detection inventory, because technique names, IDs, and detection guidance can change between releases. MITRE publishes each release on its updates pages, and the content is available as STIX 2.1 bundles in the attack-stix-data repository, so you can check the exact technique and data component definitions for the version you target. The current release notes list changes such as deprecations and revocations, which should trigger a review of affected rules. Note that v18 replaced detections in technique pages with detection strategies, so older rule mappings may point to content that no longer exists in that form.
How often should I re-run validation for internal spearphishing detections?
Re-run validation whenever a detection changes, when your mail platform or its log schema changes, and when MITRE publishes a new ATT&CK version that affects the technique or its data components. Many teams also schedule a recurring test on a fixed calendar cycle, so that silent log pipeline failures are caught before a real incident. Confirm the cadence with your security governance owner and record each run with its date, ATT&CK version, and results. Use a private cyber range to run the tests, so that the simulated messages never reach production users.
What should my team confirm before buying or building these detections?
Confirm the log sources you already collect, the retention period for each one, and whether your SIEM receives mail and identity events in near real time. Ask who owns the detection content, who maintains it after a platform upgrade, and who approves changes. For a quote from any implementation partner, ask for the fixed scope in writing, the list of log sources covered, the ATT&CK version targeted, and the validation method and evidence delivered. Clarify which parts are one-time work, such as the initial pipeline and rule set, and which recur, such as tuning, validation runs, and updates after ATT&CK releases.
Primary sources for T1534 and ATT&CK detection mapping
Before you write or deploy any detection for T1534 Internal spearphishing, confirm the technique text and its mappings against the primary sources. Start with the MITRE ATT&CK tactic page for TA0008: Lateral Movement, which defines the tactic that T1534 sits under. Lateral Movement is described as the adversary trying to move through your environment, and that framing is the test for whether a detection belongs in your lateral movement coverage at all. Record the tactic version you are working against, because a detection mapped to one ATT&CK release may need review after the next one.
Next, check the version history on the ATT&CK updates page. Releases can rename, deprecate or revoke techniques and sub-techniques, and the current release notes show whether the T1534 text, its detection strategies or its data component references have changed since your last review. The pillar facts supplied for this page name the Enterprise ATT&CK 20.0 release as the target version. Confirm that the version your SIEM content, Sigma rules and Wazuh decoders reference matches the version you intend to report against.
For mapping checks, use the enterprise-attack 20.0 STIX bundle in the attack-stix-data repository. Search the bundle for the T1534 technique object, then compare its listed tactics, data components and mitigations with the detection rules in your repository. Your rule metadata should name the ATT&CK version, the technique ID and the data sources each rule depends on, so an auditor or detection engineer can trace each rule to the bundle. Confirm the current technique text on the live ATT&CK site before you deploy rules, since the live site is the reference your stakeholders will read.
How DeployOpen builds T1534 detections and range exercises
DeployOpen works on T1534 Internal spearphishing as a fixed-scope piece of work inside your own environment, starting from the telemetry you already collect. The output is a detection set, a validation plan and a cyber range exercise that your own team can run and maintain.
How we scope
- Confirm which platforms in scope, such as Linux, macOS, Office Suite and SaaS, have log sources available for T1534 Internal spearphishing.
- Record the ATT&CK version the detections target, with its data components and mitigations, in the written scope.
- Agree in writing which telemetry sources, such as Process Creation and Network Traffic Content, are in and out of the engagement.
How we build
- Map each T1534 detection strategy to Wazuh, Security Onion, Suricata, Zeek or Sigma logic your team already operates.
- Test log parsing and field normalization so detections fire on the telemetry you actually collect, not on assumed fields.
- Document tuning decisions, known false positives and the owner of each rule so changes stay traceable.
How we hand over
- Deliver the detection rules, validation steps and range exercise scripts in your repositories with a written runbook.
- Walk your security engineers through how each T1534 alert is triaged, escalated and closed, using the documented procedure.
- Provide evidence of the validation runs, such as the detections fired and the gaps found, for your compliance and audit files.
How we support
- Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
- Review T1534 detections when a new ATT&CK version changes techniques, data components or mitigations, and confirm the impact in writing.
- Ask for a quote based on the written scope, including the number of platforms, log sources and range exercises you want.
