Spcnet.it

2026-04-17 13:45:21

Azure MCP in Visual Studio 2022: 230+ strumenti Azure direttamente nell’IDE

Addio alle estensioni: Azure MCP è ormai integrato in VS2022

Fino a poco tempo fa, usare gli strumenti Azure MCP in Visual Studio 2022 richiedeva di cercare un’estensione dal Marketplace, installare un file VSIX, riavviare Visual Studio, e sperare che tutto funzionasse. Se qualcosa andava storto, dovevi disinstallare e reinstallare completamente.

Oggi, Microsoft ha integrato nativamente Azure MCP come parte del workload Azure in Visual Studio 2022. Niente più estensioni separate da gestire, niente più problemi di versione mismatch, un unico percorso di aggiornamento. Se hai già il workload Azure installato, accedi a 230+ strumenti Azure con un semplice click.

Cosa è cambiato realmente

La differenza è fondamentale: prima avresti visto questo flusso:

1. Aprire Visual Studio Marketplace
2. Cercare “GitHub Copilot for Azure (VS 2022)”
3. Scaricare e installare l’estensione VSIX
4. Riavviare Visual Studio
5. Sperare che tutto funzioni

Ora il flusso è semplicemente:

1. Avere il workload Azure installato (già incluso in tante installazioni di VS2022)
2. Abilitare il server Azure MCP una volta in Copilot Chat
3. Usare 230+ strumenti Azure direttamente nel tuo IDE

I vantaggi di questa integrazione

1. Zero attrito

Nessun passo di installazione aggiuntivo. Azure MCP arriva automaticamente quando aggiorni Visual Studio, esattamente come gli altri componenti del tuo IDE.

2. Aggiornamenti sincronizzati

La versione di Azure MCP Server viene aggiornata insieme a Visual Studio durante i rilasci regolari. Non ci sono più versioni non allineate tra l’estensione e l’IDE.

3. 230+ strumenti per 45 servizi Azure

Gli strumenti Azure MCP coprono praticamente l’intero ecosistema Azure, da servizi core come Compute e Storage a soluzioni avanzate come Cognitive Services e Machine Learning.

Cosa puoi fare con Azure MCP Tools

Imparare

Chiedi a Copilot Chat informazioni su servizi Azure, best practices, e pattern architetturali direttamente nell’IDE:

// In Copilot Chat:
"Come architettare un'applicazione scalabile su Azure per 1 milione di utenti?"
"Qual è la differenza tra Azure Service Bus e Azure Queue Storage?"

Progettare e sviluppare

Ricevi raccomandazioni su quali servizi Azure usare e genera configurazioni pronte per il tuo codice:

// Copilot suggerisce:
// "Per una web app ad alta concorrenza, consiglio Azure App Service con SQL Database
// e Redis Cache. Vuoi che generi il bicep template?"

Deployare

Provisiona risorse Azure e distribuisci l’applicazione senza lasciare Visual Studio:

// "Crea un'App Service su eastus con auto-scaling da 2 a 10 istanze"
// Copilot esegue i comandi Azure CLI direttamente

Troubleshooter

Accedi a log, verifica lo stato delle risorse, e diagnostica problemi in produzione:

// "Controlla gli ultimi errori nella mia Function App 'MyProcessorApp'"
// Copilot legge i log da Application Insights

Come iniziare

Prerequisiti

• Visual Studio 2022 (versione recente)
• Workload Azure installato
• GitHub Copilot Chat abilitato
• Credenziali Azure configurate localmente

Passaggi

1. Apri GitHub Copilot Chat in Visual Studio
2. Cerca la sezione “Tools” (Strumenti)
3. Abilita “Azure MCP Server”
4. Inizia a scrivere prompt relativi ad Azure

Casi d’uso reali per sviluppatori italiani

Startup e PMI con risorse IT limitate: Usare Copilot + Azure MCP elimina la necessità di un DevOps engineer separato per compiti di infrastruttura semplici.

