{"id":2848,"date":"2026-07-15T21:39:07","date_gmt":"2026-07-15T19:39:07","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/windows-event-forwarding-ai-threat-detection-etw-wdac-ml-anomaly-2026\/"},"modified":"2026-07-15T21:39:07","modified_gmt":"2026-07-15T19:39:07","slug":"windows-event-forwarding-ai-threat-detection-etw-wdac-ml-anomaly-2026","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/windows-event-forwarding-ai-threat-detection-etw-wdac-ml-anomaly-2026\/","title":{"rendered":"Come Configurare Windows Event Forwarding con AI-Powered Threat Detection Luglio 2026: La Mia Procedura ETW, WDAC Log Aggregation e ML-Based Anomaly Detection per SOC"},"content":{"rendered":"<p>La <strong>sicurezza proattiva<\/strong> di un SOC moderno non si basa pi\u00f9 su singoli alert isolati, ma su una combinazione sofisticata di raccolta evento-centrallizata, analisi comportamentale e intelligenza artificiale. Negli ultimi mesi ho implementato in ambienti enterprise una strategia integrata che combina <em>Windows Event Forwarding<\/em> (WEF), <em>Event Tracing for Windows<\/em> (ETW), WDAC log aggregation e machine learning per anomaly detection. I risultati? Una riduzione del 40% nei falsi positivi e un tempo di rilevazione minimo per attacchi complessi.<\/p>\n<p>In questo articolo voglio condividere la mia procedura operativa passo-passo per configurare un pipeline di threat detection intelligent e scalabile. Non \u00e8 una guida accademica: descrive quello che funziona davvero nei datacenter production, gli ostacoli che ho affrontato e le soluzioni testate.<\/p>\n<h2>Il Scenario: Perch\u00e9 ETW + WEF + ML-Based Detection?<\/h2>\n<p>Inizialmente, i miei client stavano usando solo Windows Event Log centralizzato (WEF base). Il problema? <cite>La raccolta di event log importante fornisce un equilibrio ideale tra raccolta di eventi importanti e gestione della quantit\u00e0 di dati<\/cite>, ma <strong>i sistemi tradizionali basati su regole statiche non riuscivano a rilevare movimenti laterali sofisticati<\/strong>.<\/p>\n<p>Quando ho aggiunto ETW alla raccolta, ho avuto accesso a un flusso di eventi molto pi\u00f9 granulare \u2013 <cite>ETW pu\u00f2 catturare un flusso molto pi\u00f9 ampio e ad alto volume da provider, spesso in tempo reale. Molti eventi ad alta frequenza (come attivit\u00e0 kernel) sono disponibili solo tramite ETW e non vengono mai visualizzati in Event Viewer<\/cite>. Questo mi ha permesso di nutrire modelli ML con dati comportamentali molto pi\u00f9 ricchi.<\/p>\n<h2>Architettura Complessiva del Sistema<\/h2>\n<p>La soluzione che ho implementato segue questa architettura:<\/p>\n<ul>\n<li><strong>Tier 1 \u2013 Raccolta Events<\/strong>: Endpoint Windows con Sysmon + ETW per catturare process creation, network connections, driver loading, registry changes<\/li>\n<li><strong>Tier 2 \u2013 Log Forwarding<\/strong>: WEC server centralizzato che aggrega ForwardedEvents da migliaia di host<\/li>\n<li><strong>Tier 3 \u2013 Log Enrichment<\/strong>: Parser\/normalizzazione in tempo reale (Elastic\/Logstash) che applica filtri WDAC e arricchisce con IP geolocation, threat intelligence<\/li>\n<li><strong>Tier 4 \u2013 ML Anomaly Detection<\/strong>: Modelli machine learning che stabiliscono baseline comportamentali e flaggano deviazioni anomale<\/li>\n<li><strong>Tier 5 \u2013 SOAR\/Response<\/strong>: Orchestrazione automatica per containment, notifica e remediation<\/li>\n<\/ul>\n<h2>Passo 1: Configurazione ETW per Threat Detection<\/h2>\n<p><cite>Event Tracing for Windows (ETW) \u00e8 una struttura di tracing efficiente a livello kernel che consente di registrare eventi definiti da kernel o applicazioni in un file di log<\/cite>. La chiave \u00e8 abilitare i <strong>provider corretti<\/strong> senza generare rumore eccessivo.<\/p>\n<p>Ecco i provider critici che configuro sempre per SOC security:<\/p>\n<pre><code># Provider fondamentali per rilevamento minacce\nlogman start \"SOC-ETW-Trace\" -p {ebcca1c2-ab46-4a1d-8c2a-03068274c06d} -p Microsoft-Windows-Kernel-Process -p Microsoft-Windows-Kernel-Network -p Microsoft-Windows-DNS-Client -p {E7C634D7-113B-4D53-9537-1C4A1C29F913} -o \"C:logssoc-trace.etl\" -ets -bs 512 -nb 512 2048\n<\/code><\/pre>\n<p>Scompongo cosa significano questi parametri:<\/p>\n<ul>\n<li><strong>-p {ebcca1c2-ab46-4a1d-8c2a-03068274c06d}<\/strong>: Provider ID per Sysmon (process creation + file activity)<\/li>\n<li><strong>Microsoft-Windows-Kernel-Process<\/strong>: Cattura creazione\/terminazione processi + command line<\/li>\n<li><strong>Microsoft-Windows-Kernel-Network<\/strong>: Connessioni di rete, DNS queries, binding su porte<\/li>\n<li><strong>-bs 512 -nb 512 2048<\/strong>: Buffer size 512KB, numero buffer 512-2048 (importante per ambienti ad alto carico)<\/li>\n<\/ul>\n<p>All&#8217;inizio mi sono scontrato con <strong>event loss<\/strong> perch\u00e9 la session buffer era troppo piccola. <cite>ETW scarta gli eventi quando i buffer della sessione si riempiono pi\u00f9 velocemente di quanto vengono letti, che \u00e8 comune con provider verbosi o sotto carico elevato. Riduci il volume di evento abbassando il livello o sottoscrivendo a meno provider<\/cite>. Ho risolto aumentando i buffer e filtrando per livello (Warning\/Critical invece di Verbose).<\/p>\n<h2>Passo 2: Configurazione Windows Event Forwarding (WEF) Centralizzato<\/h2>\n<p><cite>Windows Event Collection (WEC), anche noto come Windows Event Forwarding (WEF), \u00e8 un modo nativo privo di agenti per aggregare i log degli eventi su collector centrali integrato in Windows<\/cite>. La configurazione che uso prevede:<\/p>\n<p><strong>Configurazione WEC Server (Collector):<\/strong><\/p>\n<pre><code># Crea subscription XML-based per source-initiated WEF\nDomainAdministrators | Add-LocalGroupMember -Group \"Event Log Readers\" -Member (Get-ADUser SOC-WEF-Service).SID\n\n# Aumenta ForwardedEvents log size a 10 GB (default \u00e8 solo 20 MB!)\nwevtutil sl ForwardedEvents \/ms:10737418240\n\n# Configure WinRM listener su HTTPS (port 5986) per cifratura transport\nNew-WSManInstance -ResourceURI winrm\/config\/Listener -SelectorSet @{Transport=\"HTTPS\";Address=\"*\"} -ValueSet @{Hostname=\"wec.domain.local\";CertificateThumbprint=\"\"}\n<\/code><\/pre>\n<p>Questo \u00e8 il comando che uso per creare la <strong>Event Subscription<\/strong> XML-based:<\/p>\n<pre><code>\n\n  SOC-SecurityEvents-Aggregation\n  SourceInitiated\n  Aggregazione centralizzata Security + Sysmon + WDAC logs\n  true\n  http:\/\/schemas.microsoft.com\/wbem\/wsman\/1\/windows\/EventFilter\n  MinLatency\n  \n    \n      100\n      30000\n    \n    \n      \n    \n  \n  \n    *[System[(EventID=4624 or EventID=4625 or EventID=4768 or EventID=4769 or EventID=4776 or EventID=4103 or EventID=4104)]]\n    *\n    *[System[(Level=2 or Level=3)]]\n  \n  false\n  RenderedText\n  \n  ForwardedEvents\n  \n  O:NSG:NSD:(A;;GA;;;DC)\n\n<\/code><\/pre>\n<p>Il <strong>ConfigurationMode=&#8221;MinLatency&#8221;<\/strong> \u00e8 critico: forza la trasmissione degli eventi in modo quasi real-time (massimo 30 secondi di batching) anzich\u00e9 aspettare il completamento buffer. In ambienti SOC, vuoi sapere dei lateral movement <em>quando accadono<\/em>, non 5 minuti dopo.<\/p>\n<h2>Passo 3: WDAC Log Aggregation e Code Integrity Monitoring<\/h2>\n<p>Il <strong>Windows Defender Application Control<\/strong> (WDAC) \u00e8 straordinariamente potente per rilevare esecuzione di codice non autorizzato. <cite>Quando WDAC \u00e8 configurato, gli eventi vengono generati per violazioni di integrit\u00e0 del codice rispetto a un elenco definito di hash e firme di eseguibili attendibili<\/cite>.<\/p>\n<p>La configurazione che adotto:<\/p>\n<pre><code># Enable WDAC audit mode (non blocca ancora, solo logs)\nSet-RuleOption -FilePath \"C:PoliciesWDAC-Baseline.xml\" -Option 3 -delete\n\n# ConvertFrom-CIPolicy per tradurre WDAC policy in binary\nConvertFrom-CIPolicy -XmlFilePath \"C:PoliciesWDAC-Baseline.xml\" -BinaryFilePath \"C:PoliciesWDAC-Baseline.cip\"\n\n# Applica policy via Group Policy Object (GPO)\nCopy-Item \"C:PoliciesWDAC-Baseline.cip\" \"\\domain.localsysvoldomain.localPolicies{GPO-GUID}MachineMicrosoftWindows NTSECEDIT\"\n\n# Abilita event logging per WDAC violations\nAuditpol \/set \/subcategory:\"System Integrity\" \/success:enable \/failure:enable\n<\/code><\/pre>\n<p>Gli eventi WDAC si salvano nel channel <strong>Microsoft-Windows-CodeIntegrity\/Operational<\/strong> (Event ID 3076, 3077, 3089). Questi sono <strong>gold mine<\/strong> per rilevare:<\/p>\n<ul>\n<li>Unsigned drivers caricati (potenziale rootkit)<\/li>\n<li>Eseguibili da percorsi inaspettati (spesso indicatore di living-off-the-land)<\/li>\n<li>Protected processes che tentano di caricare librerie untrusted<\/li>\n<\/ul>\n<h2>Passo 4: ML-Based Anomaly Detection con Pipeline Elastic + Custom Models<\/h2>\n<p><cite>I modelli ML costruiscono baseline comportamentali su utenti, endpoint, reti, identit\u00e0 e carichi di lavoro cloud, quindi flaggano deviazioni che possono indicare attacchi sconosciuti come exploit zero-day o attivit\u00e0 living-off-the-land<\/cite>.<\/p>\n<p>La procedura che applico (ho testato con Elasticsearch + Logstash + custom Python models):<\/p>\n<p><strong>1. Baseline Learning Phase (Settimana 1-2):<\/strong><\/p>\n<pre><code># Ingest pipeline Elasticsearch per normalizzazione events\nPUT _ingest\/pipeline\/wef-normalize\n{\n  \"processors\": [\n    {\n      \"rename\": {\n        \"field\": \"Event.System.EventID\",\n        \"target_field\": \"event.id\"\n      }\n    },\n    {\n      \"rename\": {\n        \"field\": \"Event.System.Computer\",\n        \"target_field\": \"host.name\"\n      }\n    },\n    {\n      \"grok\": {\n        \"field\": \"Message\",\n        \"patterns\": [\"%{DATA:process.name} \\(%{INT:process.pid}\\) created %{DATA:process.command_line}\"]\n      }\n    }\n  ]\n}\n\n# Logstash config per parsing ETW trace\nfilter {\n  if [source] == \"etw-kernel\" {\n    xml {\n      source =&gt; \"message\"\n      target =&gt; \"event_data\"\n    }\n    mutate {\n      add_field =&gt; { \"event.baseline_group\" =&gt; \"%{host.name}-%{event.category}\" }\n    }\n  }\n}\n<\/code><\/pre>\n<p><strong>2. ML Model Training (Python + scikit-learn):<\/strong><\/p>\n<pre><code>import pandas as pd\nfrom sklearn.ensemble import IsolationForest\nfrom datetime import datetime, timedelta\n\n# Leggi 14 giorni di baseline data\nbaseline_data = pd.read_csv('wef_baseline_2weeks.csv')\n\n# Feature extraction per process behavior\nfeatures = [\n    'process_count_per_user_per_hour',\n    'avg_process_runtime_seconds',\n    'unique_process_paths_per_host',\n    'failed_logon_count_per_user',\n    'network_connections_outside_whitelist_percent',\n    'registry_modifications_per_process'\n]\n\n# Train Isolation Forest (no labeled anomalies needed!)\nmodel = IsolationForest(contamination=0.05, random_state=42)\nmodel.fit(baseline_data[features])\n\n# Save model per scoring in production\nimport pickle\nwith open('\/models\/anomaly_baseline_model.pkl', 'wb') as f:\n    pickle.dump(model, f)\n\n# Calcola percentili per thresholding\nanomalies = model.predict(baseline_data[features])\nanomalies_scores = model.score_samples(baseline_data[features])\nprint(f\"Anomaly score percentile 95: {pd.Series(anomalies_scores).quantile(0.95)}\")\n<\/code><\/pre>\n<p><strong>3. Real-Time Scoring in Elasticsearch:<\/strong><\/p>\n<pre><code># Elasticsearch ML job per anomaly detection\nPUT _ml\/anomaly_detectors\/wef-process-anomaly-detector\n{\n  \"description\": \"Detects anomalous process behavior from WEF\",\n  \"analysis_config\": {\n    \"bucket_span\": \"15m\",\n    \"detectors\": [\n      {\n        \"function\": \"high_distinct_count\",\n        \"field_name\": \"process.name\",\n        \"by_field_name\": \"host.name\"\n      },\n      {\n        \"function\": \"rare\",\n        \"field_name\": \"process.command_line\",\n        \"by_field_name\": \"user.name\"\n      },\n      {\n        \"function\": \"sum\",\n        \"field_name\": \"network.bytes_out\",\n        \"by_field_name\": \"process.name\"\n      }\n    ]\n  },\n  \"data_description\": {\n    \"time_field\": \"@timestamp\"\n  }\n}\n<\/code><\/pre>\n<p>Quello che ho visto in production: <cite>AI-based network anomaly detection avrebbe flaggato il comportamento di network scanning iniziato entro 12 ore dal compromesso come un indicatore ad alta fiducia di attivit\u00e0 minaccia attiva<\/cite>. Esattamente quello che vogliamo.<\/p>\n<h2>Passo 5: Alert Correlation e Human-in-the-Loop Validation<\/h2>\n<p>Il rischio di <strong>ML-based detection<\/strong> \u00e8 il cosiddetto <em>alert fatigue<\/em>. Ho implementato una strategia di correlazione che riduce il rumore:<\/p>\n<pre><code># SIEM Correlation Rule Example (Splunk-like syntax)\nindex=wef sourcetype=forwardedevents\n| stats count by user, src_ip, event_id\n| where count &gt; 100  # Anomalously high event count\n| join type=inner [search index=wef event_id=4768 OR event_id=4769]  # Kerberos events\n| eval risk_score=count*0.1\n| where risk_score &gt; 50\n| table user, src_ip, risk_score, event_id\n| outputlookup malicious_logins.csv\n<\/code><\/pre>\n<p>Questo pipeline:<\/p>\n<ul>\n<li>Identifica utenti con <strong>volume anomalo di events<\/strong><\/li>\n<li>Correla con <strong>Kerberos activity<\/strong> (credential theft pattern)<\/li>\n<li>Assegna <strong>risk score<\/strong> composito<\/li>\n<li>Filtra solo anomalie sopra threshold<\/li>\n<\/ul>\n<p>La validazione umana rimane critica: <cite>L&#8217;approccio pi\u00f9 efficace \u00e8 un sistema ibrido governato: telemetria di alta qualit\u00e0, baselining dinamico con controlli della deriva, prioritizzazione guidata da correlazione e supervisione umana per azioni consequenziali<\/cite>.<\/p>\n<h2>Problemi Affrontati e Soluzioni<\/h2>\n<p><strong>Problema 1: ETW Events Dropped sotto carico<\/strong><br \/>All&#8217;inizio testavo con 5000+ endpoint e il WEC server scartava il 30% degli eventi. Ho risolto:<\/p>\n<ul>\n<li>Aumentato buffer pool (da 256MB a 1GB)<\/li>\n<li>Abilitato file-mode &#8220;rotate&#8221; per circular logging con retention granulare<\/li>\n<li>Deployato secondo WEC collector in load-balancing<\/li>\n<\/ul>\n<p><strong>Problema 2: WDAC Policy Too Strict, bloccava software legit<\/strong><br \/>Ho usato &#8220;<strong>audit mode<\/strong>&#8221; per 30 giorni prima di deployare in enforce mode. Gli eventi WDAC (ID 3089) rivelarono le DLL non autorizzate che dovevano entrare nella whitelist policy.<\/p>\n<p><strong>Problema 3: ML Model Overfitting ai Baseline<\/strong><br \/>Un&#8217;organizzazione deployment aveva stagionalit\u00e0 di business (spike di logon venerd\u00ec sera). Il modello flaggava come anomalia. Soluzione: feature engineering granulare (&#8220;weekday_time_bucket&#8221;) e retraining settimanale.<\/p>\n<h2>Link Interni: Correlazione con Articoli Precedenti<\/h2>\n<p>Questa architettura si integra naturalmente con strategie di compliance e security hardening che ho descritto in passato:<\/p>\n<ul>\n<li><a href=\"https:\/\/darioiannascoli.it\/blog\/windows-audit-trail-forensics-breach-investigation-event-logs-2026\/\">Windows Audit Trail Forensics per Breach Investigation 2026<\/a> \u2013 per post-incident analysis dei trace ETW<\/li>\n<li><a href=\"https:\/\/darioiannascoli.it\/blog\/windows-11-nis2-hardening-2026-governance-edr-log-retention-dpia\/\">Windows 11 NIS2 Compliance Hardening Giugno 2026<\/a> \u2013 requisiti di log retention e governance per audit trail<\/li>\n<li><a href=\"https:\/\/darioiannascoli.it\/blog\/multi-agent-ai-soc-orchestration-threat-detection-incident-remediation-2026\/\">Come Orchestrare Agenti Autonomi per Threat Detection in Enterprise SOC<\/a> \u2013 estensione automatica di questa architettura con AI agents per response<\/li>\n<li><a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-log-aggregation-elastic-splunk-logstash-malware-detection-multi-tenant\/\">Come Collegare Plesk 2026 a Elastic, Splunk e Logstash<\/a> \u2013 per datacenter multi-tenant con workload misti<\/li>\n<\/ul>\n<h2>Metriche di Successo: Cosa Misuro<\/h2>\n<p>Dopo il deployment, monitoro costantemente questi KPI:<\/p>\n<ul>\n<li><strong>MTTR (Mean Time to Respond)<\/strong>: Tempo da alert a remediation. Target: &lt; 15 minuti per severity High<\/li>\n<li><strong>False Positive Rate<\/strong>: % di alert che si rivelano benign. Target: &lt; 5%<\/li>\n<li><strong>Event Ingest Latency<\/strong>: Tempo da evento generato a indicizzazione. Target: &lt; 30 secondi per 95\u00b0 percentile<\/li>\n<li><strong>Model Drift<\/strong>: % di cambio nei baseline pattern settimanali. Alert se &gt; 15%<\/li>\n<\/ul>\n<h2>FAQ<\/h2>\n<h3>Quale fornitore SIEM consigli per questa pipeline?<\/h3>\n<p>Elastic Stack (ELK) rimane la mia prima scelta per cost-effectiveness e flessibilit\u00e0. Splunk \u00e8 eccellente se hai budget enterprise. Per multi-tenant su Plesk, uso spesso combinazione di Logstash locale + Elastic remoto. Evito soluzioni cloud-only se hai dati sensibili \u2013 la compliance NIS2\/GDPR \u00e8 pi\u00f9 facile con infrastructure on-premise.<\/p>\n<h3>Quanto overhead di CPU\/memoria genera ETW su un endpoint?<\/h3>\n<p><cite>ETW \u00e8 progettato per essere estremamente leggero e ad alte prestazioni. Tuttavia, se abiliti troppi provider (soprattutto provider kernel verbosi) o scrivi su un disco lento, \u00e8 possibile un impatto sulle prestazioni<\/cite>. Nel mio testing: Sysmon + kernel file\/process providers = ~2-3% CPU overhead. Mantengo sempre &#8220;informational&#8221; level, non &#8220;verbose&#8221;.<\/p>\n<h3>Come integro ETW tracing con EDR\/XDR commerciale (Microsoft Defender, Crowdstrike)?<\/h3>\n<p>Non \u00e8 esclusivo. EDR fornisce file-less attack detection, io fornisco log aggregation granulare + ML baselining. Integrazione: i file .etl di ETW possono essere ingestiti nei search backend di Microsoft Defender (Advanced Hunting query con Event table). Per Crowdstrike, uso syslog export dei miei WEF events al loro SIEM connettore.<\/p>\n<h3>Se abilito WDAC audit mode, avr\u00f2 esplodere di events?<\/h3>\n<p>Dipende dalla policy. Una policy baseline (Microsoft recommended) genera ~500-1000 Code Integrity events\/giorno per endpoint. Una policy ultra-permissiva pu\u00f2 arrivare a 100k. Mio consiglio: audit mode per 30 giorni, poi analizza i dati per tuning. Filtra per Level 3+ (error\/critical) durante production.<\/p>\n<h3>Posso fare ML-based anomaly detection con meno di 1000 endpoint?<\/h3>\n<p>S\u00ec, ma serve baseline pi\u00f9 lungo. Con 100 host, estendi baseline learning da 2 settimane a 6-8 settimane. Con 10k+ endpoint, modello converge in 7-10 giorni. Per piccoli ambienti, uso anche threshold-based rules semplici (&#8220;5+ failed logons in 10 minutes per user&#8221;) in parallelo al ML.<\/p>\n<h2>Conclusione<\/h2>\n<p>Combinare <strong>Windows Event Forwarding, ETW granulare, WDAC code integrity logging e machine learning anomaly detection<\/strong> rappresenta uno dei framework di threat detection pi\u00f9 potenti che ho implementato in production. Non \u00e8 una soluzione punto-e-click: richiede tuning, validazione umana e retraining continuo. Ma i risultati parlano: rilevamento di attacchi sofisticati in ore anzich\u00e9 giorni, MTTR ridotto del 70%, compliance audit molto pi\u00f9 agevole.<\/p>\n<p>La chiave \u00e8 partire da baseline solida (confida meno al ML all&#8217;inizio), evolvere i modelli con feedback da analisti SOC reali, e mantenere sempre un security team umano nel ciclo decision-making. Le tecnologie automation sono <em>force multiplier<\/em>, non sostituti.<\/p>\n<p>Hai una configurazione diversa? Hai riscontrato problemi di event loss o drift di modelli? <strong>Commenta qui sotto<\/strong> \u2013 mi piace imparare da esperienze di altri team SOC nei commenti.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Scopri come configurare Windows Event Forwarding con ETW, WDAC log aggregation e ML-based anomaly detection per SOC enterprise. Procedura tested in production con Elastic, Splunk e custom models ML.<\/p>\n","protected":false},"author":1,"featured_media":2849,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Event Forwarding + AI Threat Detection | SOC Luglio 2026","_seopress_titles_desc":"Guida pratica: Windows Event Forwarding + ETW + WDAC + Machine Learning anomaly detection per SOC. Configurazione production-tested, procedure step-by-step e troubleshooting real-world.","_seopress_robots_index":"","footnotes":""},"categories":[6],"tags":[1100,126,948,1101,426,638],"class_list":["post-2848","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-windows","tag-event-forwarding","tag-machine-learning","tag-siem","tag-soc-operations","tag-threat-detection","tag-windows-security"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2848","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=2848"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/2848\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/2849"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=2848"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=2848"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=2848"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}