# isMalicious — Full Blog Content > This file contains the complete text of isMalicious blog posts for AI assistant indexing. > Source: https://ismalicious.com/llms.txt --- # PHP2Shell IOCs from Amazon and Hunt.io, checked against isMalicious URL: https://ismalicious.com/posts/php2shell-iocs-amazon-hunt-io-checked Date: 2026-10-26T08:00:00.000Z Excerpt: 18 published PHP2Shell indicators, looked up on 23 October 2026: 15 listed, 5 provably before the report that named them, for malware or abuse, and 3 missed. On 21 October 2026, Amazon published six IP addresses that had sent PHP2Shell exploit attempts ([CVE-2026-109618](/cve/CVE-2026-109618) and [CVE-2026-109619](/cve/CVE-2026-109619)) to its MadPot honeypots. On 22 October, Hunt.io published the scanners, payload host, botnet servers and staging servers it had tied to the same activity. On 23 October we opened the isMalicious page of 18 of those indicators and wrote down what each one showed that day: the level, the number of threat sources, "In our dataset since" and "Record updated". The tables below are that snapshot. They do not move when the pages do. The short version: - 15 of the 18 were listed on 23 October: 8 High, 5 Medium, 2 Low. 3 were not listed. - 5 were provably listed before the report that named them. Four belong to the botnet Hunt.io describes, and they were on malware, botnet and abuse lists. The fifth, 104.219.251[.]31, was on a VoIP blacklist and an abuse list, neither related to PHP2Shell. None of the five was listed for PHP2Shell. - Amazon's six addresses were all listed, two High and four Medium, but none can be shown to have been listed before Amazon's report. Amazon says its list includes shared anonymisation infrastructure. - We missed three indicators, and the mass-exploitation server Hunt.io found reached our data only the day after its report. ## What the two reports published [Amazon's post](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) of 21 October describes a PHP2Shell attempt logged in MadPot on 17 October, four days before public disclosure, from an address on a commercial anonymisation network, then more attempts on 21 October from other anonymised infrastructure. It lists the six addresses with the date each was seen, and says they include shared anonymisation infrastructure and are not exclusive to this activity. Its advice on them: "Organizations should investigate any observations involving these addresses as opposed to blocking." [Hunt.io's report](https://hunt.io/blog/php2shell-cve-2026-109618-109619-open-directories) of 22 October traces the php2shell scanning it saw to a Mirai-style IoT botnet, active since at least May 2026, that added php2shell to its spreading kit. Its indicator table names the scanner network, a second scanner, a payload host, three botnet binary hosts and three wildcard C2 domains. It also lists attacker staging servers found in open directories, among them a mass-exploitation server that ran a tool against up to 123 servers without logging a shell. At the time of writing, Hunt.io had seen attempts and staged tooling but no confirmed compromise. From these we took Amazon's six addresses and twelve of Hunt.io's indicators: the network indicators of its table, with the scanner it names, 45.198.224[.]169, standing in for the scanner /24; two of its staging hosts, 206.188.197[.]105 and 104.219.251[.]31; and maste.mangsud[.]org, the host a webshell staged on 104.219.251[.]31 downloads from. ## How to read the dates Each isMalicious indicator page carries three dates, in UTC: - "In our dataset since" is the day the record entered our dataset, not the day anyone first reported the indicator. The dataset was reloaded on 28 August 2026, so 2026-08-28 means "on that day or earlier". - "Record updated" is the last time the record was rewritten. A new source rewrites it, and so do a rescore and a changed field. - "Last seen on a list" is the last day a list we read named the indicator. A list naming it again moves only this date. So a record whose "Record updated" date falls before a report already held, before that report, every source it shows. That is the only rule behind each "Yes" in the tables. When a record was rewritten after the report, the page cannot say whether its sources were there before it, and the row reads "Can't show". The page does not say which list created the record, or when each list added it. ## The indicators, as shown on 23 October 2026 Levels and source counts are the ones the pages showed that day. "Threat sources" counts publishers, so two lists from the same publisher count once; VPN, datacenter and other context lists are shown apart on the pages and not counted. † marks 2026-08-28, the reload date: read it as "on that day or earlier". Each indicator links to its isMalicious page, which shows today's values, not these. ### Amazon MadPot, published 21 October | Indicator | Seen by Amazon | Level | Threat sources | In our dataset since | Record updated | Listed before the report? | | ---------------------------------------- | ----------------------------- | ------ | -------------- | -------------------- | -------------- | ------------------------- | | [103.216.220[.]92](/ip/103.216.220.92) | 2026-10-17, before disclosure | Medium | 3 | 2026-08-28 † | 2026-10-23 | Can't show | | [31.223.184[.]166](/ip/31.223.184.166) | 2026-10-21 | Medium | 7 | 2026-09-17 | 2026-10-23 | Can't show | | [37.19.200[.]5](/ip/37.19.200.5) | 2026-10-21 | High | 8 | 2026-08-28 † | 2026-10-23 | Can't show | | [134.209.159[.]64](/ip/134.209.159.64) | 2026-10-21 | High | 9 | 2026-08-28 † | 2026-10-23 | Can't show | | [103.114.163[.]188](/ip/103.114.163.188) | 2026-10-21 | Medium | 4 | 2026-08-28 † | 2026-10-23 | Can't show | | [95.217.98[.]37](/ip/95.217.98.37) | 2026-10-21 | Medium | 4 | 2026-10-22 | 2026-10-23 | No, it entered after | ### Hunt.io, published 22 October | Indicator | Role in Hunt.io's report | Level | Threat sources | In our dataset since | Record updated | Listed before the report? | | -------------------------------------------------------------------- | ---------------------------------------- | ---------- | -------------- | -------------------- | -------------- | ----------------------------------------- | | [89.32.41[.]16](/ip/89.32.41.16) | Botnet binary host | High | 16 | 2026-08-28 † | 2026-09-16 | Yes | | [89.32.41[.]50](/ip/89.32.41.50) | Botnet binary host | High | 12 | 2026-07-08 | 2026-10-21 | Yes | | [45.198.224[.]88](/ip/45.198.224.88) | Botnet binary host | High | 18 | 2026-08-28 † | 2026-10-05 | Yes | | [botlesscucks[.]st](/domain/botlesscucks.st) | Botnet C2 domain (wildcard) | High | 8 | 2026-08-28 † | 2026-10-21 | Yes | | [104.219.251[.]31](/ip/104.219.251.31) | Public PoC copy and staged PHP webshells | Low | 2 | 2026-09-12 | 2026-09-12 | Yes, for VoIP and other abuse (unrelated) | | [45.198.224[.]169](/ip/45.198.224.169) | php2shell scanner | High | 32 | 2026-09-19 | 2026-10-23 | Can't show | | [85.11.167[.]243](/ip/85.11.167.243) | Second scanner | High | 26 | 2026-08-28 † | 2026-10-23 | Can't show | | [92.118.112[.]100](/ip/92.118.112.100) | Payload host | Medium | 2 | 2026-09-12 | 2026-10-23 | Can't show | | [206.188.197[.]105](/ip/206.188.197.105) | Mass-exploitation server | Low | 1 | 2026-10-23 | 2026-10-23 | No, it entered after | | [godofthunder[.]st](/domain/godofthunder.st) | Botnet C2 domain (wildcard) | Not listed | — | — | — | No | | [gettingheadfromduckysmom[.]st](/domain/gettingheadfromduckysmom.st) | Botnet C2 domain (wildcard) | Not listed | — | — | — | No | | [maste.mangsud[.]org](/domain/maste.mangsud.org) | Host a staged webshell downloads from | Not listed | — | — | — | No | ## What "listed before" means here Four of the five early listings are the botnet's own infrastructure: three binary hosts and one C2 domain. They sat on lists such as Spamhaus DROP, URLhaus, HaGeZi TIF and the Emerging Threats firewall block list weeks before Hunt.io's report. 89.32.41[.]16 held its 16 threat sources by 16 September, and 45.198.224[.]88 its 18 by 5 October, before PHP shipped the fix on 21 October. Hunt.io says the botnet has been running since at least May, so these are listings of a long-running botnet that later added php2shell to its kit. They are not a PHP2Shell detection, and nothing in our data ties them to either CVE. Amazon's six addresses tell a different story. They were all listed on 23 October, on lists such as ThreatHive, Bitwire, FireHOL and FFraud, but every record had been rewritten that day, so none can be dated before Amazon's report. One list, the Rösti MISP OSINT Feed, carried all six. It was also the only list carrying 206.188.197[.]105 when that address reached our data, the day after Hunt.io named it. It appears to pick up indicators from published reports, so its listing of Amazon's addresses may simply repeat Amazon's own list. Five of the six pages also show VPN or datacenter lists. Those sit under "Infrastructure and context", apart from the threat listings, and are not counted as detections, which is consistent with Amazon's warning about shared anonymisation infrastructure. ## What changed by 26 October We opened the same 18 pages again on 26 October 2026. - All six Amazon records were rewritten on 24 October. Five now show more threat sources, and two moved from Medium to High: 31.223.184[.]166 and 95.217.98[.]37. Lists that add an address after a vendor publishes it tell you little beyond the vendor's own report. - The payload host 92.118.112[.]100 went from Medium on 2 threat sources to High on 6. The two scanners went from 32 to 33 sources (45.198.224[.]169) and from 26 to 29 (85.11.167[.]243). - Two of the three botnet C2 domains entered our dataset on 25 October, at Low, on two lists each. maste.mangsud[.]org still has no record. - The four early botnet records and 104.219.251[.]31 keep their "Record updated" dates. One count fell: 45.198.224[.]88 showed 18 threat sources on 23 October and 17 on 26 October, under the same 2026-10-05 date. A count can fall without a rewrite. A new listing always rewrites the record, which is what the rule above relies on. ## What we missed - Two of the three botnet C2 domains, and maste.mangsud[.]org, were not in our data on 23 October, the day after Hunt.io published them. The two domains arrived on 25 October, at Low; maste.mangsud[.]org has no record yet. - The mass-exploitation server, 206.188.197[.]105, entered our data the day after the report, through one OSINT feed, at Low. On 26 October it was still Low on that one source. - The payload host, 92.118.112[.]100, was Medium on two sources on 23 October and reached High only after the report. - None of the 18 is tied to PHP2Shell in our data. On 26 October, the "Observed activity" panel of both CVE pages showed no indicator tagged with either CVE over the previous seven days. What we had was infrastructure on malware, botnet and abuse lists, not knowledge of the exploit. - We checked 2 of the 13 staging and lab hosts Hunt.io lists. The other 11 are not in this post, nor is the research checker it lists under "Watch". Its user agents, scanner fingerprint and request pattern are detection signatures, not reputation indicators, and we did not check them. ## Using these indicators Patch first: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both CVEs, and the [CVE-2026-109618](/cve/CVE-2026-109618) and [CVE-2026-109619](/cve/CVE-2026-109619) pages list the fixed versions per branch and the distribution builds. Treat Amazon's six addresses the way Amazon does: as grounds to investigate a hit, not as a block list. Hunt.io marks its scanner network, second scanner, payload host, binary hosts and C2 domains for blocking, and notes that none of them is evidence that a php2shell attack succeeded. ## Get the feed in your own tool The indicators on these pages also ship over STIX/TAXII. You can [start a 7-day trial of the STIX/TAXII feed](/data/stix-taxii): it is self-serve for the owner or an admin of a Free organization with a work address, with no card, though some requests wait for a manual check. The trial feed is licence-filtered: an indicator goes out only when a list with an explicit permissive licence carries it, so it may not include every indicator above. ## Method Lookups: the public pages `ismalicious.com/ip/
` and `ismalicious.com/domain/`, opened in a browser without an account on 23 October 2026 and again on 26 October 2026. Indicators, roles and dates: Amazon's post of 21 October and Hunt.io's report of 22 October, both re-read on 26 October. Dates are UTC. Indicators are defanged in the text ([.] for a dot); each link opens the indicator's isMalicious page, which shows its current values rather than the 23 October snapshot. --- # isMalicious + Tenzir : le renseignement dans vos pipelines URL: https://ismalicious.com/fr/posts/ismalicious-tenzir-renseignement-pipelines Date: 2026-10-23T00:45:00.000Z Excerpt: Connectez les flux de domaines et d’IP isMalicious à Tenzir via STIX/TAXII pour enrichir les événements DNS et réseau dans vos pipelines. Intégrez le renseignement sur les menaces à vos pipelines de données de sécurité avec [isMalicious](https://ismalicious.com/fr) et Tenzir. Chargez des indicateurs de domaines et d’IP via STIX/TAXII, construisez une table de correspondance locale dans Tenzir et enrichissez les événements DNS et réseau avant leur arrivée dans votre SIEM ou votre lac de données. Conservez les références des sources, les scores de risque et les métadonnées de validité avec chaque correspondance. Une recherche API facultative apporte davantage de contexte lorsqu’une investigation le nécessite. ![Le renseignement isMalicious sur les domaines et les IP alimente une table de correspondance locale Tenzir via STIX/TAXII 2.1. Les événements DNS et réseau entrent dans le pipeline Tenzir, sont enrichis localement, puis rejoignent un SIEM ou un lac de données. Les références des sources, les scores de risque et les métadonnées de validité accompagnent les correspondances. Dans le parcours facultatif d’investigation, une demande d’analyste entre dans un pipeline Tenzir à la demande, qui interroge l’API isMalicious. Le rapport complet revient dans Tenzir sous forme d’événement et rejoint le SIEM ou le lac de données.](/images/tenzir/architecture-overview.png) Les indicateurs sans correspondance restent inconnus. [Découvrir l’intégration](https://tenzir.com/integrations/ismalicious/). [Créer votre compte](/fr/auth/register). [Lire l’annonce commune](https://tenzir.com/blog/threat-intelligence-on-open-standards-with-ismalicious/). [Connecter les flux](/fr/api-docs#taxii). Utilisez vos propres identifiants [isMalicious](https://ismalicious.com/fr). L’accès aux flux TAXII nécessite un abonnement payant adapté ; la création d’un compte gratuit ne suffit pas à activer les flux. Les récupérations de collections TAXII sont soumises à la limite de requêtes par minute de votre offre, mais ne consomment pas le quota mensuel de vérifications de réputation. Les recherches API individuelles facultatives consomment ce quota mensuel. [isMalicious](https://ismalicious.com/fr) est développé par son fondateur et développeur [Jean-Vincent QUILICHINI](https://www.linkedin.com/in/jeanvincentquilichini/). Retrouvez-le aussi sur X sous le nom [@hexablob](https://x.com/hexablob). Consultez [Tenzir sur notre page partenaires](/fr/resources/partners#tenzir) et la [présentation de la solution](https://tenzir.com/resources/solution-briefs/open-standard-threat-intelligence-for-security-data-pipelines-with-ismalicious/). --- # isMalicious + Tenzir: Threat Intel in Your Pipeline URL: https://ismalicious.com/posts/ismalicious-tenzir-threat-intelligence-pipeline Date: 2026-10-23T00:45:00.000Z Excerpt: Connect isMalicious domain and IP feeds to Tenzir over STIX/TAXII for local DNS and network enrichment, with optional API lookups for investigations. Bring threat intelligence into your security data pipeline with [isMalicious](https://ismalicious.com) and Tenzir. Load domain and IP indicators over STIX/TAXII, build a local lookup table in Tenzir, and enrich DNS and network events on their way to your SIEM or data lake. Keep source references, risk scores and validity metadata with the matches. Use an optional API lookup when an investigation needs more context. ![isMalicious domain and IP intelligence flows over STIX/TAXII 2.1 into a Tenzir local lookup table. DNS and network events enter the Tenzir pipeline, are enriched locally, and continue to a SIEM or data lake. Source references, risk scores and validity metadata accompany matches. In the optional investigation path, an analyst request enters a Tenzir on-demand pipeline, which queries the isMalicious API. The full report returns to Tenzir as an event and continues to the SIEM or data lake.](/images/tenzir/architecture-overview.png) Unmatched indicators remain unknown. [Explore the integration](https://tenzir.com/integrations/ismalicious/). [Create your account](/auth/register). [Read the joint announcement](https://tenzir.com/blog/threat-intelligence-on-open-standards-with-ismalicious/). [Connect the feeds](/api-docs#taxii). Use your own [isMalicious](https://ismalicious.com) credentials. TAXII feed access requires an appropriate paid subscription; creating a free account alone does not enable the feeds. TAXII collection pulls are subject to your plan's per-minute burst limit but do not consume the monthly reputation-check quota. Optional individual API lookups consume that monthly quota. [isMalicious](https://ismalicious.com) is built by founder and developer [Jean-Vincent QUILICHINI](https://www.linkedin.com/in/jeanvincentquilichini/). You can also find him on X as [@hexablob](https://x.com/hexablob). See [Tenzir on our partners page](/resources/partners#tenzir) and the [solution brief](https://tenzir.com/resources/solution-briefs/open-standard-threat-intelligence-for-security-data-pipelines-with-ismalicious/). --- # VEX: When Should You Accept not_affected? URL: https://ismalicious.com/posts/vex-cve-not-affected-review Date: 2026-10-19T07:00:00.000Z Excerpt: Check the product, version, justification, and evidence in a VEX advisory before closing a CVE alert or postponing a patch. A VEX `not_affected` status asserts that a vulnerability does not affect the products identified in the advisory. Before closing the CVE alert, verify that the deployed product falls within that scope and that the justification describes your situation. Ask whether this version of the advisory explains why this instance of your product is not affected. Merely establishing that the supplier published a VEX document is insufficient. Keeping the question specific prevents a narrow statement from becoming a permanent exception across an entire software catalog. ## Start with the product, then examine the status Record the product, version, distribution method, and deployed artifact. A commercial name is not always enough to distinguish a hosted service, an appliance, and a locally built container image. Compare those details with the available SBOM and actual inventory. If the SBOM describes another build, fix the mapping first. Sound technical analysis applied to the wrong product can still produce an incorrect closure. For each decision, preserve the advisory received, its source, author, and date. A link to a page that will change may not let you reconstruct what was originally stated. Also retain the document's version number or identifier when available. The [CISA minimum requirements for VEX](https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf) distinguish affected, not affected, fixed, and under investigation statuses. They call for a justification or impact statement for `not_affected`. This framework describes the information exchanged; the procedure below concerns its technical verification in your environment. ## Turn the justification into a testable question A justification becomes useful when the team knows what evidence to request. “The component is absent” calls for examining the artifact. “The vulnerable code is not used” calls for an analysis of execution paths. Those assertions cannot be verified with the same document. | Stated reason | Evidence to seek in the case | Trigger for review | | ------------------------------------------ | ---------------------------------------------------------------- | -------------------------------------- | | Component absent | Inventory of the relevant artifact and the identification method | New image or dependency | | Vulnerable code absent | Build configuration, patch, or binary analysis | Build changes | | Code unreachable through the product's use | Analysis of calls and possible inputs | New functionality or configuration | | Built-in protection prevents exploitation | Description and verification of the mechanism | Mechanism changes or a new attack path | This table proposes a review method. It does not replace the exact values in the format your supplier uses. Validate the fields and vocabularies before ingesting them. Do not substitute an operational preference for missing evidence. “The patch is difficult to deploy” explains a scheduling problem. It does not establish that the vulnerability is inapplicable. ## A fictional example: the dependency is present, the function is absent Imagine an internal application called **Atelier**, distributed in two variants. The server variant includes a library with an optional module affected by a CVE. The minimal variant uses a build that excludes the module. This example is fictional and does not describe a real vulnerability. The supplier publishes a `not_affected` advisory for the minimal variant. A dependency scanner still recognizes the library and flags the CVE. Both results can coexist: one identifies a component; the other analyzes its contents within a particular product. The analyst checks the installed artifact and confirms that it is the minimal variant covered by the advisory. They retain the build reference and evidence that the module was excluded. The closure records those details and the CVE concerned. It does not remove every alert associated with that library. If the environment uses the server variant, the advisory does not answer the question. If the installed variant remains unknown, the case still needs investigation. Similar version numbers should not be sufficient grounds for applying the exception. ## Respect the differences between formats OpenVEX uses `not_affected` and justifications such as `vulnerable_code_not_present`. Its [specification](https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md) connects statements to identified products and vulnerabilities. It also distinguishes protection built into a product from an assumption about its environment. This matters when a team cites its firewall as the reason a product is not exposed. An external, changeable control needs a local risk assessment and follow-up. It should not automatically become a supplier statement that the product is inherently unaffected. CycloneDX has its own analysis model, including fields such as `state`, `justification`, and `response`. Its [vulnerability exploitability guide](https://cyclonedx.org/use-cases/vulnerability-exploitability/) describes their roles. Converting between formats must preserve meaning without assuming that every label has a direct equivalent. Test the connector with a recognized advisory, an incomplete advisory, and a value it does not understand. In the last case, the tool should leave the decision visible to an analyst. Silently dropping an unknown field can turn a limited condition into a blanket exemption. ## Put boundaries on the closure decision Associate the closure with the CVE, product, version or artifact, and advisory version. Add the person or team that accepted the reasoning and the date of the check. Then define what should reopen the case: a new product version, a configuration change, a revised advisory, or new information contradicting the justification. A status accepted today does not automatically apply to the next update. Retain the scanner finding and its explanation instead of deleting it. During a technical audit or a handover, the record should show why a known alert did not require the same action as another. This history also helps identify exceptions that no longer apply. The [SBOM guide for security teams](/posts/sbom-supply-chain-security-basics) helps establish the initial inventory. The [supply chain CVE response process](/posts/supply-chain-cve-sbom-vulnerability-response) then places the advisory within dependency and patch management. For your next alert accompanied by VEX, request four concrete items: the deployed artifact, applicable advisory, evidence supporting the justification, and condition for review. If one is missing, assign an owner to obtain it and keep the limitation explicit. Close the case once the conclusion has been established for the product concerned. --- # VEX : quand accepter un statut not_affected ? URL: https://ismalicious.com/fr/posts/vex-cve-statut-not-affected Date: 2026-10-19T07:00:00.000Z Excerpt: Vérifiez le produit, la version, la justification et les preuves d’un avis VEX avant de clôturer une alerte CVE ou de suspendre un correctif. Un statut VEX `not_affected` affirme qu’une vulnérabilité ne touche pas les produits désignés par l’avis. Avant de fermer l’alerte CVE, vérifiez que le produit déployé correspond bien à ce périmètre et que la justification décrit votre situation. La question n’est pas seulement « le fournisseur a-t-il publié un VEX ? ». Elle devient : « cet avis, dans cette version, explique-t-il pourquoi cette instance de notre produit n’est pas affectée ? ». Cette formulation évite de transformer une déclaration précise en exception permanente pour tout un catalogue logiciel. ## Commencer par le produit, pas par le statut Relevez le produit, sa version, son mode de distribution et son artefact déployé. Un nom commercial ne suffit pas toujours à distinguer un service hébergé, une appliance et une image de conteneur construite localement. Rapprochez ces éléments du SBOM disponible et de l’inventaire réel. Si le SBOM décrit une autre construction, corrigez d’abord le rapprochement. Une analyse technique solide appliquée au mauvais produit peut aboutir à une clôture incorrecte. Pour chaque décision, conservez l’avis reçu, sa provenance, son auteur et sa date. Un lien vers une page qui changera ne permet pas toujours de reconstruire ce qui avait été annoncé. Gardez aussi le numéro ou identifiant de version du document lorsqu’il existe. Les [exigences minimales VEX publiées par la CISA](https://www.cisa.gov/sites/default/files/2023-04/minimum-requirements-for-vex-508c.pdf) distinguent notamment les statuts affecté, non affecté, corrigé et en cours d’investigation. Elles prévoient une justification ou une explication d’impact pour `not_affected`. Ce cadre décrit l’information échangée ; la procédure ci-dessous porte sur sa vérification technique dans votre environnement. ## Traduire la justification en question vérifiable Une justification devient utile lorsque l’équipe sait quelle preuve demander. « Le composant est absent » invite à examiner l’artefact. « Le code vulnérable n’est pas utilisé » demande une analyse des chemins d’exécution. Ces deux affirmations ne se vérifient pas avec le même document. | Motif annoncé | Pièce à chercher dans le dossier | Déclencheur de réexamen | | -------------------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------- | | Composant absent | Inventaire de l’artefact concerné et méthode d’identification | Nouvelle image ou nouvelle dépendance | | Code vulnérable absent | Configuration de compilation, correctif ou analyse du binaire | Changement de construction | | Code non accessible dans l’usage du produit | Analyse des appels et des entrées possibles | Nouvelle fonctionnalité ou configuration | | Protection intégrée empêchant l’exploitation | Description et vérification du mécanisme | Modification du mécanisme ou nouvelle voie d’attaque | Ce tableau propose une méthode de revue. Il ne remplace pas les valeurs exactes du format utilisé par votre fournisseur. Les champs et les vocabulaires doivent être validés avant leur ingestion. Ne remplacez pas une preuve manquante par une préférence opérationnelle. « Le correctif est difficile à déployer » explique un problème de planification. Cela ne démontre pas que la vulnérabilité ne s’applique pas. ## Un exemple fictif : la dépendance est présente, la fonction absente Imaginons une application interne appelée **Atelier**, distribuée en deux variantes. La variante serveur inclut une bibliothèque dont un module optionnel est concerné par une CVE. La variante minimale utilise une construction qui exclut ce module. Cet exemple est fictif et ne décrit aucune vulnérabilité réelle. Le fournisseur publie un avis `not_affected` pour la variante minimale. Le scanner de dépendances continue à reconnaître la bibliothèque et signale la CVE. Les deux résultats peuvent coexister : l’un identifie un composant, l’autre apporte une analyse de son contenu dans un produit précis. L’analyste vérifie l’artefact installé et constate qu’il s’agit bien de la variante minimale couverte par l’avis. Il conserve la référence de construction et la preuve d’exclusion du module. La clôture mentionne ces éléments ainsi que la CVE concernée. Elle ne retire pas toutes les alertes liées à cette bibliothèque. Si l’environnement utilise la variante serveur, l’avis ne répond pas au problème. Si la variante installée reste inconnue, le dossier reste à instruire. La ressemblance des numéros de version ne doit pas suffire à appliquer l’exception. ## Respecter les différences entre formats OpenVEX emploie notamment `not_affected` et des justifications telles que `vulnerable_code_not_present`. Sa [spécification](https://github.com/openvex/spec/blob/main/OPENVEX-SPEC.md) relie les déclarations à des produits et à des vulnérabilités identifiés. Elle distingue également une protection intégrée au produit d’une simple hypothèse sur son environnement. Cela compte lorsqu’une équipe invoque son pare-feu pour expliquer une absence d’exposition. Une mesure externe, modifiable, mérite une analyse de risque et un suivi local. Elle ne doit pas être transformée automatiquement en déclaration fournisseur affirmant que le produit est intrinsèquement non affecté. CycloneDX dispose de son propre modèle d’analyse, avec des champs comme `state`, `justification` et `response`. Son [guide de l’exploitabilité des vulnérabilités](https://cyclonedx.org/use-cases/vulnerability-exploitability/) décrit leurs rôles. Une conversion entre formats doit préserver le sens, sans supposer que tous les libellés se correspondent un pour un. Faites tester au connecteur un avis reconnu, un avis incomplet et une valeur qu’il ne comprend pas. Dans ce dernier cas, l’outil doit laisser la décision visible à l’analyste. Un champ inconnu supprimé silencieusement peut transformer une condition limitée en exemption générale. ## Mettre une borne à la décision de clôture Associez la clôture à la CVE, au produit, à sa version ou son artefact et à la version de l’avis. Ajoutez la personne ou l’équipe qui a accepté le raisonnement et la date du contrôle. Définissez ensuite les événements de réouverture : nouvelle version du produit, changement de configuration, avis révisé ou nouvelle information qui contredit la justification. Un statut accepté aujourd’hui n’autorise pas automatiquement la prochaine mise à jour. Conservez le finding du scanner et son explication au lieu de l’effacer. Lors d’un audit technique ou d’un changement de responsable, le dossier doit montrer pourquoi une alerte connue n’exigeait pas la même action qu’une autre. Cette traçabilité sert aussi à repérer les exceptions qui ne sont plus applicables. Le [guide SBOM pour les équipes sécurité](/fr/posts/sbom-securite-chaine-approvisionnement-equipes-securite) aide à établir l’inventaire de départ. Le [processus de réponse aux CVE de la chaîne d’approvisionnement](/fr/posts/reponse-cve-chaine-approvisionnement-sbom-vulnerabilites) replace ensuite l’avis dans le suivi des dépendances et des correctifs. Sur votre prochaine alerte accompagnée d’un VEX, demandez quatre pièces concrètes : l’artefact déployé, l’avis applicable, la preuve de sa justification et la condition de réexamen. Si l’une manque, attribuez la recherche à un responsable et gardez la limite explicite. Vous pourrez fermer le dossier lorsque la conclusion sera démontrée pour le produit concerné. --- # Certificat révoqué : lire OCSP et CRL sans confusion URL: https://ismalicious.com/fr/posts/certificat-revoque-ocsp-crl-reputation Date: 2026-10-18T07:00:00.000Z Excerpt: Distinguez révocation, expiration et réputation d’un domaine. Vérifiez le certificat exact, la fraîcheur du statut et le résultat côté client. Un certificat TLS révoqué doit être traité comme un problème de confiance sur ce certificat. Il ne permet pas, à lui seul, de conclure que le domaine est malveillant. Inversement, un statut de révocation favorable ne garantit pas qu’un site soit honnête. Pour enquêter, séparez trois dossiers : le certificat présenté, la réponse de révocation utilisée et la réputation de l’activité observée. Cette séparation évite de remplacer un diagnostic précis par une étiquette ambiguë telle que « SSL dangereux ». ## Identifier le certificat réellement présenté Relevez le nom demandé, le point de terminaison contacté, l’heure de collecte et le client utilisé. Conservez le certificat présenté et sa chaîne si votre outil les fournit. Une vérification faite depuis un autre réseau ou à une autre heure peut recevoir un certificat différent. Le numéro de série doit être interprété avec l’identité de l’émetteur. Pour votre dossier, ajoutez l’empreinte SHA-256 du certificat. Ne l’assimilez pas à l’empreinte de sa clé publique : ce sont deux objets distincts, utiles à des rapprochements différents. Si vous disposez déjà d’une copie PEM nommée `certificat.pem`, cette commande lit ses informations locales : ```sh openssl x509 -in certificat.pem -noout -subject -issuer -serial -dates -sha256 -fingerprint ``` Une seconde lecture affiche les noms et les indications de services de statut quand ces extensions sont présentes : ```sh openssl x509 -in certificat.pem -noout -ext subjectAltName,authorityInfoAccess,crlDistributionPoints ``` Ces options sont documentées par [OpenSSL pour la commande x509](https://docs.openssl.org/3.3/man1/openssl-x509/). Elles inspectent le certificat enregistré. Elles ne contactent pas le site et ne réalisent pas une validation complète de sa chaîne ou de sa révocation. Conservez la version de l’outil et la sortie avec la pièce collectée. Si un collègue obtient un résultat différent, vous pourrez d’abord vérifier que vous examinez le même certificat. ## Distinguer les résultats OCSP OCSP prévoit les statuts `good`, `revoked` et `unknown`. `good` n’est pas une validation complète du certificat ; `revoked` indique un certificat à rejeter selon ce statut ; `unknown` signifie que le répondeur ne peut pas déterminer son état. Une erreur de connexion n’est aucun de ces trois résultats. La [RFC 6960](https://www.rfc-editor.org/rfc/rfc6960.html) définit ces distinctions et les vérifications des réponses. Dans vos journaux, évitez un seul champ booléen « OCSP OK ». Conservez plutôt le résultat reçu, l’identité du répondeur, les dates utiles, la validation de sa signature et toute erreur de transport. Cela permet de distinguer une réponse exploitable d’un texte affiché par un outil après une vérification incomplète. Une réponse transmise avec la connexion TLS, souvent appelée OCSP stapling, doit elle aussi être vérifiée. Le fait qu’elle soit disponible ne suffit pas : il faut qu’elle corresponde au certificat concerné et que le client accepte son authenticité et sa fraîcheur. L’expiration reste un contrôle séparé. Un certificat peut dépasser sa période de validité sans être présenté comme révoqué. Écrire « non révoqué donc valide » mélange ces deux conditions et peut masquer l’origine réelle de l’échec. ## Lire une CRL dans son périmètre Une liste de révocation, ou CRL, est signée et publiée pour un périmètre donné. L’absence d’un numéro de série n’a de sens qu’après vérification de l’émetteur, de la portée et de la fraîcheur de la liste. Les champs `thisUpdate` et `nextUpdate` aident à situer sa publication ; les CRL complètes et les mises à jour différentielles demandent un traitement approprié. Ces mécanismes sont décrits dans la [RFC 5280, sections 5 et 6.3](https://www.rfc-editor.org/rfc/rfc5280.html). Pour une investigation, demandez à votre outil de validation le résultat détaillé plutôt que de rechercher manuellement le numéro dans un fichier trouvé en ligne. Une liste provenant du mauvais émetteur ne répond pas à votre question, même si son contenu est bien formé. Conservez la source de la CRL et sa copie utilisée lors du contrôle. Si vous relisez le dossier plusieurs jours plus tard, la liste disponible aura pu changer. Votre compte rendu doit permettre de retrouver ce qui soutenait la décision initiale. ## Résoudre un désaccord entre deux vérifications Prenons un **cas fictif** : un moniteur signale un certificat révoqué pour `portail.example`, alors qu’un poste ouvre la page sans avertissement. Le nom réservé sert à l’illustration ; aucun incident réel n’est décrit. La première question est l’identité du certificat. Le moniteur a-t-il contacté un ancien serveur ? Le poste a-t-il reçu un certificat renouvelé ? Les deux connexions passent-elles par le même proxy ? Si les empreintes diffèrent, le désaccord n’en est peut-être pas un : les outils évaluent des objets différents. Si les empreintes concordent, comparez la période et les sources de statut. Un résultat peut reposer sur un cache ou une réponse plus ancienne. Relevez ensuite le comportement effectif des clients et leur configuration de validation. L’ouverture de la page n’établit pas que le navigateur a effectué le même contrôle que le moniteur. Pour le propriétaire du service, la décision immédiate consiste à localiser les points de terminaison qui présentent encore le certificat concerné et à appliquer la procédure de remplacement adaptée. N’invitez pas les utilisateurs à contourner l’avertissement pour tester le service. La vérification technique doit être menée par l’équipe qui administre l’infrastructure. ## Traiter la réputation comme une enquête distincte Dans un dossier de phishing, relevez aussi le domaine exact, l’URL reçue, son contexte d’envoi et les actions demandées à l’utilisateur. Un certificat valide peut accompagner une page conçue pour voler des identifiants. Le chiffrement de la connexion ne valide pas l’intention de son opérateur. De même, un certificat révoqué sur un service connu peut correspondre à une opération de remplacement mal achevée. Cherchez l’explication avant de propager une règle de blocage sur tous les sous-domaines ou toutes les adresses associées. La [surveillance Certificate Transparency](/fr/posts/certificate-transparency-detection-phishing-marque) aide à étudier les émissions de certificats, tandis que le [regroupement d’infrastructures par DNS et certificats](/fr/posts/regroupement-infrastructures-malveillantes-dns-passif-certificats) porte sur leurs relations. Aucun de ces rapprochements ne remplace le statut du certificat exact observé pendant votre connexion. Dans le ticket final, écrivez séparément : « certificat identifié », « statut vérifié à telle heure », « effet constaté sur tel client » et « hypothèse sur l’activité du domaine ». Complétez cette dernière avec un [rapport de réputation du domaine](/fr/report), puis décidez de la remédiation TLS et de l’éventuelle enquête de sécurité à partir de leurs preuves respectives. --- # Revoked Certificates: Interpret OCSP and CRL Results URL: https://ismalicious.com/posts/revoked-certificate-ocsp-crl-reputation Date: 2026-10-18T07:00:00.000Z Excerpt: Separate revocation, expiration, and domain reputation. Verify the exact certificate, status freshness, and behavior observed by the client. A revoked TLS certificate should be treated as a trust problem involving that certificate. It does not, by itself, establish that the domain is malicious. Conversely, a favorable revocation status does not guarantee that a site is honest. Keep three parts of the investigation separate: the certificate presented, the revocation response used, and the reputation of the observed activity. This prevents a precise diagnosis from being replaced with an ambiguous label such as “unsafe SSL.” ## Identify the certificate actually presented Record the requested hostname, endpoint contacted, collection time, and client used. Preserve the certificate presented and its chain if your tool provides them. A check performed from another network or at another time may receive a different certificate. Interpret the serial number together with the issuer's identity. Add the certificate's SHA-256 fingerprint to the case record. Do not confuse it with a fingerprint of the public key: they identify different objects and support different comparisons. If you already have a PEM copy named `certificate.pem`, this command reads its local information: ```sh openssl x509 -in certificate.pem -noout -subject -issuer -serial -dates -sha256 -fingerprint ``` A second command displays names and references to status services when those extensions are present: ```sh openssl x509 -in certificate.pem -noout -ext subjectAltName,authorityInfoAccess,crlDistributionPoints ``` These options are documented in [OpenSSL's x509 reference](https://docs.openssl.org/3.3/man1/openssl-x509/). They inspect the saved certificate. They do not contact the site or perform complete chain or revocation validation. Keep the tool version and output with the collected evidence. If a colleague obtains a different result, you can first establish whether you are examining the same certificate. ## Distinguish the OCSP outcomes OCSP defines `good`, `revoked`, and `unknown` statuses. `good` is not complete certificate validation; `revoked` indicates that the certificate should be rejected on that basis; `unknown` means the responder cannot determine its status. A connection error is none of these three outcomes. [RFC 6960](https://www.rfc-editor.org/rfc/rfc6960.html) defines these distinctions and the checks required for responses. Avoid a single “OCSP OK” boolean in your logs. Instead, retain the received result, responder identity, relevant timestamps, signature validation result, and any transport error. This distinguishes a usable response from text displayed by a tool after an incomplete check. A response delivered with the TLS connection, commonly called OCSP stapling, also needs validation. Its presence alone is insufficient: it must correspond to the certificate in question, and the client must accept its authenticity and freshness. Expiration remains a separate check. A certificate can be outside its validity period without being reported as revoked. Writing “not revoked, therefore valid” merges two different conditions and can hide the actual cause of a failure. ## Evaluate a CRL within its scope A certificate revocation list, or CRL, is signed and published for a defined scope. A serial number's absence is meaningful only after verifying the issuer, coverage, and freshness of the list. The `thisUpdate` and `nextUpdate` fields help establish its publication timeline; complete CRLs and delta updates require appropriate processing. These mechanisms are described in [RFC 5280, sections 5 and 6.3](https://www.rfc-editor.org/rfc/rfc5280.html). During an investigation, request detailed results from your validation tool instead of manually searching for a number in a file found online. A list from the wrong issuer does not answer your question, even if its contents are well formed. Preserve the CRL's source and the copy used for the check. If you revisit the case several days later, the available list may have changed. The report should let you recover the evidence that supported the original decision. ## Resolve disagreement between two checks Consider a **fictional case**: a monitor reports a revoked certificate for `portail.example`, while a workstation opens the page without a warning. The reserved name is illustrative; this is not a description of a real incident. The first question is certificate identity. Did the monitor contact an old server? Did the workstation receive a renewed certificate? Do both connections pass through the same proxy? If their fingerprints differ, there may be no disagreement: the tools are evaluating different objects. If the fingerprints match, compare the time periods and status sources. One result may rely on a cache or an older response. Then record the clients' actual behavior and validation configuration. Successfully opening the page does not establish that the browser performed the same check as the monitor. For the service owner, the immediate task is to locate endpoints still presenting the certificate and apply the appropriate replacement procedure. Do not ask users to bypass the warning to test the service. Technical verification belongs with the team administering the infrastructure. ## Investigate reputation separately In a phishing case, also record the exact domain, received URL, message context, and actions requested of the user. A valid certificate can accompany a page designed to steal credentials. Encrypting the connection does not establish the operator's intentions. Likewise, a revoked certificate on a familiar service can result from an unfinished replacement operation. Establish the explanation before distributing a blocking rule covering every associated subdomain or address. [Certificate Transparency monitoring](/posts/certificate-transparency-phishing-brand-monitoring) helps investigate certificate issuance, while [infrastructure clustering through DNS and certificates](/posts/malicious-infrastructure-clustering-passive-dns-certificates) examines relationships. Neither comparison replaces the status of the exact certificate observed during your connection. In the final ticket, record separately: “certificate identified,” “status checked at this time,” “effect observed on this client,” and “hypothesis about the domain's activity.” Add a [domain reputation report](/report) to the last item, then decide on TLS remediation and any security investigation using the evidence relevant to each. --- # How to Analyze an Encrypted ZIP Attachment URL: https://ismalicious.com/posts/encrypted-zip-attachment-analysis Date: 2026-10-17T07:00:00.000Z Excerpt: Handle a password-protected archive without opening it on a user workstation: collection, isolation, hashes, and a documented decision. An encrypted ZIP attachment requires a decision before it is opened: is the exchange expected, and where can its contents be examined without exposing the workstation? The password protects access to the archive. It proves neither the sender's identity nor that the contents are harmless. The procedure below covers triage of an archive received by email. It separates the user's actions from those of the analysis team. The outcome might be a documented release, a rejection, or further investigation. Successful decryption is never, by itself, approval to use the contents. ## Preserve the message and report the concern Do not extract the archive on the workstation used to read email. Use your organization's reporting mechanism so the team receives the original message, headers, and attachment. Informal forwarding or a screenshot can lose useful evidence. Explain the context plainly: whether the recipient expected the message, whether it belongs to an existing conversation, what document was promised, and whether anything has already been opened. If a file was run, report that immediately. This changes the scope of the investigation; analyzing the attachment no longer replaces examining the endpoint. A password included in the message body is still information supplied by the sender. It is not independent evidence. To confirm a business exchange, use an established contact obtained outside the suspicious message. A reply in the same thread cannot rule out compromise of the sender's account. ## Establish what the gateway actually inspected “No malware detected” and “contents not inspected” are different outcomes. Before releasing the message, the analyst needs the gateway's detailed result: archive recognized, password available, extraction successful, items examined, and errors encountered. Capabilities vary by product and configuration. Microsoft explains, for example, that Safe Attachments cannot fully scan or detonate a protected attachment without its password; the password can sometimes be obtained from the email. The [Safe Attachments documentation](https://learn.microsoft.com/en-us/defender-office-365/safe-attachments-about) describes this limitation. It supports neither “all encrypted ZIPs go undetected” nor “our gateway always inspects them.” Preserve the exact result label in the ticket. Normalization that replaces every error with a green indicator removes the information an analyst needs to make a decision. ## Prepare a copy in an isolated environment Restrict handling to an analysis workstation or virtual machine administered for this purpose. For this static triage, start with no connection to production networks or the Internet, no shared folders, no shared clipboard, and no business credentials. Use an up-to-date archive utility supplied by your team. The words “virtual machine” are not enough: verify the access actually available. A folder shared with the host or a mounted corporate drive reintroduces a path to data the archive should not reach. Plan to restore a known baseline after processing. Keep the original archive in authorized evidence storage and calculate its hash. Work on an identified copy. Separating collection, examination, and analysis, while preserving the data, is central to the [NIST SP 800-86 guide to forensic techniques](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-86.pdf). You can follow the [PowerShell SHA-256 procedure](/posts/calculate-sha256-powershell-suspicious-file) to produce the record. The hash identifies the object being handled; it does not neutralize the file. ## Examine the archive without running its contents Start with information the tool can display without extraction: recognized format, entry count, declared sizes, and paths. Some formats or settings conceal part of this information. Record what is inaccessible instead of assuming the archive contains only one document. Set limits on total extracted size, file count, and nested archive depth. A small archive can declare a disproportionately large uncompressed size. If a limit is reached, stop the examination and escalate to a specialist. Forcing extraction does not make the result more reliable. If extraction is authorized, direct it to a disposable directory reserved for that copy. The tool must prevent paths from escaping the intended directory. Disable automatic opening and do not double-click extracted entries. A filename ending in `.pdf` is not sufficient to establish the actual file type. For each relevant entry, record its name, size, type as identified by the tool, and SHA-256. Distinguish those hashes from the ZIP's hash. Two different archives can contain the same file; looking up only the container hash would miss that relationship. ## Use a fictional case to decide the next step Imagine a message titled “corrected invoice” containing `invoice.zip` and a password. The recipient is expecting an invoice, but isolated examination reveals a shortcut and an executable instead of the promised document. This **example is fictional**. It illustrates a discrepancy to investigate, not a reported incident. The team preserves the evidence and keeps the message quarantined. It can look up the hashes under its sharing policy and check whether other recipients received the same message. There is no need to run the program to establish that the delivered contents do not match the expected exchange. Another possible outcome is that a document of the promised type is extracted, with no reputation information available. The conclusion remains incomplete. The team still needs to apply its document inspection procedure and validate the business context before any release. Missing hash intelligence does not resolve the other questions. ## Keep sensitive contents within the authorized scope Do not automatically send the ZIP, its password, or extracted documents to a public service. They may contain customer data, contract information, or credentials. Establish who is authorized to receive them before sharing any file. A hash lookup transmits less information than the file itself, but still reveals an interest in that object. [File hash reputation in incident response](/posts/file-hash-reputation-lookup-ioc-enrichment-incident-response) therefore needs to remain part of the team's approved process. The final report should state what was inspected, what was not, and what decision followed. If a user had already opened an entry, proceed to [correlating local evidence](/posts/investigate-ioc-alert-ip-dns-process). If nothing was opened, retain the evidence and the reason for quarantine or release. The next analyst should be able to understand the decision without handling the archive again. --- # Pièce jointe ZIP chiffrée : comment l’analyser URL: https://ismalicious.com/fr/posts/piece-jointe-zip-chiffree-analyse Date: 2026-10-17T07:00:00.000Z Excerpt: Traitez une archive protégée par mot de passe sans l’ouvrir sur le poste utilisateur : collecte, isolation, empreintes et décision documentée. Une pièce jointe ZIP chiffrée demande une décision avant son ouverture : l’échange est-il attendu, et où peut-on examiner le contenu sans exposer le poste de travail ? Le mot de passe protège l’accès à l’archive. Il ne prouve ni l’identité de l’expéditeur, ni l’innocuité de ce qu’elle contient. La procédure ci-dessous couvre le triage d’une archive reçue par email. Elle sépare les gestes de l’utilisateur et ceux de l’équipe chargée de l’analyse. Son résultat peut être une libération documentée, un refus ou une investigation à poursuivre ; le déchiffrement réussi ne constitue jamais, à lui seul, une validation. ## L’utilisateur conserve le message et signale le doute N’extrayez pas l’archive sur le poste qui sert à lire les emails. Utilisez le mécanisme de signalement prévu par l’organisation afin que l’équipe dispose du message original, des en-têtes et de la pièce jointe. Un transfert informel ou une capture d’écran peut perdre des éléments utiles. Expliquez simplement le contexte : destinataire attendu, conversation existante, type de document annoncé et éventuelle ouverture déjà effectuée. Si le fichier a été lancé, dites-le immédiatement. Cette information change le périmètre de l’enquête ; l’analyse de la pièce jointe ne remplace plus l’examen du poste. Un mot de passe indiqué dans le corps du message reste une donnée fournie par l’expéditeur. Il n’est pas une preuve indépendante. Pour confirmer un échange métier, utilisez un contact déjà connu, obtenu hors du message douteux. Une réponse dans le même fil ne permet pas d’exclure la compromission du compte expéditeur. ## Comprendre ce que la passerelle a réellement inspecté « Aucun malware détecté » et « contenu non inspecté » sont des résultats différents. Avant de libérer le message, l’analyste doit retrouver le résultat détaillé de la passerelle : archive reconnue, mot de passe disponible, extraction réussie, éléments examinés et erreurs. Les capacités varient selon le produit et sa configuration. Microsoft indique, par exemple, que Safe Attachments ne peut pas analyser complètement ou exécuter en environnement virtuel une pièce jointe protégée sans disposer du mot de passe ; celui-ci peut parfois être récupéré dans le message. La [documentation de Safe Attachments](https://learn.microsoft.com/en-us/defender-office-365/safe-attachments-about) décrit cette limite. Elle ne justifie donc ni « tout ZIP chiffré passe inaperçu », ni « notre passerelle les inspecte toujours ». Conservez le libellé exact du résultat dans le ticket. Une normalisation qui remplace toutes les erreurs par un indicateur vert supprime l’information dont l’analyste a besoin pour décider. ## Préparer une copie dans un environnement isolé Réservez la manipulation à une station ou machine virtuelle d’analyse administrée pour cet usage. Pour ce triage statique, partez d’un environnement sans connexion aux réseaux de production ni accès Internet, sans dossiers partagés, sans presse-papiers partagé et sans identifiants métier. Employez un outil d’archivage à jour fourni par votre équipe. Le mot « machine virtuelle » ne suffit pas : vérifiez les accès réellement disponibles. Un dossier partagé vers le poste hôte ou un lecteur d’entreprise monté recrée un chemin vers des données que l’archive n’a pas à atteindre. Prévoyez un retour à un état propre après le traitement. Conservez l’archive originale dans le stockage de preuves autorisé et calculez son empreinte. Travaillez sur une copie identifiée. La séparation entre collecte, examen et analyse, ainsi que la préservation des données, sont au cœur du [guide NIST SP 800-86 sur les techniques forensiques](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-86.pdf). Vous pouvez suivre la procédure de [calcul SHA-256 avec PowerShell](/fr/posts/calculer-sha256-powershell-fichier-suspect) pour produire le relevé. Le hash permet d’identifier l’objet manipulé ; il ne neutralise pas le fichier. ## Examiner l’archive sans lancer son contenu Commencez par les informations que l’outil peut afficher sans extraction : format reconnu, nombre d’entrées, tailles annoncées et chemins. Certains formats ou réglages masquent une partie de ces données. Notez ce qui est inaccessible au lieu de supposer que l’archive ne contient qu’un document. Fixez des limites de taille totale extraite, de nombre de fichiers et de profondeur d’archives imbriquées. Une petite archive peut annoncer un volume décompressé disproportionné. Si les limites sont atteintes, interrompez l’examen et transmettez au spécialiste ; forcer l’extraction ne rend pas le résultat plus fiable. Si l’extraction est autorisée, dirigez-la vers un répertoire jetable réservé à cette copie. L’outil doit empêcher les chemins de sortie du répertoire attendu. Désactivez l’ouverture automatique et ne double-cliquez pas les éléments extraits. Un nom finissant par `.pdf` ne suffit pas à confirmer le type réel. Pour chaque élément pertinent, relevez nom, taille, type déterminé par l’outil et SHA-256. Distinguez ces empreintes de celle du ZIP. Deux archives différentes peuvent contenir le même fichier ; rechercher uniquement le hash du conteneur manquerait cette relation. ## Un cas fictif pour choisir la suite Imaginons un message intitulé « facture corrigée » contenant `facture.zip`, accompagné d’un mot de passe. Le destinataire attend bien une facture, mais l’examen isolé révèle un raccourci et un exécutable au lieu du document annoncé. Cet **exemple est fictif** ; il illustre une contradiction à examiner, sans représenter un incident observé. L’équipe conserve les éléments et maintient le message en quarantaine. Elle peut rechercher les empreintes selon sa politique de partage et vérifier si d’autres destinataires ont reçu le même message. Elle n’a pas besoin de lancer le programme pour constater que le contenu livré ne correspond pas à l’échange attendu. Autre résultat possible : un document du type annoncé est extrait, sans signal de réputation disponible. La conclusion reste incomplète. L’équipe doit appliquer sa procédure d’inspection documentaire et valider le contexte métier avant une éventuelle libération. L’absence de renseignement sur le hash n’efface pas les autres questions. ## Garder les secrets dans le périmètre autorisé N’envoyez pas automatiquement le ZIP, son mot de passe ou les documents extraits à un service public. Le contenu peut inclure des données clients, des éléments contractuels ou des identifiants. Déterminez les destinataires autorisés avant tout partage de fichier. Une recherche d’empreinte transmet moins d’information que le fichier lui-même, mais révèle tout de même un intérêt pour cet objet. La [réputation des hash en réponse à incident](/fr/posts/reputation-hash-fichiers-enrichissement-ioc-reponse-incident) doit donc rester rattachée au processus de l’équipe. Le compte rendu final doit indiquer ce qui a été inspecté, ce qui ne l’a pas été et la décision prise. Si un utilisateur avait déjà ouvert un élément, passez à la [corrélation des traces locales](/fr/posts/alerte-ioc-correler-ip-dns-processus). Si aucune ouverture n’a eu lieu, conservez les preuves et la raison de la quarantaine ou de la libération : le prochain analyste doit pouvoir comprendre le choix sans recommencer la manipulation. --- # Calculate a File’s SHA-256 Hash with PowerShell URL: https://ismalicious.com/posts/calculate-sha256-powershell-suspicious-file Date: 2026-10-16T07:00:00.000Z Excerpt: Calculate SHA-256 without executing a file, compare it with the correct reference, and document the limits of a hash reputation result. To calculate a file's SHA-256 on Windows, open PowerShell and run `Get-FileHash` with its exact path. The command hashes the contents without executing the program or opening the document in its usual application. The result lets you compare two copies or look up information about the file. It is not a security verdict. A useful procedure therefore combines the command, identification of the file, and a clear rule for interpreting the lookup result. ## Select the file without running it If an attachment looks suspicious, start with your organization's reporting process. The person who received the message does not need to open it to help the security team. The procedure below is intended for whoever is authorized to handle the collected copy. Use an analysis location intended for these files, with automatic previews disabled. Preserve the original and work on a controlled copy. Record the provenance: an email, download, EDR collection, or removable device. A hash on its own cannot explain how the file reached the endpoint. In this **fictional example**, the copy is stored at `C:\Analysis\attachment [1].bin`. The neutral extension identifies the working copy; it does not change the nature of the contents or make them harmless. ```powershell Get-FileHash -LiteralPath 'C:\Analysis\attachment [1].bin' -Algorithm SHA256 ``` `-LiteralPath` prevents the brackets in the filename from being interpreted as wildcard characters. SHA-256 is already the command's default algorithm; specifying it makes the procedure explicit. These parameters are described in [Microsoft's Get-FileHash documentation](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-7.5). Replace the example path with that of the collected file. Do not copy a command supplied by an email sender to “verify” their attachment. Construct the command from your own procedure. ## Capture a usable evidence record The output contains the algorithm, hash, and path. To avoid truncating the value during manual copying, store the result in a variable and export a small record. The destination directory below must already exist and be reserved for analysis results. ```powershell $analysisPath = 'C:\Analysis\attachment [1].bin' $analysisFile = Get-Item -LiteralPath $analysisPath -ErrorAction Stop $analysisHash = Get-FileHash -LiteralPath $analysisPath -Algorithm SHA256 -ErrorAction Stop [pscustomobject]@{ Path = $analysisFile.FullName SizeBytes = $analysisFile.Length Algorithm = $analysisHash.Algorithm SHA256 = $analysisHash.Hash CalculatedUtc = [DateTime]::UtcNow.ToString('o') } | Export-Csv -LiteralPath 'C:\Analysis\results\hash.csv' -NoTypeInformation -Encoding UTF8 ``` Run this sequence only against a stable copy. A file that is still being downloaded, synchronized, or modified by an application may not contain the same bytes between reads. An unexpected size or a changing hash needs to be investigated before interpreting its reputation. The export also contains the internal path. Keep it in the incident record and share only the fields necessary when consulting an external service. The calculation timestamp records when you analyzed the file, not when its contents were originally created. ## Compare the right hash with the right reference Suppose a publisher provides a SHA-256 for an installer. Check that the reference matches the exact version, platform, and file. Comparing an ARM package with the value for an x64 package produces a mismatch without establishing an attack. Obtain the reference through a publisher channel whose authenticity you have verified. If both the file and the expected value came from the same suspicious message, a match provides no independent evidence about the sender. You can compare the values without rereading the contents: ```powershell $expectedSha256 = Read-Host 'SHA-256 from the verified reference' if ($expectedSha256 -notmatch '^[0-9a-fA-F]{64}$') { throw 'The reference must contain exactly 64 hexadecimal characters.' } $analysisHash.Hash -ieq $expectedSha256 ``` `True` indicates that the compared values match. `False` requires investigation: an incorrect reference, an incomplete copy, or different contents are possible explanations to distinguish. Neither result, on its own, authorizes executing an unexpected file. ## Interpret a reputation lookup If a lookup returns malicious intelligence, retain the source, date, and available evidence. Compare that information with your context: whether the file is present, whether it ran, the account involved, and any observed behavior. If it returns nothing, record “hash unknown to this source at this time.” A recent, modified, or rarely distributed file may be absent from a database. Replacing that absence with “safe” erases the lookup's limitation. If the result is reassuring, still check the context of use. A legitimate administration program can be used for an unauthorized operation. The binary's reputation does not prove that the person who launched it had permission to do so. The [guide to file hash reputation in incident response](/posts/file-hash-reputation-lookup-ioc-enrichment-incident-response) explains where this intelligence fits in triage. If you suspect execution, correlate it with [process and network logs](/posts/investigate-ioc-alert-ip-dns-process). ## Add signature information where relevant For a supported format, `Get-AuthenticodeSignature` lets you inspect the Authenticode signature. [Microsoft's documentation](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature?view=powershell-7.5) describes the information and statuses returned. ```powershell Get-AuthenticodeSignature -LiteralPath $analysisPath | Select-Object Status, StatusMessage, SignerCertificate ``` Interpret this output separately from the hash. A missing signature does not establish that a file is malicious. A valid signature provides evidence about the signature checked, without establishing that the program belongs in your environment or that its presence in this folder is expected. For a file inside a ZIP, also distinguish the archive's hash from those of its extracted entries. They are different objects. Extracting a suspicious attachment requires an isolated environment and a separate procedure; it should not be improvised on the user's workstation. To add context to the case, use the [file hash reputation lookup](/threat-intel/file-hash) with the calculated SHA-256, without sending the file. Finish the ticket with the collected path, complete SHA-256, provenance, dated result, and next decision. This record lets a colleague resume the analysis without opening the file to rediscover what was checked. --- # Calculer le SHA-256 d’un fichier avec PowerShell URL: https://ismalicious.com/fr/posts/calculer-sha256-powershell-fichier-suspect Date: 2026-10-16T07:00:00.000Z Excerpt: Calculez une empreinte SHA-256 sans exécuter le fichier, comparez la bonne référence et consignez les limites du résultat de réputation. Pour calculer le SHA-256 d’un fichier sous Windows, ouvrez PowerShell et utilisez `Get-FileHash` avec son chemin exact. La commande calcule une empreinte du contenu sans exécuter le programme ni ouvrir le document dans son application habituelle. Le résultat permet de comparer deux copies ou de rechercher des renseignements sur le fichier. Il ne constitue pas un verdict de sécurité. La procédure utile associe donc la commande, l’identification du fichier et une règle claire pour interpréter ce que la recherche retourne. ## Choisir le fichier sans le lancer Si une pièce jointe vous paraît suspecte, commencez par le processus de signalement de votre organisation. L’utilisateur qui a reçu le message n’a pas besoin de l’ouvrir pour aider l’équipe sécurité. Le calcul ci-dessous s’adresse à la personne autorisée à manipuler la copie collectée. Utilisez un emplacement d’analyse prévu pour ces fichiers, sans prévisualisation automatique. Conservez l’original et travaillez sur une copie contrôlée. Relevez la provenance : message, téléchargement, collecte EDR ou support amovible. Un hash isolé ne dit pas comment le fichier est arrivé sur le poste. Dans cet **exemple fictif**, la copie est placée sous `C:\Analyse\piece-jointe [1].bin`. L’extension neutre sert à identifier la copie de travail ; elle ne modifie pas la nature du contenu et n’en garantit pas l’innocuité. ```powershell Get-FileHash -LiteralPath 'C:\Analyse\piece-jointe [1].bin' -Algorithm SHA256 ``` `-LiteralPath` évite d’interpréter les crochets du nom comme des caractères génériques. SHA-256 est déjà le choix par défaut de la commande ; le préciser rend la procédure explicite. Ces paramètres sont décrits dans la [documentation Microsoft de Get-FileHash](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash?view=powershell-7.5). Le chemin de l’exemple doit être remplacé par celui du fichier collecté. Ne copiez pas une commande fournie par un expéditeur pour « vérifier » sa pièce jointe : écrivez la commande depuis votre propre procédure. ## Capturer une preuve exploitable La sortie présente l’algorithme, l’empreinte et le chemin. Pour éviter qu’une copie manuelle tronque la valeur, conservez le résultat dans une variable puis exportez un petit relevé. Le dossier de destination ci-dessous doit déjà exister et être réservé aux résultats de l’analyse. ```powershell $cheminAnalyse = 'C:\Analyse\piece-jointe [1].bin' $fichierAnalyse = Get-Item -LiteralPath $cheminAnalyse -ErrorAction Stop $empreinteAnalyse = Get-FileHash -LiteralPath $cheminAnalyse -Algorithm SHA256 -ErrorAction Stop [pscustomobject]@{ Chemin = $fichierAnalyse.FullName TailleOctets = $fichierAnalyse.Length Algorithme = $empreinteAnalyse.Algorithm SHA256 = $empreinteAnalyse.Hash CalculUtc = [DateTime]::UtcNow.ToString('o') } | Export-Csv -LiteralPath 'C:\Analyse\resultats\empreinte.csv' -NoTypeInformation -Encoding UTF8 ``` N’exécutez cette séquence que sur une copie stable. Un fichier encore téléchargé, synchronisé ou modifié par une application ne représente pas nécessairement le même contenu entre deux lectures. Une taille inattendue ou un hash qui change impose de résoudre ce problème avant d’interpréter la réputation. L’export garde aussi le chemin interne. Conservez-le dans le dossier d’incident ; partagez uniquement les champs nécessaires lorsque vous sollicitez un service externe. La date de calcul est une date d’analyse, pas la date de création réelle du contenu. ## Comparer la bonne empreinte à la bonne référence Supposons qu’un éditeur publie un SHA-256 pour son installateur. Vérifiez que la référence correspond à la version, à la plateforme et au fichier exacts. Comparer un paquet ARM à la valeur d’un paquet x64 produit un écart sans démontrer une attaque. Récupérez la référence par un canal de l’éditeur dont vous avez vérifié l’authenticité. Si le fichier et la valeur attendue proviennent du même message suspect, leur concordance n’apporte pas de preuve indépendante sur l’expéditeur. Vous pouvez effectuer la comparaison sans relire le contenu : ```powershell $sha256Attendu = Read-Host 'SHA-256 de la référence vérifiée' if ($sha256Attendu -notmatch '^[0-9a-fA-F]{64}$') { throw 'La référence doit contenir exactement 64 caractères hexadécimaux.' } $empreinteAnalyse.Hash -ieq $sha256Attendu ``` `True` indique une correspondance des valeurs comparées. `False` demande une investigation : mauvaise référence, copie incomplète ou contenu différent sont des explications à départager. Aucun de ces deux résultats ne suffit à autoriser l’exécution d’un fichier inattendu. ## Interpréter une recherche de réputation Lorsqu’une recherche retourne un renseignement malveillant, conservez la source, sa date et les éléments disponibles. Rapprochez cette information de votre contexte : présence du fichier, lancement éventuel, compte concerné et comportement observé. Lorsqu’elle ne retourne rien, écrivez « empreinte inconnue de cette source à cette date ». Un fichier récent, modifié ou peu diffusé peut être absent d’une base. Remplacer cette absence par « sain » efface la limite de la recherche. Lorsqu’elle retourne un renseignement rassurant, vérifiez encore le contexte d’usage. Un programme d’administration légitime peut servir à une opération non autorisée. La réputation du binaire ne prouve pas que la personne qui l’a lancé avait le droit de le faire. Le [guide sur la réputation des hash en réponse à incident](/fr/posts/reputation-hash-fichiers-enrichissement-ioc-reponse-incident) précise où placer ce renseignement dans le triage. Si vous soupçonnez une exécution, rapprochez-le des [journaux de processus et de réseau](/fr/posts/alerte-ioc-correler-ip-dns-processus). ## Ajouter la signature quand elle est pertinente Pour un format pris en charge, `Get-AuthenticodeSignature` permet d’inspecter la signature Authenticode. La [documentation Microsoft](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-authenticodesignature?view=powershell-7.5) décrit les informations et statuts retournés. ```powershell Get-AuthenticodeSignature -LiteralPath $cheminAnalyse | Select-Object Status, StatusMessage, SignerCertificate ``` Interprétez cette sortie séparément du hash. Une signature absente ne suffit pas à qualifier le fichier de malveillant. Une signature valide apporte un élément sur la signature vérifiée, sans démontrer que le programme convient à votre environnement ou que son origine dans ce dossier est attendue. Pour un fichier contenu dans un ZIP, distinguez enfin l’empreinte de l’archive de celle de chaque élément extrait. Ce sont des objets différents. L’extraction d’une pièce jointe suspecte exige un environnement isolé et une procédure distincte ; elle ne doit pas être improvisée sur le poste utilisateur. Pour enrichir le dossier, utilisez la [recherche de réputation d’une empreinte de fichier](/fr/threat-intel/file-hash) avec le SHA-256 calculé, sans envoyer le fichier. Terminez le ticket avec le chemin collecté, le SHA-256 complet, la provenance, le résultat daté et la décision suivante. Ce relevé permet à un collègue de reprendre l’analyse sans ouvrir le fichier pour retrouver ce qui avait été vérifié. --- # TAXII Pagination: Sync Without Losing Feed Additions URL: https://ismalicious.com/posts/taxii-pagination-added-after-sync Date: 2026-10-15T07:00:00.000Z Excerpt: Separate added_after, date_added, and modified, then test cursors, object versions, and crash recovery in a TAXII 2.1 client. A TAXII client can report “synchronization successful” while missing objects. This often happens when it uses a STIX object's `modified` value as `added_after`, or advances its checkpoint before saving the final page. To verify your integration, separate two problems: reading every page of a request, and knowing where to resume after a failure. A pagination cursor addresses the first. A durable checkpoint and storage that can safely replay the same data address the second. ## Intelligence timestamps and transport timestamps differ In TAXII 2.1, `added_after` selects objects added to a collection after a specified time. That time is independent of the timestamps inside STIX objects. The manifest exposes `date_added`; the `X-TAXII-Date-Added-First` and `X-TAXII-Date-Added-Last` headers describe the response boundaries. These rules appear in the [TAXII 2.1 specification](https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html). Consider this **fictional example**, where A and B stand for object identifiers: | Object | Last STIX modification | Added to the collection | | ------ | ---------------------- | ----------------------- | | A | September 1 | October 12, 08:00 UTC | | B | October 11 | October 12, 08:01 UTC | An import starting after October 11 must be able to retrieve A despite its older content. If a local filter automatically rejects objects whose `modified` timestamp precedes the previous run, A disappears. Make this a priority case in your synchronization tests. Store timestamps at their original precision. Converting them to whole seconds to simplify a database can shift a recovery boundary. Keep a readable representation too, but do not use that display value as a technical key. ## Read every page before confirming the run When `more` is `true`, a TAXII 2.1 response may provide `next`. The client passes that token in the following request with the original options. Without a token, the specification provides a fallback: use `X-TAXII-Date-Added-Last` as `added_after`, retaining the other filters. The [OASIS interoperability test document](https://docs.oasis-open.org/cti/taxii-2.1-interop/v1.0/taxii-2.1-interop-v1.0.html) describes both paths. Treat `next` as an opaque value. Do not decode it to construct a page number or reuse it for another collection. The API root, collection, and filters must remain associated with the current run. An operational procedure can follow these steps: 1. Load the last confirmed checkpoint and the task's filters. 2. Request the first page and verify its status and structure. 3. Durably save the objects and any validation rejections. 4. Continue according to `more` and the continuation information received. 5. Confirm the new checkpoint once the entire run has been processed. This defines a processing contract, without prescribing a particular transaction implementation. Saving each page separately is appropriate if replay causes no additional effects. You need to be able to explain what happens between a successful write and a process failure. ## Test the boundaries where objects disappear Build a test collection containing several objects with exactly the same addition timestamp. Set a small page size so that the group spans multiple pages. Verify that the sequence of responses returns every expected identifier. This test is essential for timestamp-based continuation: a strictly “after T” condition does not, by itself, retrieve other items dated T. If the server cannot traverse that boundary correctly, blindly repeating the request will not solve the problem. Document the discrepancy and clarify the behavior with the provider before declaring the import complete. Also test an empty page following a response that indicated more items were available. A collection can change while it is being read. The client must record this result and finish or report the anomaly according to the observed contract, without entering an infinite loop. Add protection against a repeated token that produces no progress. An overlap window between runs can help replay boundary items. It also increases the duplicates your storage must absorb. It cannot repair expired retention or broken pagination that makes some objects inaccessible. ## Choose which versions to retain explicitly The TAXII `match[version]` filter can request `first`, `last`, or `all`; `last` is the default, as described in the [version filtering section](https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html). For versioned STIX objects, a specific value corresponds to their `modified` timestamp. The same identifier can therefore refer to several states of the intelligence. Decide whether you need a current view or a history. For a current view, you can retain the latest state while archiving each import's provenance. For a history, request the relevant versions and verify that the server actually retains them. No parameter can recreate a version the provider has deleted. Deduplicating on the identifier alone can discard a useful revision. For STIX objects that carry `modified`, test a key that includes it. For types without that field, define a rule appropriate to the type instead of adding an invented date. ## Simulate failure before enabling the production feed Deliberately interrupt the client after it saves a page but before it confirms the checkpoint. On restart, it should reread what is necessary without creating another alert for every object already known. Repeat the exercise with an invalid object. Two choices are defensible: stop the window for correction, or durably isolate the rejected object and continue under an explicit policy. Silently ignoring it makes the “imported” counter misleading. Logs should distinguish received, saved, already present, and rejected objects. The [continuous TAXII-to-SIEM integration guide](/posts/taxii-threat-feed-siem-continuous-integration) covers the connector's operating environment. The [differences between Indicator and Observed Data](/posts/stix-indicator-vs-observed-data) then help you verify what happens to objects after transport. Before adding more collections, replay these cases against one: a late addition, identical timestamps, a new version, an interruption, and a validation rejection. Keep the expected results with the connector. They provide a concrete check whenever the [STIX/TAXII pipeline](/posts/stix-taxii-threat-feeds-opencti-misp-pipelines) changes, beyond counting successful HTTP responses. --- # TAXII : paginer sans perdre les ajouts du flux URL: https://ismalicious.com/fr/posts/taxii-pagination-added-after-synchronisation Date: 2026-10-15T07:00:00.000Z Excerpt: Distinguez added_after, date_added et modified, puis testez les curseurs, les versions et la reprise après panne d’un client TAXII 2.1. Un client TAXII peut répondre « synchronisation réussie » tout en oubliant des objets. Le défaut apparaît souvent quand il utilise `modified` d’un objet STIX comme valeur de `added_after`, ou lorsqu’il avance son checkpoint avant d’avoir enregistré la dernière page. Pour vérifier votre intégration, séparez deux problèmes : parcourir toutes les pages d’une requête et savoir d’où reprendre après une panne. Un curseur de pagination résout le premier. Un checkpoint durable et un stockage capable de rejouer les mêmes données résolvent le second. ## La date du renseignement n’est pas la date du transport Dans TAXII 2.1, `added_after` sélectionne les objets ajoutés après une date donnée à la collection. Cette date est indépendante des horodatages internes de STIX. Le manifeste expose `date_added` ; les en-têtes `X-TAXII-Date-Added-First` et `X-TAXII-Date-Added-Last` décrivent les bornes de la réponse. Ces règles figurent dans la [spécification TAXII 2.1](https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html). Considérez cet **exemple fictif**, où A et B abrègent des identifiants : | Objet | Dernière modification STIX | Ajout à la collection | | ----- | -------------------------- | --------------------- | | A | 1er septembre | 12 octobre, 08:00 UTC | | B | 11 octobre | 12 octobre, 08:01 UTC | Un import démarré après le 11 octobre doit pouvoir récupérer A malgré son contenu ancien. Si votre filtre local rejette automatiquement les objets dont `modified` précède le dernier passage, A disparaîtra. C’est le cas à inclure en priorité dans un test de synchronisation. Stockez les horodatages avec leur précision originale. Convertir une date en secondes entières pour simplifier la base peut déplacer une frontière de reprise. Conservez aussi une représentation lisible, mais ne l’utilisez pas comme clé technique. ## Lire toutes les pages, puis confirmer le passage Lorsque `more` vaut `true`, une réponse TAXII 2.1 peut fournir `next`. Le client transmet ce jeton dans la requête suivante avec les options d’origine. Sans jeton, la spécification prévoit un repli : utiliser `X-TAXII-Date-Added-Last` comme `added_after`, en gardant les autres filtres. Le [document de tests d’interopérabilité OASIS](https://docs.oasis-open.org/cti/taxii-2.1-interop/v1.0/taxii-2.1-interop-v1.0.html) décrit ces deux parcours. Traitez `next` comme une valeur opaque. Ne le décodez pas pour construire un numéro de page et ne le réutilisez pas pour une autre collection. Le triplet racine API, collection, filtres doit rester associé au passage courant. Une recette opérationnelle peut suivre ces étapes : 1. Charger le dernier checkpoint confirmé et les filtres de la tâche. 2. Demander la première page et vérifier son statut ainsi que sa structure. 3. Enregistrer les objets et les éventuels rejets de validation de façon durable. 4. Continuer selon `more` et les informations de continuation reçues. 5. Confirmer le nouveau checkpoint lorsque tout le passage a été traité. Cette liste décrit un contrat de traitement, pas une implémentation transactionnelle imposée. Un stockage par page convient si le rejeu est sans effet supplémentaire. L’enjeu est de pouvoir expliquer ce qui se passe entre une écriture réussie et une panne du processus. ## Tester les frontières qui font perdre des objets Construisez une collection de test dont plusieurs objets partagent exactement le même instant d’ajout. Imposez une petite taille de page pour couper ce groupe. Vérifiez que la suite des réponses restitue tous les identifiants attendus. Ce test est indispensable avec une continuation temporelle : une condition strictement « après T » ne récupère pas, par elle-même, les autres éléments datés de T. Si le serveur ne permet pas de parcourir cette frontière correctement, refaire aveuglément la même requête ne règle rien. Documentez l’écart et faites préciser le comportement par le fournisseur avant de déclarer l’import complet. Testez aussi une page vide après une réponse annonçant encore des éléments. Une collection peut évoluer pendant la lecture. Le client doit enregistrer ce résultat et terminer ou signaler l’anomalie selon le contrat observé, sans entrer dans une boucle infinie. Ajoutez une protection contre un jeton répété sans progression. Une fenêtre de recouvrement entre deux passages peut aider à rejouer des éléments de frontière. Elle augmente aussi le nombre de doublons à absorber. Elle ne répare ni une rétention expirée, ni une pagination défectueuse qui rend certains éléments inaccessibles. ## Choisir explicitement les versions à conserver Le filtre TAXII `match[version]` peut demander `first`, `last` ou `all` ; `last` est le comportement par défaut, selon la [section sur les filtres de versions](https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html). Pour les objets STIX versionnés, une valeur précise correspond à leur horodatage `modified`. Le même identifiant peut donc désigner plusieurs états du renseignement. Décidez si votre besoin est une vue actuelle ou un historique. Pour une vue actuelle, vous pouvez conserver le dernier état tout en archivant la provenance de chaque import. Pour un historique, demandez les versions pertinentes et vérifiez que le serveur les conserve effectivement. Aucun choix de paramètre ne recrée une version que le fournisseur a supprimée. Une déduplication uniquement sur l’identifiant peut jeter une révision utile. Pour les objets STIX qui portent `modified`, testez une clé incluant ce champ. Pour les types sans ce champ, définissez une règle adaptée au type au lieu d’ajouter une date inventée. ## Simuler la panne avant d’ouvrir le flux en production Interrompez volontairement le client après l’enregistrement d’une page mais avant la confirmation du checkpoint. Au redémarrage, il doit relire ce qui est nécessaire sans créer une nouvelle alerte pour chaque objet déjà connu. Refaites l’exercice avec un objet invalide. Deux décisions sont défendables : arrêter la fenêtre pour correction, ou isoler durablement l’objet rejeté et poursuivre selon une politique explicite. L’ignorer silencieusement rend le compteur « importés » trompeur. Le journal doit distinguer reçus, enregistrés, déjà présents et rejetés. Le [guide d’intégration continue TAXII vers un SIEM](/fr/posts/flux-menaces-taxii-integration-siem-continue) détaille l’environnement du connecteur. Les [différences entre Indicator et Observed Data](/fr/posts/stix-indicator-observed-data-differences) permettent ensuite de vérifier ce que deviennent les objets une fois transportés. Avant de multiplier vos collections, rejouez ces cas sur une seule : ajout tardif, dates identiques, nouvelle version, panne intermédiaire et rejet de validation. Conservez le résultat attendu avec le connecteur. Vous disposerez alors d’un contrôle concret lors de chaque évolution du [pipeline STIX/TAXII](/fr/posts/flux-stix-taxii-pipelines-opencti-misp), au lieu de vous fier au seul nombre de réponses HTTP réussies. --- # STIX : distinguer Indicator et Observed Data URL: https://ismalicious.com/fr/posts/stix-indicator-observed-data-differences Date: 2026-10-14T07:00:00.000Z Excerpt: Séparez une règle de détection, un fait observé et un Sighting STIX pour importer vos IOC sans transformer chaque trace en menace. Un objet **Indicator** STIX propose une condition de détection. Un objet **Observed Data** rapporte des faits observés. Confondre les deux conduit à transformer une résolution DNS ordinaire en preuve de menace, ou à importer une règle comme si elle décrivait un incident déjà survenu chez vous. Cette différence devient concrète lorsqu’un SOC reçoit du renseignement externe et le rapproche de ses journaux. Le flux décrit ce qu’il faut chercher ; la collecte locale permet de déterminer ce qui s’est passé. Le modèle doit conserver les deux niveaux pour que l’analyste puisse expliquer son verdict. ## Trois objets, trois questions Dans STIX 2.1, `indicator` porte notamment un `pattern` et sa période de validité. `observed-data` associe des objets observables à `first_observed`, `last_observed` et `number_observed`. `sighting` exprime l’observation d’un objet de renseignement et peut référencer les données qui l’étayent. Ces rôles sont définis dans les [sections Indicator, Observed Data et Sighting de STIX 2.1](https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html). Pour choisir quoi produire, formulez d’abord votre phrase en français : | Ce que l’équipe sait | Représentation à envisager | Ce qui reste à établir | | ---------------------------------------------------------- | ----------------------------------------------- | ------------------------------------------------ | | « Nous cherchons les accès à ce domaine signalé. » | Indicator | Une activité locale correspond-elle au motif ? | | « Ce poste a résolu ce domaine à cette heure. » | Observed Data et observables | Pourquoi cette résolution a-t-elle eu lieu ? | | « Nous avons vu cet indicateur dans notre environnement. » | Sighting, éventuellement relié aux observations | Quelle interprétation et quelle action retenir ? | Ce tableau est une aide de modélisation, pas une règle de blocage. Une organisation peut recevoir un Indicator utile à une recherche rétrospective sans décider de le déployer dans ses équipements de prévention. ## Un domaine présent dans les journaux n’est pas un verdict Prenons un **exemple fictif** : une source publie un motif visant `collecteur.example`, et un résolveur interne enregistre une demande vers ce nom. Le domaine réservé `.example` sert uniquement à l’illustration. Le motif STIX pourrait être : ```text [domain-name:value = 'collecteur.example'] ``` Il s’agit seulement du champ `pattern`, pas d’un objet STIX complet. Avant de l’exploiter, votre importeur doit aussi conserver son identifiant, son auteur connu, sa version et les informations nécessaires à la politique locale. L’analyste découvre ensuite que le client DNS était une plateforme de recherche de menaces. La plateforme a interrogé le domaine dans le cadre d’une investigation autorisée. L’observation reste vraie. La correspondance avec le motif reste vraie. L’hypothèse « un poste métier est compromis » n’est toutefois pas établie. Si le connecteur avait immédiatement étiqueté cette observation comme une infection, le SIEM aurait propagé une conclusion incorrecte. Conservez donc le rôle de l’actif et le motif de l’activité dans le dossier d’enquête. Une liste d’exclusion générale sur le domaine effacerait aussi de futures correspondances pertinentes. ## Séparer les horloges pendant l’import Votre interface devrait distinguer la création du renseignement, la période pendant laquelle le motif est utile et l’heure de l’événement local. Afficher une seule colonne « date » rend ces valeurs interchangeables alors qu’elles répondent à des questions différentes. Dans notre scénario, imaginez un événement local du lundi, un Indicator reçu le mercredi et une recherche rétrospective exécutée le jeudi. Le jeudi est la date de détection dans votre outil, pas celle du contact avec le domaine. Sans cette distinction, une équipe peut chercher des traces sur le mauvais créneau ou traiter comme active une activité ancienne. Notez aussi la date de consultation du renseignement. Si la source révise son analyse, l’équipe doit pouvoir reconstruire la décision prise avec les informations disponibles au moment du traitement. Garder uniquement la dernière fiche visible ne permet pas cette relecture. La [corrélation entre IP, DNS et processus](/fr/posts/alerte-ioc-correler-ip-dns-processus) fournit la suite logique : une fois la correspondance trouvée, relier l’actif et le processus à des événements précis. ## Préserver les relations sans inventer leur sens STIX représente le renseignement comme un graphe d’objets et de relations. L’[introduction officielle d’OASIS](https://oasis-open.github.io/cti-documentation/stix/intro.html) présente cette organisation, qui permet de garder le contexte autour d’un indicateur. Dans votre pipeline, évitez d’aplatir tout le graphe en une ligne « valeur, malveillant ». Une adresse partagée par deux rapports ne suffit pas à fusionner les campagnes de ces rapports. Une relation reçue doit garder son origine ; une relation déduite localement doit être reconnaissable comme telle. Un contrat d’import peut définir trois sorties : le document brut archivé, les champs utilisables par le moteur de corrélation et les éléments soumis à examen. Un motif que votre moteur ne comprend pas va dans la troisième sortie. Extraire uniquement son premier domaine et ignorer ses autres conditions changerait sa signification. Testez cette séparation avec un jeu fictif comprenant un motif simple, un motif composé et une observation sans qualificatif de menace. Le résultat attendu doit préciser quel objet produit une recherche, lequel enrichit le contexte et lequel attend une décision humaine. Ce test vérifie le comportement du connecteur, pas seulement sa capacité à lire du JSON. ## Contrôler ce qui déclenche une action Pour chaque correspondance, demandez au moteur de décision de conserver quatre éléments : l’Indicator utilisé, sa version, l’événement local et la politique appliquée. Cette trace aide à expliquer pourquoi deux alertes portant sur le même domaine ont reçu des traitements différents. Le contexte d’un serveur de production et celui d’un environnement d’analyse peuvent justifier des priorités différentes. En revanche, l’absence de contexte doit rester visible. La remplacer automatiquement par une confiance élevée masque précisément ce qu’il reste à vérifier. Les marques de partage méritent également une étape dédiée. Avant de redistribuer une observation, vérifiez si les noms de postes, comptes ou chemins peuvent sortir de votre organisation. Le fait qu’un format accepte un champ ne signifie pas que tout destinataire doit le recevoir. Gardez les preuves détaillées dans le dossier interne quand leur diffusion n’est pas autorisée. Le [guide des flux STIX/TAXII](/fr/posts/flux-stix-taxii-pipelines-opencti-misp) explique comment situer cette transformation entre le fournisseur, la plateforme de renseignement et le SIEM. Ajoutez à votre recette un cas où l’import réussit mais où aucune action automatique ne doit se produire. Pour votre prochaine alerte, ouvrez un [rapport d’indicateur](/fr/report), consignez son contexte daté, puis écrivez séparément l’observation locale et la conclusion de l’analyste. Si ces trois phrases sont impossibles à distinguer dans le ticket, corrigez le modèle avant d’ajouter une nouvelle source de renseignement. --- # STIX: Indicator vs Observed Data URL: https://ismalicious.com/posts/stix-indicator-vs-observed-data Date: 2026-10-14T07:00:00.000Z Excerpt: Separate a detection pattern, an observed fact, and a STIX Sighting so your IOC pipeline does not turn every recorded event into a threat. A STIX **Indicator** proposes a detection condition. **Observed Data** records observed facts. Confusing the two can turn an ordinary DNS lookup into evidence of a threat, or cause a rule to be imported as though it described an incident that has already happened in your environment. The distinction matters when a SOC receives external intelligence and matches it against its logs. The feed describes what to look for; local telemetry helps establish what happened. Your data model needs to preserve both layers so an analyst can explain the verdict. ## Three objects, three questions In STIX 2.1, `indicator` includes a `pattern` and its validity period. `observed-data` associates observable objects with `first_observed`, `last_observed`, and `number_observed`. A `sighting` asserts that an intelligence object was observed and can reference the supporting data. These roles are defined in the [Indicator, Observed Data, and Sighting sections of STIX 2.1](https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html). Before deciding which object to produce, write down what you know in plain language: | What the team knows | Representation to consider | What still needs to be established | | ---------------------------------------------------- | ------------------------------------------- | ----------------------------------------------- | | “We are looking for access to this reported domain.” | Indicator | Does local activity match the pattern? | | “This endpoint resolved this domain at this time.” | Observed Data and observables | Why did the lookup happen? | | “We saw this indicator in our environment.” | Sighting, optionally linked to observations | What interpretation and action are appropriate? | This table helps with modeling; it is not a blocking policy. An organization can receive an Indicator that is useful for a retrospective search without choosing to deploy it to prevention controls. ## A domain in the logs is not a verdict Consider a **fictional example**: a source publishes a pattern for `collecteur.example`, and an internal resolver records a query for that name. The reserved `.example` domain is used only for illustration. The STIX pattern could be: ```text [domain-name:value = 'collecteur.example'] ``` This is only the `pattern` field, not a complete STIX object. Before using it, your importer also needs to preserve its identifier, known author, version, and the information required by local policy. The analyst then discovers that the DNS client was a threat research platform. It queried the domain as part of an authorized investigation. The observation remains true. The pattern match remains true. However, the hypothesis that an employee workstation is compromised has not been established. If the connector had immediately labeled the observation as an infection, the SIEM would have propagated an incorrect conclusion. Keep the asset's role and the reason for its activity in the investigation record. A blanket exclusion for the domain would also suppress future matches that might be relevant. ## Keep the different timestamps separate during import Your interface should distinguish when the intelligence was created, when its pattern is useful, and when the local event occurred. A single “date” column makes these values look interchangeable even though they answer different questions. In this scenario, imagine a local event on Monday, an Indicator received on Wednesday, and a retrospective search performed on Thursday. Thursday is the detection date in your tool, not the date of contact with the domain. Without that distinction, a team might search the wrong time window or treat historical activity as current. Also record when the intelligence was consulted. If the source revises its analysis, your team should be able to reconstruct the decision using the information available when the alert was handled. Retaining only the latest visible record does not support that review. [Correlating IP, DNS, and process evidence](/posts/investigate-ioc-alert-ip-dns-process) is the next step: after finding a match, connect the asset and process to specific events. ## Preserve relationships without inventing their meaning STIX represents intelligence as a graph of objects and relationships. The [official OASIS introduction](https://oasis-open.github.io/cti-documentation/stix/intro.html) describes this structure, which preserves the context around an indicator. Avoid flattening the entire graph into a row containing just “value, malicious.” An address shared by two reports is not enough to merge the campaigns those reports describe. An imported relationship should retain its origin, while a relationship inferred locally should be identifiable as an inference. An import contract can define three outputs: the archived raw document, fields the correlation engine can use, and items requiring review. A pattern your engine does not understand belongs in the third output. Extracting only its first domain and ignoring the other conditions would change its meaning. Test this separation with a fictional dataset containing a simple pattern, a compound pattern, and an observation that makes no threat claim. Specify which object should produce a search, which should add context, and which should await a human decision. This tests the connector's behavior, beyond its ability to parse JSON. ## Control what triggers an action For each match, have the decision engine retain four things: the Indicator used, its version, the local event, and the policy applied. This record helps explain why two alerts involving the same domain received different treatment. A production server and an analysis environment can warrant different priorities. Missing context must remain visible, however. Automatically replacing it with high confidence hides exactly what still needs to be checked. Sharing markings also deserve a dedicated step. Before redistributing an observation, establish whether endpoint names, accounts, or paths can leave your organization. A format's ability to hold a field does not mean every recipient should receive it. Keep detailed evidence in the internal case record when its distribution is not authorized. The [STIX/TAXII feed guide](/posts/stix-taxii-threat-feeds-opencti-misp-pipelines) explains where this transformation sits between the provider, intelligence platform, and SIEM. Include an acceptance test where the import succeeds but no automated action should follow. For your next alert, open an [indicator report](/report), record its dated context, and write the local observation and the analyst's conclusion separately. If those three statements cannot be distinguished in the ticket, fix the data model before adding another intelligence source. --- # Defang and Refang: Handle hxxp and IOCs Correctly URL: https://ismalicious.com/posts/defang-refang-ioc-hxxp-guide Date: 2026-10-13T07:00:00.000Z Excerpt: Share defanged IOCs while retaining usable evidence: separate display, conversion, validation and submission to external services. An IOC shared as `hxxps://portail[.]example/connexion` cannot be directly compared with the URL produced by a browser. This notation, called **defanging**, reduces accidental activation when sharing indicators. The reverse operation, **refanging**, restores a representation usable for analysis. The risk comes from implicit conversions. A tool can modify an indicator, create a clickable link or trigger a preview before the analyst has decided to contact the destination. A reliable procedure handles the received text, its conversion and any network action as separate steps. ## Retain three distinct representations First, preserve the received value exactly as it appears in the report or message. Add its source, location within the document and collection date. This version helps determine whether an error came from the producer, extraction or your own processing. Next, create a technical value intended for validation and comparison. Record its expected type, the conversion recipe and any warnings. Finally, generate a defanged display representation for tickets, notifications and documents intended for readers. These forms can look similar while serving different purposes. Copying the display form into a detection rule can prevent matching. Displaying the technical value in a tool that automatically converts URLs to links can trigger actions the author did not intend. ## Identify the convention before converting Common forms include `hxxp`, `hxxps` and `[.]` in place of a dot. Other reports use parentheses or words. Do not assume that every producer follows the same convention or that a string containing brackets is necessarily defanged. CyberChef’s [Defang URL operation](https://github.com/gchq/CyberChef/blob/master/src/core/operations/DefangURL.mjs) illustrates an implementation with defined transformations and options. Document the accepted forms for your pipeline in the same way. A precise recipe can be tested; a series of improvised replacements cannot provide the same assurance. In this fictional example, the scheme and domain separator follow an identified convention: ```text received: hxxps://portail[.]example/connexion restored: https://portail.example/connexion displayed: hxxps://portail[.]example/connexion ``` The conversion preserves the path. It does not determine whether the site is malicious, reachable or even exists. The `.example` domain is illustrative and does not represent a service to visit. ## Restrict replacements to their expected positions A global replacement of `hxxp` can affect a value in a path or parameter when only the scheme was meant to change. Globally removing brackets can break an IPv6 URL. Identify the expected structure first, then apply recognized transformations. After conversion, use a parser appropriate to the IOC type. An IP address, domain and URL cannot all be validated with the same regular expression. A relative URL does not become absolute until its base is known; do not assign a domain for convenience. A parsing failure should stop automatic export and create an explicit item for review. Do not repeatedly repair the string until the parser accepts something. That approach can manufacture an indicator different from the one originally published. The [IOC pipeline guide](/posts/building-ioc-pipelines-operational-threat-intelligence) places this validation within ingestion. Defanging remains a representation convention and must not become a threat classification. ## Keep refanging separate from network activity Text conversion can happen without a DNS query or HTTP connection. Preserve that property in your tools: disable previews on indicator fields and avoid automatic enrichment before the necessary checks. In particular, examine whether the URL contains a recipient identifier, login token or internal resource. Submission to an external service can disclose that information or cause its scanner to visit the destination. Replacing `http` with `hxxp` has removed none of those details. The guide to [scanning confidential URLs](/posts/cti-analyst-opsec-private-url-scanning) examines this sharing decision. In a routine ticket, display a defanged and, where necessary, redacted version while retaining the complete evidence in the location authorized by your policy. ## Describe the data correctly in structured exchanges An exchange format cannot infer your presentation convention. If you use STIX, the `defanged` property applies to the observable objects covered by that part of the model. The [STIX 2.1 specification](https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html) defines it for Cyber-observable Objects, defaults it to `false` and does not apply it indiscriminately to every object. Check the object actually being sent and the consumer’s expectations. Adding this field to an Indicator object that does not support it cannot replace correct encoding of the pattern. Test the export with the validator and receiving system used by your team. For a plain CSV exchange, explicitly include a type and representation state instead of expecting the recipient to guess them. A file mixing raw IPs, defanged domains and partly restored URLs needs to be identified as such before import. ## Test errors that are easy to miss Prepare positive and negative cases based on approved conventions. Check a URL that is already usable, a known defanged URL, an IPv6 address in brackets and an ambiguous string. Add links with sensitive parameters to verify how they are displayed. Applying the same conversion a second time should not continue changing an already processed value. Also test the complete path through ingestion, validation, export and import in a test environment. Correct display in the first tool does not guarantee that the second recovers the same indicator. Retain cases that caused parsing incidents, using fictional or redacted data. They form a useful test corpus when a library changes. Track converted, rejected and manually reviewed inputs separately; silent rejection hides lost intelligence. ## Base the conclusion on the value actually analyzed The case record must connect the published indicator to the validated value and the lookup performed. Record every transformation that changed its representation. If ambiguity remains, ask the producer for clarification before deploying a broad rule. For a validated public domain or IP, you can open an [IsMalicious report](/report) as a separate enrichment step. The preceding conversion performed no reputation assessment. Keeping these operations separate lets you share a readable IOC while retaining control over its interpretation and use. --- # Defang et refang : traiter hxxp et les IOC sans erreur URL: https://ismalicious.com/fr/posts/defang-refang-ioc-hxxp Date: 2026-10-13T07:00:00.000Z Excerpt: Partagez des IOC neutralisés tout en conservant une valeur exploitable : distinguez affichage, conversion, validation et soumission à un service externe. Un IOC transmis sous la forme `hxxps://portail[.]example/connexion` n’est pas directement comparable à l’URL produite par un navigateur. Cette écriture, appelée **defang**, sert à réduire les activations accidentelles lors du partage. L’opération inverse, le **refang**, restaure une représentation exploitable pour l’analyse. Le risque vient des conversions implicites. Un outil peut modifier l’indicateur, créer un lien cliquable ou déclencher une prévisualisation avant que l’analyste ait décidé de consulter la destination. Une procédure fiable traite séparément le texte reçu, la conversion et toute action réseau. ## Conserver trois représentations distinctes Gardez d’abord la valeur reçue, exactement comme elle apparaît dans le rapport ou le message. Ajoutez sa source, son emplacement dans le document et sa date de collecte. Cette version permet de vérifier si une erreur provient du producteur, de l’extraction ou de votre propre traitement. Créez ensuite une valeur technique destinée à la validation et à la comparaison. Elle porte le type attendu, la recette appliquée et les éventuels avertissements. Enfin, générez une représentation d’affichage neutralisée pour les tickets, les notifications ou les documents destinés à être lus. Ces trois formes peuvent se ressembler, mais elles remplissent des fonctions différentes. Copier celle d’affichage dans une règle de détection peut empêcher le matching. Afficher la valeur technique dans un outil qui transforme automatiquement les URL en liens peut déclencher des actions que le rédacteur n’avait pas prévues. ## Reconnaître une convention avant de convertir Les formes courantes comprennent `hxxp`, `hxxps` et `[.]` pour un point. D’autres rapports utilisent des parenthèses ou des mots. Ne supposez pas que tous les producteurs suivent la même convention, ni qu’une chaîne contenant des crochets est nécessairement neutralisée. L’opération [Defang URL de CyberChef](https://github.com/gchq/CyberChef/blob/master/src/core/operations/DefangURL.mjs) illustre une implémentation avec des transformations et options définies. Pour votre pipeline, documentez de la même façon les formes acceptées. Une recette précise se teste ; une succession de remplacements improvisés ne fournit pas cette garantie. Dans cet exemple fictif, le schéma et le séparateur du domaine suivent une convention identifiée : ```text reçu : hxxps://portail[.]example/connexion restauré : https://portail.example/connexion affiché : hxxps://portail[.]example/connexion ``` La conversion conserve le chemin. Elle ne décide pas si le site est malveillant, accessible ou même existant. Le domaine `.example` sert uniquement à l’illustration et ne représente aucun service à visiter. ## Limiter les remplacements à leur position attendue Un remplacement global de `hxxp` peut toucher une valeur dans un chemin ou un paramètre alors que seule la position du schéma devait changer. Un effacement global des crochets peut casser une URL IPv6. Repérez d’abord la structure attendue, puis appliquez les transformations reconnues. Après conversion, utilisez un parseur adapté au type d’IOC. Une adresse IP, un domaine et une URL ne se valident pas avec la même expression régulière. Une URL relative ne devient pas absolue tant que sa base n’est pas connue ; ne lui attribuez pas un domaine par commodité. Un échec de parsing doit arrêter l’export automatique et produire un état à examiner. Ne corrigez pas successivement la chaîne jusqu’à obtenir quelque chose que le parseur accepte. Cette pratique peut fabriquer un indicateur différent de celui publié. Le [guide de construction des pipelines IOC](/fr/posts/construire-pipelines-ioc-threat-intelligence-operationnelle) situe cette validation dans l’ingestion. La neutralisation, elle, reste une convention de représentation ; elle ne doit pas devenir une classification de menace. ## Séparer le refang de toute action réseau Une conversion de texte peut se faire sans requête DNS ni connexion HTTP. Gardez cette propriété dans vos outils : désactivez les prévisualisations sur les champs d’indicateurs et évitez les enrichissements automatiques avant les vérifications nécessaires. Vérifiez notamment si l’URL contient un identifiant de destinataire, un jeton de connexion ou une ressource interne. Une soumission à un service externe peut révéler cette information ou entraîner une visite par son analyseur. Remplacer `http` par `hxxp` n’a retiré aucun de ces éléments. Le guide sur l’[analyse des URL confidentielles](/fr/posts/opsec-analyste-cti-scan-url-confidentiel) détaille cette décision de partage. Dans un ticket courant, montrez une version neutralisée et expurgée si nécessaire, tout en conservant la preuve complète dans l’emplacement autorisé par votre politique. ## Décrire correctement les données dans les échanges structurés Un format d’échange ne devine pas votre convention de présentation. Si vous utilisez STIX, la propriété `defanged` concerne les objets observables concernés par le modèle. La [spécification STIX 2.1](https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html) la définit pour les Cyber-observable Objects, avec `false` comme valeur par défaut, et ne l’applique pas indistinctement à tous les objets. Vérifiez donc l’objet réellement envoyé et les attentes du consommateur. Poser ce champ sur un objet Indicator qui ne le prévoit pas ne remplace pas une stratégie d’encodage correcte du pattern. Testez l’export avec le validateur et le système destinataire utilisés par votre équipe. Lorsque vous échangez un simple CSV, ajoutez explicitement un type et un état de représentation plutôt que de demander au destinataire de les deviner. Un fichier mélangeant IP brutes, domaines neutralisés et URL partiellement restaurées doit être identifié comme tel avant import. ## Tester les erreurs qui passent inaperçues Préparez des cas positifs et négatifs à partir de conventions autorisées. Vérifiez une URL déjà exploitable, une URL neutralisée connue, une adresse IPv6 entre crochets et une chaîne ambiguë. Ajoutez les liens contenant des paramètres sensibles pour vérifier leur traitement à l’affichage. Une seconde application de la même conversion ne doit pas continuer à modifier une valeur déjà traitée. Testez aussi le trajet complet : ingestion, validation, export et import dans un environnement d’essai. Un affichage correct dans le premier outil ne garantit pas que le second retrouvera le même indicateur. Conservez les cas qui ont causé des incidents de parsing, avec des données fictives ou expurgées. Ils forment un corpus utile lors d’une mise à jour de bibliothèque. Mesurez séparément les entrées converties, rejetées et examinées manuellement ; les rejets silencieux cachent les pertes de renseignement. ## Conclure sur la valeur réellement analysée Le dossier doit permettre de relier l’indicateur publié à la valeur validée puis à la recherche réalisée. Notez toute transformation qui a changé sa représentation. Si une ambiguïté demeure, demandez une clarification au producteur avant de déployer une règle large. Pour un domaine ou une IP publique validée, vous pouvez ouvrir un [rapport IsMalicious](/fr/report) comme étape distincte d’enrichissement. La conversion préalable n’a effectué aucune vérification de réputation. C’est cette séparation qui permet de partager un IOC lisible tout en gardant le contrôle sur son interprétation et son utilisation. --- # Normalisation URL : éviter les erreurs de matching IOC URL: https://ismalicious.com/fr/posts/normalisation-url-correspondance-ioc Date: 2026-10-12T07:00:00.000Z Excerpt: Comparez les URL sans perdre les preuves : casse, encodage, paramètres et fragments demandent des règles explicites et des tests de non-correspondance. Deux chaînes différentes peuvent représenter la même destination, et deux URL visuellement proches peuvent désigner des ressources différentes. Pour un moteur de correspondance IOC, la **normalisation URL** doit réduire les différences justifiées sans effacer celles qui comptent pour l’enquête. Une règle trop stricte manque des correspondances. Une règle trop agressive associe des événements sans lien. Le travail consiste à définir une égalité adaptée au contrôle utilisé, puis à conserver la chaîne brute qui permet d’expliquer chaque décision. ## Définir ce qui doit correspondre Commencez par nommer la portée de votre indicateur. Un domaine, une origine composée d’un schéma, d’un hôte et d’un port, une URL complète et un préfixe de chemin ne représentent pas la même règle. Ne réduisez pas silencieusement un IOC URL à son domaine pour faciliter l’indexation. Précisez aussi la donnée disponible dans votre capteur. Un journal DNS ne voit pas le chemin HTTP. Un proxy peut ne conserver qu’une partie de la requête. Un navigateur peut produire une URL déjà transformée. Le moteur doit comparer des champs effectivement observés, sans reconstituer les morceaux manquants comme s’ils étaient certains. Cette étape complète le [pipeline général de gestion des IOC](/fr/posts/construire-pipelines-ioc-threat-intelligence-operationnelle). Ici, la question est plus étroite : quelles transformations permettent de dire que deux observations correspondent au même indicateur ? ## Garder la preuve et la clé de comparaison séparées Stockez au minimum la valeur brute, sa source, l’heure, la valeur destinée à la comparaison et la version du normaliseur. Conservez également le résultat du parsing et les avertissements. Une entrée rejetée doit rester explicable, avec les contrôles de confidentialité adaptés. La clé calculée sert à la recherche. La valeur brute permet de comprendre une erreur, de rejouer une conversion et de distinguer une transformation du producteur d’une transformation de votre plateforme. Sans cette séparation, modifier le normaliseur réécrit implicitement l’histoire de vos observations. N’incluez pas automatiquement l’URL entière dans tous les journaux de diagnostic. Les paramètres peuvent contenir un jeton ou une adresse personnelle. Prévoyez une conservation restreinte de la preuve et une version expurgée pour les vues courantes, sans prétendre que ces deux formes sont identiques. ## Traiter la casse composant par composant La [RFC 3986, section 6](https://www.rfc-editor.org/rfc/rfc3986.html#section-6), distingue plusieurs formes de comparaison et de normalisation. Le schéma et l’hôte ne se traitent pas comme tous les autres composants. Transformer globalement la chaîne en minuscules peut modifier le chemin ou des données de requête. Les exemples suivants sont fictifs et utilisent un domaine réservé : ```text https://PORTAIL.EXAMPLE/Compte?id=AbC https://portail.example/Compte?id=AbC https://portail.example/compte?id=abc ``` Les deux premières formes ne diffèrent que par la casse de l’hôte. La troisième modifie aussi le chemin et la valeur du paramètre. Votre moteur ne doit pas les fusionner sur la simple intuition que « les URL ne sont pas sensibles à la casse ». Pour les noms internationalisés, utilisez la même bibliothèque et la même convention des deux côtés de la comparaison. Gardez les représentations utiles à l’analyste, mais ne confondez pas ressemblance visuelle et égalité technique du nom. ## Résister aux décodages successifs L’encodage en pourcentage est un point sensible. Décoder une fois pour faciliter l’affichage, puis une seconde fois avant le matching, peut changer la valeur comparée. Les caractères réservés et les séparateurs ne doivent pas être transformés sans tenir compte de leur rôle. Comparez ces deux chemins fictifs : ```text https://portail.example/fichiers/a%2Fb https://portail.example/fichiers/a/b ``` Ils ne sont pas interchangeables par défaut. Le premier contient un séparateur encodé dont le traitement dépend aussi de la chaîne serveur. Conservez cette distinction tant que votre politique n’a pas établi précisément l’équivalence recherchée. Séparez de même le décodage HTML d’un lien extrait d’un message et le parsing de son URL. `&` peut provenir du document qui contenait le lien. Appliquer aveuglément cette conversion à une chaîne déjà extraite introduit une autre transformation. Notez à quelle couche chaque opération appartient. ## Ne pas réécrire arbitrairement la requête et le fragment Trier les paramètres paraît faciliter la déduplication. Pourtant, une application peut interpréter leur ordre ou des clés répétées. Une signature applicative peut également dépendre de la représentation transmise. Préservez l’ordre tant que l’équivalence n’est pas documentée pour votre usage. Le fragment, après `#`, appartient à la représentation de l’URL et peut servir au fonctionnement côté client. Un journal de requête HTTP ne l’observe généralement pas. Votre politique doit dire si elle compare une navigation complète ou une cible transmise au serveur. Le [standard URL de WHATWG](https://url.spec.whatwg.org/) décrit les opérations de parsing et de sérialisation utilisées pour les URL web. Choisissez un parseur dont le comportement correspond à votre source, puis vérifiez les cas limites. Mélanger plusieurs parseurs à des étapes successives peut produire des résultats différents sur une entrée ambiguë. ## Constituer un corpus qui protège contre les fusions abusives Préparez deux familles de tests : les paires qui doivent correspondre et celles qui doivent rester distinctes. Chaque cas doit indiquer la portée du matching et la raison de la décision. Un test positif seul ne détectera jamais une normalisation qui transforme toutes les URL d’un domaine en une même clé. | Cas fictif | Décision à expliciter | | --------------------------- | --------------------------------------------- | | Hôte en majuscules | Normalisation du nom avec le parseur choisi | | `/Compte` et `/compte` | Distinction conservée sauf contrat spécifique | | `a=1&a=2` et `a=2&a=1` | Ordre conservé par défaut | | `%2F` et `/` dans un chemin | Pas de fusion automatique | | Fragment absent du journal | Ne pas inventer sa valeur | Ajoutez les données mal formées, les ports explicites et les URL relatives. Une URL relative exige une base connue ; lui ajouter arbitrairement un domaine produit un indicateur inventé. Réexécutez le corpus à chaque changement de bibliothèque ou de règles. ## Expliquer une alerte avec la transformation exacte Lorsqu’un événement correspond, affichez la portée de la règle et les transformations appliquées. L’analyste doit pouvoir comprendre si le résultat vient d’une égalité exacte, d’une normalisation limitée ou d’une règle plus large au niveau domaine. Avant toute consultation externe, examinez les données sensibles selon le guide sur les [URL suspectes et redirections](/fr/posts/url-suspecte-verifier-redirections). Vous pouvez ensuite consulter un [rapport sur l’indicateur public pertinent](/fr/report), en gardant séparée l’URL originale si elle contient des secrets. Une bonne conclusion décrit ce qui correspond réellement. « Même domaine » et « même URL observée » demandent des actions différentes. Votre normaliseur doit permettre de conserver cette différence jusque dans la décision finale. --- # URL Normalization: Avoid Incorrect IOC Matches URL: https://ismalicious.com/posts/url-normalization-ioc-matching Date: 2026-10-12T07:00:00.000Z Excerpt: Compare URLs while preserving evidence: case, encoding, parameters and fragments need explicit rules and tests for values that must stay distinct. Two different strings can represent the same destination, while two visually similar URLs can identify different resources. For an IOC matching engine, **URL normalization** must remove justified differences without erasing distinctions that matter to the investigation. An overly strict rule misses matches. An overly aggressive rule connects unrelated events. The task is to define equality for the control being used, then preserve the raw string needed to explain each decision. ## Define what must match Start by naming the scope of the indicator. A domain, an origin consisting of a scheme, host and port, a complete URL and a path prefix represent different rules. Do not silently reduce a URL IOC to its domain to simplify indexing. Specify what data the sensor actually provides. A DNS log cannot see an HTTP path. A proxy might retain only part of a request. A browser can produce an already transformed URL. The engine must compare observed fields without filling in missing pieces as though they were known. This step complements the wider [IOC management pipeline](/posts/building-ioc-pipelines-operational-threat-intelligence). The question here is narrower: which transformations justify treating two observations as a match for the same indicator? ## Keep evidence separate from the comparison key Store at least the raw value, source, timestamp, comparison value and normalizer version. Also retain the parsing result and warnings. A rejected entry must remain explainable, subject to appropriate confidentiality controls. The calculated key supports searches. The raw value helps explain an error, replay a conversion and distinguish a producer’s transformation from one performed by your platform. Without this separation, changing the normalizer implicitly rewrites the history of your observations. Do not automatically copy complete URLs into every diagnostic log. Parameters can contain a token or a personal address. Provide restricted storage for the evidence and a redacted version for everyday views, without treating the two representations as identical. ## Handle case one component at a time [RFC 3986, section 6](https://www.rfc-editor.org/rfc/rfc3986.html#section-6), distinguishes several forms of comparison and normalization. The scheme and host are handled differently from other components. Lowercasing the entire string can change a path or query data. The following fictional examples use a reserved domain: ```text https://PORTAIL.EXAMPLE/Compte?id=AbC https://portail.example/Compte?id=AbC https://portail.example/compte?id=abc ``` The first two forms differ only in hostname case. The third also changes the path and parameter value. Your engine must not merge them based on an assumption that “URLs are case-insensitive.” For internationalized names, use the same library and convention on both sides of the comparison. Preserve representations useful to the analyst, but keep visual similarity distinct from technical equality of the name. ## Avoid successive decoding Percent encoding needs particular care. Decoding once for display and a second time before matching can change the value being compared. Reserved characters and separators must be transformed with their role in mind. Compare these two fictional paths: ```text https://portail.example/fichiers/a%2Fb https://portail.example/fichiers/a/b ``` They are not interchangeable by default. The first contains an encoded separator whose treatment also depends on the server chain. Preserve that distinction until your policy establishes precisely which equivalence it intends to recognize. Similarly, separate HTML decoding of a link extracted from a message from parsing the URL itself. `&` can come from the document containing the link. Blindly applying this conversion to an already extracted string adds another transformation. Record which layer each operation belongs to. ## Preserve query and fragment semantics Sorting parameters can appear to simplify deduplication. However, an application can interpret their order or repeated keys. An application signature can also depend on the transmitted representation. Preserve order unless equivalence is documented for your specific use. The fragment after `#` is part of the URL representation and can affect client-side behavior. An HTTP request log generally does not observe it. Your policy must specify whether it compares a complete navigation URL or a target sent to the server. The [WHATWG URL Standard](https://url.spec.whatwg.org/) describes parsing and serialization operations for web URLs. Choose a parser whose behavior matches your source, then test edge cases. Mixing several parsers in successive stages can produce different results for an ambiguous input. ## Build a test corpus that catches false equivalence Prepare two groups of tests: pairs that must match and pairs that must remain distinct. Each case should state the matching scope and reason for the decision. A positive test alone will never catch normalization that turns every URL on a domain into the same key. | Fictional case | Decision to specify | | ---------------------------- | ----------------------------------------------------------------- | | Uppercase hostname | Normalize the name using the chosen parser | | `/Compte` and `/compte` | Preserve the difference unless a specific contract says otherwise | | `a=1&a=2` and `a=2&a=1` | Preserve order by default | | `%2F` and `/` in a path | No automatic merging | | Fragment absent from the log | Do not invent its value | Include malformed data, explicit ports and relative URLs. A relative URL requires a known base; arbitrarily attaching a domain invents an indicator. Rerun the corpus whenever the library or normalization rules change. ## Explain an alert using the exact transformation When an event matches, show the rule’s scope and the transformations applied. The analyst needs to distinguish exact equality, limited normalization and a broader domain-level rule. Before an external lookup, examine sensitive data using the guide to [suspicious URLs and redirects](/posts/suspicious-url-check-redirects). You can then consult a [report on the relevant public indicator](/report), preserving the original URL separately if it contains secrets. A useful conclusion states what actually matched. “Same domain” and “same observed URL” call for different actions. Your normalizer must preserve that distinction through to the final decision. --- # IP Allowlists: Control the Scope of CIDR Ranges URL: https://ismalicious.com/posts/ip-allowlist-cidr-security Date: 2026-10-11T07:00:00.000Z Excerpt: Verify an IP exception’s scope, test CIDR boundaries and IPv6, then document its owner, review date and conditions for removal. An exception request arrives: “Allow this IP so the integration works.” The risk often lies in the scope being added. A single address becomes a CIDR block, followed by a blanket exception that disables more controls than intended. An **IP allowlist** should describe who can reach which service, through which control and for how long. The following procedure turns an imprecise request into a verifiable rule, with tests that catch incorrect masks and unnecessarily broad permissions. ## Define exactly what the exception bypasses Before selecting a prefix, identify the control involved. Allowing a connection through a firewall, bypassing a WAF rule and excluding an event from the SIEM are three different decisions. A failure on one application route does not justify suppressing every alert associated with the address. Record the destination service, protocol, port and, where the product supports it, the affected path or operation. Add the integration owner and evidence of the requirement: a blocked event, outbound configuration or technical documentation from the provider. Also verify that the IP corresponds to the source actually observed by the control. Behind a proxy, an address obtained from an untrusted header can undermine the entire allowlist. The requester’s identity and the network origin need separate verification. ## Calculate the scope before accepting it CIDR notation combines an address with a prefix length. For IPv4, `/32` represents one address and `/24` represents 256. [RFC 4632](https://www.rfc-editor.org/rfc/rfc4632.html) describes this prefix model and aggregation. A shorter prefix covers more addresses. This fictional example uses a block reserved for documentation: | Request | Effective scope | | --------------- | --------------------------------- | | `192.0.2.64/32` | One address | | `192.0.2.64/28` | `192.0.2.64` through `192.0.2.79` | | `192.0.2.0/24` | `192.0.2.0` through `192.0.2.255` | These ranges are not interchangeable. Establish why each covered address needs access. A range announced by a provider can host other customers. Its association with the same organization does not mean that every workload within it should reach your service. Apply the same discipline to IPv6. A `/128` represents one address, while a network prefix can cover a vast set. Do not carry assumptions about IPv4 mask sizes over to an IPv6 address. ## Reject ambiguous input instead of silently correcting it Use a network address library to validate input and calculate boundaries. A text comparison such as “starts with 192.0.2” is not a CIDR check. It handles neither masks nor IPv6 formats correctly. Python’s [ipaddress module](https://docs.python.org/3/library/ipaddress.html) provides address and network objects. With `strict=True`, it rejects a network definition whose host bits are still set. This helps expose a poorly specified request before it becomes a rule. ```python from ipaddress import ip_address, ip_network # Fictional range reserved for documentation. network = ip_network("192.0.2.64/28", strict=True) for candidate in ("192.0.2.63", "192.0.2.64", "192.0.2.79", "192.0.2.80"): print(candidate, ip_address(candidate) in network) ``` The expected results are `False`, `True`, `True`, `False`. This verifies mathematical membership in the block, including its boundaries. It does not describe which addresses can be assigned to hosts in every architecture or the exact behavior of your firewall. If someone supplies `192.0.2.70/28`, do not silently replace it with `192.0.2.64/28`. Show the resulting network and resolve the ambiguity in the request. The intended exception might have been for one address only. ## Test the rule in the product that enforces it The local calculation is an initial check. Then test the actual configuration in a suitable environment: an allowed source, a source just outside the range and a path that should receive no exception. Check rule ordering and the action actually applied. Include IPv6 if the service accepts it. A policy covering only IPv4 can leave a different access path. Also define how to handle IPv4 addresses represented in IPv6 form when your components produce them. The parser and rule engine need to share that convention. Capture a rule identifier in the logs. A successful test must show why the request was permitted. Otherwise, a broader existing rule can conceal a defect in the new configuration and give a misleading impression that it was validated. ## Retain the other security controls An expected network origin does not authenticate an account or guarantee how a request behaves. Keep the keys, signatures, certificates and application controls required for the integration. Limit the exception to the condition that was actually blocking legitimate traffic. When an allowed address appears in threat intelligence, open a review. The [reputation and context of a datacenter IP](/posts/proxy-vpn-tor-datacenter-ip-detection) help explain the observation without automatically extending a block to every use of that provider. Likewise, a good current reputation does not justify permanent access. The request must rest on a known access requirement. An external score is evidence for the decision; it cannot take responsibility for owning the rule. ## Plan removal when the rule is created Add a review date, owner and removal condition. For a provider with changing published ranges, define who monitors changes, how their origin is verified and how differences are tested before being applied. Retain the previous version to support a controlled rollback. When an integration ends, remove its exception and confirm that no expected traffic still depends on it. The principles for [reviewing IOC-based rules](/posts/ioc-expiration-remove-ip-blocklist) also apply to this maintenance discipline. The final record should contain the request, exact network, boundary tests, retained controls and owner. If a public address warrants further investigation, consult its [reputation report](/report) and timestamp the observation. The authorization will then remain explainable after a change of team or provider. --- # Liste d’autorisation IP : maîtriser les plages CIDR URL: https://ismalicious.com/fr/posts/liste-autorisation-ip-cidr-securite Date: 2026-10-11T07:00:00.000Z Excerpt: Vérifiez le périmètre d’une exception IP, testez les bornes CIDR et IPv6, puis documentez le propriétaire, la durée et le retrait de l’autorisation. Une demande d’exception arrive : « Autorisez cette IP pour que l’intégration fonctionne ». Le risque se trouve souvent dans le périmètre ajouté. Une seule adresse devient un bloc CIDR, puis une exception globale qui désactive davantage de contrôles que prévu. Une **liste d’autorisation IP** doit décrire qui peut atteindre quel service, à travers quel contrôle et pour quelle durée. Voici comment transformer une demande imprécise en règle vérifiable, avec des tests qui détectent les erreurs de masque et les autorisations trop larges. ## Définir exactement ce que l’exception contourne Avant de choisir le préfixe, identifiez le contrôle concerné. Autoriser une connexion au pare-feu, ignorer une règle WAF et exclure un événement du SIEM sont trois décisions différentes. Une panne sur une route applicative ne justifie pas de supprimer toutes les alertes associées à l’adresse. Consignez le service destinataire, le protocole, le port et, si le produit le permet, le chemin ou l’opération concernés. Ajoutez le propriétaire de l’intégration et la preuve du besoin : événement bloqué, configuration de sortie ou documentation technique du fournisseur. Vérifiez aussi que l’IP correspond à la source réellement observée par le contrôle. Derrière un proxy, une adresse issue d’un en-tête non fiable peut faire perdre toute valeur à la liste. L’identité du demandeur et l’origine réseau doivent être contrôlées séparément. ## Calculer le périmètre avant de l’accepter La notation CIDR associe une adresse à une longueur de préfixe. Pour IPv4, un `/32` représente une adresse et un `/24` en représente 256. La [RFC 4632](https://www.rfc-editor.org/rfc/rfc4632.html) décrit ce modèle de préfixes et leur agrégation. Un préfixe plus court couvre davantage d’adresses. Voici un cas fictif utilisant un bloc réservé à la documentation : | Demande | Périmètre effectif | | --------------- | ------------------------------ | | `192.0.2.64/32` | Une adresse | | `192.0.2.64/28` | De `192.0.2.64` à `192.0.2.79` | | `192.0.2.0/24` | De `192.0.2.0` à `192.0.2.255` | Ces plages ne sont pas interchangeables. Demandez ce qui justifie chaque adresse couverte. Une plage annoncée par un fournisseur peut héberger d’autres clients ; son appartenance à la même organisation n’implique pas que tous ses usages doivent accéder à votre service. Pour IPv6, conservez la même discipline. Un `/128` représente une adresse, tandis qu’un préfixe réseau peut couvrir un ensemble considérable. N’appliquez pas intuitivement une taille de masque IPv4 à une adresse IPv6. ## Refuser les entrées ambiguës plutôt que les corriger en silence Utilisez une bibliothèque d’adresses réseau pour valider les entrées et calculer les bornes. Une comparaison textuelle du type « commence par 192.0.2 » ne constitue pas un contrôle CIDR. Elle ne gère correctement ni les masques, ni les formats IPv6. Le module Python [ipaddress](https://docs.python.org/3/library/ipaddress.html) fournit des objets d’adresse et de réseau. Avec `strict=True`, il refuse notamment une définition de réseau dont les bits d’hôte sont encore positionnés. Ce comportement aide à repérer une demande mal formulée avant sa conversion en règle. ```python from ipaddress import ip_address, ip_network # Plage fictive, réservée à la documentation. network = ip_network("192.0.2.64/28", strict=True) for candidate in ("192.0.2.63", "192.0.2.64", "192.0.2.79", "192.0.2.80"): print(candidate, ip_address(candidate) in network) ``` Le résultat attendu est `False`, `True`, `True`, `False`. Il vérifie l’appartenance mathématique au bloc, y compris ses bornes. Il ne décrit pas les adresses attribuables à des hôtes dans chaque architecture, ni le comportement exact de votre pare-feu. Si quelqu’un fournit `192.0.2.70/28`, ne remplacez pas discrètement cette entrée par `192.0.2.64/28`. Présentez le réseau résultant et faites résoudre l’ambiguïté dans la demande. L’intention pouvait être une seule adresse. ## Tester la règle dans le produit qui l’applique Le calcul local est une première vérification. Testez ensuite la configuration réelle dans un environnement adapté : une source autorisée, une source juste hors plage et un chemin qui ne doit bénéficier d’aucune exception. Vérifiez également l’ordre des règles et l’action effectivement appliquée. Incluez IPv6 si le service l’accepte. Une politique contrôlant seulement IPv4 peut laisser un chemin différent. Définissez aussi le traitement des adresses IPv4 représentées sous une forme IPv6 lorsque vos composants les produisent ; le parseur et le moteur de règles doivent partager cette convention. Relevez un identifiant de règle dans les journaux. Un test réussi doit montrer pourquoi la requête a été autorisée. Sinon, une autre règle plus générale peut masquer un défaut de la nouvelle configuration et donner une impression trompeuse de validation. ## Conserver les autres contrôles de sécurité Une origine réseau attendue n’authentifie pas un compte et ne garantit pas le comportement d’une requête. Gardez les clés, signatures, certificats ou contrôles applicatifs prévus pour l’intégration. Limitez l’exception au motif qui bloquait réellement le trafic légitime. Lorsqu’une adresse autorisée apparaît dans un renseignement de menace, ouvrez une réévaluation. La [réputation et le contexte d’une IP de datacenter](/fr/posts/detection-proxy-vpn-tor-ip-datacenter-waf-siem) servent à comprendre l’observation, sans élargir automatiquement le blocage à tous les usages du fournisseur. À l’inverse, une bonne réputation actuelle ne justifie pas une autorisation permanente. La demande doit reposer sur un besoin d’accès connu. Le score externe est une pièce du dossier, pas le propriétaire de la règle. ## Prévoir le retrait dès la création Ajoutez une date de révision, un responsable et une condition de suppression. Pour un prestataire qui publie des plages variables, définissez qui surveille les changements, comment leur origine est vérifiée et comment les différences sont testées avant application. Conservez la version précédente pour permettre un retour contrôlé. Lorsqu’une intégration s’arrête, retirez son exception et vérifiez qu’aucun flux attendu n’en dépend encore. Les principes de [réévaluation des règles fondées sur des IOC](/fr/posts/expiration-ioc-retirer-ip-blocklist) s’appliquent aussi à cette discipline de maintenance. Le dossier final doit contenir la demande, le réseau exact, les tests aux bornes, les contrôles conservés et le propriétaire. Si une adresse publique mérite un examen complémentaire, consultez son [rapport de réputation](/fr/report) et datez cette observation. Une autorisation restera ainsi explicable même après un changement d’équipe ou de fournisseur. --- # X-Forwarded-For : retrouver une IP client fiable URL: https://ismalicious.com/fr/posts/x-forwarded-for-ip-client-fiable Date: 2026-10-10T07:00:00.000Z Excerpt: Identifiez l’IP à enrichir derrière vos proxys en définissant les relais de confiance, puis testez les en-têtes forgés et les accès directs. Une vérification de réputation est inutile si elle porte sur l’adresse de votre propre reverse proxy ou sur une IP choisie par le client. Avant d’exploiter **X-Forwarded-For** dans un WAF, un limiteur de requêtes ou un SIEM, il faut établir qui a fourni chaque partie de cette chaîne. L’objectif est d’obtenir une adresse attribuable au trajet réseau observé. Cela ne transforme pas cette adresse en identité personnelle : un VPN, une passerelle ou un réseau partagé peuvent toujours regrouper plusieurs utilisateurs derrière elle. ## Partir du pair réseau réellement connecté Le serveur reçoit une connexion depuis un pair immédiat. Lorsque ce pair est votre reverse proxy, il connaît directement son adresse ; il ne connaît pas directement celle du navigateur. L’en-tête transmis par le proxy apporte une déclaration supplémentaire, dont la valeur dépend de votre architecture. Inventoriez chaque chemin vers l’application : CDN, répartiteur, ingress, proxy interne, accès de supervision et éventuel accès direct à l’origine. Pour chacun, documentez le pair attendu, le traitement des en-têtes entrants et la manière dont le relais ajoute l’adresse qu’il observe. Un en-tête normalisé ne résout pas seul cette question. La [RFC 7239, section 8.1](https://www.rfc-editor.org/rfc/rfc7239.html#section-8.1), rappelle que les informations `Forwarded` peuvent être modifiées par les intermédiaires ou le client. Le choix entre `Forwarded` et `X-Forwarded-For` ne dispense donc pas de définir la confiance. ## Dessiner la frontière où la déclaration devient fiable Choisissez le composant d’entrée qui est chargé de nettoyer ou reconstruire les informations de provenance. Ce choix doit correspondre à sa configuration réelle. Un proxy qui conserve aveuglément un en-tête client ne lui donne pas une origine fiable simplement parce qu’il l’a transmis. Les relais suivants doivent n’accepter ces informations que depuis leurs prédécesseurs autorisés. Définissez cette confiance avec des adresses ou des plages contrôlées et un chemin réseau protégé. Une liste couvrant tous les réseaux privés peut être trop large si d’autres charges y sont capables d’atteindre l’application. Vérifiez surtout que l’origine ne peut pas être jointe par un chemin qui évite l’entrée prévue. Sinon, un client peut fournir directement les en-têtes que l’application attribue normalement au proxy. Le problème est architectural, même si le parseur d’adresses fonctionne correctement. ## Lire la chaîne depuis le côté connu Dans un schéma où les proxys fiables ajoutent correctement le pair qu’ils voient, la lecture part du pair immédiat, puis remonte les valeurs depuis la droite. Elle s’arrête à la première adresse qui n’appartient pas à un relais de confiance. Les valeurs situées plus loin ne gagnent pas de fiabilité par leur seule position. La [documentation du module realip de Nginx](https://nginx.org/en/docs/http/ngx_http_realip_module.html) décrit cette sélection lorsque `real_ip_recursive` est activé : le module utilise la dernière adresse non fiable de la chaîne, après vérification de l’adresse d’origine contre les relais configurés. La configuration précise reste liée au trajet que vous avez vérifié. Considérez cet exemple fictif, composé uniquement d’adresses de documentation : ```text pair immédiat : 192.0.2.10 (proxy interne fiable) X-Forwarded-For : 203.0.113.66, 198.51.100.24, 192.0.2.20 ↑ proxy d’entrée fiable ``` Si `192.0.2.20` a ajouté `198.51.100.24` comme pair réellement observé, cette dernière adresse est la candidate utile. `203.0.113.66`, située plus à gauche, peut avoir été fournie par le client. Prendre systématiquement la première valeur attribuerait la requête à une déclaration non vérifiée. ## Utiliser un parseur adapté aux formats reçus Ne découpez pas chaque adresse sur le caractère `:` : IPv6 en contient. Vérifiez également les en-têtes répétés, les espaces, les ports éventuels et les valeurs invalides selon les conventions effectivement émises par vos proxys. `Forwarded` possède une syntaxe distincte ; il ne se traite pas comme une simple liste XFF. Définissez une seule méthode de sélection utilisée par la journalisation, la limitation de débit et l’enrichissement. Si trois composants appliquent trois règles, un même événement peut être associé à des IP différentes. Une alerte devient alors difficile à reproduire, même avec tous les journaux disponibles. Conservez une issue explicite pour les valeurs inexploitables. Un parseur qui échoue ne doit pas inventer une adresse, réutiliser silencieusement celle d’une requête précédente ou choisir un autre en-tête non fiable. Le journal doit permettre de comprendre pourquoi l’attribution a échoué. ## Tester la confiance, pas seulement le cas nominal En environnement autorisé, envoyez des requêtes de test sur chaque chemin prévu. Utilisez des IP fictives dans les en-têtes contrôlés pour distinguer clairement ce qui provient du client de ce qui a été ajouté par votre infrastructure. | Test | Résultat à vérifier | | ---------------------------------- | ------------------------------------------------------- | | Client sans XFF | Adresse observée à l’entrée correctement retenue | | Client avec une fausse première IP | Valeur forgée non utilisée comme identité fiable | | En-têtes répétés ou mal formés | Traitement défini et journalisé | | Origine jointe directement | Accès refusé ou en-têtes non réputés fiables | | Chemin alternatif plus court | Sélection correcte malgré un nombre de relais différent | Le dernier cas expose les configurations qui font confiance à un nombre fixe de sauts alors que plusieurs trajets existent. Répétez ces tests après un changement de CDN, d’ingress ou de routage. La politique de confiance évolue avec le réseau. ## Enrichir l’adresse retenue avec son contexte Journalisez le pair réseau, l’adresse retenue, la méthode utilisée et un identifiant de requête. La conservation de l’en-tête brut doit suivre votre politique d’accès et de rétention, car il peut contenir des données non fiables ou superflues. Rendez ces champs distincts dans le SIEM. Vous pouvez ensuite appliquer les [critères de réputation et de type d’IP](/fr/posts/detection-proxy-vpn-tor-ip-datacenter-waf-siem), puis consulter un [rapport IP](/fr/report) lorsque l’enquête le justifie. Ne qualifiez pas l’adresse de votre CDN comme celle de l’attaquant simplement parce qu’elle apparaît dans le journal de connexion. Enfin, rapprochez l’IP des événements applicatifs : compte, session, ressource demandée et résultat. Le [guide d’enrichissement IOC pour le SOC](/fr/posts/apis-enrichissement-ioc-triage-soc-faux-positifs) apporte le contexte externe. La provenance de l’adresse reste une preuve que votre propre chaîne de proxys doit fournir. --- # X-Forwarded-For: Identify a Trusted Client IP URL: https://ismalicious.com/posts/x-forwarded-for-trusted-client-ip Date: 2026-10-10T07:00:00.000Z Excerpt: Choose the right IP to enrich behind proxies by defining trusted relays, then test forged headers, malformed values and direct origin access. A reputation lookup is of little use if it targets your own reverse proxy’s address or an IP chosen by the client. Before using **X-Forwarded-For** in a WAF, rate limiter or SIEM, establish who supplied each part of the chain. The objective is to obtain an address supported by the observed network path. That does not turn the address into a personal identity: a VPN, gateway or shared network can still place several users behind it. ## Start with the peer that actually connected The server receives a connection from an immediate peer. When that peer is your reverse proxy, the server directly knows its address; it does not directly know the browser’s address. The header forwarded by the proxy supplies an additional assertion whose value depends on your architecture. Inventory every path to the application: CDN, load balancer, ingress, internal proxy, monitoring access and any direct access to the origin. For each path, document the expected peer, treatment of incoming headers and how the relay adds the address it observes. A standardized header does not settle this question by itself. [RFC 7239, section 8.1](https://www.rfc-editor.org/rfc/rfc7239.html#section-8.1), explains that intermediaries or the client can modify `Forwarded` information. Choosing between `Forwarded` and `X-Forwarded-For` therefore does not remove the need to define trust. ## Define where provenance becomes trustworthy Choose the entry component responsible for cleaning or reconstructing provenance information. That choice must match its actual configuration. A proxy that blindly preserves a client header does not establish its origin merely by forwarding it. Subsequent relays must accept this information only from their authorized predecessors. Define trust using controlled addresses or ranges and a protected network path. Trusting every private network can be too broad if other workloads on those networks can reach the application. In particular, verify that the origin cannot be reached through a path that bypasses the intended entry point. Otherwise, a client can directly supply headers that the application normally attributes to the proxy. This is an architectural problem even when the address parser works correctly. ## Read the chain from the known end In a topology where trusted proxies correctly append the peer they observe, selection starts with the immediate peer and then works through header values from right to left. It stops at the first address that is not a trusted relay. Values farther to the left do not become trustworthy simply because of their position. The [Nginx realip module documentation](https://nginx.org/en/docs/http/ngx_http_realip_module.html) describes this selection when `real_ip_recursive` is enabled. After checking the original address against the configured trusted relays, the module uses the last non-trusted address in the chain. The exact configuration must still match the path you verified. Consider this fictional example, which uses only documentation addresses: ```text immediate peer: 192.0.2.10 (trusted internal proxy) X-Forwarded-For: 203.0.113.66, 198.51.100.24, 192.0.2.20 ↑ trusted entry proxy ``` If `192.0.2.20` appended `198.51.100.24` as the peer it actually observed, the latter is the useful candidate. `203.0.113.66`, farther to the left, could have been supplied by the client. Always taking the first value would attribute the request using an unverified assertion. ## Use a parser suited to the received formats Do not split every address on `:` because IPv6 addresses contain colons. Also check repeated headers, whitespace, possible ports and invalid values against the conventions your proxies actually emit. `Forwarded` has its own syntax and cannot be handled as a simple XFF list. Define one selection method shared by logging, rate limiting and enrichment. If three components apply three different rules, the same event can be associated with different IPs. An alert then becomes difficult to reproduce even when all the logs are available. Specify an explicit outcome for unusable values. A failing parser must not invent an address, silently reuse one from an earlier request or select another untrusted header. The log should make it possible to understand why attribution failed. ## Test the trust policy as well as the normal path In an authorized environment, send test requests through every intended path. Use fictional IPs in the headers you control so you can distinguish client input from values added by your infrastructure. | Test | Result to verify | | -------------------------------- | ------------------------------------------------------------- | | Client without XFF | The address observed at the entry point is selected correctly | | Client supplies a false first IP | The forged value is not used as a trusted identity | | Repeated or malformed headers | Handling is defined and logged | | Origin reached directly | Access is denied or supplied headers are not trusted | | Shorter alternative path | Selection remains correct with a different number of relays | The last case exposes configurations that trust a fixed number of hops despite having several possible paths. Repeat these tests after changing a CDN, ingress or route. The trust policy must follow the network as it changes. ## Enrich the selected address with its context Log the network peer, selected address, selection method and a request identifier. Retaining the raw header must follow your access and retention policies because it can contain untrusted or unnecessary data. Keep these fields separate in the SIEM. You can then apply [IP reputation and IP type criteria](/posts/proxy-vpn-tor-datacenter-ip-detection) and consult an [IP report](/report) when the investigation warrants it. Do not label your CDN’s address as the attacker’s address simply because it appears in a connection log. Finally, correlate the IP with application events: account, session, requested resource and outcome. The [SOC guide to IOC enrichment](/posts/ioc-enrichment-api-security-operations-guide) supplies external context. Evidence of the address’s provenance still has to come from your own proxy chain. --- # DNSSEC et SERVFAIL : trouver la cause de l’échec URL: https://ismalicious.com/fr/posts/dnssec-servfail-diagnostic Date: 2026-10-09T07:00:00.000Z Excerpt: Diagnostiquez un SERVFAIL avec les erreurs DNS détaillées, la chaîne DS/DNSKEY et les signatures, puis vérifiez la réparation sans désactiver DNSSEC. Un **SERVFAIL** est un échec de résolution, pas un diagnostic complet. Lorsqu’un domaine fonctionne sur certains réseaux mais échoue sur d’autres, DNSSEC fait partie des pistes : un résolveur validant peut refuser des données que d’autres retournent. Il faut toutefois établir cette cause avant de modifier une zone ou les réglages des clients. La procédure suivante concerne un domaine public que vous administrez ou dont vous pouvez examiner les données publiques. Les noms en `.example` et les adresses de documentation sont fictifs. Remplacez-les par les éléments autorisés de votre environnement, sans soumettre de noms internes à des outils publics. ## Conserver l’échec avant toute modification Commencez avec le nom exact et le type de requête concerné. Une application peut échouer sur un sous-domaine ou sur une cible de CNAME alors que le domaine principal répond. Notez l’heure, le résolveur, le réseau client et le statut complet. Capturez les réponses avec leurs options et sections, sans vous limiter à la présence d’une adresse. Gardez aussi un nom de contrôle connu pour fonctionner sur le même chemin. Si toutes les requêtes échouent, la panne doit être cherchée plus largement avant de cibler une signature particulière. ```sh # Exemples fictifs : résolveur et domaine de documentation dig @192.0.2.53 portail.service.example. A +dnssec dig @192.0.2.53 portail.service.example. AAAA +dnssec ``` L’option `+dnssec` demande les données DNSSEC disponibles. Elle ne transforme pas `dig` en validateur complet de la chaîne. Un enregistrement RRSIG visible constitue une donnée à examiner, pas une preuve automatique de validation réussie. ## Lire les erreurs détaillées du résolveur Recherchez un diagnostic complémentaire dans la sortie et dans les journaux du résolveur. Les Extended DNS Errors peuvent préciser qu’une signature est expirée, qu’une clé manque ou que les autorités ne sont pas joignables. La [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html) définit ces indications en complément des codes de réponse DNS. Conservez le numéro et le texte reçus. L’absence de détail ne permet pas d’écarter DNSSEC. Inversement, une indication très précise doit être vérifiée avec la zone et la période concernées, surtout si plusieurs caches ou serveurs intermédiaires interviennent. Évitez de traduire `SERVFAIL` en « domaine inexistant ». Si le code est réellement NXDOMAIN, le diagnostic concerne une autre situation. Mélanger ces erreurs dans un tableau de bord conduit à envoyer une panne de validation vers une équipe chargée de corriger des noms mal saisis. ## Comparer avec une validation désactivée pour ce test Sur le même résolveur et à une heure proche, une requête avec le bit Checking Disabled peut aider à isoler l’étape de validation : ```sh # Diagnostic ponctuel, pas une configuration de production dig @192.0.2.53 portail.service.example. A +dnssec +cdflag ``` Si la requête habituelle échoue mais que ce test obtient les données, la validation devient une piste prioritaire. Le [guide de dépannage de Google Public DNS](https://developers.google.com/speed/public-dns/docs/troubleshooting) utilise cette comparaison pour orienter les échecs DNSSEC. Le résultat ne prouve pas que les données obtenues sont fiables. Ne naviguez pas vers la destination sur la seule foi de ce test. Conservez les deux sorties, puis revenez aux données de délégation et de signature. Si les deux requêtes échouent, examinez aussi la disponibilité des autorités, la délégation et le transport réseau. ## Localiser la rupture de confiance Pour une zone signée, vérifiez les enregistrements DS publiés par le parent, les DNSKEY publiées par la zone et les signatures des ensembles concernés. La [RFC 4035](https://www.rfc-editor.org/rfc/rfc4035.html) décrit le traitement de validation et le rôle de ces données dans la chaîne de confiance. Dans votre investigation, relevez surtout les changements récents : transfert de registrar, migration de DNS, rotation de clés, restauration d’une ancienne zone ou panne du signataire. Demandez la configuration attendue au propriétaire technique et comparez-la aux données réellement servies. Un exemple fictif : `service.example` migre vers un nouveau fournisseur DNS. Le parent conserve un DS associé à l’ancienne clé, tandis que les nouvelles autorités publient d’autres DNSKEY. Des clients obtiennent des erreurs après expiration de leurs caches précédents. La correction doit rétablir une chaîne cohérente avec le gestionnaire de zone et le registrar ; changer le résolveur des utilisateurs masquerait le défaut. Vérifiez également les périodes de validité des signatures et l’heure système du résolveur. Un décalage temporel peut produire un résultat trompeur. Archivez les données exactes avant leur remplacement pour permettre une relecture de l’incident. ## Ne pas oublier les autorités et le réseau Interrogez les autorités séparément depuis un point autorisé. Des réponses différentes peuvent révéler un déploiement incomplet ou un serveur qui conserve une ancienne zone. Notez lequel répond, avec quel ensemble de données et quel numéro de série SOA lorsqu’il est pertinent. Si les grosses réponses échouent, comparez les comportements UDP et TCP et vérifiez le filtrage du chemin. Une modification simultanée du réseau et de DNSSEC complique le diagnostic : changez une variable à la fois et consignez le résultat attendu avant chaque test. Un outil public de diagnostic peut représenter la chaîne d’un domaine public. Utilisez son résultat comme une observation supplémentaire, avec son heure et son point de vue. Il ne remplace pas la réponse reçue par les clients affectés ni les journaux du résolveur de l’entreprise. ## Valider la réparation sur le chemin initial Après une correction, répétez la requête initiale avec la validation active. Vérifiez le nom exact, les types affectés et les différents réseaux qui avaient échoué. Gardez les sorties avant et après, ainsi que l’heure de modification et les éventuels caches encore en circulation. Le résultat attendu est une résolution correctement validée, sans dépendre du test `+cdflag`. Si une purge est nécessaire pour accélérer une vérification locale, notez-la explicitement. Les autres clients peuvent rester soumis à des caches différents, ce qui demande une surveillance adaptée. La [sécurisation du DNS](/fr/posts/securite-dns-empoisonnement-cache-detournement-durcissement) couvre les mesures de prévention qui suivent l’incident. Pour une investigation liée à une destination suspecte, complétez avec la [corrélation des événements DNS et processus](/fr/posts/alerte-ioc-correler-ip-dns-processus). Enfin, DNSSEC ne certifie pas le contenu d’un site. Vous pouvez consulter un [rapport de réputation du domaine](/fr/report) pour examiner ce sujet distinct, en conservant une conclusion séparée pour l’intégrité DNS et pour les indices d’abus observés. --- # DNSSEC and SERVFAIL: Find the Cause of Resolution Failure URL: https://ismalicious.com/posts/dnssec-servfail-troubleshooting Date: 2026-10-09T07:00:00.000Z Excerpt: Diagnose SERVFAIL using detailed DNS errors, the DS/DNSKEY chain and signatures, then verify the repair with DNSSEC validation enabled. **SERVFAIL** indicates a resolution failure, without providing a complete diagnosis. When a domain works on some networks and fails on others, DNSSEC is one possibility: a validating resolver can reject data that others return. Establish that cause before changing a zone or client settings. The following procedure applies to a public domain you administer or whose public data you can examine. The `.example` names and documentation addresses are fictional. Replace them with authorized values from your environment, keeping internal names out of public diagnostic tools. ## Preserve the failure before making changes Start with the exact name and query type affected. An application can fail on a subdomain or a CNAME target while the main domain still resolves. Record the time, resolver, client network and complete status. Capture answers with their options and sections, rather than recording only whether an address appeared. Retain a control name known to work through the same path. If every query fails, investigate the broader outage before focusing on a particular signature. ```sh # Fictional examples using a documentation resolver address and domain. dig @192.0.2.53 portail.service.example. A +dnssec dig @192.0.2.53 portail.service.example. AAAA +dnssec ``` The `+dnssec` option requests available DNSSEC data. It does not turn `dig` into a complete chain validator. A visible RRSIG record is data to examine; its presence alone does not prove that validation succeeded. ## Read the resolver’s detailed errors Look for additional diagnostics in the output and resolver logs. Extended DNS Errors can indicate an expired signature, a missing key or unreachable authoritative servers. [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html) defines these indications as additional information alongside DNS response codes. Preserve the received number and text. Missing detail does not rule out DNSSEC. Conversely, a precise indication still needs checking against the affected zone and period, particularly when several caches or intermediate servers are involved. Avoid interpreting `SERVFAIL` as “domain does not exist.” If the actual code is NXDOMAIN, the investigation concerns a different condition. Combining these errors in a dashboard can send a validation outage to a team expecting to correct mistyped names. ## Compare with validation disabled for one test Using the same resolver at approximately the same time, a query with the Checking Disabled bit can help isolate the validation step: ```sh # A diagnostic test, not a production configuration. dig @192.0.2.53 portail.service.example. A +dnssec +cdflag ``` If the ordinary request fails while this test returns data, validation becomes a priority for investigation. The [Google Public DNS troubleshooting guide](https://developers.google.com/speed/public-dns/docs/troubleshooting) uses this comparison to identify DNSSEC problems. The result does not prove that the returned data is trustworthy. Do not browse to the destination on the strength of this test. Save both outputs, then examine the delegation and signature data. If both requests fail, investigate authoritative server availability, delegation and network transport as well. ## Locate the break in the chain of trust For a signed zone, examine the DS records published by its parent, the DNSKEY records published by the zone and the signatures on the relevant record sets. [RFC 4035](https://www.rfc-editor.org/rfc/rfc4035.html) describes validation processing and the role of this data in the chain of trust. Focus your investigation on recent changes: a registrar transfer, DNS migration, key rollover, restoration of an older zone or signing service failure. Ask the technical owner for the expected configuration and compare it with the data actually being served. Consider a fictional migration of `service.example` to a new DNS provider. The parent retains a DS associated with the old key, while the new authoritative servers publish different DNSKEY records. Clients receive errors after their earlier cached data expires. Repair requires restoring a consistent chain with the zone operator and registrar; changing user resolvers would conceal the defect. Also check signature validity periods and the resolver’s system time. A clock discrepancy can produce a misleading result. Archive the exact data before replacing it so the incident can be reviewed later. ## Check authoritative servers and the network Query the authoritative servers individually from an authorized location. Different responses can reveal an incomplete deployment or a server retaining an old zone. Record which server responds, the record set it supplies and the SOA serial number where relevant. If large responses fail, compare UDP and TCP behavior and inspect filtering along the path. Simultaneous network and DNSSEC changes make the diagnosis harder. Change one variable at a time and record the expected result before each test. A public diagnostic tool can illustrate the chain for a public domain. Treat its result as an additional observation, with its own timestamp and vantage point. It cannot replace the response received by affected clients or the logs of the enterprise resolver. ## Verify the repair through the original path After a correction, repeat the original request with validation enabled. Check the exact name, affected record types and different networks that previously failed. Retain the before and after outputs, the modification time and details of any cached data still being served. The expected result is correctly validated resolution that does not depend on `+cdflag`. If a cache flush is needed to accelerate a local check, record that explicitly. Other clients can still be affected by different caches and need appropriate follow-up monitoring. The [DNS hardening guide](/posts/dns-security-hardening-guide) covers preventive measures after the incident. If the investigation involves a suspicious destination, also use the method for [correlating DNS and process events](/posts/investigate-ioc-alert-ip-dns-process). DNSSEC does not certify website content. Consult a [domain reputation report](/report) to investigate that separate question, retaining distinct conclusions about DNS integrity and any observed evidence of abuse. --- # DNS TTL: Investigate a Change of IP Address URL: https://ismalicious.com/posts/dns-ttl-ip-change-investigation Date: 2026-10-08T07:00:00.000Z Excerpt: Reconstruct DNS address changes using dated responses, caches and network views, without confusing TTL with the lifetime of a threat. A domain contacted during an incident now resolves to a different address. That difference does not invalidate your logs or prove that malicious infrastructure has moved. To explain it, place each DNS response in context: time, resolver, record type, cache and observation point. **DNS TTL** helps with this reconstruction when used for the right purpose. It describes cache handling; it does not independently establish the age of infrastructure. The following method preserves a useful timeline when addresses change during an investigation. ## Understand what a TTL measurement represents TTL is expressed in seconds. A response from a recursive resolver can show the remaining lifetime of data already in its cache, while an authoritative server can return its configured lifetime. Comparing these numbers without identifying their origin creates misleading differences. The [TTL definition in RFC 1035](https://www.rfc-editor.org/rfc/rfc1035.html#section-3.2.1) relates the value to caching a resource record. It does not describe a domain’s age, the date it was first used or the validity period of an indicator of compromise. This fictional example shows two readings from the same resolver: ```text 10:00:00Z api.service.example. A 192.0.2.20 TTL=240 10:01:00Z api.service.example. A 192.0.2.20 TTL=180 ``` A decrease of sixty seconds is consistent with an aging cache entry. It does not reveal a zone change. To characterize a change, compare the response contents and collection conditions as well as the TTL. ## Build a table of dated evidence Create one row per observation, keeping the previous row when a new address appears. Record the full name, A or AAAA type, any CNAME records, every returned address and the corresponding TTLs. Include the resolver, sensor location and UTC time. Keep the DNS query separate from the connection actually observed in your case file. A client can receive several addresses and use only one. The resolver’s answer describes available destinations; network telemetry identifies the destination the client attempted to contact or reached. | Fictional time | Observation | What it establishes | | -------------- | ------------------------ | ------------------------------------------------------- | | 10:00Z | A response: 192.0.2.20 | This address was supplied at this observation point | | 10:02Z | Connection to 192.0.2.20 | Telemetry records the asset contacting this destination | | 10:15Z | A response: 192.0.2.80 | A different response was received later | This table does not establish the exact moment when the authoritative data changed. That event falls somewhere within a period you still need to narrow. Avoid replacing the interval with an invented timestamp derived from the last known query. ## Examine the whole chain as well as the final IP A name can be an alias for a distributed service. Preserve each CNAME with its own observation. A stable alias target can lead to changing addresses; a CNAME change can also change the operator without making that clear in your initial view. Examine IPv4 and IPv6 separately. The application might use an AAAA response while your enrichment retains only A records. An incident attributed to “the wrong IP” can result from this incomplete collection even when the DNS data itself is consistent. Different answers from two networks can reflect geographic distribution or separately administered DNS views. Compare names, types and observation points first. For an internal name, stay within authorized views instead of sending it to a public service to simplify the test. ## Account for older answers that are still being served TTL expiration does not guarantee that every client immediately receives the new address. Application layers, intermediate resolvers or specific policies can prolong the discrepancy. Review their configuration and logs before attributing the problem to DNS publication. [RFC 8767](https://www.rfc-editor.org/rfc/rfc8767.html) describes serving stale data when authoritative refresh fails. If that feature is enabled, an old answer can remain available beyond its ordinary cache lifetime. Verify the mechanism on the affected resolver instead of assuming it from the result alone. Preserve the first answer before a flush. Record restarts, resolver changes and troubleshooting actions because they alter your test conditions. A successful test after clearing a cache shows an effect of that intervention; it does not automatically reconstruct the previous situation. ## Distinguish migration, distribution and suspicious activity Ask the service owner whether a migration or provider change coincides with the period under investigation. Compare that explanation with retained responses, destinations actually used and configuration changes. A migration ticket supplies an explanation that still needs verification. If addresses rotate rapidly, examine their diversity and the associated activity. The [fast-flux detection guide](/posts/fast-flux-dns-detection-threat-intelligence) addresses that specific hypothesis. Treating every rotation as fast flux during an investigation of a single change would add an unsupported conclusion. Review each IP’s context at the relevant time as well. A shared address can host several services and change its use. Do not automatically transfer the old address’s reputation to the new one, or a domain’s reputation to every neighboring service on its hosting infrastructure. ## Choose an action and a review period If suspicious activity follows a particular name, consider a control targeting that name where your tools support it. If containment must target an IP, document the observed relationship and schedule a review. DNS TTL is not a default blocking duration. The article on [IOC expiration](/posts/ioc-expiration-remove-ip-blocklist) explains how to reassess a rule independently of caching. End the incident record with the addresses established by evidence, the periods covered and gaps in collection. External historical observations can supplement those gaps without proving what a particular endpoint received. To enrich the public addresses and domains selected for investigation, open an [IsMalicious report](/report). Include the lookup time in your timeline. Keep the conclusion tied to the retained events, even after the current DNS response has changed again. --- # TTL DNS : enquêter sur un changement d’IP URL: https://ismalicious.com/fr/posts/ttl-dns-changement-ip-investigation Date: 2026-10-08T07:00:00.000Z Excerpt: Reconstituez un changement d’adresse DNS avec des réponses datées, les caches et les vues réseau, sans confondre TTL et durée de menace. Un domaine contacté pendant un incident résout aujourd’hui vers une autre adresse. Cette différence n’invalide pas vos journaux et ne prouve pas un déplacement malveillant. Pour l’expliquer, il faut replacer chaque réponse DNS dans son contexte : heure, résolveur, type de donnée, cache et point d’observation. Le **TTL DNS** est utile dans cette reconstruction, à condition de lui poser la bonne question. Il renseigne le traitement du cache ; il ne date pas à lui seul une infrastructure. Voici une méthode pour conserver une chronologie exploitable quand les adresses changent pendant une investigation. ## Ce que vous mesurez quand vous lisez un TTL Le TTL est exprimé en secondes. Une réponse issue d’un résolveur récursif peut montrer la durée restante d’une donnée déjà en cache, tandis qu’une autorité peut présenter sa durée configurée. Comparer ces nombres sans identifier leur provenance crée des écarts artificiels. La [définition du TTL dans la RFC 1035](https://www.rfc-editor.org/rfc/rfc1035.html#section-3.2.1) rattache cette valeur à la mise en cache d’un enregistrement. Elle ne décrit ni l’âge d’un domaine, ni la date de sa première utilisation, ni la durée de validité d’un indicateur de compromission. L’exemple fictif suivant représente deux lectures du même résolveur : ```text 10:00:00Z api.service.example. A 192.0.2.20 TTL=240 10:01:00Z api.service.example. A 192.0.2.20 TTL=180 ``` Une baisse de soixante secondes est compatible avec un cache qui vieillit. Elle ne révèle pas une modification de zone. Pour qualifier un changement, comparez aussi le contenu des réponses et les conditions de collecte. ## Construire un tableau de preuves datées Créez une ligne par observation, sans écraser la précédente quand une nouvelle adresse apparaît. Enregistrez le nom complet, le type A ou AAAA, les éventuels CNAME, toutes les adresses renvoyées et les TTL correspondants. Ajoutez le résolveur, l’emplacement du capteur et l’heure UTC. Dans votre dossier, gardez séparément la requête DNS et la connexion réellement observée. Un client peut recevoir plusieurs adresses et n’en utiliser qu’une. La réponse du résolveur décrit des destinations disponibles ; le journal réseau décrit celle qui a été tentée ou atteinte. | Heure fictive | Observation | Ce qu’elle établit | | ------------- | ------------------------- | -------------------------------------------------------- | | 10:00Z | Réponse A : 192.0.2.20 | Cette adresse a été fournie à ce point d’observation | | 10:02Z | Connexion vers 192.0.2.20 | L’actif a contacté cette destination selon la télémétrie | | 10:15Z | Réponse A : 192.0.2.80 | Une réponse différente a été reçue ensuite | Ce tableau ne détermine pas l’instant exact du changement côté autorité. Celui-ci se situe quelque part dans une période encore à préciser. Évitez de remplacer cet intervalle par une heure inventée à partir de la dernière requête connue. ## Examiner toute la chaîne, pas seulement la dernière IP Un nom peut être un alias vers un service distribué. Conservez chaque CNAME avec sa propre observation. Une cible d’alias stable peut mener à des adresses variables ; un changement de CNAME peut aussi modifier l’opérateur sans que votre première vue le montre clairement. Regardez séparément IPv4 et IPv6. L’application peut utiliser une réponse AAAA alors que votre enrichissement ne conserve que A. Un incident attribué à « la mauvaise IP » peut venir de cette collecte partielle, sans incohérence dans le DNS. Des réponses différentes depuis deux réseaux peuvent correspondre à une répartition géographique ou à deux vues administrées. Comparez d’abord les noms, types et points d’observation. Pour un nom interne, restez dans les vues autorisées et ne l’envoyez pas à un service public pour simplifier le test. ## Tenir compte des réponses anciennes encore servies L’expiration d’un TTL n’assure pas que tous les clients recevront immédiatement la nouvelle adresse. Des couches applicatives, des résolveurs intermédiaires ou des politiques particulières peuvent prolonger l’écart constaté. Cherchez leur configuration et leurs journaux avant d’accuser la publication DNS. La [RFC 8767](https://www.rfc-editor.org/rfc/rfc8767.html) décrit le service de données périmées lorsque leur rafraîchissement autoritatif échoue. Si cette fonction est activée, une ancienne réponse peut rester disponible au-delà de sa durée de cache ordinaire. Ce mécanisme doit être vérifié sur le résolveur concerné, pas supposé à partir du seul résultat. Préservez donc la première réponse avant une purge. Notez les redémarrages, les changements de résolveur et les opérations de dépannage : ils modifient votre expérience. Un test qui fonctionne après une purge indique un effet du changement effectué, mais ne reconstitue pas automatiquement la situation antérieure. ## Distinguer migration, distribution et activité suspecte Demandez au propriétaire du service s’il existe une migration ou une modification de fournisseur correspondant à la période. Comparez cette déclaration avec les réponses conservées, les destinations réellement utilisées et les changements de configuration. Un ticket de migration apporte une explication à vérifier. Si les adresses tournent rapidement, examinez leur diversité et l’activité associée. Le [guide de détection du fast flux](/fr/posts/detecter-fast-flux-dns-threat-intelligence) traite cette hypothèse spécifique. Dans une enquête sur un changement ponctuel, transformer toute rotation en fast flux ajouterait une conclusion sans preuve. Consultez aussi le contexte de chaque IP à la date pertinente. Une adresse mutualisée peut héberger plusieurs services et changer d’usage. Ne transférez pas automatiquement la réputation de l’ancienne adresse à la nouvelle, ou celle d’un domaine à tous les voisins de son hébergement. ## Choisir l’action avec la bonne durée Si l’activité suspecte suit un nom précis, examinez une mesure portant sur ce nom lorsque vos contrôles le permettent. Si un confinement doit viser une IP, documentez la relation observée et prévoyez une révision. Le TTL DNS ne constitue pas une durée de blocage par défaut. L’article sur l’[expiration des IOC](/fr/posts/expiration-ioc-retirer-ip-blocklist) explique comment réévaluer une règle indépendamment du cache. Dans le dossier d’incident, terminez par les adresses démontrées, les périodes couvertes et les trous de collecte. Une observation historique externe peut compléter ces trous, sans établir ce qu’un poste précis a reçu. Pour enrichir les adresses et domaines publics retenus, ouvrez un [rapport IsMalicious](/fr/report). Joignez son heure de consultation à votre chronologie. La conclusion doit rester attachée aux événements conservés, même lorsque la résolution actuelle a déjà changé. --- # NXDOMAIN : diagnostiquer une anomalie DNS URL: https://ismalicious.com/fr/posts/nxdomain-dns-diagnostic-securite Date: 2026-10-07T07:00:00.000Z Excerpt: Distinguez nom inexistant, cache négatif, filtrage et activité suspecte avant de transformer des erreurs NXDOMAIN en incident de sécurité. Une hausse de **NXDOMAIN** signifie que davantage de recherches DNS reçoivent une réponse de nom inexistant. Pour un SOC, la question utile est de savoir quel équipement recherche quels noms, par quel résolveur et depuis quel changement. Un compteur isolé ne permet de distinguer ni une panne applicative, ni une politique de blocage, ni un programme suspect. Le diagnostic commence avec une réponse complète et un poste identifié. Il se termine par une décision assortie de preuves : corriger une configuration, expliquer un filtrage, poursuivre une investigation ou préciser ce qui manque encore. ## Lire le résultat exact de la résolution Une réponse vide ne signifie pas automatiquement NXDOMAIN. Relevez le code de réponse, le type demandé, les sections de réponse et d’autorité, ainsi que l’adresse du serveur interrogé. Avec un outil comme `dig`, évitez d’abord la sortie abrégée qui masque ces champs. La [RFC 2308 sur le cache négatif](https://www.rfc-editor.org/rfc/rfc2308.html) distingue NXDOMAIN, qui concerne l’absence du nom, de NODATA, qui correspond à un nom existant sans donnée du type demandé. Elle précise aussi qu’un NXDOMAIN peut concerner la cible finale d’un CNAME. Ces différences changent la cible à examiner. Dans cet exemple fictif, `api.service.example` existe comme alias, mais son ancienne destination ne résout plus : ```text question : api.service.example. A réponse : api.service.example. CNAME ancien.service.example. statut : NXDOMAIN ``` L’enquête porte ici sur `ancien.service.example`, puis sur la configuration qui conserve cet alias. Déclarer tout le domaine `service.example` inexistant conduirait au mauvais diagnostic. Un SERVFAIL demande encore une autre analyse : le serveur n’a pas pu mener la résolution à bien. ## Reconstituer le trajet du poste au résolveur Notez le résolveur réellement utilisé au moment de l’événement. Le DNS du système, celui du navigateur, le VPN et une passerelle d’entreprise peuvent suivre des chemins différents. Une commande lancée sur votre ordinateur ne reproduit pas nécessairement la situation du poste concerné. Conservez pour chaque observation : heure UTC, actif, nom complet, type de requête, résolveur, code de réponse et processus lorsqu’il est collecté. Ajoutez le réseau d’origine et l’état du VPN. Ces données rendent une comparaison reproductible et évitent de confondre deux vues DNS légitimes. Pour une zone interne, interrogez uniquement les serveurs prévus par votre architecture. Envoyer son nom à un résolveur public révèle une information interne sans répondre au problème de la vue privée. Le guide sur la [surveillance du DNS chiffré](/fr/posts/dns-over-https-doh-securite-surveillance) aide à comprendre pourquoi certaines requêtes échappent au point de collecte habituel. ## Vérifier si le refus vient d’une politique Un produit de filtrage peut présenter un résultat négatif au client. Consultez son journal de décisions et recherchez le nom exact, le poste, l’heure et la règle correspondante. Une correspondance avec une liste de blocage constitue une explication à confirmer, pas une propriété intrinsèque du domaine. Si le résolveur fournit des Extended DNS Errors, enregistrez-les. La [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html) prévoit notamment des indications de blocage et de filtrage qui complètent le code DNS. Leur absence ne prouve pas qu’aucune politique n’a été appliquée : le produit ou le chemin de collecte peut ne pas les transmettre. Comparez ensuite le résultat avec une résolution autorisée depuis un point sans cette politique, si le domaine est public. Documentez cette différence sans contourner le blocage pour visiter le site. Vous cherchez l’origine de la réponse, pas à démontrer que la destination est sûre. ## Départager cache négatif et configuration cassée Un changement DNS peut être correct côté autorité tandis que certains clients voient encore l’échec précédent. Capturez la réponse du résolveur et celle des serveurs faisant autorité, avec leurs heures et les informations SOA disponibles. Répétez après un délai cohérent avec le cache observé. Ne videz pas tous les caches avant de conserver la première observation. Cette action peut rétablir le service, mais elle retire une pièce qui expliquait pourquoi un groupe de clients échouait. Préférez un test contrôlé sur un poste et consignez toute purge réalisée. Le cas fictif suivant illustre une migration incomplète. Une application recherche `collecte-v1.service.example` toutes les minutes. La configuration a été modifiée sur les postes récents, tandis que plusieurs anciens agents conservent ce nom supprimé. Les échecs se concentrent sur une même version, un même processus signé et un intervalle régulier. La correction doit viser le déploiement applicatif, sans créer une exception générale dans la surveillance. ## Mesurer une anomalie à la bonne échelle Comparez le nombre de requêtes échouées au volume total du même actif, sur la même période et le même capteur. Une hausse absolue pendant une multiplication des postes actifs n’a pas le même sens qu’un nouveau comportement sur un seul serveur. Regroupez les noms par suffixe, puis examinez les valeurs individuelles. Des fautes de frappe répétées, des suffixes ajoutés automatiquement et des noms construits par une application ne demandent pas les mêmes actions. Gardez un échantillon représentatif, y compris des résolutions réussies proches des échecs. La répétition seule ne prouve pas un mécanisme malveillant. Pour évaluer cette hypothèse, cherchez un processus inattendu, un parent inhabituel, une tâche récemment créée ou une séquence réseau corroborante. La méthode de [corrélation entre DNS, IP et processus](/fr/posts/alerte-ioc-correler-ip-dns-processus) décrit les preuves nécessaires pour relier ces observations. ## Prendre une décision qui résiste à la relecture Une erreur de configuration établie appelle un correctif ciblé, un propriétaire et une vérification après déploiement. Un blocage attendu appelle la confirmation de la règle et de son périmètre. Une activité locale inexpliquée appelle une investigation du poste, même lorsque toutes ses requêtes échouent. Dans le ticket, séparez les faits et les inconnues. Écrivez par exemple : « Le processus identifié demande un ancien nom de service ; les autorités ne le publient plus ; aucune autre destination n’a été examinée ». Cette phrase justifie la réparation sans prétendre avoir exclu toute compromission. Pour un domaine public suspect, consultez son [rapport de réputation](/fr/report) et conservez le résultat daté avec votre collecte. Une réputation enrichit la décision ; elle ne remplace ni le statut DNS réellement reçu, ni l’identité du programme qui a lancé la recherche. --- # NXDOMAIN: Diagnose a DNS Security Anomaly URL: https://ismalicious.com/posts/nxdomain-dns-security-diagnosis Date: 2026-10-07T07:00:00.000Z Excerpt: Separate nonexistent names, negative caching, filtering and suspicious activity before treating NXDOMAIN errors as a security incident. A rise in **NXDOMAIN** means that more DNS lookups are receiving a response indicating that a name does not exist. For a SOC, the useful question is which device is requesting which names, through which resolver, and what changed before the activity began. A counter alone cannot distinguish an application failure, a blocking policy and a suspicious program. Diagnosis starts with a complete response and an identified endpoint. It ends with a decision supported by evidence: correct a configuration, explain a filtering action, continue an investigation or specify what information is still missing. ## Read the exact resolution result An empty answer does not automatically mean NXDOMAIN. Record the response code, requested record type, answer and authority sections, and the address of the server queried. When using a tool such as `dig`, initially avoid abbreviated output that hides these fields. [RFC 2308 on negative caching](https://www.rfc-editor.org/rfc/rfc2308.html) distinguishes NXDOMAIN, which concerns a nonexistent name, from NODATA, where the name exists but has no data of the requested type. It also explains that NXDOMAIN can refer to the final target of a CNAME chain. These distinctions change which name you need to investigate. In this fictional example, `api.service.example` exists as an alias, but its old destination no longer resolves: ```text question: api.service.example. A answer: api.service.example. CNAME ancien.service.example. status: NXDOMAIN ``` The investigation concerns `ancien.service.example`, followed by the configuration that retains this alias. Declaring the entire `service.example` domain nonexistent would lead to the wrong diagnosis. SERVFAIL requires a different investigation again: the server was unable to complete resolution. ## Reconstruct the path from endpoint to resolver Identify the resolver actually used when the event occurred. System DNS, browser DNS, a VPN and an enterprise gateway can follow different paths. A command run on your own computer does not necessarily reproduce the affected endpoint’s situation. For each observation, preserve the UTC time, asset, full name, query type, resolver, response code and process when collected. Add the originating network and VPN state. These details make comparisons reproducible and prevent two legitimate DNS views from being mistaken for contradictory results. For an internal zone, query only the servers intended by your architecture. Sending its name to a public resolver exposes internal information without resolving a private DNS view problem. The guide to [monitoring encrypted DNS](/posts/dns-over-https-doh-security-monitoring) explains why some queries bypass the usual collection point. ## Establish whether a policy caused the response A filtering product can return a negative result to the client. Review its decision log for the exact name, endpoint, time and matching rule. A blocklist match is an explanation to verify, rather than an intrinsic property of the domain. If the resolver supplies Extended DNS Errors, record them. [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html) includes blocking and filtering indications that supplement the DNS response code. Their absence does not prove that no policy was applied: the product or collection path might not expose them. For a public domain, compare the result with an authorized lookup from a point where that policy does not apply. Document the difference without bypassing the block to visit the site. This comparison establishes where the response originated; it does not establish whether the destination is safe. ## Separate negative caching from broken configuration A DNS change can be correct at the authoritative servers while some clients still see an earlier failure. Capture the resolver’s response and the authoritative responses, including their timestamps and available SOA information. Repeat after an interval consistent with the cache lifetime observed. Preserve the first observation before flushing caches. A flush might restore service, but it also removes evidence explaining why a group of clients was failing. Prefer a controlled test on one endpoint and record any cache clearing performed. Consider a fictional incomplete migration. An application requests `collecte-v1.service.example` every minute. Newer endpoints received an updated configuration, while several old agents still use this deleted name. Failures cluster around one version, one signed process and a regular interval. The correction should address the application deployment without creating a blanket monitoring exception. ## Measure the anomaly at the right level Compare failed requests with the total volume from the same asset, over the same period and through the same sensor. An absolute increase as more endpoints become active means something different from new behavior on a single server. Group names by suffix, then examine the individual values. Repeated typing errors, automatically appended suffixes and application-generated names require different responses. Keep a representative sample, including successful resolutions close to the failures. Repetition alone does not establish malicious behavior. To assess that hypothesis, look for an unexpected process, an unusual parent, a newly created task or corroborating network activity. The method for [correlating DNS, IP and process evidence](/posts/investigate-ioc-alert-ip-dns-process) describes the records needed to connect these observations. ## Make a decision that another analyst can review An established configuration error calls for a targeted fix, an owner and verification after deployment. Expected blocking calls for confirmation of the rule and its scope. Unexplained local activity calls for endpoint investigation, even when every DNS request fails. Separate facts from unknowns in the ticket. For example: “The identified process requests an old service name; the authoritative servers no longer publish it; no other destinations have been examined.” This supports the repair without claiming that every possibility of compromise has been excluded. For a suspicious public domain, consult its [reputation report](/report) and retain the dated result alongside your collected evidence. Reputation adds context to the decision. It cannot replace the DNS status the client actually received or the identity of the program that initiated the lookup. --- # CNAME Cloaking: Investigate a Third-Party Subdomain URL: https://ismalicious.com/posts/cname-cloaking-dns-investigation Date: 2026-10-06T07:00:00.000Z Excerpt: Trace CNAME records, identify the provider, and inspect transmitted cookies before deciding whether a subdomain should remain authorized. CNAME cloaking makes a third-party service appear under a website's subdomain through a DNS alias. The browser may request `mesure.example.com` while DNS resolution leads to a provider's infrastructure. A control based only on the visible name can miss that relationship. External CNAMEs do not always represent tracking. The same mechanism supports ordinary hosting and support services. Before choosing an action, establish which service is actually involved, what data is exchanged, and who is responsible for maintaining it. ## Distinguish a DNS alias from a web redirect A CNAME associates an alias with a canonical name in DNS. [RFC 1034](https://www.rfc-editor.org/rfc/rfc1034.html#section-3.6.2) describes the mechanism. It is not an HTTP redirect: the visible URL can retain its initial name while DNS resolves the destination. The following diagram is fictional. `example.com`, the `.example` domains, and the IP address are reserved for documentation. ```text Browser request: https://mesure.example.com/collect DNS: mesure.example.com CNAME collecte.prestataire.example DNS: collecte.prestataire.example A 192.0.2.126 ``` Ownership of the initial name and operation of the final server are separate questions. Keep both names in the investigation record. If your tool displays only the IP, add the requested name and observed chain so that traffic to that address is not all attributed to a single customer. ## Start with a real request Choose a page and a user action to reproduce: opening a product page, signing in, or submitting a form. Use a test account and fictional data. Record the browser, version, timestamp, consent state, and active extensions. In developer tools, locate the request to the subdomain under investigation and identify its initiator. Was it a directly embedded script, a tag manager, or a resource loaded by another provider? The initiator helps identify the team responsible for the code or configuration. Preserve a trace with secrets removed. A HAR export can contain cookies, tokens, and form data. Keep the original in the authorized investigation workspace and prepare a minimal version for discussions with the provider. The observation to establish is specific: “this action triggers this request, carrying this data, to this service.” That makes the finding reproducible and avoids attributing collection to a component merely because it is present on the page. ## Follow resolution in the right context Record the DNS responses obtained during the test, including the resolver and timestamp. For a domain you manage, a command such as the following displays the available answer: ```sh dig mesure.example.com CNAME +noall +answer ``` The command uses an illustrative name. Replace it with a hostname you are authorized to examine. If the answer contains another alias, continue following the chain. Also inspect the A and AAAA responses needed to reach the destination, rather than assuming only one address family is involved. Compare that observation with the endpoint's resolution logs when explaining a past event. Today's answer may differ from the incident's answer. An absent visible CNAME in a synthesized response also does not prove that no provider is involved. Request the zone configuration from the domain owner when that information is available to you. To expand the inventory, the [subdomain enumeration guide](/posts/subdomain-enumeration-attack-surface-dns-reconnaissance) helps find names associated with your services. Each discovery still needs an internal owner and an approved purpose. ## Inspect what reaches the server Examine the test request's URL, parameters, headers, and body. Look for account identifiers, business data, and cookies unnecessary for the service. A request without cookies can still send personal information in its body, so the analysis must extend beyond browser storage. A cookie configured with `Domain=example.com` can apply to subdomains. `HttpOnly` prevents JavaScript from reading it, but does not prevent HTTP transmission when the other conditions are met. [MDN's cookie documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies) explains these attributes. Check what was actually sent rather than declaring exposure based on configuration alone. Also distinguish _same-site_ from _same-origin_. Two subdomains can belong to the same site while remaining different origins. A DNS alias does not merge the browser's origin rules. A policy allowing every subdomain and one limited to an exact origin grant different permissions. WebKit has [documented trackers' use of CNAME cloaking](https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/) and the associated protections. Those protections help explain why two browsers can produce different observations. They do not remove the website owner's responsibility to control data sent to a provider. ## Confirm the service and its scope Send the internal owner the hostname, DNS target, initiator, and a sanitized example request. Ask what the integration does, which provider account controls it, and what data it is expected to receive. A subscription invoice confirms a commercial relationship, but not necessarily this exact configuration. Compare the observed data with the stated purpose. If a basic traffic-measurement service receives account-session information, ask why it is necessary and how it is handled. If the integration no longer has an owner, mark it as a dependency requiring review before continued use. The [subdomain takeover and dangling DNS guide](/posts/subdomain-takeover-dangling-dns-prevention) covers cases where the provider resource has been released. An alias that remains in place does not prove someone else can claim the target, but it does justify checking the decommissioning process. ## Choose a correction and verify it If the service is authorized but receives too much data, correct the component sending that data and the scope of the affected cookies. Test the affected business workflows, because a cookie change can affect sign-in or other subdomains. If the service is abandoned, plan its removal with the DNS owner and application owner. Remove active references and neutralize the alias before permanently releasing a resource that someone else could reuse. Then check remaining requests and cache effects. If the behavior remains unexplained, apply a restriction appropriate to your context and retain a condition for reassessment. To add context, open an [IsMalicious report](/report) for the initial name and the relevant target. Their reputation results can differ; relating those results to the observed request is what makes the decision meaningful. --- # CNAME cloaking : enquêter sur un sous-domaine tiers URL: https://ismalicious.com/fr/posts/cname-cloaking-enquete-dns Date: 2026-10-06T07:00:00.000Z Excerpt: Suivez la chaîne CNAME, identifiez le prestataire et contrôlez les cookies transmis avant de décider si un sous-domaine doit rester autorisé. Le CNAME cloaking consiste à faire apparaître un service tiers sous un sous-domaine du site, grâce à un alias DNS. Le navigateur peut demander `mesure.example.com` tandis que la résolution mène à l’infrastructure d’un prestataire. Un contrôle fondé uniquement sur le nom visible risque alors de manquer cette relation. Tous les CNAME externes ne sont pas des dispositifs de pistage. La même technique sert des usages ordinaires d’hébergement ou de support. L’enquête doit établir le service réellement utilisé, les données échangées et la responsabilité de son maintien avant de choisir une mesure. ## Distinguer l’alias DNS d’une redirection web Un CNAME associe un alias à un nom canonique dans le DNS. La [RFC 1034](https://www.rfc-editor.org/rfc/rfc1034.html#section-3.6.2) décrit ce mécanisme. Il ne s’agit pas d’une redirection HTTP : l’URL visible peut conserver son nom initial pendant que le DNS résout la destination. Voici un schéma fictif. `example.com`, les domaines `.example` et l’adresse IP sont réservés à la documentation. ```text Requête du navigateur : https://mesure.example.com/collect DNS : mesure.example.com CNAME collecte.prestataire.example DNS : collecte.prestataire.example A 192.0.2.126 ``` La propriété du nom initial et l’exploitation du serveur final sont deux questions différentes. Conservez les deux noms dans la fiche d’enquête. Si votre outil n’affiche que l’IP, ajoutez aussi le nom demandé et la chaîne observée, afin de ne pas attribuer tout le trafic de cette adresse à un seul client. ## Partir d’une requête réelle Choisissez une page et une action utilisateur à reproduire : ouverture d’une fiche produit, connexion ou validation d’un formulaire. Utilisez un compte de test et des données fictives. Notez le navigateur, sa version, l’heure, l’état du consentement et les extensions actives. Dans les outils de développement, trouvez la requête vers le sous-domaine étudié et son initiateur. S’agit-il d’un script directement intégré, d’un gestionnaire de balises ou d’une ressource chargée par un autre fournisseur ? L’initiateur permet de joindre l’équipe responsable du code ou du paramétrage. Conservez une trace expurgée des secrets. Un export HAR peut contenir des cookies, des jetons et des données de formulaire. Gardez l’original dans l’espace d’enquête autorisé et préparez une version minimale pour les échanges avec le prestataire. Le point à démontrer n’est pas « ce domaine ressemble à notre site ». C’est « cette action provoque cette requête, avec ces données, vers ce service ». Cette formulation rend l’observation reproductible et évite d’attribuer une collecte à un composant simplement présent sur la page. ## Suivre la résolution depuis le bon contexte Relevez les réponses DNS obtenues dans le contexte du test, avec le résolveur et l’heure. Pour une vérification sur un domaine que vous gérez, une commande comme celle-ci permet d’afficher la réponse disponible : ```sh dig mesure.example.com CNAME +noall +answer ``` Cette commande utilise un nom d’illustration ; remplacez-le par le nom autorisé à examiner. Si la réponse contient un alias supplémentaire, poursuivez la chaîne. Consultez également les réponses A et AAAA nécessaires à la destination, sans supposer qu’une seule famille d’adresses est utilisée. Comparez cette observation aux journaux de résolution du poste si vous cherchez à expliquer un événement passé. Une réponse actuelle peut différer de celle de l’incident. L’absence de CNAME visible dans une réponse synthétisée ne démontre pas non plus l’absence de prestataire : demandez la configuration de zone au propriétaire du domaine lorsque vous y avez accès. Pour élargir l’inventaire, la [méthode d’énumération des sous-domaines](/fr/posts/enumeration-sous-domaines-surface-attaque-dns) aide à retrouver les noms associés à vos services. Chaque découverte demande ensuite une attribution interne et un usage validé. ## Examiner ce que le serveur reçoit Contrôlez l’URL, les paramètres, les en-têtes et le corps de la requête de test. Recherchez les identifiants de compte, les données métier et les cookies qui n’étaient pas nécessaires au service. Une requête sans cookie peut encore transmettre une donnée personnelle dans son corps ; l’analyse ne doit donc pas s’arrêter au stockage du navigateur. Un cookie configuré avec `Domain=example.com` peut s’appliquer aux sous-domaines. `HttpOnly` empêche sa lecture par JavaScript, mais ne supprime pas son envoi HTTP lorsque les autres conditions sont réunies. La [documentation MDN sur les cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies) précise le rôle de ces attributs. Vérifiez le contenu réellement envoyé, sans conclure à une exposition à partir de la seule configuration. Distinguez également _same-site_ et _same-origin_. Deux sous-domaines peuvent appartenir au même site tout en étant des origines différentes. Un alias DNS ne fusionne pas les règles d’origine du navigateur. Une politique qui autorise tous les sous-domaines et une politique limitée à une origine exacte n’accordent pas les mêmes permissions. WebKit a [documenté l’usage du CNAME cloaking par des traceurs](https://webkit.org/blog/11338/cname-cloaking-and-bounce-tracking-defense/) et les protections associées. Ces protections expliquent pourquoi deux navigateurs peuvent produire des observations différentes. Elles ne dispensent pas le propriétaire du site de maîtriser les données envoyées à son prestataire. ## Faire confirmer le service et son périmètre Envoyez au propriétaire interne le nom d’hôte, la cible DNS, l’initiateur et un exemple de requête expurgé. Demandez à quoi sert l’intégration, quel compte fournisseur la contrôle et quelles données sont attendues. Une facture d’abonnement confirme une relation commerciale, pas nécessairement cette configuration précise. Comparez ensuite les données observées au besoin annoncé. Si une simple mesure de fréquentation reçoit des éléments liés à une session de compte, faites préciser leur nécessité et leur traitement. Si l’intégration n’a plus de propriétaire, inscrivez-la comme dépendance à examiner avant son maintien. L’article sur la [prise de contrôle de sous-domaines et le DNS orphelin](/fr/posts/prise-controle-sous-domaines-dns-orphelin) traite le cas où la ressource du prestataire a été libérée. Un alias encore présent ne prouve pas qu’un tiers peut reprendre la cible, mais il justifie de vérifier le cycle de décommissionnement. ## Choisir une correction et la vérifier Si le service est autorisé mais reçoit trop de données, corrigez le composant qui les envoie et la portée des cookies concernés. Testez les parcours métier affectés, car une modification de cookie peut toucher la connexion ou d’autres sous-domaines. Si le service est abandonné, planifiez son retrait avec le responsable DNS et le propriétaire de l’application. Retirez les références actives et neutralisez l’alias avant de libérer définitivement une ressource réutilisable. Vérifiez ensuite les requêtes restantes et les effets du cache. Si le comportement reste inexpliqué, appliquez la restriction adaptée à votre contexte et gardez une condition de réexamen. Pour compléter le dossier, consultez un [rapport IsMalicious](/fr/report) sur le nom initial et sur la cible pertinente. Des résultats de réputation différents sont possibles ; c’est leur relation avec la requête observée qui donne un sens à la décision. --- # Domaine parqué : évaluer le risque avant de bloquer URL: https://ismalicious.com/fr/posts/domaine-parque-reputation-risque Date: 2026-10-05T07:00:00.000Z Excerpt: Distinguez parking, expiration et comportement malveillant. Examinez l’usage réel du domaine et choisissez une restriction proportionnée. Un domaine parqué affiche une page d’attente, une offre de vente ou une forme de monétisation plutôt que le service attendu. Cette observation ne suffit pas à le classer comme malveillant. En revanche, elle devient importante lorsqu’un utilisateur vient d’y suivre un lien de facture, qu’une application y transmet encore des données ou qu’une règle de confiance l’autorise depuis des années. Le triage doit répondre à deux questions distinctes : que fait ce domaine aujourd’hui, et pourquoi votre organisation essaie-t-elle de le contacter ? Le croisement des réponses permet de choisir entre correction d’un lien obsolète, restriction d’accès et enquête de sécurité. ## Décrire ce que signifie « parqué » dans votre source Commencez par la source de la catégorie. S’agit-il d’un moteur de réputation, d’une capture de page ou d’un nom de serveur DNS associé à une plateforme de parking ? Conservez le motif et la date. Une classification historique ne remplace pas une observation récente. Une page de vente, une page publicitaire et un avis d’expiration correspondent à des situations différentes. La politique ICANN de récupération après expiration prévoit notamment des cas de redirection vers une page indiquant l’expiration et les modalités de renouvellement. Ce comportement peut donc résulter du cycle de vie d’un domaine, sans démontrer un détournement. Voir la [politique ERRP d’ICANN](https://www.icann.org/en/contracted-parties/consensus-policies/expired-registration-recovery-policy/expired-registration-recovery-policy-21-02-2024-en). Gardez une formulation descriptive : « page proposant la vente du nom observée à telle heure ». Si l’accès direct n’est pas nécessaire à l’enquête, utilisez des preuves déjà collectées par votre passerelle ou un environnement d’analyse approprié. Ne vous connectez pas avec une session métier pour vérifier une ancienne adresse. ## Retrouver le lien qui a conduit au domaine Dans les journaux, identifiez l’utilisateur ou le service, le nom d’hôte exact et l’heure. Recherchez la page, le message ou la tâche à l’origine de la requête. Un navigateur peut charger une ressource indirecte sans que l’utilisateur ait saisi ce domaine. Classez l’usage attendu : portail interactif, dépendance d’application, lien documentaire ou simple erreur de saisie. Demandez au propriétaire métier si le domaine fait encore partie du service. Une réponse « nous utilisions ce fournisseur » ne suffit pas à autoriser son adresse actuelle. Cette étape permet parfois de résoudre le problème avant toute mesure réseau. Un ancien modèle de facture peut contenir un lien abandonné ; la correction doit alors porter sur le modèle et les documents encore accessibles. Bloquer le domaine protège certains clics, mais laisse la cause de ces clics intacte. ## Une chronologie fictive de portail fournisseur Prenons `factures-fournisseur.example`, domaine fictif utilisé ici pour un exercice. Une application interne le référençait pour télécharger des justificatifs. L’IP de documentation ci-dessous ne correspond à aucun serveur réel. | Moment observé | Pièce disponible | Interprétation possible | | ------------------- | ---------------------------------------------------- | ---------------------------------- | | Ancien inventaire | Portail approuvé et responsable identifié | Usage historique établi | | Alerte actuelle | Requête vers `192.0.2.91` et nouvelle page d’attente | Service différent de celui attendu | | Vérification métier | Fournisseur migré vers une autre adresse | Lien interne probablement obsolète | | Contrôle applicatif | Tâche périodique toujours active | Dépendance à retirer ou corriger | Aucune ligne de ce tableau ne prouve une infection. Pourtant, laisser la tâche active serait une mauvaise décision : elle contacte un service qui n’est plus validé pour cet usage. La mesure adaptée peut être de suspendre cette tâche, de corriger l’adresse et de vérifier ce qu’elle envoyait. Si la tâche transmettait uniquement une requête publique, l’impact diffère d’un envoi de jeton ou de document. Examinez sa configuration et ses journaux avant de déclarer une fuite. La présence d’un nouveau destinataire ne prouve pas, à elle seule, qu’une donnée sensible lui a été remise. ## Observer les transitions et les redirections Conservez le nom initial, les étapes de redirection observées et la destination finale, avec leurs heures. Une page parquée peut orienter vers des contenus différents selon le contexte. Une capture unique décrit donc une visite, pas nécessairement tous les visiteurs. La recherche de [Unit 42 sur le parking de domaines](https://unit42.paloaltonetworks.com/domain-parking/) documente des cas d’abus et des transitions vers des contenus dangereux. Elle justifie l’examen des comportements dans le temps ; elle ne permet pas d’attribuer ces cas à chaque domaine portant la catégorie « parked ». Pour une analyse active, utilisez un environnement prévu pour examiner des liens suspects. Conservez les URL exactes dans le dossier sécurisé ; évitez de publier les jetons ou identifiants présents dans leurs paramètres. Si vous ne disposez que du DNS, notez que le contenu web et les redirections n’ont pas été observés. Le [guide sur les domaines légitimes compromis](/fr/posts/domaines-compromis-phishing-contournement-reputation) traite une autre situation importante : un nom reconnu peut rester actif tout en hébergeant un chemin malveillant. Une page d’accueil rassurante ne suffit donc pas non plus à valider toutes les URL. ## Choisir une restriction avec un périmètre clair Pour un domaine sans usage professionnel identifié, votre politique peut prévoir une restriction de catégorie. Documentez alors qu’il s’agit d’une mesure de prévention, sans annoncer une compromission démontrée. Prévoyez un circuit de demande d’exception et une date de revue. Pour un fournisseur encore nécessaire, vérifiez un autre canal de contact et une adresse de service approuvée. Évitez une exception permanente accordée uniquement parce que son nom figure dans un ancien contrat. Le service actuel doit correspondre à l’usage autorisé. Si une URL précise présente un contenu malveillant, adaptez la mesure au périmètre confirmé et aux capacités de votre équipement. Une IP mutualisée peut héberger d’autres clients. Une règle trop large peut casser des services sans rapport ; une règle trop étroite peut laisser actives les autres adresses de la même campagne. Expliquez le compromis choisi dans le ticket. La [méthode d’automatisation des listes de blocage](/fr/posts/automatisation-listes-blocage-pare-feu-flux-ip-domaines) détaille les essais et le suivi des effets. Après déploiement, vérifiez les événements bloqués et les éventuelles demandes métier, au lieu de supposer que la règle fonctionne comme prévu. ## Fermer le dossier avec une condition de réexamen Un domaine peut changer de titulaire ou de contenu après votre décision. Conservez la preuve initiale, le motif de restriction et ce qui permettrait de la revoir : confirmation du fournisseur, service rétabli, dépendance retirée ou nouvelle analyse. Si le domaine appartient à votre organisation, transmettez également le dossier au responsable de son cycle de vie. Vérifiez les contacts du registrar, le renouvellement et les applications dépendantes. L’objectif est de corriger la relation entre le nom et ses usages, pas seulement de faire disparaître une catégorie dans un outil. Pour compléter cette évaluation, consultez un [rapport de réputation IsMalicious](/fr/report), puis rapprochez les signaux datés de votre observation et de l’usage métier. La conclusion peut être « ancien lien supprimé, aucune transmission sensible démontrée » ou « redirection suspecte confirmée, investigation poursuivie ». Dans les deux cas, les pièces disponibles doivent expliquer la décision. --- # Parked Domains: Assess the Risk Before Blocking URL: https://ismalicious.com/posts/parked-domain-reputation-risk Date: 2026-10-05T07:00:00.000Z Excerpt: Distinguish domain parking, expiration, and malicious behavior. Examine actual use and choose a restriction supported by the evidence. A parked domain displays a placeholder, a sale offer, or some form of monetization instead of the expected service. That observation alone does not make it malicious. It becomes significant when a user has just followed an invoice link to it, an application still sends it data, or a long-standing trust rule allows access. Triage should answer two separate questions: what does the domain do today, and why is your organization trying to contact it? Combining those answers helps you choose between fixing an obsolete link, restricting access, and opening a security investigation. ## Establish what “parked” means in your source Start with the source of the category. Is it a reputation engine, a page capture, or a DNS server name associated with a parking platform? Preserve the reason and date. A historical classification does not replace a recent observation. A sale page, an advertising page, and an expiration notice describe different situations. ICANN's Expired Registration Recovery Policy includes circumstances where a domain redirects to a page identifying expiration and renewal options. That behavior can therefore result from the registration lifecycle without proving a takeover. See [ICANN's ERRP](https://www.icann.org/en/contracted-parties/consensus-policies/expired-registration-recovery-policy/expired-registration-recovery-policy-21-02-2024-en). Use descriptive wording: “page offering the domain for sale observed at this time.” If direct access is unnecessary, use evidence already collected by your gateway or an appropriate analysis environment. Do not use an authenticated work session to check an old address. ## Find the link that led to the domain Identify the user or service, exact hostname, and timestamp in your logs. Find the page, message, or job that caused the request. A browser can load an indirect resource without the user ever typing that domain. Classify the expected use: interactive portal, application dependency, documentation link, or typing mistake. Ask the business owner whether the domain remains part of the service. “We used that supplier” is not enough to authorize its current address. This step can sometimes resolve the issue before a network change is needed. An old invoice template may contain an abandoned link; the correction then belongs in that template and any documents still accessible. Blocking the domain can stop some visits while leaving the source of those visits unchanged. ## A fictional supplier-portal timeline Consider `factures-fournisseur.example`, a fictional domain used for this exercise. An internal application referenced it to download supporting documents. The documentation IP below does not represent a real server. | Observation point | Available evidence | Possible interpretation | | --------------------- | -------------------------------------------------- | ---------------------------------------------- | | Earlier inventory | Approved portal with an identified owner | Historical use established | | Current alert | Request to `192.0.2.91` and a new placeholder page | Observed service differs from the expected one | | Business verification | Supplier moved to a different address | Internal link is probably obsolete | | Application check | Scheduled job still active | Dependency needs removal or correction | Nothing in this table proves an infection. Nevertheless, leaving the job running would be a poor decision: it contacts a service no longer approved for that use. An appropriate response may be to suspend the job, correct the address, and inspect what it was sending. A job making only a public request has a different impact from one sending a token or document. Inspect its configuration and logs before declaring a data leak. A new recipient alone does not prove that sensitive information was delivered to it. ## Observe transitions and redirects Preserve the initial hostname, observed redirect steps, and final destination, with timestamps. A parked page may lead to different content depending on context. One capture therefore describes one visit, not necessarily every visitor's experience. [Unit 42's domain-parking research](https://unit42.paloaltonetworks.com/domain-parking/) documents abuse cases and transitions to harmful content. It supports examining behavior over time; it does not attribute those cases to every domain classified as parked. For active analysis, use an environment designed for investigating suspicious links. Keep exact URLs in the secured case record and avoid publishing tokens or identifiers from their parameters. If you have only DNS evidence, state that web content and redirects were not observed. The [guide to compromised legitimate domains](/posts/compromised-domains-phishing-reputation-bypass) covers another relevant situation: a recognized name can remain active while hosting a malicious path. A reassuring homepage therefore cannot validate every URL either. ## Choose a restriction with a defined scope For a domain with no identified business use, your policy may allow a category restriction. Document it as a preventive measure rather than claiming a demonstrated compromise. Provide an exception-request process and a review date. For a supplier still needed by the business, verify an alternative contact channel and an approved service address. Avoid granting a permanent exception solely because the name appears in an old contract. The current service must match the authorized purpose. If a specific URL displays malicious content, match the measure to the confirmed scope and your equipment's capabilities. A shared IP can serve other customers. An overly broad rule can break unrelated services; an overly narrow one can leave other campaign addresses accessible. Explain the chosen tradeoff in the ticket. The [blocklist automation guide](/posts/firewall-blocklist-automation-ip-domain-feeds) covers testing and monitoring effects. After deployment, examine blocked events and business requests rather than assuming the rule behaves as intended. ## Close with a condition for reassessment A domain can change registrant or content after your decision. Retain the initial evidence, reason for restriction, and conditions for reconsidering it: supplier confirmation, restored service, removed dependency, or a new analysis. If the domain belongs to your organization, involve the person responsible for its lifecycle. Check registrar contacts, renewal, and dependent applications. The aim is to repair the relationship between the name and its uses, not simply remove a category from a tool. To complete the assessment, open an [IsMalicious reputation report](/report), then compare dated signals with your observation and the business use. Your conclusion might be “obsolete link removed; no sensitive transmission demonstrated” or “suspicious redirect confirmed; investigation continuing.” In either case, the available evidence should explain the decision. --- # RDAP: Read Domain Data During an Investigation URL: https://ismalicious.com/posts/rdap-domain-investigation-data Date: 2026-10-04T07:00:00.000Z Excerpt: Use RDAP events, statuses, and contacts to document a suspicious domain without misattributing an identity or claiming an unproven compromise. RDAP provides structured data about a domain's registration. In a security investigation, its value is the ability to preserve comparable observations: dated events, statuses, the registrar, and nameservers. It does not automatically reveal a website's operator or the source of a campaign. The following method starts with a domain found in a suspicious message. It produces an investigation record with dated facts, explicit limitations, and an appropriate contact. It complements the [WHOIS investigation guide](/posts/whois-lookup-security-investigations-domain-ownership) by focusing on how to handle RDAP JSON. ## Choose the object and the service to query First, preserve the received URL and its exact hostname in your case record. Registration lookups generally concern the registered domain, which is not necessarily the service's full hostname. Keep that relationship visible: an observation about `connexion.example.com` and a registration record for `example.com` do not describe exactly the same object. Use a recognized lookup service or an RDAP client that discovers the responsible server. Record the queried server's URL, timestamp, and HTTP result along with the response. [ICANN's information for RDAP users](https://www.icann.org/en/contracted-parties/registry-operators/registration-data-access-protocol/information-for-rdap-users-31-08-2018-en) explains the protocol and its domain lookup tool. Do not treat every result as equivalent. A registry response, registrar response, and aggregator result may cover different information. If your tool combines sources, retain their provenance instead of assigning all values to one source. ## Preserve facts before interpreting them Export the complete response into the case record, then build a short view for the analyst. Keeping both lets you retrieve a field omitted during initial triage. It also preserves notices explaining disclosure restrictions or missing information. Attach the source and lookup date to each retained value. If you calculate domain age, preserve the event used in that calculation. A standalone value of “12 days” becomes ambiguous a week later and conceals cases where no relevant date was available. The following fictional JSON excerpt contains only the fields needed for the exercise. It is neither a complete response nor the result of a real domain query. ```json { "objectClassName": "domain", "ldhName": "portail-fournisseur.example", "status": ["client transfer prohibited"], "events": [ { "eventAction": "registration", "eventDate": "2024-04-12T09:00:00Z" }, { "eventAction": "last changed", "eventDate": "2026-09-28T15:20:00Z" } ], "nameservers": [{ "ldhName": "ns1.dns-prestataire.example" }] } ``` [RFC 9083](https://www.rfc-editor.org/rfc/rfc9083.html) defines these structures: events with actions and dates, statuses, entities with roles, and domain information. An array can contain multiple events. Your reader must select the relevant action rather than arbitrarily taking the first date it encounters. ## Reconstruct a timeline without inventing the change In the example, registration dates to 2024 and the object changed recently. That proves neither a sale nor a compromise. The result alone does not show the difference between the old and new configuration. Look for a comparable earlier observation. If your team retains RDAP responses, compare fields while accounting for their sources. If DNS history is available, examine delegation or resolution changes separately. The two timelines can complement one another without describing exactly the same event. Suppose the supplier confirms a migration on the date of the change and the new nameservers match the approved configuration. That agreement explains part of the record. It does not validate every link sent in the supplier's name: the received URL and request still need examination. Conversely, if nobody recognizes the change and an unfamiliar login portal appears, raise the investigation's priority. Describe the two observations separately, followed by the hypothesis they support. That wording remains open to revision if later evidence supplies another explanation. ## Read statuses as operational controls A transfer lock is often a normal administrative measure. It does not attest to the safety of web content. A DNS hold describes a technical effect, but does not necessarily reveal why the hold was applied. The [ICANN table of EPP codes and RDAP labels](https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en) explains these values. For example, `clientTransferProhibited` represents a transfer restriction set on the registrar side. Do not translate it into “malicious domain blocked.” In your record, separate the raw value, operational meaning, and your interpretation. This prevents a technical label from becoming a reputation verdict when exported to the SOC or support team. ## Distinguish contacts and their roles The registrar manages registration, the DNS provider hosts the zone, and the web host serves content. One company may perform several roles, but verify that relationship. Sending a request to the first company name in the JSON can delay resolution. When preparing an abuse report, gather the domain, affected URLs, timestamps, and evidence of the observed abuse. Then verify the appropriate contact channel for the responsible service. Share the information needed for that request rather than automatically attaching the entire incident record. A missing registrant name is not evidence of malicious concealment. Write “identity not public in this response.” An investigation can still rely on observed content, logs, and chronology without attributing activity to a person. ## Choose the next step from the missing evidence If the question concerns a user's activity, look for local events. If it concerns a service change, contact the owner through an established channel. If it concerns suspicious infrastructure, compare registration observations with available technical indicators, preserving their dates. [Monitoring domain reputation changes](/posts/monitor-domain-reputation-changes) helps maintain this record over time. Avoid an automatic rule based solely on age, the registrar's country, or a redacted contact. These fields describe characteristics; they do not demonstrate compromise. End the record with an action, its owner, and the remaining limitation. For example: “recent change confirmed; supplier has not validated the migration; portal access suspended pending verification.” To add context about the domain, open an [IsMalicious report](/report), then retain the dated result alongside the RDAP data and observations supporting your decision. --- # RDAP : lire les données d’un domaine en enquête URL: https://ismalicious.com/fr/posts/rdap-enquete-domaine-donnees Date: 2026-10-04T07:00:00.000Z Excerpt: Exploitez les événements, statuts et contacts RDAP pour documenter un domaine suspect sans attribuer à tort une identité ou une compromission. RDAP fournit des données structurées sur l’enregistrement d’un domaine. Pour une enquête de sécurité, son intérêt est de conserver des observations comparables : événements datés, statuts, bureau d’enregistrement et serveurs de noms. Il ne révèle pas automatiquement l’auteur d’un site ni l’origine d’une campagne. La méthode suivante part d’un domaine découvert dans un message suspect. Elle produit une fiche d’enquête avec des faits datés, des limites explicites et un interlocuteur adapté. Elle complète la [lecture des données WHOIS en investigation](/fr/posts/recherche-whois-enquetes-securite-propriete-domaine) en se concentrant sur le traitement du JSON RDAP. ## Choisir l’objet et le service interrogé Conservez d’abord l’URL reçue et son nom d’hôte exact dans votre dossier. La recherche d’enregistrement porte généralement sur le domaine enregistré, qui n’est pas nécessairement le nom complet du service. Gardez cette relation : une observation sur `connexion.example.com` et une fiche pour `example.com` ne décrivent pas exactement le même objet. Utilisez un service de recherche reconnu ou un client RDAP qui découvre le serveur compétent. Notez l’URL du serveur interrogé, l’heure et le résultat HTTP avec la réponse. Le [point d’information ICANN pour les utilisateurs RDAP](https://www.icann.org/en/contracted-parties/registry-operators/registration-data-access-protocol/information-for-rdap-users-31-08-2018-en) présente le protocole et son outil de consultation pour les noms de domaine. Ne considérez pas tous les résultats comme équivalents. Une réponse du registre, une réponse du registrar et un agrégateur peuvent avoir des périmètres différents. Si votre outil fusionne plusieurs sources, conservez leur provenance au lieu d’attribuer toutes les valeurs à une source unique. ## Sauvegarder les faits avant de leur donner un sens Exportez la réponse complète dans le dossier, puis construisez une vue courte pour l’analyste. Cette séparation permet de retrouver un champ omis lors du premier triage. Elle évite aussi de perdre les notices qui expliquent une restriction de diffusion ou une donnée absente. Pour chaque valeur retenue, ajoutez sa source et sa date de consultation. Si vous calculez un âge de domaine, conservez l’événement utilisé pour ce calcul. Un simple entier « 12 jours » devient ambigu une semaine plus tard et masque les cas où aucune date pertinente n’était disponible. Voici un extrait JSON fictif, limité aux champs nécessaires à l’exercice. Il ne représente pas une réponse complète ni un domaine réellement interrogé. ```json { "objectClassName": "domain", "ldhName": "portail-fournisseur.example", "status": ["client transfer prohibited"], "events": [ { "eventAction": "registration", "eventDate": "2024-04-12T09:00:00Z" }, { "eventAction": "last changed", "eventDate": "2026-09-28T15:20:00Z" } ], "nameservers": [{ "ldhName": "ns1.dns-prestataire.example" }] } ``` La [RFC 9083](https://www.rfc-editor.org/rfc/rfc9083.html) définit ces structures : événements avec action et date, statuts, entités avec rôles et informations de domaine. Un tableau peut contenir plusieurs événements. Votre lecteur doit donc choisir l’action pertinente, sans prendre arbitrairement la première date rencontrée. ## Reconstituer une chronologie sans inventer le changement Dans l’exemple, l’enregistrement remonte à 2024 et l’objet a été modifié récemment. Cela ne démontre ni une vente ni un piratage. Le résultat ne donne pas, à lui seul, la différence entre l’ancienne et la nouvelle configuration. Cherchez alors une observation antérieure comparable. Si votre équipe conserve des réponses RDAP, comparez les champs en tenant compte de leur origine. Si vous disposez d’un historique DNS, examinez séparément les changements de délégation ou de résolution. Les deux chronologies peuvent se compléter sans raconter exactement le même événement. Supposons que le fournisseur confirme une migration le jour de la modification et que les nouveaux serveurs de noms correspondent au changement approuvé. Cette concordance explique une partie du dossier. Elle ne valide pas tous les liens envoyés au nom de ce fournisseur : l’URL et la demande reçues restent à vérifier. À l’inverse, si personne ne reconnaît le changement et qu’un portail de connexion inhabituel apparaît, augmentez la priorité de l’enquête. Décrivez les deux observations séparément, puis l’hypothèse qu’elles motivent. Cette formulation reste révisable si une pièce ultérieure apporte une autre explication. ## Interpréter les statuts comme des opérations Un verrouillage de transfert est souvent une mesure de gestion normale. Il n’atteste pas la sécurité du contenu web. Un statut de suspension DNS décrit, lui, un effet technique ; il ne révèle pas nécessairement le motif de la suspension. La [table ICANN des codes EPP et de leurs libellés RDAP](https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en) permet de lire ces valeurs. Par exemple, `clientTransferProhibited` correspond à une interdiction de transfert demandée côté registrar. Ne le traduisez pas par « domaine malveillant bloqué ». Dans votre fiche, séparez la valeur brute, sa signification opérationnelle et votre interprétation. Cette présentation évite qu’une étiquette technique devienne un verdict de réputation dans un export destiné au SOC ou au support. ## Distinguer les contacts et leurs rôles Le registrar gère l’enregistrement ; le fournisseur DNS héberge la zone ; l’hébergeur sert le contenu. Une même société peut exercer plusieurs rôles, mais il faut le vérifier. Envoyer une demande au premier nom d’entreprise rencontré dans le JSON risque d’allonger le traitement. Si vous préparez un signalement, réunissez le domaine, les URL concernées, les heures et les preuves de l’abus constaté. Vérifiez ensuite le canal de contact du service responsable. Ne transmettez que les informations nécessaires, sans joindre automatiquement tout le dossier d’incident. L’absence de nom de titulaire ne constitue pas une preuve d’opacité malveillante. Notez « identité non publique dans cette réponse ». Une enquête peut rester pertinente grâce au contenu observé, aux journaux et à la chronologie, même sans attribution personnelle. ## Choisir l’étape suivante selon la preuve manquante Si la question concerne l’activité d’un utilisateur, recherchez les événements locaux. Si elle concerne le changement de service, contactez son propriétaire par un canal connu. Si elle concerne une infrastructure suspecte, comparez les observations d’enregistrement aux indicateurs techniques disponibles, en conservant leurs dates. Le [suivi des changements de réputation d’un domaine](/fr/posts/surveiller-reputation-domaine-alertes) aide à prolonger cette fiche dans le temps. Évitez une règle automatique fondée uniquement sur l’âge, le pays du registrar ou un contact masqué : ces champs décrivent des caractéristiques, pas une compromission démontrée. Terminez la fiche par l’action, son responsable et la limite restante. Par exemple : « modification récente confirmée ; migration non validée par le fournisseur ; accès au portail suspendu dans l’attente de vérification ». Pour compléter le contexte du domaine, consultez un [rapport IsMalicious](/fr/report), puis associez ce résultat daté aux données RDAP et aux observations qui motivent votre décision. --- # Rapport DMARC XML : interpréter les échecs URL: https://ismalicious.com/fr/posts/analyser-rapport-dmarc-xml Date: 2026-10-03T07:00:00.000Z Excerpt: Lisez les rapports DMARC agrégés, distinguez alignement et authentification, puis classez les anomalies par service et impact métier. Un rapport DMARC XML devient utile lorsque chaque ligne conduit à une décision : corriger un expéditeur autorisé, examiner une source inconnue ou documenter un transfert attendu. Le nombre total d’échecs, seul, ne permet pas de choisir entre ces actions. Un petit flux de facturation mal configuré peut demander une intervention plus rapide qu’un grand volume d’usurpations déjà rejetées. Cette méthode transforme un rapport agrégé en file de travail. Elle ne suppose pas que tous les destinataires produisent des rapports ni que les messages signalés ont atteint la boîte de réception. ## Vérifier le fichier avant de compter Conservez le message transportant le rapport, son fichier joint original et une copie de travail décompressée. Notez l’organisme déclarant, l’identifiant du rapport, le domaine concerné et la période couverte. La date de réception du fichier n’est pas nécessairement la date des événements. Traitez l’entrée comme un fichier externe. Imposez des limites de taille après décompression et utilisez un parseur XML dont les entités externes sont désactivées. Les [recommandations OWASP contre les attaques XXE](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) expliquent pourquoi un parseur mal configuré peut accéder à des ressources inattendues. Aucun accès réseau n’est nécessaire pour lire les valeurs d’un rapport. Vérifiez le format effectivement reçu. La [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) définit le format actuel des rapports agrégés DMARC ; des producteurs peuvent encore utiliser le format historique. Faites remonter un format non pris en charge comme une erreur d’import, pas comme un rapport contenant zéro message. ## Séparer trois niveaux de lecture Les métadonnées décrivent qui rapporte et pour quelle période. La politique publiée décrit ce que le récepteur a observé. Les lignes `record` regroupent des résultats associés à une IP source et à des identités d’authentification. Dans chaque ligne, `count` est un nombre de messages. Le bloc `policy_evaluated` décrit l’évaluation DMARC, alors que `auth_results` expose les résultats SPF et DKIM sous-jacents. Cette séparation explique les apparentes contradictions. Gardez les deux dans votre export, ainsi que les domaines évalués, avant toute agrégation. Créez une table de travail avec une ligne par groupe observé : organisme déclarant, période, IP, domaine visible, domaine SPF, domaine DKIM, résultats, disposition et volume. Ajoutez ensuite vos propres colonnes : service reconnu, responsable interne, preuve de reconnaissance et action. Ces dernières rendent la table exploitable par une équipe, sans modifier les données reçues. ## Un extrait qui paraît contradictoire Cet exemple fictif est un fragment pédagogique, pas un rapport complet à importer. Les domaines `.example` et l’adresse IP sont réservés à la documentation. ```xml 192.0.2.74 24 none fail fail entreprise.example prestataire.example support pass rebonds.prestataire.example mfrom pass ``` Pour cet exercice, supposons une politique observée `p=none`. Le prestataire réussit ses contrôles bruts, mais ses identités ne correspondent pas au domaine visible de l’entreprise. La règle d’alignement DMARC explique ce résultat : une authentification réussie doit aussi être alignée avec l’identité de l’auteur. Voir la [RFC 9989](https://www.rfc-editor.org/info/rfc9989/). La bonne question est donc : « ce prestataire doit-il envoyer au nom de cette entreprise, et sa configuration personnalisée est-elle complète ? ». Ajouter arbitrairement son IP à une liste de confiance ne répond pas au problème montré par cet extrait. ## Reconnaître un service avec une preuve métier Commencez par les sources que votre inventaire associe à un service interne. Demandez un envoi de test, son identifiant et les en-têtes du message reçu. Rapprochez ces pièces du groupe XML. Une IP appartenant à un grand fournisseur ne suffit pas : plusieurs clients peuvent partager son infrastructure. Pour une source inconnue, cherchez le responsable possible dans les équipes finance, support, marketing et informatique. Un nom de domaine évocateur est une piste, pas une approbation. Documentez la réponse obtenue et la période vérifiée, notamment pour les applications qui n’envoient qu’en fin de mois. Si personne ne reconnaît le flux, conservez-le comme inconnu. Le [guide d’enrichissement IOC pour le SOC](/fr/posts/apis-enrichissement-ioc-triage-soc-faux-positifs) aide à compléter cette enquête avec le contexte des IP et domaines. Ce contexte ne prouve pas qu’une plateforme était autorisée à utiliser votre identité. ## Prioriser selon l’impact observable Attribuez d’abord une action aux flux légitimes qui échouent : propriétaire à solliciter, paramètre à vérifier et test attendu. Précisez le risque métier, par exemple des notifications de support non reçues. Évitez une priorité fondée uniquement sur le volume. Pour une source inconnue dont les messages échouent, ouvrez une investigation ciblée. Examinez si le groupe est nouveau, s’il persiste et si un utilisateur a signalé un message correspondant. Un rapport agrégé ne contient pas nécessairement assez d’informations pour attribuer une campagne ou confirmer le contenu envoyé. Une source inconnue qui réussit mérite également une revue. Cherchez une autorisation oubliée, une intégration déployée sans inventaire ou un usage inattendu d’un service existant. Le succès d’authentification ne remplace pas la validation de son usage. Le [guide général de déploiement DMARC](/fr/posts/authentification-email-dmarc-spf-dkim-securite) présente les étapes de configuration. Pour choisir un durcissement, appuyez-vous sur les flux reconnus et testés, avec une période d’observation couvrant vos usages réels. ## Comparer les périodes sans créer de faux progrès Dédupliquez les rapports avant de sommer leurs volumes. Utilisez l’identité du déclarant et son identifiant de rapport, tout en conservant le domaine et la période pour détecter les anomalies. Si deux fichiers prétendent représenter le même rapport avec des contenus différents, signalez le conflit au lieu de conserver silencieusement le dernier. Comparez ensuite des ensembles de récepteurs équivalents. Une baisse des échecs peut venir d’un fichier manquant ou d’un producteur qui ne rapporte plus. Affichez les rapports attendus et reçus à côté des volumes, afin de distinguer une correction d’une perte de visibilité. Après chaque changement, gardez un tableau avant/après par service et les résultats des essais de réception. Une amélioration globale peut masquer un nouveau problème sur un petit flux. Conservez aussi les écarts encore inexpliqués avec leur propriétaire et une date de revue. Pour une IP ou un domaine inconnu, ouvrez un [rapport IsMalicious](/fr/report) et joignez le résultat daté à la ligne d’investigation. Vous obtenez alors une décision argumentée sur chaque source, tout en laissant aux traces de messagerie le rôle de démontrer l’envoi et la réception. --- # DMARC XML Reports: Interpret Authentication Failures URL: https://ismalicious.com/posts/analyze-dmarc-xml-reports Date: 2026-10-03T07:00:00.000Z Excerpt: Read aggregate DMARC reports, distinguish alignment from authentication, and prioritize anomalies by sending service and business impact. A DMARC XML report becomes useful when each row leads to a decision: fix an authorized sender, investigate an unknown source, or document expected forwarding. The total failure count alone cannot tell you which action to take. A small, misconfigured billing flow may need attention sooner than a large volume of spoofed messages already being rejected. This method turns an aggregate report into a work queue. It does not assume that every recipient produces reports or that the reported messages reached an inbox. ## Check the file before counting Preserve the email carrying the report, its original attachment, and a decompressed working copy. Record the reporting organization, report identifier, affected domain, and reporting period. The file's arrival date is not necessarily the date of the events. Treat the input as an external file. Set limits on its decompressed size and use an XML parser with external entities disabled. [OWASP's XXE prevention guidance](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) explains how a poorly configured parser can access unexpected resources. Reading values from a report does not require network access. Check the actual format received. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines the current aggregate DMARC report format, while some producers may still use the historical format. Report an unsupported format as an import error, not as a report containing zero messages. ## Separate three levels of information The metadata identifies who is reporting and for which period. The published-policy section describes what the receiver observed. The `record` elements group results associated with a source IP and authentication identities. Within each row, `count` is a number of messages. `policy_evaluated` describes the DMARC evaluation, whereas `auth_results` exposes the underlying SPF and DKIM results. This distinction explains apparent contradictions. Keep both blocks in your export, together with the evaluated domains, before aggregating anything. Create a working table with one row per observed group: reporter, period, IP, visible domain, SPF domain, DKIM domain, results, disposition, and volume. Then add your own columns for recognized service, internal owner, evidence of recognition, and action. These make the table usable by a team without modifying the received data. ## An excerpt that appears contradictory This fictional example is an educational fragment, not a complete report ready for import. Its `.example` domains and IP address are reserved for documentation. ```xml 192.0.2.74 24 none fail fail entreprise.example prestataire.example support pass rebonds.prestataire.example mfrom pass ``` For this exercise, assume the observed policy is `p=none`. The provider passes the raw checks, but its identities do not align with the company's visible domain. DMARC's alignment requirement explains the result: successful authentication must also align with the author's identity. See [RFC 9989](https://www.rfc-editor.org/info/rfc9989/). The useful question is therefore: “Should this provider send on the company's behalf, and is its custom-domain configuration complete?” Arbitrarily adding its IP to a trusted list does not address the problem shown in the excerpt. ## Recognize a service through business evidence Start with sources your inventory associates with an internal service. Request a test send, its identifier, and the received message's headers. Match those pieces to the XML group. An IP belonging to a major provider is not sufficient: multiple customers may share its infrastructure. For an unknown source, look for a possible owner in finance, support, marketing, and IT. A suggestive domain name is a lead, not approval. Document the response and the period checked, particularly for applications that send only at month-end. If nobody recognizes the flow, leave its status as unknown. The [SOC IOC enrichment guide](/posts/ioc-enrichment-api-security-operations-guide) helps add context about IP addresses and domains. That context does not prove a platform was authorized to use your identity. ## Prioritize by observable impact First, assign an action to legitimate flows that fail: an owner to contact, a setting to inspect, and an expected test. State the business risk, such as missing support notifications. Avoid assigning priority solely by volume. For an unknown source whose messages fail, open a focused investigation. Check whether the group is new, whether it persists, and whether a user reported a corresponding message. An aggregate report may not contain enough information to attribute a campaign or establish what content was sent. An unknown source that passes deserves review too. Look for a forgotten authorization, an integration deployed outside the inventory, or an unexpected use of an existing service. Successful authentication does not establish that its use was approved. The [DMARC deployment guide](/posts/email-authentication-dmarc-spf-dkim-security) covers configuration steps. When deciding whether to tighten policy, rely on recognized and tested flows, observed over a period that covers your actual usage. ## Compare periods without inventing progress Deduplicate reports before summing their volumes. Use the reporter's identity and report identifier, retaining the domain and period to detect anomalies. If two files claim to be the same report but have different contents, flag the conflict instead of silently keeping the latest one. Compare equivalent sets of receivers. Fewer failures may mean a missing file or a producer that stopped reporting. Display expected and received reports alongside message volumes so that a correction can be distinguished from lost visibility. After each change, keep a before-and-after table by service and the results of reception tests. An overall improvement can conceal a new problem in a small flow. Retain unexplained differences with a responsible owner and a review date. For an unknown IP or domain, open an [IsMalicious report](/report) and attach the dated result to the investigation row. That gives each source an evidence-based decision while leaving mail traces to establish sending and reception. --- # SPF Permerror: Fix the DNS Lookup Limit URL: https://ismalicious.com/posts/spf-permerror-dns-lookup-limit Date: 2026-10-02T07:00:00.000Z Excerpt: Trace SPF dependencies, distinguish permerror from fail, and reduce DNS lookups while testing every sending service. An SPF `permerror` means evaluation encountered a permanent policy or processing problem. It differs from `fail`, which can result from a valid policy that does not authorize the sending IP. Before adding another `include`, identify the specific cause: syntax, competing records, an invalid dependency, or the DNS lookup budget being exceeded. This guide follows an organization using separate services for office mail, billing, support, and campaigns. Its SPF record looks short, yet some messages fail. The goal is to remove the problematic dependency without breaking an infrequent flow such as monthly payment reminders. ## Start with a message that actually fails Obtain the outbound IP address, timestamp, and domain evaluated by the recipient. Use reception traces from a test message or logs from the provider that rejected it. The domain in the visible `From` address is not automatically the domain whose SPF policy was checked. Ask for a successful example from another service as well. Keep the two observations separate: application, envelope domain, IP address, recipient, and result. Without those parameters, a generic validator may describe today's DNS without reproducing the incident. The [email authentication guide](/posts/email-authentication-dmarc-spf-dkim-security) places SPF in its wider context. For this troubleshooting task, keep a narrower question: which evaluation path leads to the observed `permerror`? ## Count evaluated terms, not network packets [RFC 7208, section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) imposes a limit of ten evaluated DNS terms: `include`, `a`, `mx`, `ptr`, `exists`, and `redirect`. Nested dependencies count too. `ip4`, `ip6`, and `all` do not consume this budget. A fast DNS cache does not remove the logical limit. The same section sets other bounds, including lookups that return no usable answer, known as _void lookups_. It recommends limiting those to two. A count below ten therefore does not guarantee a valid policy. Preserve the detailed reason returned by your tool. This fictional policy is used only to explain the diagnostic process: ```text example.com TXT "v=spf1 include:mail.example include:crm.example include:factures.example -all" ``` The `.example` names are not real providers. Assume the complete path through `mail.example` consumes four terms, `crm.example` consumes another four, and `factures.example` consumes three. In this example, those numbers include each parent `include` and its dependencies. An IP recognized early in the first group can pass. A path that needs to evaluate all three groups exceeds ten. [Microsoft's SPF documentation](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) explains that the same policy can succeed for some senders and fail for others, depending on which terms evaluation reaches. ## Build an inventory with named owners Export the published TXT record and the responses for every dependency consulted. Record the time and resolver used. Work with a tool that shows the evaluation path. A bare value of “11” does not tell you which service to remove or which IP was failing. Assign each branch to an internal owner. A supplier contract is not enough: an old integration may still send invoices to a small customer segment. Ask the owner for a recent example and the configuration actually in use. | Fictional branch | Owner to contact | Evidence to obtain | | ---------------- | ---------------- | ---------------------------------------------- | | Office mail | IT team | Test message and return-path domain | | CRM | Sales team | Recent campaign or notification | | Billing | Finance team | Test reminder and invoice | | Old tool | Contract owner | Confirmed shutdown and no remaining dependency | Include backup flows, scheduled jobs, and custom return-path domains. This inventory explains why a service is authorized and makes future removals verifiable. ## Choose a lasting correction The first option is to remove an authorization that is no longer needed, after confirmation from its owner. Preserve the old value in the change ticket and identify the retired flow. Do not remove a branch merely because it did not appear in one day's logs. A second option is to eliminate proven redundancy. Instructions copied from different procedures may cover the same integration, but check the provider's current documentation before combining them. Similar names do not establish identical scope. A third option is to move a service to a dedicated envelope domain, if its platform supports that configuration. Plan the DMARC alignment and reception tests as part of the change. Editing only the main domain's SPF text does not create the new sending path. [Google's SPF troubleshooting documentation](https://knowledge.workspace.google.com/admin/security/troubleshoot-spf-issues) recommends examining nested inclusions and removing references to unused services. Turn that check into a recurring dependency review, with an owner assigned to every branch. ## Assess the maintenance cost of flattening _Flattening_ replaces DNS references with IP addresses calculated at a particular moment. It can reduce the number of queried terms, but transfers responsibility for tracking IP changes to the system publishing that list. Before choosing it, establish who detects provider changes, how quickly they are published, and how to roll back an error. Without that responsibility, the policy may be shorter today and less reliable at the next infrastructure change. Avoid copying a broad network range just to eliminate an error. The policy should represent authorized senders. A wider authorization than necessary can resolve the symptom while changing the trust policy. ## Validate every relevant path Prepare a test matrix before publishing: service, owner, IP or pool, envelope domain, and test recipient. Add an unauthorized case in a local or offline SPF validator to check that the correction did not accidentally broaden the policy. After the change, observe DNS responses and account for the TTL of old values. Repeat the tests from each application, then inspect the results at the receiver. Successful office mail does not validate the billing platform. Keep reputation checks separate. Repairing SPF does not remove a malicious-activity signal or a recipient's private rule. [Monitoring domain reputation changes](/posts/monitor-domain-reputation-changes) can support this follow-up. If a domain or IP appears in a rejection, inspect its [IsMalicious report](/report) and preserve that context alongside the technical test results. --- # SPF permerror : corriger la limite des recherches DNS URL: https://ismalicious.com/fr/posts/spf-permerror-limite-recherches-dns Date: 2026-10-02T07:00:00.000Z Excerpt: Reconstituez les dépendances SPF, distinguez permerror et fail, puis réduisez les recherches DNS avec des tests pour chaque service d’envoi. Un résultat SPF `permerror` indique que l’évaluation a rencontré un problème permanent de politique ou de traitement. Ce n’est pas le même résultat que `fail`, qui peut correspondre à une politique valide n’autorisant pas l’IP émettrice. Avant d’ajouter un nouvel `include`, identifiez donc la cause précise : syntaxe, enregistrements concurrents, dépendance invalide ou dépassement du budget DNS. Le cas étudié ici est celui d’une entreprise qui cumule messagerie, facturation, support et campagnes. Son enregistrement semble court, pourtant certains envois échouent. L’objectif est de retirer la dépendance responsable sans casser un flux rarement utilisé, comme les relances mensuelles. ## Partir d’un envoi qui échoue réellement Récupérez l’IP de sortie, l’heure et le domaine évalué par le destinataire. Utilisez les traces de réception d’un message de test ou celles du prestataire qui l’a refusé. Le domaine de l’adresse visible dans `From` n’est pas automatiquement celui dont le SPF a été évalué. Demandez aussi un exemple réussi issu d’un autre service. Les deux observations doivent rester distinctes : application, domaine d’enveloppe, IP, destinataire et résultat. Si vous ne connaissez pas ces paramètres, un validateur générique peut décrire le DNS actuel sans reproduire l’incident. Le [guide d’authentification e-mail](/fr/posts/authentification-email-dmarc-spf-dkim-securite) permet de remettre SPF dans son contexte. Pour ce dépannage, gardez une question plus étroite : quel parcours d’évaluation mène au `permerror` observé ? ## Compter les termes évalués, pas les paquets réseau La [RFC 7208, section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) impose une limite de dix termes DNS évalués : `include`, `a`, `mx`, `ptr`, `exists` et `redirect`. Les dépendances imbriquées comptent aussi. `ip4`, `ip6` et `all` n’entrent pas dans ce budget. Un cache DNS rapide ne supprime pas cette limite logique. La même section prévoit d’autres bornes, notamment pour les recherches sans réponse exploitable, dites _void lookups_. Elle recommande de les limiter à deux. Un compteur inférieur à dix ne suffit donc pas à garantir une politique valide. Conservez le motif détaillé retourné par votre outil. Voici une politique fictive, utilisée uniquement pour expliquer le diagnostic : ```text example.com TXT "v=spf1 include:mail.example include:crm.example include:factures.example -all" ``` Les noms `.example` ne sont pas des prestataires réels. Supposons que le parcours complet de `mail.example` consomme quatre termes, celui de `crm.example` quatre autres, et celui de `factures.example` trois. Ces nombres incluent, dans cet exemple, chaque `include` parent et ses dépendances. Une IP reconnue rapidement dans le premier groupe peut réussir. Un parcours qui doit examiner les trois groupes dépasse dix. La [documentation Microsoft sur SPF](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) rappelle qu’une même politique peut ainsi réussir pour certains expéditeurs et échouer pour d’autres, selon les termes atteints pendant l’évaluation. ## Produire un inventaire avec des responsables Exportez le TXT publié et les réponses de chaque dépendance consultée. Notez l’heure et le résolveur utilisés. Travaillez avec un outil capable d’afficher le détail du parcours ; une simple valeur « 11 » ne dit pas quel service supprimer ni quelle IP échouait. Associez chaque branche à un propriétaire interne. Le contrat avec un fournisseur ne suffit pas : une ancienne intégration peut encore envoyer les factures d’un petit segment de clients. Demandez au responsable un exemple récent d’envoi et la configuration réellement utilisée. | Branche fictive | Responsable à contacter | Preuve à obtenir | | ---------------------- | ----------------------- | ------------------------------------------------ | | Messagerie bureautique | Équipe informatique | Message de test et domaine de retour | | CRM | Équipe commerciale | Campagne ou notification récente | | Facturation | Équipe finance | Relance et facture de test | | Ancien outil | Propriétaire du contrat | Arrêt confirmé et absence de dépendance restante | Ajoutez les flux de secours, les tâches programmées et les domaines de retour personnalisés. Ce travail d’inventaire explique pourquoi un service est autorisé ; il rend les futures suppressions vérifiables. ## Choisir une correction durable La première option est de retirer une autorisation devenue inutile, après confirmation de son propriétaire. Conservez l’ancienne valeur dans le ticket de changement et indiquez le flux qui a été décommissionné. Ne retirez pas une branche seulement parce qu’elle n’apparaît pas dans une journée de journaux. Une deuxième option consiste à supprimer une redondance démontrée. Deux instructions copiées de procédures différentes peuvent couvrir la même intégration, mais vérifiez la documentation actuelle du prestataire avant de les fusionner. Une ressemblance de noms n’établit pas que leurs périmètres sont identiques. Une troisième option est d’isoler un service sur un domaine d’enveloppe dédié, lorsque sa plateforme le permet. Planifiez alors aussi l’alignement DMARC et les tests de réception. Changer le seul texte SPF du domaine principal ne crée pas ce nouveau trajet d’envoi. La [documentation Google de dépannage SPF](https://knowledge.workspace.google.com/admin/security/troubleshoot-spf-issues) conseille notamment d’examiner les inclusions imbriquées et de retirer les références aux services inutilisés. Utilisez ce contrôle comme une revue régulière de dépendances, avec un propriétaire pour chaque branche. ## Évaluer le coût du flattening Le _flattening_ remplace des références DNS par des adresses IP calculées à un instant donné. Il peut réduire le nombre de termes interrogés, mais transfère la maintenance des changements d’IP vers le système qui publie cette liste. Avant de retenir cette solution, demandez qui détecte une modification chez le prestataire, combien de temps elle met à être publiée et comment revenir en arrière après une erreur. Si personne ne porte cette responsabilité, la politique sera plus courte aujourd’hui et moins fiable au prochain changement d’infrastructure. Évitez aussi de recopier une grande plage réseau pour faire disparaître une erreur. L’objectif est de représenter les expéditeurs autorisés. Une autorisation plus large que nécessaire peut résoudre le symptôme tout en changeant la politique de confiance. ## Valider tous les parcours utiles Préparez une matrice d’essais avant la publication : service, propriétaire, IP ou pool utilisé, domaine d’enveloppe et destinataire de test. Ajoutez un cas non autorisé dans un validateur SPF local ou hors envoi, afin de vérifier que la correction n’a pas élargi la politique par accident. Après le changement, observez les réponses DNS et tenez compte du TTL des anciennes valeurs. Refaites les essais avec chaque application, puis contrôlez les résultats reçus. Un succès depuis la messagerie principale ne valide pas la plateforme de facturation. Gardez enfin un contrôle séparé de la réputation. Réparer SPF ne supprime pas un signal lié à une activité malveillante ni une règle privée du destinataire. La [surveillance des changements de réputation](/fr/posts/surveiller-reputation-domaine-alertes) peut accompagner ce suivi. Si un domaine ou une IP apparaît dans un refus, consultez son [rapport IsMalicious](/fr/report) et conservez ce contexte avec le résultat technique de vos essais. --- # Erreur SMTP 550 5.7.1 : trouver la cause du rejet URL: https://ismalicious.com/fr/posts/erreur-smtp-550-5-7-1-reputation Date: 2026-10-01T07:00:00.000Z Excerpt: Un rejet 550 5.7.1 peut venir de la politique destinataire, de l’authentification ou de la réputation. Retrouvez la cause avec les bonnes traces. L’erreur SMTP `550 5.7.1` ne suffit pas à conclure que votre adresse IP a mauvaise réputation. Le serveur destinataire a refusé le message, mais la raison exploitable se trouve dans le texte complet du rejet et dans le trajet de l’envoi. Demander un retrait de liste avant d’identifier ce serveur peut vous faire traiter le mauvais problème. Le diagnostic ci-dessous part d’un avis de non-remise et aboutit à un test de correction. Il convient aux équipes qui gèrent leur propre serveur comme à celles qui utilisent un prestataire : dans ce second cas, certaines traces devront être demandées au support. ## Lire l’avis complet et retrouver l’envoi Conservez le message de non-remise original, souvent appelé NDR ou DSN. Relevez l’heure, le destinataire concerné, le serveur qui a refusé, le diagnostic SMTP complet et l’identifiant de l’envoi dans votre plateforme. Plusieurs destinataires d’un même message peuvent avoir reçu des résultats différents. Ne confondez pas le serveur qui vous remet l’avis d’échec avec celui qui a pris la décision. Le premier peut simplement retransmettre le refus du second. Dans le journal sortant, recherchez la tentative correspondante et l’adresse IP effectivement utilisée. Une machine possède parfois plusieurs sorties, notamment après une migration ou via un pool partagé. La [documentation Microsoft consacrée à 550 5.7.1](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-550-5-7-1-in-exchange-online) présente plusieurs causes, dont des restrictions de réception et des problèmes de routage ou d’autorisation. Ce code sert donc de point d’entrée au diagnostic, sans désigner à lui seul une liste de blocage. ## Construire une ligne d’incident exploitable L’exemple suivant est fictif. Les domaines et l’adresse IP sont réservés à la documentation ; le texte illustre un journal simplifié et n’est pas un code propre à un fournisseur. ```text heure : 2026-09-29T08:20:00Z application : facturation id_envoi : TEST-204 sortie_smtp : 192.0.2.52 destination : comptabilite@client.example serveur_rejet : mx.client.example phase : fin de DATA diagnostic : 550 5.7.1 Message refused by recipient policy ``` Cette ligne permet de demander une vérification précise : « pouvez-vous retrouver TEST-204 vers cette boîte à cette heure ? ». Elle ne justifie pas encore « notre IP est blacklistée ». L’administrateur destinataire peut reconnaître une règle sur les pièces jointes ou un expéditeur interdit, tandis que votre fournisseur vérifie la sortie réelle. Ajoutez à cette ligne la dernière réussite connue, le premier échec et les modifications intervenues entre les deux. Un changement de plateforme, de domaine de retour ou de modèle de facture devient alors une hypothèse testable. Une liste de changements datés vaut mieux qu’une série d’essais improvisés. ## Orienter l’enquête avec le texte du refus | Indice présent dans le diagnostic | Première vérification utile | | -------------------------------------------------- | -------------------------------------------------------- | | Liste ou service de réputation explicitement nommé | Vérifier l’IP ou le domaine cité auprès de cette source | | SPF, DKIM ou DMARC mentionné | Examiner l’identité d’envoi et les résultats du contrôle | | Relais interdit ou authentification requise | Contrôler le connecteur et l’autorisation de transport | | Règle de transport ou politique du destinataire | Faire retrouver la règle dans les journaux de réception | | Contenu ou format rejeté | Comparer un message minimal et le message concerné | Cette table organise les recherches ; elle ne remplace pas la terminologie du fournisseur. Google publie par exemple plusieurs diagnostics associés à `550 5.7.1`, avec des motifs différents, dans sa [liste des erreurs SMTP Gmail](https://support.google.com/mail/answer/3726730?hl=en). Conservez la phrase qui accompagne le code au lieu de la supprimer dans le ticket. Vérifiez aussi l’étendue de l’incident. Une seule adresse touchée oriente vers une restriction locale. Plusieurs destinataires d’un même domaine orientent vers sa passerelle ou sa politique. Plusieurs domaines touchés par une seule application orientent vers son trajet d’envoi. Ces observations priorisent les tests, mais ne constituent pas une preuve définitive. ## Séparer l’authentification de la réputation Pour l’authentification, travaillez sur un message récent du même flux, avec les mêmes paramètres, reçu par une boîte de test que vous contrôlez. Relevez les domaines évalués, pas seulement les mots `pass` ou `fail`. Un service marketing et votre messagerie bureautique peuvent utiliser des identités différentes malgré un nom visible identique. Le [guide SPF, DKIM et DMARC](/fr/posts/authentification-email-dmarc-spf-dkim-securite) donne les repères nécessaires. Comparez ensuite la configuration attendue par le prestataire et le DNS publié. Évitez de modifier simultanément plusieurs domaines ou de retirer une protection pour voir si « cela passe » : vous perdriez la relation entre changement et résultat. Pour la réputation, recherchez l’indicateur exact mentionné dans le refus. Une réputation de domaine web et une réputation d’IP SMTP ne décrivent pas nécessairement le même risque. Le [guide de réputation e-mail](/fr/posts/verifier-reputation-email-securite-messagerie) aide à distinguer les objets examinés. Une source externe peut apporter du contexte sans connaître la politique privée du destinataire. Si votre IP est partagée, demandez au prestataire de confirmer sa responsabilité et l’action prévue. Si vous contrôlez cette IP, cherchez d’abord une activité d’envoi inattendue : compte compromis, application détournée, file d’attente inhabituelle ou ancien service encore actif. Un retrait de liste ne corrige pas la cause qui a déclenché le signal. ## Tester une correction, une variable à la fois Préparez un essai limité avec un destinataire volontaire. Utilisez le même flux que celui en échec et un contenu reconnu comme attendu. Notez exactement ce qui a changé : connecteur corrigé, signature activée, destinataire autorisé ou problème de réputation traité. Conservez le nouvel identifiant d’envoi, le résultat SMTP et, en cas de réception, les en-têtes du message arrivé. L’acceptation par un relais intermédiaire n’établit pas à elle seule la présence dans la boîte de réception. Vérifiez également si le message a été classé en courrier indésirable ou en quarantaine. Ne relancez pas toute la file sur la base d’un seul résultat ambigu. Déterminez quels messages ont réellement échoué et lesquels ont déjà été délivrés. Un rejeu doit éviter les doubles factures, doubles notifications ou demandes de validation répétées. ## Préparer l’escalade lorsque la cause reste opaque Un ticket utile contient le diagnostic intégral, les heures avec fuseau, les identifiants de trace, la sortie SMTP et un exemple représentatif expurgé des données inutiles. Indiquez les domaines touchés, les réussites comparables et le test réalisé. Demandez la règle ou la catégorie précise à l’origine du refus. La clôture doit nommer la cause démontrée et la preuve de rétablissement. Si la passerelle destinataire conserve un motif privé, écrivez cette limite et le résultat de ses vérifications. Pour examiner le contexte public de l’indicateur cité, ouvrez un [rapport IP ou domaine](/fr/report). Utilisez-le dans l’escalade comme un élément daté, sans promettre qu’un score favorable fera accepter les prochains messages. --- # SMTP 550 5.7.1: Find the Cause of an Email Rejection URL: https://ismalicious.com/posts/smtp-550-5-7-1-rejection-diagnosis Date: 2026-10-01T07:00:00.000Z Excerpt: A 550 5.7.1 rejection can involve recipient policy, authentication, or reputation. Use the full diagnostic and delivery traces to find the cause. SMTP error `550 5.7.1` does not establish that your IP address has a poor reputation. The receiving server refused the message, but the specific reason is in the full rejection text and the delivery path. Requesting removal from a blocklist before identifying that server can send you after the wrong problem. This diagnostic process starts with a non-delivery notice and ends with a correction test. It applies both to teams running their own servers and to those using a provider. In the latter case, support may need to supply some of the traces. ## Read the full notice and locate the send Preserve the original non-delivery message, often called an NDR or DSN. Record the time, affected recipient, rejecting server, complete SMTP diagnostic, and the send identifier in your platform. Different recipients of the same message may have received different outcomes. Distinguish the server delivering the failure notice from the one that made the decision. The former may simply be passing on the latter's rejection. Find the corresponding attempt in outbound logs and identify the IP address actually used. A system may have multiple outbound paths, particularly after a migration or through a shared pool. [Microsoft's documentation for 550 5.7.1](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-550-5-7-1-in-exchange-online) covers several causes, including recipient restrictions and routing or authorization problems. Treat the code as the start of the investigation; it does not identify a particular blocklist. ## Build an incident record The following example is fictional. Its domains and IP address are reserved for documentation. The text illustrates a simplified log, not a provider-specific error. ```text time: 2026-09-29T08:20:00Z application: billing send_id: TEST-204 outbound_smtp_ip: 192.0.2.52 recipient: comptabilite@client.example rejecting_server: mx.client.example stage: end of DATA diagnostic: 550 5.7.1 Message refused by recipient policy ``` This record supports a specific request: “Can you locate TEST-204 to this mailbox at this time?” It does not yet justify “our IP is blocklisted.” The recipient administrator may find an attachment rule or a prohibited sender, while your provider verifies the outbound path. Add the last known success, first failure, and changes between them. A platform migration, a changed return-path domain, or a new invoice template then becomes a testable hypothesis. A dated change history is more useful than a series of improvised attempts. ## Use the rejection text to direct the investigation | Diagnostic clue | Useful first check | | --------------------------------------- | ------------------------------------------------------- | | A named list or reputation service | Check the specified IP or domain with that source | | SPF, DKIM, or DMARC mentioned | Examine the sending identity and authentication results | | Relay denied or authentication required | Check the connector and transport authorization | | Transport rule or recipient policy | Have the recipient locate the rule in receiving logs | | Content or formatting rejected | Compare a minimal message with the affected message | This table organizes the investigation; retain the provider's terminology when applying it. Google, for example, documents several `550 5.7.1` diagnostics with different causes in its [Gmail SMTP error list](https://support.google.com/mail/answer/3726730?hl=en). Keep the explanatory sentence alongside the code in your ticket. Establish the incident's scope as well. One affected address points toward a local restriction. Multiple recipients at one domain point toward that domain's gateway or policy. Several domains affected by one application point toward the application's sending path. These observations prioritize tests but are not definitive proof. ## Separate authentication from reputation For authentication, use a recent message from the same sending flow, with the same settings, received by a test mailbox you control. Record the evaluated domains, not just `pass` or `fail`. Your marketing service and office mail can use different identities even when their visible display names match. The [SPF, DKIM, and DMARC guide](/posts/email-authentication-dmarc-spf-dkim-security) provides the necessary background. Compare the provider's expected configuration with the published DNS. Avoid changing several domains at once or removing a protection merely to see whether delivery works. That would obscure the relationship between the change and its result. For reputation, investigate the exact indicator named in the refusal. A web domain's reputation and an SMTP IP's reputation do not necessarily describe the same risk. The [email reputation guide](/posts/email-reputation-check-security-guide) helps distinguish these objects. An external source can provide context without knowing the recipient's private policy. If your IP is shared, ask the provider to confirm its responsibility and planned action. If you control the IP, first look for unexpected sending activity: a compromised account, an abused application, an unusual queue, or an old service still operating. Delisting does not fix the behavior that caused the listing. ## Test one correction at a time Prepare a limited test with a willing recipient. Use the same flow that failed and content the recipient expects. Record exactly what changed: a corrected connector, enabled signing, authorized recipient, or resolved reputation issue. Preserve the new send identifier, SMTP result, and, if delivered, the received message's headers. Acceptance by an intermediate relay alone does not establish that the message reached the inbox. Check whether it was placed in spam or quarantine as well. Do not replay the entire queue based on one ambiguous result. Determine which messages actually failed and which were already delivered. A replay should avoid duplicate invoices, notifications, or approval requests. ## Prepare an escalation when the cause remains unclear A useful ticket includes the complete diagnostic, timestamps with time zone, trace identifiers, outbound SMTP IP, and a representative example stripped of unnecessary data. List affected domains, comparable successes, and the test performed. Ask for the specific rule or category responsible for the rejection. Close the incident by naming the demonstrated cause and the evidence of recovery. If the receiving gateway keeps its reason private, record that limitation and the outcome of its checks. To examine the public context of a named indicator, open an [IP or domain report](/report). Include it in the escalation as dated evidence, without suggesting that a favorable score will make the recipient accept future messages. --- # Analyser les en-têtes d’un e-mail suspect URL: https://ismalicious.com/fr/posts/analyser-entetes-email-phishing Date: 2026-09-30T07:00:00.000Z Excerpt: Identifiez les serveurs fiables, interprétez Authentication-Results et reliez un e-mail suspect à ses liens sans confondre identité et contenu. Pour analyser les en-têtes d’un e-mail suspect, commencez par déterminer qui a ajouté chaque information. Un nom de dirigeant dans `From`, une mention `spf=pass` ou une longue chaîne de relais ne valent rien sans cette attribution. La question utile est précise : quelle passerelle fiable a observé quelle identité, depuis quelle connexion ? Cette méthode sert au triage d’un message reçu. Elle complète le [guide d’authentification SPF, DKIM et DMARC](/fr/posts/authentification-email-dmarc-spf-dkim-securite) en se concentrant sur les preuves à conserver et sur les décisions possibles lorsque les résultats semblent contradictoires. ## Conserver le message original Exportez le message au format proposé par votre messagerie, avec ses en-têtes complets. Un transfert ordinaire peut remplacer les informations de transport par celles du nouvel envoi. Une capture d’écran conserve le leurre visible, mais elle ne suffit pas pour reconstruire sa réception. Gardez une copie intacte et une copie de travail. Notez la boîte concernée, l’heure de réception, le fuseau horaire et l’identifiant de votre dossier. Si une passerelle a déjà classé le message, conservez son identifiant de trace. Vous pourrez ainsi retrouver la décision appliquée sans dépendre d’un copier-coller partiel. Ne collez pas l’ensemble du message dans un service public d’analyse. Les en-têtes peuvent contenir des adresses personnelles et des détails d’infrastructure ; le corps peut inclure des documents ou des liens individualisés. Pour un contrôle de réputation externe, commencez par l’indicateur nécessaire, par exemple le domaine d’un lien. ## Trouver le point d’entrée fiable Les relais SMTP ajoutent leurs lignes `Received` en tête du message : la partie haute décrit donc les étapes les plus récentes. Ce mécanisme de trace est défini dans la [RFC 5321, section 4.4](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.4). Il ne garantit pas que toutes les lignes reçues étaient authentiques avant leur arrivée dans votre infrastructure. Repérez d’abord les relais de votre organisation et ceux de son prestataire de messagerie. Descendez jusqu’à la ligne qui décrit la réception depuis Internet. Comparez son adresse IP et son heure aux journaux de la passerelle. À partir de cette frontière, les déclarations des relais précédents exigent une corroboration. Cette lecture évite une erreur fréquente : considérer la ligne la plus ancienne comme l’origine certaine du message. Un expéditeur peut préparer de faux champs avant l’envoi. Même une chaîne cohérente en apparence ne permet pas de remonter jusqu’au poste d’un auteur sans traces supplémentaires. ## Lire un exemple avec trois identités différentes Voici un extrait fictif et simplifié. Les domaines `.example` et l’IP de documentation ne représentent aucun expéditeur réel. ```text From: Direction achats Reply-To: factures@paiement.example Return-Path: Authentication-Results: mx.destinataire.example; spf=pass smtp.mailfrom=routeur.example; dkim=pass header.d=routeur.example; dmarc=fail header.from=entreprise.example Received: from sortie.routeur.example (192.0.2.40) by mx.destinataire.example with ESMTPS; Tue, 29 Sep 2026 08:15:00 +0000 ``` Supposons que `mx.destinataire.example` soit votre passerelle reconnue et que ses journaux confirment la réception. Trois questions restent séparées : l’adresse à laquelle le lecteur pense répondre, l’identité contrôlée lors du transport et celle présentée dans le champ visible. Le champ `Reply-To` propose une autre destination de réponse. Cette différence mérite une explication métier, mais les outils de support et certaines plateformes l’utilisent aussi. Dans le dossier, écrivez « réponse dirigée vers un autre domaine », puis vérifiez si cette configuration était attendue. Écrire directement « adresse de l’attaquant » dépasserait les preuves. Les résultats SPF et DKIM concernent ici `routeur.example`. Le résultat DMARC échoue pour `entreprise.example`. Ce contraste n’est pas une contradiction : les contrôles n’évaluent pas tous la même identité. La définition actuelle de DMARC relie le domaine visible à une authentification alignée, comme l’explique la [RFC 9989](https://www.rfc-editor.org/info/rfc9989/). Dans notre scénario, demandez au propriétaire du service d’envoi si ce routeur est autorisé et correctement configuré. Une erreur d’intégration et une usurpation peuvent produire des traces voisines. Le contenu du message, les journaux et la confirmation métier permettent de les départager. ## Ne retenir que les résultats de la bonne passerelle Un message peut comporter plusieurs champs `Authentication-Results`. Identifiez le service qui les a écrits, puis vérifiez que votre architecture lui accorde confiance. La [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) encadre précisément cette frontière et le traitement des champs ajoutés en dehors d’elle. La présence du nom de votre serveur dans un champ n’est pas, seule, une preuve. Consultez la trace du message et la configuration d’assainissement des en-têtes si vous avez un doute. Un résultat copié dans le corps, placé dans un message joint ou conservé depuis un autre trajet ne décrit pas nécessairement la réception étudiée. Comparez ensuite les contrôles au chemin réellement emprunté. Un transfert ou une liste de diffusion peut modifier la situation observée à l’arrivée. Si ce parcours existe, demandez les traces intermédiaires avant de conclure à une falsification. Consignez les pièces manquantes au lieu de transformer un résultat incomplet en certitude. ## Examiner la demande après l’authentification Une fois les identités clarifiées, revenez au geste demandé : transmettre un document, saisir un mot de passe, approuver une connexion ou modifier un compte bancaire. Un message correctement authentifié peut être frauduleux si un compte légitime est compromis ou si le domaine appartient à l’expéditeur malveillant. Relevez les domaines des liens sans les ouvrir dans une session de travail. Distinguez le texte affiché de la destination, puis gardez le chemin utile dans le dossier. Le [guide de vérification d’un domaine de phishing](/fr/posts/phishing-explique-verifier-domaine-menaces) aide à examiner cette seconde partie de l’enquête. Une demande inhabituelle doit aussi être confirmée par un canal déjà connu, indépendamment des coordonnées du message. Si l’utilisateur a cliqué, changez le périmètre de l’analyse. Les en-têtes expliquent la réception, pas ce que le navigateur a fait ensuite. Recherchez les connexions, téléchargements ou authentifications correspondants. La [corrélation entre IOC, DNS et processus](/fr/posts/alerte-ioc-correler-ip-dns-processus) décrit cette étape. ## Écrire une conclusion qui permet d’agir Une conclusion utile distingue l’observation, l’interprétation et l’action. Par exemple : « passerelle confirmée ; authentification alignée en échec ; routeur non reconnu ; demande de paiement non validée ; message maintenu en quarantaine et propriétaire métier sollicité ». Ce texte dit ce qui manque et évite une clôture fondée sur un seul voyant. Si le message est légitime, documentez le service responsable et la correction nécessaire avant toute exception. S’il est frauduleux, conservez les identifiants permettant de rechercher les autres destinataires. Pour enrichir les domaines et IP extraits, consultez un [rapport IsMalicious](/fr/report), puis joignez le résultat daté aux preuves de réception. La réputation complète l’enquête ; elle ne remplace pas les traces du message. --- # How to Analyze Suspicious Email Headers URL: https://ismalicious.com/posts/analyze-suspicious-email-headers Date: 2026-09-30T07:00:00.000Z Excerpt: Identify trusted servers, interpret Authentication-Results, and investigate a suspicious email without confusing authentication with safe content. To analyze a suspicious email's headers, first establish who added each piece of information. An executive's display name in `From`, an `spf=pass` result, or a long relay chain means little without that attribution. Ask a specific question: which trusted gateway observed which identity, through which connection? This method supports the triage of a received message. It complements the [SPF, DKIM, and DMARC authentication guide](/posts/email-authentication-dmarc-spf-dkim-security) by focusing on the evidence to preserve and the decisions available when results appear contradictory. ## Preserve the original message Export the message in your mail client's supported format, including its full headers. Ordinary forwarding can replace transport information with details of the new delivery. A screenshot preserves the visible lure, but cannot reconstruct how the original arrived. Keep an untouched copy and a working copy. Record the affected mailbox, reception time, time zone, and case identifier. If a gateway has already classified the message, preserve its trace identifier. That lets you retrieve the actual decision without relying on a partial copy of the headers. Do not paste the whole message into a public analysis service. Headers can contain personal addresses and infrastructure details; the body may include documents or individualized links. For an external reputation check, start with the indicator you need, such as a link's domain. ## Find the trusted entry point SMTP relays prepend their `Received` headers, so the top of the message describes the most recent steps. [RFC 5321, section 4.4](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.4) defines this trace mechanism. It does not guarantee that every header was authentic before the message reached your infrastructure. Identify your organization's relays and those of its mail provider. Work down to the header describing reception from the Internet. Compare its IP address and timestamp with gateway logs. Beyond that boundary, statements made by earlier relays need corroboration. This approach avoids a common mistake: treating the oldest header as the message's proven origin. A sender can prepare false headers before transmission. Even a plausible relay chain cannot identify the author's endpoint without additional evidence. ## Read an example with three different identities The following is a simplified fictional excerpt. Its `.example` domains and documentation IP address do not represent a real sender. ```text From: Purchasing team Reply-To: factures@paiement.example Return-Path: Authentication-Results: mx.destinataire.example; spf=pass smtp.mailfrom=routeur.example; dkim=pass header.d=routeur.example; dmarc=fail header.from=entreprise.example Received: from sortie.routeur.example (192.0.2.40) by mx.destinataire.example with ESMTPS; Tue, 29 Sep 2026 08:15:00 +0000 ``` Assume `mx.destinataire.example` is your recognized gateway and its logs confirm reception. Keep three questions separate: where a reader's reply would go, which identity was checked during transport, and which identity appears in the visible sender field. `Reply-To` directs replies elsewhere. That difference needs a business explanation, but support tools and other platforms use it legitimately. Record “replies directed to another domain,” then check whether this was expected. Calling it “the attacker's address” would go beyond the evidence. Here, the SPF and DKIM results concern `routeur.example`, while DMARC fails for `entreprise.example`. These results are not contradictory: the checks do not all evaluate the same identity. DMARC connects the visible domain to aligned authentication, as described in [RFC 9989](https://www.rfc-editor.org/info/rfc9989/). In this scenario, ask the sending service's owner whether that mailer is authorized and correctly configured. An integration error and impersonation can leave similar traces. The message's content, logs, and business confirmation help distinguish them. ## Use results from the right gateway A message can contain several `Authentication-Results` headers. Identify the service that wrote each one and establish whether your architecture trusts it. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) addresses this boundary and the handling of headers added outside it. Your server's name appearing in a header is not sufficient evidence. Check the message trace and the header-sanitization configuration if there is doubt. A result copied into the body, placed in an attached message, or retained from a different route may not describe the reception you are investigating. Next, compare the checks with the route the message actually took. Forwarding or a mailing list can alter what the final receiver observes. Where such a route exists, request the intermediate traces before concluding that a header was forged. Record missing evidence instead of treating incomplete results as certainty. ## Examine the request after authentication Once the identities are clear, return to the requested action: sending a document, entering a password, approving a login, or changing bank details. A correctly authenticated message can still be fraudulent if a legitimate account was compromised or the domain belongs to a malicious sender. Extract link domains without opening them in a work session. Distinguish the displayed text from the actual destination, and preserve the relevant path in the case record. The [guide to checking phishing domains](/posts/phishing-explained-check-domain-threats) covers this part of the investigation. Confirm unusual requests through an established channel, independently of the contact details supplied in the message. If the user clicked, expand the investigation. Headers explain reception, not what the browser did afterward. Look for associated connections, downloads, or authentications. The [guide to correlating IOCs, DNS, and processes](/posts/investigate-ioc-alert-ip-dns-process) describes that next step. ## Write a conclusion that supports action A useful conclusion separates observations, interpretation, and action. For example: “gateway confirmed; aligned authentication failed; mailer unrecognized; payment request unverified; message remains quarantined while the business owner is contacted.” This identifies the missing evidence and avoids closing the case based on one status indicator. If the message is legitimate, document the responsible service and the required correction before granting an exception. If it is fraudulent, retain identifiers that let you search for other recipients. To enrich extracted domains and IP addresses, open an [IsMalicious report](/report), then attach the dated result to the reception evidence. Reputation adds context; the message traces establish what happened. --- # Accès distant des prestataires du secteur public : guide URL: https://ismalicious.com/fr/posts/acces-distant-prestataires-secteur-public Date: 2026-09-18T09:00:00.000Z Excerpt: Encadrez les accès prestataires avec identités nominatives, créneaux approuvés, chemins limités et révocation vérifiée, grâce à un exemple de collectivité. **Un accès distant prestataire dans le secteur public doit prendre fin lorsque le travail autorisé se termine.** Une date d’expiration sur un compte ne suffit pas. L’institution doit connaître la personne connectée, le service qu’elle peut modifier, les sessions encore actives et le responsable capable de retirer l’accès sans interrompre les opérations essentielles. Un contrat peut durer plusieurs années alors qu’un technicien intervient pendant quatre-vingt-dix minutes. Ce sont deux autorisations distinctes. Le processus proposé transforme chaque intervention en créneau doté d’un responsable, de limites observables et d’une clôture vérifiable. Son exemple municipal est fictif et ne décrit ni architecture cliente ni résultat mesuré. ## Suivre tout le chemin avant d’approuver le compte Cartographiez le trajet du poste du technicien jusqu’à l’opération finale : fournisseur d’identité du prestataire, authentification de la collectivité, VPN ou courtier d’accès, bastion et rôle d’administration applicatif. Une clé API créée dans l’application peut ouvrir un autre chemin avec une durée différente. Pour chaque étape, identifiez qui accorde l’accès, qui le retire et quelle preuve démontre ce retrait. Le prestataire peut désactiver l’identité de son salarié sans contrôler un jeton délivré par la collectivité. Inversement, celle-ci peut fermer un chemin réseau tandis qu’une session d’administration cloud distincte reste utilisable. Séparez maintenance interactive et connexions automatisées. Une intégration nocturne nécessite une identité de service et un cycle de gestion des secrets ; elle ne doit pas emprunter le compte d’un technicien. Ce mélange complique le départ urgent d’un salarié, car retirer ses droits risque d’interrompre la production. Placez les dépendances métier à côté du chemin. Le [plan de sécurité réseau des collectivités](/fr/posts/securite-reseau-collectivites-locales) montre comment attribuer les responsabilités et vérifier la continuité. La décision devient précise : quelle partie de ce service cette personne peut-elle atteindre pendant cette intervention ? ## Définir un créneau applicable par l’exploitant Les [questions d’assurance fournisseurs du NCSC](https://www.ncsc.gov.uk/guidance/supplier-assurance-questions) invitent à examiner limitation, contrôle et surveillance des accès, accords de support distant et journalisation des sessions. La fiche suivante traduit ces questions en proposition de transmission opérationnelle entre institution et prestataire. ```text Changement : mise à jour du connecteur de collecte des déchets Responsable métier et suppléant : contacts de la collectivité Technicien : identité individuelle vérifiée Objectif : modifier la configuration et vérifier la transmission Début/fin : date explicite, horaires UTC et affichage local Cibles : interface d’administration approuvée uniquement Actions : configuration et vérification d’un traitement fictif Transfert : dépôt de paquets approuvé Arrêt : responsable de permanence ou directeur d’incident Clôture : administrateur d’accès identifié Preuves : session terminée, rôle temporaire retiré, secrets délivrés recensés, tentative refusée ``` Ajoutez les conditions du poste et d’authentification réellement vérifiables. « Poste sécurisé » est trop vague pour accepter ou refuser une connexion. Précisez source de preuve, fraîcheur attendue et conduite à tenir lorsque l’information manque. Cette fiche ne remplace pas les conditions contractuelles ou juridiques. Vérifiez que le contrat prévoit notifications, changements d’intervenants, approbation des sous-traitants et remise des preuves. Sinon, l’équipe technique risque de devoir imposer des conditions auxquelles le fournisseur n’a jamais consenti. Définissez les prolongations. Un retard n’étend pas silencieusement l’autorisation initiale. Le responsable métier ou son suppléant habilité choisit poursuite, réduction du périmètre ou rétablissement précédent. Enregistrez la nouvelle échéance et vérifiez sa transmission au mécanisme de contrôle. ## Préparer personne, poste et procédure de retrait Vérifiez le technicien auprès d’un contact fournisseur établi auparavant. N’acceptez pas une nouvelle identité ou un numéro de téléphone simplement parce qu’ils figurent dans une demande urgente. Vérifiez si l’intervenant appartient au cocontractant ou à un sous-traitant soumis à approbation. Attribuez une identité individuelle pour le travail prévu. Séparez rôles élevés et collaboration ordinaire, puis appliquez la politique d’authentification de l’institution. Pour les accès privilégiés, privilégiez une authentification résistante au phishing lorsque l’architecture le permet. Toute exception comporte responsable et échéance. Avant activation, demandez comment le prestataire signalera départ, changement de fonction ou perte du poste. Désignez destinataire et responsable du traitement. Une revue annuelle ne convient pas à une permission dépendant de la situation actuelle d’une personne. Testez la procédure de retrait avec une identité de test dès l’intégration. Découvrir à la fin d’une intervention réelle que les sessions applicatives restent actives oblige la collectivité à négocier une faiblesse après l’ouverture de l’accès. Les logiciels compromis et dépendances fournisseurs relèvent plus largement de [l’évaluation des risques de chaîne d’approvisionnement](/fr/posts/detection-attaques-chaine-approvisionnement-risque-tiers). Ce processus traite les droits des personnes réalisant une intervention autorisée sur un service. ## Limiter séparément le chemin et les permissions cibles Un technicien pouvant atteindre un serveur doit conserver uniquement les privilèges applicatifs nécessaires. Connectivité, droits du système d’exploitation et rôles applicatifs correspondent à des décisions distinctes. Documentez ces niveaux et le contrôle empêchant l’accès aux services sans rapport avec l’intervention. Le [guide ANSSI d’administration sécurisée, version 3.0](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-admin_securisee_si_v3-0.pdf), recommande une chaîne d’accès dédiée aux administrateurs tiers et des comptes d’accès et d’administration dédiés. Adaptez l’architecture aux systèmes concernés : un document d’assurance fournisseur ne remplace pas les contrôles appliqués dans l’institution. Évaluez VPN ou ZTNA sur le chemin réel. Le [guide de mise en œuvre ZTNA du NCSC](https://www.ncsc.gov.uk/collection/zero-trust/zero-trust-network-access-ztna/how-to-implement-ztna) maintient explicitement la nécessité du cloisonnement réseau local. Les décisions d’accès ZTNA et les contrôles des mouvements entre segments internes répondent à des fonctions différentes. Examinez les cibles accessibles depuis connecteur ou bastion, les transferts permis et la possibilité d’installer un autre outil de téléassistance. Pour l’intervention, approuvez les canaux nécessaires et empêchez les alternatives inexpliquées. Un raccourci temporaire de dépannage pourrait survivre au créneau initial. ## Une intervention municipale, de la demande à la clôture Une collectivité fictive remplace la configuration du connecteur qui transmet les tournées au prestataire de collecte des déchets. Le technicien doit modifier cette configuration et vérifier la réception d’un planning fictif. Il n’a besoin ni des recettes, ni des dossiers habitants, ni de l’annuaire d’identité. Le responsable métier réserve quatre-vingt-dix minutes après l’export opérationnel. La fiche indique date, horaires UTC et équivalent local pour éviter l’ambiguïté du changement d’heure. La collectivité conserve la configuration précédente et confirme que les agents disposent du planning existant si la mise à jour échoue. Avant l’ouverture, un test confirme que le technicien ne peut établir sa session d’administration. L’administrateur active ensuite rôle et chemin approuvés. Le technicien utilise l’identité et le poste convenus ; l’observateur vérifie la présence de la session dans les journaux attendus. Pendant l’intervention, le technicien modifie la configuration et transmet le planning de test identifié. Le métier confirme réception et suppression de ce dossier. Un contrôle autorisé vers une cible de test indépendante vérifie que le chemin prestataire ne traverse pas la frontière des recettes. Une cible indisponible ne prouve pas un refus de sécurité. Si le planning fictif échoue, le responsable décide du retour arrière ou d’une prolongation approuvée avant l’échéance. Un diagnostic incomplet n’accorde pas automatiquement davantage de droits. Toute cible supplémentaire nécessite justification et permission nouvelles. À la clôture, l’administrateur termine la session distante, retire le rôle temporaire et recense les secrets délivrés pendant l’opération. L’observateur vérifie le refus avec la même identité de test et documente le sort de la session déjà établie. La collectivité confirme ensuite le bon fonctionnement de l’export réel. Réservez une partie du créneau à cette transmission. Si les quatre-vingt-dix minutes sont entièrement consacrées à la modification, la clôture devient une opération réalisée après expiration de l’accord. Fixez le moment où le technicien cesse les changements et commence la vérification, avec une marge suffisante pour le retour arrière. Cette marge dépend de l’opération et de ses étapes de récupération. Inscrivez-la dans la fiche plutôt que d’appliquer un pourcentage universel. Le responsable de permanence doit connaître ce point d’arrêt avant le début du travail. Recensez également les éléments prévus pour fonctionner plus tard. Un export approuvé peut continuer après la déconnexion du technicien, mais une nouvelle tâche planifiée, un agent de téléassistance ou une clé API nécessite objectif et responsable. Indiquez s’il s’agit d’une dépendance permanente validée par la collectivité ou d’un élément temporaire à supprimer. Terminer la session visible n’explique pas ces changements en arrière-plan. Avant la réception, demandez au responsable applicatif de comparer leur configuration à la fiche de changement. Tout contrôle incomplet reste une action ouverte, avec personne désignée et échéance, plutôt qu’une case déclarée terminée faute de temps. ## Révoquer les états qui survivent à la connexion initiale Construisez la liste de clôture à partir des technologies présentes : session réseau, bastion, session applicative, rôle temporaire, mécanisme de renouvellement, clé API et secret local introduit. Tous les systèmes ne comportent pas tous ces éléments. Recherchez ce qui permet encore une opération après la modification de l’autorisation principale. Pour chacun, identifiez la terminaison ou l’invalidation disponible. Vérifiez si retirer un rôle affecte immédiatement une session ou seulement sa prochaine vérification d’autorisation. Déterminez si la déconnexion du navigateur laisse fonctionner un jeton indépendant. Deux produits peuvent réagir différemment au même événement d’identité. Si la terminaison immédiate est impossible, consignez durée résiduelle maximale et confinement testé : retrait du chemin réseau précis ou désactivation de la fonction cible, par exemple. Évaluez leurs conséquences métier avant de compter sur ces mesures. Réduire la durée des futurs jetons ne révoque pas un secret déjà délivré sous une autre politique. Vérifiez la clôture par une tentative sûre et autorisée nécessitant la permission retirée. Testez l’accès existant autant qu’une nouvelle connexion. Conservez la preuve d’échec sans enregistrer valeurs des jetons ni mots de passe. « Le prestataire s’est déconnecté » n’équivaut pas à une preuve institutionnelle du retrait des droits. Renouvelez les secrets exposés ou concernés par la procédure approuvée, après vérification des applications qui les utilisent. Une rotation indiscriminée de secrets partagés peut interrompre d’autres services. Leur inventaire permet un retrait précis et évite de casser une intégration sans rapport avec l’intervenant. Consignez également les limites découvertes pendant ce contrôle. Si une application ne permet qu’une expiration différée, le responsable doit connaître la durée réelle avant le prochain créneau. Une mention « accès fermé » sans cette réserve rendrait le dossier trompeur et empêcherait une décision informée sur l’intervention suivante. ## Prévoir un accès d’urgence qui reste exceptionnel Rédigez la procédure avant un appel nocturne. Définissez l’interruption justifiant son activation, l’approbateur et la vérification du demandeur lorsque l’identité habituelle est indisponible. Nommez un suppléant pour éviter qu’une seule absence entraîne une exception improvisée. Limitez le chemin à l’opération de rétablissement. Lorsque possible, une seconde personne habilitée observe l’usage ou le vérifie rapidement. Si l’outil de tickets est indisponible, gardez une trace indépendante puis réconciliez-la ensuite. L’urgence conserve une échéance et un responsable de clôture. Exercez cette procédure sans perturber la production. Confirmez que contacts, identifiants conservés, poste et cible fonctionnent dans la panne envisagée. Un compte de secours dépendant du mécanisme d’authentification défaillant ne remplit pas son rôle. Après utilisation, examinez la défaillance du chemin normal, rapprochez les modifications privilégiées et supprimez les autorisations temporaires. Des recours répétés au secours pour un même service nécessitent une décision d’architecture, plutôt qu’une normalisation du contournement. ## Garder des preuves utiles sans exposer l’investigation Le dossier d’audit relie approbation, activité et clôture. Conservez identité, cible, dates, décisions pertinentes, référence du changement et résultats de vérification. Si des sessions sont enregistrées, définissez finalité, accès et conservation avec les responsables compétents. Une capture vidéo peut contenir informations d’habitants et identifiants. Face à une activité inattendue, préservez les événements originaux et suivez la [méthode de corrélation IP, DNS et processus](/fr/posts/alerte-ioc-correler-ip-dns-processus). Une sortie fournisseur partagée identifie une infrastructure, pas nécessairement la personne responsable. Une [vérification de réputation](/fr/posts/verifier-reputation-ip-adresse-malveillante) ajoute un renseignement daté sans certifier l’identité. N’envoyez pas d’URL de session, de nom interne ou de lien signé dans un scanner public. Le [guide OPSEC des analystes](/fr/posts/opsec-analyste-cti-scan-url-confidentiel) explique comment une investigation peut divulguer les éléments qu’elle cherche à examiner. Pour une première évaluation IsMalicious, l’institution peut choisir l’un de ses domaines publics ou une IP publique lui appartenant et consulter le [rapport d’indicateur](/fr/report). Si les renseignements alimentent ensuite un contrôle existant, définissez qui interprète les correspondances et qui approuve les restrictions affectant le prestataire. Une réputation favorable ne doit jamais rouvrir une permission fermée. À la fin du contrat, rapprochez le registre complet avec le responsable métier : personnes, routes, rôles applicatifs et secrets automatisés. Terminez le transfert de service nécessaire avant de retirer les dépendances, puis conservez les preuves selon la politique approuvée. La dernière facture du fournisseur ne prouve pas la fin de ses accès techniques. --- # Achats de threat intelligence : guide du secteur public URL: https://ismalicious.com/fr/posts/achats-threat-intelligence-secteur-public Date: 2026-09-18T09:00:00.000Z Excerpt: Préparez un achat CTI public avec des exigences vérifiables, les droits d’usage, la protection des données, une recette technique et un plan de sortie. Un **achat de threat intelligence dans le secteur public** doit décrire un service que l’institution pourra tester, exploiter et quitter. Un catalogue de millions d’indicateurs ne démontre pas qu’un analyste pourra expliquer un résultat, qu’un SOC mutualisé aura le droit de le redistribuer ou qu’une correction atteindra les systèmes qui utilisent une appréciation erronée. Ce guide propose des critères d’évaluation technique pour les institutions britanniques et européennes. Il ne constitue pas un ensemble de clauses obligatoires. Les exemples sont fictifs. Les responsables achats, sécurité, gouvernance de l’information et affaires juridiques doivent adapter ces critères à leur institution et à sa procédure. Les [recommandations de base de l’ENISA pour les achats numériques](https://www.enisa.europa.eu/publications/indispensable-baseline-security-requirements-for-the-procurement-of-secure-ict-products-and-services), publiées en 2017, abordent la sécurité pendant le cycle de vie du service acheté. Elles fournissent un contexte technique, pas un état du droit actuel. Les fiches et tests CTI ci-dessous constituent notre méthode proposée. ## Définir le service avant de demander des offres Précisez qui consommera le renseignement et quels traitements seront autorisés. Une collectivité examinant les signalements de phishing de ses agents n’a pas les mêmes besoins qu’un service mutualisé distribuant des listes de blocage à plusieurs institutions. Un besoin unique et vague masque des différences de droits, de délais et de responsabilité. Dans notre exemple fictif, un SOC mutualisé enrichit des alertes sur des domaines et adresses IP pour trois organismes publics. Les analystes examinent les résultats avant tout changement réseau. Le fournisseur reçoit des indicateurs autorisés par API. Il ne reçoit pas les dossiers d’incident complets et ne décide pas quelle connexion interrompre. Nommez chaque organisme participant, son opérateur et les systèmes consommateurs. Un SOC externalisé, une collectivité voisine et un prestataire temporaire de réponse à incident constituent des destinataires différents. Leur inclusion doit être explicite, sans être déduite du seul mot partenariat. Utilisez le [cahier de PIR et de plan de collecte](/fr/posts/definir-pir-threat-intelligence-plan-collecte) pour clarifier une décision encore floue. Conservez ensuite les usages, les données autorisées, les horaires d’exploitation et le responsable du service. Ils déterminent quelles promesses commerciales méritent une vérification. ## Rédiger des exigences qui permettent de trancher Remplacez les adjectifs comme exploitable ou complet par un comportement attendu et une preuve. Demandez la signification du verdict, ses observations justificatives, ses dates et son mécanisme de correction. Deux notes sur cent ne deviennent pas comparables si leurs méthodes restent différentes ou inconnues. Une fiche d’exigence proposée peut prendre cette forme : ```text Référence : CTI-07 Besoin : identifier une modification d’appréciation sur un domaine Comportement attendu : identifiant stable, date d’appréciation, statut courant et mécanisme de correction Preuves fournisseur : schéma, exemples, procédure de correction Recette : récupérer un enregistrement de test avant et après correction Résultat attendu : le consommateur détecte et consigne la modification Responsable : équipe d’intégration SOC Réserve : limite, conséquence, propriétaire et date de réexamen ``` Cet exemple n’impose pas une architecture d’API. Un enregistrement de remplacement, un point de mise à jour ou un événement de retrait peuvent répondre au besoin si le consommateur sait les traiter. Décrivez le résultat nécessaire et demandez au candidat d’expliquer son mécanisme. Séparez absence de preuve et contradiction. Une date d’observation manquante doit rester identifiable. Elle ne doit pas être remplacée discrètement par l’heure de récupération. Le guide sur [l’évaluation des sources de threat intelligence](/fr/posts/sources-threat-intelligence-evaluer-preuves) développe les questions de provenance et de portée des conclusions. ## Cartographier les données envoyées et reçues Dessinez le parcours des données avant de qualifier l’intégration de peu risquée : client, connecteur, API, enrichissement amont, assistance, journaux, sauvegardes et rapports exportés. Une recherche peut révéler un intérêt d’investigation, même si l’indicateur interrogé est déjà visible publiquement. Demandez si les valeurs soumises sont conservées, transmises, rendues consultables, utilisées pour améliorer les jeux de données ou intégrées aux résultats d’autres clients. Distinguez fonctionnement normal et dépannage. Un ticket d’assistance peut contenir bien plus d’informations que la requête API dont il traite. Consignez où chaque catégorie est traitée et stockée, quelles organisations peuvent y accéder et quels changements nécessitent une information ou un accord selon le dispositif retenu. Une région d’hébergement ne répond pas seule aux questions sur l’assistance, les sous-traitants, les sauvegardes et les traitements secondaires. Testez la minimisation avec un cas fictif. Pour rechercher la réputation d’un domaine, envoyer une URL complète avec référence de dossier et jeton d’accès peut exposer des données inutiles. Définissez ce que le connecteur retire, ce qu’il conserve pour l’enquête et où reste l’original. Le guide [OPSEC et confidentialité des scans d’URL](/fr/posts/opsec-analyste-cti-scan-url-confidentiel) explique cette décision de soumission. Prévoyez une voie distincte pour les éléments qui ne peuvent pas entrer dans le service. La commodité d’une API ne doit pas élargir silencieusement le périmètre de données approuvé. ## Obtenir des réponses écrites sur les droits d’usage Un jeu de données techniquement accessible n’est pas automatiquement autorisé pour tous les usages. Présentez au fournisseur des scénarios précis de traitement et de diffusion. Demandez une réponse rattachée à l’accord applicable. Les droits non résolus doivent rester visibles pendant l’évaluation. Pour notre SOC mutualisé fictif, la fiche de droits doit notamment couvrir : - l’ingestion automatisée et le cache local par l’opérateur ; - l’affichage des preuves dans les dossiers de chaque organisme ; - les alertes ou listes dérivées transmises aux organismes participants ; - le partage de résultats avec un prestataire de réponse autorisé ; - la conservation de pièces pertinentes après la fin de l’abonnement ; - le retrait ou la séparation des données lorsqu’un membre quitte le dispositif. Distinguez l’appréciation produite par le fournisseur des éléments issus de sources amont. Demandez quels droits il peut accorder, quelles restrictions sont transmises et comment une limite propre à une source apparaît dans les exports. Une formule générale sur la plateforme peut masquer plusieurs licences différentes. Faites également expliquer comment le fournisseur établit son autorisation à collecter et fournir les données proposées. Visibilité publique, possibilité technique d’accès et droit de redistribution sont des questions distinctes. Une origine juridique incertaine doit devenir un sujet d’achat attribué à un responsable, sans être laissée à l’interprétation du développeur du connecteur. Les consignes de diffusion doivent suivre les exports. Le [guide du partage TLP](/fr/posts/tlp-2-partage-threat-intelligence) traite ces périmètres ; les droits contractuels du service nécessitent leur propre suivi. Vérifiez comment les instructions sont conservées lorsqu’un analyste copie un résultat dans un ticket. ## Relier les preuves fournisseur au service acheté Le [guide d’évaluation de la chaîne d’approvisionnement du NCSC](https://www.ncsc.gov.uk/collection/assess-supply-chain-cyber-security) s’adresse aux équipes achats, risques et sécurité. Il propose une démarche d’assurance dans la durée, au-delà du questionnaire initial. Construisez les demandes de preuve autour du service prévu. Elles peuvent porter sur l’architecture, les accès administratifs, la gestion d’incident, le périmètre d’évaluation, les corrections en attente et la séparation des clients. Rattachez chaque document à une affirmation. Une politique décrit un processus attendu ; un test récent et délimité apporte une autre preuve de sa mise en œuvre. Pour les interventions de support, la [procédure d’accès distant des prestataires](/fr/posts/acces-distant-prestataires-secteur-public) précise personne, tâche, périmètre et durée. Pour une certification ou un rapport d’évaluation, vérifiez organisation, service, date, périmètre et exclusions. Si l’API achetée se trouve hors du système évalué, la preuve ne s’y étend pas automatiquement. Demandez comment les constats importants sont suivis et qui accepte les risques restants. Identifiez les dépendances pouvant interrompre ou modifier le service : hébergeur, plateforme d’identité, source essentielle ou équipe d’assistance externalisée. Le but est d’en comprendre les conséquences et l’escalade, sans exiger une description illimitée de toutes les relations commerciales. Classez les affirmations comme étayées, partiellement étayées ou non étayées. Une réponse commerciale assurée ne remplace pas une pièce absente. Chaque point ouvert doit conduire à une suite explicite : preuve complémentaire, condition avant recette, réduction du périmètre ou rejet selon la procédure annoncée par l’acheteur. ## Préparer une recette incluant les cas de panne Utilisez un consommateur de test isolé et des données approuvées. Convenez des résultats attendus avant la démonstration et maintenez les protections de production. Les exemples fournis par le candidat vérifient des mécanismes ; ils ne démontrent pas une couverture réelle des attaques. Commencez par une récupération ordinaire. Vérifiez authentification, pagination, identifiants et interprétation des champs. Interrompez une collecte sur plusieurs pages, puis contrôlez sa reprise sans perte silencieuse ni multiplication des mêmes preuves. Conservez la configuration du test pour permettre sa reproduction. Modifiez ensuite une appréciation de test. Son état précédent doit rester explicable et le nouvel état doit atteindre le consommateur. Si un retrait exige une resynchronisation complète, documentez cette dépendance et mesurez son exécution. Une correction visible dans le portail, mais absente du flux opérationnel, n’achève pas le parcours attendu. Testez séparément un indicateur inconnu et une requête en échec. L’application locale doit distinguer absence de résultat, service indisponible et appréciation de faible risque. Une réponse HTTP positive ne prouve pas à elle seule que le renseignement demandé existe. Examinez les droits d’accès avec des comptes de test autorisés. Si le service héberge des dossiers privés, vérifiez qu’un utilisateur d’un organisme ne peut pas consulter ceux d’un autre. Si cette donnée n’est jamais stockée, consignez cette limite plutôt que d’inventer un besoin d’isolement pour un jeu public commun aux abonnés. Terminez par une notification de correction ou de panne. Elle doit atteindre le destinataire opérationnel réel et identifier la fonction concernée. Conservez résultat observé, défauts restants et décision de recette. Une capture du tableau de bord fournisseur ne prouve pas que le système consommateur a réagi comme convenu. ## Organiser les interruptions et les changements Précisez séparément disponibilité, fraîcheur et délai d’assistance. Une API peut répondre avec des données anciennes. Un prestataire peut accuser réception d’un ticket sans rétablir le service. Définissez le début et la fin de chaque mesure, ainsi que la partie capable de l’observer. Convenez du comportement lorsque la fraîcheur dépasse la limite acceptée : garder des preuves datées pour l’enquête, suspendre de nouvelles importations ou imposer une revue humaine. La réponse dépend de l’usage. Remplacer automatiquement une politique de protection par une liste vide peut créer une autre défaillance. Demandez comment sont annoncés les changements de champs, d’authentification, de quotas et de couverture amont. Prévoyez les changements urgents et les tests des évolutions planifiées. Nommez le responsable interne des connecteurs : un avis fournisseur ne réalise pas une mise à jour. Les coûts et la valeur opérationnelle relèvent du [benchmark de ROI des flux CTI](/fr/posts/mesurer-roi-flux-threat-intelligence-benchmark). La recette vérifie que le service convenu fonctionne. Elle ne démontre pas que l’achat apporte une valeur suffisante. ## Répéter la sortie pendant que le fournisseur est disponible Le [guide ANSSI sur l’externalisation](https://messervices.cyber.gouv.fr/guides/externalisation-et-securite-des-systemes-dinformation-un-guide-pour-maitriser-les), publié en 2010, propose d’exprimer les attentes de sécurité selon le contexte dans une démarche d’assurance. Il apporte une méthode, pas un modèle juridique actuel. L’exercice suivant est une proposition propre aux services CTI. Choisissez un dossier représentatif et exportez les éléments que l’institution a le droit de conserver. Un autre analyste doit encore distinguer observation initiale, appréciation fournisseur, corrections, annotations locales et restrictions. Un fichier ne contenant que la dernière note de risque peut être lisible tout en étant insuffisant pour expliquer une décision passée. Consignez les éléments impossibles à exporter ou à garder. Convenez du traitement des caches, identifiants de connecteur, tâches programmées, copies d’assistance et données détenues par les sous-traitants. Une suppression générale peut contredire un besoin convenu de conservation de preuve. Faites résoudre ce point par les responsables compétents avant la résiliation. Nommez responsable de migration, dépendances, assistance nécessaire et coûts prévus. Répétez la révocation des accès après validation du chemin de remplacement. Demandez les preuves de clôture convenues. Consignez toute conservation résiduelle avec sa justification et sa condition de fin. Identifiez les copies avant l’exercice, pendant que leurs propriétaires peuvent répondre. ## Remettre un dossier d’achat traçable Présentez ensemble service proposé, exigences vérifiées, réserves et responsabilités d’exploitation. Reliez chaque résultat de recette à son exigence. Adéquation de sécurité, valeur économique et validation procédurale restent des décisions distinctes, avec les responsables appropriés. Une [note CTI orientée décision pour la direction](/fr/posts/rapport-threat-intelligence-direction) permet d’exposer les arbitrages sans reproduire le dossier technique. Une réserve doit préciser l’inconnue, la personne acceptant sa conséquence et la date de réexamen. Un [rapport de réputation IsMalicious](/fr/report) peut fournir une consultation d’indicateur pendant une évaluation autorisée. Appliquez les mêmes exigences de preuve, de traitement et de recette qu’aux autres candidats. Le dossier final doit permettre d’expliquer ce qui a été acheté, ce qui a été vérifié et comment l’institution réagira lorsque le service changera. --- # DNS protecteur : déploiement dans le secteur public URL: https://ismalicious.com/fr/posts/dns-protecteur-secteur-public Date: 2026-09-18T09:00:00.000Z Excerpt: Déployez un DNS protecteur sur les sites publics et les postes nomades. Vérifiez la couverture, gérez les exceptions et préparez la continuité des services. Un **DNS protecteur dans le secteur public** est utile lorsque les équipements prévus appliquent sa politique et que les équipes peuvent examiner ses décisions sans interrompre les services essentiels. Configurer le résolveur du siège ne répond pas à toutes les questions : que se passe-t-il dans une bibliothèque, sur le portable d’un agent en déplacement ou dans une application exploitée par un prestataire ? Pour une collectivité ou un établissement public britannique ou européen, le travail consiste à établir une couverture, des responsabilités et une procédure de continuité. L’achat d’un service DNS ne suffit pas à les démontrer. Ce guide propose un dossier de déploiement et une recette technique à adapter avec l’exploitant réseau. Le cas pratique est fictif et les étapes proposées ne constituent pas une liste d’obligations réglementaires. ## Définir les services publics et les connexions concernés Commencez par les services dont l’interruption a une conséquence identifiable pour les usagers ou les agents : rendez-vous logement, encaissement, prêt en bibliothèque, authentification des équipes. Désignez un responsable métier capable d’expliquer les dépendances et de valider la période du pilote. « Tous les équipements de la collectivité » est un périmètre trop flou pour une recette. Pour chaque service, identifiez les postes administrés, les lieux de connexion, le propriétaire de l’application et les modalités de support. Distinguez l’accès des agents à une application hébergée du trafic propre aux serveurs du fournisseur. Le DNS utilisé par les agents ne démontre pas la protection de l’infrastructure SaaS distante. Conservez une fiche courte : ```text Service : administration des rendez-vous logement Responsable métier : gestionnaire identifié Population : portables administrés, au bureau et en déplacement Chemins inclus : réseau local, VPN approuvé, connexion à domicile Dépendances : identité, réservation, stockage documentaire Exploitant réseau : équipe interne ou prestataire nommé Preuves de recette : un résultat par chemin de connexion Exclusions : infrastructure fournisseur non administrée ``` Traitez les postes en libre accès séparément des équipements des agents. Les utilisateurs, les procédures de remise en état et les attentes de confidentialité diffèrent. Plusieurs politiques adaptées peuvent coexister. Conservez cette distinction dans le bilan de couverture et les consignes du support, plutôt que de les fondre dans une déclaration générale de protection. ## Vérifier l’éligibilité avant de choisir le service Le [Protective DNS du NCSC](https://www.ncsc.gov.uk/information/pdns) est un programme britannique de protection DNS récursive soumis à des critères d’éligibilité. Vérifiez ses modalités d’inscription pour votre organisme. Au Royaume-Uni, recherchez également le circuit prévu pour votre secteur ou votre organisme de rattachement. Une école, une collectivité et un ministère peuvent relever de modalités différentes. Lorsque la connectivité est externalisée, convenez de qui réalise l’inscription, configure la transmission des requêtes et reçoit les notifications d’exploitation. Ailleurs en Europe, notez l’autorité nationale consultée et les dispositifs sectoriels éventuellement disponibles. Examinez ensuite les autres offres à partir du réseau réel et des exigences d’achat de l’établissement. Un nom commercial évoquant une région ne démontre pas où se trouvent les journaux, les sauvegardes ou les accès du support. Demandez une description écrite de ces flux. Le [guide d’achat de threat intelligence pour le secteur public](/fr/posts/achats-threat-intelligence-secteur-public) aide à convertir les déclarations du fournisseur en preuves attendues. Ces éléments alimentent la revue propre à l’établissement, notamment celle des responsables de la gouvernance des données et des contrats. ## Mesurer la couverture du DNS protecteur par chemin L’inventaire des équipements fournit un dénominateur, mais la protection dépend du chemin de connexion. Un même portable peut appliquer la politique au bureau puis la contourner involontairement en déplacement. Une résolution réussie sur un poste fixe ne suffit donc pas comme preuve de recette. Préparez un résultat pour chaque combinaison pertinente entre politique du poste et réseau : filaire, Wi-Fi administré, site distant, VPN, accès direct à Internet autorisé. Pour les usages nomades, testez les transitions entre ces chemins. Le démarrage d’un appareil dans une configuration connue ne vérifie pas son comportement après changement de réseau. Relevez le chemin effectivement utilisé, la politique appliquée et l’événement correspondant dans la supervision. Employez des destinations inoffensives fournies ou approuvées pour les tests. Il n’est pas nécessaire de visiter une infrastructure malveillante réelle pour démontrer un blocage. Conservez l’heure et le résultat attendu afin qu’un autre technicien puisse répéter la vérification. Distinguez trois populations dans le bilan : couverture testée, configuration présente mais non vérifiée, équipements hors périmètre. Un portable absent durant le pilote reste dans la deuxième catégorie jusqu’à obtention d’une preuve. N’améliorez pas artificiellement le taux de couverture en excluant discrètement les agents de terrain de l’inventaire. Le guide des [listes de blocage DNS](/fr/posts/securite-dns-blocage-malware-resolveur-threat-intelligence) présente les mécanismes du résolveur. Ici, la question de recette est différente : l’établissement peut-il montrer que les populations convenues passent réellement par le contrôle attendu ? ## Préserver la résolution interne et les dépendances applicatives Un organisme public dépend souvent de noms internes, d’un annuaire et d’applications partagées entre plusieurs structures. Documentez les requêtes destinées aux résolveurs internes et celles transmises à l’extérieur. Testez cette séparation avant de modifier les réglages par défaut de tout le parc. N’envoyez pas les espaces de noms internes à un service externe simplement parce que les sites publics fonctionnent sur un poste témoin. Ne supposez pas non plus que chaque application utilise les réglages DNS du système. Un navigateur administré, un conteneur ou un client de sécurité peut introduire un autre chemin. Construisez une recette applicative avec le responsable métier. Elle doit inclure l’authentification, une opération habituelle, l’accès aux documents et les échanges nécessaires en arrière-plan. L’ouverture de la page d’accueil ne prouve pas que le paiement, la prise de rendez-vous ou l’identité fonctionnent jusqu’au bout. Tenez compte des caches et du délai d’application des politiques. Une réponse mémorisée ou une connexion existante peut survivre à un changement et fausser l’interprétation. Utilisez la procédure de vérification prise en charge par le fournisseur, sans vider les caches de tout le parc dans l’urgence. Le [guide de durcissement DNS](/fr/posts/securite-dns-empoisonnement-cache-detournement-durcissement) couvre les contrôles d’infrastructure associés. La résolution protectrice ne remplace pas l’administration sécurisée du DNS faisant autorité pour les domaines publiés par l’organisme. ## Maîtriser les autres résolveurs et les chemins chiffrés Le chiffrement DNS protège le transport. Il ne précise pas, à lui seul, la politique appliquée par le résolveur. Un poste administré peut utiliser correctement du DNS chiffré ; un autre résolveur non prévu peut sortir les requêtes de la visibilité attendue. Examinez ensemble les politiques du système, du navigateur, du VPN et du client de sécurité. Définissez les chemins autorisés puis vérifiez leur comportement réel. Encadrez les alternatives non autorisées avec les contrôles disponibles, et documentez les exceptions lorsqu’une application présente une dépendance justifiée. Les [recommandations du NCSC pour choisir un DNS protecteur](https://www.ncsc.gov.uk/guidance/protective-dns-for-private-sector) abordent le déploiement et l’assurance fournisseur pour les organismes non éligibles à son propre service. Elles aident à formuler les questions ; la démonstration de couverture locale reste un travail distinct. Une règle pare-feu visant le DNS classique ne démontre pas une maîtrise complète des connexions. Certaines applications possèdent leur propre comportement de résolution ou de connexion. Le guide de [surveillance du DNS-over-HTTPS](/fr/posts/dns-over-https-doh-securite-surveillance) explique pourquoi il faut rapprocher les observations du poste et du réseau. Décrivez les écarts résiduels plutôt que de présenter un réglage théorique comme une protection universelle. ## Organiser le pilote autour des usages du service public Prenons une commune fictive disposant d’un site administratif, de deux bibliothèques et d’agents qui se déplacent chez les habitants. Le pilote inclut quelques postes administrés dans chaque lieu ainsi que plusieurs utilisateurs nomades. Les protections existantes restent actives pendant la validation du nouveau chemin de résolution. La recette suit une séquence de travail : connexion, ouverture d’un rendez-vous autorisé, consultation d’un document nécessaire, puis transaction de test permise. Utilisez des comptes et données de test lorsque c’est possible. Associez le centre de support, qui recevra les premiers signalements de blocage inattendu. Une bibliothèque réussit la recette initiale, mais échoue après bascule sur son accès réseau de secours. L’analyse montre que cette liaison annonce un autre résolveur. C’est un défaut de couverture, même si le tableau de bord du siège reste rassurant. L’équipe corrige ce chemin avant d’étendre le pilote. Un portable nomade doit aussi être vérifié après déconnexion du VPN. La réponse dépend de l’architecture approuvée : composant nomade administré, autre politique de connexion ou modification du périmètre. Documentez la décision puis rejouez les tests concernés. Le réglage du bureau ne suit pas nécessairement l’agent. Étendez ensuite le déploiement par population prise en charge, après acceptation des preuves par son responsable. Une dépendance essentielle dépourvue de support ou de procédure de reprise doit suspendre cette extension jusqu’à résolution du problème. ## Transformer les blocages en éléments utilisables par le support Une requête bloquée montre qu’une politique a pris une décision. Elle ne prouve pas, à elle seule, qu’une personne a cliqué, qu’un programme malveillant s’est exécuté ou qu’une attaque a été empêchée. Une tâche de fond ou les nouvelles tentatives d’une application peuvent multiplier les événements. Conservez l’horodatage, le nom demandé, la raison indiquée, le chemin DNS et un moyen autorisé d’identifier l’équipement. Gardez le lien avec l’observation d’origine. Une synthèse sans motif technique peut masquer la différence entre une classification de menace et une panne ordinaire. La [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914) définit les Extended DNS Errors, qui peuvent apporter un contexte supplémentaire aux erreurs. Leur prise en charge varie. Vérifiez ce que le résolveur et le client exposent réellement, sans interpréter toute erreur de résolution comme un blocage de domaine malveillant. Donnez au support une séquence courte : identifier le service affecté, déterminer si la politique explique l’échec, recueillir les preuves minimales puis transmettre au bon responsable. Pour l’analyse de menace, examinez la [provenance et la fraîcheur des sources](/fr/posts/sources-threat-intelligence-evaluer-preuves) avant de transformer un résultat de réputation en restriction étendue. Gardez les éléments de diagnostic dans les circuits approuvés. Les historiques de domaines et leur association à un poste peuvent révéler des habitudes de travail sensibles, même sans contenir de documents. Définissez qui y accède et pour quelle investigation. ## Attribuer un périmètre et une échéance aux exceptions Rétablir un service public nécessite parfois une décision rapide, mais pas une autorisation générale et permanente. Commencez par identifier la dépendance en échec et le caractère intentionnel du blocage. Un site fournisseur compromis peut également être une dépendance métier réelle. Faites convenir au responsable du service et à l’intervenant sécurité l’action la plus limitée qui fonctionne. Lorsque l’outil le permet, bornez l’exception à la destination, aux utilisateurs et à la période nécessaires. N’autorisez pas tout un domaine d’hébergement partagé pour rétablir un seul composant. Utilisez un registre : ```text Service affecté et dépendance exacte : Preuves qui soutiennent l’action envisagée : Incertitudes ou observations contradictoires : Approbateur et responsable d’application : Population et destinations autorisées : Échéance et date de revue : Surveillance complémentaire : Test confirmant la suppression : ``` Si la plateforme ne sait pas imposer la granularité ou l’échéance souhaitée, précisez le processus compensatoire et la personne qui l’exécutera. Inscrire une date dans un ticket ne supprime pas automatiquement une règle. Examinez les exceptions récurrentes avec le fournisseur et le responsable applicatif. Des prolongations répétées peuvent signaler une classification non corrigée, une intégration non prise en charge ou une dépendance qui exige une autre conception du service. ## Décider du fonctionnement dégradé avant la panne Convenez de ce qui se passe si le résolveur, la liaison ou le composant nomade devient indisponible. La disponibilité et la protection ne se dégradent pas toujours ensemble. Un autre résolveur peut rétablir Internet tout en supprimant la politique de sécurité. Une seconde instance peut encore dépendre du même accès en panne. Testez le chemin de reprise approuvé avec un exercice délimité et une procédure de retour. Vérifiez la politique effective après bascule, la résolution des noms internes et l’alerte permettant aux équipes de reconnaître la situation dégradée. Deux adresses configurées ne prouvent pas une indépendance réelle. Le responsable métier doit connaître les conséquences d’une mesure d’urgence qui réduit la protection, la personne habilitée à la décider et les conditions de retour au fonctionnement normal. Gardez les contacts d’urgence accessibles quand l’identité ou la messagerie habituelle sont indisponibles. Intégrez l’essai de reprise à la passation avec l’exploitant. Un schéma d’architecture ne démontre pas qui répondra à l’heure concernée, ni si son contrat actuel inclut l’intervention attendue. Vérifiez aussi comment joindre le responsable d’une exception pendant cette période. ## Examiner les écarts de couverture plutôt qu’un compteur Organisez une revue d’exploitation courte : quelles populations disposent de preuves récentes, quels chemins restent non vérifiés, quelles exceptions ont expiré, quels incidents nécessitent une modification ? Associez ces questions à des responsables identifiés. Un nombre élevé de blocages peut provenir des tentatives répétées d’un seul poste. Il appelle une analyse, sans justifier un chiffre d’attaques évitées. Le résultat utile est un contrôle qui fonctionne, dont les limites sont connues et dont la gestion préserve les services publics. Pour un domaine public dont l’analyse est autorisée, le [contrôle de réputation de domaine IsMalicious](/fr/threat-intel/domain) fournit un contexte externe daté. Conservez-le avec les preuves DNS et les observations locales du poste. IsMalicious apporte du renseignement ; le résolveur, la politique réseau et le processus d’incident de l’établissement assurent l’application du contrôle et la décision finale. --- # Government Threat Intelligence Procurement: A Practical Guide URL: https://ismalicious.com/posts/government-threat-intelligence-procurement Date: 2026-09-18T09:00:00.000Z Excerpt: Specify a public-sector threat intelligence service with clear evidence, data-handling rules, acceptance tests and an exit plan for UK and European teams. A **government threat intelligence procurement** should describe a service that the institution can test, operate and leave. A catalogue containing millions of indicators does not establish whether an analyst can explain a result, whether a shared SOC may redistribute it, or what happens when a source withdraws an incorrect assessment. This guide proposes technical evaluation criteria for UK and European public institutions. It is not a set of mandatory procurement clauses. The examples are fictional, and the responsible procurement, security, information-governance and legal teams must adapt the requirements to their institution and purchasing process. [ENISA's baseline procurement guidance](https://www.enisa.europa.eu/publications/indispensable-baseline-security-requirements-for-the-procurement-of-secure-ict-products-and-services), published in 2017, treats security across the purchased service's lifecycle. It provides technical context, not a statement of current procurement law. The CTI specification and test cases below are our proposed implementation method. ## Define the service boundary before requesting offers Describe who consumes the intelligence and what they are authorised to do with it. A council investigating staff-reported phishing needs different evidence and delivery arrangements from a shared security service supplying blocklists to several institutions. Combining both under one undefined threat intelligence requirement hides differences in rights, latency and operational responsibility. Use a short service statement. In our fictional example, a shared SOC enriches domain and IP alerts for three participating public bodies. Analysts review the results before any network change. The supplier receives approved indicators through an API; it does not receive complete incident records or decide which connection to block. Name each participating organisation, its operator and the systems consuming results. An outsourced SOC, a neighbouring authority and a temporary incident-response contractor are different recipients. Their inclusion should be explicit rather than inferred from the word partnership. Use the [PIR and collection-plan workbook](/posts/define-pir-threat-intelligence-collection-plan) to resolve an unclear decision need. For this specification, retain the resulting use cases, data boundaries, operating hours and named service owner. They determine which supplier claims matter. ## Write requirements that produce an acceptance decision Replace vendor adjectives with behaviour and evidence. Ask for the meaning of a verdict, its supporting observations, relevant dates and correction mechanism. An undocumented confidence score cannot become comparable merely because two providers both express it on a hundred-point scale. A proposed requirement record can use this structure: ```text Reference: CTI-07 Need: identify when a domain assessment changes Required behaviour: expose a stable record identifier, assessment time, current status and a correction mechanism Supplier evidence: schema, example records, correction workflow Acceptance test: retrieve a supplied test record before and after correction Expected result: the consumer detects and records the change Reviewer: SOC integration owner Exception: documented limitation, impact, owner and review date ``` The example does not prescribe one API design. A replacement record, an update endpoint or a documented withdrawal event may satisfy the need if the consuming system can process it reliably. State the required outcome and let the supplier explain its mechanism. Distinguish unavailable evidence from contradictory evidence. A missing observation date must remain visibly missing. It should not be replaced silently by the retrieval date. Our guide to [evaluating threat intelligence sources](/posts/threat-intelligence-sources-evaluate-evidence) explains why provenance and claim boundaries matter when interpreting results. ## Map what the institution sends and what comes back Draw the data path before agreeing that an integration is low risk. Include the client, connector, service endpoint, upstream enrichment, support tooling, logs, backups and exported reports. A query can reveal investigative interest even when its indicator appears publicly elsewhere. Ask the supplier to explain whether submitted values are retained, forwarded, made searchable, used to improve datasets or included in other customers' results. Separate normal operation from troubleshooting: a support ticket may contain a much richer payload than the API request it discusses. Record where each relevant category is processed and stored, which organisations can access it, and what changes require notification or approval under the agreed arrangement. A hosting-region label alone does not answer questions about support access, subcontractors, backups or secondary processing. Test minimisation with a fictional case. If an analyst needs domain reputation, submitting an entire URL with a case reference and access token can disclose more than the task requires. Define what the connector removes, what it preserves for investigation and where the original remains. The [guide to private URL scanning and analyst OPSEC](/posts/cti-analyst-opsec-private-url-scanning) develops that submission decision. Create a separate handling route for material that cannot enter the service. The existence of a convenient API should not silently expand its approved data boundary. ## Obtain written answers about use and redistribution rights A technically accessible dataset is not automatically licensed for every intended use. Present the supplier with concrete recipient and processing scenarios, and ask for an answer linked to the applicable agreement. Keep unresolved rights questions visible during evaluation. For the fictional shared SOC, the rights schedule should address: - automated ingestion and local caching by the operating team; - display of supporting evidence in each participating body's case records; - derived alerts or blocklists delivered to those bodies; - sharing selected findings with an authorised response contractor; - retention of relevant evidence after the subscription ends; - removal or separation of material when an institution leaves the arrangement. Distinguish the supplier's own assessment from upstream material bundled with it. Ask which rights the supplier can grant, which restrictions pass through, and how a source-specific restriction is represented in exports. One broad statement about the platform may conceal several different data licences. Request an explanation of how the supplier establishes that it can collect and supply the datasets offered. Public visibility, technical access and authority to redistribute are separate questions. Unclear upstream rights should become an explicit procurement issue with an owner, rather than an assumption made by the integration engineer. Handling markings also need to survive export. The [TLP sharing guide](/posts/tlp-2-threat-intelligence-sharing) covers distribution boundaries; the service's contractual rights need their own record. Ask how the connector prevents those instructions from disappearing when an analyst copies a finding into a ticket. ## Match supplier assurance evidence to the purchased service The [NCSC supply-chain assessment guidance](https://www.ncsc.gov.uk/collection/assess-supply-chain-cyber-security) addresses procurement, risk and security teams establishing supplier assurance. It supports examining the relationship through its lifetime, rather than relying on the initial questionnaire alone. Build an evidence request around your service boundary. Relevant material can include an architecture diagram, administrative-access controls, incident procedures, assessment scope, remediation status and a demonstration of tenant separation. Identify which claim each item supports. A policy document demonstrates an intended process; a recent, scoped test can provide different evidence about its implementation. For support connections, use the [third-party remote access workflow](/posts/public-sector-third-party-remote-access) to define the person, task, scope and duration. For any certificate or assessment, verify the organisation, service, date, scope and exclusions. If the purchased API sits outside the assessed environment, the evidence does not automatically extend to it. Ask how material findings are tracked and who accepts outstanding risk. Identify dependencies that could interrupt or change the service: a hosting provider, an identity platform, a critical upstream feed or an outsourced support team. The purpose is to understand consequences and escalation, not to demand unlimited disclosure of every commercial relationship. In the evaluation record, distinguish supported, partly supported and unsupported claims. A confident sales answer should not overwrite a missing artefact. Give each unresolved item a consequence: further evidence, a bounded condition before acceptance, a reduced scope or rejection according to the buyer's stated process. ## Run a service acceptance exercise with failure cases Use an isolated test consumer and approved sample data. Agree the expected outcomes before the demonstration, and keep the production service protected while testing. Supplier-provided fixtures are useful for checking mechanics; they do not establish real-world detection coverage. Start with ordinary retrieval. Verify authentication, pagination, record identifiers and field interpretation. Interrupt a multi-page fetch and confirm whether the consumer can resume without silently losing records or multiplying the same evidence. Record the test configuration so a later reviewer can repeat it. Next change a test assessment. Confirm that its previous status remains explainable and that the current state reaches the consumer. If a withdrawal needs a full resynchronisation, measure and document that dependency. An update visible in the supplier's portal but absent from the operational feed has not completed the required workflow. Test an unknown indicator and a failed request separately. The local application should distinguish no result, unavailable service and an assessment of low risk. An HTTP success response is not by itself proof that the requested intelligence exists. Exercise access boundaries with authorised test accounts. Check that a user for one institution cannot retrieve another institution's private case material, where the service stores such material. If it does not, record that boundary rather than inventing a tenant-isolation requirement for a dataset that is public to all subscribers. Finish with a correction or outage notification. The test should reach the actual operational recipient and identify the affected function. Save the observed result, remaining defects and acceptance decision. A screenshot of the supplier dashboard cannot substitute for evidence that the consuming workflow behaved as agreed. ## Make service interruption and change manageable Specify availability, freshness and support response separately. An endpoint can answer requests while serving stale data. A supplier can acknowledge a ticket while the service remains unavailable. Define where each measurement starts and ends, and which party can observe it. Agree what the consumer does when freshness exceeds the accepted limit. It might retain dated evidence for investigation, suspend new automated imports or require manual review. The right response depends on the use case; automatically replacing every control with an empty list can introduce a different failure. Ask how changes to fields, authentication, quotas and upstream coverage are communicated. Include a route for urgent changes and a way to test planned ones. Identify the institution's owner for connector updates, because supplier notice alone does not implement a fix. Cost and operational value belong in the separate [threat intelligence feed ROI benchmark](/posts/threat-intelligence-feed-roi-benchmark). Acceptance establishes that the agreed service works; it does not prove that the purchase delivers sufficient value. ## Rehearse the exit while the supplier is still available [ANSSI's outsourcing guidance](https://messervices.cyber.gouv.fr/guides/externalisation-et-securite-des-systemes-dinformation-un-guide-pour-maitriser-les), published in 2010, uses a security-assurance approach to express context-specific expectations of a provider. It is methodological background, not a current procurement-law template. The following exit rehearsal is a proposed CTI-specific exercise. Choose a representative case and export the information that the institution is entitled to retain. Check whether another analyst can still distinguish the original observation, supplier assessment, correction history, local annotation and handling restriction. A file containing only the final risk score may be readable but inadequate for explaining an earlier decision. Record what cannot be exported or kept. Agree the treatment of caches, connector credentials, scheduled jobs, support copies and material held by subcontractors. An instruction to delete everything can conflict with an agreed need to preserve investigation evidence; resolve that question before termination with the responsible teams. Name the migration owner, dependencies, assistance required and expected costs. Rehearse credential revocation after the replacement path works. Request the agreed evidence of closure and record any residual retention with its reason and end condition. Identify these copies before the rehearsal, while their owners can still answer questions. ## Give the decision-maker a traceable purchasing record Present the proposed service, verified requirements, unresolved exceptions and operating responsibilities together. Link each acceptance result to its requirement. Keep security suitability, commercial value and procedural approval as distinct decisions with their appropriate owners. Use a [decision-oriented CTI briefing](/posts/threat-intelligence-report-executives) to explain the important trade-offs without reproducing the entire technical pack. An exception should show what remains unknown, who accepts its consequence and when it will be revisited. An [IsMalicious reputation report](/report) can provide an indicator lookup to examine during an authorised evaluation. Assess it against the same evidence, handling and acceptance criteria as any other candidate. A defensible purchase leaves the institution able to explain what it bought, what it verified and how it will respond when the service changes. --- # Local Government Network Security: A 90-Day Council Plan URL: https://ismalicious.com/posts/local-government-network-security Date: 2026-09-18T09:00:00.000Z Excerpt: Build a council network security plan around public services, clear ownership, tested segmentation and useful logs, with practical actions across 90 days. **Local government network security starts with the public service that must keep working.** A firewall change that interrupts urgent housing repairs or a revenue collection run creates an immediate operational problem, even when its security intention is sound. A useful plan connects every network action to a service owner, a tested dependency and a recovery decision. The [NCSC network security fundamentals](https://www.ncsc.gov.uk/guidance/network-security-fundamentals) cover asset identification, restricted access, network architecture and monitoring. They also explain that segmentation controls traffic between smaller networks. Those principles provide a foundation; the staged council workflow below is an original implementation proposal, with fictional examples rather than reported customer results. Use it for administrative networks and public service applications. Specialist operational technology needs its own engineering assessment. Responsibilities also differ between UK councils and European municipalities: map the services your institution actually operates, commissions or shares. ## Start with a resident journey, then draw the dependencies Choose one journey whose interruption has an understandable consequence. In our fictional council, a resident reports a dangerous housing defect through a portal. A caseworker assesses the report, a contractor receives a work order and the resident gets an appointment notification. The service is complete when the work order reaches the correct team, not when the portal returns a successful status. Draw the dependencies behind that journey: public hosting, staff authentication, case management, the integration that transfers work orders, supplier connectivity and the notification provider. Add shared services such as DNS and the network route between the case management system and the integration host. Identify which dependency carries resident information and which merely enables a connection. For each dependency, maintain a short record: ```text Service: urgent housing repairs Dependency: work-order integration Service owner: housing operations lead Technical operator: named application supplier team Network change operator: council network provider Failure evidence: work order accepted but not delivered Fallback: approved telephone dispatch and reconciliation Change window: agreed outside peak dispatch period Verification: synthetic work order received and cancelled ``` Use test records that cannot accidentally dispatch a contractor. The housing team must agree how those records are labelled and removed. A network engineer cannot infer that operational detail from a packet trace. Repeat the exercise for a small initial portfolio: revenue collection, an essential resident contact channel and the selected housing service. Expanding from completed examples is more useful than drawing an organisation-wide map that nobody can validate. ## Give each dependency an owner who can make a decision Separate the person accountable for the service from the person who can alter a device. A managed service provider may own the firewall, another supplier may administer the application, and the council may control the identity tenant. None can independently confirm that a change is acceptable for the whole resident journey. Record three responsibilities: who approves the service impact, who implements the technical change and who verifies the result. Add an alternate for each. The directory must work outside office hours and remain available if the institution's normal collaboration platform is unavailable. When a provider owns a network device, request a bounded change through its agreed channel. Include the service record, proposed source and destination, expected behaviour, acceptance checks and rollback trigger. Ask for the applied configuration reference and test evidence. “The supplier handles networking” leaves the council unable to distinguish an agreed restriction from an undocumented operational dependency. Escalate missing ownership as a service risk with a named decision maker and review date. Do not silently make the network team responsible for an application it cannot administer. Detailed supplier controls belong in the [public sector remote access lifecycle](/posts/public-sector-third-party-remote-access). Shared dependencies need more than one service sign-off. A change to a common authentication path might affect housing, libraries and the contact centre even when the request originated in housing. Attach the affected service list to the change and identify a representative transaction for each. If a service cannot provide a test or an alternate owner, make that uncertainty visible before approval. The operator should know whether to defer the shared change, split the implementation or proceed under a recorded decision. Silence from another department is not evidence that its workflow will continue. ## Days 1–15: establish what is connected and what must survive Begin with existing evidence: device inventories, firewall configurations, identity records, application documentation and representative traffic logs. Compare those sources. A device absent from the asset register but present in a current route or authentication log needs investigation before it is labelled obsolete. Mark observations with a date and a confidence level. A supplier document describes intended behaviour; a log describes observed behaviour during its covered period. Neither establishes that a quarterly revenue export or an emergency contact workflow has been captured. Ask service teams about infrequent jobs before accepting a short monitoring sample. Create a small queue of unresolved dependencies. Each entry needs a question, an owner and the evidence that would resolve it. For example: “Does the revenues export still use this destination during month end?” Avoid an unprioritised spreadsheet of unfamiliar IP addresses. Collect software support status and update responsibility for the network devices in scope. An urgent, confirmed exposure may need action before the mapping exercise finishes. Use the incident or emergency change process for that decision, with the affected service owner involved, rather than treating the 90-day timetable as a reason to defer it. The first milestone is a map that someone can use to explain a failure. Test it with a short exercise: if the work-order integration loses connectivity, who notices, who restores it and how does housing continue dispatching urgent repairs? ## Days 16–30: remove specific exposure without losing the service Select a small number of changes whose purpose and impact are clear. Candidates include an expired supplier route, an administrative interface reachable from staff browsing networks or an obsolete rule that permits a much wider source range than its application requires. For each candidate, write the exact unwanted path and the authorised path that must remain. “Tighten access to housing” is insufficient. “Allow the integration host to reach the approved application endpoint while denying access from the guest network” can be evaluated. Validate dependencies before removing the old path. If a rule appears unused, check whether the available logs include denied events, the relevant schedule and the full route. Missing evidence should lead to a controlled observation or test period, not an unsupported claim that the rule is redundant. Agree the rollback operator before the window starts. Store the previous configuration through an approved mechanism and confirm that the operator can reach the device if the new rule interrupts normal management. Establish a stop condition, such as a failed synthetic work order or an unexplained increase in integration errors. Record exceptions with an expiry and a reason. An exception that permits a legacy workflow for one month must return to a decision, not become an unnamed permanent route. ## Days 31–60: prove the segmentation boundary Choose one boundary around a service or administration function. The design should state which connections cross it, why they are necessary and where they are enforced. Separate VLAN labels alone do not establish the outcome. The acceptance evidence must show the permitted and prohibited paths. Run authorised, non-destructive checks from representative locations. A practical acceptance record for the fictional housing service includes: - A caseworker completes the agreed synthetic transaction through the normal application. - The integration host delivers that transaction using the approved endpoint and protocol. - A test device on the guest network cannot reach the administrative interface. - The supplier administration path reaches its approved target and fails against an unrelated revenues target. - DNS, authentication, monitoring and backup dependencies still work within the intended scope. - The technical operator restores the previous configuration in a controlled rollback rehearsal or equivalent validated recovery exercise. For a denial, distinguish a security control decision from an unavailable test target. Preserve the rule reference or other enforcement evidence. For an allowed action, inspect the application result as well as the transport connection. A successful handshake is not proof that a resident transaction completes. Our [lateral movement detection guide](/posts/lateral-movement-detection-network-security) provides further context for investigating cross-system activity. Here, the acceptance question is narrower: can an account or host cross this particular boundary beyond its approved purpose? Avoid changing every boundary together. Pilot a service, observe its normal workload and review failures with its owner. Carry the resulting dependency corrections into the next change rather than copying a faulty rule pattern across the estate. ## Make logs answer an investigation question Before purchasing more storage, choose a question the institution needs to answer. For example: “Which staff or supplier identity used the housing administration path between the change window and the first failed work order?” That requires compatible evidence across identity, remote access, application and network systems. Record the fields available at each stage: event time, timezone, source identifier, destination, account, decision and policy reference where supported. Check clock alignment and whether address translation obscures the original device. A shared public IP cannot identify a particular employee without additional records. Test retrieval with a known event. Record how long it takes, who can perform the search and whether the provider must assist. The [IOC investigation workflow](/posts/investigate-ioc-alert-ip-dns-process) explains how IP, DNS and process evidence contribute different parts of an investigation. Set retention by use case and approved policy. Document the searchable period, archive period, retrieval delay, access controls and deletion process for each source. Involve the relevant information governance and legal owners where required. Keeping everything indefinitely is not a substitute for knowing which evidence is necessary. State coverage gaps explicitly. “No matching activity in seven days of gateway logs” cannot establish what occurred before that period, on a different route or inside an application that provides no audit events. For investigations that revisit older intelligence, use the time distinctions in our [historical IOC retrohunting guide](/posts/ioc-retrohunting-historical-logs). ## Days 61–90: rehearse a disruption and accept the remaining work Exercise a failure that crosses organisational boundaries. In the fictional council, the application supplier is available but the network provider's usual contact is not. Ask the alternate contact to locate the approved change, find the logs and explain the rollback. This exposes a different weakness from testing whether a firewall rule blocks a packet. Then rehearse the operational fallback with housing staff. Confirm how urgent jobs are captured, who can authorise telephone dispatch and how those jobs are reconciled after recovery. Avoid copying resident data into improvised personal spreadsheets or messaging accounts. Measure recovery against the service owner's accepted interruption and backlog, not an arbitrary target copied from another institution. A technically restored connection may still leave hundreds of queued records or duplicate notifications requiring reconciliation. At the review, present completed boundaries, demonstrated transactions and unresolved dependencies. Count outcomes such as services with a tested fallback, supplier routes with a current owner and changes with verified enforcement. Report the denominator and exclusions so a successful three-service pilot is not represented as estate-wide assurance. Use the format in our [executive threat intelligence reporting guide](/posts/threat-intelligence-report-executives) when an unresolved issue requires a funding or service decision. State the operational consequence, available options and the date by which an owner must decide. ## Add reputation evidence where the network team can act on it A public destination associated with suspicious activity deserves context before a rule change. Record when the institution connected, what that destination does and when the intelligence was observed. Shared hosting, reassigned IP addresses and supplier infrastructure changes can alter the interpretation. For a first IsMalicious check, select a public IP address or domain that the institution owns and is authorised to assess. Use the [indicator report](/report) to review available reputation evidence, then attach the dated result to the relevant service record. Do not submit internal hostnames, credentials or resident-specific URL parameters. If repeated enrichment is useful, define feed requirements around the existing firewall or investigation platform: supported indicators, freshness, expiry handling, review ownership and a route for correcting false positives. The [feed evaluation benchmark](/posts/threat-intelligence-feed-roi-benchmark) helps measure whether that addition changes local decisions. The next network change should leave a concrete trail: an identified public service, a named approver, a bounded technical action, evidence that required work still succeeds and a person ready to restore the previous state. --- # Protective DNS for the Public Sector: A Deployment Guide URL: https://ismalicious.com/posts/protective-dns-public-sector Date: 2026-09-18T09:00:00.000Z Excerpt: Deploy protective DNS across public-sector sites and remote staff. Test coverage, handle exceptions and keep essential services available during failures. **Protective DNS for the public sector** succeeds when the intended devices use the policy and staff can investigate its decisions without interrupting essential services. Enrolling a council's headquarters resolver leaves important questions unanswered: what happens at a library, on a housing officer's laptop, or when an outsourced application uses its own connection? For UK and European public institutions, the practical task is to establish coverage, responsibility and continuity. A resolver purchase alone does not establish any of them. This guide proposes a deployment record and acceptance process that a public-sector IT team can adapt with its network provider. The worked example is fictional, and the milestones are suggested engineering controls rather than a statutory checklist. ## Define the public services and connections in scope Start with services whose interruption has a clear consequence for residents or staff. Examples include housing appointments, revenue collection, library lending and workforce authentication. Name a service owner who can explain the dependencies and approve the pilot window. “All council devices” is too vague to test. For each service, identify the managed endpoints, network locations, application owners and support arrangements. Distinguish staff access to a hosted service from the service provider's own server traffic. Routing employees through a protective resolver does not establish that a SaaS provider's infrastructure follows the same policy. Use a compact service record: ```text Service: housing appointment administration Business owner: named service manager Population: managed office and field-worker laptops Included paths: office LAN, approved VPN, home connection Dependencies: identity service, booking application, document store Network owner: council team or named managed provider Acceptance evidence: test record for each connection path Exclusions: supplier infrastructure not managed by the council ``` List public-access terminals separately from staff devices. They have different users, recovery procedures and expectations of privacy. An institution can operate several appropriate policies without describing them as one undifferentiated deployment. Preserve that distinction in the coverage report and support instructions. ## Check programme eligibility before choosing the delivery model The [NCSC Protective DNS service](https://www.ncsc.gov.uk/information/pdns) is a UK recursive DNS protection programme with specific eligibility requirements. Check its current registration guidance for your institution. UK teams should also check whether their sector or parent organisation has an established route to the service. A school, council and central department need not have the same onboarding process. Where an existing provider administers connectivity, agree who completes registration, configures forwarding and receives operational notifications. For institutions elsewhere in Europe, record the national authority consulted and any sector-specific service already available. Compare the remaining options against the actual network and procurement requirements. Geography in a product name does not establish where query logs, backups or support access will reside. Request a written description of those data flows. The [public-sector threat-intelligence procurement guide](/posts/government-threat-intelligence-procurement) provides a way to turn supplier claims into evidence requests. Treat this as an input to your institution's own review, including information governance and contractual approval. ## Measure protective DNS coverage by connection path An endpoint inventory gives a denominator, but coverage depends on how each endpoint connects. The same laptop can be protected in the office and uncovered after leaving it. A single successful lookup on one desktop is therefore insufficient acceptance evidence. Build a test record for each relevant combination of device policy and network path. Include wired offices, managed wireless, satellite sites, VPN connections and approved direct internet access. For mobile work, test transitions between paths, not only a device that starts in the expected configuration. Record the observed resolver route, effective policy and corresponding event in the monitoring system. Use harmless test destinations supplied or approved for that purpose. Do not browse live malicious infrastructure merely to prove that a block works. Retain the time and the expected result so another engineer can repeat the check. Report three populations separately: tested and covered, configured but unverified, and outside scope. A device that has not connected during the pilot belongs in the second category until evidence supports promotion. Avoid dividing tested devices by an inventory that silently excludes field workers. For the underlying resolver and feed concepts, see the [DNS blocklist guide](/posts/dns-security-threat-intelligence-blocklist). Here, the acceptance question is narrower: can this institution demonstrate that its agreed populations use the intended control? ## Preserve internal resolution and application dependencies A public organisation often depends on internal names, directory services and applications shared with other authorities. Document which queries must reach internal resolvers and which are forwarded externally. Test that boundary before changing defaults across the estate. Do not send internal namespaces to an external service simply because a workstation appears to resolve public websites correctly. Equally, do not assume every application uses the operating system's DNS settings. A managed browser, container or security client can introduce a different path. Build an application smoke test with service owners. It should include authentication, a normal transaction, document access and any background integration required to complete the task. A landing page loading successfully does not prove that the payment, scheduling or identity component works. Record caches and policy propagation when comparing results. A cached answer or existing connection can survive a policy change and mislead the test. Use the provider's supported verification procedure rather than making an unplanned estate-wide cache change. The guide to [DNS hardening](/posts/dns-security-hardening-guide) covers related infrastructure controls. Protective resolution is one layer; it does not replace secure administration of the authoritative DNS that publishes the institution's own domains. ## Manage alternative resolvers without confusing encryption and policy Encrypted DNS protects a transport path; it does not by itself say which security policy the resolver applies. A managed device can use encrypted DNS appropriately, while an unmanaged alternative resolver can take queries outside the institution's intended visibility. Review operating-system, browser, VPN and security-client policies together. Decide which resolver paths are supported, then test their actual behaviour. Restrict unauthorised alternatives through the controls available in that environment, with documented exceptions where an application has a justified dependency. The [NCSC guidance on selecting protective DNS](https://www.ncsc.gov.uk/guidance/protective-dns-for-private-sector) discusses deployment and provider assurance for organisations outside its own service eligibility. Use it to frame questions, while preserving the distinction between choosing a service and proving local coverage. Avoid claiming that a firewall rule blocking ordinary DNS proves complete control. Applications can have independent resolution or connection behaviour. The [DNS-over-HTTPS monitoring guide](/posts/dns-over-https-doh-security-monitoring) explains why the endpoint and network views must be considered together. Document the remaining gaps instead of presenting a nominal configuration as universal protection. ## Run a pilot around public-service transactions Consider a fictional municipality with a civic office, two libraries and staff who visit residents. Its first pilot includes a small managed-device group at each location and several mobile users. The team keeps the existing protections active while validating the new resolution path. The acceptance exercise follows normal work: log in, open an authorised appointment, access a required document and submit a permitted test transaction. Use test accounts and non-production records where available. Include the service desk, because its staff will receive the first reports of unexpected blocks. One library passes the office test but fails after a local connectivity failover. Investigation shows that the secondary connection advertises a different resolver. This is a coverage defect, even if the security dashboard for headquarters looks healthy. The team corrects that path before expanding the pilot. A mobile laptop also needs evidence after its VPN disconnects. The remedy depends on the approved architecture, such as a managed roaming component or a different connection policy. Record the decision and rerun the relevant tests; do not assume that the office configuration travels with the user. Expand by supported population once the owner accepts the evidence. Stop an expansion when an essential dependency has no workable support or recovery procedure. ## Turn blocks into evidence the service desk can use A blocked query shows that a policy decision occurred. It does not alone prove that a person clicked a malicious link, that malware ran, or that an attempted attack was prevented. Background activity, retries and cached application behaviour can produce repeated events. Capture the timestamp, queried name, policy reason, resolver path and an authorised way to identify the affected asset. Preserve the relationship between an event and its source. A translated summary without the original reason can conceal whether the result came from a threat classification or a technical failure. [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914) defines Extended DNS Errors for communicating additional error context. Support and presentation vary, so ask what your resolver and client actually expose. Do not interpret an undifferentiated resolution error as a confirmed malicious-domain block. Give the service desk a short triage sequence: establish which service is affected, determine whether the failure is policy-related, collect the minimum useful evidence, and route the case to the correct owner. For threat context, examine [source provenance and freshness](/posts/threat-intelligence-sources-evaluate-evidence) before escalating a reputation result into a broad restriction. Keep diagnostic data inside approved channels. Domain histories and endpoint mappings can reveal sensitive working patterns even when no document contents are present. ## Give exceptions an owner, scope and expiry An urgent request to restore a public service deserves a fast review, not an automatic permanent bypass. First establish the failing dependency and whether the block is intentional. A compromised supplier site can also be a genuine business dependency. Ask the service owner and security responder to agree the narrowest workable action. Limit an exception to the required destination, population and period where the platform supports that granularity. Avoid approving an entire shared hosting domain because one application component is needed. Keep an exception record: ```text Affected service and precise dependency: Evidence supporting the proposed action: Known uncertainty or conflicting observations: Approver and implementation owner: Permitted population and destination scope: Expiry and scheduled review: Compensating monitoring: Test confirming removal: ``` If the platform cannot enforce the required scope or expiry, name the compensating process and who will perform it. The exception is not self-managing merely because a ticket contains an end date. Review recurring exceptions with the provider and application owner. Repeatedly extending the same bypass can indicate an unresolved classification problem, an unsupported integration or a dependency that needs a different design. ## Decide failure behaviour before the next outage Agree what happens if the resolver, network path or roaming component becomes unavailable. Availability and protection can fail differently. An alternate resolver may restore connectivity while removing the security policy; an alternate instance of the same service may still depend on the same failing network. Test the approved recovery path with a bounded exercise and a restoration procedure. Confirm the effective policy after failover, the availability of internal names and the monitoring signal that tells staff the estate is degraded. Two configured addresses do not establish independent resilience. Service owners should understand any emergency change that reduces protection, the person authorised to approve it and the conditions for restoring the normal path. Keep emergency contact details accessible when the main identity or collaboration service is unavailable. Include the recovery test in handover to the managed provider. An architecture diagram cannot demonstrate who will answer at the relevant time or whether the current contract includes that action. ## Review coverage and unresolved decisions, not a block counter Use a short operational review: which populations have fresh coverage evidence, which paths remain unverified, which exceptions have expired, and which service-impacting incidents need a design change? Keep those questions attached to named owners. A high block count can reflect repeated requests from one endpoint. It should trigger analysis rather than an unsupported claim about attacks prevented. The meaningful outcome is a functioning control with understood limits and a response process that preserves public services. For one approved public domain involved in a block review, use the [IsMalicious domain reputation check](/threat-intel/domain) to collect dated external context. Keep that result alongside local DNS and endpoint evidence. IsMalicious provides threat context; the institution's resolver, network policy and incident process remain responsible for enforcement and the final decision. --- # Public Sector Supplier Remote Access: Control Every Session URL: https://ismalicious.com/posts/public-sector-third-party-remote-access Date: 2026-09-18T09:00:00.000Z Excerpt: Control supplier remote access with named identities, agreed work windows, bounded paths and verified revocation, using a practical public sector example. **Public sector supplier remote access should end when the authorised work ends.** That requires more than an expiry date on an account. The institution needs to know who is connecting, which service they can change, which active sessions remain and who can withdraw access while preserving essential operations. A supplier's contract may last several years while an engineer needs access for ninety minutes. Treat those as separate permissions. The proposed workflow below turns each intervention into an access window with an owner, observable boundaries and a verifiable end. Its council example is fictional; it describes no customer's architecture or measured outcome. ## Follow the whole access path before approving the account Map the engineer's route from their device to the final operation. A typical path might include the supplier identity provider, council authentication, a VPN or access broker, a jump host and an application administration role. An API key created inside that application can become another path with a different lifetime. For every step, record who grants access, who can revoke it and which evidence shows that revocation worked. A supplier can disable its employee identity without controlling an application token issued by the council. Conversely, the council can close a network route while a separate cloud administration session remains available. Separate interactive maintenance from unattended service connections. A nightly integration needs an accountable service identity and credential lifecycle; it should not borrow an engineer's account. Mixing the two makes an urgent employee departure difficult to handle without breaking production. Place the service dependencies alongside this path. Our [council network security plan](/posts/local-government-network-security) shows how to assign service owners and verify continuity. The remote access decision then becomes specific: which part of that service can this person reach during this intervention? ## Agree an access window that an operator can enforce The [NCSC supplier assurance questions](https://www.ncsc.gov.uk/guidance/supplier-assurance-questions) ask organisations to consider how supplier access is limited, controlled and monitored, whether remote support agreements exist and whether sessions are logged. The following record converts those questions into a proposed operational handover between the institution and its provider. ```text Change reference: municipal waste scheduling connector update Service owner and alternate: named council contacts Supplier engineer: verified individual identity Purpose: replace connector configuration and validate delivery Start/end: explicit date, UTC times and local display Allowed targets: approved administration endpoint only Allowed actions: configuration update and synthetic job check Transfer channel: approved package repository Stop authority: council duty lead or incident commander Closure owner: named access administrator Closure evidence: session ended, temporary role removed, issued credentials reconciled, test denied ``` Add the device and authentication conditions that the operator can actually check. A requirement saying “secure device” is too vague to accept or reject a connection. Specify the approved evidence source, freshness and response when that evidence is unavailable. An access window is an operating record, not a replacement for procurement or legal terms. Ensure the contract supports the necessary notification, personnel changes, subcontractor approval and evidence delivery. Otherwise, the technical team may be expected to enforce conditions the provider has never agreed to meet. Define extensions explicitly. A delay does not silently extend the original permission. The service owner or authorised alternate decides whether to continue, narrow the task or restore the previous state. Record the revised deadline and ensure the enforcement mechanism receives it. ## Onboard the person, the device and the exit process Verify the engineer through a previously established supplier contact. Do not accept a new telephone number or identity solely because it appears in the urgent access request. Check whether the person belongs to the contracted organisation or a subcontractor with separate approval requirements. Issue an individual identity for the approved work. Keep elevated roles distinct from ordinary collaboration access, and apply the institution's authentication policy. For privileged access, prefer phishing-resistant authentication where the supported architecture allows it. Document any exception, its owner and its expiry. Before activating the identity, ask the supplier how it will notify the institution when the engineer leaves, changes role or loses a device. Name the recipient and the response owner. An annual supplier review is too slow for an access decision tied to a specific person's current employment. Test the offboarding procedure with a test identity during onboarding. Discovering that application sessions cannot be terminated at the end of a real intervention leaves the council negotiating a control gap after access has already been granted. Broader questions about compromised software and vendor dependencies remain part of [supply chain risk assessment](/posts/supply-chain-attack-detection-third-party-risk). This workflow addresses the permissions used by people performing an authorised service task. ## Bound the route and the target permission separately An engineer who can reach a server should still receive only the application privileges required for the task. Network reachability, operating system rights and application roles are separate decisions. Record all three where relevant, including the control that prevents access to unrelated services. [ANSSI's secure administration guide, version 3.0](https://messervices.cyber.gouv.fr/documents-guides/anssi-guide-admin_securisee_si_v3-0.pdf), recommends a dedicated remote access chain for third-party administrators and dedicated access and administration accounts. Use its architecture recommendations with a local assessment of the systems concerned; a supplier assurance document does not replace controls within the institution. A VPN or ZTNA product must be evaluated against the actual path. The [NCSC ZTNA implementation guidance](https://www.ncsc.gov.uk/collection/zero-trust/zero-trust-network-access-ztna/how-to-implement-ztna) explicitly retains the need for local network segmentation. ZTNA access decisions and controls on movement between internal segments serve different purposes. Ask whether the connector or jump host can reach unrelated targets, whether file transfer is permitted and whether a supplier can introduce another remote support tool. For the agreed intervention, approve necessary channels and prevent unexplained alternatives. A temporary troubleshooting shortcut can otherwise survive the original access window. ## A municipal supplier change from request to closure Consider a fictional council updating the connector that sends collection schedules to a waste contractor. The supplier needs to modify one configuration and confirm delivery of a synthetic schedule. It does not need access to revenues, resident case records or the identity directory. The service owner schedules a ninety-minute window after the operational export. The change record includes the actual date, UTC times and their local equivalent to avoid daylight-saving ambiguity. The council retains the previous connector configuration and confirms that the existing schedule is available to operational staff if the update fails. Before the window, a test confirms that the engineer cannot open the administration session. The access administrator then activates the approved role and route. The engineer authenticates with the agreed identity and device; the observer checks that the session appears in the expected logging systems. During the intervention, the engineer changes the configuration and submits the labelled synthetic schedule. The service team confirms receipt and removal of that test record. An authorised check against an unrelated test target confirms that the supplier route cannot cross into the revenues environment. Do not substitute an unavailable target for proof that a control denied access. If the synthetic schedule fails, the service owner chooses rollback or a separately approved extension before the deadline. The engineer does not gain broader access simply because the initial diagnosis is inconclusive. An additional target requires a new reason and permission. At closure, the access administrator ends the remote session, removes the temporary role and checks any credentials issued during the change. The observer verifies denied access using the same test identity and records what happened to the already established session. The council then confirms that the real scheduled export remains healthy. Reserve part of the window for this handover. If all ninety minutes are allocated to the technical change, closure becomes an activity performed after the approval has expired. Set a point at which the engineer stops making changes and starts verification, leaving enough time for the agreed rollback. The appropriate margin depends on the operation and its recovery steps; record it in the change rather than adopting a universal percentage. Also reconcile anything designed to run later. An approved export job may legitimately continue after the engineer disconnects, but a new scheduled task, remote support agent or API credential needs an identified purpose and owner. Record whether each item is a permanent service dependency approved by the institution or a temporary artefact to remove. Ending the visible session does not explain these background changes. Ask the application owner to verify their configuration against the change record before accepting closure, and record any incomplete check as outstanding work. ## Revocation must cover state that survives login Build a closure checklist from the actual technology. Include the network session, jump-host session, application session, temporary role, refresh mechanism, API key and any local credential introduced by the intervention. Not every system uses every item. The important question is whether something still authorises an operation after the account's main permission changes. For each item, identify the supported termination or invalidation mechanism. Check whether removing a role affects an existing session immediately or only after another authorisation check. Check whether logging out of a browser leaves an independently issued token usable. Do not assume that two products respond identically to the same identity event. Where immediate termination is unsupported, record the maximum remaining lifetime and a tested containment action, such as withdrawing the specific network path or disabling the affected target capability. Assess service impact before relying on that action. Shorter future lifetimes do not revoke a credential already issued under a different policy. Verify closure with a safe, authorised attempt that would require the withdrawn permission. Test existing access as well as a new login. Preserve failure evidence without recording token values or passwords. A provider's statement that it “logged out” is not equivalent to institution-side evidence that the operation is no longer authorised. Rotate credentials that were exposed or must change under the agreed procedure, with dependency checks for applications using them. Indiscriminate rotation of shared secrets can interrupt unrelated services. An inventory of issued credentials makes precise revocation possible. Record limitations discovered during verification. If an application only supports delayed expiry, the owner needs its actual duration before the next window. Describing access as closed without that qualification would misrepresent the evidence and prevent an informed decision about the next intervention. ## Keep an emergency route that does not become routine Write the emergency process before a supplier needs it at night. Define which service disruption justifies its use, who can approve it and how the requester is verified if the usual identity system is unavailable. Name an alternate approver so one missing person does not force an improvised exception. Restrict the route to the recovery operation and have a second authorised person observe or promptly review its use where feasible. Maintain an independent record when the normal ticketing system is unavailable, then reconcile it afterwards. Emergency access still needs a deadline and a closure owner. Exercise the process without disrupting production. Confirm that the stored contact details, credentials, device and target are usable under the assumed failure. A recovery account that depends on the failed authentication path cannot fulfil the intended purpose. Afterwards, review why the normal path failed, reconcile privileged changes and close temporary permissions. Repeated emergency use for the same service should trigger a design decision, rather than normalising an exceptional route. ## Keep evidence useful without exposing the investigation The audit package should connect approval to activity and closure. Retain identity, target, timestamps, relevant policy decisions, change reference and verification results. If session recording is used, define its purpose, access restrictions and retention with the relevant institutional owners. Screen recordings can contain resident information and credentials. When activity is unexpected, preserve original events and follow the [IP, DNS and process investigation workflow](/posts/investigate-ioc-alert-ip-dns-process). A shared supplier egress address identifies infrastructure, not necessarily the individual responsible. A [reputation check](/posts/how-to-check-ip-reputation-safe) provides additional dated evidence, not identity assurance. Do not paste session URLs, internal hostnames or signed download links into public scanning tools. The [analyst OPSEC guide](/posts/cti-analyst-opsec-private-url-scanning) explains how an investigation can disclose the material being assessed. For an initial IsMalicious assessment, the institution can select one of its own public domains or public IP addresses and review the [indicator report](/report). If reputation data will feed an existing control, first specify who interprets matches and who approves restrictions affecting supplier access. A clean reputation result must never reopen a closed permission. At contract exit, reconcile the full access register with the service owner: people, routes, application roles and non-interactive credentials. Complete any required service transfer before removing dependencies, then retain the closure evidence under the approved policy. The supplier's final invoice is not evidence that its technical access has ended. --- # School Network Security: Test Segmentation That Works URL: https://ismalicious.com/posts/school-network-security-segmentation Date: 2026-09-18T09:00:00.000Z Excerpt: Plan school network segmentation around teaching needs, test permitted and blocked paths, protect administration, and manage changes without losing access. School network security depends on whether a device can reach the right services and is prevented from reaching the wrong ones. A pupil laptop should open its learning platform without gaining access to the finance application. A visiting presenter may need internet access without seeing classroom devices. A heating controller should not become a route into staff administration. Network segmentation makes those boundaries explicit. Its value comes from enforced and tested access rules, not the number of VLANs, wireless names or firewall objects on a diagram. A school also needs to know whether a change will interrupt accessible learning software, registration, examinations or an essential building service. This guide develops an original acceptance workflow for a fictional two-site school trust. The examples are synthetic. The Department for Education references concern **England**; NCSC programme references concern the **UK**. Schools elsewhere in Europe should apply the technical method alongside their own education authority's requirements. Completing these steps does not establish regulatory compliance. ## Start with a teaching day, not a network diagram The fictional North Mere Learning Trust wants to separate classroom devices from its administrative systems before the next term. Its initial inventory lists laptops, switches and servers. The missing information is what each service needs to do during an ordinary school day. Ask a teacher to demonstrate registration, presenting a lesson, submitting work and printing. Ask the inclusion team to demonstrate the assistive tools pupils depend on. Ask office staff to show the administrative workflows that must remain available. Use demonstration accounts and documents, not live pupil records. Record the service, user group, device type, destination, dependency and owner. A learning application may need an identity provider, a content service and a licence check. Permitting its main website alone may leave the actual lesson unusable. The [DfE cyber security core standard](https://www.gov.uk/guidance/meeting-digital-and-technology-standards-in-schools-and-colleges/cyber-security-core-standard) includes current network documentation and discussion of logging needs. The practical deliverable here is a local service record that lets teaching and IT staff agree what a successful change looks like. ## Group access by purpose and consequence North Mere's working design distinguishes managed teaching devices, staff administration, guests, infrastructure management and building equipment. These are planning categories, not a requirement to create exactly five networks. A small school and a large college may implement very different boundaries. For each category, describe the damage that unrestricted access could cause and the connections it genuinely needs. Guest internet access does not justify access to internal management pages. A classroom printer may need a controlled printing service, but not permission to initiate arbitrary sessions towards office computers. Shared services need deliberate treatment. DNS, time synchronisation, authentication and device management can support several groups. Document the specific paths rather than moving everything into a broad trusted segment because multiple departments use it. The [lateral movement guide](/posts/lateral-movement-detection-network-security) explains why unnecessary reach matters after an initial compromise. In this school design, the immediate question is narrower: which connection could carry a problem from one educational or administrative service into another? ## Specify the boundary where enforcement happens Different Wi-Fi names can still lead to the same routed network. Separate VLANs can still communicate freely through a default rule. A device can also use a wired connection that bypasses the wireless policy the team just reviewed. Record which component makes the access decision: a firewall, switch access rule, host firewall or application policy. Record who can change it and where its configuration is backed up. If the broadband supplier controls the boundary, obtain the relevant evidence from that supplier rather than assuming the school console represents the whole path. The [DfE network switching standard](https://www.gov.uk/guidance/meeting-digital-and-technology-standards-in-schools-and-colleges/network-switching-core-standard) covers switching infrastructure and security features. Procurement capability and operational enforcement are different checks. A switch that supports access controls does not prove that the installed rules implement the school's intended boundary. Give every material rule a purpose and owner. “Teaching devices to approved print service” is reviewable. “Temporary school access” is not sufficient once the person who added it has left or forgotten which lesson required it. ## Keep identity controls alongside network controls A segmented network cannot fix an administrative application that accepts a pupil account as an administrator. Conversely, an application login does not protect an exposed infrastructure management interface from every unwanted connection. Check the role a test account actually receives. A supply teacher, permanent teacher and office administrator may use the same building while needing different rights. On shared devices, verify sign-out and profile handling rather than assuming the next user inherits a clean session. The [Zero Trust implementation guide](/posts/implementing-zero-trust) provides background on explicit verification. For this project, retain a small access matrix linking the person or role, device condition and service. Avoid collecting more personal information than is necessary to establish that the policy works. For managed cloud applications, the school may not control the provider's internal network. Test the identity and application permissions available to the institution. Do not mark that service as isolated merely because its traffic leaves through a school firewall. ## Preserve accessibility and legitimate classroom services Segmentation can expose dependencies that informal arrangements previously hid. Screen-sharing equipment may rely on local discovery. An assistive application may contact a separate licensing endpoint. A specialist classroom may use a device that cannot meet the same management requirements as a standard laptop. Have the appropriate teaching or inclusion lead define an acceptance task. “The site opens” is weaker than “the learner can sign in, hear the content, save work and resume it on the approved device.” Use a demonstration workflow and record the relevant accessibility requirement without identifying an individual pupil. If discovery across a boundary is required, evaluate a narrowly scoped service or controlled gateway. Broadly allowing all traffic between groups to restore a projector would defeat the purpose of the change. The exception should identify which devices and functions need the additional path. For an unusual device, document the limitation and compensating arrangement. A blanket statement that every device must behave identically can exclude legitimate teaching needs without creating a workable security design. ## Separate protective DNS from safeguarding decisions Known-malicious-domain blocking, safeguarding content filtering and monitoring answer different questions. A malware-related destination can require a security investigation. A safeguarding concern needs the school's established safeguarding process and authorised staff. Neither should be inferred solely from the existence of a blocked DNS query. The [NCSC PDNS for Schools announcement](https://www.ncsc.gov.uk/blog-post/pdns-for-schools-provide-cyber-resilience-for-more-institutions) explicitly says the service complements existing safeguarding filtering. Our [public-sector protective DNS guide](/posts/protective-dns-public-sector) examines resolver coverage, roaming and exceptions. It does not turn a reputation result into a safeguarding assessment. In England, the [DfE filtering and monitoring standard](https://www.gov.uk/guidance/meeting-digital-and-technology-standards-in-schools-and-colleges/filtering-and-monitoring-core-standard) assigns distinct responsibilities to leadership, safeguarding and IT. Establish those contacts before changing network paths so that a technical exception receives the appropriate review. Do not bypass mandatory or policy-required filtering as a troubleshooting shortcut. Test an approved learning resource through the intended controls. If the resource fails, investigate the specific cause and use the school's documented exception procedure where one is applicable. ## Create tests for permitted and prohibited paths North Mere prepares a small acceptance set before changing the rules. Each test identifies a representative device group, a controlled destination, an expected result and the evidence needed. Tests are authorised and non-destructive; they do not require vulnerability scanning across a live school network. A teaching device should complete the demonstration learning task. A guest device should reach the approved internet test resource but fail to reach a controlled administrative test endpoint. An authorised management device should access its designated console. A building-device test should preserve its required service while failing to reach the classroom test endpoint. Record the outcome in a reusable form: ```text Test reference and approved change: Source device group and connection type: Controlled destination and intended operation: Expected result: permitted / denied Observed result and timestamp: Enforcement evidence reference: Teaching or service-owner acceptance: Unexpected dependency and follow-up owner: ``` A timeout alone is ambiguous. The destination could be offline, DNS could fail, or a different control could block the request. Confirm that the controlled endpoint is available through its authorised path and inspect the intended enforcement point's evidence. Otherwise, a broken service may be mistaken for successful isolation. ## Test the paths that are easy to overlook Repeat relevant cases on wired and wireless access, at both sites, and through the approved backup internet connection. Check any supported IPv6 path as well as IPv4. A rule applied to one protocol or one site does not establish the same result elsewhere. For managed devices used away from school, identify which policies follow the device and which depend on the campus network. Remote learning must not quietly become an untested exception. Record the supported location and device combinations rather than promising protection everywhere. Test management reach separately from ordinary application use. An application can work correctly while its management interface remains unnecessarily exposed. Similarly, check whether an existing session survives a permission change when the expected outcome requires revocation. Retain enough technical context to reproduce a result. The [IP, DNS and process correlation guide](/posts/investigate-ioc-alert-ip-dns-process) helps explain why a single network record rarely establishes a user's action or the full sequence of events. ## Phase changes around term, examinations and support capacity Select a pilot group whose owner can verify the required workflows. Agree on a change window, an observation period and the conditions that would trigger rollback. Avoid moving every classroom immediately before examinations merely because the technical deployment is quick. Check support availability at the affected sites. A successful evening test does not cover the next morning's simultaneous registrations, lessons and guest arrivals. The pilot should include a representative teaching period with a clear route for reporting failures. Keep the previous configuration and the authority to restore it. A rollback plan should say which settings return, who approves the decision, and which acceptance tests run afterwards. Restoring connectivity without checking the boundary can leave a broad emergency rule in place. The [operational blocklist testing guide](/posts/blocklists-operational-threat-prevention) discusses controlled rollout and reversal for another class of security change. Here, the same discipline applies to network policy: define the evidence for continuing, pausing or reversing before the change begins. ## Control supplier and building-system access A heating or classroom-equipment supplier may need a maintenance connection. That does not justify permanent access to the entire school network. Record the named support relationship, destination, task, permitted period and person able to terminate access. Building systems can have availability and safety constraints. Coordinate changes with the responsible facilities team and supplier, use an approved test method, and avoid disruptive experiments. An emergency override needs a documented purpose and review, rather than an open-ended bypass inherited from an old support call. The [public-sector supplier remote access guide](/posts/public-sector-third-party-remote-access) provides a fuller access record. For the school project, confirm that the maintenance path does not cross into staff records, pupil devices or infrastructure administration without a separately authorised need. After maintenance, test the expected closure. A ticket marked complete is not evidence that an account, remote session or firewall exception has stopped providing access. ## Turn investigation findings into reviewed changes When a security alert appears, retain the time, affected device group and relevant local evidence. Avoid interpreting an IP address as a named pupil or treating an automated background request as deliberate browsing. Keep safeguarding escalation and technical investigation within their authorised responsibilities. For an approved public domain or IP address, an [IsMalicious reputation report](/report) can add context to the technical case. Submit only the permitted indicator. Do not upload pupil records, browsing histories, signed access links or restricted attachments. A reputation result supports review; it does not authorise automatic school-wide blocking. At the end of the pilot, deliver the current flow record, test results, exceptions, rollback evidence and unresolved issues to the service owners. Re-run the affected acceptance cases after a material change in devices, applications, suppliers or connectivity. The useful outcome is a boundary the school can explain, test and maintain while its teaching services continue to work. --- # Sécurité réseau des collectivités : plan de 90 jours URL: https://ismalicious.com/fr/posts/securite-reseau-collectivites-locales Date: 2026-09-18T09:00:00.000Z Excerpt: Construisez un plan de sécurité réseau pour votre collectivité : services publics, responsables identifiés, segmentation testée et journaux utiles en 90 jours. **La sécurité réseau des collectivités commence par le service public qui doit continuer à fonctionner.** Une règle de pare-feu qui interrompt une réparation urgente de logement ou un traitement de recettes crée un problème immédiat, même si son intention est légitime. Un plan utile relie chaque action réseau à un responsable métier, une dépendance vérifiée et une décision de rétablissement. Les [fondamentaux de sécurité réseau du NCSC](https://www.ncsc.gov.uk/guidance/network-security-fundamentals) abordent inventaire, restrictions d’accès, architecture et surveillance. Ils expliquent aussi que la segmentation contrôle les échanges entre réseaux plus petits. Le programme proposé ci-dessous applique ces principes à un déroulement municipal original, avec des exemples fictifs qui ne décrivent aucun résultat client. Son périmètre couvre les réseaux administratifs et applications de service public. Les systèmes industriels nécessitent une analyse spécialisée. Les responsabilités diffèrent entre collectivités françaises, conseils britanniques et autres municipalités européennes : cartographiez les services effectivement exploités, délégués ou mutualisés. ## Partir du parcours usager pour retrouver les dépendances Choisissez un parcours dont l’interruption a une conséquence compréhensible. Dans notre collectivité fictive, un habitant signale un défaut dangereux dans son logement. Un agent évalue le signalement, une entreprise reçoit un ordre d’intervention et l’habitant obtient une notification de rendez-vous. Le service aboutit lorsque la bonne équipe reçoit cet ordre, pas lorsque le portail affiche un succès. Dessinez les dépendances : hébergement public, authentification des agents, gestion des dossiers, transfert des ordres, connexion du prestataire et notifications. Ajoutez les services communs, notamment DNS et chemin réseau entre application métier et serveur d’intégration. Distinguez les dépendances transportant des informations sur les habitants de celles qui permettent seulement une connexion. Pour chaque dépendance, conservez une fiche courte : ```text Service : réparations urgentes des logements Dépendance : transfert des ordres d’intervention Responsable métier : responsable du service logement Exploitant applicatif : équipe identifiée du prestataire Exploitant réseau : infogérant de la collectivité Signe de panne : ordre accepté mais non transmis Secours : dispatch téléphonique validé, puis rapprochement Créneau : convenu hors pic de traitement Vérification : ordre fictif reçu puis annulé ``` Les dossiers de test ne doivent pas déclencher un déplacement réel. Le service logement valide leur identification et leur suppression. Une capture réseau ne permet pas à un ingénieur de déduire cette précaution métier. Répétez l’exercice sur un premier ensemble limité : recettes, canal essentiel de contact avec les habitants et service logement sélectionné. Étendre des exemples validés est préférable à une cartographie générale que personne ne sait vérifier. ## Attribuer chaque dépendance à des personnes capables de décider Séparez responsabilité du service et capacité à modifier l’équipement. L’infogérant possède parfois le pare-feu, un autre prestataire administre l’application et la collectivité contrôle les identités. Aucun ne peut confirmer seul qu’une modification convient à l’ensemble du parcours usager. Désignez qui accepte l’impact métier, qui réalise la modification et qui vérifie le résultat. Ajoutez des suppléants. Cet annuaire doit fonctionner hors horaires habituels et rester disponible si la plateforme collaborative de la collectivité tombe en panne. Si un prestataire possède l’équipement, transmettez une demande délimitée par le canal convenu. Joignez fiche métier, source, destination, comportement attendu, tests de réception et déclencheur du retour arrière. Exigez la référence de configuration appliquée et les preuves de vérification. « Le prestataire gère le réseau » ne distingue pas une restriction approuvée d’une dépendance inconnue. Traitez une responsabilité absente comme un risque métier, avec décideur et date de réexamen. Ne rendez pas tacitement l’équipe réseau responsable d’une application qu’elle ne peut administrer. Le [cycle de contrôle des accès prestataires](/fr/posts/acces-distant-prestataires-secteur-public) développe les mesures propres à ces interventions. Une dépendance commune nécessite plusieurs validations métier. Modifier une authentification partagée peut affecter logement, médiathèques et centre de contact, même si la demande vient du logement. Joignez les services concernés au changement et prévoyez une transaction représentative pour chacun. Si un métier ne fournit ni test ni suppléant, rendez cette incertitude visible avant approbation. L’exploitant doit savoir s’il faut reporter la modification commune, séparer les interventions ou poursuivre selon une décision consignée. L’absence de réponse d’un autre service ne prouve pas que son activité continuera. Vérifiez également les créneaux où chaque équipe peut constater un échec et participer au rétablissement. ## Jours 1 à 15 : connaître les connexions et les services indispensables Commencez par les éléments disponibles : inventaires, configurations de pare-feu, identités, documentation applicative et journaux représentatifs. Comparez-les. Un équipement absent de l’inventaire mais présent dans une route active ou un journal d’authentification doit être étudié avant d’être considéré comme obsolète. Datez les observations et précisez leur niveau de confiance. La documentation décrit un fonctionnement prévu ; un journal montre un fonctionnement observé sur sa période. Aucun ne garantit qu’un export trimestriel ou une procédure d’urgence apparaît dans l’échantillon. Interrogez les métiers sur les traitements rares. Tenez une liste courte des dépendances à éclaircir. Chaque entrée comporte question, responsable et preuve recherchée. Par exemple : « L’export des recettes utilise-t-il encore cette destination en fin de mois ? » Évitez le fichier interminable d’adresses IP inconnues sans priorité. Recueillez aussi le statut de support et le responsable des mises à jour des équipements concernés. Une exposition urgente et confirmée peut imposer une action avant la fin de la cartographie. Utilisez alors la procédure d’incident ou de changement urgent, avec le responsable métier. Le calendrier de 90 jours ne justifie aucun report automatique. Le premier résultat attendu est une carte permettant d’expliquer une panne. Mettez-la à l’épreuve : si le transfert des ordres perd sa connexion, qui le remarque, qui rétablit la liaison et comment les réparations urgentes continuent-elles ? ## Jours 16 à 30 : réduire une exposition précise Choisissez quelques modifications dont l’objectif et les conséquences sont explicites : route prestataire expirée, interface d’administration accessible depuis le réseau bureautique ou règle autorisant une plage beaucoup plus large que nécessaire. Décrivez pour chacune le chemin indésirable et celui qui doit subsister. « Renforcer le logement » ne suffit pas. « Autoriser le serveur d’intégration vers le point d’accès approuvé et interdire l’interface d’administration depuis le réseau invité » permet une vérification. Validez les dépendances avant de retirer l’ancien chemin. Si une règle paraît inutilisée, vérifiez que les journaux couvrent les refus, les traitements périodiques concernés et le trajet complet. Une absence de preuve appelle une observation ou un test encadré ; elle ne démontre pas que la règle est inutile. Avant le créneau, identifiez la personne réalisant le retour arrière. Conservez la configuration précédente par un mécanisme approuvé et vérifiez qu’elle pourra joindre l’équipement même si la nouvelle règle coupe l’administration habituelle. Fixez un critère d’arrêt : transaction fictive échouée ou hausse inexpliquée des erreurs d’intégration. Datez les exceptions et leur justification. Une autorisation accordée un mois à une application ancienne doit revenir devant un décideur, plutôt que devenir une route permanente sans propriétaire. ## Jours 31 à 60 : démontrer le cloisonnement Choisissez une frontière autour d’un service ou d’une fonction d’administration. Précisez les connexions qui la traversent, leur nécessité et le point où elles sont contrôlées. Des noms de VLAN distincts ne prouvent rien à eux seuls. La réception doit démontrer les chemins permis et interdits. Réalisez des contrôles autorisés et non destructifs depuis des emplacements représentatifs. Pour le service logement fictif, le dossier de réception prévoit notamment : - Un agent termine la transaction fictive convenue dans l’application habituelle. - Le serveur d’intégration transmet cette transaction par la destination et le protocole prévus. - Un poste de test du réseau invité ne peut atteindre l’interface d’administration. - Le chemin prestataire atteint sa cible autorisée et échoue vers une cible du service recettes sans rapport avec l’intervention. - DNS, authentification, supervision et sauvegarde restent fonctionnels dans le périmètre prévu. - L’exploitant démontre le retour à la configuration précédente lors d’un exercice contrôlé ou d’une vérification de récupération équivalente. Pour un refus, distinguez une décision du contrôle de sécurité d’une cible simplement indisponible. Conservez la référence de règle ou une autre preuve du mécanisme appliqué. Pour une action autorisée, observez aussi le résultat applicatif : une connexion établie ne prouve pas l’aboutissement du parcours usager. Notre guide de [détection des mouvements latéraux](/fr/posts/detection-mouvement-lateral-securite-reseau) détaille les investigations entre systèmes. Ici, la question de réception est plus délimitée : ce compte ou ce poste peut-il traverser cette frontière au-delà de sa fonction approuvée ? Évitez de modifier toutes les frontières simultanément. Testez un service, observez son activité habituelle et examinez les erreurs avec son responsable. Reportez les corrections de dépendances dans le changement suivant au lieu de reproduire une mauvaise règle partout. ## Faire répondre les journaux à une question d’investigation Avant d’acheter du stockage, choisissez une question utile. Par exemple : « Quelle identité interne ou prestataire a utilisé le chemin d’administration du logement entre la maintenance et le premier ordre échoué ? » Il faut alors rapprocher identité, accès distant, application et réseau. Pour chaque étape, identifiez les champs disponibles : heure, fuseau, source, destination, compte, décision et référence de politique lorsque possible. Vérifiez la synchronisation des horloges et les effets de la traduction d’adresses. Une IP publique partagée ne désigne pas un agent sans éléments complémentaires. Testez la recherche d’un événement connu. Notez son délai, la personne habilitée et l’éventuelle assistance nécessaire du prestataire. Le guide pour [corréler une alerte IOC avec IP, DNS et processus](/fr/posts/alerte-ioc-correler-ip-dns-processus) explique la contribution propre à chaque type d’observation. Définissez la conservation selon l’usage et la politique approuvée : période interrogeable, archives, délai de récupération, habilitations et suppression pour chaque source. Associez les responsables de gouvernance des données et les fonctions juridiques lorsque nécessaire. Tout conserver indéfiniment ne remplace pas l’identification des preuves utiles. Énoncez les limites de couverture. « Aucune activité correspondante dans sept jours de journaux de passerelle » ne décrit ni les semaines antérieures, ni une autre route, ni une application sans audit. Pour réexaminer un renseignement récent dans des événements anciens, utilisez les distinctions temporelles du guide de [rétrochasse IOC](/fr/posts/retrochasse-ioc-logs-historiques). ## Jours 61 à 90 : exercer la continuité et décider du travail restant Simulez une panne traversant les frontières contractuelles. Dans notre collectivité fictive, le prestataire applicatif répond, mais le contact réseau habituel est indisponible. Demandez au suppléant de retrouver la modification approuvée, les journaux et la procédure de retour arrière. Cet exercice révèle une difficulté différente du simple blocage d’un paquet. Testez ensuite le fonctionnement de secours avec les agents du logement. Vérifiez comment les demandes urgentes sont enregistrées, qui autorise leur transmission téléphonique et comment les dossiers sont rapprochés après rétablissement. Évitez les fichiers personnels improvisés contenant les informations des habitants. Évaluez le rétablissement selon l’interruption et le retard de traitement acceptés par le métier. Une connexion rétablie peut laisser des dossiers en attente ou des notifications en double. Ces conséquences font partie de la récupération, même lorsque le réseau fonctionne à nouveau. Lors du bilan, présentez frontières vérifiées, transactions démontrées et dépendances encore inconnues. Comptez les services ayant un secours testé, les routes prestataires avec responsable actuel et les modifications disposant de preuves. Indiquez dénominateur et exclusions : trois services validés ne constituent pas une assurance sur tout le parc. Le format du [rapport de threat intelligence destiné à la direction](/fr/posts/rapport-threat-intelligence-direction) aide lorsqu’un problème réclame une décision budgétaire ou métier. Précisez conséquence opérationnelle, options et échéance de décision. ## Ajouter la réputation là où elle éclaire une action Une destination publique associée à une activité suspecte nécessite du contexte avant tout changement. Notez date de connexion, fonction de la destination et date du renseignement. Hébergement partagé, réattribution d’une IP et changement d’infrastructure fournisseur peuvent modifier l’interprétation. Pour une première vérification IsMalicious, choisissez une IP publique ou un domaine appartenant à la collectivité et dont l’évaluation est autorisée. Consultez le [rapport d’indicateur](/fr/report), puis joignez le résultat daté à la fiche métier. N’envoyez ni nom interne, ni secret, ni paramètre d’URL propre à un habitant. Si l’enrichissement répété est utile, définissez les besoins du pare-feu ou de la plateforme d’investigation existante : indicateurs acceptés, fraîcheur, expiration, responsable de révision et correction des faux positifs. Le [protocole d’évaluation des flux](/fr/posts/mesurer-roi-flux-threat-intelligence-benchmark) aide à mesurer les décisions réellement améliorées. La prochaine modification réseau doit laisser une trace concrète : service public identifié, approbateur nommé, action technique délimitée, preuve du fonctionnement attendu et personne capable de rétablir l’état précédent. --- # Réseau scolaire : tester et maintenir la segmentation URL: https://ismalicious.com/fr/posts/securite-reseau-etablissements-scolaires-segmentation Date: 2026-09-18T09:00:00.000Z Excerpt: Segmentez le réseau scolaire selon les usages, vérifiez les accès autorisés et interdits, préservez les outils pédagogiques et préparez un retour arrière. La sécurité du réseau scolaire se vérifie dans les connexions qu'un appareil peut établir. Un ordinateur d'élève doit ouvrir sa plateforme pédagogique sans accéder à l'application financière. Un intervenant doit pouvoir utiliser la connexion prévue sans découvrir les équipements des salles. Un contrôleur de chauffage ne doit pas créer un chemin vers l'administration. La segmentation réseau rend ces limites explicites. Son intérêt repose sur des règles appliquées et testées, pas sur le nombre de VLAN ou de réseaux Wi-Fi dessinés. L'établissement doit aussi savoir si une modification interrompra un outil d'accessibilité, l'appel, les examens ou un service indispensable du bâtiment. Ce guide propose une méthode de recette originale pour un groupement scolaire fictif comprenant deux sites. Les exemples sont synthétiques. Les références du Department for Education concernent **l'Angleterre**; les programmes du NCSC concernent **le Royaume-Uni**. Ailleurs en Europe, adaptez la méthode aux exigences de l'autorité éducative compétente. Ces étapes ne constituent pas une attestation de conformité. ## Partir d'une journée de cours Le groupement fictif de Val-des-Rives souhaite séparer les appareils pédagogiques des systèmes administratifs avant la prochaine rentrée. Son inventaire recense ordinateurs, commutateurs et serveurs. Il ne décrit pas encore les opérations que ces équipements doivent permettre pendant une journée normale. Demandez à un enseignant de montrer l'appel, la présentation d'un cours, le dépôt d'un travail et l'impression. L'équipe chargée de l'inclusion présente les outils d'assistance nécessaires. Le personnel administratif décrit ses opérations essentielles. Utilisez des comptes et documents de démonstration, sans données réelles d'élèves. Pour chaque service, notez le groupe utilisateur, le type d'appareil, la destination, les dépendances et le responsable. Une application pédagogique peut utiliser un fournisseur d'identité, un serveur de contenus et une vérification de licence. Autoriser son site principal ne garantit pas qu'un cours fonctionnera. Le [standard de cybersécurité du DfE](https://www.gov.uk/guidance/meeting-digital-and-technology-standards-in-schools-and-colleges/cyber-security-core-standard) prévoit une documentation réseau actualisée et l'examen des besoins de journalisation. Notre livrable pratique est une fiche locale permettant aux équipes pédagogiques et informatiques de définir ensemble une modification réussie. ## Regrouper les accès selon leur usage Val-des-Rives distingue, pour travailler, les appareils pédagogiques administrés, les applications du personnel administratif, les invités, la gestion informatique et les équipements du bâtiment. Ce sont des catégories de réflexion. Elles n'imposent pas exactement cinq réseaux à chaque école, collège ou établissement d'enseignement supérieur. Décrivez les conséquences d'un accès sans restriction et les connexions réellement nécessaires à chaque catégorie. Une connexion internet pour les invités ne justifie pas l'accès aux consoles internes. Une imprimante de salle peut avoir besoin d'un service d'impression contrôlé, sans pouvoir initier des sessions vers tous les postes du secrétariat. Les services partagés demandent un traitement explicite. Résolution DNS, synchronisation horaire, authentification et gestion des appareils peuvent servir plusieurs groupes. Documentez les chemins précis au lieu de placer tous leurs consommateurs dans une grande zone de confiance. Le guide de [détection du mouvement latéral](/fr/posts/detection-mouvement-lateral-securite-reseau) explique les conséquences d'une portée réseau excessive après une compromission. Ici, la question immédiate est concrète : quelle connexion permettrait de transmettre un problème d'un service scolaire vers un autre ? ## Identifier l'endroit où la règle s'applique Deux noms Wi-Fi peuvent rejoindre le même réseau routé. Des VLAN distincts peuvent communiquer librement à travers une règle générale. Un appareil peut également utiliser une prise filaire qui contourne la politique Wi-Fi récemment vérifiée. Notez le composant qui prend la décision : pare-feu, règle de commutateur, pare-feu local ou politique applicative. Identifiez qui peut le modifier et où sa configuration est sauvegardée. Si le fournisseur d'accès contrôle cette limite, demandez-lui les preuves pertinentes. La console de l'établissement ne représente pas forcément tout le chemin. Le [standard DfE sur la commutation réseau](https://www.gov.uk/guidance/meeting-digital-and-technology-standards-in-schools-and-colleges/network-switching-core-standard) traite l'infrastructure et ses fonctions de sécurité. Une capacité annoncée à l'achat ne prouve pas son activation ni l'efficacité des règles installées. Chaque règle importante reçoit un objectif et un propriétaire. « Appareils pédagogiques vers service d'impression autorisé » peut être revu. « Accès temporaire école » ne permet plus de comprendre le besoin lorsque la personne qui l'a créé est partie. ## Conserver les contrôles d'identité Un réseau segmenté ne corrige pas une application administrative qui attribue des droits privilégiés à un compte élève. Réciproquement, une connexion applicative authentifiée ne protège pas à elle seule toutes les interfaces de gestion exposées sur le réseau. Vérifiez le rôle réellement reçu par un compte de test. Un enseignant remplaçant, un enseignant permanent et un gestionnaire utilisent parfois le même bâtiment avec des droits différents. Sur les appareils partagés, examinez la fermeture de session et les profils. Le prochain utilisateur ne doit pas être présumé isolé de la session précédente. Le guide de [mise en œuvre du Zero Trust](/fr/posts/mettre-en-oeuvre-zero-trust-verification-explicite) détaille la vérification explicite. Pour ce projet, conservez une petite matrice reliant rôle, état de l'appareil et service. Recueillez uniquement les informations nécessaires à la validation. Pour une application cloud, l'établissement ne contrôle pas nécessairement le réseau interne du fournisseur. Testez les permissions d'identité et d'application dont vous disposez. Le passage par un pare-feu scolaire ne suffit pas à déclarer le service isolé. ## Préserver l'accessibilité et les usages pédagogiques La segmentation révèle parfois des dépendances jusque-là invisibles. Un équipement de projection peut utiliser la découverte locale. Une application d'assistance peut contacter un serveur de licences distinct. Une salle spécialisée peut utiliser un appareil qui ne possède pas les fonctions de gestion d'un ordinateur standard. Le responsable pédagogique ou de l'inclusion définit alors une tâche de recette. « Le site s'ouvre » est moins utile que « le compte de démonstration peut se connecter, écouter le contenu, enregistrer son travail puis le reprendre ». Notez l'exigence d'accessibilité concernée sans identifier un élève. Si une découverte entre zones est nécessaire, examinez un service limité ou une passerelle contrôlée. Autoriser tous les échanges pour rétablir un projecteur annulerait la limite recherchée. L'exception doit préciser quels appareils et quelles fonctions ont besoin du chemin supplémentaire. Pour un appareil atypique, documentez sa limitation et l'arrangement retenu. Exiger que tous les équipements fonctionnent exactement de la même manière peut écarter un besoin pédagogique légitime sans produire une solution de sécurité exploitable. ## Séparer DNS protecteur et protection des élèves Le blocage de domaines malveillants, le filtrage des contenus et le suivi des préoccupations concernant les élèves poursuivent des objectifs différents. Une destination associée à un malware appelle une analyse technique. Une préoccupation de protection des élèves suit le dispositif de l'établissement et implique les personnes autorisées. L'[annonce NCSC de PDNS for Schools](https://www.ncsc.gov.uk/blog-post/pdns-for-schools-provide-cyber-resilience-for-more-institutions) précise que le service complète le filtrage existant. Le guide du [DNS protecteur pour le secteur public](/fr/posts/dns-protecteur-secteur-public) traite la couverture des résolveurs, les appareils mobiles et les exceptions. Un résultat de réputation ne devient pas une évaluation de protection d'un élève. En Angleterre, le [standard DfE sur le filtrage et le suivi](https://www.gov.uk/guidance/meeting-digital-and-technology-standards-in-schools-and-colleges/filtering-and-monitoring-core-standard) répartit les responsabilités entre direction, protection des élèves et informatique. Identifiez ces interlocuteurs avant de modifier les chemins réseau afin qu'une exception technique reçoive la revue appropriée. Ne contournez pas un filtrage requis pour accélérer le dépannage. Testez une ressource pédagogique autorisée à travers les contrôles prévus. En cas d'échec, recherchez la cause précise et appliquez la procédure d'exception de l'établissement lorsqu'elle est pertinente. ## Tester les connexions autorisées et interdites Avant la modification, Val-des-Rives prépare quelques cas de recette. Chacun indique un groupe d'appareils représentatif, une destination contrôlée, un résultat attendu et les éléments à conserver. Ces tests autorisés restent non destructifs; ils ne nécessitent pas de scanner les vulnérabilités du réseau scolaire en production. Un appareil pédagogique doit terminer l'activité de démonstration. Un appareil invité doit atteindre la ressource internet de test, mais échouer vers un point de test administratif contrôlé. Un poste de gestion autorisé doit accéder à sa console. Le test d'un équipement technique conserve son service requis tout en refusant le chemin vers un point de test pédagogique. Utilisez une fiche courte : ```text Référence du test et modification autorisée : Groupe source et type de connexion : Destination contrôlée et opération prévue : Résultat attendu : autorisé / refusé Résultat observé et heure : Référence de preuve du contrôle : Validation pédagogique ou métier : Dépendance inattendue et responsable du suivi : ``` Une expiration de délai reste ambiguë. La destination peut être arrêtée, le DNS défaillant ou un autre contrôle peut bloquer la requête. Vérifiez la disponibilité du point de test par son chemin autorisé et examinez la trace du contrôle attendu. Sinon, un service cassé risque d'être pris pour une isolation réussie. ## Examiner les chemins facilement oubliés Rejouez les cas pertinents sur les connexions filaires et sans fil, sur les deux sites et via l'accès internet de secours approuvé. Vérifiez IPv6 lorsqu'il est utilisé, ainsi qu'IPv4. Une règle efficace pour un protocole ou un bâtiment ne démontre pas le même résultat ailleurs. Pour les appareils administrés utilisés à domicile, identifiez les politiques qui suivent l'appareil et celles qui dépendent du réseau scolaire. L'apprentissage à distance ne doit pas devenir une exception implicite. Consignez les combinaisons d'appareils et de lieux réellement prises en charge. Testez séparément l'accès à la gestion et l'usage ordinaire. Une application peut fonctionner alors que son interface d'administration reste trop accessible. Vérifiez également si une session existante survit à un changement de permission lorsque le résultat attendu impose une révocation. Conservez le contexte permettant de reproduire l'observation. La [corrélation entre IP, DNS et processus](/fr/posts/alerte-ioc-correler-ip-dns-processus) rappelle pourquoi une seule trace réseau suffit rarement à établir l'action d'une personne ou toute la séquence technique. ## Organiser le déploiement autour des cours et examens Choisissez un groupe pilote dont le responsable peut vérifier les opérations nécessaires. Convenez d'une fenêtre de changement, d'une période d'observation et des conditions de retour arrière. Une installation rapide ne justifie pas de modifier toutes les salles juste avant les examens. Vérifiez la disponibilité du support sur les sites concernés. Une recette réussie le soir ne couvre pas les appels, cours et arrivées d'invités simultanés du lendemain matin. Le pilote doit inclure une période pédagogique représentative et un moyen clair de signaler les difficultés. Conservez la configuration précédente et l'autorité nécessaire pour la restaurer. Le plan précise quels paramètres reviennent, qui décide et quels tests seront rejoués. Rétablir la connectivité sans vérifier les limites peut laisser subsister une règle d'urgence trop large. Le guide sur les [listes de blocage opérationnelles](/fr/posts/listes-blocage-prevention-menaces-operationnelle) décrit le déploiement contrôlé et la réversibilité pour un autre type de changement. La même discipline s'applique ici : définir les preuves permettant de continuer, suspendre ou annuler avant de commencer. ## Encadrer les prestataires et les systèmes techniques Un fournisseur de chauffage ou d'équipement pédagogique peut avoir besoin d'une connexion de maintenance. Cela ne justifie pas un accès permanent à tout le réseau. Consignez l'intervenant ou la relation de support, la destination, la tâche, la période autorisée et la personne capable de fermer l'accès. Les équipements du bâtiment possèdent parfois des contraintes de disponibilité et de sûreté. Coordonnez les changements avec l'équipe responsable et le fournisseur. Employez un test approuvé et évitez toute expérience perturbatrice. Un accès d'urgence conserve un objectif documenté et une revue ultérieure. Le guide sur les [accès distants des prestataires du secteur public](/fr/posts/acces-distant-prestataires-secteur-public) développe cette fiche d'accès. Pour le projet scolaire, vérifiez que la maintenance ne traverse pas les dossiers administratifs, les appareils d'élèves ou la gestion informatique sans besoin distinctement autorisé. Après l'intervention, contrôlez la fermeture attendue. Un ticket terminé ne prouve pas qu'un compte, une session distante ou une exception de pare-feu a cessé de donner accès. ## Transformer une alerte en modification examinée Lorsqu'une alerte apparaît, conservez l'heure, le groupe d'appareils et les preuves locales pertinentes. N'associez pas automatiquement une adresse IP à un élève. Une requête d'arrière-plan ne démontre pas une navigation volontaire. L'analyse technique et le traitement d'une préoccupation concernant un élève restent dans leurs circuits autorisés. Pour un domaine public ou une adresse IP dont l'analyse est approuvée, un [rapport de réputation IsMalicious](/fr/report) peut compléter le dossier technique. Soumettez uniquement l'indicateur autorisé. Les dossiers d'élèves, historiques de navigation, liens d'accès signés et pièces restreintes restent internes. Le résultat soutient une revue; il n'autorise pas un blocage automatique dans tout l'établissement. À la fin du pilote, remettez aux responsables les flux actualisés, résultats de tests, exceptions, preuves de retour arrière et questions ouvertes. Rejouez les cas concernés après un changement important d'appareil, d'application, de prestataire ou de connexion. L'établissement dispose alors d'une limite qu'il peut expliquer, tester et maintenir tout en conservant ses usages pédagogiques. --- # Attribution cyber : preuves, confiance et hypothèses concurrentes URL: https://ismalicious.com/fr/posts/attribution-cyber-niveaux-confiance-hypotheses Date: 2026-09-17T09:00:00.000Z Excerpt: Évaluez une attribution cyber sans confondre IOC et identité : preuves, hypothèses concurrentes, niveaux de confiance et modèle de jugement pour vos rapports CTI. L’**attribution cyber** consiste à relier une activité à une entité avec un raisonnement vérifiable. Le nom d’un groupe affiché à côté d’un IOC n’est que le résultat d’un jugement antérieur. Pour le reprendre dans votre rapport, il faut comprendre ce qui est attribué, à quelle date, sur quelles preuves et avec quelles alternatives. Dans une [discussion Reddit du 10 septembre 2026](https://www.reddit.com/r/isc2/comments/1wc4l5u/is_a_kevbased_threat_intelligence_report_like/), un auteur demande si son rapport de renseignement est utile et propose d’y inclure gravité, confiance et acteurs associés. La question expose un problème d’écriture analytique : ces éléments ne décrivent pas la même chose. Le fil fournit un point de départ, pas une validation technique de la méthode présentée ici. Ce guide propose un dossier de jugement qui peut être contesté et révisé. Son objectif est de soutenir les décisions de défense sans transformer une ressemblance d’infrastructure en accusation. ## Définir précisément ce que vous cherchez à attribuer L’expression « même acteur » peut recouvrir plusieurs propositions. Deux fichiers peuvent appartenir à une famille de logiciels malveillants. Deux sites peuvent utiliser le même kit. Plusieurs attaques peuvent relever d’une campagne. Une campagne peut être reliée à une équipe opérationnelle, puis éventuellement à une organisation qui la finance ou la dirige. Chaque proposition exige des preuves différentes. Une fonction de code commune éclaire une relation entre logiciels ; elle ne prouve pas qui les a exécutés. Un nom de campagne permet de regrouper des observations sans résoudre l’identité de l’opérateur. Un nom commercial attribué par un fournisseur peut désigner un périmètre différent de celui d’un autre fournisseur. Écrivez d’abord la proposition exacte : « Les sites A et B ont été administrés par la même équipe pendant la période étudiée. » Vous pourrez ensuite décider si les preuves répondent à cette question. « Tout appartient au groupe X » regroupe trop d’affirmations pour une seule conclusion. Le [regroupement d’infrastructures par DNS et certificats](/fr/posts/regroupement-infrastructures-malveillantes-dns-passif-certificats) fournit des pistes d’enquête. Une relation dans ce graphe doit conserver son type : hébergement commun, même certificat, code identique ou contrôle administratif observé. Ces liens ne sont pas interchangeables. L’[enquête guidée avec le Diamond Model](/fr/posts/diamond-model-analyse-intrusion-cti) aide à organiser les entités et leurs relations avant de comparer les explications de ces liens. ## Séparer observations, suppositions et jugements Une observation décrit ce que votre source permet de constater. Une supposition comble un manque nécessaire au raisonnement. Un jugement est la conclusion obtenue à partir des éléments retenus. Les mélanger rend difficile la relecture du dossier. Les [standards analytiques ICD 203 de l’ODNI](https://www.dni.gov/files/documents/ICD/ICD-203.pdf) demandent notamment de distinguer informations, hypothèses et jugements, d’expliquer les incertitudes et d’examiner les alternatives. Ils concernent la communauté américaine du renseignement ; nous les utilisons ici comme référence de méthode, sans les présenter comme une obligation imposée à votre entreprise. Dans un dossier concret, ces trois lignes peuvent coexister : - **Observation :** les pages collectées sur deux domaines contiennent un formulaire identique. - **Supposition :** cette version du formulaire n’est pas distribuée publiquement. - **Jugement :** les deux déploiements pourraient partager une origine opérationnelle. La deuxième ligne est décisive. Si le formulaire provient d’un kit largement disponible, sa valeur discriminante baisse. Le rapport doit montrer où cette supposition a été vérifiée, ou indiquer qu’elle reste ouverte. Une conclusion écrite sans cette limite invite le lecteur à prendre une ressemblance pour une preuve d’identité. Conservez aussi la méthode de collecte. Une capture de page observée directement, une description dans un rapport et une copie de cette description dans un agrégateur n’ont pas la même portée. Le guide d’[évaluation des sources CTI](/fr/posts/sources-threat-intelligence-evaluer-preuves) aide à examiner cette chaîne. ## Ne pas confondre vraisemblance, confiance et gravité La vraisemblance répond à la question « dans quelle mesure ce jugement est-il plausible ? ». La confiance concerne la qualité et la stabilité de ses fondements. La gravité décrit les conséquences possibles pour le périmètre concerné. Une attaque aux effets graves peut être attribuée avec peu de confiance. Le cadre britannique [Explaining Uncertainty in UK Intelligence Assessment](https://www.gov.uk/government/publications/explaining-uncertainty-in-uk-intelligence-assessment/explaining-uncertainty-in-uk-intelligence-assessment) distingue le langage probabiliste des niveaux de confiance. Il explique aussi pourquoi des pourcentages précis peuvent donner une impression de mesure que les informations disponibles ne justifient pas. Écrivez séparément le jugement et son assise. Par exemple : « Nous retenons une administration commune comme explication la plus plausible. La confiance reste faible, car les artefacts proviennent d’une seule collecte et leur caractère exclusif n’a pas été établi. » Cette formulation ne produit pas un chiffre arbitraire. Si votre organisation adopte un vocabulaire de probabilité, choisissez une convention explicite et gardez-la stable. Ne mélangez pas des mots issus de plusieurs échelles en supposant qu’ils désignent les mêmes intervalles. Le [curriculum FIRST sur l’incertitude dans les rapports CTI](https://www.first.org/global/sigs/cti/curriculum/cti-reporting) fournit une autre référence et recommande également de qualifier les jugements. Une mention « confiance élevée » doit être accompagnée d’une raison propre au dossier. « Plusieurs sources » n’est pas suffisant si elles reprennent toutes le même rapport. Expliquez plutôt les observations indépendantes, leurs limites et les informations qui pourraient modifier l’évaluation. ## Construire des hypothèses qui peuvent être mises en défaut L’analyse des hypothèses concurrentes, ou ACH, sert à examiner plusieurs explications plutôt qu’à accumuler des confirmations pour la première. Le [Tradecraft Primer de la CIA](https://www.cia.gov/resources/csi/static/Tradecraft-Primer-apr09.pdf) décrit cette technique et l’attention à porter aux éléments qui contredisent les hypothèses. Elle structure une discussion ; elle ne transforme pas mécaniquement une collection d’indices en vérité. Pour un dossier de deux sites de phishing, vous pourriez retenir : - **H1 :** une même équipe administre les deux opérations. - **H2 :** deux équipes utilisent un service commun qui fournit une partie de l’infrastructure. - **H3 :** deux déploiements indépendants reproduisent des éléments disponibles dans un kit commun. Précisez ce qui distingue réellement H2 de H3 : le service commun est-il encore exploité pendant la campagne ou s’agit-il seulement d’un composant copié ? Sans cette distinction, les hypothèses se recouvrent et leur comparaison devient confuse. Ajoutez une catégorie d’explication non résolue si les données ne permettent pas de décrire les alternatives correctement. Mieux vaut garder une limite explicite que fabriquer une troisième hypothèse absurde pour favoriser la première. Le travail porte sur les explications crédibles, avec la possibilité de reformuler le problème. ## Exemple d’attribution : deux sites, trois explications Tous les éléments de cet exemple sont synthétiques. Les domaines `alpha.example` et `beta.example` représentent des pages collectées dans un exercice. Ils ne désignent pas des infrastructures à visiter ou à bloquer. **Première observation : les pages ont la même apparence.** H1 l’explique, mais H2 et H3 aussi. Cette observation justifie une comparaison plus détaillée ; elle départage peu les scénarios. Le dossier doit éviter de compter chaque image commune comme une nouvelle confirmation indépendante. **Deuxième observation : les pages utilisent le même identifiant de collecteur.** L’équipe vérifie s’il appartient à la configuration d’un client ou s’il est présent dans une version générique du kit. Tant que cette vérification manque, l’identifiant ne prouve pas un contrôle commun. Le champ est conservé dans le dossier restreint, sans publication d’une valeur qui pourrait être sensible. **Troisième observation : les hébergements se chevauchent dans le temps.** La chronologie écarte certaines explications de simple réattribution successive d’une adresse. Elle n’exclut pas l’hébergement partagé ou le service commun. L’observation améliore une relation temporelle, pas l’identité de son opérateur. **Quatrième observation : une copie du kit contient la même configuration par défaut.** Cet élément affaiblit l’usage de l’identifiant comme preuve spécifique. Le jugement doit changer même si la première présentation associait déjà les deux sites à une campagne unique. À ce stade, le dossier peut regrouper les sites pour une recherche de comportements similaires tout en refusant une attribution à une équipe. Ce résultat reste utile : il définit un ensemble de vérifications sans exagérer ce que les données établissent. ## Chercher la preuve qui départage réellement les scénarios Après les premières observations, la question suivante n’est pas « quel autre indicateur ressemble aux précédents ? ». Demandez quel renseignement pourrait rendre une hypothèse moins plausible que les autres. Dans le cas fictif, une preuve vérifiée de comptes administratifs distincts pourrait soutenir H2 ou H3. Une observation indépendante reliant les deux déploiements à une même opération administrative renforcerait H1, dans la limite de ce que cette observation couvre. Une preuve de revente du service donnerait du poids à H2. Aucune de ces informations ne doit être supposée disponible. Définissez la collecte qui pourrait éclairer chaque point et ses limites d’accès. Une équipe d’entreprise doit travailler avec ses sources autorisées, ses propres traces et les éléments communiqués par ses partenaires. L’absence d’accès à une preuve décisive est un résultat à mentionner, pas une invitation à combler le manque par une certitude verbale. Pour chaque observation absente, demandez aussi si vos capteurs auraient pu la voir. Un journal qui ne collecte pas les événements d’administration ne peut pas exclure une administration commune. La mention « non observé » n’a de sens que si la visibilité est expliquée. Le guide d’[investigation par IP, DNS et processus](/fr/posts/alerte-ioc-correler-ip-dns-processus) détaille la recherche de traces locales. Cette corrélation peut établir une activité sur votre périmètre sans résoudre la personne ou l’organisation qui la dirige. ## Tenir un registre de jugement révisable Un registre relie la conclusion aux éléments décisifs plutôt qu’au volume du dossier. Voici un modèle de travail original : ```text Jugement : Proposition exacte et période concernée : Hypothèse retenue : Alternatives encore plausibles : Observations déterminantes et références : Éléments qui contredisent la conclusion : Sources dépendantes ou reprises : Suppositions non vérifiées : Confiance et raisons : Information qui ferait changer le jugement : Décision soutenue et limites d’usage : Auteur, réviseur, date et version : ``` Réservez une ligne à la dépendance des sources. Si un rapport A est repris par B, C et D, conservez une chaîne de provenance plutôt que quatre confirmations. Si B dispose aussi d’une collecte propre, distinguez cette portion de la reprise. Le registre doit pouvoir survivre à un changement d’analyste. Une phrase comme « attribution évidente après pivots » n’aide pas le successeur. Décrivez le pivot, la relation observée et la raison pour laquelle elle compte. L’[historique des preuves de rapport](/fr/posts/historique-rapports-menaces-reutiliser-preuves) sert de support à cette continuité, avec des observations datées. ## Associer chaque niveau d’attribution à une décision Un SOC peut rechercher une technique, isoler un poste compromis ou révoquer une session sur la base de faits locaux établis. Il n’a pas besoin d’attendre le nom d’une organisation pour prendre ces mesures. En revanche, une communication externe qui désigne un acteur demande une revue adaptée à ses conséquences. Dans la note opérationnelle, indiquez si l’attribution change le périmètre de chasse, le choix des traces ou la priorité de réponse. Si elle ne change rien à l’action immédiate, gardez-la comme contexte et ne la laissez pas prendre la place des preuves utiles. Ne transmettez pas une relation analytique comme une règle de blocage générale. Associer un domaine à un cluster ne rend pas malveillants tous les autres clients de son fournisseur. Le guide des [faux positifs de réputation IP](/fr/posts/ip-blacklistee-verifier-faux-positif) montre pourquoi la portée de l’observation doit rester visible. Lorsqu’IsMalicious apporte un résultat de réputation pendant l’enquête, conservez le verdict, sa date et son rôle exact dans le dossier. Cet enrichissement contribue à examiner une infrastructure ; il ne remplace pas la démonstration d’un lien entre activité et opérateur. ## Réviser une attribution sans effacer le raisonnement précédent Une nouvelle preuve peut modifier le jugement sans rendre inutile le travail initial. Publiez une version corrigée qui dit ce qui a changé : source retirée, artefact devenu public, erreur de chronologie ou observation supplémentaire. Identifiez les destinataires dont une décision dépendait de l’ancienne conclusion. Conservez la version précédente avec son état historique, puis indiquez clairement quelle version fait référence. Si l’attribution a alimenté des règles, des tickets ou un registre de fournisseurs, vérifiez ces sorties également. Corriger seulement le paragraphe du rapport laisse les conséquences de l’erreur en circulation. La revue finale doit permettre à un collègue de répondre à trois questions : quelle proposition est soutenue, pourquoi elle l’est et ce qui pourrait la faire tomber. Un nom d’acteur peut rester inconnu. Un raisonnement traçable permet malgré cela de choisir et de réviser les actions de défense.