Once an attacker can read a mailbox or a chat tenant, every payment instruction, password reset request and incident discussion carried on that system can be watched, forged or used against you. MITRE ATT&CK added Out-of-Band Communications Channel as mitigation M1060 in 2024 and relates it to seven techniques and sub-techniques in ATT&CK v20: Email Collection and its three sub-techniques, Data from Information Repositories and its Messaging Applications sub-technique, and Service Stop. This guide reads M1060 as a control with two jobs: verifying high-risk requests on a channel the attacker does not control, and keeping security and response communications away from systems that may be compromised. It is for security operations, incident response, finance control and identity teams. The design of a full incident response out-of-band environment is covered in the Out-of-Band Communications for Incident Response Guide and is not repeated here.
Key takeaways
- Two controls under one ID. ATT&CK uses M1060 both for out-of-band verification of actions requested by email and for separate channels for incident communications; plan, own and test them separately.
- It reduces impact, not access. M1060 does not stop an attacker reading mail or chat; it limits what that access is worth by moving high-value decisions and conversations elsewhere.
- Verification must use known contact data. A callback to a number taken from the suspicious message, or a chat with the same compromised account, is not out of band.
- Independence is about identity. A second channel that signs in through the same compromised identity provider gives an attacker the same view.
- Measure use, not existence. The useful metrics are the share of payment and access changes verified out of band and the time to stand up the incident channel in a drill.
What M1060 is in ATT&CK
ATT&CK describes M1060 as establishing secure out-of-band channels to keep critical communications running during security incidents, data integrity attacks or in-network communication failures, using a separate path that does not depend on the potentially compromised primary network. Examples it gives are secure messaging apps, encrypted phone lines, satellite communications and dedicated emergency communication systems. The mitigation page shows version 1.0, created 30 August 2024 and last modified 12 October 2024, and cites NIST SP 800-53 Rev 5, where the matching control is SC-37 Out-of-band Channels.
In practice the ATT&CK usage text describes three distinct uses:
| Use | What ATT&CK says | Typical owner |
|---|---|---|
| Out-of-band verification | Verify critical actions initiated by email, such as password resets, financial transactions or access requests, using secure out-of-band methods | Finance controls, service desk, identity team |
| Out-of-band alerting | Send alerts about unusual email activity, such as mass forwarding or large attachments, to the security team over a separate channel | Security operations |
| Out-of-band incident communications | Plan and use a secure channel instead of in-network chat and email during an incident, enforced by policy | Incident response lead, CISO |
D3FEND's ATT&CK mitigation mapping file has no entry for M1060, so there is no official D3FEND countermeasure mapping to cite. See the MITRE D3FEND Guide for how the two frameworks relate.
Techniques ATT&CK says M1060 mitigates
| Technique | Tactic | How M1060 helps, per ATT&CK | Priority (NHI Mgmt Group view) |
|---|---|---|---|
| T1114 Email Collection | Collection | Verify email-initiated critical actions out of band; send highly sensitive information over other channels instead of relying only on email | High: underpins business email compromise |
| T1114.002 Remote Email Collection | Collection | As T1114, plus out-of-band alerts on unusual activity and alternate channels if the mail server is compromised | High: cloud mailbox takeover is the common case |
| T1114.003 Email Forwarding Rule | Collection | As T1114.002, with a focus on spotting suspicious forwarding | High: rules persist after password resets |
| T1114.001 Local Email Collection | Collection | Out-of-band alerts to the security team about unusual local email activity such as mass forwarding or large attachments | Medium |
| T1213 Data from Information Repositories | Collection | Plan to use an out-of-band channel rather than in-network chat during an incident | Medium |
| T1213.005 Messaging Applications | Collection | Provide a secure out-of-band alternative to in-network chat during an incident | High during active response |
| T1489 Service Stop | Impact | Policy requiring out-of-band channels for critical communications during an incident | Medium: continuity when mail or chat services are stopped |
All seven relationships sit in Collection and Impact. M1060 is therefore a consequence control: it assumes the adversary already has access to communication systems and denies them the decisions and intelligence those systems carry. For the wider collection picture, see the ATT&CK Collection Tactic Guide.
Out-of-band verification against business email compromise
Business email compromise is where M1060 pays for itself. The FBI's Internet Crime Complaint Center (IC3) public service announcement of 11 September 2024 reported 305,033 domestic and international incidents with an exposed loss of about $55.5 billion between October 2013 and December 2023, and advises using secondary channels or two-factor authentication to verify requests for changes in account information. The UK NCSC's guidance on business email compromise similarly recommends confirming significant email requests by a different method, such as a phone call, logging into the account directly, or written or in-person confirmation.
NHI Mgmt Group recommends defining a short list of request types that always require out-of-band verification, with the rule that contact details come from a system of record, never from the request.
| Request arriving by email or chat | Out-of-band check | Contact source |
|---|---|---|
| Change of supplier bank details | Call back the supplier and require a second approver | Supplier master data recorded at onboarding |
| Urgent payment from an executive | Direct call or in-person confirmation with the executive | Corporate directory, not the email signature |
| Password or MFA reset | Identity proofing per service desk policy, callback to the registered number | HR or identity system of record |
| Privileged access or new admin role | Approval by the asset owner through a separate workflow | Access governance system |
| Issue of an API key, token or service account credential | Confirm the requester and owner through the ticketing or identity workflow | NHI inventory owner field |
| Payroll or direct deposit change | Confirm through the employee self-service portal or a callback | HR record |
The MGM Resorts breach shows the access-request side of this. By the attackers' own account, a phone call to the IT help desk impersonating an employee found on LinkedIn led to a credential reset and, later, administrator access to the Okta and Azure tenants. The lesson is the same as for payments: the verification step must use information the attacker cannot obtain or control. See the Account Recovery and Help Desk Security Guide and the Business Email Compromise Awareness for Finance Teams Guide.
Out-of-band channels for detection and response
The second job is keeping defenders' own communications away from the attacker. In the Microsoft Midnight Blizzard breach, the actor used an OAuth application with the Exchange Online full_access_as_app role to read mailboxes of senior leaders and cybersecurity and legal staff, and initially searched for information about Midnight Blizzard itself. A response coordinated over that same mail system would have been visible to the intruder.
- Preparation: CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks (November 2021) recommend, in the preparation phase, infrastructure for out-of-band communications, a defined method for out-of-band coordination, and managing sensors and security devices by out-of-band means; its OPSEC guidance prefers notifying users of compromised systems by phone rather than email.
- Alert routing: route high-severity mailbox alerts (new external forwarding rules, mass mailbox access by an application, new inbox rules on executive mailboxes) to an on-call path that does not depend on the corporate mail or chat tenant.
- Activation triggers: define the conditions that move the response off corporate systems, for example confirmed compromise of the identity provider, of an administrator account, or of the mail or chat tenant.
- Continuity: when T1489 Service Stop takes down mail or chat, the same channel keeps leadership, legal and responders connected.
Channel selection, pre-enrolment and drills are covered in the Out-of-Band Communications for Incident Response Guide.
Where identity fits
An out-of-band channel is only independent if its identities are. NHI Mgmt Group recommends three checks. First, the incident channel should not federate with the corporate identity provider, and its accounts should be enrolled in advance with phishing-resistant MFA. Second, alerting integrations that post into the out-of-band channel use their own webhook URLs or API tokens: store them in a secrets manager, scope them to posting only, and rotate them after any incident in which the security tooling may have been exposed. Third, treat requests to create or re-credential service accounts, OAuth applications and API keys as high-risk actions that need out-of-band confirmation, because a forged request for a machine credential gives durable access that survives user password resets. See the Email Identity and BEC Guide.
Implementing M1060
- Define the verification list. Agree with finance, HR and the service desk the request types that always need out-of-band confirmation, and the system of record for contact details.
- Write it into procedure and tooling. Add a mandatory verification field (who was called, on which number, when) to payment change and access request workflows so the step is evidenced, not remembered.
- Stand up the incident channel. Choose a channel independent of corporate identity and devices, pre-enrol responders, executives and legal, and store contact lists offline.
- Route critical alerts. Send high-severity email and identity alerts to the on-call path through the out-of-band channel as well as the SIEM.
- Pilot and test. Run a tabletop with a simulated mailbox compromise, then a live drill that activates the channel. Test the verification procedure with simulated payment change requests.
- Rollback and fallback. Keep a documented fallback (phone tree with personal numbers held offline) if the primary out-of-band tool fails, and record when the incident team returns to corporate channels after eradication.
What M1060 does not stop
- Initial mailbox access. It does not prevent phishing, token theft or OAuth consent abuse; those need M1032 Multi-factor Authentication, M1018 User Account Management and M1047 Audit.
- Data already in the mailbox. Messages that already contain secrets or sensitive data are exposed regardless; see M1057 Data Loss Prevention and M1041 Encrypt Sensitive Information.
- Compromised out-of-band endpoints. If responders use a compromised device, the separate channel inherits that compromise.
- Social engineering of the callback. Voice impersonation can defeat a callback that relies on recognising a voice rather than calling a recorded number.
- Forwarding rules themselves. M1060 helps detect and route alerts about T1114.003, but blocking external forwarding is a tenant configuration task; see M1054 Software Configuration.
Verifying it works and measuring it
| Metric | How to collect | Signal |
|---|---|---|
| Share of bank detail and payment changes with evidenced out-of-band verification | Sample from the payment change workflow | Close to 100% |
| Share of resets and privileged access grants verified through a recorded contact | Service desk and access governance records | Close to 100% |
| Time to activate the incident channel with all named roles present | Quarterly drill | Down, and stable |
| Enrolled members whose access works in the drill | Roll call during drill | All core roles |
| Critical mailbox alerts delivered through the out-of-band path | Alert pipeline logs | All high-severity alerts |
| Simulated payment change requests correctly verified | Finance verification exercises | Up over time |
Common failure patterns
- Calling the number in the email. The callback reaches the attacker, so the check adds confidence rather than security.
- A second channel on the same identity provider. A "separate" chat workspace with single sign-on through the compromised tenant is visible to the same intruder.
- Channel exists, nobody enrolled. During the incident, executives cannot sign in and the team falls back to corporate email.
- Verification by exception. Urgent requests from senior staff skip the procedure, which is exactly the pressure business email compromise relies on.
- Response discussed in the compromised mailbox. As the Midnight Blizzard case shows, attackers look for what defenders are saying about them.
Framework mapping
| Framework | Reference | Relevance to M1060 |
|---|---|---|
| MITRE ATT&CK v20 | M1060; TA0009 Collection; TA0040 Impact | Technique relationships listed above |
| NIST SP 800-53 Rev 5 | SC-37 Out-of-band Channels; SC-37(1) Ensure Delivery and Transmission; IR-4 Incident Handling; CP-8 Telecommunications Services | Separate channels, response coordination, alternative telecommunications |
| NIST CSF 2.0 | RS.CO-02, RS.CO-03 | Notifying stakeholders and sharing information during incidents |
| CIS Controls v8.1 | Control 17 Incident Response Management | Contact information and communication plans for incidents |
| ISO/IEC 27001:2022 Annex A | A.5.24 Information security incident management planning and preparation | Communication procedures for incidents |
See the ATT&CK Mitigations overview for how M1060 fits with the other 43 enterprise mitigations.
Practitioner checklist
- Publish the list of request types that always require out-of-band verification.
- Take all callback numbers from a system of record and evidence each check in the workflow.
- Require a second approver for supplier bank detail changes.
- Treat requests for machine credentials and new OAuth applications as verification-required.
- Stand up an incident channel that does not federate with the corporate identity provider.
- Pre-enrol responders, executives and legal, with offline contact lists.
- Route high-severity mailbox and identity alerts through the out-of-band path.
- Define activation triggers and the return-to-normal decision.
- Drill activation quarterly and test finance verification with simulated requests.
Standards and references
- MITRE ATT&CK: Out-of-Band Communications Channel (M1060)
- MITRE ATT&CK: Email Collection (T1114)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-37)
- NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
- CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
- FBI IC3: Public Service Announcement I-091124-PSA on Business Email Compromise
- NCSC: Business Email Compromise: Dealing with Targeted Phishing Emails
Related NHI Mgmt Group resources: Out-of-Band Communications for Incident Response Guide, Business Email Compromise Response Playbook, Email Identity and BEC Guide, ATT&CK Mitigations.