Category: Forensics

Sticky post

SVCHost.exe and Internet Sharing Triage

Intro

I recently had an interesting case, which involved some digging into SVCHost.exe and command line parameters parsed to it.

The Scenario

It started with an alert for a large number of DNS requests associated with an InfoStealer, ViperSoftx, from a user laptop. There were thousands of requests to the domains in a 90-minute period. Looking at the Endpoint telemetry available for the device, I could see the responsible process for the DNS requests was SVCHost.exe. This was an immediate red flag.

SVCHost.exe

SVCHost.exe is a key Windows Operating System Process, it helps host Windows Services and can load DLLs used by Shared Service Processes. Outbound connections to domains from SVCHost.exe aren’t terribly common (especially to malicious domains). Historically, SVCHost.exe has been a common process for malware to inject into / perform process hollowing on. This is typically because it’s a process that tends to load different DLLs, creates and starts services, and is a stable process to inject into.

Continued Triage

In our case, there was no evidence of process injection into SVCHost.exe and no evidence of any unusual DLLs loaded either. The infostealer that our domains had been previously associated with has also been around for a while, and its TTPs are well known. It does not typically inject into SVCHost.exe but rather sideloads a payload DLL into its own executable. It then uses PowerShell to download a 2nd stage, I had seen none of these TTPs.

The traffic patterns also did not make sense. There would be hundreds of requests to the domains in a 90-minute period, then the connections would stop. Only to continue again a few days later for another 40 minutes, then nothing. For an infected host, we’d expect to see constant beaconing.

Command Line Arguments

The endpoint telemetry for the SVCHost.exe process responsible for the connections had command line arguments parsed. The arguments were key to determining what had occurred. I’ve recreated the telemetry on my own host, and captured with Symon. I use the Swift on Security Sysmon Config.

Replicated Example

In the example below, I’m connecting to my own site and two other security blogs. Both that I highly recommend checking out:

Sysmon Output

In the examples below we can see queries to our domains, as well as the responsible process and its command line.


Dns query:
RuleName: -
UtcTime: 2023-10-04 13:48:07.128
ProcessGuid: {de4ebfc2-6b69-651d-5e04-000000001000}
ProcessId: 12484
QueryName: kmsec.uk
QueryStatus: 0
QueryResults: 185.199.109.153;185.199.111.153;185.199.110.153;185.199.108.153;
Image: C:\Windows\System32\svchost.exe
CommandLine: C:\Windows\System32\svchost.exe -k netsvcs -p -s SharedAccess
User: NT AUTHORITY\SYSTEM


Dns query:
RuleName: -
UtcTime: 2023-10-04 13:47:57.910
ProcessGuid: {de4ebfc2-6b69-651d-5e04-000000001000}
ProcessId: 12484
QueryName: newtonpaul.com
QueryStatus: 0
QueryResults: 162.241.24.119;
Image: C:\Windows\System32\svchost.exe
CommandLine: C:\Windows\System32\svchost.exe -k netsvcs -p -s SharedAccess
User: NT AUTHORITY\SYSTEM


Dns query:
RuleName: -
UtcTime: 2023-10-04 13:48:17.490
ProcessGuid: {de4ebfc2-6b69-651d-5e04-000000001000}
ProcessId: 12484
QueryName: lowery.tech
QueryStatus: 0
QueryResults: 154.49.138.213;
Image: C:\Windows\System32\svchost.exe
CommandLine: C:\Windows\System32\svchost.exe -k netsvcs -p -s SharedAccess
User: NT AUTHORITY\SYSTEM

SharedAccess

The command line “C:\Windows\System32\svchost.exe -k netsvcs -p -s SharedAccess” is the key.

  • -k netsvcs: This indicates that the registry key for svchost shown below, should locate the value parsed by -k, which in this case is netsvcs.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost\netsvcs

In this case, netsvcs is a service group.

  • p -s SharedAccess: This is telling svchost to only load the SharedAccess service from the selected group parsed by -k.

