DET0111: Detect Unsecured Credentials Shared in Chat Messages
DET0111 is a detection strategy for finding unsecured credentials shared in chat or collaboration messages. Its business value is reducing the chance that...
Analyst context for executives and security teams
DET0111 is a detection strategy for finding unsecured credentials shared in chat or collaboration messages. Its business value is reducing the chance that passwords, API keys, or tokens exposed in internal communications become a shortcut to account takeover, cloud/SaaS access, or follow-on intrusion. Because the ATT&CK object has no official detection text, teams should treat this as a validation prompt: confirm which chat, office, and collaboration systems are in scope, what content or security telemetry is available, and how credential exposure is triaged and remediated.
Executive priority
Prioritize this as an identity and SaaS risk-control question: can the organization prove that credentials shared through collaboration tools are detected, removed, rotated, and investigated quickly? Leaders should ask whether monitoring is permitted by policy, aligned with privacy/compliance requirements, and backed by an incident process for token revocation and password/API key rotation. This matters for operational resilience because a single exposed secret in chat can undermine stronger perimeter or endpoint controls.
Technical view
This detection strategy relates to ATT&CK T1552.008, Chat Messages, under Credential Access, with related platforms SaaS and Office Suite. SOC, IAM, cloud security, and IR teams should validate coverage across corporate communication services such as chat, email, and collaboration platforms where users may share usernames/passwords, API keys, or authentication tokens. Since MITRE provides no official analytic logic for DET0111, detection engineering should be based on approved content inspection, DLP/security event logs, secret-pattern matching, and correlation with subsequent authentication or API activity.
Likely telemetry
- Chat and collaboration message audit logs where available
- Office suite and SaaS audit logs for message creation, edits, file attachments, and sharing activity
- DLP or content inspection alerts for passwords, API keys, tokens, and other secrets
- Security logs from collaboration tools such as access, export, admin, and retention events
- Identity provider authentication logs for accounts or tokens associated with exposed credentials
Detection direction
- Inventory which SaaS, office suite, chat, email, and collaboration services are approved for business communication and confirm they generate usable audit or DLP telemetry.
- Tune secret-detection patterns for common credential types while accounting for false positives such as examples, documentation, test strings, and redacted values.
- Correlate suspected exposed credentials with authentication, token use, API calls, or unusual access after the message timestamp to support triage without assuming compromise.
- Validate coverage for private channels, direct messages, file attachments, code snippets, pasted logs, and integrated collaboration tools, subject to legal, privacy, and retention constraints.
- Define severity based on credential type, privilege, environment, exposure scope, and whether the secret is still valid.
Mitigation priorities
- Establish policy and user guidance prohibiting credential sharing in chat and collaboration systems.
- Use approved secret-management and password-management workflows so users have a safe alternative to sending credentials in messages.
- Implement DLP or content inspection where legally and operationally appropriate for SaaS, office suite, and collaboration platforms.
- Create an IR runbook for exposed secrets: validate, remove or restrict access to the message, rotate passwords or API keys, revoke tokens, and review related access logs.
- Reduce impact through least privilege, short-lived credentials, MFA where applicable, and scoped API tokens.
Analyst notes and limits
The ATT&CK detection strategy object itself is sparse: it has no official description, no official detection logic, and no platforms or tactics directly specified. The practical context comes from its relationship to T1552.008 Chat Messages, which describes credentials stored or passed through user communication services including email, Slack/Teams-like chat, Jira/Trello-like collaboration tools, and other internal communications.
This take is based only on the supplied STIX fields, external reference, and relationship to T1552.008. It does not establish that any specific vendor tool, chat platform, or organization has coverage. Local privacy rules, retention settings, SaaS licensing, encryption, and audit-log availability will determine what can actually be detected and evidenced.
Detect Unsecured Credentials Shared in Chat Messages
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1552.008 | Chat Messages Sub-technique | This object detects Chat Messages. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | ff4014c17776… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0111Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.