Today, DomainTools announced their Maltego integration through our partnership and we are very excited about the integration. We feel as though this is definitely a positive addition to the portfolio of partners that will enable researchers and analysts to cut down analysis time, as well as uncover additional links of interest. We’ve put together the quick example that follows in order to show how you can use the DomainTools integration along with some of our other partner data. Best of all, it’s a value add available to any DomainTools API customer!
To start, we’ll pull some incidents from the ThreatConnect Common Community. The Common Community is available to anyone with a ThreatConnect account and consists of publicly shared incidents, as well as a selection shared by the CyberSquared TCIRT. You can see the results of that pull below.
From here, we’ll choose an incident at random and pull the indicators that are already included within the ThreatConnect platform. For reference, the incident chosen was 20130520A: Tendrit APT. Based on the indicators present in the pull below, we can see that there seems to be a good starting point to build out more relationships. We’ve got a few URLs distributing malware, some C2 infrastructure, a registrant email, and some malicious binaries to work with.
We now have several options with how to proceed. The first thing I’ll attempt to do is tie the hashes to a specific domain by checking them within the ThreatGRID system. Since I know the incident was from mid 2013, I’ll make sure to set my beginning dates for ThreatGRID as early as January, 2013. Running the query returns results for three of the noted binaries, and all three of those are communicating with the same domain: laton.bounceme.net
Depending on my goal, I may build out the graph a bit more based upon some of the data in the ThreatGRID analysis. For instance, maybe I want to design some network detections for the samples, so I pull the UserAgent, URLs, and IP involved as well.
Back on our original graph, I now want to build out more of the potential network infrastructure related to this specific threat. I see that a good number of the domains already on the graph are dynamic DNS so I know whois history isn’t going to be beneficial there. As a result, I’ll start with a quick resolutions check via PassiveTotal. In this case, we get a good number of results (to include the IPs we already had) which is likely aided by the age of the incident. A few checks of the IP details and we can see that some of the results are also marked as sinkholes.
Now, for the purposes of this demonstration, I won’t pivot off the new IPs that we’ve got. Doing so starts to require more time and validation for the results, especially since we know we have some sinkholes in the returned data. If I were continuing on that path, I would first select the IPs that were recorded within a short time window of the initial incident and move outward, excepting all sinkholes. At this level, what we don’t know is if there are additional potentially related non-dynamic DNS domains, and this is where DomainTools shines. The first thing I’m going to do is select the included malicious registrant email address and perform a historic domain lookup.
As a result, I get 5 potential new top level domains. However, one thing I notice is that there was a non dynamic DNS domain in our original data that isn’t on this list. I’ll attempt to link it by pulling a historic email check. In the results, I’ll look for the email that most closely corresponds to the time period in question and run a historic domain check to determine if there may be any overlap.
We don’t have any overlap yet, but what I notice is that another domain from our original data has appeared: americams.net. In order to try to try these registrant addresses together, I’ll run one more query across all of the domains above for the historic registrants of each domain. As you can see, we now have some overlap among the domains.
This also shows me that I likely need to include another registrant email from careerchallenges based upon the name involved in the overlap. In the graph below, I’ve gone ahead and run a historic domain search for the additional email, as well as a historic domain search for all registrants that showed overlap in the previous pull. To fill out the graph a bit more, I’ve run the historic IP search on all included domains. What you can see is a highly interconnected result set.
I now want to see if this data matches with any of the original data from the ThreatConnect incident post. Selecting all of the entities and copying them to the new graph will allow me to merge them while keeping the original properties populated by the transforms that were originally run. The merge process tells me that 39 entities overlapped on the pre-existing graph of ThreatConnect and PassiveTotal data, so it does in fact suggest there is a relation.
While this wouldn’t be the end of my analysis process, it would likely be a good point to shift gears and start pruning the relationships that have been generated. We have a good idea of the indicators that are higher confidence based upon multiple overlaps and concurrent timeframes. As you move away from the center, indicators that can’t be corroborated or don’t fall within the appropriate timeframe may fall out of scope and be deleted. There’s some pretty clear value in aggregating multiple data sets during your analysis, and we feel the domain data from DomainTools is a great addition in our partner lineup.