Day 8 of #100DaysOfCyber 🔐 Answer to yesterday’s question 👇 DSL, Cable, Fibre, Wireless they’re all ISP connectivity options. Fibre wins on speed. Wireless wins on mobility. DSL & Cable are the most common at home. Your connection type determines your speed ceiling. 📡

Day #29 of #100DaysOfCyber | Veille & Outillage Aujourd'hui, pas de lab ni de nouveau concept théorique. Journée axée sur la recherche et la veille technologique pour découvrir des outils puissants afin d'enrichir ma boîte à outils de pentest. Trois sujets principaux analysés : ➖ #Mitmproxy ( mitmproxy.org/ ) : Un proxy d'interception HTTPS interactif, gratuit et open-source en ligne de commande (CLI). C'est une excellente alternative à Postman ou Burp Suite pour capturer le trafic de manière ultra légère. Il dispose aussi d'une interface web. Je vais le tester concrètement sur un prochain lab. ➖ #KittySploit Framework ( lnkd.in/ew2ggx7B ) : Un framework d'exploitation open-source écrit en Python conçu pour le Red Teaming moderne. C'est un outil modulaire qui regroupe pas mal de fonctionnalités intéressantes. ➖ #Cybersecurity-Projects ( lnkd.in/eXYujvU4 ) : Un dépôt que @_makh0u m'a partagé qui regroupe plus de 70 projets cyber, des roadmaps de certification et des ressources. #Un dev qui comprend la sécurité. #Un pentester qui comprend le code. #Cybersecurity #WebSecurity #APISecurity #RedTeam #Mitmproxy #KittySploit #Github #Veille linkedin.com/posts/mahmoudba…

Day 4 of #100daysofCyber - Continued the Pre Security (SEC0) path on TryHackMe - Unlocked the "World Wide Web" badge - Rank increased from top 35% to top 25% - 12 new rooms completed Tomorrow I'm going to see if I can get through the final 2 modules, then move to CyberSecurity 101 (SEC1).

Day 7 of #100DaysOfCyber 🔐 How does your device actually connect to the internet? 🔴 DSL (through your phone line) 🟡 Cable (through TV cable) 🟢 Fibre optic (through light pulses) 🔵 Wireless/cellular Which one are you using right now? 👇 #NetworkingBasics #CiscoNetAcad

Day #28 of #100DaysOfCyber | Identifier et manipuler les Endpoints d'une API Après avoir automatisé la collecte de requêtes avec Postman, l'étape suivante consiste à analyser et interagir avec les endpoints pour comprendre la logique du backend et trouver des failles. ➖ 1. Identifier la structure des Endpoints Même sans doc, la majorité des APIs suivent des structures standardisées (REST). On cherche d'abord à repérer trois indicateurs : ⚪ Le Versioning : Repérer les routes comme /api/v1/ ou /api/v2/. Parfois, une ancienne version (v1) moins sécurisée est toujours active sur le serveur. ⚪ La nomenclature : Comprendre comment sont désignées les ressources (ex: /users, /vehicles, /products). Les Identifiants : Repérer où et comment sont passés les IDs (dans l'URL ou directement dans le body JSON). ➖ 2. Manipuler les requêtes pour tester le backend Une fois la structure comprise, on modifie systématiquement les composants de la requête pour analyser la réaction du serveur : ⚪ Changer les méthodes HTTP : Si une route fonctionne en GET /api/profile, on teste l'envoi d'un POST, PUT ou DELETE pour voir si le backend bloque correctement les actions non autorisées. ⚪ Modifier le Content-Type : Si l'API attend du JSON (application/json), on tente de lui envoyer du XML ou des données de formulaire. Changer le format peut contourner certains filtres ou provoquer des erreurs. ⚪ Fuzzer les paramètres : Modifier le type de données (envoyer du texte à la place d'un ID numérique) ou ajouter des clés JSON inattendues pour forcer le serveur à renvoyer des messages d'erreur verbeux. L'objectif est d'observer comment le backend réagit dès qu'on sort du comportement attendu par l'interface graphique. On continue sur les prochains labs #Un dev qui comprend la sécurité. #Un pentester qui comprend le code. @_makh0u #Cybersecurity #WebSecurity #APISecurity #PortSwigger #Endpoints #RestAPI #Backend #FullStack

