Remote Access Tool (RAT) Deployment

By only allowing pre-approved software to be installed and run on corporate devices, the subject is unable to install software themselves.

An anti-virus solution detect and alert on malicious files, including the ability to take autonomous actions such as quarantining or deleting the flagged file.

Network Intrusion Prevention Systems (NIPs) can alert on abnormal, suspicious, or malicious patterns of network behavior, and take autonomous actions to stop the behavior, such as resetting a network connection.

Only allow necessary protocols to communicate over the network. Implement strict access controls to prevent unauthorized protocols from being used. Typically these controls would be implemented on next-generation firewalls with Deep Packet Inspection (DPI) and other network security appliances.

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.

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).

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.

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.

By using files with canary tokens as tripwires, investigators can create an early warning system for potential collection activities before a data exfiltration infringement occurs.

By strategically placing these files on endpoints, network shares, FTP servers, and collaboration platforms such as SharePoint or OneDrive, the canaries monitor for access and automatically trigger an alert if an action is detected.

Service Principal Names (SPNs) are unique identifiers used by the Kerberos authentication protocol to associate a service instance with a specific account in Active Directory. In the Kerberos authentication process, a client—which could be any user, computer, or service—requests access to a particular service, such as email, file shares, or database servers. To authenticate and gain access to that service, the client must obtain a service ticket from the Ticket Granting Service (TGS).

The client first requests a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC), which is part of the Kerberos infrastructure. Once the client has a TGT, it can use it to request a service ticket from the TGS for a specific service identified by its SPN. The service ticket contains the hashed credentials of the service account associated with that SPN, allowing the client to authenticate to the service securely.

In a Kerberoasting attack, an adversary—who is often a domain-joined user—requests service tickets for service accounts with weak or guessable passwords. These tickets can then be captured and cracked offline to reveal the service account’s password. This process is typically initiated by an attacker who targets SPNs associated with high-privilege accounts.

A Honey SPN is a decoy SPN created with no legitimate use, designed specifically to attract malicious actors. By monitoring for TGS requests for these fake SPNs, defenders can detect when attackers are probing for service tickets associated with non-existent or intentionally misleading accounts. These unauthorized requests serve as an early detection mechanism, allowing defenders to identify enumeration attempts and potential attack activities before credential abuse occurs.

Event ID: 4769 – Kerberos Service Ticket Request (Security Log)
This event is logged whenever a client requests a service ticket from the TGS. It provides details of the SPN being requested, allowing defenders to track requests for honey SPNs and identify potential Kerberoasting activity.

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.

A honeypot is a decoy system that mimics a legitimate system or service, enticing a malicious actor to interact with it. It records any interaction for later review.

A Data Loss Prevention (DLP) solution refers to policies, technologies, and controls that prevent the accidental and/or deliberate loss, misuse, or theft of data by members of an organization. Typically, DLP technology would take the form of a software agent installed on organization endpoints (such as laptops and servers).

Typical DLP technology will alert on the potential loss of data, or activity which might indicate the potential for data loss. A DLP technology may also provide automated responses to prevent data loss on a device.

Implement Deep Packet Inspection (DPI) tools to inspect the content of network packets beyond the header information. DPI can identify unusual patterns and hidden data within legitimate protocols. DPI can be conducted with a range of software and hardware solutions, such as Unified Threat Management (UTM) and Next-Generation Firewalls (NGFWs), as well as Intrusion Detection and Prevention Systems (IDPS) such as Snort and Suricata, 

Monitor DNS queries and outbound HTTP/S traffic to known domains associated with browser-based remote access services. These platforms—such as LogMeIn, AnyDesk, Chrome Remote Desktop, and Microsoft RD Web Access—allow subjects to initiate or maintain remote sessions outside of approved IT infrastructure. Their use may indicate preparation for unauthorized remote access, data exfiltration, or external collaboration.

Detection Methods:

