The Relay Exit Node Can Be a Residential IP in Your Users’ Metro. Your Impossible-Travel Rule May Never See It

A session may authenticate to your GlobalProtect gateway through a compromised consumer router on residential broadband forty miles from headquarters, carrying a credential that is valid, and no geo-velocity rule fires because nothing about that sign-in looks like travel. That scenario — a Zyxel box on a cable segment, an employee’s metro, a working credential — is illustrative rather than reported, but it is the shape of the problem AA26-113A describes. The April 23, 2026 advisory was jointly released by NCSC-UK, with support from the UK Cyber League, and 15 international partners across nine other countries — CISA, NSA, FBI and DC3 among them — and its central operational claim is that covert-network traffic usually exits in the same geographic region as the target. Usually, not always — but often enough that the egress IP stops carrying the signal you have been asking it to carry. Adversary infrastructure did not stop being something you can block. It stopped being something a static list can keep up with, which is a different and more demanding problem.

TL;DR

• AA26-113A’s operational point: China-nexus covert relay networks commonly egress from compromised SOHO routers, cameras and EOL appliances on residential broadband near the target, so a valid credential arriving at the VPN gateway may never trip impossible-travel or geo-velocity logic.
• Static IP-only deny lists decay fast — Mandiant observed IPv4 addresses staying with an ORB node for as few as 31 days, and Lumen measured an average Tier 1 lifespan of roughly 17 days on Raptor Train. Keep dynamic feeds for enrichment, alerting and retrospective hunting, and for dynamic blocking where your risk tolerance justifies it; the advisory explicitly recommends both.
• Per-identity ASN novelty is a practical first detector, not the detection. It cannot see an exit node whose ASN is already in the user’s baseline, so combine it with device identity and compliance, OS and timezone, concurrent-session and geographic anomalies, threat intel, and machine-certificate validation.
• Your own branch and acquired gear is the recruitment pool. Black Lotus Labs found Nosedive samples memory-resident and deleted from disk, with most sampled Tier 1 infections lacking reboot persistence, and inferred that operators could reinfect as needed — so power-cycling alone is not durable remediation. Replace unsupported and EOL devices; for supported ones, follow vendor-directed patching, credential rotation and post-remediation monitoring.
• Machine certificate enforcement on the tunnel (IA-3) transfers across environments where source-IP allowlisting does not, but it binds the session to a device credential rather than to hardware — use non-exportable or TPM-backed keys if you want hardware assurance.

Neither the mechanism nor its broad scale was new in 2026. Mandiant’s ORB work described the model years earlier. Lumen documented more than 200,000 cumulative Raptor Train devices since May 2020 and a peak above 60,000 concurrently active devices in June 2023; the DOJ separately described an Integrity Technology Group-controlled botnet of more than 200,000 consumer devices in its September 2024 disruption announcement. Those are two different sources making two different claims, and only Lumen published the concurrency figure. What AA26-113A adds is consolidation: prior reporting turned into multinational defensive guidance with a tiered set of recommendations. Covert relay networks (the advisory’s term; the trade has been calling them ORB networks, operational relay boxes) are pools of compromised SOHO routers, IP cameras, NAS boxes and end-of-life edge appliances, stitched together with leased VPS and administered by contractors rather than by the intelligence units that rent them. A typical network uses an on-ramp, one or more traversal layers, and an exit node usually chosen for geographic proximity to the target. Mandiant’s observation about Chinese hosting applies to a specific layer: in its terminology, the ACOS servers and entry-facing relay nodes were most commonly hosted in PRC-affiliated and Hong Kong-based IP space. That says nothing about the globally distributed traversal pool, and it does not mean the exit node a victim actually sees will be in PRC or Hong Kong space — which is rather the point of the whole architecture. Multi-tenancy is the part that matters most for attribution: the same pool serves several unrelated actors, so while an egress IP may help you identify a particular ORB network, infrastructure alone is generally insufficient to attribute the actor using it.

Why the blocklist is stale before you finish loading it

Mandiant’s research reported that the lifespan of an IPv4 address associated with an ORB node can be as few as 31 days — a floor on observed rotation, not a population average and not a half-life. Mandiant is explicit that each network has different cycling practices and that the ability to cycle a significant percentage of infrastructure monthly is a competitive differentiator between contractors. Lumen’s Black Lotus Labs measured something shorter on the Raptor Train pool: an average active Tier 1 node lifespan of approximately 17 days.

