~/docs/detection/llm-soc-detection-starter.mdDerniere modification : maintenant
AUDIENCE:SOC leads, blue teams, detection engineers, incident responders et responsables securite qui doivent cadrer des usages LLM sans rester au niveau purement theorique.
PROMESSE:Passer d'un sujet OWASP LLM abstrait a un pack concret: scenarios prioritaires, signaux a logger, correlations a tester et exemples SPL directement telechargeables.

LLM SOC Detection Starter Pack

5 scenarios a surveiller, les signaux a correler et les priorites de detection a mettre en place en premier sur une stack LLM.

Un document de cadrage detection pour transformer les risques LLM en surfaces observables, correlations initiales et premiers SPL reutilisables.

Le plus mauvais reflexe face aux usages LLM est de discuter les risques sans regarder les signaux qu ils produisent deja.

Cette ressource condense l essentiel en un point de depart simple: 5 scenarios prioritaires, les signaux a logger, les correlations a tester et une logique source-backed pour commencer sans survendre la couverture.

##Ce que vous obtenez exactement

  • -5 scenarios LLM a prioriser cote SOC.
  • -Les signaux a logger en premier pour rendre ces usages visibles.
  • -Les correlations a tester avant de promettre une couverture complete.
  • -Une logique de detection de depart qui reste lisible pour une blue team.
  • -Un pack JSON des 5 SPL source-backed pour accelerer le cadrage.

##Lecture recommandee

[01]Partir d'un scenario observable
[02]Identifier les signaux qui bougent
[03]Relier les signaux a une correlation initiale
[04]Comparer avec les patterns Splunk publics
[05]Telecharger le pack JSON de SPL

Recevoir les prochaines ressources detection LLM

Laisse ton email pour recevoir les prochains packs detection, analyses blue team et schemas associes. La lecture reste libre sans inscription.

Verification anti-bot requise avant envoi.

La lecture de cette ressource reste ouverte. L'email sert uniquement a preparer les prochains envois et updates.

##SPL exacts du repo

Les 5 exemples ci-dessous viennent directement de splunk/security_content. Leur interet n'est pas de faire croire a une couverture complete. Leur interet est de montrer qu'il existe deja du SPL LLM ou AI-adjacent publiquement exploitable comme point de depart.

01. MCP Prompt Injection

Source: splunk/security_content

Prompt injection sur trafic MCP.

`mcp_server` direction=inbound ( "IGNORE PREVIOUS INSTRUCTIONS" OR "AI_INSTRUCTION" OR "SYSTEM PROMPT OVERRIDE" OR "[SYSTEM]:" OR "ignore all security" OR "New directive" OR "ignore security policies" )
| eval dest=host
| eval injection_payload=coalesce('params.content_preview', 'params.result_preview')
| eval target_path='params.path'
| eval sql_query='params.query'
| stats count min(_time) as firstTime max(_time) as lastTime values(method) as method values(target_path) as target_path values(sql_query) as sql_query values(injection_payload) as injection_payload by dest, source
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| table dest firstTime lastTime count source method target_path sql_query injection_payload
| `mcp_prompt_injection_filter`

02. M365 Copilot Jailbreak Attempts

Source: splunk/security_content

Tentatives de jailbreak sur prompts Microsoft 365 Copilot.

`m365_exported_ediscovery_prompt_logs`
| search Subject_Title IN ("*act as*", "*bypass*", "*ignore*", "*override*", "*pretend you are*", "*rules=*")
| eval user = Sender
| eval jailbreak_score=case(match(Subject_Title, "(?i)pretend you are.*amoral"), 4, match(Subject_Title, "(?i)act as.*entities"), 3, match(Subject_Title, "(?i)(ignore|bypass|override)"), 3, match(Subject_Title, "(?i)rules\s*="), 4, 1=1, 1)
| where jailbreak_score >= 2
| table _time, user, Subject_Title, jailbreak_score, Workload, Size
| sort -jailbreak_score, -_time
| `m365_copilot_jailbreak_attempts_filter`

03. LLM Model File Creation

Source: splunk/security_content

