Illuminating Transparent Tribe with Validin

Illuminating Transparent Tribe with Validin

Identifying unreported domain names leveraging DNS history and host responses

In this post, I’ll highlight how to use comprehensive passive DNS and host response history, assisted with public reporting of threat groups, to identify unreported infrastructure potentially related to APT36, also known as “Transparent Tribe.”

Initial Report

This post begins with a report by CyberXTron in which a targeted phishing attack attributed to Transparent Tribe, targeted the Indian Government and Defense. The report highlighted several domain and IP indicators, and was later augmented by CyberXTroon by a tweet on X containing dozens of additional domain and IP indicators.

Figure. Indicators from the original report about the targeted phishing attempt.

Figure. Indicators from the original report about the targeted phishing attempt.

Initial Indicator Enrichment

The approach begins by creating a project in Validin, naming it “Transparent Tribe Enrichment,” and adding the indicators from the latest tweet noting it includes the indicators from the original report.

Figure. Creating a new project for tracking indicators related to Transparent Tribe enrichment.

Figure. Creating a new project for tracking indicators related to Transparent Tribe enrichment.

Note Validin extracts indicators from large blocks of text through bulk indicator import, making it easy to copy and paste from reports and other indicator sources, even when indicators have been defanged. Validin will also extract domain names and IP addresses embedded in URLs, even when defanged.

Figure. Bulk adding indicators from the update tweet by CyberXTron.

Figure. Bulk adding indicators from the update tweet by CyberXTron.

It’s important to note the tweet containing the indicators above includes indicators from hacktivist group activity and possibly other sources, so I’ll focus our efforts exclusively on the indicators from the original reporting, using Validin’s project tracking feature to highlight connections in search results to the other indicators as I progress.

In summary, these were the original IP, domain, and URL indicators:

Original Indicator Set
Ip Addr
93.127.133[.]58

Domain
kashmirattack[.]exposed
iaf[.]nic[.]in[.]ministryofdefenceindia[.]org
ministryofdefenceindia[.]org

URL
hxxps://jkpolice[.]gov[.]in[.]kashmirattack[.]exposed/service/home/

We can narrow this down even further to two two apex domains: kashmirattack[.]exposed and ministryofdefenceindia[.]org, plus the IP 93.127.133[.]58.

Wildcard Searching the Apex Domains

Within Validin, using just one search, I can identify all records associated with an apex domain and all of its subdomains simultaneously. This wildcard search enables a single query to access 11 DNS record types, host response history, certificates, and connections, registration data, and OSINT reports with a single search query.

I’ll do this with our two starting domains, kashmirattack[.]exposed and ministryofdefenceindia[.]org.

I’ll begin by adding all of the subdomains for the apex domains to our project. Through this additional subdomain awareness, I add 5 domains related to kashmirattack[.]exposed and 9 domains related to ministryofdefenceindia[.]org to our project.

Figure. Adding the subdomains for an apex domain to our project.

Figure. Adding the subdomains for an apex domain to our project.

This wildcard search under an apex domain enables us to effectuate many searches at once, saving time and effort.

DNS History

Looking at DNS hosting history for each of these domains, we can learn how the domains have changed over time and the other domains and IPs associated with these domains by DNS.

Figure. Name server resolution history for the two domains in the original report show brief resolutions to other name servers before transitioning to Cloudflare.

Figure. Name server resolution history for the two domains in the original report show brief resolutions to other name servers before transitioning to Cloudflare.

These two domains show similar patterns in Name Server history: both domains used the name servers ns1.peruadelante[.]com and ns2.peruadelante[.]com for less than a day before transitioning to Cloudflare. Note that these name servers are not considered highly popular according to Validin and thus might be a good pivot for additional discovery.

A record (DNS IPv4) history reveals a handful of low-popularity IPs when I exclude the Cloudflare IPs. I do this by clicking “Expand Summary,” then clicking on the non-Cloudlare ASNs (those that are not Cloudflare’s ASN: 13335). I exclude Cloudflare’s ASN because Cloudflare IPs typically host many thousands of unrelated domain names on them as part of their reverse proxy service offering. By filtering out Cloudflare IPs, I might be able to find IP addresses that are shared by many fewer domains, or possibly dedicated IP addresses.

