Rapport type de test d’intrusion pour la fintech | Aperçu du PDF de 68 pages

Projet Meridian : exercice fictif de Fintech AG couvrant trois fonctions critiques, trois scénarios et douze constats. Tous les systèmes, participants et résultats sont inventés.

L’équipe obtient une exécution de commandes sans privilèges root sur un hôte de diagnostic exposé à Internet, accède à la CI et utilise un jeton de service pour modifier un paiement canari. La synthèse distingue cette chaîne d’attaque menée sans assistance des résultats obtenus avec assistance pour le CRM et la reprise, et identifie les contrôles de signature, de données essentielles et de copies immuables qui ont résisté.

L’architecture relie les canaux clients, les identités et les fournisseurs aux zones périmétriques, opérationnelles et d’assistance. Les paiements, les comptes numériques et la trésorerie dépendent des données centrales, de la détection et de la reprise. Les flèches représentent des dépendances logiques, et non un accès réseau sans restriction.

L’équipe envoie une sonde littérale d’injection de commandes et reçoit une réponse 403 du WAF. Une variante échappée en Unicode reçoit une réponse 200 et renvoie les sorties de id, hostname et pwd sous svc_diag sur mb-diag-01. Les deux échanges HTTP, les identifiants de requête et les heures UTC sont présentés comme des éléments de preuve synthétiques.

F-03 montre une requête PATCH utilisant l’identité svc_pay_orch obtenue, la modification acceptée du bénéficiaire sur MER-PAY-0042 et une relecture indépendante. Le service modifie le brouillon canary, tandis qu’une autorisation de signature distincte empêche le règlement.

F-06 décrit la reproduction depuis la requête WAF acceptée, via CI, jusqu’à l’API de paiement. Un dossier doit relier l’hôte, la requête, l’artefact, le principal et le paiement, avec un objectif de triage de 15 minutes. La procédure est explicitement indiquée comme n’ayant pas encore été exécutée ; une validation future n’est pas présentée comme un retest réussi.

Des vérifications de clôture sont consignées pour trois constatations : injection de commandes, révocation des sessions et nettoyage. Neuf restent ouvertes, avec des échéances pour les justificatifs d’identité, les pouvoirs relatifs aux paiements et au rétablissement, le lien avec les approbations, le cloisonnement, la détection et les contrôles associés. Il s’agit de cibles fictives pour des plateformes, et non de délais légaux de correction.

La correspondance relie les résultats évalués aux objectifs de contrôle, aux responsables désignés, aux éléments de vérification et aux limites de l’évaluation. Elle ne revendique aucune certification réglementaire.