Team già in Azure: Se usi già servizi come Azure App Service, SQL Database, o Azure Functions, gli strumenti MCP ti permettono di gestirli senza alternare tra Visual Studio e il portale Azure.

Development in Cloud: Con Azure MCP integrato, puoi debuggare, deployare, e troubleshootare applicazioni cloud interamente dall’IDE, migliorando la produttività.

Conclusione

L’integrazione nativa di Azure MCP in Visual Studio 2022 è un esempio di come Microsoft continua a eliminare frizioni dai workflow degli sviluppatori. Non è una feature entusiasmante sulla carta, ma nella pratica quotidiana risparmia tempo e riduce la complessità gestionale. Per qualsiasi team che sviluppa su Azure, abilitare Azure MCP in Copilot Chat dovrebbe essere una delle prime cose da fare.

Fonte: Microsoft Visual Studio Blog – Azure MCP Tools Now Ship Built Into Visual Studio 2022

Azure MCP tools now ship built into Visual Studio 2022 — no extension required - Visual Studio Blog

Azure MCP tools are now built into Visual Studio 2022 as part of the Azure development workload — no separate extension to find, install, or update.

^{Yun Jung Choi (Visual Studio Blog)}

(in)sicurezza digitale

2026-04-17 08:54:20

Kong RAT: la nuova campagna di SEO poisoning con dropper NativeAOT .NET 10 che prende di mira gli sviluppatori cinesi

Si parla di:
Toggle

• Il panorama: SEO poisoning come vettore strategico verso la Cina
• La kill chain in sei stadi
• Tecniche di evasione: il dettaglio che conta
• Post-exploitation e telemetria raccolta
• Attribuzione e contesto
• Indicatori di compromissione
• Raccomandazioni per i difensori

Una nuova campagna di SEO poisoning documentata da eSentire TRU sta prendendo di mira sviluppatori e professionisti IT di lingua cinese con Kong RAT, un impianto modulare distribuito attraverso installer contraffatti di strumenti molto diffusi nell’ecosistema sinofono: FinalShell, Xshell, QuickQ e Clash. La catena di infezione, articolata in sei stadi, abusa di Alibaba Cloud OSS per ospitare i payload di prima fase e combina tecniche di evasione avanzate — da PEB masquerading al bypass UAC tramite CMSTPLUA COM — che la pongono in una fascia qualitativa superiore rispetto alle classiche campagne Gh0st/kkRAT viste nel 2025.

Il panorama: SEO poisoning come vettore strategico verso la Cina

Il SEO poisoning è diventato negli ultimi diciotto mesi uno dei vettori preferiti dagli attori di lingua cinese per colpire il mercato domestico, quasi sempre perché il Great Firewall rende difficile l’accesso ai canali di distribuzione occidentali e spinge utenti e sviluppatori a cercare software tecnici tramite motori di ricerca locali, dove il ranking manipolato porta a domini typosquatted praticamente indistinguibili dagli originali. La telemetria pubblica degli ultimi mesi ha mostrato HiddenGh0st, Winos/ValleyRAT, FatalRAT e kkRAT diffusi con lo stesso schema, con landing page clone di DeepL, Chrome, Signal, Telegram e WPS Office. Kong RAT rappresenta il naturale salto di qualità: un impianto custom scritto ex-novo, non derivato da Gh0st, con un proprio protocollo C2 e un’architettura modulare a plug-in.

La scelta dei “software-esca” è particolarmente chirurgica. FinalShell e Xshell sono client SSH/terminale ampiamente utilizzati da sysadmin e DevOps cinesi; QuickQ e Clash sono utility di rete comunemente associate ad ambienti tecnici. Compromettere questi utenti significa posizionare la backdoor esattamente dove serve: su macchine che hanno credenziali verso server di produzione, bastion host, reti aziendali.

La kill chain in sei stadi

La catena di esecuzione è quella che distingue Kong RAT dalle precedenti campagne di SEO poisoning sinofone. eSentire ha ricostruito sei stadi distinti, ognuno progettato per ridurre la superficie di rilevamento al passaggio successivo:

