The Maliciousness of Proxies
Proxies have been in the cyber news somewhat recently because of Treasury sanctions and a DoJ arrest of a large proxy botnet operator. This is related to previous Brian Krebs reporting in 2022 in his A Deep Dive Into the Residential Proxy Service ‘911’ and 911 Proxy Service Implodes After Disclosing Breach blogs. These are excellent write ups on how there are legitimate uses for this kind of service, but it is predominately used in the cybercrime last mile. This very thing has been used on attacks I’ve seen in enterprise environments.
Krebs notes that usually something like proxy software is distributed in “free” VPN software where the end user does get a VPN but are also unknowingly sharing their internet connection. Alternatively, popular trojanized software is distributed via torrents with an added proxy “feature.” One other method not mentioned is explicitly installing proxy software and getting paid for sharing an internet connection. Something you don’t own, like a corporate network, is a great choice as that's free money... until you get caught.
The value of malicious actors using a service like this is having 100s or 1000s of network connections all appearing to come from unique residential IPs. This one-to-many relationship can be powerful and help attackers avoid detection. One thing Krebs doesn’t mention is how password spraying uses these proxy services. To fly under the radar, attackers leverage a unique IP for each password spray connection attempt. Endpoint Detection and Response (EDR)/eXtended Detection and Response (XDR) suites or Identity and Accessment Management (IAM) provides Okta or Microsoft Entra (formerly Azure Active Directory) can miss this because that type of traffic looks like a normal user failed authentication. It would be no different than if you failed to authenticate remotely from your home. EDRs/XDRs/IAM providers might only alert for many failed attempts from a single IP across a range of different user accounts. These proxy services easily allow attackers to implement this type of thing programmatically which requires additional or new defender logic to detect across multiple hosts and/or accounts.
Backstory and a War Story
So why summarize some Krebs stories and add a few tidbits of my own? I once happened to find a sysadmin running proxy sharing software during an assessment, among other things. It was interesting for me as that’s not common for the type of work that I do.
A little backgroun first. A couple years ago I started writing PowerShell code for data collection in an Active Directory based domain environment. There are several well-known, much more capable and robust tools that already do this, so why reinvent the wheel? Primarily because I’m not approved to use those tools. My scenario was that PowerShell Remoting was enabled (or could be) and I have local admin on all target workstations and servers. However, I was not allowed to install any unapproved executables or other tools. If I went through the approval process, I’d likely still be waiting. Nor was I supposed to run scripts that I hadn’t reviewed and vetted. My only interpreter available was PowerShell. I didn't have Python, a compiler, or anything else.
After all this wouldn’t you know, the first time I ran my code produced the best find I’ve had over two years! The code runs extremely fast due to the parallelization of PowerShell’s Invoke-Command. This is compared to a collection tool we'd typically use called Hyena from SystemTools Software. It runs system collection sequentially from a target list of domain computers, one at time, and also uses protocols that are much slower than PowerShell's Windows Remote Management (WinRM) protocol. If you see the references in my script's documentation to "Fake Hyena," this is why. A colleague gave it that name due to the similar collection functionality that we used with Hyena.
Over the years I’ve also added more collection sets and some additional capabilities, like an option to gather the same datasets locally on a non-domain standalone system. Or I’ve tried to add some robustness for certain PowerShell commands you might not find on older versions of Windows. For instance, the Get-LocalUser and Get-LocalGroup cmdlets were not on Windows Server 2012 R2, by default. If the script fails trying to use those cmdlets, it will attempt the data collection using Windows Management Instrumentation (WMI) with PowerShell’s CIM cmdlets for the former or use Active Directory Services Interface (ADSI) for the latter.
I added some additional functionality to include associating the process name with a network connection from PowerShell’s Get-NetTCPConnection cmdlet. It’s not there by default (only the process ID) or as an option like you have when running netstat elevated with the -b option in cmd. When collecting process information using Get-Process, I SHA-256 hash the related image file so I can then feed that into VirusTotal (VT) using their API. That can check 100s of file hashes in minutes for easy review. I’ve integrated @DBHeise VirusTotal.psm1 module code into some PowerShell of my own to feed my process collection output to VT.
The Finds’ Process
So what did I find? A sysadmin was actively mining Ethereum classic coins by running the T-Rex NVIDIA GPU (crypto) miner and the Honeygain proxy sharing software on corporate systems. The latter having a catchphrase of, “Passive Income – Effortlessly.” There was also some very old adult content on another system but that’s less interesting to me (though still something I must report) and unrelated to this post. I'll walk through the specifics of these two things:
Honeygain Particulars
After the environmetn collection, I first noted "Honeygain" in an Excel pivot table. I was performing long tail analysis on the environment's running processes and was looking for uncommon results. I wasn't familiar with Honeygain so I googled it. What I got back was a surprise. I then PS remoted to the system of interest and confirmed it was still actively running with process ID (PID) 9980.
This is a screenshot from the Honeygain vendor website. It also says that Honeygain is the first-ever app that allows its users to make money online by sharing their internet connection.
From there I checked for any network activity and noted that the Honeygain process ID of 9980 had an established connection on port 443 to IP 104.21.93[.]19 (click the image to zoom in).
A whois check showed that 104.21.93[.]19 belonged to Cloudflare. My guess is this was likely a system to report local client Honeygain metrics, status, etc. back to the mothership.
Looking in the user's Downloads directory I also found evidence of the Honeygain installer, Honeygain_install.exe.
I SHA-256 hashed the Honeygain_install.exe file as well for good measure/reference: 6016D3E073288A2067F288D313C944088B7282E9ED9061A9F785DEB1659036FF (click the image to zoom in).
T-Rex Particulars
Discovering the T-Rex NVIDIA GPU miner was a bit more challenging and not something I immediately noticed. Continuing with my Excel pivot table long tail analysis, I noted two "mctray" processes. From past work I knew this was the name for McAfee's A/V. However, it stuck out here because most of this environment was running another A/V, Symantec Endpoint Protection (SEP). That I was also familiar with. Not knowing anything was nefarious at this point, I wondered why only a couple instances of McAfee were detected on one system in an environment that was primarily SEP based, including the system of interest. It's possible to run multiple A/Vs at once but not typical I'd say when the capabilities of each product are so closely aligned.
Along with the Honeygain process, here you can see two instances of the McAfee's “mctray" process shown with PIDs 2836 and 10820.
Digging further in the user's Downloads directory, there's another MCAFEE directory that appeared to have the McAfee installer mctray.exe. I'm not a crypto guy so seeing these coin type abbreviations didn't ring any immediate bells, but I later realized that this directory also had saved commands to mine various coins.
Like for Honeygain I then looked for any network activity and did find the "mctray" PID 2836 was actively connected to 172.65.248[.]195 on port 4444. Hmmm, port 4444? Is that something to do with a Metasploit reverse shell listener? I'm not a red teamer or pentester but I know from some labs that port 4444 is the default Metasploit uses for that (click the image to zoom in).
A whois check showed that 172.65.248[.]195 belonged to Cloudflare as well. I'm guessing that was just a coincidence with the Honeygain network connection, but I don't know for sure. I think this was likely a T-Rex server for reporting the mining status of the local system.
From there I SHA-254 hashed the "mctray.exe" process to submit to VirusTotal and this was the clue I needed: 0fee99d5da7a84f2156397639cfc3192d2b51c3c5f750a83101252ecbb02731b (click the image to zoom in).
BOOM! It came back as t-rex.exe. I had no idea what it was but that certainly was not the real McAfee mctray.exe process. This was some security through obscurity type stuff. Now I had some leads to google which ultimately led me to the T-Rex github page.
From there the other pieces of local evidence started to pop out and make sense. There was that locally saved markdown file Readme.md from the Downloads\MCAFEE directory which was the T-Rex miner documentation. I didn't bother to open it before.
Then there was the handful of batch files I overlooked. These were saved one-liners to mine various coins. I noticed the one named mctray - ETC.cmd was the only one that had a port option of 4444. It was also affiliated with Classic Ethereum (ETC). Since the "mctray" processes were active, I think it's likely that it was the coin being mined due to the connection on port 4444. If so then obviously it had nothing to do with a Metasploit reverse shell listener (click the image to zoom in).
There was also XMRig crypto mining commands which are Linux based. This is obviously a Windows system but there was some evidence that the Windows Subsystem for Linux (WSL) was installed. Anyway, not a huge deal either way but simply more evidence supporting the general crypto mining activities of this user. I included the XMRig documentation options as a reference based on what can be seen in the screenshot (click the image to zoom in).
--url=URL: URL of mining server--user=USERNAME: Username for mining server--pass=PASSWORD: Password for mining server--donate-level=N: Donate level, default 1% (1 minute in 100 minutes)--tls: Enable SSL/TLS support (needs pool support)--tls-fingerprint=HEX: Pool TLS certificate fingerprint for strict certificate pinning--cpu-max-threads-hint=N: Maximum CPU threads count (in percentage) hint for autoconfig
The last bit of info was the user's Chia crypto wallet. Again, not my area but a quick google search shows it's for the XCH coin. I suppose a person with nefarious intent could have stolen this user's wallet based on the saved wallet recovery information. Though this is recent, there's a newer Android based malware called SpyAgent that uses optical character recognition (OCR) to steal this very thing.