Day 3 of #100daysofCyber - Continued the Pre Security (SEC0) path on TryHackMe - Unlocked the Webbed badge - Rank increased from top 40% to top 35% - 2 new rooms completed Tomorrow I'm going to try and blitz through a whole load of it so that I can move onto SEC1.

Day 6 of #100DaysOfCyber 🔐 Every device on a network plays a role. Client = requests data. Server = provides it. Your phone asking for a webpage = client. The machine sending it back = server. Some devices do both at the same time. That’s the internet in two roles. #Networking

Today's Topic - Multi-Factor Authentication (MFA) Passwords can be stolen, guessed, leaked, or reused. MFA adds another layer. It asks for more than just a password: • Something you know → password/PIN • Something you have → phone/security key • Something you are → fingerprint/face Even if your password leaks, MFA can stop the attacker from getting in. Use it everywhere important. #100DaysOfCyber

Day #27 of #100DaysOfCyber | Pratique : Reverse Engineering d'API avec Postman Hier, on a vu la théorie sur le Reverse Engineering d'API lorsque la documentation est absente. Aujourd'hui, je suis passé à la pratique J'ai cherché les outils les plus simples et efficaces pour automatiser tout ça, et j'ai lancé mes tests sur crAPI (l'environnement volontairement vulnérable d'APIsec University) en utilisant Postman. Au lieu de capturer et de copier les liens un par un manuellement, j'ai configuré l'extension Postman Interceptor. C'est un outil ultra puissant qui fait office de proxy et qui permet d'automatiser complètement la phase de collecte. Le déroulement : ➖ 1. La configuration de l'environnement : J'ai d'abord créé un Workspace dédié sur mon application Postman pour bien organiser mes futures requêtes. ➖ 2. Le filtrage du trafic : J'ai démarré le proxy via l'extension du navigateur. Pour éviter d'être pollué par les requêtes de mes autres onglets (YouTube, recherches, etc.), j'ai spécifié uniquement le domaine cible de crAPI dans les filtres de l'extension. Seul le trafic qui m'intéresse est intercepté. ➖ 3. La collecte (Sniffing) : Une fois le proxy actif, j'ai simplement navigué sur l'application crAPI et manipulé toutes ses fonctionnalités (connexion, profil, boutique, etc.). En arrière-plan, Postman Interceptor a capturé chaque appel HTTP de manière transparente. ➖ 4. L'organisation : Quelques instants plus tard, je suis retourné sur Postman. Toutes les requêtes y étaient enregistrées automatiquement ! Il ne me restait plus qu'à les trier et les organiser pour reconstruire proprement la structure des endpoints du backend. Avec cette méthode, on obtient en quelques minutes une copie conforme de l'API (routes, headers, structures JSON). C'est la base parfaite pour commencer à chercher des vulnérabilités logiques ou des IDOR.. #Un dev qui comprend la sécurité. #Un pentester qui comprend le code. @_makh0u #Cybersecurity #WebSecurity #APISecurity #Postman #APIsecUniversity #crAPI #ReverseEngineering #Backend #FullStack linkedin.com/posts/mahmoudba…

Day 5 of #100DaysOfCyber 🔐 Bandwidth ≠ Throughput. Bandwidth = max capacity of the network. Throughput = what actually gets delivered in real time. Your internet can be “fast” on paper but slow in reality. That’s throughput losing to latency. Which matters more? 👇

Started a #100daysofCyber challenge yesterday. Going to breeze through the TryHackMe Pre Security pathway, and then get a feel for where I should go from there. Today was day 2 - unlocked the networking nerd badge.