Checking the SharedAccess service, we can see it has a display name of Internet Connection Sharing (ICS).

svchost.exe service

You can find out more about the Shared-Access Service here:

Internet Connection Sharing

This was the “aha” moment. What if it wasn’t our host that was infected, but another host sharing its internet connection? Internet Connection Sharing or ICS is essentially internet hotspotting. It allows you to share the internet connection on one device, with another.

This would also explain the start/stop nature of the C2 traffic. We’d only seen DNS requests from the SVCHost.exe hosting the ICS service, while the infected host was connected. During an ICS session, DNS requests from the remote host are essentially proxied through the svchost.exe process on our local host.

Confirming the Hypothesis

How can we know for sure that our hypothesis is correct? Well, some quick and dirty forensics is the answer.

I dumped the svchost.exe process responsible for the DNS requests (PID 12484).

A quick run of Strings across the .dmp, where I outputted the results into a .txt file.

strings 12484.dmp > svchost_strings.txt

Strings Output

# Copyright (c) 1993-2001 Microsoft Corp.
# This file has been automatically generated for use by Microsoft Internet
# Connection Sharing. It contains the mappings of IP addresses to host names
# for the home network. Please do not make changes to the HOSTS.ICS file.
# Any changes may result in a loss of connectivity between machines on the
# local network.
#192.168.137.246 vn-mon-99.mshome.net #
#192.168.137.1 LAPTOP-8FH6K397.mshome.net #

In the strings output, we can see the Internet Sharing session being established between our two hosts:

In addition to this, we can also see the domains that we beaconed out to, as well as other general host traffic, and SVCHost activity.

v10.events.data.microsoft.com
AMER08.azure-devices.net
AMER08.azure-devices.net
statics.teams.cdn.live.net
newtonpaul.com
v10.events.data.microsoft.com
gew1-spclient.spotify.com
lowery.tech
kmsec.uk
Inbound rule for Internet Connection Sharing to allow use of the IPv6 DHCP Server. [UDP 547]

Concluding Thoughts

With that, I was able to confirm that it wasn’t our initial host infected, but rather a personal host belonging to the user, connected via Internet Sharing.

That brings this mini-post to an end. Hopefully, if you encounter unusual DNS requests coming from svchost.exe with the ICS service loaded, you’ll save some time on triage.

Previous Posts

Check out some older posts here, or below.

Malware Analysis: Memory Forensics with Volatility 3

Intro

In this post, we’re going to take a look at Volatility 3, the newest version of the industries most popular memory forensics tool (within the open-source community at least).

We have a memory dump from an infected host that we’re going to look at and compare how the newest version of the tool performs as opposed to volatility 2. Let’s get started!

Install Volatility

Firstly we need to install a couple of dependencies, Python3 and Pefile. I’ve installed Python 3.8.6 from here.

When installing Python, make sure you tick the box “Add Python 3.8 to PATH” if you do not want to add the PATH manually.

Memory Forensics with Volatility 3

Follow the default instructions to complete the installation.

Next, we need to install PEFile. I installed PEFile using pip.

pip install pefile


I installed version 2019.4.18 which you can find here.

These are the only two “required” dependencies that volatility requires, so we can now move on to install volatility.

I used git to download volatility, you can download git from here if you do not already have it installed. Once installed, launch Git Bash and run the command

git clone https://github.com/volatilityfoundation/volatility3.git

The package should be cloned into a folder called volatility 3, which by default will be located in your user folder. So in my case, it’s
C:\Users\paul\volatility3

Memory Forensics with Volatility 3

We can now check if volatility has been installed properly by navigating to our volatility3 folder in CMD and running the command.

python vol.py -h

If all has gone right, we should see an output like the following:

Memory Forensics with Volatility 3

This means that we’re now ready to use volatility to analyse our memory dump.

Using Volatility

