{ "id": "622e8b36-884c-450f-b048-2b5be94e5fa2", "created_at": "2026-04-06T01:31:04.782563Z", "updated_at": "2026-04-10T13:11:44.873666Z", "deleted_at": null, "sha1_hash": "c018a93f0e1467fab7e3a6ba310ad34938a77400", "title": "NanoCore RAT Hunting Guide", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1030604, "plain_text": "NanoCore RAT Hunting Guide\r\nBy John F\r\nPublished: 2022-09-14 · Archived: 2026-04-06 00:44:12 UTC\r\nAnalysis and tools for hunting NanoCore command-and-control\r\n9 min read\r\nAug 30, 2022\r\nNanoCore is a prevalent RAT (Remote Access Trojan) which is used by threat actors to spy on victims and\r\nprovide remote access to target computers. CISA identified NanoCore as a top malware strain of 2021 due to its\r\nprevalence among cyber criminals and potential to cause damage. I have researched NanoCore’s command-and-control framework and I wrote this blog post as a guide for hunting-down and blocking NanoCore.\r\nTable of Contents\r\nBackground and Functionality\r\nCommand-and-Control Analysis\r\nNetwork Defenses\r\nMeta-Analysis of IOCs\r\nHunting Summary\r\nSee Also\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@the_abjuri5t/nanocore-rat-hunting-guide-cb185473c1e0\r\nPage 1 of 7\n\nBackground and Functionality\r\nIn 2013, Taylor Huddleston (arrested in 2017) wrote NanoCore using the .NET framework. Despite its age, the\r\nRAT remains popular among cyber-criminals and malware-as-a-service markets because of its ease of use for non-technical threat actors and various plugin features. NanoCore is widely used today with ANY.RUN Trends\r\ndocumenting it as the 8th most-common malware strain in July 2022.\r\nAs a RAT, NanoCore is well-suited for providing initial access, stealing information, and spying on victims.\r\nHistorically, NanoCore’s remote access and spyware capabilities have been used to attack businesses, stalk\r\nvictims, and conduct espionage for nation-state groups¹. There are multiple NanoCore plugins which can be\r\npurchased (or stolen/cracked) from cyber-crime forums to add new features and capabilities — though\r\nNanoCore’s base payload is already capable of:\r\naccessing files\r\nexecuting programs\r\nstealing saved passwords\r\nlogging keystrokes\r\nand surveilling webcams\r\nNanoCore payloads are primarily controlled from a GUI installed on the threat actor’s computer. The GUI\r\nfunctions as both a payload builder and command-and-control panel. Using the GUI to create and operate\r\nNanoCore payloads requires limited technical knowledge as there is no shell involved and the interface provides\r\nguiding documentation. Once built and deployed, a threat actor can control single agents or an entire collection of\r\nbots from the panel.\r\nPress enter or click to view image in full size\r\nFigure 1: Experiments with NanoCore platform included builder configurations and traffic analysis.\r\nI downloaded cracked NanoCore platforms and used them to conduct experiments inside virtual machines. It’s\r\ndisturbing to see the “community” which forms around malware-as-a-service capabilities…\r\nCommand-and-Control Analysis\r\nhttps://medium.com/@the_abjuri5t/nanocore-rat-hunting-guide-cb185473c1e0\r\nPage 2 of 7\n\nAt start-up, a NanoCore payload will query the domain name of its assigned C2 (Command-and-Control) server\r\nand then attempt to use the answered IP address for all of its communications². NanoCore payloads are configured\r\nwith 8.8.8.8 as their primary DNS server and 8.8.4.4 as a backup. Some payloads are also configured with primary\r\nand secondary C2 domains — though in practice, many threat actors just list the same C2 twice.\r\nA NanoCore payload will then send an ‘introduction’ message to its C2 server with basic context about the\r\npayload configuration and the infected target host. Following an acceptance message from its C2 server,\r\nNanoCore will then begin sending a ‘heartbeat message’ to the C2 server in order to let the server know that the\r\npayload is still active and to request new tasks. NanoCore will encode these heartbeat messages to the C2 server\r\nas 0x00000600. Experiments show that NanoCore will send these heartbeat messages almost immediately after\r\nprocessing the C2’s response — leading to a stream of communication (unlike other RATs/agents which may only\r\ncommunicate once every several minutes). The generic heartbeat messages are interspersed with commands and\r\nrequests from the C2 server itself. Most often, these messages are automated requests for status updates though\r\nthey will also include commands initiated by the threat actor.\r\nPress enter or click to view image in full size\r\nFigure 2: PCAP of server DNS request, C2 introduction message, and encrypted heartbeat\r\nThe content of the messages sent from NanoCore to its C2 server will be encrypted using a custom protocol over\r\nTCP. NanoCore uses DES to encrypt the contents of its messages (curiously, the DES key and IV have the same\r\nvalue). The length of the message ciphertext is then appended to the front of the TCP data payload and sent to the\r\nC2 server. I wrote a CyberChef recipe to help explain NanoCore’s custom protocol and decrypt its messages.\r\nPress enter or click to view image in full size\r\nhttps://medium.com/@the_abjuri5t/nanocore-rat-hunting-guide-cb185473c1e0\r\nPage 3 of 7\n\nFigure 3: Debugging of NanoCore’s method for message encryption — including IV/Key values\r\nFor more analysis of NanoCore’s actual code, check-out the awesome reverse engineering conducted by\r\nand .\r\nNetwork Defenses\r\nSignature-Based Detection\r\nNanoCore’s encryption of its C2 communications makes PCAP analysis and signature mapping more difficult.\r\nThe custom protocol which NanoCore implements, however, inadvertently creates patterns that can be leveraged\r\nto develop network signatures³. There are a few DES Keys/IVs that have been hard-coded into NanoCore strains\r\nand are commonly used in different payloads — even those appearing to belong to unique threat actors. Accurate\r\nnetwork signature rules for tools such as Snort can be written to monitor for NanoCore’s heartbeat message, as\r\nencrypted by these common keys.\r\n# NanoCore ’heartbeat’ signature (0x00000600) encrypted by common key\r\nalert tcp any any -\u003e any any (msg:\"NanoCore ’heartbeat’ signature\";flags:PA;dsize:12;content:\"|08 00\r\nSeveral less-popular NanoCore strains have begun changing their DES Keys/IVs — making the encryption of the\r\nheartbeat message difficult to predict. The command-and-control messages from these rarer strains can still be\r\ndetected by taking-advantage of NanoCore’s custom protocol. In the protocol, the first 4 bytes of a TCP payload\r\nare used to encode the length of a message and the possible lengths are limited due to the protocol’s reliance on\r\nDES. NanoCore’s custom C2 messaging protocol can still be detected regardless of Key/IV by searching the first\r\n4 bytes of TCP data and matching the value to the message length.\r\nhttps://medium.com/@the_abjuri5t/nanocore-rat-hunting-guide-cb185473c1e0\r\nPage 4 of 7\n\n# NanoCore command-and-control custom message protocol\r\nalert tcp any any -\u003e any any (msg:\"NanoCore DES length 08\";flags:PA;dsize:12;content:\"|08 00 00 00|\"\r\nalert tcp any any -\u003e any any (msg:”NanoCore DES length 40\";flags:PA;dsize:68;content:\"|40 00 00 00|\"\r\nBy implementing these network signature rules into a monitoring tool such as Snort or Suricata, you will be\r\nalerted to an infected host sending NanoCore’s ‘introduction’ to the C2 server, the encrypted ‘heartbeat’, and all\r\nsubsequent communications which use its custom message protocol.\r\nGet John F’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nThe rules have been released publicly in my GitHub repository NanoCore-Hunting. Additionally, I strongly\r\nencourage you to monitor for incoming C2 traffic as well as outgoing. I have worked with cloud services, small\r\nbusinesses, and others in the past to help them take-down malicious C2 servers that they were unknowingly\r\nhosting. It is better to handle hosting abuse before your infrastructure is used to harm others.\r\nInfrastructure Blocking\r\nTraditional network blocking solutions can of course be used to deny access to NanoCore C2 servers — though\r\nthese methods require constant updating. With a DNS sinkhole deployed⁴, DNS requests from NanoCore can be\r\nanswered with an incorrect IP address to redirect NanoCore from its real C2 server — though this redirection is\r\nonly possible if the DNS sinkhole is configured with the payload’s domain name (for more information, see Palo\r\nAlto’s explanation of DNS sinkholes). Simple firewalls can also be deployed to block⁵ connection attempts to\r\nknown NanoCore IP addresses but again, this blocking solution only works if the C2 server’s address is known\r\nand added to the blocklist.\r\nThe following lists are based on the hundreds of recently-active NanoCore C2s I verified while researching the\r\nRAT. The lists likely do not include all active NanoCore C2s but they should block a decent amount of\r\nconnections.\r\nIP-list.txt domain-list.txt Indicators-of-Compromise.csv\r\nThose of you familiar with my SarlackLab project know that I track malicious infrastructure — not to look for\r\nspecific IOCs but to gather intelligence and get a better picture of the Internet threat landscape.\r\nMeta-Analysis of IOCs\r\nI set my malware analysis lab to collect and analyze thousands of NanoCore samples throughout the Spring and\r\nSummer of 2022. By analyzing network traffic generated during sample detonation and cross-referencing apparent\r\nC2 traffic with malware configuration extractors, I confirmed the existence of hundreds of NanoCore C2 servers.\r\nDomain Patterns\r\nhttps://medium.com/@the_abjuri5t/nanocore-rat-hunting-guide-cb185473c1e0\r\nPage 5 of 7\n\nI analyzed trends among the NanoCore C2 servers I had identified and uncovered patterns for server domains as\r\nwell as suspicious hosting providers. Almost all of the domain names I found are legible and do not appear to be\r\nhigh-entropy or randomized. Many of the Fully Qualified Domain Names (FQDNs) have the same second-level\r\ndomains (see Figure 4) — of which most appear to be tied to dynamic record and redirection services.\r\nPress enter or click to view image in full size\r\nFigure 4: Second-Level Domains of NanoCore C2 Domain Names\r\nThe second-level domains ddns[.]net, duckdns[.]org, hopto[.]org, bounceme[.]net, and 3utilities[.]com appeared in\r\nalmost 80% of all NanoCore FQDNs. The listed second-level domains are tied to Dynamic DNS services which\r\ntheir FQDNs appear to be utilizing. The service ngrok[.]io, however, is a distributed reverse proxy that is\r\ncommonly used as a network tunnel for hosting gaming servers or file shares — though it also has a history of\r\nabuse.\r\nDynamic DNS (abbreviated as DDNS) is built upon common Domain Name System (DNS) technology but uses s\r\nI have used DNS sinkholes to great effect in denying access from hosts to various C2 servers — regardless of how\r\nthreat actor modify their DNS or DDNS records. Personally, I recommend sinkholing⁴ DNS requests to all\r\nsubdomains of the identified infrastructure and authoritative DDNS servers, then only allowing specific FQDNs\r\nas-needed⁶. By configuring such a sinkhole, many NanoCore payloads will be unable to resolve the IP address of\r\nthe C2 server — even if the payload is attempting to connect to a novel subdomain, not yet identified as an IOC.\r\nPart 2 — TLP:GREEN\r\nThere is a second part to this command-and-control meta-analysis which is labeled TLP:GREEN. If you are\r\ninterested, contact me via Twitter and I will send you a copy of the research.\r\nhttps://medium.com/@the_abjuri5t/nanocore-rat-hunting-guide-cb185473c1e0\r\nPage 6 of 7\n\nHunting Summary\r\nNanoCore is a powerful remote access trojan that remains popular among cybercriminals today. To hunt-down\r\nNanoCore command-and-control communications in your network, look for the signature of its custom messaging\r\nprotocol (see published rules). You can of course attempt blocking individual IPs and sinkholing specific domains\r\n— but I recommend considering the overall trends of malicious traffic on the Internet and denying access to\r\ncommonly malicious infrastructure. Please contact me on Twitter, if you have any feedback or wish to contribute.\r\nSee Also\r\nOther work on NanoCore analysis (technical deep-dives). Config extractor. Other places to watch.\r\nFull break-down of IOCs available at https://github.com/Abjuri5t/Hunting-NanoCore/\r\nCyberChef recipe https://gchq.github.io/CyberChef/#recipe=…\r\nFootnotes\r\n[1] According to research compiled by MITRE ATT\u0026CK, groups back by nation-states have been attributed to the\r\nuse of NanoCore.\r\n[2] In my research, I found a couple of NanoCore payloads which used hard-coded IP addresses. The\r\noverwhelming trend among threat actors, however, appears to be relying on domain names because the hosting IP\r\naddresses may change.\r\n[3] I work for Vectra AI as a Network MDR Analyst. I honestly believe that network metadata and AI models (ya,\r\nI said it) are the best indicators of malicious activity in a network. That being said, signatures and IOCs are useful\r\nas part of a complete balanced b̶r̶e̶a̶k̶f̶a̶s̶t̶ defense. I wrote a Vectra custom model based on these IDS signatures\r\nwhich Recall customers can install.\r\n[4] When configuring your DNS sinkhole, remember to re-direct all DNS requests to your local server. Otherwise,\r\nNanoCore’s DNS requests will just go to 8.8.8.8 and the sinkhole will fail.\r\n[5] Make sure you log these connection attempts as well and consider setting an alert for them. Just because you\r\nhave blocked a C2 server does not mean that you have completely managed the threat.\r\n[6] Check your SIEM and/or firewall logs before applying these restrictions. Depending on how locked-down\r\nyour network is, you may accidentally block an important service that happens to be using ngrok or similar.\r\nSource: https://medium.com/@the_abjuri5t/nanocore-rat-hunting-guide-cb185473c1e0\r\nhttps://medium.com/@the_abjuri5t/nanocore-rat-hunting-guide-cb185473c1e0\r\nPage 7 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://medium.com/@the_abjuri5t/nanocore-rat-hunting-guide-cb185473c1e0" ], "report_names": [ "nanocore-rat-hunting-guide-cb185473c1e0" ], "threat_actors": [ { "id": "5d2bd376-fcdc-4c6a-bc2c-17ebbb5b81a4", "created_at": "2022-10-25T16:07:23.667223Z", "updated_at": "2026-04-10T02:00:04.705778Z", "deleted_at": null, "main_name": "GCHQ", "aliases": [ "Government Communications Headquarters", "Operation Socialist" ], "source_name": "ETDA:GCHQ", "tools": [ "Prax", "Regin", "WarriorPride" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775439064, "ts_updated_at": 1775826704, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/c018a93f0e1467fab7e3a6ba310ad34938a77400.pdf", "text": "https://archive.orkl.eu/c018a93f0e1467fab7e3a6ba310ad34938a77400.txt", "img": "https://archive.orkl.eu/c018a93f0e1467fab7e3a6ba310ad34938a77400.jpg" } }