Day #26 of #100DaysOfCyber | Sécurité Dev : Le Reverse Engineering d’API Hier, on a vu comment une documentation d'API oubliée en prod pouvait détruire la sécurité d'un site. Mais en situation réelle, la doc est souvent désactivée. Alors, comment fait un pentester pour attaquer une API s'il n'a pas le mode d'emploi ? C'est là qu'intervient le #Reverse #Engineering d'API. Le concept est simple : on va observer passivement comment l'application frontend discute avec son backend pour deviner et reconstruire la structure de l'API, ses routes et ses paramètres cachés. 3 étapes pour Reverse Engineering d'API : ➖ 1. L'analyse du trafic : On utilise un proxy comme Burp Suite pour intercepter toutes les requêtes HTTP/HTTPS générées lorsqu'on clique sur le site. On note la structure des URLs (ex: /api/v2/products/10) et le format des données (JSON, XML). ➖ 2. Deviner la structure : Les développeurs suivent souvent des conventions de nommage (REST). Si on voit une route GET /api/v1/users/42, on peut légitimement tester l'existence de : - GET /api/v1/users (pour lister) - POST /api/v1/users (pour créer) - DELETE /api/v1/users/42 (pour supprimer) ➖ 3. Le Fuzzing de paramètres : Même sans doc, on peut deviner les variables acceptées par le backend. Si une mise à jour de profil envoie {"name": "Mahmoud"}, on va tenter d'injecter des clés cachées comme {"role": "admin"} ou {"is_premium": true} (le Mass Assignment) pour voir comment le serveur réagit. Pourquoi c'est crucial pour un Dev ? Beaucoup de devs pensent encore que si une route d'API n'est pas écrite sur le site ou dans une doc publique, personne ne la trouvera. Un attaquant motivé mettra quelques mn surtout avec les outils à cartographier vos endpoints backend juste en regardant les requêtes réseau de son navigateur. C'est pourquoi il faut un contrôle d'accès strict sur chaque route, documentée ou non #Un dev qui comprend la sécurité. #Un pentester qui comprend le code. @_makh0u #Cybersecurity #WebSecurity #APISecurity #ReverseEngineering #PortSwigger #Backend #FullStack

Day 4 of #100DaysOfCyber Answer: 🟢 Fibre optic cable Fibre converts electrical signals into light pulses light travels faster and further with less signal loss than copper or Wi-Fi. That’s why enterprises and large networks use it over copper wire. #NetworkingBasics

Day #25 of #100DaysOfCyber | Lab : Exploiter une API grâce à sa documentation cachée Hier, @Elkha_D disait en commentaire de mon post qu'il fallait toujours protéger ou désactiver les routes de documentation en prod. Aujourd'hui, j'en ai eu la preuve concrète en validant le lab de PortSwigger. #L'objectif : supprimer l'utilisateur carlos. #Problème : aucune option dans l'interface graphique. J'ai donc dû passer en mode Reconnaissance d'API pour comprendre comment le backend fonctionne. #Le déroulement de l'attaque : ➖ 1. J'ai lancé Burp Suite et analysé le trafic en manipulant le site, je suis tombé sur une route intéressante : /api/. ➖ 2. J'ai envoyé la requête dans le Repeater pour tester le comportement de l'API. J'ai d'abord tenté /api/users pour lister tout le monde : erreur, le chemin n'existe pas. ➖ 3. En testant /api/user (sans ID), le backend me renvoie une erreur intéressante : "Malformed URL: expecting an identifier" OK, il attend un username précis. Je teste /api/user/mahmoud : "User not found". L'API fonctionne, mais je n'ai pas les bons noms. ➖ 4. J'ai continué à modifier mes requêtes petit à petit. En testant simplement un GET sur /api, j'ai obtenu une redirection 302 vers /api/. J'ai copié ce lien dans mon navigateur : je suis tombé sur la documentation 👇