Do the arithmetic on your own pipeline, and be careful about which clock you are measuring. If your threat intel platform pulls a covert-network feed nightly and refreshes the Palo Alto EDL every 30 minutes, your local enforcement can be perfectly current relative to the feed while the underlying intelligence is already stale. The refresh interval is not the variable that matters. What matters is the feed’s observation-to-publication delay, its confidence and expiration policy, and how fast it withdraws indicators — none of which your EDL cadence can fix.

The collateral risk is real but it is also measurable rather than assumed. Dynamically assigned residential addresses get reassigned after an indicator is observed, so a stale /32 that was a relay node last Tuesday can belong to a sales engineer working from her kitchen this Tuesday. Whether that is actually happening to you is a question for your block logs, feed age, and provider attribution — not something to infer from the shape of the problem.

None of which argues for never denying anything. The advisory’s own guidance is that all organisations should adopt dynamic threat feed filtering that includes known covert network indicators, and that higher-risk entities should run dynamic blocklists with alert rules. The honest position is narrower than “stop blocking”: a static IP-only deny list should not be your primary control, because it decays faster than you can maintain it. Keep the feed for enrichment, alerting, retrospective hunting, and — where confidence in the feed and your organizational risk justify it — dynamic blocking. Pick the retrospective window from your retention, threat model and investigation requirements rather than adopting someone else’s number.

The detection you will actually build first

One practical starting detector is per-identity ASN novelty: baseline the set of ASNs an identity has authenticated from, alert on a first-seen ASN. Treat it as one feature in a broader connection profile rather than the answer. It has an obvious structural blind spot — it will never fire on an exit node whose ASN is already in that user’s baseline, which is exactly what a well-chosen residential exit in your users’ own metro looks like. The advisory’s guidance is closer to a composite: connection profiling across device identity and compliance, operating system, timezone and configuration attributes, concurrent or geographic anomalies, threat intelligence, and machine-certificate validation.

In Sentinel that first feature is a self-join against SigninLogs, where AutonomousSystemNumber is populated on interactive sign-ins. One scoping decision has to be made before you write a line of it: a bare SigninLogs query is a tenant-wide ASN-novelty detector across every application, not a VPN detector. If the VPN gateway is what you care about, filter both sides of the join on IsInteractive == true and on the immutable AppId of your VPN enterprise application. If you leave it unscoped, describe it honestly as covering all interactive Entra sign-ins, and expect the volume that implies.

// Schedule: run every 1d. Measure ingestion_lag in your own tenant first.
// Set vpn_app to the AppId of your VPN enterprise application, or drop the
// AppId filter and accept a tenant-wide interactive-sign-in detector.
let lookback = 1d;
let ingestion_lag = 30m;
let baseline_window = 45d;
let vpn_app = "<vpn-enterprise-application-id>";
let baseline = SigninLogs
| where TimeGenerated between (ago(baseline_window) .. ago(lookback + ingestion_lag))
| where ResultType == 0 and IsInteractive == true and AppId == vpn_app
| where isnotempty(AutonomousSystemNumber)
| summarize known = make_set(AutonomousSystemNumber) by UserId;
SigninLogs
| where TimeGenerated > ago(lookback + ingestion_lag)
| where ingestion_time() > ago(lookback)
| where ResultType == 0 and IsInteractive == true and AppId == vpn_app
| where isnotempty(AutonomousSystemNumber)
| join kind=inner baseline on UserId
| where not(set_has_element(known, AutonomousSystemNumber))
| extend DeviceId = tostring(DeviceDetail.deviceId),
         IsCompliant = tostring(DeviceDetail.isCompliant)
| extend DeviceState = case(isempty(DeviceId), "unregistered",
                            IsCompliant == "false", "noncompliant",
                            isempty(IsCompliant), "unknown",
                            "compliant")
| where DeviceState in ("unregistered", "noncompliant")   // route "unknown" to its own branch
| extend EventDay = bin(TimeGenerated, 1d)
| summarize arg_min(TimeGenerated, UserPrincipalName, IPAddress, UserAgent,
                    AppDisplayName, NetworkLocationDetails, CorrelationId, Id)
    by UserId, AutonomousSystemNumber, DeviceState, EventDay

Five things in that query are worth doing deliberately, because the naive version of each is a quiet failure.