1. SEO poisoning e landing page contraffatte (finalshell-ssh.com, xshell-cn.com, quickq-cn.com, clash-cn.com) posizionate in cima ai risultati di ricerca tramite tecniche di manipolazione del ranking.
2. Dropper NativeAOT in .NET 10.0. Il Setup.exe iniziale è compilato con NativeAOT, la modalità di compilazione ahead-of-time introdotta con .NET 10: il risultato è un binario privo delle tipiche strutture metadata IL del CLR, quindi non analizzabile con gli strumenti classici per .NET (dnSpy, ILSpy, de4dot). È una scelta che spezza la pipeline di reverse engineering di molti analisti.
3. Orchestratore DLL in-memory che risolve e carica i componenti successivi senza mai toccare il disco.
4. DLL sideloading su rc.exe, il Microsoft Resource Compiler firmato, che carica una rcdll.dll malevola.
5. Shellcode loader tramite callback di EnumWindows: lo shellcode viene eseguito come callback dell’API di enumerazione finestre, aggirando i monitor che agganciano CreateThread/NtCreateThreadEx.
6. Kong RAT eseguibile: l’impianto finale, con C2 TCP proprietario su MPK1, compressione LZ4 e meccanismo di plug-in.

Tecniche di evasione: il dettaglio che conta

Gli operatori di Kong RAT dimostrano familiarità con la moderna superficie di detection EDR. Quattro punti meritano particolare attenzione.

PEB masquerading come explorer.exe. Prima di eseguire le routine malevole, il loader riscrive le strutture del Process Environment Block per far apparire il processo come explorer.exe. Molti prodotti di rilevamento ragionano su liste di processi “attesi” o su reputation: mascherarsi da explorer.exe riduce il segnale verso il SOC.

UAC bypass silente via CMSTPLUA COM. L’abuso dell’interfaccia COM CMSTPLUA è noto dal 2019 ma resta efficace: la shell malevola ottiene privilegi elevati senza prompt grazie all’auto-elevation dell’oggetto COM, senza dover ricorrere a UAC bypass più rumorosi come fodhelper.exe.

Shellcode tramite EnumWindows. Utilizzare una callback API come dispatcher di shellcode è una tecnica di living-off-the-land meno comune delle più note indirizzazioni (QueueUserAPC, SetWindowsHookEx) e aggira l’instrumentation di molti EDR che vigilano sulle primitive di creazione thread.

Persistenza via RPC diretto. Invece di invocare schtasks.exe — che molti SOC monitorano come marker comportamentale — Kong RAT registra task pianificati chiamando direttamente le RPC del Task Scheduler, con nomi del pattern SimpleActivityScheduleTimer_{GUID}. La configurazione finisce in HKCU\Software\KongClient.

Post-exploitation e telemetria raccolta

Una volta insediato, Kong RAT attiva un keylogger basato su GetAsyncKeyState che scrive in chiaro su C:\ProgramData\KongKeylogger.txt, esegue enumerazioni WMI per mappare i prodotti di sicurezza installati e preleva dati di geolocalizzazione via CDN LeTV. Il payload è modulare: plug-in aggiuntivi possono essere caricati dinamicamente dal C2 tramite il protocollo MPK1 su porta TCP 5947, e la configurazione dei plug-in è persistita in registro sotto HKCU\Software\KongClient\Plugins. Il framework supporta anche C2 migration, una caratteristica che aumenta la resilienza dell’infrastruttura contro takedown parziali.

Attribuzione e contesto

Il percorso PDB di alcuni sample contiene il riferimento all’utente 52pojie, nickname riconducibile alla nota community cinese di reverse engineering 52pojie.cn. È un indizio debole — potrebbe essere una false flag — ma coerente con la targeting cinese e con la lingua delle landing page. L’infrastruttura C2 (x.x-x[.]icu:5947, risolta su 45.192.208.126, ASN Antbox Networks Hong Kong) e l’uso di Alibaba Cloud OSS di Hong Kong come stage server rafforzano l’ipotesi di un attore radicato nell’ecosistema APAC, presumibilmente non direttamente state-sponsored ma al servizio di finalità di raccolta credenziali e accesso iniziale rivendibile.