Anyone who like myself is used to using Volatility 2 will notice that there are immediately some obvious changes with Volatility 3. Firstly, profiles are gone so you no longer have to scan a memory dump to find out which OS profile it’s compatible with. YAY 🙂

The way in which plugins are called in the command line is also slightly different. For example, if we want to run the plugin pslist to display the running processes in a memory image, we would do so by specifying the plugin name windows.pslist.PsList

Let’s give that a try now!

Top Tip: It’s good practice to record the output of volatility into txt files. That way we can easily go back and read through the results instead of having to try and read everything via the command line. I’ve created a new folder called evidence, and the results from each plugin run will be written to txt files in there.

To run the pslist plugin we’re going to run the following command:

C:\Users\paul\volatility3>python vol.py -f C:\Users\paul\Documents\memdump.mem windows.pslist.PsList > C:\Users\paul\Documents\Evidence\pslist.txt

Let’s break this command down to understand what it’s doing. Firstly, we’re telling Python to run our volatility script called vol.py. Then we’re using the -f flag to specify the location of our memory dump file. Next, we’re specifying the name of the plugin we want to run, and finally, we’re using the > flag to say that we want the results to be written out to a txt file called pslist which will be written to our evidence folder.

This is the basic command line format that we’re going to need to use for most plugins. Let’s go ahead and run some of the core plugins to gather some basic information. We’re going to run:

  • pslist – gives us a list of running processes.
  • pstree – gives us the same information as pslist, however, displays the output in a process tree so we can see child and parent process relationships.
  • netscan – gives us open network connections.

Processes

If we look at the output from running pslist below, there are a couple of processes that catch my eye, firstly Microsoft Word. As we know, Microsoft Office applications like Word and Excel are commonly used to distribute malware usually by using a malicious macro or embedded file. The Emotet campaign is particularly well known for using these methods.

The other application that catches my eye is fphc.exe. This is not an application that I am familiar with and does not look to be a Windows application. Basically, it looks weird.

PID PPID ImageFileName Offset(V) Threads Handles SessionId Wow64 CreateTime ExitTime File output

1100 720 svchost.exe 0x85854dd362c0 23 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1140 720 svchost.exe 0x85854ba842c0 2 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1180 720 svchost.exe 0x85854ba90300 3 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1188 720 svchost.exe 0x85854f8020c0 2 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1196 720 svchost.exe 0x85854f805300 3 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1320 720 svchost.exe 0x858547e3c240 5 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
1376 720 svchost.exe 0x85854faa0240 5 - 0 False 2020-10-15 12:53:55.000000 N/A Disabled
8048 968 UserOOBEBroker 0x85854bd31080 3 - 1 False 2020-10-15 13:05:55.000000 N/A Disabled
7328 720 svchost.exe 0x85854f707080 4 - 0 False 2020-10-15 13:12:01.000000 N/A Disabled
5732 968 WinStore.App.e 0x858547ec2080 11 - 1 False 2020-10-15 13:12:47.000000 N/A Disabled
4288 968 RuntimeBroker. 0x85854dce9080 1 - 1 False 2020-10-15 13:12:47.000000 N/A Disabled
8400 968 dllhost.exe 0x8585506ed080 5 - 1 False 2020-10-15 13:12:53.000000 N/A Disabled
4372 968 SystemSettings 0x8585506ea080 19 - 1 False 2020-10-15 13:13:17.000000 N/A Disabled
6140 720 svchost.exe 0x85854e9430c0 2 - 0 False 2020-10-15 13:15:14.000000 N/A Disabled
8532 2176 WINWORD.EXE 0x85854b48e080 16 - 1 True 2020-10-15 13:24:51.000000 N/A Disabled
8340 2176 Taskmgr.exe 0x85854b23b080 15 - 1 False 2020-10-15 13:26:00.000000 N/A Disabled
7432 5668 fphc.exe 0x85854b659080 4 - 1 True 2020-10-15 13:26:03.000000 N/A Disabled
6880 1884 chrome.exe 0x85854fadb080 11 - 1 False 2020-10-15 13:37:20.000000 N/A Disabled
5844 720 svchost.exe 0x858551224080 5 - 0 False 2020-10-15 13:38:02.000000 N/A Disabled
6932 968 smartscreen.ex 0x85854e241080 10 - 1 False 2020-10-15 13:38:02.000000 N/A Disabled
7572 6104 wermgr.exe 0x85854e393080 4 - 1 False 2020-10-15 13:38:36.000000 N/A Disabled
5268 2348 audiodg.exe 0x85854c4b1080 8 - 0 False 2020-10-15 13:38:53.000000 N/A Disabled
8348 2176 FTK Imager.exe 0x85854d191080 22 - 1 True 2020-10-15 13:38:55.000000 N/A Disabled
548 720 svchost.exe 0x8585512bb080 6 - 0 False 2020-10-15 13:38:55.000000 N/A Disabled

