[Q2 2026 | Intelligence Report] Global Threat Infrastructure Trends

The SANDS Lab Threat Analysis Team publishes a quarterly intelligence report based on collected information.

We aim to create a safer cyberspace by sharing malware characteristics, threat trends, and related intelligence identified through expert analysis.

More detailed information is available through the cyber threat intelligence service <CTX>.

1. Summary

The previous quarter’s report focused on moving beyond simple IoC lists. IP addresses and domains change quickly, but metadata repeatedly left behind during infrastructure operations persists longer. Certificates, ports, URIs, ASNs, time zones, and C2 communication structures provide clues that outlast simple blocklists. Building on that perspective, this report focuses more closely on the infrastructure attackers select and how they operate it.

The Q2 data continues this theme. Threat infrastructure has not disappeared; it has moved deeper within legitimate services. ClearFake and ClickFix were detected in large numbers on Cloudflare and major cloud/shared hosting platforms, using aged domains and compromised web assets to bypass reputation-based blocking. This does not justify labeling any particular provider as malicious. The practical challenge is deciding how to distinguish legitimate business traffic from malicious campaign traces when both share the same service environment.

Lifecycle analysis leads to the same conclusion. The median lifecycle of all IoCs is short, but not every threat ends quickly. Some IoCs are exhausted immediately after detection, while some campaigns persist or cycle between active and dead states. The key question is therefore not how often something was seen, but whether it remains within the response scope, could reactivate, or repeats the same infrastructure fingerprint.

Accordingly, this report is not centered on individual attack tools. A more meaningful axis is which providers attackers repeatedly choose for which roles. Cloudflare illustrates malicious payloads and redirects mixed into a legitimate CDN, while Hostinger, Hetzner, Railnet, and Namecheap infrastructure calls for responses to payload delivery and active C2/backends. ASNs associated with Alibaba, Tencent, and Yancy showed high concentrations of C2/framework threat tags. Distinguishing abuse roles and response priorities by provider offers more intelligence value than merely comparing detection volumes.

Provider selection ultimately reflects the C2 operating model. Rather than putting all C2 functions on one server, attackers separate payload delivery, configuration delivery, command and control, upload/exfiltration, and fallback-route candidates, choosing services suited to each role. CDNs and aged domains are used for accessibility and reputation-based concealment, self-service hosting for rapid replacement and payload delivery, and certain regional cloud ASNs for core control infrastructure.

The Analyst’s Pick—a developer-targeting JavaScript C2 case linked to North Korean actors—illustrates this trend particularly clearly. The important point is not a single IP address, but the connection between the developer workflow trust chain, SaaS-based configuration delivery, Socket.IO/WebSocket control, and upload/exfiltration channels within one operational structure. Validation headers, host metadata fields, and combinations of Node.js dependencies can persist after servers change and provide a basis for file and network-packet detection.

This report aims to turn collected threat clues into criteria defenders can use operationally. Immediately blockable active C2/backends and campaign-evidenced IoCs should be separated promptly, while IoCs on clouds, CDNs, or shared hosting with significant business impact should be managed for review. ASN/provider profiles, C2 operating models, URI/header combinations, SPKI/ASN_Port, and file artifacts should remain long-term hunting signals. The value of analysis lies in extracting detection logic that defenders can operate even as infrastructure changes.

2. Overview

To support real defense, an intelligence report must do more than enumerate collected IoCs. Understanding how attackers build infrastructure, repeatedly select services, and leave traces matters more than knowing many endpoints that have already been neutralized.

This report is based on 59,833 IoCs collected from March 1 through June 15, 2026. The analysis goes beyond individual IoCs to examine providers, ASNs, countries, threat tags, URI paths, ports, TLS/SPKI fingerprints, lifecycles, and cluster evidence.

The data divides threat infrastructure into two categories. One comprises active C2/backends and payload delivery infrastructure requiring immediate blocking. The other is shared infrastructure abuse intertwined with legitimate services, where provider-wide blocking is difficult. Treating both alike undermines defensive policy: broad blocklisting disrupts business, while review alone can miss active C2.