• Collect and analyze DNS logs and web proxy traffic across all egress points.
• Maintain and regularly update a threat intelligence list of domains and subdomains linked to web-based remote desktop platforms.
   

Example domains and subdomains include:

• logmein.com
• remotedesktop.google.com
• anydesk.com
• rdweb.wvd.microsoft.com
• teamviewer.com
• parsec.app
• splashtop.com

Configure alerting for:

• First-time access to any listed domain by a user or endpoint.
• Repeated access over time, suggesting potential session establishment.
• Access outside approved VPN channels or corporate IP ranges.
• DNS tunneling or large data transfers over HTTPS to these platforms.

Integrate results with identity sources to correlate web access with role-based access expectations.

Logging DNS requests made by corporate devices can assist with identifying what web resources a system has attempted to or successfully accessed.

Monitor outbound DNS traffic for unusual or suspicious queries that may indicate DNS tunneling. DNS monitoring entails observing and analyzing Domain Name System (DNS) queries and responses to identify abnormal or malicious activities. This can be achieved using various security platforms and network appliances, including Network Intrusion Detection Systems (NIDS), specialized DNS services, and Security Information and Event Management (SIEM) systems that process DNS logs.

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.

Analyze network flow data (NetFlow) to identify unusual communication patterns and potential tunneling activities. Flow data offers insights into the volume, direction, and nature of traffic.

NetFlow, a protocol developed by Cisco, captures and records metadata about network flows—such as source and destination IP addresses, ports, and the amount of data transferred.

Various network appliances support NetFlow, including Next-Generation Firewalls (NGFWs), network routers and switches, and dedicated NetFlow collectors.

Network Intrusion Detection Systems (NIDS) can alert on abnormal, suspicious, or malicious patterns of network behavior. 

Detailed PowerShell logging is not enabled by default and must be configured.

PowerShell is able to record the processing of commands, script blocks, functions, and scripts whether invoked interactively, or through automation.

PowerShell logging can be enabled through Group Policy with the following: Administrative Templates → Windows Components → Windows PowerShell

There are 3 available logging types, they are: Module Logging, Script Block Logging and Transcription.

Module Logging: Records pipeline execution details, such as variable initialisation and command invocations, capturing portions of scripts and some de-obfuscated code. This logging is available since PowerShell 3.0 and generates a large volume of events, providing valuable output not captured elsewhere. Events are written to Event ID 4103.

Module logging can be enabled by setting the following registry values:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ModuleLogging \ModuleNames → * = *

Script Block Logging: Captures blocks of code as they are executed, including de-obfuscated code, allowing visibility into the full contents of executed scripts and commands. This feature is available in PowerShell 5.0 and records events under Event ID 4104.

Script block logging can be enabled by setting the following registry values:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1

Transcription: Records the input and output of entire PowerShell sessions, providing a comprehensive record of all commands executed and their results.

Transcription logging can be enabled by setting the following registry values:

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableTranscripting = 1

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → EnableInvocationHeader = 1

HKLM\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\PowerShell\Transcription → OutputDirectory = “” (Enter path. Empty = default)

Monitor and alert when users are added to the local Remote Desktop Users group on Windows systems. Unauthorized additions to this group provide remote logon privileges and may indicate preparatory insider activity.

Detection Methods

• Audit group membership changes using Windows Security Event ID 4732.
• Track additions to the Remote Desktop Users group (SID: S-1-5-32-555).
• Correlate membership changes with user identity, prior privilege levels, and change management records.

Indicators

• Unauthorized or unexpected users added to the Remote Desktop Users group.
• Membership changes performed outside approved IT operations or helpdesk interventions.
• Additions correlated with accounts flagged for prior policy violations or behavioral risk indicators.

This detection is not enabled by default and requires additional configuration.

System Monitor (Sysmon) Event ID 1 is used to record process execution. Reviewing these logs can determine what software has been run on a system.