The window construction is the first. A tempting shape is a baseline ending at ago(2d) and a detection set starting at ago(1d), on the theory that the gap absorbs sign-in log ingestion lag. It does not. A gap creates a blind interval — events landing between those two bounds are in neither the baseline nor the detection set — and it does nothing about delay, because TimeGenerated is the event time and a late-arriving record still falls outside a window keyed on it. Microsoft’s prescribed approach is the opposite: measure your actual delay with ingestion_time(), extend the lookback by that measured delay so the windows overlap, then use ingestion_time() to associate each event with exactly one run so the overlap does not double-alert. That is what the lookback + ingestion_lag / ingestion_time() > ago(lookback) pair above is doing.

The device condition is the second. The conjunction people describe — a first-seen ASN and a device that fails compliance or has no registered device ID — is not what tostring(DeviceDetail.isCompliant) != "true" implements. That test lumps a confirmed non-compliant device together with a session where the compliance value is simply absent, and it never looks at DeviceDetail.deviceId at all, so “unregistered” is not being evaluated. Split them: an explicit false, a missing value, and an empty deviceId are three different findings with three different confidences. And having split them, filter on the two you actually meant — DeviceState in ("unregistered", "noncompliant"). A != "compliant" test quietly readmits the unknown bucket you just went to the trouble of separating, which is how a “high-confidence” rule ends up firing on missing telemetry. Route unknown to a lower-confidence branch and let it earn its own threshold.

The identity key is the third. UserPrincipalName is mutable — a name change or a UPN-domain migration produces what looks like a brand-new identity, and under the inner join below that identity has no baseline and therefore generates nothing at all. A rename becomes a silent detection outage for that user. Key the baseline and the join on UserId, which is the stable user identifier, and carry UserPrincipalName through only as an analyst-facing display field.

The aggregation is the fourth, and it is the subtlest. Building the output row with FirstSeen = min(TimeGenerated), IPAddress = any(IPAddress), UserAgent = any(UserAgent) looks like it summarizes one event. It does not. any() is a deprecated alias of take_any(), and Microsoft’s documentation is explicit that using it multiple times in a single summarize “may have each application select a different record.” So the IP can come from one sign-in, the user agent from another, and neither has to correspond to the timestamp you reported. You would be handing an analyst a composite event that never happened. Use arg_min(TimeGenerated, ...) with all the fields you want in one call, which guarantees every value comes from the single earliest record in the group. (The minimized column comes back as min_TimeGenerated.)

The inner join is the fifth, and it has a consequence people get backwards. An identity with no successful sign-in anywhere in the baseline window never matches, so it generates nothing at all. That is the right default for a first build, but it means a new hire with an empty baseline is a false-negative condition, not a false positive. Identities with thin baselines — a handful of historical sign-ins rather than none — are the ones that generate noise, and they need their own confidence handling rather than a blanket exclusion. Break-glass accounts deserve dedicated monitoring, not a suppression rule.

One scope note on that query: it hunts interactive user sign-ins only. Service principals are a separate and worthwhile hunt, but they live in a different table — AADServicePrincipalSignInLogs, which carries its own AutonomousSystemNumber column. It needs its own query, with service-principal-specific success and identity handling; you will not get workload identities by widening the SigninLogs version above.

Splunk side, if your VPN is the source of truth rather than Entra, you are working pan:globalprotect or the ASA %ASA-6-113039 AnyConnect session-start events. And here is the first thing that will annoy you: iplocation gives you lat/lon, city, country, and no ASN. You need a separate lookup. Most shops convert the free GeoLite2-ASN CSV into a CIDR lookup and refresh it on a scripted schedule, which works fine right up until the refresh job starts failing silently after a MaxMind license key rotation and nobody notices for five months because the lookup still returns results, just increasingly wrong ones.

Put a freshness check on that lookup — but check the right thing. GeoLite2 ASN CSV records contain only the network, the ASN, and the ASN organization. There is no date field on a record, so “alert if the newest record is older than N days” is checking a column that does not exist. Freshness has to come from the archive or build date, local file metadata, updater exit status, or successful-download telemetry. MaxMind’s own guidance on updating databases is to check periodically through the day rather than relying on a fixed schedule, so that you catch off-schedule releases — which means the right alert is on a missed or failed expected update, not on a staleness threshold measured in weeks.