As seen in the figure below, subdomains of ministryofdefenceindia[.]org have resolved to several IP addresses since mid-April, including one already in our project: 37.221.64[.]134, which is also associated with subdomains of kashmirattack[.]exposed.

Figure. Filtering by A record and further layering AS filters to highlight possible dedicated IP addresses.

Figure. Filtering by A record and further layering AS filters to highlight possible dedicated IP addresses.

Figure. Non-Cloudflare IP addresses associated with kashmirattack[.]exposed.

Figure. Non-Cloudflare IP addresses associated with kashmirattack[.]exposed.

Combined, I find the following IP addresses related by historical DNS to the original two domain names:

  • 37.221.64[.]134 - AS 200019 (ALEXHOST, Moldova) - NOTE: already in our project
  • 45.141.58[.]224 - AS 213373 (IPCONNECT, Seychelles)
  • 78.40.143[.]188 - AS 45839 (SHINJIRU-MY-AS-AP Shinjiru Technology Sdn Bhd, Malaysia)
  • 78.40.143[.]189 - AS 45839 (SHINJIRU-MY-AS-AP Shinjiru Technology Sdn Bhd, Malaysia)
  • 176.65.143[.]215 - AS 44592 (SKYLINK, Netherlands)

DNS Resolution Pivoting

Pivoting on each of the IP addresses found above, I can discover other domain names that have shared history with the original domain names over time.

Starting with 37.221.64[.]134, and sorting by First Seen, descending, I find subdomains of the two apex domains I’ve already searched, plus one additional: mea[.]gov[.]in[.]indiandefence[.]services. However, I see from the yellow asterisk by the domain that this one was already tracked in our project from the indicators in the initial tweet.

The DNS history timeline view tells a very interesting story very concisely:

  • In early March, the domain dayenter[.]shop resolved to 37.221.64[.]134 for about a month, and the PTR record for the IP pointed to mail.dayenter[.]shop.
  • In mid-April, the PTR record for 37.221.64[.]134 changed to ksm[.]ik, and domains attributed to Transparent Tribe began resolving to this IP.
  • The IP addresses for the domains dayenter[.]shop did not change after mid-April, possibly indicating dangling DNS - in this case, DNS names pointing to IP addresses no longer under the control of entity that controls the domain.
Figure. Timeline view, filtering out everything but the most recent resolutions to 37.221.64[.]134.

Figure. Timeline view, filtering out everything but the most recent resolutions to 37.221.64[.]134.

Completing this process for other IP addresses connects the original domains to several others in our project:

  • departmentofdefence[.]de
  • defenceindia[.]ltd
  • briefcases[.]email
  • departmentofspace[.]info
Figure. Pivoting through IPs connected to the starting domains connects to additional infrastructure noted in the follow-up tweet.

Figure. Pivoting through IPs connected to the starting domains connects to additional infrastructure noted in the follow-up tweet.

Note that the IPs in AS 45839 appear to be shared with hundreds of other domain names, so I will not use them directly as pivots.

Host Response Title Pivoting

Validin makes over 1 billion HTTP/s requests per day, and keeps virtual host responses for at least 75 days. This enables us to go back in time and look at how “virtual hosts” (requests made to IP addresses with a “Host” header containing a DNS name and not an IP address) have responded over time, and find other hosts that have responded the same way.

Starting in the “Host Responses” tab from our initial two searches (the wildcard searches for the apex domains mentioned in the original report), I find title tags with the text “Pahalgam Terror Attack Updates.pdf” associated with subdomains in both queries.

Figure. Using a title tag filter from the search results to identify subdomains that have responded with the title tag “Pahalgam Terror Attack Updates.pdf”.

Figure. Using a title tag filter from the search results to identify subdomains that have responded with the title tag “Pahalgam Terror Attack Updates.pdf”.

Pivoting on that title tag reveals domains and IPs I’ve already seen (including the domain dayenter[.]shop, which I believe is likely a dangling DNS record), plus one additional domain: www[.]cetus-flamer[.]com.

Figure. Showing pivots to domains and IPs from a title tag pivot.

Figure. Showing pivots to domains and IPs from a title tag pivot.