Indicatori di compromissione

# Domini di distribuzione
finalshell-ssh.com
xshell-cn.com
quickq-cn.com
clash-cn.com

# Infrastruttura C2
x.x-x[.]icu:5947
45.192.208.126 (Antbox Networks, Hong Kong)

# URL di stage
kkwinapp.oss-cn-hongkong.aliyuncs.com/dow/zj.mp4

# SHA-256
Setup.exe  D6620D753E746E63B59E1E47943BE5093F24FD3F82E994115CADEEA3720F1AEA
rcdll.dll  2B7D31A83FF817BE7BDD6E9CF92DEA438CA97DC93EA84CBF048F8656F7DD57DD

# Persistenza
%LOCALAPPDATA%\Programs\Bvasted
HKCU\Software\KongClient\LoginPermanent
HKCU\Software\KongClient\Plugins
C:\ProgramData\KongKeylogger.txt
Scheduled Task: SimpleActivityScheduleTimer_{GUID}

Raccomandazioni per i difensori

La campagna Kong RAT ha tre implicazioni concrete per i team di sicurezza, anche al di fuori del perimetro sinofono. Primo: il DLL sideloading su rc.exe è un pattern che qualunque regola EDR dovrebbe coprire, insieme al monitoraggio delle registrazioni task scheduler via RPC anziché via processo schtasks. Secondo: i binari compilati con NativeAOT in .NET 10 renderanno obsoleti i playbook di reverse basati sul CLR classico — gli analisti devono attrezzarsi con strumenti di disassembly nativo (Ghidra, IDA Pro, Binary Ninja) e familiarizzare con le convenzioni di chiamata di NativeAOT. Terzo: il monitoraggio di GetAsyncKeyState in combinazione con scritture in C:\ProgramData continua a essere un indicatore comportamentale molto efficace, ma solo se integrato nei playbook di hunting e non delegato alla sola signature.

Sul fronte preventivo, le organizzazioni con dipendenti o fornitori cinesi dovrebbero considerare block-list dei quattro domini sopra citati e verificare che nessuno abbia scaricato installer di FinalShell/Xshell/QuickQ/Clash al di fuori dei mirror ufficiali. Per i CERT italiani con controparti manifatturiere in Asia, la campagna rappresenta un vettore realistico di compromissione della supply chain attraverso il laptop di un consulente o di un partner locale.

Kong RAT: la nuova campagna di SEO poisoning con dropper NativeAOT .NET 10 che prende di mira gli sviluppatori cinesi - (in)sicurezza digitale

eSentire TRU ha documentato Kong RAT, un impianto modulare distribuito via installer contraffatti di FinalShell, Xshell, QuickQ e Clash. La catena a sei stadi sfrutta un dropper NativeAOT in .

^{Dario Fadda ((in)sicurezza digitale)}

Spcnet.it

2026-04-17 08:30:12

Visual Studio Debugger Agent: l’IA che caccia i bug per te

Introduzione: fine della ricerca manuale dei bug

Uno dei compiti più frustranti per uno sviluppatore è ricevere una segnalazione di bug vaga come “L’app si blocca a volte” senza passi per riprodurlo. La maggior parte del mattino finisce per essere dedicata a un’indagine forense: posizionare breakpoint a caso, leggere call stack, e cercare di capire cosa stava pensando l’utente originale.

Microsoft sta rivoluzionando questo processo con il nuovo Debugger Agent in Visual Studio 2022, che trasforma il debug da attività manuale e incerta in un processo guidato e interattivo.

Come funziona il debugger agent

A differenza degli strumenti di debugging tradizionali che si limitano a visualizzare il codice, il nuovo Debugger Agent integrato con Copilot Chat diventa un vero partner interattivo, connesso direttamente al runtime della tua applicazione.

Il flusso di lavoro è semplice:

