💼 Prêt à vous démarquer en cybersécurité ? Découvrez l'importance d'un portfolio bien rempli et comment attirer les recruteurs dans ce domaine compétitif. Regardez notre vidéo maintenant pour des conseils pratiques ! #Cyber #Portfolio
🎥https://youtu.be/89k1hDp4cvM
🎥https://youtu.be/89k1hDp4cvM
🔥3❤1👍1🥰1
💻 Préoccupé par le defacement de votre site web ? Apprenez comment vous protéger avec notre guide complet en cybersécurité. Regardez notre vidéo maintenant pour renforcer votre sécurité en ligne !
🎥https://youtu.be/RxmW8VXDCCU
🎥https://youtu.be/RxmW8VXDCCU
🐞🔍 Plongez dans la vie des bug hunters ! Découvrez les défis quotidiens comme la solitude et la gestion des revenus. Regardez notre vidéo pour une perspective authentique sur cette carrière en cyber sécurité. #BugBounty #Cyber
🎥 https://youtu.be/3-z4PbVCmeU
🎥 https://youtu.be/3-z4PbVCmeU
Salut à tous,
Pendant 3 années j’ai essayé de vous aider à travailler dans le milieu de la cybersécurité.
Je sais que pour de nombreuses personnes (dont les étudiants), le coup d’une formation est un frein majeur.
J’ai officiellement décidé de rendre mon programme accessible au plus grand nombre dès aujourd’hui.
Pour 47€ vous accédez à plus de 5 heures de contenu vous permettant d’obtenir les connaissances nécessaires pour faire de votre métier la cybersécurité.
https://overshell.systeme.io/formation-debutant
À travers 4 modules sous forme de vidéo vous allez découvrir :
- Comment maitriser les bases de la cybersécurité
- Appréhender la défense en profondeur pour protéger une société- Savoir mettre en place une analyse de risque
- Savoir gérer une crise cyber- Maitriser les méthodologies utilisées lors des intrusions
- Et bien encore.
https://overshell.systeme.io/formation-debutant
Vous pouvez suivre la formation à votre rythme et revoir le contenu tant que vous le souhaitez.
Bonne journée
Mickael de Over Shell
Pendant 3 années j’ai essayé de vous aider à travailler dans le milieu de la cybersécurité.
Je sais que pour de nombreuses personnes (dont les étudiants), le coup d’une formation est un frein majeur.
J’ai officiellement décidé de rendre mon programme accessible au plus grand nombre dès aujourd’hui.
Pour 47€ vous accédez à plus de 5 heures de contenu vous permettant d’obtenir les connaissances nécessaires pour faire de votre métier la cybersécurité.
https://overshell.systeme.io/formation-debutant
À travers 4 modules sous forme de vidéo vous allez découvrir :
- Comment maitriser les bases de la cybersécurité
- Appréhender la défense en profondeur pour protéger une société- Savoir mettre en place une analyse de risque
- Savoir gérer une crise cyber- Maitriser les méthodologies utilisées lors des intrusions
- Et bien encore.
https://overshell.systeme.io/formation-debutant
Vous pouvez suivre la formation à votre rythme et revoir le contenu tant que vous le souhaitez.
Bonne journée
Mickael de Over Shell
overshell.systeme.io
Page de présentation
👍8❤1😁1
Hello ,
Après 3 ans à vous donner des informations et des conseils sur la cybersécurité, j’ai décidé d’arrêter la chaine Youtube Over Shell.
Je ferai un dernier live vendredi 9 aout 2024 à 12h (heure de Paris).
https://www.youtube.com/watch?v=gzHBw5xVyZ8
Je prendrai le temps de répondre à l’ensemble de vos questions et vous expliquerai ma décision.
Je resterai en support pour les personnes ayant souscrit à la formation cybersécurité débutant.
Au plaisir de vous voir durant ce dernier échange.
Mickael de Over Shell
Après 3 ans à vous donner des informations et des conseils sur la cybersécurité, j’ai décidé d’arrêter la chaine Youtube Over Shell.
Je ferai un dernier live vendredi 9 aout 2024 à 12h (heure de Paris).
https://www.youtube.com/watch?v=gzHBw5xVyZ8
Je prendrai le temps de répondre à l’ensemble de vos questions et vous expliquerai ma décision.
Je resterai en support pour les personnes ayant souscrit à la formation cybersécurité débutant.
Au plaisir de vous voir durant ce dernier échange.
Mickael de Over Shell
YouTube
Je vous ai accompagné pendant 3 ans maintenant, j'arrête Youtube...
Dans ce live je vous explique pourquoi je vais arrêter de publier de nouvelles vidéos en cybersécurité.
Ce live sera pour nous la dernière occasion d'échanger en direct ensemble.
🎁 Téléchargez votre guide pour bien débuter dans la cybersécurité 🎁 : http…
Ce live sera pour nous la dernière occasion d'échanger en direct ensemble.
🎁 Téléchargez votre guide pour bien débuter dans la cybersécurité 🎁 : http…
😢8👍2🤔2😱1
Salut à tous,
On commence dans 15 minutes le live sur YouTube.
https://www.youtube.com/watch?v=gzHBw5xVyZ8
A tout de suite.
On commence dans 15 minutes le live sur YouTube.
https://www.youtube.com/watch?v=gzHBw5xVyZ8
A tout de suite.
YouTube
Je vous ai accompagné pendant 3 ans maintenant, j'arrête Youtube...
Dans ce live je vous explique pourquoi je vais arrêter de publier de nouvelles vidéos en cybersécurité.
Ce live sera pour nous la dernière occasion d'échanger en direct ensemble.
🎁 Téléchargez votre guide pour bien débuter dans la cybersécurité 🎁 : http…
Ce live sera pour nous la dernière occasion d'échanger en direct ensemble.
🎁 Téléchargez votre guide pour bien débuter dans la cybersécurité 🎁 : http…
❤5👍4
Tu peux savoir lancer un nmap, monter un lab et faire tomber une machine vulnérable, et rester incapable de dire pourquoi une entreprise devrait te payer pour ça.
C'est l'impasse classique de l'autoformation en cybersécurité : on collectionne des outils, on n'acquiert jamais une lecture du système. Résultat, tu progresses en technique et tu stagnes en employabilité.
L'ordre qui fonctionne est l'inverse de celui que tout le monde prend :
1️⃣ Lire le système (réseaux, identités, données)
2️⃣ Qualifier le risque (menaces, impacts, priorités)
3️⃣ Comprendre la défense (prévenir, détecter, répondre)
4️⃣ Seulement après, choisir sa voie
Le pentest n'est pas le point d'entrée du domaine. C'est une méthode de mesure, et elle n'a de sens que si tu sais déjà ce que tu mesures.
J'ai reconstruit Over Shell Academy entièrement autour de cette progression. C'est en ligne.
👉 https://academy.overshell.com
C'est l'impasse classique de l'autoformation en cybersécurité : on collectionne des outils, on n'acquiert jamais une lecture du système. Résultat, tu progresses en technique et tu stagnes en employabilité.
L'ordre qui fonctionne est l'inverse de celui que tout le monde prend :
1️⃣ Lire le système (réseaux, identités, données)
2️⃣ Qualifier le risque (menaces, impacts, priorités)
3️⃣ Comprendre la défense (prévenir, détecter, répondre)
4️⃣ Seulement après, choisir sa voie
Le pentest n'est pas le point d'entrée du domaine. C'est une méthode de mesure, et elle n'a de sens que si tu sais déjà ce que tu mesures.
J'ai reconstruit Over Shell Academy entièrement autour de cette progression. C'est en ligne.
👉 https://academy.overshell.com
Over Shell
Over Shell Academy : apprendre la cybersécurité
Apprenez les fondamentaux de la cybersécurité, découvrez les métiers et construisez un parcours adapté grâce aux ressources pédagogiques d’Over Shell.
👏4
⚡️ Les agents IA progressent très vite sur la reproduction de vulnérabilités
CyberGym est un benchmark de l'UC Berkeley qui mesure une chose précise : un agent reçoit la description d'une vulnérabilité connue et le code source non corrigé, puis doit produire un proof of concept qui déclenche réellement le bug.
Le dispositif :
• 1 507 vulnérabilités réelles
• 188 projets open source en C/C++, issus d'OSS-Fuzz
• validation par exécution : le PoC doit faire crasher la version pré-patch, et pas la version corrigée
📈 Ce qui a changé en un an. À la publication du papier (juin 2025), la meilleure combinaison agent + modèle plafonnait autour de 20 %. Les meilleurs scores publiés aujourd'hui dépassent 85 %.
Deux effets de bord documentés par les auteurs pendant l'évaluation : 34 vulnérabilités zero-day découvertes et 17 correctifs incomplets identifiés.
⚠️ Comment lire ces chiffres. La tâche notée est la reproduction d'une faille déjà connue, avec sa description fournie. Ce n'est pas de la découverte auto
CyberGym est un benchmark de l'UC Berkeley qui mesure une chose précise : un agent reçoit la description d'une vulnérabilité connue et le code source non corrigé, puis doit produire un proof of concept qui déclenche réellement le bug.
Le dispositif :
• 1 507 vulnérabilités réelles
• 188 projets open source en C/C++, issus d'OSS-Fuzz
• validation par exécution : le PoC doit faire crasher la version pré-patch, et pas la version corrigée
📈 Ce qui a changé en un an. À la publication du papier (juin 2025), la meilleure combinaison agent + modèle plafonnait autour de 20 %. Les meilleurs scores publiés aujourd'hui dépassent 85 %.
Deux effets de bord documentés par les auteurs pendant l'évaluation : 34 vulnérabilités zero-day découvertes et 17 correctifs incomplets identifiés.
⚠️ Comment lire ces chiffres. La tâche notée est la reproduction d'une faille déjà connue, avec sa description fournie. Ce n'est pas de la découverte auto
❤2
🔌 Ton assistant IA a les clés de la maison. Tu sais où elles sont stockées ?
MCP (Model Context Protocol) est le standard qui permet à un agent IA d'agir sur de vrais systèmes : lire une base, ouvrir un fichier, appeler une API. Entre l'IA et le système, il y a un petit programme intermédiaire, le serveur MCP.
Et pour agir sur un système, ce serveur a besoin des identifiants de ce système. Clés d'API, tokens, comptes de service. Tout ça se retrouve concentré au même endroit.
Les quatre façons dont ça fuite :
1️⃣ Secrets en clair dans les fichiers de conf. Pour démarrer un serveur MCP, on colle souvent une chaîne de configuration qui contient directement les identifiants. Ce fichier finit copié entre machines, ou commité dans un dépôt Git.
2️⃣ La dispersion. Chaque agent gère ses propres secrets, dupliqués entre dev, staging et prod. Personne n'a l'inventaire, donc rien n'est jamais tourné. Résultat : des identifiants valides indéfiniment.
3️⃣ Les permissions trop larges. Pendant le développement, on donne des droits généreux pour éviter les erreurs d'autorisation. Ces droits partent en production et n'en reviennent jamais.
4️⃣ L'injection de prompt. Celle-là est spécifique à l'IA. L'agent lit du contenu et agit dessus. Un attaquant peut cacher des instructions dans un document, un ticket ou une page web, et l'agent les exécute comme si elles venaient de toi.
🧱 Le cas concret. CVE-2025-6514, découverte par JFrog en juillet 2025. Le proxy mcp-remote acceptait sans validation l'URL d'authentification renvoyée par le serveur distant, ce qui permettait à un serveur MCP malveillant d'exécuter des commandes arbitraires sur la machine du client. CVSS 9,6. Première RCE complète documentée sur l'OS d'un client depuis un serveur MCP distant. Corrigé en 0.1.16.
💡 Ce qu'il faut retenir. Sur les quatre, une seule est vraiment nouvelle : l'injection de prompt. Les trois autres sont de l'hygiène d'identifiants qu'on enseigne depuis vingt ans. Le problème n'est pas que MCP soit dangereux par nature, c'est qu'on déploie des composants qui détiennent des clés de production sans leur appliquer le niveau d'exigence d'un composant de production.
Première question à te poser si tu utilises des agents : est-ce que tu sais lister tous les serveurs MCP qui tournent chez toi, et ce que chacun a le droit de toucher ? Si la réponse est non, le reste vient après.
MCP (Model Context Protocol) est le standard qui permet à un agent IA d'agir sur de vrais systèmes : lire une base, ouvrir un fichier, appeler une API. Entre l'IA et le système, il y a un petit programme intermédiaire, le serveur MCP.
Et pour agir sur un système, ce serveur a besoin des identifiants de ce système. Clés d'API, tokens, comptes de service. Tout ça se retrouve concentré au même endroit.
Les quatre façons dont ça fuite :
1️⃣ Secrets en clair dans les fichiers de conf. Pour démarrer un serveur MCP, on colle souvent une chaîne de configuration qui contient directement les identifiants. Ce fichier finit copié entre machines, ou commité dans un dépôt Git.
2️⃣ La dispersion. Chaque agent gère ses propres secrets, dupliqués entre dev, staging et prod. Personne n'a l'inventaire, donc rien n'est jamais tourné. Résultat : des identifiants valides indéfiniment.
3️⃣ Les permissions trop larges. Pendant le développement, on donne des droits généreux pour éviter les erreurs d'autorisation. Ces droits partent en production et n'en reviennent jamais.
4️⃣ L'injection de prompt. Celle-là est spécifique à l'IA. L'agent lit du contenu et agit dessus. Un attaquant peut cacher des instructions dans un document, un ticket ou une page web, et l'agent les exécute comme si elles venaient de toi.
🧱 Le cas concret. CVE-2025-6514, découverte par JFrog en juillet 2025. Le proxy mcp-remote acceptait sans validation l'URL d'authentification renvoyée par le serveur distant, ce qui permettait à un serveur MCP malveillant d'exécuter des commandes arbitraires sur la machine du client. CVSS 9,6. Première RCE complète documentée sur l'OS d'un client depuis un serveur MCP distant. Corrigé en 0.1.16.
💡 Ce qu'il faut retenir. Sur les quatre, une seule est vraiment nouvelle : l'injection de prompt. Les trois autres sont de l'hygiène d'identifiants qu'on enseigne depuis vingt ans. Le problème n'est pas que MCP soit dangereux par nature, c'est qu'on déploie des composants qui détiennent des clés de production sans leur appliquer le niveau d'exigence d'un composant de production.
Première question à te poser si tu utilises des agents : est-ce que tu sais lister tous les serveurs MCP qui tournent chez toi, et ce que chacun a le droit de toucher ? Si la réponse est non, le reste vient après.
🎯 Pourquoi les flux de threat intelligence déçoivent presque toujours
Un SOC achète un flux de renseignement sur les menaces. La promesse : moins de bruit, des investigations plus rapides, des analystes qui traitent plus d'événements sans embaucher. Six mois plus tard, l'équipe ignore la moitié des alertes du flux.
Ce n'est pas un problème de fournisseur. C'est une propriété de ce qu'on achète.
Ce qu'est vraiment un IOC
Un indicateur de compromission, c'est une empreinte laissée par un attaquant : un hash de fichier, une adresse IP, un nom de domaine. Le flux te dit « ce hash est malveillant ». Et là, l'investigation ne fait que commencer.
Savoir qu'un objet est classé malveillant ne te dit ni ce qu'il fait, ni pourquoi il a été classé ainsi, ni ce que ça implique pour ton infrastructure à toi. Sans ce contexte, l'analyste part en pivot manuel entre trois portails. Le flux a déplacé le travail, il ne l'a pas supprimé.
Le vrai problème : la pyramide de la douleur
David Bianco a formalisé ça en 2013, et ça n'a pas bougé. Il classe les indicateurs par le coût qu'ils imposent à l'attaquant quand tu les bloques :
🔹 Hash de fichier : trivial. Un bit modifié, nouveau hash.
🔹 Adresse IP : facile. On en loue d'autres pour quelques euros.
🔹 Nom de domaine : génant. Il faut en réenregistrer.
🔹 Artefacts réseau et système : pénible. Il faut modifier l'outillage.
🔹 Outils : très pénible. Il faut en redévelopper ou en racheter.
🔹 TTP, les tactiques et comportements : maximal. Il faut réapprendre à opérer.
Or un flux d'IOC vend massivement les deux premières lignes. Celles qui coûtent le moins cher à l'attaquant, donc celles qui périment le plus vite.
La conséquence en chaîne
Indicateurs périmés → faux positifs → les analystes enquêtent pour rien → la confiance dans la source s'effondre → ils commencent à ignorer ses alertes, y compris les bonnes. Le flux devient une source de bruit financée par abonnement.
Ce qu'il faut en retenir
Le volume d'indicateurs n'est pas une mesure de qualité. Les bonnes questions avant d'acheter : quelle est la durée de vie opérationnelle des indicateurs, quel contexte comportemental accompagne chaque entrée, et surtout, qu'est-ce qu'on saura faire dans trois mois qu'on ne sait pas faire aujourd'hui ? Sans réponse à la dernière, aucun outil ne comblera le manque.
Un SOC achète un flux de renseignement sur les menaces. La promesse : moins de bruit, des investigations plus rapides, des analystes qui traitent plus d'événements sans embaucher. Six mois plus tard, l'équipe ignore la moitié des alertes du flux.
Ce n'est pas un problème de fournisseur. C'est une propriété de ce qu'on achète.
Ce qu'est vraiment un IOC
Un indicateur de compromission, c'est une empreinte laissée par un attaquant : un hash de fichier, une adresse IP, un nom de domaine. Le flux te dit « ce hash est malveillant ». Et là, l'investigation ne fait que commencer.
Savoir qu'un objet est classé malveillant ne te dit ni ce qu'il fait, ni pourquoi il a été classé ainsi, ni ce que ça implique pour ton infrastructure à toi. Sans ce contexte, l'analyste part en pivot manuel entre trois portails. Le flux a déplacé le travail, il ne l'a pas supprimé.
Le vrai problème : la pyramide de la douleur
David Bianco a formalisé ça en 2013, et ça n'a pas bougé. Il classe les indicateurs par le coût qu'ils imposent à l'attaquant quand tu les bloques :
🔹 Hash de fichier : trivial. Un bit modifié, nouveau hash.
🔹 Adresse IP : facile. On en loue d'autres pour quelques euros.
🔹 Nom de domaine : génant. Il faut en réenregistrer.
🔹 Artefacts réseau et système : pénible. Il faut modifier l'outillage.
🔹 Outils : très pénible. Il faut en redévelopper ou en racheter.
🔹 TTP, les tactiques et comportements : maximal. Il faut réapprendre à opérer.
Or un flux d'IOC vend massivement les deux premières lignes. Celles qui coûtent le moins cher à l'attaquant, donc celles qui périment le plus vite.
La conséquence en chaîne
Indicateurs périmés → faux positifs → les analystes enquêtent pour rien → la confiance dans la source s'effondre → ils commencent à ignorer ses alertes, y compris les bonnes. Le flux devient une source de bruit financée par abonnement.
Ce qu'il faut en retenir
Le volume d'indicateurs n'est pas une mesure de qualité. Les bonnes questions avant d'acheter : quelle est la durée de vie opérationnelle des indicateurs, quel contexte comportemental accompagne chaque entrée, et surtout, qu'est-ce qu'on saura faire dans trois mois qu'on ne sait pas faire aujourd'hui ? Sans réponse à la dernière, aucun outil ne comblera le manque.
❤2👍1💯1
🚪 L'accès permanent : le risque qui ne déclenche jamais d'alerte
Une notion que peu de débutants connaissent, alors qu'elle explique une bonne partie des incidents actuels.
La définition. Un accès permanent (standing access), c'est un droit ouvert en continu, qu'on l'utilise ou non. Un compte de service qui garde les clés de la production. Un jeton OAuth accordé à un outil testé une fois. Un administrateur qui garde ses droits complets 365 jours par an pour deux interventions par mois.
Pourquoi c'est un problème particulier. Une vulnérabilité finit par être détectée par un scanner. Un accès permanent, lui, est parfaitement conforme. Il est enregistré, légitime, et il fonctionne exactement comme prévu. Aucun outil ne le signalera, parce qu'il n'est pas cassé.
Il attend simplement que quelqu'un d'autre mette la main dessus.
Deux cas réels.
🔹 Vercel, avril 2026. Un employé avait autorisé un outil IA sur son compte Google professionnel, puis abandonné l'essai. L'autorisation est restée. Quand l'éditeur de l'outil s'est fait compromettre, l'attaquant a rejoué le jeton et est entré chez Vercel. Aucun mot de passe cassé, MFA contourné sans effort : un jeton OAuth vaut identité authentifiée.
🔹 Salesloft Drift, août 2025. Des jetons OAuth à longue durée liés à une seule intégration de chatbot restaient valides sur les environnements Salesforce de centaines d'organisations. Pas de malware, pas de vol de mot de passe. Juste des jetons que personne n'avait bornés dans le temps.
La réponse : l'accès juste-à-temps.
Le principe inverse tient en une phrase : ne pas mieux gérer les droits permanents, mais les supprimer. Un accès est demandé quand on en a besoin, accordé pour une durée bornée, puis révoqué automatiquement. On parle de zéro privilège permanent.
Ce n'est pas une question d'outil. C'est une question de défaut : est-ce que l'accès expire tout seul, ou est-ce qu'il faut que quelqu'un pense à le retirer ? Dans le second cas, personne n'y pense jamais.
💡 Ce raisonnement s'applique aussi à ton échelle. Regarde les autorisations d'applications tierces sur ton compte Google ou Microsoft. Tu vas probablement en trouver que tu ne reconnais plus.
Une notion que peu de débutants connaissent, alors qu'elle explique une bonne partie des incidents actuels.
La définition. Un accès permanent (standing access), c'est un droit ouvert en continu, qu'on l'utilise ou non. Un compte de service qui garde les clés de la production. Un jeton OAuth accordé à un outil testé une fois. Un administrateur qui garde ses droits complets 365 jours par an pour deux interventions par mois.
Pourquoi c'est un problème particulier. Une vulnérabilité finit par être détectée par un scanner. Un accès permanent, lui, est parfaitement conforme. Il est enregistré, légitime, et il fonctionne exactement comme prévu. Aucun outil ne le signalera, parce qu'il n'est pas cassé.
Il attend simplement que quelqu'un d'autre mette la main dessus.
Deux cas réels.
🔹 Vercel, avril 2026. Un employé avait autorisé un outil IA sur son compte Google professionnel, puis abandonné l'essai. L'autorisation est restée. Quand l'éditeur de l'outil s'est fait compromettre, l'attaquant a rejoué le jeton et est entré chez Vercel. Aucun mot de passe cassé, MFA contourné sans effort : un jeton OAuth vaut identité authentifiée.
🔹 Salesloft Drift, août 2025. Des jetons OAuth à longue durée liés à une seule intégration de chatbot restaient valides sur les environnements Salesforce de centaines d'organisations. Pas de malware, pas de vol de mot de passe. Juste des jetons que personne n'avait bornés dans le temps.
La réponse : l'accès juste-à-temps.
Le principe inverse tient en une phrase : ne pas mieux gérer les droits permanents, mais les supprimer. Un accès est demandé quand on en a besoin, accordé pour une durée bornée, puis révoqué automatiquement. On parle de zéro privilège permanent.
Ce n'est pas une question d'outil. C'est une question de défaut : est-ce que l'accès expire tout seul, ou est-ce qu'il faut que quelqu'un pense à le retirer ? Dans le second cas, personne n'y pense jamais.
💡 Ce raisonnement s'applique aussi à ton échelle. Regarde les autorisations d'applications tierces sur ton compte Google ou Microsoft. Tu vas probablement en trouver que tu ne reconnais plus.
👍4❤1