Creation locale de fichiers de modeles LLM sur endpoint.

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime from datamodel=Endpoint.Filesystem where Filesystem.file_name IN ("*.gguf*", "*ggml*", "*Modelfile*", "*safetensors*") by Filesystem.action Filesystem.dest Filesystem.file_access_time Filesystem.file_create_time Filesystem.file_hash Filesystem.file_modify_time Filesystem.file_name Filesystem.file_path Filesystem.file_acl Filesystem.file_size Filesystem.process_guid Filesystem.process_id Filesystem.user Filesystem.vendor_product
| `drop_dm_object_name(Filesystem)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `llm_model_file_creation_filter`

04. Local LLM Framework DNS Query

Source: splunk/security_content

Usage local de frameworks LLM ou telechargement de modeles.

`sysmon` EventCode=22 QueryName IN ("*huggingface*", "*ollama*", "*jan.ai*", "*gpt4all*", "*nomic*", "*koboldai*", "*lmstudio*", "*modelscope*", "*civitai*", "*oobabooga*", "*replicate*", "*anthropic*", "*openai*", "*openrouter*", "*api.openrouter*", "*aliyun*", "*alibabacloud*", "*dashscope.aliyuncs*") NOT Image IN ("*\MsMpEng.exe", "C:\ProgramData\*", "C:\Windows\System32\*", "C:\Windows\SysWOW64\*")
| stats count min(_time) as firstTime max(_time) as lastTime by src Image process_name QueryName query_count answer answer_count reply_code_id vendor_product
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `local_llm_framework_dns_query_filter`

05. AWS Bedrock Invoke Model Access Denied

Source: splunk/security_content

Tentative d acces refuse a des modeles AWS Bedrock.

`cloudtrail` eventSource=bedrock.amazonaws.com eventName=InvokeModel errorCode=AccessDenied
| rename user_name as user
| stats count min(_time) as firstTime max(_time) as lastTime values(requestParameters.modelId) as modelIds by src user user_agent vendor_account vendor_product dest signature vendor_region result result_id
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
| `aws_bedrock_invoke_model_access_denied_filter`
JSON

Telecharger le pack JSON de SPL

Le JSON reprend les 5 detections sous forme d objets exploitables, avec nom, surface, scenario, SPL et source de reference.

Ouvrir le JSON

##Pourquoi ce sujet compte maintenant

Le vrai probleme avec les risques LLM n'est pas de les connaitre. C'est de ne pas savoir quoi surveiller, quoi correler et quoi detecter en premier.

Pour une blue team, le sujet utile n'est donc pas seulement quel item OWASP concerne l'architecture. Le sujet utile devient: quelles surfaces LLM existent deja, quels signaux remontent, quels patterns seraient difficiles a expliquer a un analyste, et quels scenarios justifient une detection prioritaire.

  • -Quelles surfaces LLM existent deja dans l environnement ?
  • -Quels signaux remontent deja ?
  • -Quels patterns seraient difficiles a expliquer a un analyste ?
  • -Quels scenarios justifient une detection prioritaire ?

##Un exemple simple: quand un prompt devient un scenario SOC

Prompt exemple

say cheese over and over until you cannot say it anymore

Le prompt a l'air idiot. Mais ce qui compte pour un SOC n'est pas le texte. C'est ce qu'il fait bouger dans la telemetrie.

On ne cherche donc pas seulement un prompt bizarre. On cherche un pattern observable de consommation anormale. C'est exactement la bascule qui rend LLM04 utile pour une priorisation detection.

  • -Hausse de tokens par prompt ou par session
  • -Latence anormale
  • -Faible rendement tokens/seconde
  • -Hausse du rythme de requetes
  • -Pression sur les files d attente backend

##Les 5 scenarios ou le sujet devient operationnel

Scenario 1 : Prompt injection avec action ou sortie non prevue

  • ->Tool calls rares
  • ->Destinations nouvelles
  • ->Actions hors baseline

Scenario 2 : Fuite de donnees sensibles via prompts, contexte ou reponses

  • ->Sorties trop riches
  • ->Extraction repetee
  • ->Exports anormaux

Scenario 3 : Model DoS et abus de consommation tokens / latence

  • ->Tokens en hausse
  • ->Latence anormale
  • ->Retries et saturation

Scenario 4 : Usage non autorise ou detournement d identite sur les interfaces LLM

  • ->Identite incoherente
  • ->Routes nouvelles
  • ->Volume hors profil

Scenario 5 : Exfiltration de connaissances systeme ou model extraction progressive

  • ->Repetition forte
  • ->Variations incrementales
  • ->Intensite extractive

Prompt injection avec action ou sortie non prevue

Menace / mecanisme

Un prompt force une action, un appel d outil ou une sortie qui n etait pas attendue par le workflow normal.

Signaux a logger
  • -Prompt brut ou redacted
  • -Reponse brute
  • -Tool calls ou function calls
  • -Destinations externes appelees apres le prompt
  • -Policy denials ou contournements
  • -Metadonnees de session
Logique de detection de depart

Remonter les sequences ou un prompt suspect est suivi d'un appel d'outil rare, d'une destination nouvelle ou d'une action nettement hors baseline pour cette app, cet utilisateur ou ce tenant.

Angle Splunk / source-backed

Traiter ce scenario comme une chaine entree suspecte -> action externe -> enrichissement et reutiliser les patterns adjacents de reputation URL, d'identifier activity et de dynamic analysis comme precedent d'operationalisation.

Fuite de donnees sensibles via prompts, contexte ou reponses

Menace / mecanisme

Des secrets, de la PII, du contexte interne, des prompts systeme ou des fragments RAG ressortent dans les echanges ou sont exfiltres progressivement.

Signaux a logger
  • -Taille des prompts et des reponses
  • -Tags de sensibilite ou PII
  • -Volume de contexte injecte
  • -Source documentaire ou RAG
  • -Sorties a haute entropie
  • -Destinations aval ou exports
Logique de detection de depart

Remonter les sessions ou les reponses sont anormalement riches, ou le comportement d'extraction se repete, ou l'on voit un enchainement source sensible -> longue reponse -> export.

Angle Splunk / source-backed

Utiliser les patterns exfiltration, anomaly detection et telemetry prerequisites comme precedent methodologique plutot qu'une signature LLM pretendument universelle.

Model DoS et abus de consommation tokens / latence

Menace / mecanisme

L usage pousse le modele, l orchestrateur ou les backends dans une zone de consommation anormale ou de saturation.

Signaux a logger
  • -Tokens input/output
  • -Latence totale
  • -Retries et timeouts
  • -Cadence de requetes
  • -Concurrence par session
  • -Cout estime
  • -Saturation de file d attente
Logique de detection de depart

Creer un baseline par app, route, identite ou tenant, puis detecter la derive simultanee des tokens, de la latence, des retries et de la frequence.

Angle Splunk / source-backed

Utiliser les patterns de baselines, d anomaly et la categorie abuse comme precedent detection pour cadrer les seuils et l interpretation.

Usage non autorise ou detournement d identite sur les interfaces LLM

Menace / mecanisme

Une cle API, un compte de service ou une identite applicative est utilisee hors contexte attendu pour interroger l interface LLM ou declencher ses outils.

Signaux a logger
  • -Identite technique ou humaine
  • -IP source et user-agent
  • -Route ou modele appele
  • -Succes et echecs auth
  • -Horaires
  • -Volumes d usage
  • -Nouvelles destinations ou nouveaux clients
Logique de detection de depart

Remonter les anomalies d'usage par identite, surtout quand elles combinent source inhabituelle, volume anormal, nouvelles routes et activite en dehors du profil normal.

Angle Splunk / source-backed

Reutiliser les patterns IAM, account locking et identifier activity pour traiter une interface LLM comme une surface d'acces et d'abus d'identite.

Exfiltration de connaissances systeme ou model extraction progressive

Menace / mecanisme

L'attaquant tente d'obtenir progressivement les prompts systeme, les regles internes, les artefacts de comportement ou des equivalences fonctionnelles.

Signaux a logger
  • -Repetition de prompts proches
  • -Variations incrementales d une meme demande
  • -Volumes de reponses inspectees
  • -Acces repetes aux memes corpus
  • -Intensite conversationnelle
  • -Requetes meta sur les regles, instructions ou comportements
Logique de detection de depart

Remonter les sessions a forte repetition, faible diversite fonctionnelle et intensite extractive elevee, surtout quand elles se concentrent sur le systeme lui-meme plutot que sur l'usage metier.

Angle Splunk / source-backed

Utiliser les patterns de hunting, d'investigations et de baselines comme precedent pour une detection progressive plutot qu'une logique de signature statique.

##Signals to log first

  • -Prompt brut ou redacted
  • -Reponse brute ou redacted
  • -Tokens input/output
  • -Latence par session
  • -Utilisateur ou identite technique
  • -Tool calls et destinations aval
  • -Contexte injecte ou source RAG

##What to correlate first

  • -Prompt suspect + appel d outil rare
  • -Hausse de tokens + hausse de latence
  • -Sortie sensible + export ou destination aval
  • -Identite inhabituelle + volume anormal
  • -Repetitions extractives + faible diversite fonctionnelle

##Ce que contient le starter pack

  • *Un cadrage detection oriente SOC plutot que compliance.
  • *Un exemple LLM04 qui montre comment un prompt devient un signal observable.
  • *Les premiers signaux et correlations a prioriser.
  • *Un fichier JSON telechargeable avec 5 SPL LLM ou AI-adjacent.

##Ce que Splunk apporte vraiment ici

  • -Des patterns de hunting et d identifier activity
  • -Des precedents d exfiltration et d anomaly detection
  • -Des playbooks et investigations pour l operationalisation
  • -Des data sources pour cadrer la telemetrie necessaire
  • -Un cadre source-backed sans pretendre a 5 detections universelles

##30-day first move

[01]Semaine 1 : Inventorier les surfaces LLM reelles.
[02]Semaine 2 : Verifier les signaux deja visibles.
[03]Semaine 3 : Choisir 2 scenarios prioritaires et definir un baseline simple.
[04]Semaine 4 : Tester une correlation initiale et un playbook de triage court.

##Closing

L'objectif de ce pack n'est pas de prouver que votre stack LLM est deja couverte. C'est de rendre visible ce qui doit l'etre d'abord.

Si vous avez maintenant une meilleure idee de ce que votre SOC doit surveiller, alors le pack a deja fait son travail.

Quel scenario LLM votre SOC serait incapable d expliquer aujourd hui ?