1. Apri Visual Studio con la tua soluzione
2. Attiva la modalità Debugger in Copilot Chat
3. Descrivi il problema con una URL di GitHub/ADO oppure semplicemente: “L’app si blocca quando salvo un file”

Il processo di debug guidato: quattro fasi intelligenti

Una volta che avvii il debugger, l’agente segue un processo strutturato e in tempo reale:

1. Ipotesi e preparazione

L’agente analizza il problema e propone una causa radice. Se il ragionamento è solido, posiziona automaticamente breakpoint intelligenti e prepara il lancio del progetto.

// Se il progetto non si avvia automaticamente,
// avvia manualmente il codice, collega il debugger,
// e comunica all'agente che sei pronto

2. Riproduzione attiva

L’agente rimane “in linea” mentre tu esegui i passi per riprodurre il bug. Monitora lo stato runtime mentre avanzi attraverso i passaggi.

3. Validazione in tempo reale

Quando gli breakpoint vengono raggiunti, l’agente valuta le variabili, i valori locali e il contesto della stack. Non è solo un osservatore passivo, ma un partecipante attivo che costruisce una mappa mentale del fallimento.

4. Identificazione della causa radice

Sulla base dei dati raccolti durante l’esecuzione, l’agente identifica la causa radice e propone correzioni specifiche con spiegazioni dettagliate.

Vantaggi pratici per sviluppatori

Risparmio di tempo: Da 2-3 ore di debug manuale a pochi minuti con il Debugger Agent.

Meno incertezza: L’agente ha accesso ai dati runtime reali, non deduce da codice statico.

Apprendimento: Mentre risolve il problema, l’agente spiega il ragionamento, e impari come affrontare bug simili in futuro.

Supporto per team: Quando ricevi una segnalazione vaga, puoi delegare il debug iniziale all’agente e concentrarti su nuove features.

Conclusione

Il Debugger Agent in Visual Studio 2022 rappresenta un cambio di paradigma nel modo in cui sviluppiamo e risolviamo i problemi. Non è solo un chatbot nel tuo IDE: è un partner intelligente che legge il tuo codice, monitora l’esecuzione, e ti guida attraverso una struttura logica verso la soluzione. Per sviluppatori .NET e C# che spendono ore in debugging manuale, questa è una feature che ripagherà il tempo investito nel primo giorno di utilizzo.

Fonte: Microsoft Visual Studio Blog – Stop Hunting Bugs: Meet the New Visual Studio Debugger Agent

Stop Hunting Bugs: Meet the New Visual Studio Debugger Agent Workflow - Visual Studio Blog

Learn about the new Visual Studio debugger agent that helps streamline debugging, making it easier to tackle bug reports effectively.

^{Harshada Hole (Visual Studio Blog)}

Spcnet.it

2026-04-16 14:14:54

Confronto tra stringhe in C#: Equals, OrdinalIgnoreCase, StringComparer e le insidie culturali

Il confronto tra stringhe è una delle operazioni più comuni in qualsiasi applicazione .NET, eppure è anche una delle fonti più insidiose di bug difficili da riprodurre — specialmente quando l’applicazione viene eseguita in ambienti con culture diverse o in pipeline CI/CD con impostazioni locali variabili. In questo articolo vediamo come funzionano correttamente string.Equals(), OrdinalIgnoreCase, StringComparer e come evitare le trappole più comuni legate alla cultura.

L’operatore == e il confronto ordinale

L’operatore == su stringhe esegue un confronto ordinale case-sensitive, basato sui valori Unicode dei caratteri, senza alcuna considerazione culturale:

var a = "Hello";
var b = "hello";
Console.WriteLine(a == b);       // False
Console.WriteLine(a == "Hello"); // True

Questo è corretto e prevedibile per confronti interni al codice (chiavi di dizionari, nomi di variabili, costanti). Il problema nasce quando si vuole un confronto case-insensitive, o quando si confrontano stringhe con caratteri soggetti a regole culturali.

string.Equals() con StringComparison

