{ "id": "bf9d2ca5-327a-41b0-839c-67c69f9cd07a", "created_at": "2026-04-06T00:06:27.086718Z", "updated_at": "2026-04-10T03:37:49.689893Z", "deleted_at": null, "sha1_hash": "42043389bc7cf3e03c7f7f309f9b708ead2bfee7", "title": "Analyzing Network Infrastructure as Composite Objects - DomainTools | Start Here. Know Now.", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 711839, "plain_text": "Analyzing Network Infrastructure as Composite Objects -\r\nDomainTools | Start Here. Know Now.\r\nBy Joe Slowik\r\nArchived: 2026-04-05 16:21:00 UTC\r\nIntroduction\r\nNetwork infrastructure is one of the primary observables associated with cyber intrusions. From IP addresses\r\nserving as scanning or reconnaissance infrastructure through domains functioning as command and control (C2)\r\nor exfiltration servers, network infrastructure forms a prerequisite for adversary operations. Viewed through\r\ntypical models such as the Lockheed-Martin Cyber Killchain, (shown below) network infrastructure observables\r\nfactor into nearly every stage of the intrusion lifecycle as either a critical dependency or an enabling factor.\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 1 of 14\n\nYet while commonly referred to and almost universally present, network infrastructure observables—specifically\r\ndomain names and IP addresses—are also frequently derided as atomic, minimally enriched items for defensive\r\npurposes. This paper will show that such a view is mistaken and misguided—but only if we expand our\r\nunderstanding of network infrastructure observables and their characteristics.\r\nA thorough examination of network observables shows differentiation between minimally enriched indicators and\r\ncomposite objects which enable more in-depth understanding and analysis. By adopting the latter view, a\r\nseemingly atomic object such as a domain name yields a number of linked observations, which enable further\r\nanalysis and pivoting. By following this methodology, defenders can use a relatively small set of observations to\r\nbuild a robust picture of adversary tendencies and unearth additional campaigns and adversary observations.\r\nIndicators and Atomic Objects\r\nInformation security operations live through the ingestion, analysis, and disposition of technical observations.\r\nFrequently called “indicators of compromise” (IOCs), these items are, in theory, composite objects consisting of\r\nobservations, descriptions, and metadata. Yet, in practice, “IOC” refers to a debased, diminished version of the\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 2 of 14\n\noriginal concept. Rather than containing built-in contextuality, IOCs instead are reduced to mere observables in\r\nisolation: an IP address, a domain name, and a hash value.\r\nWhile (debased) IOCs still drive much of everyday network security operations, they are increasingly derided by\r\nanalysts and industry representatives. Examples include calls to emphasize adversary behaviors over specific\r\ntechnical observations for defense or theoretical constructs such as the Pyramid of Pain representing the “staying\r\npower” of different types of observations.\r\nWhile these arguments are generally correct and insightful for improving the practice of information security, such\r\ndevelopments come with an implicit and often ignored cost. In a rush to embrace behavior-based, tactics-techniques-procedures (TTP) focused defense, the value of indicators and their nature may be left behind.\r\nA more thorough understanding of what exists within an indicator allows us to explore in greater detail the nature\r\nand basis for that indicator’s existence. Just as an atom, while representing the fundamental building block of\r\nmatter, contains subatomic particles that define its characteristics, the same is true for bare indicators. With further\r\nanalysis and enrichment, we can discover greater details and better understand these observations.\r\nNature of Network Infrastructure\r\nNetwork infrastructure observables are those artifacts related to intrusion events or adversary activity linked to\r\ndelivery, communication, control, and exfiltration, among other items. Although not exhaustive, examples of\r\nnetwork infrastructure observables include domain names, IP addresses, and SSL/TLS certificates. These items\r\nare interrelated as they pertain to aspects of the same overall communication scheme: an IP hosts a domain that\r\nuses an SSL/TLS certificate to encrypt traffic.\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 3 of 14\n\nAt first glance, these items appear to be unitary atomic indicators. As such, they would appear to require\r\nenrichment and context outside of themselves to have lasting, meaningful value for understanding adversary\r\nbehaviors and tendencies. However, further investigation of these items indicates a more complex nature with\r\nmultiple subcomponents and characteristics that identify these items, under proper analysis, as composite objects.\r\nAs shown in the updated image, infrastructure observables contain a wealth of data when properly analyzed and\r\nobserved. Extending the comparison to atoms made above, each type of network observable effectively “breaks\r\ndown” into a mixture of subcomponents. Understanding and analyzing these items, their relationships, and\r\npatterns of composition yields insights into adversary behaviors which extends and deepens the value of a “bare”\r\nnetwork indicator.\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 4 of 14\n\nDomain Names\r\nA domain name is a natural language, a human-readable item designed to reference a machine-focused IP address\r\nhosting content online. While content or services can be accessed simply through an IP address, domains facilitate\r\nthe process and allow for a certain degree of “branding” or uniqueness through their name.\r\nThe domain itself is not a unitary object, though. Instead, the domain consists of several components or\r\nidentifying metadata that can be used to “fingerprint” or gain further insight into the domain’s nature or creation.\r\nIn addition to any hosting information related to the domain and its use, covered below, the following items\r\nrepresent characteristics of a domain that analysts and defenders can leverage:\r\nDomain Registrar: To create and take ownership of a domain, an individual or entity needs to work\r\nthrough a registrar to secure a domain through one of the registries managing the desired Top Level\r\nDomain (TLD – e.g., “.com”). Registrars differ widely in pricing, client scrutiny, and other aspects. As a\r\nresult of these characteristics and infrastructure preferences, threat actors may prefer or primarily leverage\r\ncertain registrars over others for infrastructure creation.\r\nDomain Registrant: Domains are created by a given registrant. While this information was historically\r\nquite useful, as such information would include contact email addresses and other information that could\r\nbe used to fingerprint infrastructure creation, the increasing adoption of privacy protection services and the\r\nimpact of the European Union’s General Data Protection Regulation (GDPR) have greatly restricted such\r\ninformation at present. Nonetheless, commonality in privacy protection services across registrations can\r\nstill be a weak link to tie together various domains.\r\nName Server: Domain resolution to an IP address requires an authoritative name server in order to\r\ntranslate requests. Identifying name servers associated with registration—especially specific authoritative\r\nservers—can reveal patterns of infrastructure creation and adversary tendencies.\r\nDomain Naming Theme or Convention: In one of my previous posts, I described how actual domain\r\nname selection may be used to infer adversary intent as well as adversary tendencies. Threat actors must\r\npick something for a domain name, whether this is a randomly-generated string, an item matching a theme,\r\nor a name matching a target or campaign. Identifying these themes or conventions can be a surprisingly\r\nuseful mechanism to differentiate domain registrations and identify commonalities for an actor.\r\nThe totality of these above items defines a domain. Just as they are components that represent the domain, they are\r\nalso items that can be used to search for similarly-structured or created infrastructure. For example, an adversary\r\nmay consistently use the same combination of name server, registrar, and registration privacy protection service\r\nthat can enable pivoting and identification of additional adversary infrastructure.\r\nAs seen in the DomainTools Iris Investigate screenshot below, these items can be readily identified and used for\r\npivoting purposes.\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 5 of 14\n\nIP Addresses\r\nIP addresses are the identifying schema for Internet Protocol (IP) traffic and are used to designate specific\r\nmachines or servers to receive traffic. While domain names are not necessary for network communication, IP\r\naddresses are required for IP-based communication. An active, communicating domain will always be paired with\r\nan IP address, while an IP address need not have a related domain to ensure communication between hosts.\r\nWhile IP addresses are one of the most commonly seen indicators in CTI reporting, just like domains IP addresses\r\nhide multiple subcomponents that identify aspects of adversary tendencies and behaviors:\r\nHosting Provider: Adversaries must find reasonably private, non-attributable hosting for network\r\ninfrastructure. Options include any major cloud service providers from Amazon Web Services to\r\nDigitalOcean; smaller virtual private server (VPS) providers, or utilizing services such as CloudFlare to\r\nmask true hosting from monitoring parties.\r\nHosting Location: In addition to hosting providers, threat actors have a degree of choice over hosting\r\nlocation. Cloud, VPS, and other providers typically own infrastructure in various countries. Adversaries\r\ncan leverage location specificity for purposes ranging from avoiding potential geographic-based traffic\r\nfiltering to taking advantage of the legal system of the hosting country to maximize privacy or make\r\ndefender investigations more difficult.\r\nServer Type: Infrastructure still needs a system on which to run, and the choice of operating system (OS)\r\nand version can also be used to fingerprint adversary tendencies. Threat actors can decide between various\r\nflavors of Linux to different versions of Windows for the underlying OS. Identifying particular tendencies\r\n—especially related to exposed system services, described below—can reveal patterns of activity that can\r\nbe used to identify or disposition new infrastructure.\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 6 of 14\n\nServer Services: To function as a command and control (C2) or another node, a server must listen on some\r\nservice. The most direct and basic would be HTTP or HTTPS, in which we as defenders, can identify the\r\nweb server type, version, and, in the case of HTTPS, server SSL/TLS certificates (described further\r\nbelow). Identifying non-standard or atypical services, especially for unique or custom C2 frameworks, can\r\nfurther enable identification and tracking.\r\nTo illustrate the above concepts, the suspicious domain “adverting-cdn[.]com” is hosted on a dedicated server at\r\n213.252.246[.]23. Within DomainTools Iris Investigate, we can identify the IP address, hosting provider, and\r\nhosting location:\r\nUsing an internet scanning and enumeration tool such as Shodan, we can further investigate the server to identify\r\nservices and fingerprint the server’s OS:\r\nBased on the above, we can identify a suspicious-looking domain hosted using a specific service in Lithuania,\r\nexposing HTTP and SSH as well as HTTP over TCP 8000, and allowing us to fingerprint the server as a Debian\r\nLinux machine. Using this information, we could work to identify further infrastructure through both domain and\r\nserver characteristics.\r\nSSL/TLS Certificates\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 7 of 14\n\nFinally, adversaries (as well as most legitimate web services) frequently employ standard encryption using the\r\nSecure Sockets Layer (SSL) or Transport Layer Security (TLS) protocols. While adversaries can certainly use\r\ncustom encryption or encoding protocols for traffic, the ubiquity of SSL/TLS-wrapped communications and the\r\nlimited visibility into such communications for most organizations make the publicly-available standard both very\r\neffective and significantly cheap for threat actors to deploy.\r\nAs a form of public key cryptography, SSL/TLS encryption depends upon certificates for functionality.\r\nCertificates can be tracked through various data points, as they typically feature identifying information related to\r\nthe certificate owner, such as organization or location.\r\nCertificates can take various forms from self-signed, untrusted items to certificates created through free and\r\nunvetted services (such as Let’s Encrypt) or sources which perform some degree of vetting when issuing them.\r\nWhile resulting metadata will vary depending on the issuer and the certificate, there is a rich history in using\r\ncertificate characteristics to track adversary behavior, such as legacy APT28 or Fancy Bear certificate and\r\ninfrastructure activity.\r\nLooking at the suspicious domain european-who[.]com, we discover a free certificate associated with cPanel\r\nservices. As such, there is limited data to pivot off of although we can note the limited certificate information and\r\nuse of a free service to identify this as potentially suspicious, while the certificate hash value provides a way to\r\ntrack the use of this specific item.\r\nEven though in this case we have limited information for direct pivoting, just identifying the use of self-signed,\r\nbuilt-in cPanel certificates can be used to differentiate and identify further infrastructure discovered through\r\ndomain- or IP-based analysis. Identifying another network object with similar domain or IP characteristics that\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 8 of 14\n\nalso deploys similar SSL/TLS certificate creation tendencies can allow us to link infrastructure and begin\r\nunderstanding adversary behaviors.\r\nComposite Details and Pivoting\r\nIn addition to pivoting within different types of infrastructure characteristics, as shown in the diagram below,\r\nunderstanding of adversary infrastructure tendencies enables pivoting between items as well.\r\nIn this view, insight into domain creation can reveal infrastructure hosting tendencies, which can be leveraged to\r\nidentify additional domains. Or a persistent pattern in SSL/TLS certificate creation yields additional domains\r\nwhich in turn map to additional infrastructure.\r\nHowever, while the discovery of new indicators is enticing and potentially useful for defense, this represents an\r\nintermediate objective as part of a larger process. Instead of merely attempting to identify more IOCs, cyber threat\r\nintelligence (CTI) analysts should leverage this work as a means to identify fundamental adversary tendencies\r\nwhich can be used to continuously identify and disclose infrastructure over time. Indicators will certainly be\r\nproduced through this work, but they represent an output of a more fundamental process of identifying and\r\nobserving ground-truth adversary behaviors in creating network infrastructure.\r\nExample: Late 2020 Ryuk Activity\r\nTo see an example of the above, we can look at the recent episode of Ryuk ransomware incidents across multiple\r\nhospital and health care provider systems in the United States, linked to a group referred to as UNC1878 by\r\ninformation security company FireEye. While utilizing malware and droppers such as BazarLoader and\r\nBazarBackdoor, Ryuk deployers still required C2 infrastructure to control and further expand infections in victim\r\nenvironments. Based on information released by FireEye and Kyle Ehmke from ThreatConnect, and confirmed by\r\nmultiple additional parties, the UNC1878 network infrastructure activity encompassed several hundred domains\r\ncreated from summer 2020 through October 2020. (Please see the linked file for IOCs.)\r\nWhile seemingly overwhelming, the above domains contained a number of commonalities:\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 9 of 14\n\n1. Similar registration patterns used over time.\r\n2. Preference for a limited number of hosting providers.\r\n3. Consistency in SSL/TLS certificate characteristics.\r\nFor example UNC1878-linked domain “drive-boost[.]com” features the following characteristics:\r\nBreaking these observables down, we see the following:\r\nUse of consistent naming “theme” reflecting IT-related concepts or items (e.g., “driver”).\r\nUse of the Namecheap registrar.\r\nConsistent use of WhoisGuard privacy protection service.\r\nConsistent use of registrar-servers[.]com DNS server.\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 10 of 14\n\nWhile the above items individually are quite common, taken together they allow us to begin filtering likely related\r\nitems. Looking at hosting ISP patterns, shown above in a DomainTools Iris Investigate visualization, reveals\r\nadditional characteristics—namely four distinct “waves” or series of activity centered around the following\r\nproviders:\r\nPrivate Layer Inc., located in Switzerland.\r\nPsychz Networks, located in the United States.\r\nFrantech Solutions, located in the United States.\r\nCombahton GmbH, located in Germany.\r\nNow we have a better way of clustering known activity, and potentially identifying new, similar items. But even\r\nfurther options exist within a subset of domains that feature an existing SSL/TLS certificate. For example, looking\r\nat “driver-boosters[.]com” shows the following certificate information:\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 11 of 14\n\nIn this case, we see a certificate pattern using a Locality Name of “Texas” and an Organization Name of “lol” for a\r\nself-signed certificate. Diving into certificate information yields over 100 items which, when looked at in\r\nconjunction with other items documented above, allows for high confidence attribution to UNC1878 activity.\r\nThrough this process, we have identified a set of characteristics denoting UNC1878 infrastructure. This can be\r\nused both for post-incident attribution to determine what entity may be responsible for a breach. Additionally, such\r\nmethodologies can be used through datasets such as DomainTools and search tools such as Iris Investigate to\r\nproactively and preemptively identify infrastructure as it is created. In this fashion, CTI becomes more attuned to\r\nadversary tendencies and characteristics while also enabling more direct, proactive support to network defense\r\noperations through continuous identification of adversary infrastructure.\r\nConclusion\r\nWhile network infrastructure indicators and observables are typically viewed as atomic objects, seeing these items\r\nas composites enables powerful analysis able to keep pace with adversary evolution. By understanding the\r\nfundamental nature of items such as domain names, IP addresses, and SSL/TLS certificates, analysts can begin\r\nunderstanding fundamental adversary tendencies and tradecraft. When done well, such actions enable defenders to\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 12 of 14\n\nnot only accurately disposition new infrastructure as it is discovered, but also to identify new infrastructure as it is\r\ncreated to boost defensive operations.\r\nWhile this process can be quite powerful in identifying and tracking adversary operations, we must also note\r\nlimitations to this methodology. For example, adversaries may leverage compromised, legitimate infrastructure for\r\ncommunications and similar activity in order to hide their tracks and confuse analysis. This is an increasing trend\r\nfor many threat actors, which can throw off analytical techniques such as those described above. However, even in\r\nthese cases, possibilities exist such as identifying underlying server or software commonalities which may be\r\nindicative of a vulnerability exploited to gain access to the legitimate server. These commonalities can enable\r\nsimilar types of pivoting to what was discussed previously with respect to adversary-owned-and-operated\r\ninfrastructure.\r\nBy viewing indicators as not just isolated objects but as composites containing multiple components that can be\r\nused to better understand the nature, purpose, and composition of the indicator, CTI analysts can unlock a greater\r\nunderstanding of adversary operations. Furthermore, while this article is limited to network observables, the same\r\nfundamental concepts are equally applicable to host and file-based indicators as well. By further refining,\r\nresearching, and enriching indicators, CTI analysts can continuously push the envelope of threat understanding\r\nand threat detection, enabling both a better understanding of past events and potential identification of new threat\r\nvectors from known adversaries as they emerge.\r\nTo learn how to identify and track adversary operations in DomainTools with Iris Investigate, visit our product\r\npage.\r\nLearn More\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 13 of 14\n\nSource: https://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nhttps://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects\r\nPage 14 of 14", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://www.domaintools.com/resources/blog/analyzing-network-infrastructure-as-composite-objects" ], "report_names": [ "analyzing-network-infrastructure-as-composite-objects" ], "threat_actors": [ { "id": "12211366-1f14-4eed-9d91-46b6a2ede618", "created_at": "2025-08-07T02:03:25.014713Z", "updated_at": "2026-04-10T02:00:03.624097Z", "deleted_at": null, "main_name": "GOLD ULRICK", "aliases": [ "Grim Spider ", "UNC1878 " ], "source_name": "Secureworks:GOLD ULRICK", "tools": [ "Bloodhound", "Buer Loader", "Cobalt Strike", "Conti", "Diavol", "PowerShell Empire", "Ryuk", "SystemBC", "Team9 (aka BazarLoader)", "TrickBot" ], "source_id": "Secureworks", "reports": null }, { "id": "ab9d6b30-7c60-4d0b-8f49-e2e913c28508", "created_at": "2022-10-25T16:07:24.584775Z", "updated_at": "2026-04-10T02:00:05.042135Z", "deleted_at": null, "main_name": "UNC1878", "aliases": [], "source_name": "ETDA:UNC1878", "tools": [ "Agentemis", "BEERBOT", "BazarBackdoor", "BazarCall", "BazarLoader", "Cobalt Strike", "CobaltStrike", "KEGTAP", "Ryuk", "Team9Backdoor", "bazaloader", "cobeacon" ], "source_id": "ETDA", "reports": null }, { "id": "0a4f4edc-ea8c-4a30-8ded-35394e29de01", "created_at": "2023-01-06T13:46:39.178183Z", "updated_at": "2026-04-10T02:00:03.23716Z", "deleted_at": null, "main_name": "UNC1878", "aliases": [], "source_name": "MISPGALAXY:UNC1878", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "63061658-5810-4f01-9620-7eada7e9ae2e", "created_at": "2022-10-25T15:50:23.752974Z", "updated_at": "2026-04-10T02:00:05.244531Z", "deleted_at": null, "main_name": "Wizard Spider", "aliases": [ "Wizard Spider", "UNC1878", "TEMP.MixMaster", "Grim Spider", "FIN12", "GOLD BLACKBURN", "ITG23", "Periwinkle Tempest", "DEV-0193" ], "source_name": "MITRE:Wizard Spider", "tools": [ "TrickBot", "AdFind", "BITSAdmin", "Bazar", "LaZagne", "Nltest", "GrimAgent", "Dyre", "Ryuk", "Conti", "Emotet", "Rubeus", "Mimikatz", "Diavol", "PsExec", "Cobalt Strike" ], "source_id": "MITRE", "reports": null }, { "id": "730dfa6e-572d-473c-9267-ea1597d1a42b", "created_at": "2023-01-06T13:46:38.389985Z", "updated_at": "2026-04-10T02:00:02.954105Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "Pawn Storm", "ATK5", "Fighting Ursa", "Blue Athena", "TA422", "T-APT-12", "APT-C-20", "UAC-0001", "IRON TWILIGHT", "SIG40", "UAC-0028", "Sofacy", "BlueDelta", "Fancy Bear", "GruesomeLarch", "Group 74", "ITG05", "FROZENLAKE", "Forest Blizzard", "FANCY BEAR", "Sednit", "SNAKEMACKEREL", "Tsar Team", "TG-4127", "STRONTIUM", "Grizzly Steppe", "G0007" ], "source_name": "MISPGALAXY:APT28", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "id": "e3767160-695d-4360-8b2e-d5274db3f7cd", "created_at": "2022-10-25T16:47:55.914348Z", "updated_at": "2026-04-10T02:00:03.610018Z", "deleted_at": null, "main_name": "IRON TWILIGHT", "aliases": [ "APT28 ", "ATK5 ", "Blue Athena ", "BlueDelta ", "FROZENLAKE ", "Fancy Bear ", "Fighting Ursa ", "Forest Blizzard ", "GRAPHITE ", "Group 74 ", "PawnStorm ", "STRONTIUM ", "Sednit ", "Snakemackerel ", "Sofacy ", "TA422 ", "TG-4127 ", "Tsar Team ", "UAC-0001 " ], "source_name": "Secureworks:IRON TWILIGHT", "tools": [ "Downdelph", "EVILTOSS", "SEDUPLOADER", "SHARPFRONT" ], "source_id": "Secureworks", "reports": null }, { "id": "ae320ed7-9a63-42ed-944b-44ada7313495", "created_at": "2022-10-25T15:50:23.671663Z", "updated_at": "2026-04-10T02:00:05.283292Z", "deleted_at": null, "main_name": "APT28", "aliases": [ "APT28", "IRON TWILIGHT", "SNAKEMACKEREL", "Group 74", "Sednit", "Sofacy", "Pawn Storm", "Fancy Bear", "STRONTIUM", "Tsar Team", "Threat Group-4127", "TG-4127", "Forest Blizzard", "FROZENLAKE", "GruesomeLarch" ], "source_name": "MITRE:APT28", "tools": [ "Wevtutil", "certutil", "Forfiles", "DealersChoice", "Mimikatz", "ADVSTORESHELL", "Komplex", "HIDEDRV", "JHUHUGIT", "Koadic", "Winexe", "cipher.exe", "XTunnel", "Drovorub", "CORESHELL", "OLDBAIT", "Downdelph", "XAgentOSX", "USBStealer", "Zebrocy", "reGeorg", "Fysbis", "LoJax" ], "source_id": "MITRE", "reports": null }, { "id": "d2516b8e-e74f-490d-8a15-43ad6763c7ab", "created_at": "2022-10-25T16:07:24.212584Z", "updated_at": "2026-04-10T02:00:04.900038Z", "deleted_at": null, "main_name": "Sofacy", "aliases": [ "APT 28", "ATK 5", "Blue Athena", "BlueDelta", "FROZENLAKE", "Fancy Bear", "Fighting Ursa", "Forest Blizzard", "G0007", "Grey-Cloud", "Grizzly Steppe", "Group 74", "GruesomeLarch", "ITG05", "Iron Twilight", "Operation DealersChoice", "Operation Dear Joohn", "Operation Komplex", "Operation Pawn Storm", "Operation RoundPress", "Operation Russian Doll", "Operation Steal-It", "Pawn Storm", "SIG40", "Sednit", "Snakemackerel", "Sofacy", "Strontium", "T-APT-12", "TA422", "TAG-0700", "TAG-110", "TG-4127", "Tsar Team", "UAC-0028", "UAC-0063" ], "source_name": "ETDA:Sofacy", "tools": [ "ADVSTORESHELL", "AZZY", "Backdoor.SofacyX", "CHERRYSPY", "CORESHELL", "Carberp", "Computrace", "DealersChoice", "Delphacy", "Downdelph", "Downrage", "Drovorub", "EVILTOSS", "Foozer", "GAMEFISH", "GooseEgg", "Graphite", "HATVIBE", "HIDEDRV", "Headlace", "Impacket", "JHUHUGIT", "JKEYSKW", "Koadic", "Komplex", "LOLBAS", "LOLBins", "Living off the Land", "LoJack", "LoJax", "MASEPIE", "Mimikatz", "NETUI", "Nimcy", "OCEANMAP", "OLDBAIT", "PocoDown", "PocoDownloader", "Popr-d30", "ProcDump", "PythocyDbg", "SMBExec", "SOURFACE", "SPLM", "STEELHOOK", "Sasfis", "Sedkit", "Sednit", "Sedreco", "Seduploader", "Shunnael", "SkinnyBoy", "Sofacy", "SofacyCarberp", "SpiderLabs Responder", "Trojan.Shunnael", "Trojan.Sofacy", "USB Stealer", "USBStealer", "VPNFilter", "Win32/USBStealer", "WinIDS", "Winexe", "X-Agent", "X-Tunnel", "XAPS", "XTunnel", "Xagent", "Zebrocy", "Zekapab", "carberplike", "certutil", "certutil.exe", "fysbis", "webhp" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775433987, "ts_updated_at": 1775792269, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/42043389bc7cf3e03c7f7f309f9b708ead2bfee7.pdf", "text": "https://archive.orkl.eu/42043389bc7cf3e03c7f7f309f9b708ead2bfee7.txt", "img": "https://archive.orkl.eu/42043389bc7cf3e03c7f7f309f9b708ead2bfee7.jpg" } }