Running pstree does not give us anything else of interest. WinWord.exe has a parent of explorer.exe which is to be expected. While our other application of interest, fphc.exe has a Parent Process ID (PPID) of 5668. However, there is no application that has this PID in the recorded pslist output. This likely means that our fphc.exe is an orphan process.

C:\Users\paul\volatility3>python vol.py -f C:\Users\paul\Documents\memdump.mem windows.pstree.PsTree > C:\Users\paul\Documents\Evidence\pstree.txt

Network Connections

Now let’s take a look at network connections by running netscan.

vol.py -f C:\Users\paul\Documents\memdump.mem windows.netscan.NetScan > C:\Users\paul\Documents\Evidence\netscan.txt

We can perform basic OSINT on the IPs returned below using tools like VirusTotal. Many of the IP addresses appear to belong to Microsoft, specifically Azure.

Offset Proto LocalAddr LocalPort ForeignAddr ForeignPort State PID Owner Created
0x858546369010 TCPv4 192.168.44.130 51793 52.109.76.78 443 CLOSED - - N/A
0x8585467aa2c0 TCPv4 192.168.44.130 139 0.0.0.0 0 LISTENING 4 System 2020-10-15 13:24:48.000000
0x858547334d70 TCPv4 192.168.88.128 139 0.0.0.0 0 LISTENING 4 System 2020-10-15 12:53:57.000000
0x8585473a6830 TCPv4 0.0.0.0 49669 0.0.0.0 0 LISTENING 2856 spoolsv.exe 2020-10-15 12:53:56.000000
0x8585473a7160 TCPv4 0.0.0.0 49668 0.0.0.0 0 LISTENING 2188 svchost.exe 2020-10-15 12:53:56.000000
0x8585473a72b0 TCPv4 0.0.0.0 49668 0.0.0.0 0 LISTENING 2188 svchost.exe 2020-10-15 12:53:56.000000
0x858547e17270 TCPv4 192.168.44.130 51894 87.237.22.163 443 CLOSE_WAIT - - N/A
0x85854b936ba0 TCPv4 192.168.44.130 51899 52.114.132.91 443 ESTABLISHED - - N/A
0x85854bb56010 TCPv4 192.168.44.130 51895 13.107.3.254 443 ESTABLISHED - - N/A
0x85854c16d960 TCPv4 192.168.44.130 51891 40.67.251.132 443 ESTABLISHED - - N/A
0x85854c378460 TCPv4 192.168.44.130 51901 62.108.35.36 443 SYN_SENT - - N/A
0x85854c3b3010 TCPv4 192.168.44.130 51900 185.99.2.123 443 CLOSED - - N/A
0x85854d0cfa40 TCPv4 192.168.44.130 51893 13.107.4.254 443 ESTABLISHED - - N/A
0x85854d3b4280 TCPv4 192.168.44.130 51831 54.183.140.32 443 ESTABLISHED - - N/A
0x85854d5ac010 TCPv4 192.168.44.130 51896 204.79.197.222 443 ESTABLISHED - - N/A
0x85854e3a6050 TCPv4 192.168.44.130 51898 84.53.156.184 80 ESTABLISHED - - N/A
0x85854fef1010 TCPv4 192.168.44.130 7680 192.168.44.1 57428 CLOSED - - N/A
0x8585500ada70 TCPv4 192.168.44.130 51886 172.217.20.130 443 ESTABLISHED - - N/A
0x8585506e98a0 TCPv4 192.168.44.130 51781 40.67.251.132 443 ESTABLISHED - - N/A
0x8585508b6230 TCPv4 192.168.44.130 51890 204.79.197.200 443 ESTABLISHED - - N/A

