Threat Modeling Applied to Sec Ops
We discussed a process for applying Threat intelligence to Security Operations in the previous blog. Here we are going to examine a use case to provide the technical details on the process. For the purposes of this deep dive we will look at parts of a Ransomware Attack, specifically, Ragnar Locker (MITRE ATT&CK FLOW). This Threat Actor (TA) utilizes many “Live-off-The-Land” (LotL) and Defense Evasion techniques: RDP, COM Object Hijacking, Powershell and GPO Installations.
The first action in the attack model is the exploitation of externally available RDP services. It is possible that the RDP servers running EDR or Authentication services would identify a Brute Force (BF) attempt. However, without MFA or a centralized IAM security tool, attackers utilizing stolen credentials would be difficult to detect.
RDP can be utilized by administrators for maintenance purposes (although should be protected by a VPN). Utilization of valid remote session credentials alone cannot be used for detection. Contextualization through Network Traffic Analysis (NTA) or Account Authentication Event Thresholding can be used.
Existing security telemetry can be utilized to support analysis and anomaly detection around these detection techniques, in particular netflow data or authentication logs.
If we assume for this exercise that the RDP service is utilizing AzureAD sign-in logs, queries directly in the AzureAD SigninLogs Table based on Location can be accomplished using IPAddress or Location Fields, example:
SigninLogs | summarize Successful=countif(ResultType==0), Failed=countif(ResultType!=0) by Location
When those logs are sent to a SIEM, SIEM native query languages or Detection-as-Code can further refine utilizing specific location or uniqueness filters.
Security Operations Analysts viewing these events in either table or alert format will require further information and contextualization to conduct the investigation. It is important to know if there is known travel, normal login location or IP, and the frequency and time of login.
Here is the summary of this example using the process from the previous blog.