We therefore prioritize criteria for defensive decisions over collection volume. Infrastructure is reclassified by current activity, reactivation potential, overlap with legitimate services, recurring fingerprints, and attackers’ preferred providers and C2 operating models. The following sections cover infrastructure distribution, provider-specific abuse, preferred C2 operations, operating hours, evasion patterns, SPKI-based campaign connections, the Analyst’s Pick, and actionable defensive outputs.

3. Q2 2026 Ecosystem

3.1. Attack Infrastructure Inside Legitimate Services

Attack infrastructure is no longer confined to low-trust hosting. It has moved into legitimate services that defenders cannot readily block. Cloudflare and major cloud/shared hosting platforms have been repeatedly abused for payload delivery, redirection, and campaign deployment. The defensive question must shift from whether to block frequently observed providers to how to distinguish malicious campaigns mixed into legitimate services.

CLOUDFLARENET is central to this pattern. It accounted for 26,213 IoCs by ASN-role/tag, the largest provider share. ClearFake appeared 18,644 times (71.1%), ClickFix 2,081 times, and Vidar 1,108 times. By ASN-role, payload delivery dominated with 22,549 cases (86.0%). These figures do not establish Cloudflare as attack infrastructure; they warn that legitimate services and malicious delivery coexist on shared infrastructure.

Cloudflare-related IoCs are therefore better placed on a shared-infrastructure review list than a blocklist. Detection conditions should be narrowed using URIs, Host headers, certificates, threat tags, and current status together. Blocking a large provider as a whole can cause outages through false positives.

3.2. ClearFake and ClickFix Persist After Detection

ClearFake and ClickFix were the most frequently observed campaigns, but treating them only as high-volume cases misses an important point. Shared infrastructure and aged domains kept them within the response scope long after detection. They require continued status checks and historical-log review, rather than one-time blocking.

Across the quarter, tags identified 15,535 ClearFake and 10,648 ClickFix cases. ClearFake had 9,993 active cases, an active ratio of 64.33%; ClickFix had 8,123, or 76.29%. Median MTTD (Mean Time To Death) was also long: 1,289 and 1,489.7 hours respectively. Both campaigns thus remain response targets after detection. They should be managed through shared-infrastructure review, revalidation of active domains/URIs, and retrospective hunting combining certificates and URI structures, rather than simply discarding IoCs after a single use.

3.3. IoCs Expire; Fingerprints Persist

Lifecycle metrics require particular care. The overall median is short, at approximately 0.35 days, which alone might suggest most IoCs quickly lose value. Yet SPKI reuse over the same period was 40.47%, and 115 of 128 strategic hunting signatures were SPKI-based. Endpoints disappear quickly, while certificates and deployment traces recur.

Defenders should treat these separately. IP- and domain-based blocklists need short TTLs, while combinations of SPKI, communication patterns, URIs, and headers should remain long-term hunting signals. IoCs die quickly, but infrastructure fingerprints persist.

3.4. Infrastructure Choices Reveal More Than Attack Tools

The data shows which providers are repeatedly abused for which roles more clearly than which tools are prevalent. Cloudflare requires review for payloads and redirects mixed into its legitimate CDN. Hostinger and Namecheap frequently yield blocklist entries for ClickFix-focused payload delivery. Hetzner and Railnet combine payload delivery with botnet/C2 roles requiring current response, while Alibaba/Tencent/Yancy infrastructure shows concentrations of C2/framework tags on particular ASNs.

From this perspective, tools serve as clues to provider-specific abuse rather than independent topics. Yancy Limited’s botnet_cc role was nearly 100%, with C2/framework tags at 96.2%; Hangzhou Alibaba and Shenzhen Tencent also predominantly had botnet_cc roles and high concentrations of C2/framework tags. Cloudflare, DigitalOcean, Vultr, and Amazon, by contrast, should be treated as shared infrastructure mixing legitimate services and malicious campaigns. The main hunting axis combines ASN/provider roles, tag concentration, active status, and abuse patterns rather than tools alone.

3.5. View C2 as an Operating Model, Not a Server

C2 infrastructure follows a division-of-roles model rather than relying on one server for every function. Payload delivery, redirection, configuration delivery, command and control, upload/exfiltration, and fallback-route candidates are deployed across different environments. Attackers select services for each function, and defenders should interpret the combination as one C2 operating model.

