{"id":1,"date":"2026-06-25T22:46:09","date_gmt":"2026-06-25T20:46:09","guid":{"rendered":"https:\/\/the8layer.com\/?p=1"},"modified":"2026-06-26T11:16:28","modified_gmt":"2026-06-26T09:16:28","slug":"crowdstrike-didnt-block-it-dns-query-did","status":"publish","type":"post","link":"https:\/\/the8layer.com\/it\/crowdstrike-didnt-block-it-dns-query-did\/","title":{"rendered":"CrowdStrike Didn\u2019t Block It. Knox Didn\u2019t Block It. A DNS Query\u00a0Did"},"content":{"rendered":"<p class=\"wp-block-paragraph\">There are currently more active mobile devices on Earth than there are people. Every one of them is a network endpoint. Every one of them resolves DNS. And virtually none of them are protected at the DNS layer in any meaningful way.<\/p>\n<p class=\"wp-block-paragraph\">The security industry has spent the last decade obsessing over endpoint detection \u2014 behavioral agents, kernel-level hooks, ML classifiers running on device. CrowdStrike, SentinelOne, Microsoft Defender, Samsung Knox, Google Play Protect. The investment is real, the technology is serious, and the results are measurable.<\/p>\n<p class=\"wp-block-paragraph\">And yet.<\/p>\n<p class=\"wp-block-paragraph\">I have personally tested all of the above against a controlled network monitored by AegisDNS, a Rust-based DNS security engine I built. The result was unambiguous: telemetry exfiltration domains, spyware SDK callbacks, and C2 infrastructure passed through every single one of those endpoint agents without triggering a single alert. AegisDNS blocked them all.<\/p>\n<p class=\"wp-block-paragraph\">This is not a failure of those products. It is a structural limitation of where they operate \u2014 and understanding that distinction is the entire point of this article.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">What DNS Sinkholes Do \u2014 and What They Don\u2019t<\/h2>\n<p class=\"wp-block-paragraph\">A DNS sinkhole intercepts domain name resolution requests and returns a controlled response \u2014 typically a null route or a local IP \u2014 instead of the legitimate address. Any client that queries for\u00a0<code>malware-c2.ru<\/code>\u00a0gets back\u00a0<code>0.0.0.0<\/code>. The connection never happens. The packet never exists.<\/p>\n<p class=\"wp-block-paragraph\">This is architecturally elegant. It operates below the application layer. It doesn\u2019t need to understand what the application is doing \u2014 it only needs to see the query. SSL, certificate pinning, obfuscated payloads \u2014 none of it matters if the domain never resolves.<\/p>\n<p class=\"wp-block-paragraph\"><strong>What DNS sinkholes do well:<\/strong><\/p>\n<ul class=\"wp-block-list\">\n<li>Block known malicious domains from curated threat feeds \u2014 malware, phishing, botnets, telemetry<\/li>\n<li>Provide network-wide coverage regardless of device type, OS, or application<\/li>\n<li>Generate per-query logs for forensic analysis and behavioral correlation<\/li>\n<li>Operate passively without touching device state or consuming endpoint resources<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\"><strong>What feed-based DNS sinkholes don\u2019t do:<\/strong><\/p>\n<ul class=\"wp-block-list\">\n<li>Detect domains generated algorithmically (DGA) that aren\u2019t yet in any feed<\/li>\n<li>Identify behavioral patterns across query sequences<\/li>\n<li>Block telemetry and spyware SDKs embedded in legitimate, signed applications \u2014\u00a0<em>unless those specific domains are known<\/em><\/li>\n<li>Distinguish between a legitimate API call and a data exfiltration payload riding the same infrastructure<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">That last limitation is where the mobile threat landscape gets genuinely interesting, and where proactive structural detection \u2014 not just feed matching \u2014 becomes essential.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">Mobile: The Largest Attack Surface, the Least Defended<\/h2>\n<p class=\"wp-block-paragraph\">Consider the geometry of a modern enterprise attack surface:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>Servers:<\/strong>\u00a0hardened, patched, monitored, often network-segregated<\/li>\n<li><strong>Workstations:<\/strong>\u00a0EDR agents, centralized policy, SOC visibility, DNS logging<\/li>\n<li><strong>Mobile devices:<\/strong>\u00a0MDM with varying enforcement, OS sandboxing, and \u2014 in the vast majority of deployments \u2014 no DNS-layer visibility whatsoever<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">Mobile devices make DNS queries constantly. Every app, every SDK, every background service. A typical Android device with a standard app portfolio generates thousands of DNS queries per day. The overwhelming majority are legitimate. But embedded within that traffic are queries you almost certainly don\u2019t want resolving.<\/p>\n<p class=\"wp-block-paragraph\">The mobile threat model has a specific characteristic that makes it uniquely dangerous:\u00a0<strong>the most effective attack vectors are not malware. They are legitimate, signed SDKs doing exactly what they were designed to do.<\/strong><\/p>\n<p class=\"wp-block-paragraph\">Advertising SDKs that exfiltrate device identifiers, location data, and behavioral profiles. Analytics libraries that beacon home every user interaction. Telemetry frameworks embedded three levels deep in a dependency tree that the app developer never audited. All signed. All passing integrity checks. All invisible to endpoint agents \u2014 not because those agents are poorly engineered, but because of\u00a0<em>where<\/em>\u00a0in the stack the behavior is hidden.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">Why Automated Analysis Fails Here: The IPC Bypass<\/h2>\n<p class=\"wp-block-paragraph\">To understand why Knox, Play Protect, MobSF, and MTD agents miss this class of threat, you need to understand the mechanism these SDKs use to hide their behavior from static and dynamic analysis. It operates on three layers simultaneously.<\/p>\n<p class=\"wp-block-paragraph\"><strong>Layer 1 \u2014 Lazy heuristic categorization.<\/strong>\u00a0MobSF and most MTD classification engines analyze the APK, extract strings, and map class hierarchies. When they detect a known advertising SDK package \u2014 say,\u00a0<code>com.mintegral.msdk<\/code>\u00a0\u2014 they apply a rigid heuristic rule:\u00a0<em>known ad network package = Advertisement \/ Riskware (low risk)<\/em>. Analysis stops there. The code is structurally designed to display banners, so any network traffic it generates is presumed to be \u201cloading advertising assets.\u201d The engine moves on. The deeper behavior is never reached.<\/p>\n<p class=\"wp-block-paragraph\"><strong>Layer 2 \u2014 Runtime URI construction via IPC obfuscation.<\/strong>\u00a0Aggressive SDKs do not make direct, visible HTTP calls that static analysis can trace. Instead, they construct the target URI dynamically at runtime \u2014 decrypting AES or XOR-encoded strings stored in asset files, or assembling them via reflection and method swizzling. The assembled URI is then passed through an Android\u00a0<code>Intent<\/code>\u00a0or a custom URI scheme (<code>customscheme:\/\/<\/code>) that travels through the OS\u2019s IPC space. No hard-coded domain string exists in the binary. No static scanner sees the destination. MobSF finds what looks like standard inter-component communication \u2014 because structurally, it is.<\/p>\n<p class=\"wp-block-paragraph\"><strong>Layer 3 \u2014 Signature bypass via legitimate process context.<\/strong>\u00a0The entire sequence occurs within a legitimately signed APK. The developer imported the SDK dependency without auditing it \u2014 this is the norm, not the exception. Knox and Play Protect see authorized components communicating through standard Android constructs. There is no memory exploit, no privilege escalation, no anomalous system call. There is only a legitimate feature of the Android architecture being used for a purpose its documentation does not advertise.<\/p>\n<p class=\"wp-block-paragraph\"><strong>The logical conclusion is precise:<\/strong>\u00a0an attacker can hide the code, encrypt the strings, abuse Android\u2019s Intent system to deceive MobSF and Knox at every layer of on-device analysis. But at the end of the computational stack, to exfiltrate that packet off the device, the OS must resolve a domain name. The obfuscation stops at UDP\/TCP port 53.<\/p>\n<p class=\"wp-block-paragraph\">No Intent, no reflection, no AES layer obscures a DNS query. It is the one operation that cannot be faked within the device boundary. This is why the network perimeter DNS layer is not an additional defense \u2014 it is the\u00a0<em>last<\/em>\u00a0defense that the obfuscation chain cannot bypass.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">The Mintegral Case: SIGINT from Reverse Engineering<\/h2>\n<p class=\"wp-block-paragraph\">During research conducted through the GAMA (Greyware Analysis and Mitigation Approach) methodology, I reverse engineered the Mintegral MBridge SDK \u2014 an advertising framework embedded in thousands of applications, including titles distributed through official stores.<\/p>\n<p class=\"wp-block-paragraph\">The SDK implements exactly the IPC obfuscation pattern described above. Network destinations are assembled at runtime. URI schemes route through IPC channels invisible to proxy-based traffic capture. MobSF classifies the package as Advertisement. Knox sees legitimate inter-process communication. Play Protect finds a signed APK with no integrity violations.<\/p>\n<p class=\"wp-block-paragraph\">I extracted 6 specific domains used by Mintegral for data collection and callback communication. These domains are now part of AegisDNS\u2019s SIGINT intelligence layer \u2014 always blocked, zero exceptions, categorized as Spyware.<\/p>\n<p class=\"wp-block-paragraph\">This is what happened when I tested across enterprise endpoint security products:<\/p>\n<figure class=\"wp-block-table\">\n<table class=\"has-fixed-layout\">\n<thead>\n<tr>\n<th>Product<\/th>\n<th>Mintegral domains blocked?<\/th>\n<th>Alert generated?<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Samsung Knox<\/td>\n<td>No<\/td>\n<td>No<\/td>\n<\/tr>\n<tr>\n<td>Google Play Protect<\/td>\n<td>No<\/td>\n<td>No<\/td>\n<\/tr>\n<tr>\n<td>SentinelOne<\/td>\n<td>No<\/td>\n<td>No<\/td>\n<\/tr>\n<tr>\n<td>CrowdStrike Falcon<\/td>\n<td>No<\/td>\n<td>No<\/td>\n<\/tr>\n<tr>\n<td>MobSF (static analysis)<\/td>\n<td>No \u2014 classified as Advertisement<\/td>\n<td>No<\/td>\n<\/tr>\n<tr>\n<td><strong>AegisDNS<\/strong><\/td>\n<td><strong>Yes \u2014 all 6<\/strong><\/td>\n<td><strong>Yes \u2014 SIGINT category<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n<p class=\"wp-block-paragraph\">The reason is not that these products are inferior. Knox is a serious security framework. CrowdStrike\u2019s sensor engineering is genuinely impressive. The reason is architectural: they operate inside the device, where the obfuscation is designed to be invisible. AegisDNS operates at the network perimeter, where the obfuscation is irrelevant.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">Why EDR and MTD Cannot Fully Close This Gap<\/h2>\n<p class=\"wp-block-paragraph\">Modern Mobile Threat Defense solutions \u2014 including the mobile modules of vendors like CrowdStrike and SentinelOne \u2014 are aware of the sandboxing limitation. Their typical mitigation is a local VPN tunnel (<code>NEPacketTunnelProvider<\/code>\u00a0on iOS,\u00a0<code>VpnService<\/code>\u00a0on Android) that routes all traffic through a local loopback before it reaches the network interface. In theory, this allows on-device DNS inspection regardless of which app generated the query.<\/p>\n<p class=\"wp-block-paragraph\">This is a real capability and it should be acknowledged. However, it introduces a different set of constraints that limit its effectiveness in practice:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>Resource consumption:<\/strong>\u00a0Running a continuous local VPN tunnel with DNS inspection on a mobile device has measurable battery and CPU impact. Users disable it. MDM policies are inconsistently enforced. The agent is not always running.<\/li>\n<li><strong>DoH and custom APN bypass:<\/strong>\u00a0An application or an embedded SDK that integrates a native DoH client \u2014 issuing HTTPS requests directly to a public resolver on port 443 \u2014 bypasses local VPN DNS inspection entirely. The query never reaches the loopback tunnel, and it does not reach a standard port-53 perimeter sinkhole either, appearing instead as ordinary encrypted web traffic to a legitimate IP. A comprehensive network architecture mitigates this by blocking outbound port 443 traffic to known public DoH endpoints at the packet filter level \u2014 forcing the OS to fall back to the corporate DNS infrastructure. In AegisDNS deployments, this is enforced via the same iptables layer that already rejects external port-53 queries: no DNS resolution, encrypted or otherwise, exits the network perimeter without passing through the sinkhole.<\/li>\n<li><strong>No perimeter intelligence context:<\/strong>\u00a0An on-device agent making a block decision has access only to what it can observe locally. A perimeter DNS engine operating across an entire network segment can correlate query patterns across devices, identify distributed exfiltration campaigns, and apply intelligence feeds of a scale that is simply not deployable on endpoint storage \u2014 651,171 domains in AegisDNS\u2019s current feed set would be operationally impossible to maintain on mobile endpoint memory.<\/li>\n<li><strong>Scale of intelligence:<\/strong>\u00a0Maintaining a feed of 650k+ domains on a mobile endpoint is not realistic from a storage, update, and performance perspective. A perimeter sinkhole absorbs that complexity without touching the endpoint at all.<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">The conclusion is not that MTD is useless \u2014 it provides genuine value at the process and behavioral layer. The conclusion is that perimeter DNS security and endpoint security address structurally different parts of the problem. Deploying one does not substitute the other.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">What a DNS Engine Needs to Do This at Enterprise Scale<\/h2>\n<p class=\"wp-block-paragraph\">A feed-based DNS sinkhole is necessary but not sufficient. Feeds are reactive \u2014 a domain must be known bad before it appears in any list. DGA malware generates thousands of new domains per day specifically to stay ahead of feed updates. DNS tunneling uses structurally valid domains that will never appear in any feed. Typosquatting campaigns register domains hours before launching.<\/p>\n<p class=\"wp-block-paragraph\">An enterprise-grade DNS security engine requires three capabilities beyond feed matching:<\/p>\n<p class=\"wp-block-paragraph\"><strong>1. Proactive structural detection.<\/strong>\u00a0The ability to match against the\u00a0<em>shape<\/em>\u00a0of a domain \u2014 not its identity. A 47-character random-looking label is not in any feed. But it matches a DNS tunneling pattern.\u00a0<code>paypa1-secure-login.com<\/code>\u00a0is not in any feed yet. But it matches a typosquatting pattern with homoglyph substitution (<code>1<\/code>\u00a0replacing\u00a0<code>l<\/code>). This requires a compiled pattern engine \u2014 specifically PCRE2, chosen for its support for lookaround assertions and advanced feature set not available in simpler regex engines \u2014 applied at query resolution speed.<\/p>\n<p class=\"wp-block-paragraph\"><strong>2. Zero-downtime pattern updates.<\/strong>\u00a0Emerging campaigns require immediate response. Restarting a DNS service to update detection rules introduces a window of exposure. A hot-reload mechanism \u2014 where pattern files are watched and recompiled atomically without dropping queries in flight \u2014 is an operational requirement, not a nice-to-have.<\/p>\n<p class=\"wp-block-paragraph\"><strong>3. Real-time telemetry for SOC correlation.<\/strong>\u00a0A DNS block in isolation is a data point. A DNS block correlated with a simultaneous IDS alert, an anomalous packet volume, and an exfiltration monitor hit is an incident. The DNS engine must expose a structured, real-time event feed that a SOC can consume and correlate \u2014 not just a log file.<\/p>\n<p class=\"wp-block-paragraph\">Building these capabilities on a memory-safe foundation matters beyond ideology. The C codebase underlying most traditional DNS resolvers \u2014 including dnsmasq, which powers Pi-hole\u2019s FTL engine \u2014 carries the structural risk of buffer overflows and memory corruption vulnerabilities that are impossible in Rust at the language level. For a component that handles every DNS query on a network, that is not a theoretical concern.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">On the Block Rate: Understanding the Operational Trade-off<\/h2>\n<p class=\"wp-block-paragraph\">The 15.8% block rate observed across a monitored network segment deserves context, because raw block rate numbers without context alarm administrators rightly.<\/p>\n<p class=\"wp-block-paragraph\">Amplitude and Firebase are legitimate analytics platforms used by thousands of applications for crash reporting, session state synchronization, and performance metrics. Blocking\u00a0<code>api2.amplitude.com<\/code>\u00a0at the DNS layer will break functionality in applications that depend on it for more than behavioral tracking.<\/p>\n<p class=\"wp-block-paragraph\">This is a real operational trade-off, and pretending otherwise serves nobody. The value of a DNS security engine is not the block rate \u2014 it is the\u00a0<em>control<\/em>. AegisDNS allows selective blocking by source IP, time window, and category, passive logging without drop for domains where the risk-to-breakage ratio is ambiguous, and per-domain whitelist overrides that survive feed updates. The 15.8% figure represents a deployment configured for a research context with aggressive telemetry blocking. An enterprise deployment would be tuned differently \u2014 likely logging Amplitude traffic without dropping it, while maintaining hard blocks on the Mintegral SIGINT domains and known malware C2.<\/p>\n<p class=\"wp-block-paragraph\">The point is not to block everything. The point is to\u00a0<em>see<\/em>\u00a0everything, make informed decisions, and enforce those decisions at a layer where enforcement is structurally guaranteed.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">Real Numbers from a Live Deployment<\/h2>\n<p class=\"wp-block-paragraph\">From the AegisDNS deployment monitored during this research period:<\/p>\n<ul class=\"wp-block-list\">\n<li><strong>651,171<\/strong>\u00a0malicious domains loaded across 11 threat intelligence feeds<\/li>\n<li><strong>28,000+<\/strong>\u00a0DNS queries processed in a 24-hour monitoring window<\/li>\n<li><strong>4,400<\/strong>\u00a0queries blocked \u2014 15.8% block rate in research configuration<\/li>\n<li><strong>27ms<\/strong>\u00a0average upstream latency (resolver internal latency significantly lower)<\/li>\n<li><strong>Top blocked category:<\/strong>\u00a0Telemetry \u2014\u00a0<code>api2.amplitude.com<\/code>\u00a0at 728 hits,\u00a0<code>region1.app-measurement.com<\/code>\u00a0at 428 hits<\/li>\n<li><strong>SIGINT layer:<\/strong>\u00a06 Mintegral domains \u2014 always blocked, zero exceptions<\/li>\n<li><strong>Firebase logging:<\/strong>\u00a0blocked and logged in live query feed<\/li>\n<\/ul>\n<p class=\"wp-block-paragraph\">The telemetry category warrants attention. On a corporate device with access to sensitive systems, every event Amplitude or Firebase receives is behavioral intelligence leaving the network perimeter. In regulated industries, that is a compliance exposure. In environments handling sensitive data, it is a threat surface that no endpoint agent currently monitors.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">The Architecture: Why Rust and Why It Matters<\/h2>\n<p class=\"wp-block-paragraph\">The performance advantage of a Rust-based DNS engine over Pi-hole\u2019s pihole-FTL \u2014 which is a native C binary integrating dnsmasq at source level, not a Python wrapper as is sometimes claimed \u2014 is not primarily about speed. On modern hardware, both resolve queries fast enough that raw throughput is rarely the bottleneck.<\/p>\n<p class=\"wp-block-paragraph\">The meaningful architectural differences are:<\/p>\n<p class=\"wp-block-paragraph\"><strong>Memory safety by construction.<\/strong>\u00a0Rust\u2019s ownership model eliminates at the language level the class of vulnerabilities \u2014 buffer overflows, use-after-free, race conditions \u2014 that remain structurally possible in C regardless of developer skill. For a component that parses untrusted network input on every query, this is not a theoretical concern. DNS parsers have a history of memory corruption vulnerabilities. Rust makes that class of bug impossible to compile.<\/p>\n<p class=\"wp-block-paragraph\"><strong>Native async architecture.<\/strong>\u00a0AegisDNS is built on Tokio\u2019s async runtime, which means concurrent query handling with no thread-per-connection overhead. The PCRE2 pattern engine runs within the same async context, with compiled patterns applied at query time and no global lock required for hot-reload updates \u2014 the pattern set is swapped atomically.<\/p>\n<p class=\"wp-block-paragraph\"><strong>PCRE2 for detection, not performance.<\/strong>\u00a0The choice of PCRE2 over Rust\u2019s native\u00a0<code>regex<\/code>\u00a0crate is deliberate: PCRE2 supports lookaround assertions, atomic groups, and possessive quantifiers that are essential for writing precise DGA and tunneling detection patterns without catastrophic backtracking \u2014 features the native crate intentionally omits in favor of guaranteed linear-time execution. The trade-off is acknowledged: PCRE2 is a C library, and its Rust bindings cross an FFI boundary that technically introduces unsafe code outside Rust\u2019s memory safety guarantees. This is mitigated by strict pattern governance \u2014 every structural rule in the library is reviewed and regression-tested before deployment, specifically to eliminate patterns susceptible to backtracking amplification or edge-case memory pressure in the underlying C engine. For multi-pattern matching at scale, an Aho-Corasick layer handles the feed domains in O(n) against query length regardless of feed size, while PCRE2 handles the structural pattern library where expressiveness is required.<\/p>\n<hr class=\"wp-block-separator has-alpha-channel-opacity\" \/>\n<h2 class=\"wp-block-heading\">Implications<\/h2>\n<p class=\"wp-block-paragraph\">The picture that emerges from this research is structural, not vendor-specific.<\/p>\n<p class=\"wp-block-paragraph\">Most enterprise mobile security postures have a DNS-shaped gap in them. Devices are managed, applications are vetted, endpoint agents are deployed \u2014 but the DNS layer, where the most pervasive and least detectable exfiltration happens, is either unmonitored or monitored with tools that cannot match the operational requirements of a live threat environment.<\/p>\n<p class=\"wp-block-paragraph\">The mobile attack surface is the largest, the fastest-growing, and currently the least defended at the DNS layer. The obfuscation techniques used by aggressive SDK ecosystems are specifically engineered to be invisible to every on-device analysis tool \u2014 and they succeed, consistently, against tools from the most well-resourced security vendors in the industry.<\/p>\n<p class=\"wp-block-paragraph\">The obfuscation stops at port 53. That is where the defense has to be.<\/p>","protected":false},"excerpt":{"rendered":"<p>A critical RCE flaw in OpenSSL 3.x affects 17 million servers. CVE-2023-0286 allows heap overflow via crafted X.400 address. Patch to 3.0.7 immediately.<\/p>","protected":false},"author":1,"featured_media":12,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,5],"tags":[],"class_list":["post-1","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-analysis","category-threat-intel"],"_links":{"self":[{"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/posts\/1","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/comments?post=1"}],"version-history":[{"count":1,"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/posts\/1\/revisions"}],"predecessor-version":[{"id":13,"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/posts\/1\/revisions\/13"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/media\/12"}],"wp:attachment":[{"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/media?parent=1"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/categories?post=1"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/the8layer.com\/it\/wp-json\/wp\/v2\/tags?post=1"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}