I am starting these short-form blog posts that aim to provide insights into attackers’ actions once they gain access to a network. Although the intrusions I will cover do not require lengthy reports, they are still useful for understanding the mindset behind the adversaries’ actions.
One of my main goals is to provide resources for newcomers in the field and help them develop their investigative skills with data from real intrusions. Each blog post will feature sanitized artifacts related to the intrusion, such as endpoint logs, network traffic, and host-related files. In that way, people can re-trace the steps attackers made using the available telemetry and, at the same time, learn how to use or create their own tools. Let’s dive into this short intrusion!
Summary
In late June, I observed an intrusion that originated from the direct distribution of a Cobalt Strike beacon via phishing email. Although I have seen phishing campaigns delivering Cobalt Strike directly in the past, they are generally not as common. This short blog will highlight the hands-on-keyboard activity of the threat actors five hours after the initial infection.
In this instance, they tried to disguise the Cobalt Strike Beacon as a PDF document. They did this by using a file name that matched the subject of the phishing email and adding a phony “.pdf” extension. There was a delay of around five hours between the time of the initial infection and the hands-on activity. After deciding to interact with the host, they added another Cobalt Strike Beacon under the “C:\Users\Public“ folder that had similar characteristics to the original payload. After saving all the malicious files to the disc, they used the attrib command to hide them from the system. They also set up a scheduled task to ensure persistence. I also observed them a couple of times querying for the services of the host. Based on the command line, I assume they were looking for any installed antivirus software.
Eventually, after looking around for some more interesting files and directories, they staged their files of choice under “C:\Users\Public”, zipped them up, and proceeded with exfiltrating them via the Cobalt Strike Beacon. Before they departed the network for the day, they made sure to delete all traces of staged files and initial payloads from the host.
You can find the artifacts of this case at: https://github.com/tsale/Intrusion_data
Initial Access
The malicious software was distributed through a phishing email that contained a compressed RAR file attachment. Inside the compressed file was the Cobalt Strike beacon.
Thanks to @tosscoinwitcher for providing additional context related to the phishing campaign in this thread.
Execution
This case had a very simple execution involving only Cobalt Strike Beacons. They appeared to be Python-compiled binaries. When a packaging tool like PyInstaller is used to compile the binaries, upon its execution, the binary needs to extract certain resources to a temporary location on the disk in order to execute.
- These include shared libraries (DLLs in Windows) which are necessary for the execution of the Python binary.
- Other resources might include Python .pyd files and other data files bundled with the binary, such as an image or text file used by the application.
The exact behaviour depends on the settings used when packaging the Python script into an executable. By default, many of these tools will create a directory with the same name as the executable in the user’s Temp directory and extract the necessary resources there. In this case, the name of the directory was “_MEI94402”.
In general, the extraction of these resources can help us detect any unwanted execution of a Python binary.
One important aspect of the initial Cobalt Strike executable is that its metadata has been altered to resemble that of a genuine Google Chrome binary. This was not the case for the second Cobalt Strike Beacon they brought into the environment, GoogleChrome.exe. I used the exiftool to extract some of the most notable metadata and present them below:
Filename: Public Opinion Survey.pdf.exe
Language Code : English (U.S.)
Character Set : Unicode
Company Name : Google LLC
File Description : Google Chrome
File Version : 114.0.5735.135
Internal Name : chrome_exe
Legal Copyright : Copyright 2023 Google LLC. All rights reserved.
Original File Name : chrome.exe
Product Name : Google Chrome
Product Version : 114.0.5735.135
Company Short Name : Google
Product Short Name : Chrome
Last Change : fbfa2ce68d01b2201d8c667c2e73f648a61c4f4a-refs/branch-heads/5735@{#1270}
Persistence
The threat actors used the Schtasks Windows binary to schedule a task that will execute every minute on the infected cost. Below you can see the command and a breakdown of its components:
schtasks /create /tn WindowsUpdate2 /tr “C:\Users\Public\GoogleChrome.exe” /sc minute /mo 1
- schtasks: — This is Windows’s task scheduler command line tool.
- /create: — It’s a switch of the Schtasks binary that tells it to create a new scheduled task.
- /tn WindowsUpdate2: — The ‘/tn’ switch specifies the name of the task; in this case, it’s named ‘WindowsUpdate2’.
- /tr “C:\Users\Public\GoogleChrome.exe”: — The ‘/tr’ switch stands for “Task Run”, and specifies the task to be run at each scheduled time. Here, ‘C:\Users\Public\GoogleChrome.exe’ is the task to be run. The file path leads to the executable on the disc.
- /sc minute: — The ‘/sc’ switch stands for “Schedule”, and is used to specify the frequency of the task. Here, ‘minute’ means that the task will run every minute.
- /mo 1: — The ‘/mo’ switch stands for “Modifier”, and is used in conjunction with ‘/sc’ to specify how often the task occurs during the frequency period. Here, ‘1’ means that the task is performed at an interval of 1 minute.
This task was set to start immediately and run every minute indefinitely after you execute the command.
💡 Detection Opportunity
We can detect this activity by looking into executables that are spawned from the “C:\Users\Public” directory as part of a scheduled task.(see Sigma rule on the IOC section at the end of the blog)
Discovery
Threat actors used the command line to enumerate the host for running services and to view the current working directory. I am also aware that they had visual access to the system by some means. Based on the capabilities of Cobalt Strike, I assume they use the VNC capability to discover important documents with the purpose of exfiltrating them later on. When threat actors use features like this, by default, a new process of “rundll32.exe” will spawn without any command line arguments. I dive into these features in the two Cobalt strike reports I’ve written:
💡 Detection Opportunity
We can detect this behavior by looking for rundll32.exe processes spawning without any command line arguments(see Sigma rule on the IOC section at the end of the blog)
Defense Evasion
Attackers often do this to deceive users or security systems about the file’s true nature. By changing the file extension, an attacker can disguise an executable file (such as .exe) as a harmless file type (such as .jpg or .txt), tricking the end user into opening it thinking it’s a harmless file.
Attackers are often attempting to deceive users or security systems about the true nature of a file. They do that by changing the file extension to disguise an executable file (such as .exe) as a harmless file type (such as .pdf). In this case, they went to the extent of including the icon that corresponds to a PDF file on Windows systems.
Fake PDF main_icon_dhash: 64e4d4d4e8f4dcd4
One of the first things that threat actors did was to use the “attrib” command to hide the malicious files from the user. Below you can see the command and a breakdown of its components:
attrib “C:\Users\Public\GoogleChrome.exe” +s +h
- attrib : This is a command in Windows that alters the attributes of a particular file or directory. It can change files to read-only, hidden, system, etc.
- “C:\Users\Public\GoogleChrome.exe” : This is the path to the file that you want to change the attributes for. In this case, the file is GoogleChrome.exe in the ‘Public’ directory.
- +s : This is making the file a system file. System files are important files for your operating system and are often hidden to prevent users from accidentally deleting or modifying them.
- +h : This stands for ‘hidden’. This is making the file hidden from view in the default file explorer. If the user wanted to see this file, they would need to adjust their folder settings to view hidden files.
Additionally, changing the metadata can complicate the process of threat analysis and investigation. Metadata can provide vital clues about a file’s origin, its intended purpose and other identifiable information. By changing the metadata, attackers could also hinder investigative efforts.
This could also be an attempt to bypass security systems, as some systems may be designed to block files based on certain metadata characteristics. However, in this case, the name of the file did not match the metadata characteristics, making it easy to distinguish.
💡 Detection Opportunity
We can set up a detection rule to notify us whenever a .exe file is executed with a non-executable file extension preceding it. (see Sigma rule on the IOC section at the end of the blog)
Collection
Threat Actors found the files and directories of Interest and zipped them under their working directory “C:\Users\Public”. There is no evidence of execution related to this, however, as described above, they could have used VNC to do it manually after having graphical access of the infected host.
💡 Detection Opportunity
We can look for the creation of large-sized compressed files in unusual directories. This is more of a hunting rather than a detection opportunity. You may have to baseline your environment to learn what is normal in this case before you identify related abnormal activity.
Exfiltration
When looking for signs of data exfiltration, we anticipate seeing a larger amount of data leaving the network than coming in. In this specific case, we are analyzing the traffic between the Cobalt Strike Beacon and malicious infrastructure. The visual representation below indicates a sudden increase in outgoing traffic, which implies that data may have been exfiltrated during this time.
Another source of information to look for possible data exfiltration would be the System Resource Usage Monitor (SRUM). Using the Network Usage information from SRUM, we can see what applications are responsible for the most data on the wire — either sent or received — and correlate to the user behind them (source: https://www.magnetforensics.com/blog/srum-forensic-analysis-of-windows-system-resource-utilization-monitor/). We can use Eric’s SrumECmd tool to parse the SRUDB.dat file located under “C:\Windows\System32\sru\” directory.
Command and Control
The beacon was communicating over HTTP to the same infrastructure over port 39999 as the main C2 connection and 9090 to download additional payloads. The information was passed back to the Cobalt Strike server using the cookie field.
Upon visiting the IP on port 9090, a file called “Survey.rar“ will download. Inside this compressed file is there initial Cobalt Strike Beacon.
💡 Detection Opportunity
We can detect suspicious network traffic that involves the use of unusual ports for communication through HTTP. To a trained eye, this network activity stands out. If you utilize an IDS/IPS sensor in your network environment, you can use the existing Suricata/Snort rules from the ET Open Ruleset. (See related Suricata rules in the IOC section at the end of the blog)
IOC/IOA
103.147.13.191 — newsis[.]info
103.147.13.191:39999
103.147.13.191:9090
JARM: 3fd3fd0003fd3fd21c42d42d000000307ee0eb468e9fdb5cfcd698a80a67ef
Cobalt Strike Profile (source: https://tria.ge/230629-vxtbwsec98/behavioral2)
host: 103.147.13.191,/push
http_method1: GET
http_method2: POST
polling_time: 60000
port_number: 39999
sc_process32: %windir%\syswow64\rundll32.exe
sc_process64: %windir%\sysnative\rundll32.exe
uri: /submit.php
user_agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0; BOIE9;ENUS)
watermark: 0
Suricata Rules
ET MALWARE Cobalt Strike Beacon Observed
ET HUNTING GENERIC SUSPICIOUS POST to Dotted Quad with Fake Browser 1
Sigma Rules
Suspicious Service Binary Directory
Suspicious Rundll32 Without Any CommandLine Params
Suspicious Scheduled Task Creation
Suspicious Double Extension File Execution
Artifacts
GoogleChrome.exe — ef1200ef966e3f1e1edafe90b10cadea68bbd4a5041afdb12b0513f61d4b3dcf
Public Opinion Survey.pdf.exe — f08acb183d2554fa099f9a7f79fdbf7930a5ec63a39a735b425e0e49049d272f
Start.png — 7f293907f1a91722ee8e8247f5a21964dcccdabe9f502e3115cc716f7811f392
Start3.png — 4f6492881c68306804c8b78fde7052c0a480b2de59e226ed6b8ef25ee5b2e5b5
Update2.ico — cdd799a7ab5a63730d4a22a32764351caea8ef5f7a7202db68c7058bd8612b87
Update3.ico — 080b8fa8fb8bdb51397367f3d5de41d997be1027538bf220effefdaa92af5b05
