Hunt threats now to seal your leaks
Over the past few years I have had the opportunity to perform threat hunting at various organizations and have personally seen the positive impact the findings had on an organization’s security posture and attitude towards being proactive. What’s truly great about threat hunting is that there is no right or wrong way to do it and as long as you remain proactive with your defenses you’ll be successful.
Being proactive can mean different things to different people and can get further muddied based on what your security stack & mission scope looks like. But this isn’t a post about the relationships between people, processes, and tools.
My goal as a threat hunter is to find threats that are bypassing current security mechanisms. The success of these threats are critical for any adversary aiming to perform an information operation on a target network. Typically, the threats I look for are grouped as running code, establishment of persistence or a network connection. The relationships between these groups may be worthy of an additional post at some point, but again, that is not the focus of this article.
For this post, my focus is to provide an “in-the-wild” example (I call them findings) of what threat hunting can do for you, and your organization, if you’re willing to get your hands dirty.
Trust, but verify
Before getting in to the “What” of the finding, I want to give you some context on how I classify sources of threats. A source of threats to a network can come in many forms and will not always be considered Advanced Persistent Threats (APTs). This is why I put threats into four categories of sources.
- Internal
- Unwitting Internal
- External
- Unwitting External
Because I operate with this mindset, I need access to all available data. I am not interested in data that has been filtered through allow-lists. Though these lists are necessary for efficiency in a Security Operations Center (SOC), they filter data that would otherwise be important to me in understanding the baseline. Instead, I want it all.
During one of my threat hunting operations I discovered an anomalous process, named coordinator.exe, running that was only found on a handful of the enterprise’s information systems. This article is meant to convey the importance of threat hunting through the finding outlined below.
Initial Discovery
As mentioned above, this finding started by identifying a rare process in my environment. Though I used an Endpoint Detection & Response (EDR) platform to aid in discovering this finding, I could have done the same by massaging 4688 events found in a Security Information and Event Management (SIEM).
The procedure for investigating an anomaly like this can differ from organization to organization. In this case I am going to assume I have Remote Desktop Protocol (RDP) access to the endpoint where I first discovered the anomaly and I am able to utilize open-source Sysinternals tools on the machine.
To verify the process was actively running, and to get a peek at what VirusTotal has to say, I used Process Explorer to gather some initial details. At this point I have validated the process creation events that led me here, and I observed a small number of security vendors have flagged it as malicious.
At this point in my investigation I have verified the following:
- Code is running
- The code is creating network connections
- A small percentage of security vendors suggest this is malicious
Research
As with most findings, a significant amount of research needs to be done to verify whether the anomaly we discovered should be handled as a threat. We don’t rely on tools to tell us something is bad, we make that determination as a team and do our best to provide supporting evidence as to why something is a threat.
My first stop, inevitably, is a search engine. Using information garnered from Process Explorer’s additional details, I focused in on the full path of the application:
C:\Users\user\AppData\Local\ZoomInfoCEUtility\2214\coordinator.exe“ZoomInfoCEUtility” was the search term I used and the results confirmed association to the process “coordinator.exe” and was described as ZoomInfo’s Community Edition contact contributor. A quick search on ZoomInfo showed that it is a publicly traded company and sells business to business contact information.
Results related to the search term go back to 2014 and are littered with questions about what it is and reports from online sandboxes. As far as I can tell we have a legitimate company, conducting a legitimate business, that has software installed in my environment. Normally this may be enough to write the anomaly off as a non-threat, but there are some tidbits that prompted me to follow through with the investigation.
Phase Two Investigation
The next step was to gather more information on the process, how it interacted with the operating system, and figure out why there were network communications originating from it.
Using Process Monitor helped to uncover some more details on what this process was doing. I initially clued-in on the file path that included “export” with an accompanying zip file that was resident on the filesystem. The zip file has a GUID for a name, which was redacted above. Additionally I noticed the WriteFile operation to a log file and active TCP traffic.
Using the Windows file system explorer I dug in to the “export” directory but didn’t see the zip file as expected. However, I did see a few files that warranted reading. The first file I decided to view was “login.json”. What I found were some very descriptive keys. The files “strack3.json” & “strack4.json” didn’t yield as much information, however, they did contain the names of some of my folders within Outlook.
I was still missing that zip file, but there was one more file that I needed to analyze before I could troubleshoot the zip file’s disappearance. Earlier, Process Monitor indicated the presence of a log file. I wanted to take a gander at that.
Looking through the log I can verify that data was written to the zip file, and the zip file was uploaded (potentially to cswapper.appspot[.]com). The data appears to be collected from Outlook, given the mention of “OutlookScanner”, but can not be confirmed at this point. I can only assume that once the information is “contributed”, the zip file is removed.
Now I needed to figure out what data was being exfilled from our network. It seems obvious at this point, but I needed the details if I wanted this finding to be impactful. I watched the directory for a bit while I tried to find a pattern in the log file. It appeared to activate every ~20 minutes, or when a user was active (Yes, it monitored how active the end user was). My suspicion is that it would activate if a new email came in or if the process was restarted. First I tried restarting the process through Process Explorer.
Restarting the process using Process Explorer worked as expected. The process did it’s thing and created a zip file. After ~3 minutes the zip was removed again, but not before I copied the contents. After preserving a copy of the zip file I was able to easily identify the scope of data that Zoom Info was taking from the network. Zoom Info collected the following:
- Email Header Information
- Address Book Entries
- Email Signatures
- Email Contact
- Subject Lines
- Email Signatures V2
- Email Bounce Codes
Looking through the data collected, there were a few things that were particularly disturbing. The most obvious is the fact that Zoom Info is collecting email subject lines (which they claim to not do on their website). The second disturbing piece here is that Zoom Info is scraping contact information from anyone that sends an email to an infected host/person, whether they “opted” in or not. Data is being collected on people unknowingly, subject to no terms of service (TOS) or acceptable use policy (AUP), based simply on association to someone.
Seeing the access ZoomInfo had to Outlook data made me question how it was doing all this while staying under the radar of security applications.
I appears that ZoomInfo is using a DLL to gain it’s unfettered access to Outlook. This DLL was easily researched and it’s site clearly states it’s purpose:
Outlook Redemption works around limitations imposed by the Outlook Security Patch plus provides a number of objects and functions to work with properties and functionality not exposed through the Outlook Object Model.
The access this DLL creates is a bit much for my liking, especially in a production network.
Wayyy back in the beginning of the post I mentioned something that is worth repeating. For an adversary to achieve a successful information operation, they need to establish some combination of running code, a network connection, and persistence. The only thing we have not found yet is how this application is persisted.
This may have been overkill, given that there is an uninstall.exe in the root of the ZoomInfo application directory space, but important nonetheless to ensure you completely eliminate this threat from the network.
Investigation Conclusion
With the details I collected, I knew this would be considered an incident for my client. From here I created a finding with all relevant details and packaged up some evidence to help bolster support for this being a threat. Though I couldn’t be sure, I feel this finding could be attributed to an unwitting internal person and an external threat.
To me, there are a few major issues with this finding:
- Though ZoomInfo may have had a user accept a terms of use / acceptable use policy, the contacts who send this person emails have not.
- This information can be used for contact chaining which could lead to successful targeting phishing.
- ZoomInfo is collecting data they claim is not collected.
- What type of risk does this introduce to a network. Especially considering the trend of high-profile supply-chain attacks.
Opting Out
ZoomInfo does promote that they contact any person that was not already in their database, as a notification. I can confirm that they do, in fact, notify someone but fortunately for ZoomInfo that email landed in my Spam folder.
ZoomInfo also allows a person to opt out of their database. This requires you put your email address in and submit a code that they subsequently send to you.
SO WHAT?
OK, so to many of you who are threat hunting, I understand this could be perceived as ‘cherry picking’. I want people who read this to have a realistic example of what Threat Hunters do on a day-to-day basis. Folks, we’re looking for things that fly under the radar and are not triggering detections elsewhere. This typically requires that we deal with an immense amount of data, of which, requires a bit of research to determine whether its normal. Not all anomalies result in a finding like we outlined above, but when we are able to provide findings, they go a long way in sealing the defensive gaps that inevitably exist in your network.
Indicators
- SHA1: 0F9E6849B6AE00158671989906B4309971CAF8DC
- Domains Contacted: cswapper.appspot[.]com
- Signer: Zoom Information Inc.
- SHA1: FF1ED12E43EF48EB28182E41DB6B8B6F1F660E8F
- Signer: Advanced Messaging Systems LLC
ZoomInfoContactContributor.exe (Installer)
- SHA1: DD7C4BEC659C97E7AA64D4CB44DA7DC5561475D7
- Domains Contacted: cswapper.freshcontacts[.]com
- Signer: Zoom Information Inc.
Additional interesting files:
- coordinator.cfg: A configuration file that shows a GUID as an anonymous id, and some version information on the client process (coordinator.exe). A key of ‘crawled’ under the [gal] tag (presumed to be global address list) was set to false. It worries me what the value of True would do.
- dict.json: interesting list of “tokens” or keywords. Provides indications as to what, exactly, ZoomInfo has access to.
- BadEmailDomains.txt: ZoomInfo claims to not collect contact information from privately owned accounts, and this list seems to include domains related to private email vendors. One would presume these emails would be dropped before export, however my research has shown this to be not true.
- strack3.json & strack4.json: File that tracks Outlook folders by name