The same database also will not tell you whether an address is residential, mobile, satellite or privacy infrastructure. GeoLite2 ASN carries no access-type classification at all. MaxMind’s GeoIP Enterprise dataset does include connection_type (Cable/DSL, Cellular, Corporate, Satellite) and user_type (whose values include residential, cellular, hosting, traveler and consumer_privacy_network), and MaxMind also sells narrower Connection Type, Anonymous IP and Residential Proxy databases; other vendors have their own equivalents. Whichever you pick, something in your pipeline has to own it and monitor its health. If that mapping rots, the rule keeps running and quietly stops firing on the exact population it was built for.

This matters for how you describe the rule, too. Until that enrichment is actually wired in, the query above detects a first-seen ASN plus a device-state finding — it does not know whether the source is consumer broadband. Call it what it is rather than what you wish it were.

What tuning has to fix, and what you will have to measure yourself

Alert volume for a naive first-seen-ASN rule is environment-specific, and so is the minimum viable baseline history. Anyone quoting you a hits-per-day number for a 12,000-seat shop is quoting their environment, not yours. Measure it during a staged deployment and record the environment size, observation period, query version, population exclusions and resulting counts — that is the artifact that makes the next tuning decision defensible. What you can say qualitatively is that mobile, satellite, travel, hotel and privacy networks are plausible sources of first-seen-ASN noise. How much each contributes is environment-specific. AA26-113A recommends baselining consumer-broadband VPN connections and profiling operating system, timezone, configuration and geographic attributes; it does not quantify ASN-novelty volume by network class, and neither should you before measuring.

Mobile carriers can be a major source of it — heavily so in a workforce leaning on cellular access, roaming or hotspots, less so elsewhere, and you should measure alert counts by ASN, access type, user population and device state before crowning a dominant noise class. Verizon Wireless, T-Mobile, AT&T Mobility, plus whatever regional MVNOs your fleet picked up. The address churn inside a carrier is constant — CGNAT pools reassign by the hour — but the ASN is the part that generates your alerts: the big carriers announce more than one, MVNOs ride transit that resolves to somebody else entirely, and a roaming session or a market handoff drops a user onto an ASN they have never presented before. Starlink is a second cluster, and it is more awkward than the carriers because the geolocation attached to AS14593 has historically been poor: the address resolves to whichever ground station or PoP the session lands on rather than to the dish, which will place a user in a different state from one session to the next. Hotel and conference-center networks are a third, and they are seasonal in a way that will make your rule look tuned in February and noisy in June. Consumer VPN and privacy-network exits are a fourth.

The instinct is to carve all four out and move on. Resist the blanket version of that, because the same infrastructure that generates your noise is usable cover for the traffic you are hunting — a full suppression on AS14593 or a major mobile ASN removes adversarial sessions riding the same paths. Treat them as high-noise classes rather than unconditional exclusions: down-rank them, route them to a lower-priority queue, or require corroborating device and session anomalies before they page anyone, while preserving the events for hunting and retrospective analysis. If you do suppress, log the suppression somewhere a hunter will actually read it.

The tuning hypothesis worth testing first is the conjunction: first-seen residential ASN and a device that is explicitly non-compliant or unregistered. Measure during staged deployment how much that actually reduces volume and whether it improves confirmed-positive yield, rather than assuming every surviving event deserves a human. The ones that are not attacks are often contractors on personal equipment, which is itself a finding you should file rather than suppress.

One structural caveat before you ship it. Your VPN concentrator logs and your identity logs may disagree on time — not because any particular vendor emits bad timestamps, but because device clocks, timezone settings, log formats and SIEM parsing all get a vote, and any of them can be misconfigured. Some Palo Alto telemetry exposes explicit UTC timestamps, so this is a failure mode to check for rather than a property to assume. Normalize to UTC, synchronize devices against authoritative time sources, and monitor clock offset and parser health on a schedule rather than discovering the problem during an incident. If your correlation window is five minutes and your offset is larger than that, you lose joins silently.

The half of this nobody staffs

Your gear is the supply side. The branch-office DrayTek that went end-of-support years ago and nobody replaced, the eight Zyxel units a regional acquisition brought in, the NVR in the warehouse that somebody port-forwarded for a contractor who left. Those are the recruitment pool. If you are going to make that argument to a budget owner, name the actual models and cite the vendor’s own lifecycle notice — the specificity is what moves it out of the “someday” column.

