F-Secure Elements Endpoint Detection and Response recently introduced a feature greatly simplifying incident response, called Advanced Response Actions. This feature allows responders to execute actions directly on attack targets when an attack is detected in order to aid with the incident investigation and containment.
Full documentation of the feature can be found in the EDR user guide. Without further ado, let us observe how a response process to a sample incident might look like when the aforementioned feature is utilized.
Incident detection
The following detections have been generated after the attack:
As we can see, the attack focuses on three things: PowerShell, explorer.exe injection and service-based persistence (suspicious service). We will base our analysis on this information while using Response Actions at the same time.
Analysis
Overview of the attack
The detections shown in the previous section suggest PowerShell was used to execute the payload. We can also see it was downloaded from an external host and evaluated in an interactive manner by the Administrator user. Thus we may assume – at least as the first pointer – that the command was, indeed, executed from within an interactive session. It is worth to note the PowerShell execution time as it may coincide – to an extent – with the user’s logon time.
Before we proceed, let us execute Response Actions:
The following response actions were used in order to gain additional information:
- Enumerate Processes (to list all the processes running on the system should any malicious binary be running in background)
- Enumerate Services (to list all services including potential persistence attempts)
- Netstat (to list all network connections including attacker-established ones)
- Retrieve PowerShell History (to obtain any payloads and/or recon/lateral movement/… commands used by the attacker)
- Retrieve Event Log Files (to investigate events registered by the system)
Initial access
Since Remote Desktop may be one of the methods for obtaining interactive access, one could focus on analyzing the event logs – such as ones from the Security category. As we have obtained event logs from the target system using the Retrieve Event Log Files action, we can now proceed with the analysis in Event Viewer:
If we investigate further, we can see multiple 4625 (failed login) events and two logon events – 4624 and 4648, respectively. Event details provide us with the evidence – together with Terminal Services Local Session Manager (Operational) events – confirming a successful brute-force login attack against the Administrator user from 192.168.22.10:
We could, however, gain other evidence suggesting 192.168.22.10 was, indeed, the attacker-controlled box from which the attack was executed.
Post-exploitation
Before, in the introduction, we could see that explorer.exe was injected into using Metasploit. In order to confirm it, we can analyze the Netstat action output to pinpoint any suspicious connections. In the course of doing so, we can see that the process established a network connection with 192.168.22.10:8443:
{
"localAddress": "192.168.22.13",
"localPort": 61197,
"protocol": "TCP",
"remoteAddress": "192.168.22.10",
"remotePort": 8443,
"state": "SYN_SENT",
"process": {
"pid": 316,
"path": "C:\\Windows\\Explorer.EXE",
"name": "explorer"
},
"executable": {
"normalisedPath": "C:\\Windows\\Explorer.EXE",
"fullPath": "C:\\Windows\\Explorer.EXE",
"sha1Hash": "7CAF46864357E582C8A8ACCA3D62791F456E12A7",
"owner": "NT SERVICE\\TrustedInstaller",
"publisher": "Microsoft Corporation",
"md5Hash": "368AAD73C5BD09498ED2928125FBDCA8"
},
"error": ""
}
Going forward, the persistence detection suggested that a suspicious service – qlllgq – was created. Let us see the detection-related Process Tree:
We can see that, in fact, two services were created: qlllgq and qwYEjkwIC. We can now download the service list generated using Response Actions. Then we can see whether any remnants of those services have been left after the attack by searching through it:
$ grep -e 'qlllgq' log.txt $ grep -e 'qwYEjkwIC' log.txt 1/13/2022 5:40:56 PM [I]: "qwYEjkwIC","YaVOprkJ","Win32OwnProcess"
The service list does, indeed, contain one of the services which looks suspicious. We could now obtain the information related to the service (such as what binary is started with it) using registry hives although we will leave this as an exercise to the reader. In the detection below we are shown the path under which the binary resides:
As for a reason unknown to us antivirus software might not have been triggered or not installed on the target machine – which we do recommend – we can now download the file and scan it using antivirus software on our own:
Once downloaded, the file can easily be extracted and detonated or scanned using – for example – VirusTotal:
$ unzip '[JENKINS][files][2022-01-13 18-32-14].zip' Archive: [JENKINS][files][2022-01-13 18-32-14].zip replace metadata.md? [y]es, [n]o, [A]ll, [N]one, [r]ename: A inflating: metadata.md inflating: metadata.json inflating: contents/c/windows/temp/dolphin.exe.zip.inactive $ mv contents/c/windows/temp/dolphin.exe.zip.inactive . $ unzip dolphin.exe.zip.inactive Archive: dolphin.exe.zip.inactive [dolphin.exe.zip.inactive] dolphin.exe password: inflating: dolphin.exe $
The results confirm that the binary downloaded is suspicious:
Although multiple actions could allow us to gain a deeper insight into how the attack unfolded, we will leave the demonstration at this stage.
Summing up, the attacker logged in over RDP after multiple failed attempts – suggesting a brute-force attack – on the Administrator account. Once they logged in, they launched PowerShell and executed a payload that launched Meterpreter – a part of the Metasploit framework – that was used to execute subsequent actions. Those actions included injecting into explorer.exe – in order to stay hidden and maintain a stable session – gained SYSTEM privileges and achieved persistence by creating a malicious service connected to the C:\Windows\Temp\dolphin.exe executable.
Attack execution video
We do, however, recommend watching how the attack unfolded in order to see how well it is covered by detections shown above and how easy it is to gain additional coverage using evidence obtained with Response Actions:
Additional actions
In order to perform a complete investigation and secure evidence before a full Incident Response process can be done we should:
- Perform a full memory dump (the Full memory dump Response Action)
- Contain the incident by isolating the host(s) in question (on the detection details page, as shown in the image above)
- Save the machine state/create a snapshot in case of a virtual machine
Information such as network connections (netstat), service list, process list etc. can be delivered to the Incident Response team as additional pointers as well.
Remediation
The issue of remediation could be tackled differently depending on the tools we have at our disposal. Assuming multiple avenues are available we could:
- Block communication with the attacker-controlled machine (192.168.22.10)
- Disable local account logins via Remote Desktop on the target (192.168.22.13) as a temporary measure and do not allow such logins on any machine (especially Internet-facing)
- Hunt for any communication with the address above
- Hunt for any communication from the target in order to find any signs of lateral movement
Summary
As we can see, Response Actions greatly simplify acquiring evidence when F-Secure EDR is installed and used. Although we can rely on alerts, having additional tools at our disposal is crucial when handling an incident. As such, we provide this feature since having such means can make a difference in situations where quick reaction is paramount.
Additionally, we would like to encourage you to register for our trainings should you want to gain a deeper understanding of similar topics. It is, after all, important to understand the adversary in order to strengthen our defence against them.
Links
Categories