In our previous posts we identified Apple Pay domains created after the Apple Pay announcement here. We then aggregated them in a context graph and analyzed the features of the graph here. We then statistically analyzed the individual clusters here. Companion posts explaining Verum, the context graph system, can be found here and here. In this post we will manually validate the results of the previous analysis by looking at the individual clusters previously identified through statistical analysis.
Manual Cluster Validation
To this point in the analysis, everything can be automated. Rather than manually analyzing the clusters that are potentially malicious, we could classify all of the infrastructure as malicious with a confidence derived from the various measures we looked at above. The infrastructure atomic values (IPs, BGP prefixes, domains, etc) could be added to our IDS and other detection tools. Once detected, our SIEM could use the confidence to prioritize incidents for investigation and response.
But let’s say we aren’t quite sure we trust our system yet. Instead, we will now manually analyze the clusters we highlighted to validate that they represent malicious infrastructure. Let’s first recap the clusters we hoped to look at:
- Clusters with zero topic nodes. (We will take clusters with no nodes at distance zero, one, and two to make the set to analyze manageable.)
- Clusters with greater than 1.5% IQR (or just over 16%) of nodes directly related to the malice node
- Clusters above the 95% percentile of nodes two relationships from the malice node
- Clusters with high aggregate malice scores, starting with the largest score and working our way down.
- Clusters containing highly malicious nodes
To do this, let’s first subset our data to what we want. We can use the following code to subset the dataset from our previous post.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# Subset out interesting clusters # get clusters far from the topic far_clusters = df_norm[df_norm['topicDistance0'] + \ df_norm['topicDistance1'] + \ df_norm['topicDistance2']== 0].index # Get clusters greater than 1.5x IQR for maliceDistance 1 iqr15 = 1.5 * (np.percentile(df_norm['maliceDistance1'], 75) - \ np.percentile(df_norm['maliceDistance1'], 25)) + \ np.percentile(df_norm['maliceDistance1'], 75) classified_malicious_clusters = df_norm[df_norm['maliceDistance1'] > iqr15].index # Get top 5% of clusters by nodes at maliceDistancae 2 close_to_malice_clusters = df_norm[df_norm['maliceDistance2'] > \ np.percentile(df_norm['maliceDistance2'], 95)].index # Add Clusters above the 1.5x IQR for the aggregate malice score in descending order iqr15 = 1.5 * (np.percentile(df_norm['aggMaliceScore'], 75) - \ np.percentile(df_norm['aggMaliceScore'], 25)) + \ np.percentile(df_norm['aggMaliceScore'], 75) scored_malicious_clusters = df_norm[df_norm['aggMaliceScore'] > \ iqr15].sort('aggMaliceScore', ascending=False).index # 81 below was determined before by calculating the outlier cutoff for nodes. contains_malicious_nodes_clusters = df_norm.sort('MaliciousNodeRank')[:81] |
Clusters Far from the Topic
We’ll start by looking at cluster 41. The cluster is the colorful cluster below and to the left of center of the three green nodes at the center of Figure 12. It is an IP address node surrounded by 4 record nodes that indicate that it is malicious. It is connected to an ASN, BGP prefix and a domain. The domain, (center green node with 2 close, green, neighbors), is not classified as malicious. From a malice standpoint the domain, (which connects to 21 topic nodes, colored black in Figure 12, through six IP nodes in the 4 other clusters) is just at the edge of the 1.5x IQR. This appears to be a malicious IP address that has a tangential connection to multiple other sets of infrastructure through a single domain that has moved between those infrastructures. Cluster 41 is most certainly malicious, but not necessarily related to our topic domains in the other clusters. Cluster 51 represents the same situation. A malicious IP address connected to the greater graph through a single domain. Same for clusters 69, 83, and 86. Rather than analyze all of the far-distance clusters, we will assume this pattern applies to the other clusters far from the topic nodes. Next we will analyze clusters with significant percentages of nodes directly related to the malice node.
Clusters Connected to Malice
We will start with the cluster with the highest percentage of malice nodes, cluster 270. Upon inspection, it is two nodes, one of which is a malicious domain and the other is the record of the malicious classification. Same thing goes for 231, 134, 150, and the rest, (some having multiple records). A few are malicious IP addresses which then include ASN and BGP enrichments slightly diluting the concentration of maliciously classified nodes. These clusters are all malicious, but do not add any value over their original classification. We do have one cluster, 186 shown in Figure 13, which do not fit with the previous pattern. It contains two malicious nodes which share a BGP prefix and few other nodes. This should probably heighten our concern about that subnet, but not necessarily the entire cluster. The two purple nodes represent the malicious IP addresses with the associated BGP prefix represented by the yellow node in between. Hopefully the aggregated malice score will provide the necessary insight on the BGP prefix.
Clusters Two Relationships from Malice
These clusters follow a similar pattern to those directly related to the malice node. Starting with cluster 102 shown in Figure 14, we see it has a single malicious IP, an associated BGP prefix, and 12 records indicating the IP is malicious. The yellow node represents the center IP node with the red nodes indicating the records in the cluster. The blue node represents the domain that, while not in the cluster, is directly related to the malicious IP. The IP is still connected to a domain, which should be concerning due to potentially being malicious, however, the topic node’s malice score should indicate that. There are alternate clusters similar to cluster 186 profiled above in this group as well, however most follow the pattern of clusters directly connected to malice, except with IP addresses, (rather than domains), which have additional enrichments that increase the number of nodes two relationships from malice in the clusters.
Aggregate Malice Score
Aggregate malice score is the average malice score of all nodes within the cluster. The node malice score is a propagation of malice from the malice node through the graph. As such, it captures not just the direct relationship between a node and malice, but also the malice propagated through relationships from neighbors to the node. The most malicious cluster in this context graph only has 2 nodes: a record and a domain. That domain, however, is a malicious name server. This plays out for multiple clusters where a single, highly malicious name server node carries the malice for a rather small cluster. There are some interesting clusters however. Cluster 41, which popped up previously, shows up again as well as clusters 107 and 71. These tend to cluster with a highly malicious IP, which then points to a presumably malicious domain.
Cluster 65 is our first interesting cluster in this set. It has five IPs classified malicious and a whole host of information as can be seen in Figure 15. The size of the node in Figure 15 corresponds to its malice score. The Five blue IP nodes are directly connected to the malice node. In this cluster, the large green node in the center of various other nodes lower left is a topic Apple Pay domain. This domain is highly likely to be malicious even though it is not directly classified that way by any of our enrichments or classifications.
This type of pattern continues as the clusters get less malicious. More nodes are added which decreases the cluster malice score, but the additional nodes reveal additional infrastructure and indicators associated with the known malice. Some contain a topic; others are linked to topics not within the cluster. These larger clusters provide the best means of classifying previously unclassified malice. These clusters have higher internal malice scores, more nodes classified as malicious, and are highly interconnected highlighting a collection of malicious infrastructure. All of this can be algorithmically identified and the new indicators fed back into our detection tools.
We will take a look at the largest cluster, cluster 16. Figure 16 shows this cluster with nodes colored by type other than maliciously classified nodes that are colored red and topic nodes that are colored black. In the upper right we see multiple malicious domains in a single BGP prefix/ASN. Connected to that cluster of malicious IPs are various domains. Those IPs and domains connect into a less malicious portion of the cluster in the lower left. Rather than classify the nodes in the lower section as malicious, we may classify them malicious with a lower confidence that the domains directly connected to the malicious infrastructure in the upper right. This does, however, validate what we suspected about large clusters with significant aggregated malice scores.
Malice Score of Individual Topic Nodes
As outlined above, 81 clusters contain the top 1734 most malicious nodes identified as outliers. We will look at a few of those here, focusing on the clusters containing the most malicious nodes. Unsurprisingly, both the most malicious and second most malicious node in our graph are within cluster 16. They are the two largest nodes in Figure 16, one red and one brown in the upper right. The third most malicious node lies within cluster 2. This cluster contains 1390 nodes and represents a shared infrastructure based on analysis of the centrality of the cluster. In the cluster centrality, a single *aaS provider’s ASN, name servers, and IP space are very central. As such, when threat actors use the shared infrastructure, the malice ‘collects’ in the graph on nodes representing the shared service provider’s services. Cluster 0 represents a similar cluster and can be seen in Figure 18. It is interesting in that it represents two clusters of shared infrastructure (large clusters left and right of center) with domains associated with both of them (nodes in center). The two are actually two registrars, one of which used to be a reseller for the other.
|
|
df_norm.sort('MaliciousNodeRank')[:81]['order'] |
When sorted by most malicious individual node using the above line of python, the first dozen clusters all have more than 100 nodes each validating what we suspected: that the shared infrastructure dilutes the overall malice but concentrates it on individual nodes. Cluster 76 is the first with less than 100 nodes. This cluster also shows up in our aggregate malice score analysis.
Conclusion
In this series of blogs we have collected an enriched graph centered on multiple topic domains related to Apple Pay. We have scored individual nodes and clusters, identifying small clusters of malicious nodes, medium-sized clusters of infrastructure, and large clusters of publicly available shared infrastructure. We’ve classified clusters as well as individual nodes as potentially malicious with an associated confidence. We’ve done this both through automated means as well as through manual analysis. We have also included contextual data in our analysis so that analysts trying to make an assessment later have the data they need to do so. All of this allows the classification and investigation of malicious infrastructure, even before it acts maliciously or when it only indirectly exhibits it’s malice, in such a way that it can either be consumed by human analysts or by automated protection, detection, and response systems.
Addendum
While the graph database used for this analysis stores the temporal aspects of the nodes and relationships, functions to implement the algorithms to time phase the analysis through the graph has yet to be completed. As such, the analysis within this blog post is done as if all classifications and enrichments occur at a single time. In reality, IP addresses, domains, and other nodes change classifications and relationships over time. In the future we will conduct analysis through the graph that respects the temporal aspect of the data. For now, understand that the lack of temporal phasing can skew the analysis.
Also, many large clusters exist in the graph representing publicly shared infrastructure (such as shared whois obfuscating services, domain registrars, IP space, and name servers). Cluster 2 is an example of this. The analysis correctly identifies these as non-malicious, however due to their size they contain subsets of malice. This can be corrected by rerunning modularity on the large cluster by itself. (Modularity suffers from low resolution.) Alternately, future research into subdividing these large infrastructure into smaller clusters which can then be individually classified may prove fruitful.