When searching on the Microsft IP addresses, none of them returns any “detection” hits. However, if we look in the “relations” tabs and look at communicating files, we can see many hits on malicious word documents that have called out to some of the IPs we’ve seen. If we draw a threat graph, like the one below, we can see an example of a malicious document that has been associated with the Microsoft IP 52.114.132.91.

It can often be difficult to determine if connections to cloud services like Azure and AWS are malicious or not, due to the fact that IP addresses are shared and reused by different users. It’s a good place for malware authors to hide their attack infrastructure and attempt to blend in with legitimate traffic.

Aside from the Microsoft IP addresses, there were also two other addresses from netscan which are of significant interest.

62.108.35.36
185.99.2.123

Both of these addresses returned detection hits on VirusTotal. Additional OSINT links both of these IP to TrickBot infrastructure. TrickBot is a well-known banking trojan that has been around for several years now. It is commonly distributed via Emotet.

Digging Deeper

We’ve seen a few things now which make us suspect that TrickBot malware has been delivered onto the host via an Emotet. Now we need to try and confirm that this is what has occurred.

Firstly let’s look to see if PowerShell was used by a Macro to download malware as can commonly be the case. We can use the command cmdline to list process command line arguments.

vol.py -f C:\Users\paul\Documents\memdump.mem windows.cmdline.windows.cmdline.CmdLine> C:\Users\paul\Documents\Evidence\cmdline.txt

Unfortunately, there were no interesting PowerShell commands in the results. In Volatility 2, we had the option to use the plugins “cmdscan” and “console” as well as the third-party plugins which try to locate interesting Powershell activity in memory. We’re a little more limited with Volatility 3 as we only have the “cmdline” command.

However, cmdline still did return some useful pieces of informatiuon.

We have the name of the Word Document that was opened by the user:

8532 WINWORD.EXE "C:\Program Files (x86)\Microsoft Office\Root\Office16\WINWORD.EXE" /n "C:\Users\Admin\Documents\Detalii-123393.doc\Detalii-123393.doc" /o ""

And we also have the path of the unusal executable that we saw:

7432 fphc.exe "C:\Users\Admin\AppData\Local\fltLib\fphc.exe"

In volatility 2, we were able to use the “dumpfiles” plugin to dump files from memory. However, that seems to no longer be an option in Volatility 3. We can, however, dump a running process by using the pslist command with a dump flag. Using the command below we can dump fphc.exe to analyse.

python vol.py -f C:\Users\paul\Documents\memdump.mem windows.pslist.PsList --pid 7432 --dump

We still need to obtain the Word Document, but this is going to be difficult without being able to dump individual files. What we could do is dump the WinWord.exe process and try to carve the file out. This is a lot of effort though for what is likely to be commodity malware. So instead we’re going to cheat and just pull the file directory from the host now that we know the path that it’s located in. You could also do OSINT on the filename and try to find a copy on VT or AnyRun to download.

Emotet Analysis

As expected, the document contained a malicious VBS macro, which launches PowerShell with a base64 encoded command. I used CyberChef to decode the text from Base64 and also decoded the text from UTF-16LE (1200). Below we have the obfuscated PowerShell command:

I performed some basic deobfuscation of the code, which I’m not going to go into in this post. I have written how to deobfuscate Emotet Powershell in a previous post here.

