• AdaptixC2 is an open-source post-exploitation C2 framework whose default configuration ships branded HTTP headers (Server: AdaptixC2, Adaptix-Version: v1.2) on every unauthenticated request, making deployed servers trivially identifiable from passive scanning.
• As of 16 June 2026, Censys tracks 412 web properties across 236 hosts running AdaptixC2 with default or near-default settings.
• Three beacon listener clusters (Hivelocity, M247, PSB Hosting) – each spanning multiple IPs across adjacent subnets with identical default TLS certificates – suggest individual operators running coordinated, redundant callback infrastructure.
• One host (2.26.229[.]254) was actively serving payloads, including a Linux installer with 12 persistence mechanisms and Russian-language comments.
• Operators who modify the Server header to evade detection leave the default 404 page body intact. Querying on both signals catches this class of evasion.
• All detections are available in Censys via the THREAT-0210 threat label.

AdaptixC2 is an open-source post-exploitation framework with a default configuration that makes deployed servers trivially identifiable from passive scanning. As of 11 June 2026, Censys tracks 390 web properties — each a distinct IP or hostname and port pair — across 217 hosts running AdaptixC2 with default or near-default settings. This includes three distinct beacon-listener clusters that suggest coordinated multi-server deployments and one host serving implants from an open directory. The framework ships branded HTTP headers on every unauthenticated request, so the first passive probe identifies the framework without authentication or endpoint knowledge.

Not all of these hosts represent malicious activity. Some are almost certainly authorized red team infrastructure. What we can say from passive scanning is that the infrastructure exists, it’s detectable, and defenders who understand the fingerprint can make informed decisions about what to block or monitor.

What Is AdaptixC2?

Post-exploitation frameworks provide the tooling operators use after gaining an initial foothold: maintaining access, running commands, moving laterally, and collecting data from compromised systems.

AdaptixC2 is a publicly available post-exploitation framework written in Go (teamserver) and C++/Qt (GUI client). It’s designed for red team engagements, though like most offensive frameworks it sees use in unauthorized operations as well. The project is at v1.2 and has less public analysis coverage than older frameworks like Cobalt Strike, Havoc, or Sliver.

The framework ships two agent families. In C2 terminology, an agent is an implant that runs on a compromised host and checks in with the operator for tasking, not an AI agent. The Beacon agent is a C++ implant supporting Beacon Object File (BOF) execution on Windows, Linux, and macOS; the Gopher agent is a Go implant with async BOF support across the same platforms. The framework implements listeners as loadable plugins (“extenders”) covering HTTP/S, DNS/DoH, SMB named pipes, and raw TCP transports. The teamserver exposes a full REST and WebSocket API for operator control — credential management, agent tasking, screenshot capture, tunnel management, and multi-operator collaboration.

What makes AdaptixC2 detectable at scale is a design choice in profile.yaml: the error block sets Server: AdaptixC2 and Adaptix-Version: v1.2 on every unmatched route. They appear on any request that doesn’t match the configured endpoint — no authentication required, no prior knowledge of the endpoint path needed. Passive scanners see the banner on the first probe.

Architecture

Teamserver

The teamserver is a single Go binary. At startup it loads profile.yaml to configure the network interface, port, endpoint path, password, and HTTP response behavior. It then generates or loads a self-signed TLS certificate, loads extender plugins from disk, starts an HTTPS server via gin, and restores state from a SQLite database.

The router hierarchy in connector.go defines four distinct groups under the configured endpoint (default /endpoint):

Anything outside the /endpoint prefix, and any path under /endpoint that isn’t registered, hits the NoRoute handler, which returns the configured error response — the 404 page with the branded headers.

Authentication Model

Authentication is two-tier. The /login endpoint takes a JSON body with a username and password and returns a short-lived JWT access token (12 hours) and a long-lived refresh token (168 hours, or seven days). Each startup generates fresh JWT signing keys via crypto/rand and signs tokens with HS256.

OTP tokens gate WebSocket upgrades and one-time file transfers. An authenticated operator calls /otp/generate with a JWT access token to create a 64-character hex OTP. These tokens are single-use — calling the corresponding endpoint twice with the same token fails.

Extender System

Listeners compile to Go shared libraries (.so files) that load at runtime. When a listener starts, it can register routes on either the api_group (JWT-protected) or the public_group (unauthenticated). This is the correct design for agent callbacks — agents don’t carry operator credentials, so their check-in endpoints can’t require JWT auth.

In practice, the HTTP beacon listener (BeaconHTTP extender) doesn’t use the teamserver’s public endpoint group at all. It starts its own separate HTTP server on the operator-configured callback port, independent of the teamserver:

This is why the Censys scan finds two distinct populations — teamservers (typically port 4321, operator API) and beacon listeners (high ports like 43211, agent callbacks). Both surfaces return the default 404 page, but they serve different purposes.

The Fingerprint

Detection relies on two independent signals from the default configuration, both visible without authentication.

The headers. The default profile.yaml sets these headers in HttpServer.error.headers:

HttpServer:
  error:
    status: 404
    headers:
      Content-Type: "text/html; charset=UTF-8"
      Server: "AdaptixC2"
      Adaptix-Version: "v1.2"
    page: "404page.html"

Because this is the error handler, not a specific route, these headers appear on any path that doesn’t match the configured endpoint. Even when an operator uses the default /endpoint path, API access still requires a valid JWT. But any request to /, /robots.txt, /favicon.ico, or any arbitrary path returns a 404 with Server: AdaptixC2 in the response.

The 404 body. The default 404page.html contains:

<h1>AdaptixC2 404</h1>
<p>You need to enter the correct connection details.</p>

This string is specific enough to use as a standalone indicator when an operator has changed the response headers.

Combined query:

host.services.endpoints.http.headers: (key: "server" and value: "AdaptixC2") or host.services.endpoints.http.headers: (key: "adaptix-version" and value: "v1.2")

Body-only fallback (catches header-modified deployments):

host.services.endpoints.http.body: "You need to enter the correct connection details."

DNS listener (tertiary signal). The BeaconDNS extender sets AA=true on every response and returns TXT "OK" for any query that doesn’t match its beacon protocol format — specifically, any query with fewer than five labels. Censys captures this as a DNS service with version: "OK" on UDP/53.

host.services.dns.version: "OK" and host.services.protocol = "DNS"

This query returns around 30 hosts globally. Most are legitimate DNS servers hiding their BIND version with a custom string, so the signal needs cross-referencing, either against the Adaptix C2 threat label or via active probe. Querying a random short hostname returns TXT "OK" (what Censys captures), while a query formatted as a beacon-check-in (five or more dot-separated labels in the BeaconDNS protocol format) returns A 127.0.0.1 on a genuine listener. Default TTLs jitter between 10 and 70 seconds). On hosts that aren’t running BeaconHTTP, this is the only passive signal.

Discovery

We started from the source code. AdaptixC2’s profile.yaml and 404page.html are both in the public GitHub repository — the fingerprint follows directly from reading them, no prior infrastructure exposure needed. We confirmed the expected headers against live deployments and ran both queries against Censys.

The combined scan returned 236 unique hosts. The default configuration is explicit enough that a single query captures most of the population. The harder work was making sense of what those hosts represent.

Censys ARC Perspective

The hosts break down across a range of ASNs and geographies, with clustering that suggests organized deployment.

Port Distribution

The 46 hits on port 4321 confirm that many operators deploy with the default configuration and leave the port unchanged. The 15 hits on 43211 concentrate in two of the three beacon listener clusters described below.

Top ASNs

Geographic Distribution

The US count is high partly because Hivelocity is a US-based provider, and those hosts are almost certainly beacon listeners rather than teamservers. The Hong Kong and China hosts cluster on Tencent Cloud, consistent with East Asia-based operators or operators targeting that region.

Notable Hosts

The cert on 89.125.255[.]29 stands out: C=RU, ST=as, O=as — “as” filled in twice when prompted for state and organization. 185.190.142[.]66 has both AdaptixC2 on port 4321 and RDP open on 3389, which suggests an operator working directly on the teamserver box rather than managing it remotely through a jump host.

38.147.173[.]24 runs AdaptixC2 on port 8562 and also has port 50050 open. Port 50050 is the default Cobalt Strike teamserver port. We can’t confirm from a passive scan that a live Cobalt Strike instance is present — port 50050 could be in use for something else, or the process may not be running at scan time. The combination suggests an operator working with multiple offensive tools.

Infrastructure Clusters

The most informative finding from the Censys scan isn’t the individual hosts — it’s three beacon listener clusters that likely represent single operators running multiple callback servers.

These are beacon listeners, not teamservers. A teamserver needs to be reachable by the operator for API access — typically a single port on a fixed IP. A beacon listener only needs to be reachable by agents on compromised hosts. Operators often run multiple beacon listeners across different providers, ports, and geographies for redundancy and to complicate takedown. Shared TLS certificate patterns tie these clusters together.

• Hivelocity cluster. Eight or more IPs across two subnets (23.227.203.0/24 and 46.21.153.0/24) all serving the AdaptixC2 404 page on randomized high ports (42215, 42235, 43211, 43435, 43655). Every host in this cluster uses the default OpenSSL self-signed certificate: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd. That certificate is what OpenSSL generates when you run openssl req and accept all defaults. Its presence across eight IPs on two adjacent subnets from the same provider strongly suggests a single operator who stood up a batch of callback servers without customizing the TLS configuration.
• M247 cluster. Eight IPs across two subnets (38.132.122.x and 146.70.87.x), almost all on port 43211. Same default OpenSSL certificate as the Hivelocity cluster. M247 is a popular choice for red team and grey-area infrastructure. The shared port and shared cert pattern point to the same operator or the same deployment tooling.
• PSB Hosting cluster. Six IPs across two subnets (45.155.69.x and 185.242.245.x) on randomized ports in the 42xxx–44xxx range. Smaller than the other two clusters but the same behavioral signature: adjacent IPs, randomized high ports, default cert.

The sequential or near-sequential IP allocation within each cluster suggests these were provisioned at the same time, probably from the same provider account. Operators who spin up beacon listeners in bulk tend to take consecutive IPs because that’s what you get when you order multiple VMs in the same region in the same session. Whether any of these are authorized engagements, passive scanning can’t say — the clustering pattern describes how the infrastructure was built, not what it was used for.

A Live Deployment: 2.26.229[.]254

The clearest evidence of an active operation in this dataset is 2.26.229[.]254. It ran AdaptixC2 listeners on ports 4433 (BeaconHTTP) and 4455 (GopherTCP) and simultaneously served payloads over an open HTTP directory on port 7000. No authentication required — the files were publicly accessible to anyone who connected.

Payloads

timesync.bin is a Gopher agent (ELF x64) for Linux. The three .exe files are Windows Beacon implants in both x64 and x86 variants. A legitimate VC_redist.x86.exe was also present, likely as a runtime dependency.

install.sh: Linux Persistence Installer

The installer presents itself as a routine package update — fake apt output, fake kernel unpacking — while running the actual installation in a background subshell. Russian-language comments throughout the script indicate the author’s working language. It deploys timesync.bin to /usr/local/lib/systemd/timesync and establishes 12 independent persistence mechanisms before shredding itself.