Raptor Train is the reference case and the numbers deserve care, because the widely-cited figure is not the researchers’ figure. Lumen’s Black Lotus Labs writeup documented more than 200,000 devices compromised cumulatively since May 2020, with a peak of over 60,000 concurrently active devices in June 2023 and an average around 30,000 by August 2024. The DOJ’s disruption announcement said more than 200,000 consumer devices. The 260,000 that appears across secondary coverage does not map to a stated counting methodology in either primary source, so do not build risk math on it and do not quote it as concurrent scale. The numbers to use are the ones the researchers published: 200,000-plus cumulative, peak concurrency in the tens of thousands.

Operationally, all Nosedive samples and associated droppers that Black Lotus Labs recovered were memory-resident and deleted from disk, and most of the Tier 1 implants they sampled had no method of persistence. The researchers inferred from this that the operator could simply reinfect devices as needed; they did not establish a general interval for how quickly that happens, so “reboot it and it comes back within hours” is an extrapolation rather than a finding. What follows regardless is that power-cycling alone is not durable remediation. For unsupported or end-of-life devices, replacement is the answer. For supported devices, the answer is vendor-directed patching, reimaging or reflashing, credential rotation, configuration review, and post-remediation monitoring — SA-22 is about unsupported components specifically, and permits supported alternatives in defined circumstances rather than making physical replacement the only response. In control terms this is SA-22 doing real work for once instead of sitting in a POA&M, alongside CM-8 for the inventory you probably do not have on branch and OT-adjacent gear.

On the wire, Nosedive-infected Tier 1 devices called back to Tier 2 C2 nodes over TLS on port 443, with random alphanumeric names in the subject and issuer fields of the observed certificates. Port 34125 belongs to a different part of the architecture: it carried regular TLS management connections from the Tier 3 Sparrow management nodes down to the Tier 2 C2 nodes, where operators collected bot information and issued commands. It was not the ordinary Tier 1 implant callback channel, and a detection built to watch for 34125 on a branch router is watching the wrong tier.

The outbound detection is still cheaper than the inbound one. Any edge device that is supposed to be a client and starts accepting inbound sessions from residential address space, or sustaining long-lived outbound TLS to destinations that look machine-generated, is worth a page. Be precise about what your telemetry can actually see, though. Ordinary L3/L4 NetFlow or IPFIX records give you endpoints, protocol, ports, counters, flags and timestamps. They do not give you SNI, and that is a matter of record rather than a configuration you have missed: the IANA IPFIX Information Elements registry defines no standard element for SNI, TLS server name, or cipher suite. IPFIX is an extensible export protocol rather than a fixed schema, so it can carry TLS metadata — but only when the exporter or probe actually captures it and ships it in suitable enterprise-specific elements. Cisco’s Encrypted Traffic Analytics is one such enhanced flow telemetry implementation; firewall or proxy logs and NDR inspection are the other common routes. If your plan depends on SNI, confirm which of those you are actually exporting.

Sampling is the other place to be careful. A 1:1000 sFlow rate can miss a relay carrying a handful of low-and-slow sessions, but sFlow is defined probabilistically — an average packet ratio, not a deterministic every-thousandth-packet skip — so observation probability scales with the flow’s packet count rather than dropping to zero. “Will reliably miss it” overstates the case; “may well miss it, and you cannot tell which” is the honest version. Evaluate your sampling empirically against known test traffic, and run unsampled telemetry at selected high-risk edges where that is technically and financially feasible. If you can only afford unsampled collection in one tier, weigh branch-edge against core placement using your actual topology rather than a rule of thumb: branch-edge collection tends to preserve appliance attribution and surface low-volume device behavior, while the core gives broader aggregate coverage and may discard the device context you wanted. Decide it with test traffic, expected routing paths, exporter capability and how much attribution survives aggregation. The branch edge is often the more interesting answer, which is counterintuitive enough to be worth testing rather than assuming.

Allowlists and machine certs, and who can actually run them

The NCSC’s version of the advisory tiers its guidance by organizational capability, which is honest of them. Potential victims are told to implement two-factor authentication for remote access and, where possible, apply zero trust controls, IP allow lists and machine certificate verification; larger or higher-risk entities are pointed at active hunting of suspicious SOHO/IoT traffic, geographic profiling and anomaly detection.

