> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/help/help-nl/email-security/link-analysis.md). # Linkanalyse Email Security inspecteert de links die worden gevonden in de e-mails die het analyseert. Hier is wat onze systemen met die links doen, en hoe u een link meldt die met rust gelaten moet worden. ## Waarom links worden opgelost Phishing verraadt zich zelden in de tekst van een bericht. Het signaal zit in de bestemming: een verkorte link die uitkomt op een lookalike-domein, of een omleidingsketen die eindigt op een domein dat drie dagen geleden is geregistreerd. Een link lezen zoals hij is geschreven vertelt ons niets van dat alles. De link moet worden opgelost om te zien waar hij daadwerkelijk naartoe gaat. ## Wat de analyse doet Voor elke link in een geanalyseerde e-mail stuurt Stoïk één HTTP `HEAD` verzoek en volgt tot vijf omleidingen. Een `HEAD` verzoek vraagt een server alleen om de responseheaders. Het is hetzelfde verzoek als het openen van de pagina, minus de paginainhoud. Het wordt gebruikt in plaats van een volledige paginalaadbeurt omdat het de lichtste manier is om te achterhalen waar een link naartoe leidt. Daaruit registreert Stoïk het einde van de omleidingsketen, het aantal hops, en de reputatie van het bestemmingsdomein. Het verzoek loopt af na twee seconden. ## Wanneer de analyse verder gaat Als het bestemmingsdomein verdacht lijkt, wat betekent dat het een slechte reputatie heeft, onlangs is geregistreerd, of zelden wordt gezien in de mailboxen die we beschermen, wordt de pagina geopend in een geïsoleerde browseromgeving en wordt een screenshot gemaakt. Een visionmodel beoordeelt vervolgens of de pagina een kit voor het verzamelen van inloggegevens is, en welk merk het nabootst. Een domein dat goed gevestigd is en vaak wordt gezien, bereikt die fase nooit. Een link naar een grote provider wordt wel opgelost, maar de pagina wordt nooit geladen. Het laden van een pagina betekent dat de pagina zijn eigen JavaScript uitvoert, precies zoals dat zou gebeuren in de browser van een bezoeker, en een pagina kan ondertussen ook zelf verzoeken doen. Die verzoeken komen van de pagina, niet van instructies die wij haar geven. Wanneer een pagina onbereikbaar is vanwege een anti-bot-uitdaging, loopt de capture via een solver die eerst de uitdaging afhandelt. ## Wat de analyse nooit doet Stoïk handelt niet namens u. Onze analyse klikt op geen enkele knop, vult geen enkel formulier in, en gebruikt nooit uw inloggegevens. Waar een link iets zou activeren enkel en alleen door het op te vragen, wordt die helemaal niet opgevraagd: zie [Links die volledig worden overgeslagen](#links-that-are-skipped-entirely). ### Uitzondering: platforms voor het delen van bestanden Aanvallers laten een groeiend deel van hun phishing via legitieme bestandsdelingsdiensten lopen. Een document dat vanaf een bekend platform wordt gedeeld, leent de reputatie van dat platform en komt langs de meeste filters, terwijl de valstrik in het gedeelde bestand zit. Zo'n e-mail beoordelen betekent lezen wat er daadwerkelijk is gedeeld. Deze platforms geven een gedeeld document niet door via een gewone paginalaadbeurt. Erbij komen betekent de aanvraag doen die het platform daarvoor definieert: een query naar zijn eigen API, of de anonieme authenticatiestap die een deel-link uitvoert met behulp van de sleutel die al in de link zit. Stoïk doet dit alleen op de platforms die het expliciet ondersteunt, en alleen met wat de link al bevat. ## Links die volledig worden overgeslagen Sommige links veranderen iets op het moment dat ze worden opgevraagd, zelfs door een `HEAD`. Een elektronische handtekeninglink kan een document als bekeken markeren of een eenmalige token verbruiken. Een link naar een quarantaineoverzicht kan een geblokkeerde e-mail vrijgeven. Een link voor afmelding met één klik haalt de ontvanger van een mailinglijst, en een link voor een agenda-uitnodiging kan een RSVP registreren. De HTTP-standaard is hier expliciet. RFC 9110 sectie 9.2.1 definieert `GET` en `HEAD` als veilige methoden: een client die er een verzendt, vraagt noch verwacht enige wijziging van de toestand op de server. In dezelfde sectie wordt toegevoegd dat wanneer een parameter in de URL een actie selecteert, de eigenaar van die bron de actie moet uitschakelen wanneer die met een veilige methode wordt bereikt. De regel bestaat zodat geautomatiseerde opvraging kan werken zonder schade te veroorzaken. Niet elke dienst volgt dat. {% hint style="info" %} Stoïk houdt een toestemmingslijst bij van bestemmingen die volledig worden overgeslagen, zonder dat er überhaupt een verzoek wordt verzonden. Deze omvat e-mailondertekeningsplatforms, portalen voor e-mailquarantaine, eindpunten voor afmelding voor nieuwsbrieven en reacties op agenda-uitnodigingen. {% endhint %} ## Een link melden Als u een actie ziet op een van uw services waarvan u denkt dat die uit onze analyse komt, meld dit dan aan Stoïk via uw gebruikelijke supportkanaal. Nuttige details: * De betrokken service * Het adres van de getroffen mailbox * Ongeveer wanneer het gebeurde * De link zelf, als u die nog heeft De bestemming wordt toegevoegd aan de toestemmingslijst, en u krijgt bericht zodra de wijziging live is. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/help/help-nl/email-security/link-analysis.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.