This pivot strengths the relationship between the original domains and other domains reported as being associated with Transparent Tribe.

Beware the Danging Cloudflare Proxy

One quick note about www[.]cetus-flamer[.]com: this is possibly another flavor of “dangling DNS” related to Cloudflare configuration. Specifically, Cloudflare enables a configurable origin IP address for domains configured to use the Cloudflare proxies. When a domain owner configures an origin IP through Cloudflare, loses control of that IP address, and then someone else takes control of that IP, the original domain could serve the content served by the new holder of the origin IP. Since Cloudflare is a reverse proxy, connections made to the original domain name might even still be served over properly-valated TLS without errors.

Figure. Explaining “dangling Cloudflare proxies” as a concept. The image above was modified from Cloudflare’s developer documentation to demonstrate the mechanics of this concept.

Figure. Explaining “dangling Cloudflare proxies” as a concept. The image above was modified from Cloudflare’s developer documentation to demonstrate the mechanics of this concept.

We’ve observed this before with other threats, and this phenomenon has led to misattribution of threats to unrelated domain names based on host response features like title tags. While usually not consequential (if a domain returns malicious content, it’s malicious whether or not intentional), it’s still important from a pivoting perspective to avoid over-pivoting in these cases.

To counter this, consider factors like:

  • How long has a candidate domain been configured with Cloudflare?
  • Does the candidate domain share registration similarities with other domains in the ground truth?
  • Has the candidate domain shown host response changes that coincide with activity on another IP address preceding the supposed connection to the current set of malicious observations?

Based on the above factors, I don’t believe www[.]cetus-flamer[.]com is related to the Transparent Tribe indicators explored here even though it may have unwittingly returned malicious content in its recent past.

Host Response ETag Pivoting

Looking at “unpopular pivots” in the host responses for the domains and IPs I’ve pivoted on so far, I realized that the “ETag” value W/"18-yDYnaqhRYUMt/OyUu05l2wAGXRQ" appears to be rare on the whole, but shared across many of the responses in our set.

Pivoting on this ETag reveals an IP address and several domain names that we haven’t seen before and are not already associated with Transparent Tribe through public reporting.

Specifically, these domains appear to match the subdomain conventions associated with other Transparent Tribe domains, and are also hosted on AS 200019 (on the nearby IP 37.221.64[.]252):

  • accounts[.]mgovcloud[.]in[.]storagecloud[.]download
  • accounts[.]mgovcloud[.]in[.]virtualeoffice[.]cloud
  • accounts[.]mgovcloud[.]in[.]cloudshare[.]digital
  • 37.221.64[.]252 - AS 200019 (ALEXHOST, Moldova)
  • 37-221-64-252[.]cprapid[.]com - an automatically-issued subdomain by cPanel
Figure. Domains and IP addresses sharing a relatively unique ETag value associated strongly with known Transparent Tribe-associated domain names.

Figure. Domains and IP addresses sharing a relatively unique ETag value associated strongly with known Transparent Tribe-associated domain names.

Conclusion

Through DNS and Host Response pivoting, Validin identifies many connections to publicly reported threat intelligence and possibly identified domain names associated with Transparent Tribe yet to be weaponized or publicly reported. This capability provides advance notification for anyone concerned about this threat.

Ready to elevate your threat hunting, threat attribution, and incident response efforts? Whether you’re an individual analyst or part of a larger enterprise team, Validin offers solutions that meet your needs. Individual users can create a free account and self-upgrade to access more advanced features and data.

Part of a team? Contact us today to explore our enterprise options and discover how Validin can power your organizations with powerful tools and unparalleled data. Let Validin help you work smarter, faster, and more effectively in the fight against cyber threats.

Indicators

Unreported indicators
accounts[.]mgovcloud[.]in[.]storagecloud[.]download
accounts[.]mgovcloud[.]in[.]virtualeoffice[.]cloud
accounts[.]mgovcloud[.]in[.]cloudshare[.]digital
37-221-64-252[.]cprapid[.]com

37.221.64[.]252

ETag: W/"18-yDYnaqhRYUMt/OyUu05l2wAGXRQ"

Contact Us

"Validin is the first tab I open every morning"

- Senior Analyst at a Financial Services IT Company