Below is a rough deobfuscation of the PowerShell. We can see the script tries to download the file I3d47K.exe into the user’s directory from one of the URLs contained in the site list. A check of the file size of the downloaded file is performed to ensure that the file was properly downloaded, and if it passes that check, the file is then executed.

Emotet Powershell

It’s interesting that we have not seen any sign of the executable I3d47k.exe within any of our Volatility outputs. It’s likely that this executable either drops fphc.exe or is renamed to this.

Executable Analysis

OSINT on our dumped application fphc.exe identifies it as Emotet, as expected. Dynamic analysis on the executable however has shown that it fails to execute properly. We see werfault.exe executed as a result of the application crash. It is possible for malware like TrickBot and Emotet to inject into WerFault. However, when this happens the command line for the process is usually empty, but in our case, we have flags being parsed. Additionally, we’re presented with a crash error, and there is no other typical Emotet activity.

There are a few reasons as to why the malware is not executing properly and the most likely is due to an error when dumping it from memory.

Review of Volatility 3

We’ve been able to build a rough picture of what has occurred on the host, but our analysis is not as complete as I would like. In forensics, you aim to build as clear a picture as possible, and in this case, there are definitely some gaps in our timeline of what’s happened. There was some information missing from our evidence collected with Volatility, but this can often occur in memory forensics as the data we’re dealing with is…..volatile.

The lack of plugins for Vol 3 is something that makes me still favour Vol 2. This will change over time though. As the tool is adopted more widespread, additional plugins will be developed. The Volatility Foundation’s annual plugin competition will from this year be focused on Volatility 3, and with official support for Volatility 2 ending in 2021, it’s only a matter of time before more users move to the newer version and the tool improves.

The two main things that Volatility 3 has going for it is its speed (it’s a huge improvement on Vol 2) and that it is now easier for developers to use the codebase to develop new plugins. The move away from OS profiles is also a welcome addition, as is it’s support for a larger variety of OS versions.

Volatility 3 Plugins

Here’s a list of the different Volatility 3 Plugins for Windows. Don’t forget there are also Mac and Linux plugins too.

windows.bigpools.BigPools,
windows.cmdline.CmdLine,
windows.dlllist.DllList,
windows.driverirp.DriverIrp,
windows.driverscan.DriverScan,
windows.envars.Envars,
windows.filescan.FileScan,
windows.getservicesids.GetServiceSIDs,
windows.getsids.GetSIDs,
windows.handles.Handles,
windows.info.Info,
windows.malfind.Malfind,
windows.memmap.Memmap,
windows.modscan.ModScan,
windows.modules.Modules,
windows.mutantscan.MutantScan,
windows.netscan.NetScan,
windows.poolscanner.PoolScanner,
windows.privileges.Privs,
windows.pslist.PsList,
windows.psscan.PsScan,
windows.pstree.PsTree,
windows.registry.certificates.Certificates,
windows.registry.hivelist.HiveList,
windows.registry.hivescan.HiveScan,
windows.registry.printkey.PrintKey,
windows.registry.userassist.UserAssist,
windows.ssdt.SSDT,
windows.statistics.Statistics,
windows.strings.Strings,
windows.symlinkscan.SymlinkScan,
windows.vadinfo.VadInfo,
windows.verinfo.VerInfo,
windows.virtmap.VirtMap

Extracted IOCs

hxxp://riandutra[.]com/img/YX1/
hxxp://swimsecure[.]com/vsim-henry/r/
hxxp://guarany[.]net/zefiro/ZO
hxxp://losgalpones[.]com/wp-admin/T
hxxp://qualitychildcarepreschool[.]com/0Bq0iCR6gx/oq
hxxp://businessexitnow[.]com/old-wp-includes/1yr/
hxxp://brownshotelgroup[.]com/2r

BFF959FC9504DCF7420C95D0F804334E366A5F54B41CD4C1B3D1FC09256EC459

Copyright © 2024 On The Hunt

Theme by Anders NorenUp ↑