Monitor and alert when the SystemPropertiesRemote.exe binary is executed, particularly by non-administrative users or accounts without prior history of remote access configuration. This executable launches the Remote tab within System Properties, a primary interface for enabling Remote Desktop or Remote Assistance.

Detection Methods

• Enable process creation auditing (Windows Event ID 4688) to capture execution events.
• Deploy EDR or SIEM rules to specifically alert on SystemPropertiesRemote.exe launches.
• Flag executions by users outside of IT, system administration, or authorized privileged groups.
• Correlate execution events with time-of-day, user role, and subsequent system configuration changes.

Indicators

• Execution of SystemPropertiesRemote.exe by non-privileged users.
• Executions occurring outside standard business hours or approved change windows.
• Execution activity associated with further remote access configuration changes or registry modifications.

When Remote Desktop is used to create a connection to a remote machine, it creates entries in the Windows registry that persist after the session has ended. These registry entries can be used in an investigation to provide insight into what remote system(s) a user account has connected to.

Registry keys are created under the Servers key for each remote system that has been connected to, with the name being the IP address of the remote system. These artifacts are located in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\Servers.

This artifact can be analyzed using the standard Registry Editor, or a third party tool such as RegistryExplorer.

Deploy User and Entity Behavior Analytics (UEBA) solutions designed for cloud environments to monitor and analyze the behavior of users, applications, network devices, servers, and other non-human resources. UEBA systems track normal behavior patterns and detect anomalies that could indicate potential insider events. For instance, they can identify when a user or entity is downloading unusually large volumes of data, accessing an excessive number of resources, or engaging in data transfers that deviate from their usual behavior.

Implement User Behavior Analytics (UBA) tools to continuously monitor and analyze user (human) activities, detecting anomalies that may signal security risks. UBA can track and flag unusual behavior, such as excessive data downloads, accessing a higher-than-usual number of resources, or large-scale transfers inconsistent with a user’s typical patterns. UBA can also provide real-time alerts when users engage in behavior that deviates from established baselines, such as accessing sensitive data during off-hours or from unfamiliar locations. By identifying such anomalies, UBA enhances the detection of insider events.

Depending on the solution used, web proxies can provide a wealth of information about web-based activity. This can include the IP address of the system making the web request, the URL requested, the response code, and timestamps.

An organization must perform SSL/TLS interception to receive the most complete information about these connections.

By comparing three notable Event IDs, it is possible to build a timeline of when a user account was actively logged into a system. This can help to identify potential periods of inactivity where the account isn't actively being used.

Event ID 4624:  A user successfully logged on to a computer.

Event ID 4634:  The logoff process was completed for a user.

Event ID 4647:  A user initiated the logoff process.

Windows Event Log ID 4660 “An object was deleted” is generated when an object was deleted, such as a file system, kernel, or registry object. This Event is not enabled by default, and requires “Delete” auditing to be enabled in the object’s System Access Control List (SACL). This event doesn’t contain the name of the deleted object, so investigators must also utilize Event ID 4663.

Windows Event Log ID 4663 “An attempt was made to access an object” can be used in combination with Event ID 4660 to track object deletion. This Event is not enabled by default, and requires “Delete” auditing to be enabled in the object’s System Access Control List (SACL).

This may represent an anti-forensics technique if there is no reasonable explanation for why the objected was deleted from the system.

On Windows 10, we can find the Recycle Bin directory for all users located at C:\$Recycle.Bin. Insider this location are sub-folders using user account SIDs for the naming convention. To get a list of user accounts on a system Windows Management Instrumentation Command (WMIC) can be used: wmic useraccount get name,SID.

Files that begin with $R followed by a random string contain the true file contents of the recycled file.

Files that begin with $I and end in the same string as the $R file counterpart contain the metadata for that specific file, such as the original filename, path, size, and timestamp of when the file was deleted.

If the user has emptied the Recycle Bin, we lose this artifact and cannot analyze it. Instead, we would need to carve these files from a disk image.