1. Hidden user — creates systemd-timesync (UID 9999) with a random password and a hardcoded operator SSH key in authorized_keys. SSH access survives agent removal.
2. Fake systemd service — overwrites systemd-timesyncd.service to execute the beacon, masquerading as the NTP sync daemon.
3. Three cron jobs at 5-minute, 10-minute, and 15-minute intervals across separate crontab locations. Any one survivor restarts the agent.
4. Initramfs hook — drops a script into /etc/initramfs-tools/scripts/init-premount/ and rebuilds the initrd via update-initramfs. The agent runs before the root filesystem mounts.
5. GRUB init replacement — appends init=/usr/local/lib/systemd/systemd-persistence.sh to GRUB_CMDLINE_LINUX_DEFAULT and rebuilds grub.cfg. The kernel hands PID 1 to the attacker’s script instead of systemd on next boot. This survives service removal, cron purges, and user deletion.
6. LD_PRELOAD library — writes and compiles libsystemd-override.so, registered in /etc/ld.so.preload. A GCC constructor causes every dynamically linked process to fork and exec the beacon. Removing the binary alone is not sufficient.
7. Kernel thread masquerading — two beacon instances launched as [kworker/0:0] and [kthreadd] via exec -a, blending into kernel thread entries in ps output.
8. Integrity monitor — monitor.sh running as [kworker/u:0], checking every 60 seconds and re-downloading the agent from hxxp://2.26.229[.]254:7000/timesync.bin if it’s absent.
9. Shell profile injection — appends agent launch to .bashrc and .profile for every user in /home/* and root.
10. DNS hijacking — sets 2.26.229[.]254 as the primary systemd-resolved DNS server. All DNS queries route through the C2 host.
11. eBPF hook — if bpftool is present, loads a kprobe on sys_getdents64 returning 0, attempting to hide processes from directory listings.
12. Systemd timer — systemd-timesync.timer firing two minutes after boot and every 10 minutes thereafter.

Cleanup: zeroes all files under /var/log, clears bash history, and shreds the installer with shred -u.

The combination of GRUB init replacement and LD_PRELOAD means the implant survives most detection-and-removal workflows short of a full OS reinstall. The eBPF hook — loading a kprobe on sys_getdents64 to zero out process directory entries — aims to make running processes invisible to standard userspace tools, adding a kernel-level hiding layer on top of the process name masquerading in items 7 and 9.

Beacon Config (Extracted via Static Analysis)

The Agents section below covers config extraction from Windows beacon binaries. The three .exe samples from 2.26.229[.]254 all call back to the same listener:

• C2: hxxp://2.26.229[.]254:4433
• Callback URIs: /api/v1/status, /updates/check.php, /content.html
• Custom header: X-ISS
• User-Agent: Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0
• RC4 key: 1baccab4cbd2b84f6bc54bf8e6551f93
• Sleep: 10 seconds

The API Surface

The teamserver’s REST API is spelled out in server.go and connector.go. Here’s what’s behind it.

The authentication flow:

1. Operator calls POST /endpoint/login with a JSON credential body. Server returns access token (12hr) and refresh token (168hr).
2. Operator attaches the access token as Authorization: Bearer <token> on all subsequent requests.
3. Before opening a WebSocket channel, operator calls POST /endpoint/otp/generate to get a one-time token, then upgrades via GET /endpoint/connect?otp=<token>.
4. Expired access tokens are refreshed via POST /endpoint/refresh with the refresh token.

Authentication and session:

Agents and tasks:

Infrastructure and collection:

What Is and Isn’t Exposed Without Authentication

The teamserver management API is reasonably secured when the password is set correctly. The unauthenticated surface on the teamserver port is limited:

All 50+ data endpoints require a valid JWT access token. There’s no unauthenticated path to agent lists, credentials, screenshots, downloads, or operator sessions through the teamserver API.

The OTP-gated endpoints (/connect, /channel, /otp/upload/temp, /otp/download/sync) require a valid OTP generated by an authenticated operator. OTP tokens are single-use and expire quickly.

Error Response Behavior

Failed authentication attempts — wrong password, missing token, expired token — all return HTTP 404 with the same Server: AdaptixC2 branded response. The server doesn’t distinguish between “wrong password” and “path doesn’t exist” in its response to the client. This is intentional: it prevents an attacker from confirming which endpoint paths are valid by observing different status codes.

The side effect is that the Server: AdaptixC2 header appears on every response, including failed auth attempts. An attacker probing the server learns the framework identity from the first probe, before making any authentication attempts.

Agents

AdaptixC2 ships two distinct agent families.

Beacon is a C++ implant targeting Windows, Linux, and macOS. Its primary capability beyond standard C2 tasks is BOF (Beacon Object File) execution — a technique popularized by Cobalt Strike that lets operators run compiled C code in-process without touching disk. This makes Beacon harder to detect for endpoint tools focused on child process creation. The default watermark embedded in config.yaml is be4c0149.

Beacon supports multiple transport protocols through its extender system:

• BeaconHTTP: HTTP/S callback with configurable URIs, headers, and User-Agent rotation
• BeaconDNS: DNS-based callback channel. The listener replies with TXT "OK" to any short-label or unrecognized query and sets the authoritative-answer bit on every response, which Censys surfaces as dns.version: "OK" — a usable passive fingerprint on its own.
• BeaconSMB: Named pipe communication for peer-to-peer pivoting within compromised networks
• BeaconTCP: Bind-style TCP channel for internal pivots

The transports differ in external visibility. BeaconHTTP, BeaconDNS, and BeaconTCP all expose a socket reachable by any internet scanner. BeaconSMB has no external footprint at all — the teamserver-side Start() for the SMB extender is a no-op. The named pipe lives on a victim machine already running another beacon, which acts as an SMB relay for the rest of the network. An SMB-only deployment is invisible to Censys or any other internet scanner.

Gopher is a Go implant covering the same platforms. It supports async BOF execution, meaning tasks run in a background goroutine and the agent continues polling without waiting for completion. The default watermark is 904e5493. Gopher compiles to a statically linked binary with no external runtime dependency, which makes Linux deployment straightforward.

Both agents use watermarks — short hex strings baked into the compiled binary — to associate callbacks with a specific build. The defaults (be4c0149, 904e5493) are identifiable in memory or binary dumps if an operator doesn’t change them.

Agent Beacon Protocol

When a BeaconHTTP listener starts, it runs its own HTTP server on the configured callback port, completely separate from the teamserver. Agent callbacks don’t go to port 4321 — they go to the listener’s dedicated port. That’s why the Hivelocity cluster (all high ports, no operator API) looks different from individual teamservers (single port, full REST API).

On check-in, the agent sends a request to the configured URI path with a custom header containing a base64-encoded, RC4-encrypted “beat” blob. The listener decrypts the beat using the pre-shared encrypt_key (32 hex chars configured when the listener is created) and extracts the agent type, agent ID, and beacon data. The request body contains any outgoing task data from the agent. The response body contains pending tasks for the agent, embedded in the configured page-payload template string.

The RC4 key is specific to each listener instance and is set by the operator at listener creation time. Agents compiled for a given listener embed this key. This provides meaningful separation between the callback protocol and the teamserver API.

Beacon Config Extraction

Beacon implants embed an RC4-encrypted configuration blob in the .rdata section of the compiled PE. MinGW builds (the default toolchain) place it at the start of .rdata. The layout, derived from the Go-side serialization in pl_main.go and the C++ parser in AgentConfig.cpp:

[4-byte LE: ciphertext_size]
[ciphertext_size bytes: RC4 ciphertext]
[16 bytes: RC4 key]

Decryption requires no external keys — the RC4 key is stored in the binary itself. Slice the ciphertext using the 4-byte size field, use the trailing 16 bytes as the key, and decrypt. The first four bytes of the plaintext are the agent watermark (0xBE4C0149 for Beacon, 0x904E5493 for Gopher). C2 host strings follow as length-prefixed fields, each immediately followed by a 4-byte port value.

Because the number of header fields between the watermark and the first host string varies across build configurations, the most reliable extraction approach scans the plaintext for strings that match IP or hostname patterns rather than parsing at fixed offsets. Non-MinGW toolchains may place the blob at a non-zero offset within .rdata; a 4-byte-aligned sliding search over the section recovers it in those cases.

Any Beacon implant recovered from an endpoint, pulled from a staging server, or retrieved from a sandbox can be parsed for its C2 server, callback URIs, and the listener RC4 key — without executing the binary. The 2.26.229[.]254 samples above demonstrate this: three independently compiled executables, all pointing to the same listener config.

Third-Party Extensions: KharonHTTP

AdaptixC2’s extender system supports loading third-party listeners as Go plugins. KharonHTTP (github.com/entropy-z/Kharon) is one — we found it running on two hosts in this dataset.

KharonHTTP implements a malleable C2 profile system — operators configure URI paths, response headers, User-Agent patterns, request body prepend/append wrappers, and cookie or parameter encoding via a JSON profile. This is similar to Cobalt Strike’s Malleable C2 profiles: a single listener binary that takes on different network personas depending on operator configuration. KharonHTTP uses a custom block cipher (“LokyCrypt”) — an 8-byte block, 16-round Feistel construction with XOR post-processing — instead of AdaptixC2’s default RC4.

We found KharonHTTP active on two hosts. 1.14.172[.]47 ran two KharonHTTP listeners on ports 56743 and 56744. 104.236.230[.]184 ran one on port 443. The callback domain llmscience.top was extracted from the listener config on 1.14.172[.]47. The hardcoded agent type identifier is c17a905a.

One behavioral note for defenders running active scans: KharonHTTP returns the literal string "Bad Request" in the response body when the Host header doesn’t match any configured callback. This fires before the operator’s malleable profile is consulted, so it’s consistent regardless of what profile is loaded. KharonHTTP listeners run plain HTTP by default — operators configure TLS separately — so this response is readable in cleartext even on non-standard ports.

Operator Profile

The infrastructure doesn’t suggest a single threat actor; it’s a mixed population with varying levels of operational discipline.

The three beacon listener clusters — Hivelocity, M247, PSB — show operators who understand multi-server deployment. Spinning up eight servers across two subnets and pointing agents at all of them is not a default behavior; someone made a deliberate choice to run redundant callback infrastructure. Whether those campaigns are authorized is a separate question.

The default OpenSSL certificate (C=AU, ST=Some-State, O=Internet Widgits Pty Ltd) visible across these clusters indicates operators who aren’t concerned about TLS fingerprinting — they either don’t know it’s a detection vector or don’t consider it a priority for their specific operations.

The outlier hosts show more varied configurations. 89.125.255[.]29 uses C=RU, ST=as, O=as in the certificate — someone who customized the TLS config but filled in “as” twice for state and organization. 185.190.142[.]66 carries an O=OpenClaw certificate on port 443 alongside an active AdaptixC2 instance and open RDP. The install.sh installer distributed from 2.26.229[.]254 has Russian-language comments throughout. These are observations about individual hosts, not a basis for connecting them to each other.

The three sequential CTG Server IPs (202.95.8[.]92, 202.95.8[.]97, 202.95.8[.]98), all on port 4321, were likely provisioned by the same operator. Port 4321  appeared on .92 on May 26th, .98 on May 29th, .97 appeared on May 30th: three consecutive IPs from the same provider, all coming online within a four-day window.

The “TestCoonection” variant is the most instructive signal in the dataset for detection purposes. Changing the Server header requires editing profile.yaml and restarting the teamserver — the operator made a deliberate choice to evade header-based detection. The Server value contains a consistent typo: “Coonection” with a double-o, present across multiple scans. Querying on the 404 body string still catches it.

That’s the pattern across this population: operators at varying stages of OPSEC maturity, some running defaults, some making targeted changes. The ones making targeted changes tend to address one detection vector at a time and leave others intact. That’s what makes layered detection — headers and body, passive and active — worth maintaining.

IOCs

Detection Queries

Threat label (simplest — finds all detections including evasion variants):

host.services.threats.name: "Adaptix C2" or web.threats.name: "Adaptix C2"

Header-based (primary):

web.endpoints.http.headers: (key: "Server" and value: "AdaptixC2")

Version-specific:

web.endpoints.http.headers: (key: "Adaptix-Version" and value: "v1.2")

Body-based (catches header-modified deployments):

web.endpoints.http.body: "You need to enter the correct connection details."

DNS listener (tertiary — requires cross-reference):

host.services.dns.version: "OK" and host.services.protocol = "DNS"

Censys threat detection: THREAT-0210 (includes body hash, header, and “TestCoonection” variant)

Representative Infrastructure

Hivelocity beacon listener cluster:

M247 beacon listener cluster:

PSB Hosting beacon listener cluster:

Notable individual hosts:

Samples and Artifacts (2.26.229[.]254)

Operator SSH public key (hardcoded in install.sh):

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIoi/bPuWr2EOQZo2OVDqG8XsRMz5epEGqG9sjcwZGJ1 timesync-manager

Presence of this key in authorized_keys on any host links the infection to this operator.

BeaconHTTP RC4 key (extracted from Windows samples): 1baccab4cbd2b84f6bc54bf8e6551f93

Agent Watermarks

Find AdaptixC2 Infrastructure on Censys

All hosts in this dataset are tagged under the Adaptix C2 threat label (THREAT-0210) in Censys. The threat detection covers both the default header-based detection and the body-based fallback, including the “TestCoonection” evasion variant.

host.services.threats.name: "Adaptix C2" or web.threats.name: "Adaptix C2"

Takeaways

1. Default branding makes passive detection trivial. The Server: AdaptixC2 and Adaptix-Version: v1.2 headers appear on every unauthenticated request because they’re set in the error handler, not a specific route. No credential or endpoint knowledge is needed to identify a default-configuration deployment.
2. Operators trying to evade headers leave the body string behind. The “TestCoonection” variant confirms that at least one operator modified the response headers to avoid detection but left the default 404 page intact. Body-based detection catches this class of evasion. Defenders should query both signals.
3. Three beacon listener clusters suggest coordinated multi-server operations. The Hivelocity, M247, and PSB clusters — identifiable from sequential IPs, shared ports, and identical default OpenSSL certificates — likely represent single operators running redundant callback infrastructure. The shared cert pattern is the clustering signal.
4. External visibility varies by transport. BeaconHTTP, BeaconDNS, and BeaconTCP all expose sockets that passive scanning can reach. BeaconSMB does not — the SMB extender binds no socket on the teamserver, and the named pipe lives on an already-compromised victim. Operators who pivot entirely through SMB after initial access leave nothing for internet scanners to find. The deployments counted here are necessarily those that kept at least one externally-reachable listener running.
5. 412 web properties across 236 hosts is a population worth monitoring — with the caveat that passive scanning can’t separate authorized engagements from unauthorized ones. Some of these are authorized red team engagements. Passive scanning can’t distinguish them from unauthorized activity. What it can do is surface the infrastructure so analysts can make that determination themselves. The fingerprint is in production (THREAT-0210) and covers both header-based and body-based detection paths, including the evasion variant. Defenders can use the queries above to identify AdaptixC2 deployments in their threat intelligence pipelines.

The post AdaptixC2: Fingerprinting an Open-Source C2 Framework at Scale appeared first on Censys.

• Google’s Threat Intelligence Group (GTIG) recently attributed a year-plus espionage campaign against North American academic, medical, and military research institutions to UNC6508, a PRC-nexus actor. The consistent initial access vector was an externally facing REDCap server: exploited, then backdoored with custom malware (dubbed “INFINITERED”) for over a year of data exfiltration. The initial access method is unconfirmed at the time of writing.
  
• REDCap (Research Electronic Data Capture) is a web application used by research institutions worldwide to build and manage study databases. It commonly holds clinical trial data, participant records, and other sensitive research information.
  
• As of June 16, 2026, Censys observed just over 8,500 REDCap instances globally, with concentrations in the U.S. (40%), the U.K (7.4%), Germany (4.8%), and Australia (3.9%).
  
• REDCap version 16.0.17 represents a third of all observations, followed by 16.1.4 at 4.93% and 16.0.15 at 3.34%. Based on Censys observations, 17.1.3 appears to be the latest version available, and just 1.18% of instances are on this patch version. 

Introduction

REDCap is a browser-based platform for collecting and managing research data, developed and distributed by Vanderbilt University to a group of academic, healthcare, and non-profit organizations. By design, the software is often exposed to the Internet to facilitate collaboration and enable study participants to access the platform. 

In a report published on June 15, 2026, Google Threat Intelligence Group (GTIG) attributed a “sophisticated” campaign targeting North American academic, medical, and military researchers to UNC6508, a People’s Republic of China (PRC)-nexus threat actor. 

While the initial access method is currently unconfirmed, UNC6508 exploited a public-facing REDCap server to drop a webshell and deploy INFINTERED malware, a PHP backdoor. Using this method, the actor maintained access to sensitive environments for over a year and collected information from sensitive systems, abused administrative tools for data exfiltration, and deployed additional malware.

Patch management for this is likely complicated for academic users who maintain self-hosted installations of REDcap, where available versions and how they’re rolled out depend on your institution’s IT team. REDcap states that new long-term support releases are rolled out every 6 months.

Censys ARC Perspective

Geography

The U.S. dominates the exposure landscape of REDCap instances (40%), followed by the U.K. (7.4%), Germany (4.8%), and Australia (3.9%). While most instances are concentrated in the U.S. and Europe, there is a long tail of instances across more than 100 countries, including China (2.5%), India (2.4%), and South Africa (2.1). The global spread illustrates it’s a popular tool with wide adoption.

Networks

A plurality of REDCap instances are cloud deployments—primarily Amazon and Microsoft, though Alibaba Cloud, OVH, and Digital Ocean are also among the top autonomous systems where we observe REDCap instances.

Research institutions like the U.K’s Janet Network (Jisc), Germany’s National Research and Education Network (DFN), and Italy’s Research and Education Network (GARR) also host instances of REDCap on their dedicated networks.

Versions

We find that 16.0.17 is the most commonly observed version of REDCap deployed, representing just over 30% of all Internet-facing deployments. 16.1.4, the next largest concentration of versions, represents just 4.93%.

It’s unclear from REDCap’s website when each of these versions were released, but existence of 17.x.x releases suggest that 16.x.x versions may be somewhat outdated. 17.1.3 appears to be the latest version available, and only 1.18% of instances are running this patch version as of June 16, 2026.

Mitigation: What Can Be Done?

• REDCap operators should assemble a comprehensive inventory of instances and ensure they are patched to the latest version available. 
• As REDCap notes in their documentation on best practices, “much of the security surrounding REDCap has nothing to do with the REDCap software itself but rather is dependent upon the IT infrastructure and environment in which REDCap has been installed…Typical best practices are that the web server and database server be two separate servers and that the database server be located securely behind a firewall.”
• Enforce multi-factor authentication on administrator accounts at a minimum.

The post REDCap on the Internet: An Exposure Analysis appeared first on Censys.

Security Operations teams are being asked to move faster, investigate more accurately, and utilize automation and AI to understand what is happening across not only their own environments, but outside their firewall as well. Google helps teams achieve this through the SecOps platform, but as SOCs are pressured to deliver on faster triaging, more in-depth investigations, wider hunting, and accurate detections, one thing becomes clear: quality, high-fidelity, world-class adversary external Internet intelligence data is key to fulfilling the goals of the AI-enabled SOC.

This is where Censys steps in.

Censys provides the foundational Internet mapping data that gives Google SecOps users rich, real-time context about IPs, web properties, certificates, active DNS, history, adversary clusters, and relationships — all in real-time. With the Censys for Google SecOps SOAR integrations, teams can automatically enrich their alerts with Censys data and get all the context they need to make quick, accurate decisions that proactively protect their organization.

Why External Infrastructure Context Matters

Many alerts begin with a simple indicator: an IP address, domain or certificate hash, for example. On its own, this indicator only tells part of the story. An analyst still needs more detail, such as:

• Is this infrastructure newly spun-up or has it been around for awhile?
• What services are exposed?
• Any certificates associated with it?
• Is this host malicious?
• Is that indicator related to other suspicious infrastructure?
• Was this service active when the incident was triggered?
• Has the host changed recently?
• Is this something we should block, hunt deeper, escalate or ignore?

Without context, analysts lose time pivoting across different tools, ingesting from multiple data sources, and reconstructing relationships to answer those questions above. It doesn’t matter whether those tasks are completed manually or automated with the help of AI; if the contextual data isn’t at the forefront of any decision, investigation, or detection, then teams will not get the results they expect, no matter how much AI they throw at it.

Censys closes that gap by bringing Internet-scale intelligence directly into Google SecOps workflows, so that those questions are answered immediately without needing to look elsewhere. And by injecting contextualized, evidence-backed data at the start, organizations can even reduce AI token costs.

Google SecOps + Censys: Enrichment Where Analysts Already Work

Google SecOps supports enrichment of indicators, events, and cases through playbooks, helping teams add context throughout their investigation, triage, detection and response workflows. The Censys integration extends that model with external Internet mapping intelligence without requiring analysis to leave their SecOps workflow. Censys actions can be run directly from a SecOps case or triggered automatically through playbooks. Currently, the integration supports these key actions:

• Entity enrichment for hosts, web properties and certificates. This can be a manual enrichment or automated.
• Rescan actions to refresh Censys observations outside of the scheduled scan.
• Historical lookups to understand how an asset has changed over time.
• Related infrastructure discovery to identify clusters of interest from an indicator.

This creates a stronger foundation for triage, threat hunting, detection engineering, and incident response use cases — everything that the AI-enabled SOC needs.

Let’s explore how Google SecOps + Censys works for each use case.

Use Case #1: Faster, Higher Confidence Alert Triaging

In a traditional SOC workflow, alert triage often starts with a basic question: “Is this worth investigating?”

Censys helps answer that question faster.

When an alert contains an IP address, domain, web property, or certificate, Google SecOps can invoke Censys enrichment to return external context such as exposed services, certificates, host details, web technologies, and security configurations. The actual IP address is also scored by Censys through its intelligent Reputation Scoring method that instantly lets analysts know if it’s malicious, high risk, medium risk, low risk, or benign. 

If the Reputation Score is used in automated workflows, analysts can confidently triage thousands of alerts within minutes by ignoring the benign and low risk and concentrating on only malicious and high risk hosts.

The overall result is faster, accurate triaging with clearer reasoning.

Use Case #2: Threat Hunting Across Related Infrastructure

Threat hunters rarely care about a single IOC in isolation. The real value comes from understanding the broader cluster of infrastructure that surrounds it.

Censys enables this by allowing hunters to pivot from one observable IOC into related infrastructure. Through the Google SecOps integration, users can use the powerful CensEye to discover related assets for a host, web property, or certificate. This is especially valuable when threat actors reuse infrastructure patterns rather than exact indicators. A single IP may rotate out, but certificates or other configurations or naming conventions may reveal a larger campaign. 

Inside Google SecOps, this allows hunters to move from an isolated IOC to an infrastructure-led investigation. This, in turn, supports a more proactive approach in the AI-enabled SOC, where teams proactively uncover adversary footprints instead of waiting for that indicator to become an alert in the future.

Use Case #3: Detection Engineering With Internet Mapping Context

Detection engineering becomes more powerful when rules are informed by external infrastructure context.

Google SecOps supports customer detection authoring using YARA-L and also enables users to leverage natural language and Gemini to search, iterate, drill down, and create detections. Censys now adds another layer: infrastructure intelligence that can help detection engineers understand what to look for and why it matters.

For example, detection engineers can use Censys to identify patterns such as:

• Newly exposed services associated with suspicious infrastructure.
• Certificates reused across multiple suspicious hosts.
• Web properties sharing technologies with known malicious infrastructure.
• Infrastructure that appears, disappears, or changes during a campaign window.
• Hosts with service histories that align with attacker staging or payload delivery.

This can help detection engineering teams move beyond static IOC-based detections and towards behaviorally informed infrastructure-aware detections. The value is not just detecting one bad IP, but understanding the infrastructure pattern well enough to detect the next one.

Use Case #4: Incident Response With Historical Asset Context

During incident response, timing matters.

Responders need to know what an external host looked like at the time of an event, not just what it looks like now. Censys historical data helps teams understand how a host appeared at a particular point in time, with scan snapshots and event history showing when services were added, removed or modified.

This is critical when investigating callbacks, credential theft, phishing infrastructure, or suspicious outbound connections. An IP may no longer expose the same service by the time an analyst investigates. A domain may have changed hosting providers. A service may have appeared briefly and disappeared, or a certificate may have rotated.

With Censys historical lookups available through the Google SecOps integration, responders can investigate infrastructure as it existed during the relevant incident window, helping teams track changes over time and giving incident responders better evidence for containment, scoping, and post-incident analysis.

Use Case #5: Rescans, Refreshing The Internet View When It Matters

Internet infrastructure changes constantly. Attackers rotate services, move infrastructure on the fly, update certificates, and stand up short-lived assets.

For the first four use cases, analysts need the latest view; the context they had just a few hours ago may already be out of date. A rescan lets analysts scan for any changes on-demand rather than having to wait for the scheduled scans, which may be too late. With the Censys rescan integration, Google SecOps can initiate a rescan of all data and return a scan ID that can be used to monitor status. This is especially useful when:

• An alert references infrastructure that may have changed since last observation.
• A suspicious service needs to be verified before escalation.
• A responder wants to confirm whether exposed infrastructure is still active.
• A hunter wants the freshest possible data before expanding an investigation.

For the AI-enabled SOC, rescans help ensure that automated reasoning is grounded in truth and current evidence, not stale observations.

Conclusion

The future SOC will not be defined by automation per se; rather, it will be defined by the quality of the data that powers automation and AI.

Together, Google SecOps and Censys can help security teams:

• Triage alerts faster with richer infrastructure context.
• Hunt beyond isolated IOCs into related infrastructure.
• Create stronger detections based on observable infrastructure patterns.
• Investigate incidents using current and historical internet asset data.
• Invoke manual or automated enrichment directly inside existing SOC workflows.
• Refresh observations with rescans when the latest Internet view is needed.
• Use CensEye to uncover related infrastructure and support deeper adversary investigations.

For the AI-enabled SOC, this is the difference between just reacting to alerts and being able to understand the infrastructure behind them. 

Google and Censys are the perfect partners to enable AI-assisted security operations to be faster, more accurate, and more actionable than ever before.

The post Powering the AI-Enabled SOC with Censys Internet Intelligence and Google SecOps appeared first on Censys.

• A live smishing campaign delivered by SMS impersonates United States Postal Service (USPS)  package delivery. The lure is not a hand-built knockoff. The kit serves USPS’s own production HTML, CSS, fonts, and images verbatim from the phishing host, complete with USPS’s live Google Analytics tag firing against USPS’s real marketing infrastructure.
• Underneath the deception the kit captures data in real time. It opens a WebSocket back to its origin and streams the victim’s card data keystroke-by-keystroke, runs a server-side BIN lookup on the card number, and pushes routing decisions (retry, PIN prompt, OTP prompt, kill-switch) back into the victim’s browser while they type. This was captured live, not inferred from source.
• The lure arrives as a single hostname. Censys passive DNS turned that one host into the whole operation. A single seed IP resolved to over a hundred lookalike subdomains, and across the confirmed cluster Censys recorded 682 unique lookalike hostnames (snapshot 2026-05-20), most of which no longer answer in live DNS but remain in Censys’s historical record.
• Pivoting on the kit’s HTTP banner hash carried the hunt from the USPS lure host onto a sibling running a second campaign from a Tencent prefix that impersonates UPS instead of USPS, on a Java/Spring Boot backend instead of the USPS kit’s Go backend. Both campaigns bake the operator’s own internal theme name, us_post_ups, directly into their cookies. Same operator, two brands, one kit family.
• The durable detection signals are structural, not cosmetic: the /us_post_usps/ asset path, the theme_*_verify_us_post_ups cookie family, the valid_<14digits>_<32hex> token shape, and a banner hash that returns exactly the five UPS-themed (not USPS) hosts globally. Hostnames and IPs rotate weekly. These do not.

It Starts With a Text Message

You know the message. Everyone has gotten one. A package could not be delivered, there is an unpaid customs fee or a bad address, and here is a helpful link to fix it. This one pointed at:

https://usps.xupqnqz[.]one/uqjmw

Believe it or not, xupqnqz[.]one is not USPS (United States Postal Service). It is a six-character random string on a .one domain, prefixed with the comforting subdomain usps. That usps. label is the entire con. On a phone, with the real domain truncated in a narrow address bar, the leftmost thing the victim reads is “usps”. The kit operator is betting the rest never gets read.

Tap the link and you do not land on a fake mailbox right away. You hit a “Security Check” page that is a pixel-faithful clone of Cloudflare’s “Verify you are human” interstitial: the orange shield, the rounded checkbox, the Performance & security by Cloudflare footer. It even ships a twelve-language translation table and picks your language from navigator.language, so the lure speaks English, Spanish, Chinese, Arabic, and eight others without the operator lifting a finger.

This is the modern smishing pattern: wrap the scam in the most boring, most trusted interaction on the web. Nobody is suspicious of a Cloudflare check. We are all trained to click it and move on. That is exactly what the kit wants.

For the purposes of this post, though, the interesting move is not the lure. It is what happens when you take that one hostname to Censys and start pulling on the thread.

One Host, and What Censys Already Knew About It

The lure hostname resolves to `43.157.174.200`, a Tencent Cloud machine in 43.157.128.0/18, ASN 132203. A normal first step. The interesting step is the second one.

Censys does not just tell you what is running on 43.157.174.200 right now. It tells you every hostname it has ever seen resolve to that IP. Pull the host’s DNS view and the single SMS hostname explodes into roughly a hundred siblings, all variations on the same two themes:

• usps.xupq*.one (the SMS lure’s exact shape, with a rotating four-to-six character tail)
• informed.deliwek*.shop (a nod to “Informed Delivery”, USPS’s real free mail-preview product)

That is the moment a single-link phishing report turns into an infrastructure hunt. The operator is not running one domain. They are running a domain factory, and one IP is hosting the whole catalog.

Following the DNS

This is the part of the investigation I want to dwell on, because it is the part that Censys makes almost unfairly easy and that you cannot reproduce with live DNS alone.

Active DNS answers one question: what does this name resolve to right now. Smishing operators have read that memo. The lure hostname in your text message is meant to live for hours, maybe a day, then go dark. Resolve it next week and you get nothing. The infrastructure looks like it evaporated.

It did not evaporate. It rotated. And Censys’s DNS resolutions data keeps the receipts.

Querying Censys’s resolutions API for the seven IPs that ultimately make up this cluster returns 682 unique hostnames as of the 2026-05-20 snapshot. The shape distribution is the operator’s whole playbook on one page:

Most of these names return nothing if you dig them today. They are spent. But they all sit in Censys’s history with first_seen and last_seen timestamps, which lets you reconstruct the rotation cadence and, more usefully, prove that a domain you just received in a fresh lure belongs to infrastructure that has been burning through names for weeks. The single host 43.157.174.200 alone accounts for 306 of those names. Two of its siblings carry another 197 and 202.

A defender who only has the live hostname sees one disposable domain. A defender with Censys sees the disposable-domain *generator* and every name it has emitted. That is the difference, and it is the whole reason this investigation got interesting instead of dead-ending at a 404.

What the Lure Actually Does

Before chasing the rest of the infrastructure, it is worth understanding what is waiting at the end of the link, because the kit’s mechanics are genuinely a step above the average phishing page.

Click the fake Cloudflare checkbox and the page makes a JSONP call to /eat?callback=jsonpCallback_<timestamp>, which hands back a token shaped like valid_20260521033009_cfe592644a1fdc56930624518ab3bcf7, that is, valid_<YYYYMMDDhhmmss>_<32-hex>. The endpoint also sets a gfsessionid cookie, the default cookie name of the Go GoFrame web framework. That cookie is our first tell about the backend stack. The “CAPTCHA” itself is theater: the callback parameter is never validated, so the gate’s only real job is to keep casual visitors and crawlers from deep-linking straight to the payload.

Token in hand, the page boots a Vue 3 single-page app (/assets/index-02f64fb4.js, a 444 KB Vite bundle) titled Welcome | USPS, and here is the design choice that makes this kit worth writing about. It does not draw a fake USPS page. It serves the visually compelling version, that to the victim appears to be a real one. Every template, stylesheet, font, and image is USPS’s genuine production asset, fetched straight off the phishing host under the path prefix /us_post_usps/. A single victim session pulls 66 distinct USPS-owned files, roughly 700 KB: USPS’s head.html, header.html, and footer.html, USPS’s Bootstrap CSS, two dozen navigation icons, the hero images, even six USPS-licensed Monotype web fonts.

Because the kit serves USPS’s real head.html verbatim, it also serves the live tags embedded in it: USPS’s Google Analytics 4 property G-CSLL4ZEK4L and a Google AdServices conversion beacon pointed at https://www.usps.com/. Every victim browser that touches this kit fires analytics hits into USPS’s own marketing pipeline. That is an odd and very useful artifact: USPS’s marketing team is, in principle, the one party on earth who can see this campaign’s traffic landing on their conversion dashboards from domains they do not own.

The /us_post_usps/ prefix is the cleanest detection seam in the whole kit. It exists nowhere on the real usps.com. Any browser fetching /us_post_usps/pages/head.html is, by definition, on the kit, no matter which throwaway hostname it arrived through.

Image: V1 USPS package lure rendered from USPS’s own templates

Now the part the victim never sees. As they fill in the form, the SPA opens a WebSocket to wss://<host>/ws?token=<UUIDv4> and streams what they type, character by character. We captured this live (279 WebSocket frames across seven sessions), not from reading the bundle. The capture shows the kit exfiltrating each stabilized keystroke as it lands:

{"event":"input_text","content":{"type":"input_card","key":"cardName","text":"Rob"},...}
{"event":"input_text","content":{"type":"input_card","key":"cardName","text":"Robert Bbase"},...}
{"event":"input_text","content":{"type":"input_card","key":"cardName","text":"Robert Base"},...}
{"event":"input_text","content":{"type":"input_card","key":"cardNumber","text":"4242424242424242"},...}
{"event":"input_text","content":{"type":"input_card","key":"cvv","text":"145"},...}

Note the typo Robert Bbase and its correction both reach the operator. Every intermediate state of the card number, expiry, and CVV is captured before the victim ever clicks submit. A parallel HTTP POST to /<random>/api/input double-ships the same values, so an abandoned, half-typed card is still harvested.

When the form is finally submitted, the operator’s backend does something most kits do not bother with. It runs a server-side BIN lookup (to validate the format of the value to protect against bogus data) against the card number and pushes the enriched record back into the victim’s browser over the same socket:

{
  "event": "result_type",
  "content": {
    "type": "reject",
    "value": { "data": {
      "cardData": {
        "cardBIN": { "bin": 424242, "bank": "STRIPE PAYMENTS UK, LTD.",
          "country": "UNITED KINGDOM", "schema": "VISA", "type": "CREDIT", "level": "CLASSIC" },
        "cardName": "Robert Base", "cardNumber": "4242424242424242", "expires": "02/30", "cvv": "145"
      },
      "cardHistory": [ ... ]
    }}
  }
}

Two things stand out. First, cardHistory is an array: the kit remembers every card the victim has tried in the session, which is exactly the data structure you build if you intend to trap a victim in a “your card was declined, try another” loop and skim a second and third card. Second, the data is streamed via websocket live. The periodic config the backend returns carries operator-controlled fields including a kill-switch (isBlock) that, when flipped, bounces the victim to the real www.usps.com, and two capture templates whose internal labels are in Chinese (PIN验证, “PIN verification”; 邮箱验证, “Email verification”) while every victim-facing string is in clean English. The operator works in one language and presents in another.

That dual-language config, captured straight out of the kit, is also the strongest in-artifact attribution signal we have. More on that below.

The Twin: A UPS Campaign Built on the Same Bones

Here is where the hunt paid off in a way I did not expect when I started with a single SMS link.

The seven hosts in this cluster did not come from DNS alone. DNS gave me the lookalike catalog on each known IP. To find the *other* IPs, I pivoted on what the kit looks like on the wire. The host’s HTTP service has a banner hash (http header hash), and one of those hashes turned out to be a near-perfect cluster boundary:

host.services.banner_hash_sha256="4fe8bec780537aa223406965415c1f85e83eec1f4e2181cf82e2a7b7516026e6" and host.services.protocol="HTTP"

That query returns exactly five hosts, globally. Not five thousand. Five. And they are spread across two different Tencent /18 prefixes (43.157.128.0/18 and 43.173.64.0/18), which is the tell that the operation is bigger than the prefix the lure lives on.

When I pulled those five hosts and visited them, they were not USPS. They were UPS.

The UPS variant (call it V2) wears a similar fake Cloudflare gate, but the machinery behind it is a different build:

• The gate is English-only, with no twelve-language table, but the HTML hard-codes <html lang="zh-CN">: a Chinese locale stamped on an English page, a small slip that survived the re-skin.
• Instead of the JSONP token, clicking through fires a redirect chain: /__theme/runtime/entry/verify sets a cookie and 302s off-domain to xupqrnn[.]one/us?__theme_site_ticket=<32hex>, which chains through /__theme/runtime/site/pass and lands on the UPS SPA.
• Both hops in that chain set a cookie, and both cookie names, contain the literal string us_post_ups: theme_entry_verify_us_post_ups and theme_site_verify_us_post_ups. That is the operator’s own internal name for the kit’s “theme”, leaked twice, in two independent endpoints. Neither name has any business existing on real UPS or USPS infrastructure, which makes either one a SIEM-grade indicator on its own.
• The UPS SPA’s favicon still points at /usps/images/logo_mobile.svg. The brand on screen says UPS; the favicon path says USPS. That is a fork artifact, left in place when the operator copied the USPS kit and re-themed it for UPS.
• The backend is no longer Go. Request any path the kit does not route and you get Spring Boot’s stock JSON error, timestamp and all:

{"timestamp":"2026-05-21T05:33:43.670+08:00","status":404,"error":"Not Found","path":"/__theme/runtime/entry/verify"}

Image: V2 UPS lure, same kit family, different brand

The second campaign represents a sibling within the same kit lineage that mirrors the real-time exfiltration model, the Tencent hosting footprint, and the shared Caddy reverse proxy, yet it swaps the USPS costume for a UPS one across two distinct technical platforms, GoFrame and Spring Boot. It is the signature of a single operator managing parallel brands, where the infrastructure and code heritage are shared, even if the specific backend implementation is not.

Same Operator, Two Brands

Lining up the two variants side by side makes the shared parentage hard to miss, and gives defenders a clean V1-versus-V2 discriminator.

The seven confirmed hosts break down as two V1 USPS hosts and five V2 UPS hosts:

*43.157.158.108 showed no HTTP service and zero DNS names in the snapshot, only SSH on a different OpenSSH build than its siblings. A live probe against one of its usps.xupq*.one names returned Server: GoFrame HTTP Server with a valid JSONP token, confirming it as a second V1 USPS host whose web service simply was not in the cache at scan time.

A few infrastructure notes that shape how durable each pivot is:

• All six HTTP-serving hosts share one port-443 TLS banner hash and front everything with Via: 1.1 Caddy. The shared TLS config is real, but on its own the TLS hash is far too common (over a million hits) to use globally; it only becomes useful ANDed with the Tencent ASN.
• Six of the seven run the same OpenSSH 8.9p1 build, yet every host has a distinct SSH host key. Identical golden-image clones would share host keys. These do not, which means the operator provisions each VM individually. SSH host-key pivoting is therefore a dead end here, worth saying out loud so nobody wastes time on it.
• Nobody is patching. Every host carries the same stale SSH CVE set, regreSSHion (CVE-2024-6387) and friends, untouched. That is consistent with a spin-up, run-until-burned, abandon model. Potentially attributed to the vendored image of the hosting provider.

Where Is This Thing, Actually?

Geolocation on this cluster is a useful reminder that the obvious answer is usually wrong. The seven hosts give four different “locations” depending on which signal you trust:

None of São Paulo, Santa Clara, Singapore, or Beijing is a reliable physical-server location. The realistic read is: VMs inside Tencent’s overseas cloud, billed to a Singapore entity, owned by a Chinese ASN, with geo-IP records that reflect intended customer regions rather than where the metal sits.

The one signal that shows up consistently is the +08:00 server clock, emitted independently by both backends (the Go kit’s token timestamp and the Spring Boot kit’s JSON error timestamp). That is the servers’ configured locale, Asia/Shanghai, and it is worth being precise about what it does and does not tell us. It is a property of the deployment, not a GPS pin on the operator. A Chinese-speaking operator working from anywhere can set their Linux boxes to CST.

On Attribution

I am going to be disciplined here, because this is where smishing writeups tend to over-reach.

Everything about this kit is consistent with the loosely-tracked Chinese-language smishing-as-a-service ecosystem often labeled “Smishing Triad”: the USPS and delivery-brand themes, the multilingual fake Cloudflare gate, the Tencent-on-Singapore-whois hosting, the dual-language operator config with Chinese internal labels and English victim copy, and the polished realtime card-skimming with server-side BIN enrichment. Those are real, in-artifact signals.

What I do not have is a shared TLS certificate, a shared backend IP, or a shared body hash tying this specific infrastructure to a previously published IOC list. So I am not asserting attribution to that cluster or to any named operator. The evidence supports “consistent with a known ecosystem,” and stops there.

Hunting It Yourself

The whole point of doing this in Censys is that you can reproduce and monitor it. Here are the pivots, ordered by how durable I expect them to be.

Strongest, the V2 banner hash (returns exactly the five UPS-themed hosts):

host.services.banner_hash_sha256="4fe8bec780537aa223406965415c1f85e83eec1f4e2181cf82e2a7b7516026e6" and host.services.protocol="HTTP"

The V1 USPS banner hash (separates the GoFrame USPS hosts):

host.services.banner_hash_sha256="8e5546c83d764e1287b55cbe868a45344a6f0afa9782d798d03b2b7cfc53ec38" and host.services.protocol="HTTP"

JA4T transport fingerprints, scoped to the Tencent ASN so they stay tight (they survive application-layer re-skins that would flip the body or banner hash):

host.services.ja4tscan.fingerprint="65160_2-4-8-1-3_1424_7_1-2-4-8-16" and host.autonomous_system.asn=132203
host.services.ja4tscan.fingerprint="59136_2-4-8-1-3_1424_7_1-2-4-8-16" and host.autonomous_system.asn=132203

The first matches the cluster hosts in 43.157.128.0/18; the second the hosts in 43.173.64.0/18.

And the move that started everything: take any one of these IPs (or a fresh lure hostname) and pull its DNS history in Censys. That is what turns a single disposable domain into the operator’s whole rotation.

For Defenders

Hostnames and IPs in this operation are disposable by design. Detections written against them go stale in days. Detections written against the kit’s structure should outlive several re-skins.

The Tencent prefixes 43.157.128.0/18 and 43.173.64.0/18 are also reasonable block-list candidates for most enterprises, since legitimate destinations on operator-occupied overseas cloud prefixes are rare.

Conclusion

The lesson I keep relearning is that the artifact in your messages inbox is the smallest part of the story. One USPS smishing text gave up one hostname. That hostname gave up one IP. And Censys’s view of that IP, especially its DNS history, unrolled an operation with hundreds of disposable lookalike domains, a real-time operator-piloted skimming kit that serves the genuine USPS website as its own bait, and an entire parallel UPS campaign built on the same kit and the same internal theme name.

What makes DNS so valuable here is that it is the one layer the operator cannot make disposable. They can burn a hostname in a day, rotate an IP, re-skin USPS into UPS, swap Go for Java. What they cannot do is un-resolve the names they have already used, because Censys already saw them. The cosmetic layer is cheap and changes constantly. The structure, the asset paths, the cookie theme name, the banner hash, and the DNS history, is where the operation actually lives, and it is where it can be tracked.

Indicators of Compromise

Cluster hosts (Tencent, ASN 132203)

43.157.174.200    V1 USPS (GoFrame)   43.157.128.0/18
43.157.158.108    V1 USPS (GoFrame)   43.157.128.0/18
43.157.151.131    V2 UPS  (Spring)    43.157.128.0/18
43.157.148.168    V2 UPS  (Spring)    43.157.128.0/18
43.173.100.171    V2 UPS  (Spring)    43.173.64.0/18
43.173.104.156    V2 UPS  (Spring)    43.173.64.0/18
43.173.105.83     V2 UPS  (Spring)    43.173.64.0/18

Lure / handoff hostnames

usps.xupqnqz[.]one      V1 USPS lure

xupqnqz[.]one           V1 apex

gwrpfjx[.]life          V2 UPS lure

xupqrnn[.]one           V2 cross-domain handoff

Hostname-generation shapes (hundreds of disposable instances)

usps.xupq*[.]one          78 observed

informed.deliwek*[.]shop  250 observed

*[.]life (random apex)    334 observed

deliwek*[.]shop           17 observed

Banner hashes

4fe8bec780537aa223406965415c1f85e83eec1f4e2181cf82e2a7b7516026e6   V2 UPS (port 80, 5 hosts globally)
8e5546c83d764e1287b55cbe868a45344a6f0afa9782d798d03b2b7cfc53ec38   V1 USPS (port 80)

Cookies / paths / token shape

gfsessionid                          GoFrame default (V1)
theme_entry_verify_us_post_ups=1     V2 redirect chain
theme_site_verify_us_post_ups=1      V2 redirect chain
/us_post_usps/                       V1 USPS-asset path prefix
/__theme/runtime/entry/verify        V2 handoff
/__theme/runtime/site/pass           V2 handoff
valid_<YYYYMMDDhhmmss>_<32-hex>      V1 JSONP token shape

More Reading

1. Resecurity, “‘Smishing Triad’ Targeted USPS and US Citizens for Data Theft” (Aug 2023), the original naming of the cluster. https://www.resecurity.com/blog/article/smishing-triad-targeted-usps-and-us-citizens-for-data-theft
   
2. Brian Krebs, “Phishers Spoof USPS, 12 Other Nat’l Postal Services,” Krebs on Security (Oct 2023), an early account of the USPS-themed campaign and its reuse of USPS’s own Google Analytics tag. https://krebsonsecurity.com/2023/10/phishers-spoof-usps-12-other-natl-postal-services/

3. Silent Push, “Smishing Triad: Chinese eCrime Group Targets 121+ Countries, Intros New Banking Phishing Kit” (Apr 2025), documents the Lighthouse kit and its real-time front-end-to-backend victim sync. https://www.silentpush.com/blog/smishing-triad/
   
4. Palo Alto Networks Unit 42, “The Smishing Deluge: China-Based Campaign Flooding Global Text Messages.” https://unit42.paloaltonetworks.com/global-smishing-campaign/

5. Google, “Fighting scams with legal and legislative action” (Nov 2025), Google’s civil action against the operators of the Lighthouse phishing-as-a-service kit. https://blog.google/company-news/outreach-and-initiatives/public-policy/legal-action-and-legislation-fight-scammers/

6. Brian Krebs, “Google Sues to Disrupt Chinese SMS Phishing Triad,” Krebs on Security (Nov 2025), names “Wang Duo Yu” and “CoSmile” as the kit developers. https://krebsonsecurity.com/2025/11/google-sues-to-disrupt-chinese-sms-phishing-triad/

The post The Package That Never Shipped: Following a USPS Smishing Kit Through Censys DNS Data appeared first on Censys.

Security has always been a cat-and-mouse game between attacker and defender. Reaper answered Creeper in 1972. VirusScan arrived in 1987. EDR, SIEM, CTI, and vulnerability management all emerged because defenders and attackers forever adapted to one another.

Mythos is the latest turn of that wheel. The wrinkle this time is speed. Ease of automation.

As of May 22, 2026, Mythos Preview has found what it estimates are 6,202 high- or critical-severity vulnerabilities across 1,000+ open-source projects. Less than 1% have been patched or have public disclosures.

An example: this FreeBSD NFS remote code execution flaw. 

As for adversary usage of frontier models, Anthropic has also reported a large-scale espionage campaign where attackers used agentic AI to carry out major portions of the operation across dozens of targets.

AI is automating away repetitive work everywhere. Cybercrime is no different. Agents can handle reconnaissance, testing, reproduction, exploit development, infrastructure recycling, and operational follow-through. 

Censys has always hung our hat on our superior speed, going back to our ASM announcement in 2019. The AI breakthroughs have been staggering since then – we never anticipated how prescient our desire was to build a real-time map of the entire public Internet.

Censys Attack Surface Management helps security teams understand what they expose. Censys Platform helps SOC, CTI, and detection engineering teams understand what adversaries expose.

In the Mythos era, both matter. Let’s talk about why, starting with exposures.

Exposure Management in the Mythos Era

Exposure management is the practice of continuously finding, validating, prioritizing, and reducing Internet-facing risk when AI can accelerate vulnerability discovery, exploit development, and attacker reconnaissance.

Same as it always was, just under a faster clock.

Why ASM Becomes the First Control Plane

Censys cannot protect against every path to compromise.

Social engineering exists. Identity attacks exist. Insider risk exists. Supply chain compromise exists. A user can still approve a bad OAuth grant, enter credentials into a fake login page, or run something they should not run.

But if an attacker, or an army of agents working for an attacker, wants to operate at scale, the public Internet is the lowest-lift place to start.

It is remote. It is parallelizable. It is measurable. It is full of services, ports, certificates, software, DNS records, cloud resources, admin panels, developer tools, forgotten test environments, and vulnerable systems waiting to be found.

That makes ASM the first control plane for Mythos-era exposure management.

Traditional disciplines (vulnerability management, cloud security, NDR alerts, etc.) still matter. But when the vulnerability is Internet-reachable, outside-in visibility becomes the first line of prioritization.

Censys ASM helps answer the questions that matter in that moment:

• What assets do we expose?
• Which services are reachable?
• Which ports are open?
• Which software, certificates, protocols, and web properties are present?
• Which vulnerabilities are associated with those services?
• Which exposures changed recently?
• Which risks should remediation teams handle first?

In an AI-speed vulnerability cycle, that context is not a luxury. It is how teams decide what to fix first.

The Exposure Problem AI Makes Impossible to Ignore

Most organizations do not have one clean, static attack surface.

There are mergers, subsidiaries, regional teams, contractor-managed infrastructure! 

And you’re bound to have abandoned projects and experiments. Forgotten load balancers. Old DNS records. SaaS configuration buried in portals, each with a different solitary admin. Temporary GPU instances. Jupyter notebooks. AI demos. 

A traditional inventory might know the approved assets. A cloud console might know what exists in one provider. A vulnerability scanner might know what it can reach on expected ports. A CMDB might know what someone remembered to register.

Attackers do not care about those boundaries. They care about what is reachable.

That is why Censys ASM continuously maps the public-facing attack surface. Teams need to see what the Internet sees, not just what their internal systems believe should exist.

If AI helps attackers test more hosts, more ports, more paths, more headers, more version combinations, more default panels, and more obscure service fingerprints, then the defender’s data has to keep up.

“AI will magically exploit every vuln” – no. It’s dumber than that: more automation creates more attempts. Brute force by intelligent, subject-authoritative bots.

Censys ASM: Comprehensive Coverage for AI-Speed

Censys ASM is built for the problem Mythos amplifies: discovering and prioritizing Internet-facing exposure before it becomes an incident.

If your ASM program only looks where you expect services to live, it will miss the places where real risk accumulates. AI tools and developer infrastructure often do not show up on a tidy list of standard ports. They show up wherever someone got a demo working, opened a port, pushed a test environment, or forgot to clean up.

Censys ASM helps teams discover assets and services across the public Internet, including non-standard ports and unexpected service locations. That matters when the riskiest exposure is not the corporate website. It might be an AI service, Jupyter notebook, model dashboard, admin panel, debug server, or forgotten development tool listening somewhere your normal controls do not inspect.

Playbook 1: Find What Others Miss Across All 65,535 Ports

A lot of exposure management failures begin with a vendor assumption:

“Nobody runs that there.”

Except – someone does!

AI and ML tools are a good example. Ollama, Jupyter, TensorBoard, MLflow, Spark, Ray, Xinference, local LLM UIs, GPU dashboards, and experimental model services can appear on non-standard ports. Some are intended for local development. Some are spun up for a week. Some are created by data science teams that move faster than security review. Some are forgotten after the demo.

That is exactly the kind of asset an attacker would rather find before you do.

A Mythos-era exposure management program should start with full-port visibility and searches for AI-adjacent services.

Example ASM QL patterns:

host.services.http.response.body: {Ollama, Xinference}
or web_entity.instances.http.response.body: {Ollama, Xinference}
or host.services.port: {11434, 8080, 7860}
or web_entity.instances.port: {11434, 8080, 7860}

For broader AI and ML workflow detection:

host.services.port: {8888, 6006, 5000, 7077, 8080, 8265}
or host.services.software.product: {Jupyter, TensorBoard, MLflow, Spark, Ray}
or host.services.service_name: {Jupyter, TensorBoard, MLflow, Spark, Ray}
or web_entity.instances.port: {8888, 6006, 5000, 7077, 8080, 8265}
or web_entity.instances.software.product: {Jupyter, TensorBoard, MLflow, Spark, Ray}
or web_entity.instances.service_name: {Jupyter, TensorBoard, MLflow, Spark, Ray}

The goal is not to declare every AI tool malicious.

The goal is to find Internet-facing AI infrastructure that security did not approve, does not monitor, or cannot explain.

That is the difference between “we have a policy” and “we know what is exposed.”

Playbook 2: Triage New Vulnerabilities During Resolution Hour

When a critical CVE is disclosed, most organizations enter some version of the same scramble. 

In the Mythos era, that first hour matters more. Call it Resolution Hour.

The objective is not to fix everything in 60 minutes (wouldn’t that be nice). The objective is to resolve the most important uncertainties quickly.

A strong Resolution Hour workflow looks like this:

1. Search ASM for affected software, products, services, ports, banners, web fingerprints, and vulnerability identifiers (using the Censys ARC rapid response queries).
2. Prioritize assets exposed to the public Internet.
3. Check whether Censys indicates active exploitation or other high-risk context.
4. Segment findings by ownership, business unit, cloud provider, geography, or asset tag.
5. Route the most urgent assets into remediation workflows.
6. Set alerts so newly discovered exposure is not missed after the first search.

This is where Censys ASM and vulnerability management meet.

Vulnerability management teams have massive lists of theoretical risk. Censys ASM helps identify reachable risk. The intersection helps set priorities for the entire program.

Playbook 3: Hunt for Shadow AI and Exposed AI Services

Again, let’s use AI tools as an example. Businesses are urging their use faster than methodologies can be vetted. 

Data scientists, engineers, analysts, and product teams are experimenting with AI tools recklessly to fulfil these mandates. Security doesn’t need to block all of that (arguably), but does need to know when it becomes an exposure.

Censys ASM helps teams identify AI-related cloud assets using provider metadata, tags, service fingerprints, and exposed ports.

Example ASM QL pattern for cloud-tagged AI experiments:

(
  host.cloud: {aws, google, azure, "Amazon Aws", "Google Cloud", "Microsoft Azure", "Microsoft Corporation"}
  or cloud.aws.tags.value: *
  or cloud.gcp.tags: *
  or cloud.azure.tags: *
)
and
(
  cloud.aws.tags.value: {"ai-test", "gpu-instance", "jupyter"}
  or cloud.gcp.tags.value: {"ai-test", "gpu-instance", "jupyter"}
  or cloud.azure.tags.value: {"ai-test", "gpu-instance", "jupyter"}
  or tags: {"ai-test", "gpu-instance", "jupyter"}
  or host.tags: {"ai-test", "gpu-instance", "jupyter"}
)

That query is not the end state. It is a starting point.

Every organization will have its own naming conventions. Search for your internal project names, GPU naming patterns, model names, business unit tags, sandbox labels, and cloud account conventions.

Then operationalize it:

• Save the query.
• Alert on new matches.
• Send notifications to Slack, Teams, Jira, ServiceNow, or the workflow your teams already use.
• Review whether the exposure is approved, temporary, misconfigured, or dangerous.
• Track recurrence.

The important shift is that ASM is not just a dashboard. It’s a control loop.

Playbook 4: Close Dangling DNS Before Agents Follow It

Dangling DNS is exactly the kind of boring exposure that survives because everyone assumes someone else owns it.

A team shuts down a bucket, app, page, or third-party service. The DNS record stays behind. Now a trusted subdomain may still point at a resource your organization no longer controls.

Boom: subdomain takeover.

In the Mythos era, this matters even more. Dangling DNS is easy to automate. Attackers do not need a brilliant exploit chain to abuse a forgotten CNAME. They need to find it, claim the abandoned resource, and put content behind a domain your users and systems already trust.

Censys ASM helps close that gap by detecting dangling DNS risks across CNAMEs, NS records, and third-party services like S3, GitHub, Heroku, and others. These detections are powered by Censys Internet Map data, and ASM shows the impacted name, the DNS record, and the evidence behind the finding.

From there, the fix is usually straightforward: update or remove the stale DNS record, or reclaim the decommissioned resource before someone else does.

Playbook 5: Give AI Agents Safe Access to Real Attack Surface Data

Security teams are going to use AI agents too. They should; make it a fair fight.

But if an AI workflow is going to reason about your attack surface, it needs real data. Not a stale export or an old spreadsheet. 

Censys ASM MCP Server gives AI-assisted workflows structured access to verified attack surface data, so teams can ask practical questions:

• What Internet-facing assets are affected by this CVE?
• What exposed services appeared this week?
• Which AI-related assets are not approved?
• Which dangling DNS findings need review?
• Which high-risk exposures should become tickets?

Give your own agents bounded access to current, external visibility so it can help triage, summarize, and route work without hallucinating assets or working from stale data.

If attackers are using AI to move faster, defenders should too. The pattern is, AI needs current and correct context.

Now, Where Does Censys Platform Fit?

Censys ASM answers one half of the Mythos problem:

“What do we expose?”

Censys Platform answers the other:

“What are adversaries exposing?”

That matters because attackers are not static. Their infrastructure changes. Their domains rotate. Their kits mutate. Their hosting shifts. Their certs change. Their command-and-control servers churn. Their phishing pages move between compromised sites and disposable infrastructure.

An attacker can use agents to test lure variants, generate infrastructure, rotate domains, mutate templates, search for exposed services, and evade simple blocklists. The result is an unlocked scale.

That is where CTI, threat hunting, and detection engineering teams need better Internet intelligence.

A single IOC is rarely enough. An IP, a domain, a hash – these are not the detection. These are seeds!

The Domain Is Not the Detection. The Domain Is the Seed.

Let’s say a CTI team receives a suspicious domain from a phishing report.

The fastest possible detection is obvious:

Alert when url_domain = "example-bad-domain.com"

That might catch one thing. It misses the campaign.

The better workflow starts by opening the domain in Censys and asking: “What are the real indicators here?”

Maybe the answer is a certificate pattern. Maybe a redirect path. Maybe a hosting provider and port combination. Maybe a web title. A JavaScript artifact. An HTTP header. A favicon hash. An exposed admin panel. Or even – the same lure template deployed across dozens of hosts.

That is the move from IOC matching to detection engineering.

Censys Platform helps teams make that move. Instead of asking “should we block this one domain?” teams can ask:

• What else looks like this?
• What did it expose yesterday?
• What domains resolve here?
• What certs are reused?
• Does this infrastructure match known offensive tooling?
• Is this a one-off indicator or a repeatable pattern that can become a detection?
• Can that detection become enrichment, a watchlist, or a blocklist?

That is how Censys Platform helps CTI and detection engineering teams keep up with adversary infrastructure that changes faster than static feeds.

Imagine a security researcher identifies a suspicious infrastructure pattern tied to a fast-moving phishing or malware delivery campaign.

The first version of the finding is just a domain. Censys Platform then facilitates investigation:

• Search the domain.
• Review the live host and service profile.
• Look at the TLS certificate.
• Check DNS relationships.
• Inspect web titles, headers, paths, and body artifacts.
• Pivot to similar services.
• Review historical changes.
• Use Live Rescan to confirm what is still active.
• Save the pattern as a Collection.
• Monitor new matches.

Then the detection engineer turns the finding into logic:

Alert when internal telemetry touches infrastructure matching this campaign pattern:
- matching web title or page artifact
- matching redirect structure
- matching certificate reuse
- matching suspicious service exposure
- matching DNS relationship
- matching hosting or port pattern
- currently live according to Censys

The Best Mythos-Era Defense Is Not Another Static Feed

Security teams already buy threat intelligence as a finished product. They pay someone else to collect infrastructure, enrich it, score it, package it, and hand it back as a feed.

In the Mythos era, the real question is: what can your team produce from the rawest, freshest intelligence data available?

Censys already gives you dynamic intelligence out of the box. ASM continuously tracks your own Internet-facing assets, exposures, dangling DNS, vulnerable services, and risky changes. Censys Platform gives CTI teams live infrastructure intelligence like “Bulletproof hosting”, C2, or hacktool labels.

But you can also use Censys to build your own feeds.

A Censys Collection can become a living feed of infrastructure that matches your logic. Not someone else’s generic IOC list. Your pattern. Your confidence tiers. Your use case. Your decision on whether the output should become enrichment, triage context, a detection input, a blocklist, or an investigation queue.

That matters because Mythos-speed attackers will not be defeated by static indicators alone. Domains rotate. Hosts disappear. Certificates change. Services move. Infrastructure gets reused in ways that are obvious only when you can see the broader Internet pattern.

Crunch your own threat and vuln intelligence!

Feed Censys context into your own AI models and you can start doing the kind of threat intelligence work teams often outsource to vendors like Recorded Future: clustering infrastructure, identifying related services, prioritizing suspicious changes, generating analyst-ready context, and turning raw observations into operational intelligence.

The difference is that you are not limited to a finished report or a static feed. You are working directly from current Internet evidence.

See What Mythos Exposure Management Looks Like With Censys

Censys gives you best-in-class Internet data, ready-made dynamic intelligence, and the building blocks to create your own living feeds for exposure management and SecOps. 

To see how Censys provides you with the intelligence and speed required to protect your attack surface against today’s AI-powered threats, request a demo.

Or, create a free Censys account to start using features like:

• Collections: create a real-time feed based on your own tailored logic.
• Lookup APIs: integrate Censys data into your existing workflows 
• AI Assistant: ask questions in natural language to get quick insights and context.

For more on how to write detections that contend with a Mythos-caliber security landscape, read the Ultimate Detection Engineering Guide. 

The post The Mythos Era of Threat Defense: Censys Sees Exposures and Adversary Infrastructure First appeared first on Censys.

This blog will cover the importance of alert context and how to strike the right balance of contextual information without information overload in your SOC.

Context Is Key 

Keeping an organization safe requires a mix of proactive defense and reactive response. An alert that bubbles up to the SOC via a SIEM or SOAR will often contain an external IP address or URL. A SOC analyst (carbon or silicon) needs external context to answer questions that will impact how the alert is handled.

• Is it still online?  If not, how did it appear at the time of the incident?
• Where is it and who owns the network it’s running on?
• Are there certificates or DNS entries that provide clues to the entities behind it?
• What services, software, and hardware is it running?
• Are there indicators of suspicious or malicious services?
• If the incident happened in the past, how did it look at that moment?  
• Are there similar assets on the Internet that aren’t on my radar but should be?

Enrichment actions and automated playbooks can attach all of this context to an incident in real time, speeding up triage and conserving human or AI resources. 

Get the Right Context With the Right Tools

Threat intelligence platforms (TIPs) like Dataminr’s ThreatConnect, Securonix’s ThreatQ, Vertex Synapse, Maltego, Cyware, ServiceNow TISC and Filigran OpenCTI take raw intelligence, correlate it, and make it actionable. They add layers of context — but they require good inputs to make that context valuable, trustworthy, and actionable. 

The Internet changes quickly as cloud IPs change hands and attackers rotate infrastructure to stay ahead of detection. Analysts need context that answers critical questions like: 

• How many of the IOCs are still active?
• How many look like they have changed hands?
• Has anything about these incidents changed since we started looking at them?
• Have other similar systems appeared that should be added to the IOC list?

There are several tools that help fill in these blanks to provide analysts with a clear, complete picture of an alert, including what it means, how much of a risk it poses, and how best to address it.  

Contextualizing With Censys

With Censys Internet intelligence, your SOC can determine how external assets look right now and how they appeared at any point in the past, including the time an incident occurred. That context can be used directly inside SIEM, SOAR, TIP, and investigative platforms to accelerate triage, enrich investigations, and identify related infrastructure that may otherwise go unnoticed.

For example, an intel report might contain a set of IOCs that have been seen to act maliciously. Pulling in Internet intelligence from Censys can keep these indicators fresh during an investigation. Check out three common examples of contextualized SOC alerts with Censys →  

Censys also keeps track of malicious infrastructure, and can provide a near real-time view of the infrastructure an organization needs to look out for. ThreatQ can even query Censys to ingest information about vulnerabilities and exposures present in your environment or interesting third parties. This context can be used to accelerate triage, allowing an analyst to make accurate decisions about the need for proactive defense.

Contextualizing with Maltego 

Maltego can find relationships that help an analyst pivot from an asset of interest to a larger set of related assets. The more information a tool like this has about an asset, the better chance it has to find interesting relationships. Censys often has thousands of separate attributes stored for each asset which Maltego and similar investigative tools can ingest to enhance an investigation. These include:

• Network ownership
• Geolocation
• HTTP headers and banners
• DNS Domain relationships
• Certificate issuers and subjects
• Open ports and protocols
• JARM and JA4 signatures
• Censys defined labels such as IOT, LOGIN_PAGE, DATABASE, or HONEYPOT
• Censys defined threats

This information will be current thanks to a robust scanning infrastructure. All ports and services across the Internet are examined and any identified protocol is scanned for its unique attributes. Combinations of these attributes can allow an analyst using Maltego to pivot into clusters of related assets.

View the joint solution brief

Contextualizing with Vertex Synapse

A central intelligence system like Vertex Synapse can store these scanning observations, correlate them across investigations, and identify patterns that may not be visible when looking at a single incident in isolation. This current and historical enrichment data helps analysts track the evolution of malicious or otherwise interesting infrastructure.

Querying Censys for activity associated with 185.158.248.141 between July 1, 2025 and the current date.

View the joint solution brief

Build Censys Internet Intelligence Into Your Workflows

Censys provides continuously updated visibility into Internet-exposed assets and maintains historical observations to track how the infrastructure changes over time. When it is integrated into security workflows, this added context helps analysts validate and expand on threat intelligence, uncover related infrastructure, prioritize investigations, and make faster, more informed decisions during an incident.

The post Make Your Security Tools Smarter with Internet Intelligence appeared first on Censys.

These misconfigurations are common, which makes them a frequent target for attackers, who actively search for them because they create opportunities for subdomain takeover. Once exploited, attackers can host malicious content under a trusted domain, enabling phishing, malware delivery, and reputational damage.

This blog will cover what dangling DNS is, how it can lead to subdomain takeover, and how organizations can detect and defend against these risks with Censys.

What Is Dangling DNS?

A dangling DNS entry is a DNS record that points to a resource that no longer exists or is no longer controlled by the organization. The DNS record itself remains active, even though the underlying service has been deleted, decommissioned, or abandoned.

This often happens when organizations use third-party services like AWS S3, GitHub Pages, or Heroku. If the service is decommissioned or the account associated with the service is deleted but the DNS entry is not removed, the DNS record still points to the now-defunct, or “dangling” resource.

Dangling DNS can exist on any domain or subdomain in the attack surface. It is particularly common in large organizations where infrastructure changes frequently, ownership changes between teams, or cloud resources are rapidly provisioned and decommissioned.

Why Is Dangling DNS a Problem?

Dangling DNS entries create blind spots in an organization’s attack surface. Because the DNS record remains publicly visible and resolvable, attackers can identify these abandoned references and attempt to claim the associated resource. From an attacker’s perspective, dangling DNS records are a strategic opportunity to gain control over a trusted subdomain without compromising the organization directly.

Why Dangling DNS Is Hard to Catch Manually

In large organizations, DNS records accumulate over years across multiple teams, cloud accounts, and infrastructure providers. When a resource is decommissioned, removing the DNS entry is rarely part of the standard offboarding checklist. Ownership gaps between teams and legacy resources make the problem worse — nobody is sure who is responsible for a record created three years ago by someone who has since left.

Attackers, by contrast, can automate subdomain enumeration and CNAME validation at scale. The asymmetry is significant: finding these records automatically is dramatically faster than doing so manually.

How Dangling DNS Leads to Subdomain Takeover

Subdomain takeover occurs when an attacker successfully claims the resource referenced by a dangling DNS record and gains control over the affected subdomain.

Attackers find dangling DNS instances by scanning and identifying subdomains associated with a website, then checking whether these subdomains point to any resources that no longer exist (a dangling DNS entry). Attackers frequently automate the discovery of these vulnerabilities using tools that scan for:

• Dangling CNAME records
• Unclaimed cloud resources
• Expired third-party service configurations
• Misconfigured NS records

The process typically works like this:

1. A DNS Record Points to a Decommissioned Resource. 
2. Attackers Discover the Dangling Entry. 
3. The Attacker Claims the Resource. 
4. The Attacker Gains Control of the Subdomain. 

Once the dangling resource is claimed, the attacker can host arbitrary content under the legitimate domain. This may include:

• Phishing pages
• Malware delivery
• Fake login portals
• Malicious redirects
• Defacement content
• Credential harvesting infrastructure

Since the subdomain belongs to a trusted domain, users and security tools may be less likely to immediately identify the activity as malicious.

Which Services Are Most Commonly Exploited?

Subdomain takeover is most common on platforms that allow users to claim named resources. Services frequently involved include AWS S3, GitHub Pages, Heroku, Fastly, Azure, Shopify, and Zendesk. Any platform where a CNAME points to a user-claimable namespace is a potential vector.

What Are the Consequences of Subdomain Takeover?

Subdomain takeover can have serious operational and security consequences.

• Brand and Reputation Damage: Attackers can host malicious or inappropriate content on a company-owned subdomain and be associated with an attack, damaging trust with customers and partners.
• Phishing Attacks: A phishing page hosted on a legitimate company subdomain appears significantly more trustworthy than a completely unrelated domain. This increases the likelihood of credential theft and social engineering success.
• Malware Distribution: Attackers can distribute malware or malicious downloads from the compromised subdomain, leveraging the organization’s reputation to bypass suspicion.
• Session Hijacking and Cookie Abuse: In some cases, compromised subdomains can be leveraged to abuse cookies scoped to the parent domain or interfere with web application trust assumptions.
• Security Monitoring Gaps: Because the activity occurs on a legitimate company subdomain, monitoring tools may not immediately recognize the infrastructure as compromised.
• Data Breaches: If sensitive data is shared through the compromised subdomain, it could lead to data breaches.

Frequently Asked Questions About Dangling DNS

• What is the difference between dangling DNS and a misconfigured DNS record? A misconfigured DNS record has incorrect values (wrong IP, wrong CNAME target). A dangling DNS record was correct when created but now points to a resource that no longer exists or is no longer owned by the organization. Both are risks, but dangling DNS is specifically exploitable via subdomain takeover.
• Can subdomain takeover happen on subdomains I don’t actively use? Yes — inactive or forgotten subdomains are the most common targets. If a DNS record exists, attackers will find it regardless of whether the subdomain appears in your navigation or marketing materials.
• How do attackers find dangling DNS records? Attackers use automated tools to enumerate subdomains (via certificate transparency logs, DNS brute-forcing, and public records), then check each subdomain’s CNAME target to see if the referenced resource is unclaimed on the relevant platform.
• Does HTTPS or a valid TLS certificate protect against subdomain takeover? No. An attacker who claims the resource can also provision a valid TLS certificate for it through the platform’s automated provisioning — meaning the subdomain will show a padlock in the browser even while under attacker control.
• How often should I audit DNS records for dangling entries? Ideally, DNS should be audited continuously, since new dangling entries can appear any time a cloud resource is decommissioned. At minimum, include a DNS review in any cloud resource offboarding checklist and run a full audit quarterly.

How Censys Helps Detect Dangling DNS Risks

Censys helps organizations identify and remediate dangling DNS risks before attackers can exploit them. 

Censys continuously analyzes Internet-facing infrastructure using its Map of the Internet: the most complete, accurate, and up-to-date Internet intelligence dataset available. Now, Censys’ Internet intelligence dataset includes DNS records, which are refreshed daily. This enables organizations to detect stale or vulnerable DNS configurations with current, continuously updated visibility.

In Censys ASM, dangling DNS risks can be identified on domain and web entity assets. Censys checks all names within a given workspace to detect dangling DNS risks across CNAMEs, NS Records, and third party services. It surfaces those risks within existing ASM workflows, and includes context that helps analysts quickly decide how to best address the risk. Each detection shows: 

• Associated domain name
• Impacted DNS record
• Evidence for the detection

This context helps security teams react to alerts quickly so they can remediate risks before attackers can exploit them.

Learn more about dangling DNS detection in ASM → 

Prevent Subdomain Takeover with Censys ASM

Dangling DNS entries are easy for analysts to overlook — and, unfortunately, easy for attackers to find. They can create a direct path to subdomain takeover and expose organizations to phishing, malware distribution, and reputational harm.

Dangling DNS in Censys ASM mitigates this risk by surfacing dangling DNS threats quickly so analysts can respond to them before they’re exploited. Informed by Censys’ comprehensive, accurate, and up-to-date Map of the Internet, Censys dangling DNS alerts are fresh, reliable, and contextualized with the information analysts need to act quickly and confidently. 

Dangling DNS risks are now available in your Censys ASM workspace and will be enabled in mid-June. Reach out to your customer success team for more information. If you don’t have Censys ASM, request a demo to learn how it can help protect your organization.

The post How a Dangling DNS Entry Can Lead to a Subdomain Takeover appeared first on Censys.

Yes, yes, you’ve heard this before. Everyone has. It’s the reason you collect telemetry,  send it to your SIEM, and action on your playbook via your SOAR. It’s why you follow a CTEM style program. 

But there lies the problem. In security, ensuring visibility is a well-established objective. But too often, we focus on ensuring our team’s visibility through their tools: are they receiving the right alerts? Is the tool showing them the right data? Are my tools sharing the right information with each other? 

Meanwhile, we forget to ask the more foundational question: 

How much can these tools actually see?  

Continuous Threat Exposure Management (CTEM) is an excellent example. It’s great for discovering vulnerabilities, prioritizing risks, and integrating them into workflows. But those functions rely on complete visibility into your attack surface. When there are holes at this foundational visibility level, your CTEM won’t point them out; it’ll fill them in as best they can, often inadequately or inaccurately. This leaves you with unknown blind spots and poor output, which result in missed alerts, inaccurate data, and vulnerabilities left open. 

Welcome in, adversaries.  

Why Is Complete Internet Visibility Important to CTEM?

External exposure is where most modern intrusions start: misconfigurations, shadow IT, remote access drift, and Internet-facing systems that internal scanners never record. Without comprehensive visibility and deep scanning data that can see your entire attack surface, every other piece of your attack surface workflow is less effective. You may be prioritizing and remediating what you know, but there may be elements of your attack surface that your tools have failed to discover.

To be effective and trustworthy, CTEM must draw from a complete data set, which is achieved through comprehensive and continuous Internet visibility. An accurate picture of your attack surface starts from an accurate picture of the Internet: when your CTEM’s source of truth is instead riddled with holes, the output is equally porous. If you can’t see the entire Internet, how do you know parts of your own attack surface aren’t lurking in those blind spots? 

Further, attack surfaces are not static. Your tools should pull from real-time data to draw an accurate and complete picture of your attack surface. This requires continuous scanning of the entire Internet: anything older than 24 hours should be considered stale and out of date.

CTEMs and other tools pulling from incomplete Internet visibility is dangerous in and of itself. The problem compounds when tools deliver the output as truth rather than a best-guess, with no mention of the gaps beneath the surface. Pay no attention to the approximations made behind the UI curtain.

Analysts, in turn, assume the seemingly complete picture their CTEM has presented them is, in fact complete. As a result, its underlying holes are never addressed. Never patched. The easiest of targets.

What Does a Complete Visibility for CTEM Management Look Like?

CTEM needs a foundation of a comprehensive, accurate, and up-to-date data set. This is achieved through: 

• Deep scanning: Full visibility relies on deep scanning that spans the breadth of the Internet. For example, Censys sees all 65K ports and protocols. Most scanners miss higher, less commonly used ports — which is why adversaries tend to target those. You need to see those, because attackers certainly can. 
• Frequent seed discovery: Modern attack surfaces evolve by the minute, making stale inventories a liability. Continuous seed discovery provides the real-time awareness organizations need to keep pace with automated and AI-accelerated threats. Censys scans the entire Internet continuously — most data is no more than four hours old, and no data is ever more than 24 hours old.

What Attack Surface Management (ASM) Vendors Get Wrong

Why Most CTEM Programs Have a Discovery Gap and How to Close It

Censys ASM is built on the most complete, accurate, and real-time Internet intelligence in the world. When tested against our competitors, we consistently see more, with higher accuracy, and faster (see for yourself). Censys sees all 65K ports and protocols on the Internet, has a database of over 15 billion certificates, and a library of 700+ risks and thousands of CVEs. It pairs this data with DNS insights, emerging threat data via Censys ARC research, AI-driven predictive scanning and relationship building, and more to form the most powerful Internet intelligence engine that exists today — and, therefore, the best foundation for CTEM tooling.

Initially, Censys ASM can help you seed and map your external attack surface — but this is just step one. Equally as important is the ongoing discovery that follows. Censys ASM continuously discovers new assets and organizational relationships to populate your attack surface and ensure it is up to date. This occurs every 4 hours for cloud assets and every 24 hours for non-cloud assets.

In addition, Censys provides intelligent context to help analysts triage faster and more confidently. An AI assistant, reputation-based risk scoring, and natural-language queries allow analysts to interact with data naturally and get the intelligence they need to make quick, evidence-based decisions.

Why Internet Visibility Improves Every Security Tool in Your Stack

• Accurate and Complete Inventory: SOCs find what others miss with Censys’ first-party scanning data that discovers Internet-exposed assets (including services on nonstandard ports, hosts using self-signed certificates, and even hosts in residential networks) so your inventory accurately reflects what attackers can reach.
• Immediate Exposure Detection: Continuous asset discovery allows organizations to monitor their attack surfaces continuously and alert on meaningful deltas (new hosts, ports, certs, services). 
• Reduced Mean Time to Remediate (MTTR): Full visibility and data enriched with intelligent context allows teams to triage and remediate faster.
• Better ROI on Third-Party Tooling: When integrating with third-party tools like AI agents, SIEMs, SOARs, and CTEMs, ASM’s comprehensive and accurate data provides a strong foundation for accurate, reliable and actionable output.

Power Your Exposure Management and CTEM Program With Censys

Like any security tool, CTEMs are only as good as their foundational data inputs. Without accurate Internet-wide visibility, your CTEM ends up reporting on a subset of data that you can only hope captures everything on your attack surface. But “hope” is a vulgar word in security and better left for motivational speeches and fantasy novels. Security professionals need their source of truth to be just that: the truth, the whole truth, and nothing but it. 

Censys data’s comprehensiveness, accuracy, and freshness is proven to be better than any other vendor. That makes it indisputably the best source of truth when it comes to Internet intelligence and visibility. 

Perhaps that’s why most of Censys’ competitors use Censys data. 

Request a demo to see how Censys ASM can detect, monitor, and defend your external attack surface today.

The post Why Internet Intelligence Is the Foundation of Exposure Management and CTEM appeared first on Censys.

“So privily without their leave I went / To Delphi, and Apollo sent me back / Baulked of the knowledge that I came to seek.”
Oedipus the King, 429 BCE

And so Oedipus went in secret to Delphi to question the Oracle about his fate. Instead of answers, Apollo turned him away, denying the certainty he came to seek.

Meanwhile, at tech companies across the globe, Claude Code goes down and everybody takes lunch. The Oracle is unavailable, you are denied the certainty of working code.

In the modern SOC, the oracle doesn’t go silent.

Platforms like Palo Alto Networks Cortex XSIAM and Cortex XSOAR have become that oracle unifying telemetry, applying AI-driven analysis, orchestrating workflows, and delivering answers at machine speed. Analysts don’t just investigate anymore; they consult.

And increasingly, they trust what they’re told.

When the oracle speaks, people stop asking for evidence

AI-driven SOC platforms have fundamentally reshaped operations. Cortex correlates signals across the environment, applies analytics, and delivers clear, actionable outputs faster than any human workflow could.

This is the point.

Speed, consistency, and scale are no longer tradeoffs. They are baseline expectations.

But the earliest signal in an investigation is still thin by design:

• a single IP
• a domain
• a certificate
• a timestamp

From there, the system builds understanding by connecting activity, enriching signals, and guiding response.

The outputs are fast. Structured. Confident.

And that confidence is usually well-earned.

Ground truth keeps the oracle anchored

In security operations, ground truth isn’t a correction mechanism. It is a validation layer.

It’s the difference between:

• Inferred relationships and observed ones
• Static assumptions and time-bound reality
• Partial context and full situational awareness

Cortex already synthesizes vast internal telemetry and applies AI to drive decisions. At the same time, many investigations benefit from incorporating external, real-world context about internet-facing infrastructure:

• What is this host presenting right now?
• How has it evolved over time?
• What infrastructure is associated with it?
• How does it align with broader patterns of risk?

These aren’t gaps in capability. They are extensions of scope.

And answering them with evidence strengthens already high-quality decisions.

The next evolution of AI SOC is context-aware AI

AI SOC platforms like Cortex XSIAM are already delivering on their core promise: unified operations, AI-driven analysis, and automated response at scale.

The next evolution is not about replacing or reworking that foundation.

It’s about expanding the context those systems can draw from.

Context-aware AI doesn’t change how the oracle operates. It sharpens what it knows.

Where Censys fits: expanding context within Cortex workflows

Censys integrates directly into Cortex XSIAM and XSOAR, bringing continuously refreshed Internet intelligence into the workflows analysts already use.

Within Cortex, this enables teams to:

• Enrich observables like IPs, domains, and certificates inline
• Pivot from a single indicator to related internet-facing infrastructure
• Incorporate real-time external observations into investigations
• Extend playbooks and AI-driven workflows with additional context

This integration operates entirely within the Cortex ecosystem by enhancing visibility without changing how teams work.

The value is additive:

• broader context at the moment of decision
• more informed triage and investigation
• consistent enrichment across workflows
• stronger alignment between AI outputs and observable reality

A shared oracle needs a shared foundation

In a modern SOC, multiple teams rely on the same system:

• Triage
• Incident response
• Threat intelligence
• Detection engineering

Cortex ensures those teams operate with shared workflows and coordinated intelligence.

Expanding the context available to that system ensures that every decision, across roles and functions,  is grounded in the same external reality.

The bottom line

The Oracle Problem isn’t that AI is unreliable.

It’s that speed can make confidence feel like certainty.

Cortex delivers the speed, scale, and intelligence modern SOCs demand.

Censys expands that intelligence with real-world, verifiable context ensures those decisions remain anchored in evidence.

Bring the oracle into your SOC. Just make sure what it speaks is grounded in truth. 

This partner blog was developed as part of the Censys Partner Spotlight Series in collaboration between Palo Alto Networks and Censys to highlight joint integration capabilities and our shared better together approach to AI-driven SOC operations.

The post The Oracle Problem: Why AI SOCs Need Ground Truth Context appeared first on Censys.