Within this model, Cloudflare and aged domains support concealment and payload delivery through legitimate-service trust; Hostinger, Namecheap, Hetzner, and Railnet support delivery and active servers; Alibaba/Tencent/Yancy infrastructure is closer to core control with high C2/framework concentrations. The North Korean JavaScript C2 case qualitatively demonstrates the same logic through separate Vercel configuration delivery, Git hook/precommit configuration, potential terminal/API connections, Socket.IO/WebSocket control, and upload/exfiltration channels.

3.6. Analyst’s Pick: Connecting Developer Workflows to C2

The Analyst’s Pick is not a high-volume campaign; its numbers are smaller than the major campaigns above. It warrants separate attention because developer workflows connect directly to C2 operations. It shows how legitimate development environments, SaaS-based configuration delivery, Git hook/precommit flows, potential terminal/API connections, and a sample-confirmed C2 backend can form a single attack path.

Cluster 2046 contains 46 IoCs, 76 activity records, and 4 SPKIs. Its rare tags concentrate on North Korea-related labels: ‘contagiousinter view’, ‘lazarus’, ‘web3-targeting’, and ‘novara1o1’. Roles can be distinguished among Vercel-based OS-specific configuration endpoints, the ‘precommit.ver cel.app’ Git hook/precommit config, the potential ‘lab99.sbs /api/terminal/*’ terminal/API connection segment, ROUTERHOSTING backend pivot candidates, and the statically confirmed ‘216.126.225.243:8087’ Socket.IO/WebSocket control channel and ‘8085 /8086’ upload/exfiltration channels. The key is the communication method and division of C2 roles, rather than the IoCs alone.

4. Infrastructure Distribution and Provider-Specific Abuse

4.1. Why IoCs Concentrate on Particular Providers

Provider distribution is more than a market-share ranking: it indicates where attackers obtain legitimate-service trust and operational convenience. Leading entries include CDN/shared infrastructure such as Cloudflare, public clouds such as DigitalOcean/Vultr/Amazon, self-service hosting such as Hostinger/Namecheap, and VPS or regional cloud ASNs associated with Hetzner/Railnet/Yancy/Alibaba/Tencent. Blocking, review, and hunting criteria should vary according to the provider on which an IoC was observed.

[Table 1] IoC distribution across leading infrastructure providers

[Figure 1] Threat composition by ASN across leading providers

Cloudflare’s dominant share does not mean it supplies many direct blocking candidates. It indicates a growing overlap between legitimate services and malicious campaigns on the same infrastructure. The attached shared-infrastructure review list contains 32,448 entries, including 26,209 for CLOUDFLARENET alone. Defensive policy should therefore isolate evidence of malicious campaigns within prevalent shared infrastructure instead of blocking frequently observed ASNs. For Cloudflare, DigitalOcean, Vultr, and Amazon, precise review combining Host headers, URIs, certificates, tags, and activity status takes priority over provider-wide blocking.

4.2. Combining ASN and Tags Reveals Roles

ASN/tag combinations do not establish that a provider is malicious. They reveal recurring campaigns or C2 activity within a provider and translate those patterns into blocking, review, and hunting criteria. Higher concentrations suggest repeated use of the infrastructure’s characteristics. The strongest combinations are shown below. Percentages represent a tag’s share of that provider’s IoCs, not of the entire dataset.

[Table 2] Key ASN/tag combinations and proportions

[Figure 2] Concentration of key ASN/tag combinations

The important point is the pattern of association, not individual tool names. ClearFake, ClickFix, and Vidar recur within Cloudflare’s CDN/shared infrastructure, while Hostinger and Namecheap show strong ClickFix payload-delivery patterns. Concentrated cobaltstrike tags at Yancy, Hangzhou Alibaba, and Shenzhen Tencent are better interpreted as C2/framework activity concentrating on certain ASNs than as an issue with one tool. These combinations should become hunting conditions incorporating SPKI, ports, TLS activity, and URI/Host information, rather than independently determining provider-wide blocking.

4.3. Abuse Differs by Provider

The appropriate defense depends on whether an IoC resides in a CDN/shared environment, self-service hosting, a cloud region, or a VPS provider. This section groups leading providers by the characteristics attackers exploit and separates blocking, review, and hunting criteria. ASNs/providers should be interpreted as infrastructure selected for operations, not merely ownership information.

[Table 3] Provider-specific abuse types and response criteria

This is not intended to label any provider a malicious business. The intelligence question is which provider characteristics attackers repeatedly exploit. Free trials or credits, self-service signup, abuse-report response speed, KYC standards, CDN/proxy features, and automated VPS provisioning require separate OSINT validation as supporting context. Most providers prohibit abuse in their public terms, so conclusions should not be drawn lightly.

[Figure 3] Threat-type distribution across leading providers

4.4. C2 Operations Are Divided by Function

The more important question is how attackers operated C2, rather than which C2 servers existed. Observed patterns combine divided roles, reputation-based concealment, rapid replacement, and reused fingerprints instead of relying on a single server. The items below describe operational traces defenders should identify in security and network logs, not instructions for reproducing an attack.

[Table 4] Observed signals and defensive value by C2 operating model

Attackers’ preferred approach can be summarized as delivering payloads where concealment is easy, operating on easily replaced infrastructure, and concentrating core control on particular ASNs/regions when needed. Defenders should therefore connect IoC blocking, precise shared-infrastructure review, ASN/provider monitoring, and SPKI/URI/header hunting within one C2 operating model rather than treating them as separate tasks.

4.5. Infrastructure Roles Matter More Than Countries

By country, the United States led with 9,010 cases, followed by Germany (2,577), the Netherlands (2,300), China (1,995), and Hong Kong (1,797). Geography should distinguish infrastructure roles, not establish attacker attribution. The US combined 6,644 Other/Uncategorized and 1,798 Core C2 Framework cases, resembling a large shared-cloud environment mixing legitimate traffic and malicious campaigns. China and Hong Kong had high Core C2 Framework shares of 54.84% and 56.59%, warranting attention for core control roles rather than traffic volume alone. Singapore’s share was also high, at 47.8%.

[Figure 4] Stacked distribution of infrastructure roles by country

[Figure 5] Concentration of infrastructure roles by country

5. Lifecycles: Short-Lived IoCs and Lasting Traces

5.1. Distinguish Short-Lived and Persistent IoCs

The median IoC lifetime is approximately 0.35 days and the mean approximately 5.54 days. These figures alone suggest most IoCs are consumed very quickly. Breaking down MTTD (Mean Time To Death) by tag, however, reveals a different picture.

[Table 5] Lifecycle and dead ratios for major tags

[Figure 6] MTTD and activity status for major tags

ClearFake, ClickFix, StrelaStealer, and QuasarRAT tend to persist, while Mozi, Kimwolf, Aisuru, and Metasploit are more often short-lived or neutralized soon after detection. Some C2 frameworks include exceptionally persistent instances that substantially increase the mean despite short medians. Rather than discarding IoCs based only on the median, defenders should check for recurring SPKI and infrastructure fingerprints and retain them for long-term hunting.

5.2. Aged Domains Complicate Blocking

Among 19,032 domain-creation records, Aged (>1y) was the largest group at 13,550, followed by Intermediate at 3,144 and Fresh (0–1d) at 2,338. There were 9,516 unique domains.

[Table 6] Distribution by domain creation age

[Figure 7] Time between domain creation and malicious activity

The first point is not the sizable Fresh (0–1d) group, but the 71.2% share of Aged (>1y). Newly registered domains remain useful for early blocking and alert prioritization, yet malicious activity here was not confined to new domains. Of 19,032 records, 13,550 involved domains older than a year; 6,775 unique domains were also Aged. Policies that downgrade risk solely on creation date can miss large campaigns such as ClearFake and ClickFix.

The chart shows a distinct bar in the Fresh range of one day or less, but its greater weight lies to the right among older domains. Records exceeding 10,000 days total 8,660, or 45.5%. Attackers do not always register new domains: they can abuse longstanding legitimate domains, compromised web assets, or paths and subdomains beneath aged parent domains. Reputation and creation-date filters alone cannot reliably separate malicious delivery and redirects in these cases.

Tag distributions support this conclusion. Across 5,908 unique ClearFake domains, the median age was 11,494 days, and 81.1% of records were Aged. ClickFix had 1,029 unique domains, a median of 1,153 days, and an Aged share of 69.3%. StrelaStealer, QuasarRAT, and RemcosRAT also had long right-tailed distributions, confirming abuse of older domains. Some Vidar and CobaltStrike instances were more concentrated in intermediate ages, so domain age needs campaign-specific interpretation.

The chart ultimately challenges the assumption that old domains are safe. New domains should be managed as rapid-blocking candidates, but old domains must not automatically be trusted. Review should combine URI, Host header, redirection structure, tags, certificates, and provider context. For campaigns such as ClearFake and ClickFix using paths that resemble legitimate web resources, actual request paths and campaign traces are more useful decision criteria.

5.3. Activity Changes Indicate Reactivation Potential

Tag-expanded activity records included 32,054 [D]Unstable, 16,122 [E]Mixed, 12,560 [C]Heartbeat, 12,145 [A]AlwaysOn, and 613 [B]OfficeWorker cases. Unstable or mixed infrastructure cycling between active and inactive states is therefore more common than continuously active infrastructure. Tofsee, WordPress, EtherHiding, Polygon, compromised, Vidar, and ClickFix showed frequent transitions. ClickFix had a mean of 14.29 transitions and a median of 15.0 across 10,261 records. This is more naturally interpreted as recurring activity changes in compromised web infrastructure and shared hosting than as simple network errors.

[Figure 8] Activity transitions and lifecycle patterns by tag

6. Detection Evasion and Communication Patterns

6.1. Port Changes Are Operational Traces

Overall port reuse was high at 95.91%, but some tags clearly rotated across a broad range of nonstandard ports. How often ports change during operation matters more than simply identifying the ports used.

[Figure 9] Unique port counts and nonstandard-port shares by tag

[Table 7] Nonstandard-port usage by tag

Read the chart relative to the 1:1 baseline. Tags to its right use nonstandard ports more often than standard ports. The ratios were 96.00 for aisuru, 84.67 for tofsee, and 80.67 for kimwolf; metasploit, antidot, vshell, and adaptixc2 also relied heavily on nonstandard ports. Reviewing only web traffic on 80/443 is insufficient. Firewall, proxy, and NDR data should be checked for outbound nonstandard-port connections, protocol mismatches, and new ASN/port combinations.

[Figure 10] Unique port usage ratios by tag

This chart combines nonstandard-port share with unique port count. In the upper right, mozi, vshell, metasploit, and adaptixc2 have both high nonstandard usage and wide port ranges. Mozi has no standard-port records, preventing calculation in the preceding ratio chart, but the scatterplot shows all 536 IoCs on nonstandard ports, spanning 517 unique ports. Rather than blocking one port, analysis should combine tags, ASNs, protocols, connection direction, and recurring port-generation patterns.

Cobaltstrike, remcosrat, asyncrat, and quasarrat need a different reading. Their nonstandard-port shares are lower than vshell or metasploit, but their unique nonstandard-port counts are high. Cobaltstrike had 1,737 nonstandard-port IoCs out of 4,240, covering 228 unique nonstandard ports. Remcosrat had 771 such IoCs and 377 unique nonstandard ports. They are better understood as C2/framework families spreading infrastructure broadly across both standard and nonstandard ports, rather than relying primarily on the latter.

High-volume tags such as clearfake, clickfix, strelastealer, and vidar cluster at the bottom of the scatterplot. They rely strongly on standard web ports such as 80/443 and have low nonstandard usage, so port-based detection provides little distinction. Aged domains, legitimate-looking URIs, Host headers, certificates, and redirection structures are more valuable hunting axes.

Port analysis therefore requires tag-specific responses. Nonstandard-heavy activity should be prioritized in firewall, proxy, and NDR logs, with unapproved external destination/port combinations considered for blocking or alerting. Broad-port C2/framework families warrant long-term ASN+port, SPKI, and protocol signals. Standard-port payload delivery should instead be narrowed through web request structure and infrastructure context.

6.2. URI Patterns Reveal Campaign Characteristics

URI randomness was high for Glassworm, CalendarC2, MaskgramStealer, ClearFake, AmadeyBot, FakeAdobe, Stealc, and FakeZoom. Glassworm led with mean entropy 4.511 and median 4.634, indicating strongly randomized paths intended to evade static signatures. Mozi’s mean was 1.004, Formbook’s 2.253, and some C2 frameworks were in the upper 2s. Low entropy means less randomness, but repeated short, simple URIs resembling legitimate resources can still evade heuristics. The most frequently repeated URIs are shown below.

[Table 8] Frequently repeated URIs and campaign tags

[Figure 11] Campaign path patterns by URI entropy

7. Persistence: Links That Survive Changing IoCs

7.1. SPKI Reconnects Dispersed Campaigns

One key aim of threat intelligence is to move beyond flat blocking of individual indicators and build proactive defenses by clustering seemingly unrelated infrastructure through metadata. This case study examines a CobaltStrike-associated certificate public-key hash cluster (SPKI: 6691ce9450b4eb3d35709bbefaa63e3819c8940e8a7db70e796070e3d5cb5c93), the largest cluster among threat infrastructure collected in Q1 2026. Starting from 84 initial indicators, a final dataset incorporating port and protocol branches was constructed for expanded analy

[Table 9] Major SPKI clusters and distribution characteristics

Large clusters must be distinguished from widely dispersed clusters. A cluster concentrated on one provider may permit subnet- or provider-level action, whereas campaigns spread across ASNs and countries are difficult to address through IP blocking alone. They should be operated as hunting signals combining SPKI, ASN movement, ports, and active status.

[Figure 12] Distribution of SPKI-based campaign clusters

7.2. Strategic Hunting Starts with Persistent Features

The appendix contains 128 strategic hunting signatures: 115 SPKI-based and 13 ASN+port. Priorities comprise 73 medium, 46 high, and 9 critical. The most notable critical SPKI is ‘6691ce9450b4eb3d35709bbefaa63 e3819c8940e8a7db70e796070e3d 5cb5c93’, observed on 101 unique IPs, used 111 times, and lasting 105.1 days; leading ASNs included Railnet LLC, AROSS-AS, and Biil Ru Ltd. Another critical SPKI, ‘9ef15a1ce89f8df6b8fed558a36547e5205501e6b21fe 5b00790e4716a3bd248’, appeared with Kimsuky/Xworm/Remcos tags across 22 unique IPs, 31 uses, and 97.1 days.

The conclusion is straightforward: IPs and domains change quickly, while SPKI and deployment fingerprints recur. Strategic hunting lists should therefore outlive blocklists and be managed as reusable fingerprints in TLS inspection or CTI platforms.

8. Analyst’s Pick: Developer-Targeting JavaScript C2 Operations by North Korea-Linked Actors

8.1. Case Overview and Selection Rationale

Cluster 2046, the Analyst’s Pick, represents developer-targeting JavaScript C2 operations linked to North Korea. Although it is not the largest campaign by IoC volume, its analytical value is substantial: the dataset’s references lead to an actual JavaScript sample, and static reconstruction connects obfuscated strings, Node.js execution, C2 control, and upload/exfiltration channels.

[Table 10] Structural metrics of Cluster 2046

The key is not a single server address. Developer workstations, GitHub/NPM/VSCode/Git hooks, Vercel configuration delivery, potential terminal/API segments, Socket.IO/WebSocket control, and upload/exfiltration paths form one attack flow. Blocking a single IoC is insufficient; file traces, C2 protocols, header/field combinations, and historical proxy/SIEM log hunting should be designed together.

This case should be treated as an illustration of how North Korea-linked operations targeting developers abuse legitimate workflows to reach C2 backends and upload/exfiltration paths, rather than as a list of North Korean C2 servers.

8.2. Infrastructure by Role

Examine the infrastructure by role, not simply as a bundle of IoCs.

[Table 11] Cluster 2046 infrastructure by role

[Figure 13] Role model of developer-targeting JavaScript C2 linked to North Korean actors

The diagram shows the separation of Vercel configuration delivery, potential lab99 terminal/API connections, ROUTERHOSTING backend candidates, and sample-confirmed control/upload channels in the developer execution flow. The evidence boundary at the bottom is especially important. Roles for ‘216.126.225.243:8087’ and ‘8085/8086’ were confirmed from the sample, but whether Vercel or lab99 responses directly supply that backend still requires validation.

8.3. Sample Execution and Communication Structure

A strength of this case is that analysis extends beyond an infrastructure graph. The top-priority pivot sample was obfuscated JavaScript, and analysis separated its execution and communication structures.

[Table 12] Static-analysis observations from the JavaScript sample

This structure is more operationally developed than a basic script downloader. Victims are induced to execute code within the developer toolchain; the sample uses Node.js to execute a separate second-stage payload and then uses distinct control and upload/exfiltration channels. This section should therefore be read as both infrastructure analysis and malware static-analysis findings.

8.4. C2 Protocol and Channel Separation

The most important finding is that 216.126.225.243:8087 was confirmed as an actual C2 control channel, not merely a related IoC. The value hard-coded in the sample is http://216.126.225.243:8087 rather than a WebSocket address; execution converts or uses it for Socket.IO/WebSocket communication.

[Table 13] C2 communication elements and channel separation

The structure separates command and control from upload/exfiltration. Hunting conditions combining upload, validation, host metadata, Socket.IO/WebSocket transitions, and Node.js dependencies are more useful than blocking a single IoC.

8.5. Evidence Scope and Interpretation Limits

It is essential to distinguish confirmed evidence from candidate infrastructure.

# Confirmed

- Static reconstruction of obfuscated JavaScript revealed plaintext C2 strings and execution structure

- Node.js-based sample with separate first-stage loader and second-stage collection/control script

- ‘http://216.126.225.243:8087’ hard-coded C2 control channel

- Uses a Socket.IO/WebSocket control channel in the form ‘ws://216.126.225.243:8087’ during execution

- ‘http://216.126.225.243:8085/upload’, ‘http://216.126.225.243:8086/upload’

- Combination of the validation header, host identification fields, and Node.js dependencies

- Collection logic for browser credentials, wallets, .env, .ssh, API tokens, and private keys

# Candidate infrastructure

- lab99.sbs /api/terminal/*: potential terminal/API connection segment identified in the analysis data

- brezo.live, admin.brezo.live: potential server-side or administration hubs in the same analysis set

- Direct response-flow connection between Vercel configuration delivery and the 216.126.225.243 C2 backend

# Unconfirmed

- Direct evidence that lab99.sbs responses actually provide the 216.126.225.243 C2 backend

- Direct code-level connection between Vercel configuration endpoints and the 216.126.225.243 C2 backend

- Actor attribution based on time zones

8.6. Example File and Network Hunting Rules

This Analyst’s Pick has strong potential for conversion into operational hunting conditions. Two rule types are appropriate: YARA rules to find similar JavaScript samples in static files and artifact repositories, and network-packet rules to identify the C2 protocol in Proxy/IDS/NDR systems. Operational priorities are as follows.

[Table 14] Operational priorities for hunting rules

The file rules below have two purposes. The first includes the confirmed backend and upload path and is therefore highly precise. The second is behavior-based, targeting variants with changed server addresses. These YARA rules are suited to files retaining plaintext strings, static-analysis outputs, and repositories of decrypted or reconstructed strings. They may miss original obfuscated files whose strings have not been restored.

The network-packet rules use Suricata 6/7 syntax. Snort 2.x and some commercial IDS/IPS products may use different HTTP buffer keywords, so validate rules with each product’s parser before deployment. Direct-backend rules offer high precision but may be short-lived; the ‘/upload’ and ‘validation’ combination can remain a long-term hunting condition after server changes.

In M365 Defender or Sentinel, the query below can first check for direct connections to the backend.

Operationally, rules based on ‘216.126.225.243’ suit immediate blocking and hunting, while /upload, validation, ukey/username/timestamp, and Socket.IO/WebSocket transitions should remain long-term hunting candidates. Vercel, lab99, and brezo are not sample-confirmed C2 backends, so they should support review and connectivity validation rather than blocking rules.

9. Conclusion

The previous quarterly report examined the limits of individual IoC blocking and focused on turning infrastructure metadata into defensive logic. IPs and domains change rapidly, but certificates, ports, URIs, active time windows, and deployment methods can recur as attackers replace or expand infrastructure. This report continues that perspective while finding a somewhat different answer to the same question.

Data from March 1 to June 15, 2026 highlighted how attackers use legitimate services and shared infrastructure, rather than the dominance of a particular tool. Cloudflare and major cloud/shared hosting were places where ClearFake, ClickFix, and Vidar mixed with legitimate traffic. Hetzner, Railnet, Hostinger, and Namecheap infrastructure required responses to payload delivery and active C2 backends. Alibaba, Tencent, and Yancy ASNs showed C2/framework tags concentrated in particular networks. The practical answer was less about which infrastructure to block wholesale and more about what to block immediately, retain for review, or convert into long-term hunting signals.

Looking only at individual IPs or domains risks overblocking Cloudflare campaigns, dilutes Chinese cloud ASN C2 concentrations into country statistics, and buries SPKI and ASN+port combinations among disposable IoCs. These should not share one undifferentiated list; defenders should operate separate blocking, review, tactical hunting, and strategic hunting workflows.

The North Korea-linked developer-targeting JavaScript C2 case confirms this at sample level. Its value lies not in one IP but in a developer-workflow trust chain connecting configuration delivery, Git hook settings, Socket.IO/WebSocket control, and ‘/upload’ exfiltration. The statically confirmed backend (216.126. 225.243), validation header, and metadata fields ukey, host, os, username, and timestamp form a C2 communication structure that may outlive individual IoCs. The case therefore provides analytical grounds for both file and network-packet detection rules.

The report’s purpose is to translate collected threat clues into criteria defenders can judge and operate immediately. Narrow immediate-blocking targets, manage mixed legitimate-service targets through reviewable conditions, and retain recurring certificates, ports, URIs, headers, host fields, and ASN combinations as signals for future detection. Q2 data shows that these criteria can be organized around shared-infrastructure abuse, provider-specific roles, and role-separated C2 operations.

10. Response Guide Appendices

This report supplies five appendix datasets based on confidence in multichannel threat telemetry and the characteristics of defensive mechanisms. Each is optimized for a stage of security operations—blocking, monitoring, hunting, strategy, or prediction. Security teams are encouraged to apply them dynamically to internal security devices and SIEM systems using the guidance below.

[Appendix 1] Immediate Blocklist (Blocklist)

This list selects only highly confident malicious IoCs with C2 communication active (Alive) at analysis time. Major CDN and shared-cloud ranges, including Cloudflare and Akamai, are automatically excluded to prevent disruption of legitimate services from individual IP blocking. Security teams should immediately add these IPs and domains to firewall, IPS, and other blocking policies. If subsequent inbound/outbound attempts between internal systems and these indicators appear in logs, strongly suspect endpoint infection and promptly isolate and investigate forensically.

[Appendix 2] Shared Infrastructure Review List (Review_Shared_Infra)

This includes confirmed malicious activity where immediate blocking risks collateral damage or further payload validation is needed. This quarter includes many proxy nodes in Cloudflare (AS13335) and Amazon (AS16509) ranges abused to conceal the true origin. Avoid simple IP-level blocking; use the list to prioritize domain- and URL-path-based precise blocking through web application firewalls or proxies.

[Appendix 3] Tactical Hunting List (Tactical_Hunting_Active_Campaign)

This collection of real-time detection patterns and IoCs covers the latest, most actively distributed campaigns and reflects current quarterly attack tactics. Incorporate the patterns into SIEM correlation rules to block initial intrusion attempts in real time, and use them for a comprehensive retroactive hunt across firewall and DNS logs from the past three months.

[Appendix 4] Strategic Hunting List (Strategic_Hunting_Signatures)

This list captures attackers’ invariant infrastructure fingerprints even when they continually change IPs/domains to evade defenses. Signatures include certificate public-key hashes (SPKI) and specific hosting/nonstandard-port combinations (ASN+Port). Apply them to internal/external CTI platforms and SSL Inspection systems to proactively discover hidden reserve C2 servers and support strategic neutralization at scale.

[Appendix 5] Infrastructure Transition Tracking Indicators (Tactical to Strategic Promotions)

This long-term watchlist tracks reserve attack infrastructure newly built or migrating between hosting providers for future large-scale operations. Large campaign infrastructure migrations are representative cases. Beyond blocking targets, these are strategic indicators to watch for signs of upcoming attacks and proactively strengthen defenses.

※ All data reflects activity as of the extraction date (2026.06.16). The validity of [Appendix 1] in particular may change with the speed at which attackers discard infrastructure. Periodic validation and dynamic removal are recommended to avoid overloading firewalls.

Cyber threats can occur anywhere, at any time.

SANDS Lab continuously shares reports on threat relationships and IoCs identified through analysis of the latest malware, helping prevent cyber threats and build a safer digital society.