Where environment decides everything is that “where possible.” In an enclave with a bounded administrator population connecting from known facilities or a managed jump path, source-IP allowlisting on remote access is practical. In an organization with a work-from-home default and a large share of the workforce on rotating consumer broadband, the same recommendation produces an allowlist containing much of the residential space in several states, which is functionally an allow-any with extra maintenance. Feasibility turns on stable egress availability, PKI and MDM maturity, contractor and BYOD populations, enrollment workflow, support staffing and the remote-access architecture — not on how committed you are to the control.

Worth being precise on the compliance framing too: AC-17 requires you to establish and document usage restrictions, configuration and connection requirements, and implementation guidance for each type of remote access, and to authorize each type before allowing it. It does not specifically mandate source-IP allowlisting. An allowlist can be an excellent way to satisfy those requirements in a bounded environment; its absence does not by itself make an AC-17 implementation statement deficient.

What transfers more cleanly between those two worlds is machine certificate enforcement on the tunnel. That maps to IA-3 (device identification and authentication), and to IA-3(1) where the authentication is mutual and cryptographic. Be accurate about what it buys you: a certificate binds the connection to a device credential, not necessarily to hardware. A private key that can be exported is a credential that can move to a machine you did not issue. If you want the hardware assurance the control is usually sold on, you need non-exportable or TPM-backed keys, and device attestation where the platform supports it.

The reason this control keeps slipping is not mysterious — somebody has to own enrollment for the devices that do not fit the MDM profile, and that work rarely gets a headcount. In a highly distributed remote-work environment it is still the item most likely to be worth the argument, because it is the one that keeps working when the network path is something you do not control.

Sanctions and takedowns are part of the picture and they are the part you do not control. Treasury’s OFAC sanctioned Beijing-based Integrity Technology Group in January 2025 over its role in Flax Typhoon activity, and on March 16, 2026 the Council of the EU listed the same company, stating that more than 65,000 devices were hacked across six member states between 2022 and 2023 through its technical and material support. Disruption and sanctions do remove and constrain infrastructure. What none of the public sources establish is a rebuild rate — so plan on pools being rebuilt without claiming to know how fast.

Which leaves you with the connection profile as the durable control surface. Stop asking only whether the source IP is known-bad. Ask whether this identity has ever authenticated from this ASN, whether the device presenting itself is one you issued and can still vouch for, and whether the branch appliance in Toledo has any business accepting an inbound session at all.

Sources

• Defending Against China-Nexus Covert Networks of Compromised Devices, AA26-113A (CISA)
• Defending against China-nexus covert networks of compromised devices (National Cyber Security Centre)
• Executive Summary: Defending against China-nexus covert networks of compromised devices (National Cyber Security Centre)
• IOC extinction? China-nexus cyber espionage actors use ORB networks to raise cost on defenders (Google Cloud / Mandiant)
• Derailing the Raptor Train (Lumen Black Lotus Labs)
• Court-Authorized Operation Disrupts Worldwide Botnet Used by People’s Republic of China State-Sponsored Hackers (U.S. Department of Justice)
• Treasury Sanctions Company Associated with Salt Typhoon and Flax Typhoon Hacker Associated with Compromise of U.S. Critical Infrastructure (U.S. Department of the Treasury)
• Compromised everyday devices power Chinese cyber espionage operations (Help Net Security)
• A dozen allied agencies say China is building covert hacker networks out of everyday routers (CyberScoop)
• An Introduction to Operational Relay Box (ORB) Networks (Team Cymru)
• Handle ingestion delay in Microsoft Sentinel (Microsoft Learn)
• SigninLogs table reference (Microsoft Learn)
• AADServicePrincipalSignInLogs table reference (Microsoft Learn)
• take_any() aggregation function (Microsoft Learn / Kusto)
• GeoLite2 and GeoIP2 ASN databases (MaxMind Developer Portal)
• GeoIP Enterprise database (MaxMind Developer Portal)
• Cyber-attacks against the EU and its member states: Council sanctions three entities and two individuals (Council of the EU)
• Europe sanctions Chinese and Iranian firms for cyberattacks (BleepingComputer)
• Updating GeoIP and GeoLite databases (MaxMind Developer Portal)
• Encrypted Traffic Analytics Configuration Guide (Cisco)
• IP Flow Information Export (IPFIX) Entities registry (IANA)
• NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (NIST CSRC)

This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.