La regola d’oro è: passare sempre esplicitamente un parametro StringComparison. Senza di esso, alcuni overload usano CurrentCulture, creando comportamenti potenzialmente incoerenti tra ambienti diversi.

// Confronto case-insensitive, senza dipendenze culturali
bool uguale = string.Equals("admin", input, StringComparison.OrdinalIgnoreCase);

// Equivalente con metodo d'istanza
bool ancheUguale = "admin".Equals(input, StringComparison.OrdinalIgnoreCase);

Panoramica dei valori di StringComparison

Valore	Case	Cultura	Uso consigliato
Ordinal	Sensibile	Nessuna	File, chiavi, dati binari
OrdinalIgnoreCase	Insensibile	Nessuna	Comandi, URL, identificatori
InvariantCulture	Sensibile	Invariante	Testo serializzato/persistito
InvariantCultureIgnoreCase	Insensibile	Invariante	Testo serializzato, case-indipendente
CurrentCulture	Sensibile	Locale utente	Testo mostrato all’utente
CurrentCultureIgnoreCase	Insensibile	Locale utente	Ricerca/filtro lato UI

La trappola di ToLower() e ToUpper()

Uno degli antipattern più diffusi è usare ToLower() per normalizzare le stringhe prima del confronto:

// Antipattern: alloca una nuova stringa inutilmente
if (input.ToLower() == "admin") { }
if (input.ToLowerInvariant() == "admin") { }

// Corretto: nessuna allocazione, semantica esplicita
if (string.Equals(input, "admin", StringComparison.OrdinalIgnoreCase)) { }

Il problema non è solo di prestazioni (allocazione di una stringa temporanea), ma di correttezza semantica. La versione con ToLower() dipende dalla cultura corrente del thread, mentre OrdinalIgnoreCase è culturalmente neutro e deterministico.

Il problema della “i” Turca

Questo è forse il bug più famoso legato alla cultura nelle stringhe. In turco esistono quattro varianti della lettera i: la “i” minuscola con punto diventa “İ” maiuscola con punto (non “I” come in italiano), e la “ı” minuscola senza punto diventa “I” maiuscola. Il risultato:

var culture = new System.Globalization.CultureInfo("tr-TR");

// Bug su locale turco!
bool sbagliato = "file".ToUpper(culture) == "FILE"; // False! "file" diventa "FİLE" in turco

// OrdinalIgnoreCase usa regole invarianti
bool corretto = string.Equals("file", "FILE", StringComparison.OrdinalIgnoreCase); // True

Questo bug si manifesta tipicamente in applicazioni multi-tenant o globali dove il server ha una cultura diversa dall’ambiente di sviluppo. La soluzione è sempre usare OrdinalIgnoreCase per confronti tecnici (nomi di file, comandi, URL, header HTTP) e riservare CurrentCulture solo al testo destinato all’utente finale.

StringComparer per collezioni

StringComparer implementa sia IComparer<string> che IEqualityComparer<string>, rendendolo ideale per strutture dati come Dictionary, HashSet e SortedSet:

Dizionario case-insensitive per gli header HTTP

// "Content-Type" e "content-type" devono essere equivalenti
var headers = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
headers["Content-Type"] = "application/json";

Console.WriteLine(headers["content-type"]); // application/json
Console.WriteLine(headers["CONTENT-TYPE"]); // application/json

SortedSet case-insensitive

var comandi = new SortedSet<string>(StringComparer.OrdinalIgnoreCase);
comandi.Add("Start");
comandi.Add("stop");

bool haStart = comandi.Contains("START"); // True
// I duplicati vengono rilevati correttamente
comandi.Add("START"); // Non aggiunge, esiste già come "Start"
Console.WriteLine(comandi.Count); // 2

Confronto ad alte prestazioni con Span<char>

Per scenari con requisiti di performance elevati (parsing di protocolli, hot paths), .NET offre confronti allocation-free tramite ReadOnlySpan<char>:

var riga = "Content-Type: application/json";

