Preparation
Archive Data
Boot Order Manipulation
CCTV Enumeration
Circumventing Security Controls
Data Obfuscation
Data Staging
Device Mounting
Email Collection
External Media Formatting
File Download
File Exploration
Impersonation
Increase Privileges
IT Ticketing System Exploration
Network Scanning
Physical Disk Removal
Physical Exploration
Physical Item Smuggling
Private / Incognito Browsing
Read Windows Registry
Remote Desktop (RDP)
Security Software Enumeration
Social Engineering (Outbound)
Software Installation
- Installing Browser Extensions
- Installing Browsers
- Installing Cloud Storage Applications
- Installing FTP Clients
- Installing Messenger Applications
- Installing Note-Taking Applications
- Installing RDP Clients
- Installing Screen Sharing Software
- Installing SSH Clients
- Installing Virtual Machines
- Installing VPN Applications
Software or Access Request
Suspicious Web Browsing
Testing Ability to Print
- ID: PR027.002
- Created: 07th May 2025
- Updated: 07th May 2025
- Contributor: The ITM Team
Impersonation via Collaboration and Communication Tools
The subject creates, modifies, or misuses digital identities within internal communication or collaboration environments—such as email, chat platforms (e.g., Slack, Microsoft Teams), or shared document spaces—to impersonate trusted individuals or roles. This tactic is used to gain access, issue instructions, extract sensitive data, or manipulate workflows under the guise of legitimacy.
Impersonation in this context can be achieved through:
- Lookalike email addresses (e.g., spoofed domains or typo squatting).
- Cloned display names in collaboration tools.
- Shared calendar invites or chats initiated under false authority.
- Use of compromised or unused accounts from real employees, contractors, or vendors.
The impersonation may be part of early-stage insider coordination, privilege escalation attempts, or subtle reconnaissance designed to map workflows, bypass controls, or test detection thresholds.
Example Scenarios:
- A subject registers a secondary internal email alias (
john.smyth@corp-secure.com
) closely resembling a senior executive and uses it to request financial data from junior employees. - A subject joins a sensitive Slack channel using a display name that mimics another department member and quietly monitors ongoing discussions related to mergers and acquisitions activity.
- A compromised service account is used by an insider to initiate SharePoint document shares with external parties, appearing as a legitimate internal action.
- The subject impersonates an IT support contact via Teams or email to socially engineer MFA tokens or password resets.
Prevention
ID | Name | Description |
---|---|---|
PV023 | Access Reviews | Routine reviews of user accounts and their associated privileges and permissions should be conducted to identify overly-permissive accounts, or accounts that are no longer required to be active. |
PV055 | Enforce Multi-Factor Authentication (MFA) | Multi-Factor Authentication (MFA) is a critical component of a comprehensive security strategy, providing an additional layer of defense by requiring more than just a password for system access. This multi-layered approach significantly reduces the risk of unauthorized access, especially in cases where an attacker has obtained or guessed a user’s credentials. MFA is particularly valuable in environments where attackers may have gained access to user credentials via phishing, data breaches, or social engineering.
For organizations, enabling MFA across all critical systems is essential. This includes systems such as Active Directory, VPNs, cloud platforms (e.g., AWS, Azure, Google Cloud), internal applications, and any resources that store sensitive data. MFA ensures that access control is not solely dependent on passwords, which are vulnerable to compromise. Systems that are protected by MFA require users to authenticate via at least two separate factors: something they know (e.g., a password), and something they have (e.g., a hardware token or a mobile device running an authenticator app).
The strength of MFA depends heavily on the factors chosen. Hardware-based authentication devices, such as FIDO2 or U2F security keys (e.g., YubiKey), offer a higher level of security because they are immune to phishing attacks. These keys use public-key cryptography, meaning that authentication tokens are never transmitted over the network, reducing the risk of interception. In contrast, software-based MFA solutions, like Google Authenticator or Microsoft Authenticator, generate one-time passcodes (OTPs) that are time-based and typically expire after a short window (e.g., 30 seconds). While software-based tokens offer a strong level of security, they can be vulnerable to device theft or compromise if not properly secured.
To maximize the effectiveness of MFA, organizations should integrate it with their Identity and Access Management (IAM) system. This ensures that MFA is uniformly enforced across all access points, including local and remote access, as well as access for third-party vendors or contractors. Through integration, organizations can enforce policies such as requiring MFA for privileged accounts (e.g., administrators), as these accounts represent high-value targets for attackers seeking to escalate privileges within the network.
It is equally important to implement adaptive authentication or risk-based MFA, where the system dynamically adjusts its security requirements based on factors such as user behavior, device trustworthiness, or geographic location. For example, if a subject logs in from an unusual location or device, the system can automatically prompt for an additional factor, further reducing the likelihood of unauthorized access.
Regular monitoring and auditing of MFA usage are also critical. Organizations should actively monitor for suspicious activity, such as failed authentication attempts or anomalous login patterns. Logs generated by the Authentication Service Providers (ASPs), such as those from Azure AD or Active Directory, should be reviewed regularly to identify signs of attempted MFA bypass, such as frequent failures or the use of backup codes. In addition, setting up alerts for any irregular MFA activity can provide immediate visibility into potential incidents.
Finally, when a subject no longer requires access, it is critical that MFA access is promptly revoked. This includes deactivating hardware security keys, unlinking software tokens, and ensuring that any backup codes or recovery methods are invalidated. Integration with the organization’s Lifecycle Management system is essential to automate the deactivation of MFA credentials during role changes or when an employee departs. |
PV022 | Internal Whistleblowing | Provide a process for all staff members to report concerning and/or suspicious behaviour to the organization's security team for review. An internal whistleblowing process should take into consideration the privacy of the reporter and the subject(s) of the report, with specific regard to safeguarding against reprisals against reporters. |
PV049 | Managerial Approval | The process for having software installed on a corporate endpoint by IT should require approval from the employee's line manager to ensure the request is legitimate and appropriate. |
PV048 | Privileged Access Management (PAM) | Privileged Access Management (PAM) is a critical security practice designed to control and monitor access to sensitive systems and data. By managing and securing accounts with elevated privileges, PAM helps reduce the risk of insider threats and unauthorized access to critical infrastructure.
Key Prevention Measures:
Benefits:
|
PV002 | Restrict Access to Administrative Privileges | The Principle of Least Privilege should be enforced, and period reviews of permissions conducted to ensure that accounts have the minimum level of access required to complete duties as per their role. |
Detection
ID | Name | Description |
---|---|---|
DT046 | Agent Capable of Endpoint Detection and Response | An agent capable of Endpoint Detection and Response (EDR) is a software agent installed on organization endpoints (such as laptops and servers) that (at a minimum) records the Operating System, application, and network activity on an endpoint.
Typically EDR operates in an agent/server model, where agents automatically send logs to a server, where the server correlates those logs based on a rule set. This rule set is then used to surface potential security-related events, that can then be analyzed.
An EDR agent typically also has some form of remote shell capability, where a user of the EDR platform can gain a remote shell session on a target endpoint, for incident response purposes. An EDR agent will typically have the ability to remotely isolate an endpoint, where all network activity is blocked on the target endpoint (other than the network activity required for the EDR platform to operate). |
DT045 | Agent Capable of User Activity Monitoring | An agent capable of User Activity Monitoring (UAM) is a software agent installed on organization endpoints (such as laptops); typically, User Activity Monitoring agents are only deployed on endpoints where a human user Is expected to conduct the activity.
The User Activity Monitoring agent will typically record Operating System, application, and network activity occurring on an endpoint, with a focus on activity that is or can be conducted by a human user. The purpose of this monitoring is to identify undesirable and/or malicious activity being conducted by a human user (in this context, an Insider Threat).
Typical User Activity Monitoring platforms operate in an agent/server model where activity logs are sent to a server for automatic correlation against a rule set. This rule set is used to surface activity that may represent Insider Threat related activity such as capturing screenshots, copying data, compressing files or installing risky software.
Other platforms providing related functionality are frequently referred to as User Behaviour Analytics (UBA) platforms. |
DT047 | Agent Capable of User Behaviour Analytics | An agent capable of User Behaviour Analytics (UBA) is a software agent installed on organizational endpoints (such as laptops). Typically, User Activity Monitoring agents are only deployed on endpoints where a human user is expected to conduct the activity.
The User Behaviour Analytics agent will typically record Operating System, application, and network activity occurring on an endpoint, focusing on activity that is or can be conducted by a human user. Typically, User Behaviour Analytics platforms operate in an agent/server model where activity logs are sent to a server for automatic analysis. In the case of User Behaviour Analytics, this analysis will typically be conducted against a baseline that has previously been established.
A User Behaviour Analytic platform will typically conduct a period of ‘baselining’ when the platform is first installed. This baselining period establishes the normal behavior parameters for an organization’s users, which are used to train a Machine Learning (ML) model. This ML model can then be later used to automatically identify activity that is predicted to be an anomaly, which is hoped to surface user behavior that is undesirable, risky, or malicious.
Other platforms providing related functionality are frequently referred to as User Activity Monitoring (UAM) platforms. |
DT011 | Cyber Deception, Honey User | In cyber deception, a "honey user" (or "honey account") is a decoy user account designed to detect and monitor malicious activities. These accounts attract attackers by appearing legitimate or using common account names, but any interaction with them is highly suspicious and flagged for investigation. Honey users can be deployed in various forms, such as Active Directory users, local system accounts, web application users, and cloud users. |
DT050 | Impossible Travel | Custom or pre-built detection logic can be used to determine if a user account has authenticated from two geographic locations in a period of time that is not feasible for legitimate travel between the locations. |
DT104 | Leaver Watchlist | In relevant security tooling (such as a SIEM or EDR), a watchlist (also known as a reference set) should be used to monitor for any activity generated by accounts belonging to employees who have left the organization, as this is unexpected. This can help to ensure that the security team readily detects any unrevoked access or account usage.
This process must be in partnership with the Human Resources team, which should inform the security team when an individual leaves the organization (during an Employee Off-Boarding Process, see PV024), including their full and user account names. Ideally, this process should be automated to prevent any gaps in monitoring between the information being sent and the security team adding the name(s) to the watchlist. All format variations should be considered as individual entries in the watchlist to ensure accounts using different naming conventions will generate alerts, such as john.smith, john smith, john.smith@company.com, and jsmith.
False positives could occur if there is a legitimate reason for interaction with the account(s), such as actions conducted by IT staff. |