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).
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.