// Confronto senza allocare nuove stringhe
bool isContentType = riga.AsSpan(0, 12).Equals(
    "Content-Type".AsSpan(),
    StringComparison.OrdinalIgnoreCase);

// StartsWith su Span
bool isHttps = url.AsSpan().StartsWith(
    "https://".AsSpan(),
    StringComparison.OrdinalIgnoreCase);

Questo approccio è particolarmente utile in middleware HTTP, parser di configurazione e codice che elabora grandi volumi di testo.

Pattern Matching con Switch

Il pattern matching di C# non supporta nativamente il confronto case-insensitive negli switch, ma esistono due approcci corretti:

// Approccio 1: Guard clause con Equals
var risultato = comando switch
{
    _ when string.Equals(comando, "start", StringComparison.OrdinalIgnoreCase) => "Avvio...",
    _ when string.Equals(comando, "stop", StringComparison.OrdinalIgnoreCase) => "Arresto...",
    _ => "Comando non riconosciuto"
};

// Approccio 2: Normalizzazione con ToUpperInvariant (accettabile per switch)
var risultato2 = comando.ToUpperInvariant() switch
{
    "START" => "Avvio...",
    "STOP" => "Arresto...",
    _ => "Comando non riconosciuto"
};

Esempio completo: parser di configurazione

public sealed class ConfigParser
{
    private readonly FrozenDictionary<string, string> _impostazioni;

    public ConfigParser(IEnumerable<KeyValuePair<string, string>> rawSettings)
    {
        // FrozenDictionary è ottimizzato per letture frequenti (immutabile dopo la creazione)
        _impostazioni = rawSettings.ToFrozenDictionary(
            kvp => kvp.Key,
            kvp => kvp.Value,
            StringComparer.OrdinalIgnoreCase);
    }

    public string? Get(string chiave) =>
        _impostazioni.TryGetValue(chiave, out var valore) ? valore : null;
}

// Utilizzo
var config = new ConfigParser(new[]
{
    new KeyValuePair<string, string>("DatabaseUrl", "Server=..."),
    new KeyValuePair<string, string>("MaxConnections", "100"),
});

Console.WriteLine(config.Get("databaseurl"));    // "Server=..."
Console.WriteLine(config.Get("MAXCONNECTIONS")); // "100"

Riepilogo: regole pratiche

1. Usa OrdinalIgnoreCase per chiavi, identificatori, URL, nomi di file, comandi, header HTTP.
2. Usa CurrentCulture solo per testo mostrato all’utente, quando le regole locali sono rilevanti.
3. Non usare ToLower() per confronti: alloca inutilmente e dipende dalla cultura.
4. Specifica sempre StringComparison esplicitamente nelle chiamate a Equals e Compare.
5. Usa StringComparer quando passi logica di confronto a strutture dati.
6. Usa MemoryExtensions su Span<char> per hot path ad alta frequenza e senza allocazioni.

Seguendo queste linee guida, si eliminano intere classi di bug difficili da riprodurre e si ottiene codice più robusto, portabile e performante.

Fonte: DevLeader — C# String Comparison: Equals, OrdinalIgnoreCase, StringComparer, and Culture Pitfalls

C# String Comparison: Equals, OrdinalIgnoreCase, StringComparer, and Culture Pitfalls

Master C# string comparison with Equals, OrdinalIgnoreCase, StringComparer, and culture-sensitive APIs. Avoid the ToLower() antipattern and Turkish i problem.

^{Nick Cosentino (Dev Leader)}

(in)sicurezza digitale

2026-04-16 15:08:07

Qilin e Warlock BYOVD: come il ransomware disabilita 300+ soluzioni EDR utilizzando driver vulnerabili

Qilin e Warlock, due dei ransomware RaaS (Ransomware-as-a-Service) più sofisticati del panorama criminale, hanno potenziato significativamente le loro capacità di evasione implementando la tecnica BYOVD (Bring Your Own Vulnerable Driver). La nuova strategia consente ai malware di disabilitare oltre 300 soluzioni EDR/XDR utilizzando driver vulnerabili del kernel, rendendo inefficaci quasi tutti i sistemi di rilevamento degli endpoint contemporanei.

