Incident : XMRig injecté dans mon Gitea via packObjectsHook
Mon Gitea auto-hébergé a été compromis par un cryptominer XMRig déployé via le mécanisme git packObjectsHook. Retour d’expérience sur la détection, l’analyse et la remédiation.
Mon Gitea auto-hébergé a été compromis par un cryptominer XMRig déployé via le mécanisme git packObjectsHook. Retour d’expérience sur la détection, l’analyse et la remédiation.
J’ai vu un post sur Dread décrivant l’usage des flux Falcon MCP pour tracker des C2 APT. Ce soir, j’ai reproduit ça avec mes propres sources gratuites — et trouvé un C2 Cobalt Strike actif dans ma base.
SOCRadar exposed an active Russian espionage campaign targeting Ukraine’s defense sector. Their C2 stack? Almost identical to my homelab. Here’s the full comparison.
Mon alert-agent appelait Ollama/Mistral pour prendre des décisions de remédiation. Problème : 40+ secondes de latence, timeouts, et une sévérité figée à ‘warning’. Voilà comment j’ai branché Claude Haiku à la place — et pourquoi ça change vraiment quelque chose.
J’ai branché mon modèle RandomForest sur 6 millions de vrais hosts Metasploit — et obtenu accuracy=1.0. Voilà pourquoi c’était un bug, pas un succès, et comment j’ai vraiment corrigé le tir.
Mon alertmanager.yml avait deux credentials en clair : un token Telegram et un mot de passe SMTP. Je les ai migrés vers des Docker secrets en dix minutes — sans patcher l’image ni écrire une ligne de script.
J’intègre Trivy dans mon pipeline Gitea Actions pour scanner automatiquement mes 30+ Dockerfiles et stacks Docker Swarm à chaque push. Premier constat : mon propre infra avait des gaps évidents.
Comment j’ai ajouté un enrichissement OSINT automatique sur chaque IP lors du fingerprinting réseau — détection de menaces en temps réel, 20 minutes de dev avec Claude.
Comment j’ai construit, en partant de zéro, une plateforme de threat intelligence de niveau production qui prédit les attaques DDoS en surveillant les canaux Telegram hacktivistes.