Dalla lateralizzazione alla disattivazione: la nuova tattica Qilin

Qilin rappresenta una delle principali operazioni di ransomware RaaS attualmente operative. Il gruppo ha consolidato il controllo su decine di reti aziendali utilizzando metodologie di accesso ben collaudate e movimentazione laterale. Tuttavia, la fase finale dell’attacco era frequentemente rilevata dagli EDR in grado di identificare comportamenti malware tipici durante la crittografia di file.

Con l’introduzione della catena di infezione EDR-Killer, Qilin ha chiuso questa lacuna critica. Gli attacchi moderni seguono un pattern ben definito: accesso iniziale, lateralizzazione (6 giorni medi), disattivazione degli EDR, dispiegamento ransomware.

La catena multi-stadio: msimg32.dll e il carico del Kernel

La catena di infezione EDR-Killer di Qilin utilizza la tecnica classica del DLL Side-Loading per eseguire una DLL malevola denominata “msimg32.dll”. Per mantenere la funzionalità attesa, la DLL malevola invia gli API call legittimi alla libreria legittima in C:\Windows\System32, mascherando completamente la sua attività malevola.

Lo stadio 1 implementa una tabella slot-policy per l’evasione delle syscall e la tecnica “Halo’s Gate”, consentendo al codice malware di invocare direttamente funzioni di kernel bypassando i filtri tradizionali. Gli stadi 2-3 presentano offuscamento del flusso di controllo VEH-based complesso.

Il doppio carico di driver: rwdrv.sys e hlpdrv.sys

rwdrv.sys è una versione rinominata di “ThrottleStop.sys”, uno strumento legittimo di tuning dei processori Intel. Sfruttando una vulnerabilità nel driver originale, Qilin lo utilizza per ottenere accesso diretto alla memoria fisica del sistema. Una volta caricato nel kernel, rwdrv.sys funziona come un livello di accesso hardware di modo kernel.

hlpdrv.sys è il vero “EDR killer”. Lavora in stretto coordinamento con rwdrv.sys per terminare i processi associati a oltre 300 diversi driver EDR appartenenti a praticamente ogni maggiore fornitore di sicurezza. Prima di caricare hlpdrv.sys, il componente EDR-killer annulla la registrazione dei callback di monitoraggio stabiliti dall’EDR, accecando efficacemente lo strumento di rilevamento a livello di kernel.

Meccanismo di disattivazione tecnica: callback unregistration

I sistemi di rilevamento moderni utilizzano callback di kernel registrati per monitorare eventi critici: creazione di processi, creazione di thread, caricamento di moduli/DLL, operazioni di file system. Iterando attraverso una lista hardcoded di oltre 300 driver EDR, Qilin annulla sistematicamente la registrazione dei loro callback di monitoraggio.

Senza questi callback, l’EDR diventa essenzialmente cieco: non può rilevare nuovi processi, non può intercettare thread sospetti, non può monitorare il caricamento di moduli malware. Una volta che i callback sono stati annullati, hlpdrv.sys procede a terminare i processi del servizio EDR stesso, disattivando completamente la protezione in tempo reale.

Timeline e implicazioni per la difesa

L’analisi forense rivela un pattern tattico coerente: accesso iniziale via credenziali compromesse, lateralizzazione (6 giorni medi), EDR disattivazione, dispiegamento ransomware. Questa evoluzione tattica rappresenta una significativa escalation nella sofisticazione dei ransomware RaaS.

Per la difesa: implementare il Kernel Patch Protection (KPP/HVCI), implementare Device Guard per il whitelisting dei driver firmati, implementare segmentazione di rete aggressiva, monitorare il movimento laterale, implementare il privileged access management (PAM). Se il caricamento di un driver sospetto viene rilevato, avviare immediatamente un killchain completo dell’incidente con isolamento di rete e acquisizione forense.