Verdächtige Links kontrolliert prüfen

Verdächtige Links kontrolliert prüfen

Prüfe verdächtige URLs zuerst ohne Seitenaufruf und entscheide dann, ob ein entfernter Browser nötig ist. Erfahre, wie du sensible Links schützt, Beobachtungen festhältst und Grenzen der Analyse benennst.

Praxisanleitungen
Browser.lol
30.10.2025
20 Min. Lesezeit
Teilen

Eine Nachricht behauptet, ein Lieferant habe eine Rechnung geteilt. Der Link führt über einen Kurz-URL-Dienst, und das eigentliche Ziel ist aus der Nachricht nicht ersichtlich. Du musst beurteilen, ob es sich um Phishing handelt, ohne deinen Alltagsbrowser zur Testumgebung zu machen. Die Prüfung beginnt, bevor jemand den Link öffnet.

Eine verdächtige URL ist ein Belegstück, kann aber auch eine persönliche Kennung oder einen einmaligen Zugangscode enthalten. Dieser Leitfaden trennt Prüfungen ohne Seitenaufruf von kontrolliertem Browsen. Er zeigt, was ein entfernter Browser leisten kann, wo seine Grenzen liegen und wie du Ergebnisse festhältst, ohne einen einzelnen Scannerbefund als Sicherheitsbeweis auszugeben.

Vor dem Öffnen des Links prüfen

Links ein Browser, ein Pfeil zu einem Browser mit Lupe und ein weiterer Pfeil zu einem Dokument mit Häkchen: sichten, prüfen, berichten

Beginne mit der ursprünglichen Nachricht, nicht mit der Webseite. Bewahre Absender, Kopfzeilen, sichtbaren Linktext, tatsächliche URL und Empfangszeit auf. Kläre, ob jemand den Link geöffnet, Zugangsdaten eingegeben oder eine Datei heruntergeladen hat. Davon hängt ab, ob du nur eine verdächtige Nachricht oder bereits einen Vorfall prüfst.

Lies die URL als Daten. Prüfe Schema, Hostname, Pfad, Abfrageparameter und Fragment, ohne die Seite aufzurufen. Ein vertrauter Markenname im Pfad macht einen fremden Hostnamen nicht vertrauenswürdig. Kurzlinks und kodierte Weiterleitungen brauchen besondere Vorsicht: Schon ihr Auflösen kann das Ziel kontaktieren. Nutze dafür ein freigegebenes Prüfwerkzeug statt deines Alltagsbrowsers.

Wähle die nächste Prüfung. Vorhandene Reputationsberichte können Hinweise geben, ohne dass du die URL erneut einreichst. Ein Live-Scanner kann die Seite besuchen und einen weitergebbaren Bericht erzeugen; in einem entfernten Browser kannst du selbst sehen, was sie anzeigt. Beides liefert kein sicheres Malware-Urteil. Laut Googles Hinweisen zu den Schutzstufen hängen Safe-Browsing-Warnungen in Chrome von der gewählten Stufe und den verfügbaren Bedrohungsdaten ab.

Eskaliere nach möglichen Folgen. Hat jemand Zugangsdaten eingegeben, eine MFA-Anfrage bestätigt oder eine heruntergeladene Datei ausgeführt, folge rasch eurem Verfahren für Sicherheitsvorfälle. Auf das Urteil eines Scanners zu warten, macht eine mögliche Konto- oder Gerätegefährdung nicht rückgängig. Auch die Phishing-Hinweise der CISA empfehlen, verdächtige Nachrichten zu melden und ihre Links im normalen Gebrauch nicht zu öffnen.

Was die einzelnen Prüfmethoden übersehen

Browserfenster mit drei diagonalen Rissen und einem Warndreieck im Inhalt; darüber eine kleine Uhr

Eine Reputationsabfrage, ein URL-Scanner und ein isolierter Browser beantworten unterschiedliche Fragen. Ihre Lücken gehören zum Ergebnis, besonders bei neuen, personalisierten oder zeitlich begrenzten Links.

Reputation ist kein Urteil. Ein unauffälliges Ergebnis kann bedeuten, dass noch niemand das Ziel gemeldet hat. Weiterleitungen und Seiteninhalte können sich zudem je nach Zeitpunkt, Besucher oder Standort ändern. Chrome Safe Browsing warnt vor bekannten Gefahren; Standardschutz und erweiterter Schutz prüfen aber unterschiedlich und teilen unterschiedliche Daten mit Google. Halte fest, welche Prüfung du genutzt hast.

Öffentliche Scans geben die URL weiter. Abfrageparameter können Zugangscodes, Kundennamen oder private Dokumentlinks enthalten. Der Leitfaden von urlscan.io zur Sichtbarkeit unterscheidet öffentliche, nicht gelistete und private Scans. Auch nicht gelistete Scans sind für geprüfte Pro-Kunden zugänglich. Laut VirusTotal hält Private Scanning Einreichungen aus dem gemeinsam genutzten Bedrohungsdatenbestand heraus, anders als normale Einreichungen. Prüfe vor jeder vollständigen URL oder Datei eure Regeln zum Umgang mit Daten.

Browsen löst Interaktionen aus. Eine Website sieht die Exit-Adresse des entfernten Browsers, empfängt Anfragen, kann Cookies setzen und auf Klicks reagieren. Isolation verlagert die Ausführung weg vom Gerät der prüfenden Person; sie macht diese weder anonym noch bestätigt sie die Echtheit der Seite. Gespeicherte Profile können Browserdaten behalten. Das Schliessen des Viewer-Tabs beweist nicht, dass die Browser.lol-Session beendet wurde.

Kontrolliertes Browsen vorbereiten

Browserfenster in einem gestrichelten Isolationsrahmen, verbunden mit einer Cloud; daneben ein Schloss und eine Kamera als Symbol für einen gesonderten Beweisschritt
Trenne das Browsen, die Beweissicherung und die Eskalation als eigene Schritte.

Wähle eine Umgebung, die zum Risiko und zu euren Regeln für Beweismaterial passt. Ein entfernter Browser verringert die Belastung des lokalen Geräts durch die Ausführung von Webinhalten. Er ist jedoch nur eine Massnahme in einem grösseren Ablauf. Lege vorher fest, was du erfasst und wo diese Daten gespeichert werden dürfen.

Netzwerkpfad. Bei Browser.lol kontaktiert der entfernte Browser die Zielseite über seinen Exit. Dein Gerät verbindet sich mit Browser.lol, um den Stream zu empfangen und Eingaben zu senden. Die Zielseite sieht dadurch eine andere Adresse. Der Browserdienst kann die Aktivität weiterhin sehen; ein bestimmter Exit-Standort ist nicht garantiert, und Schutzmassnahmen für deine lokale Verbindung bleiben nötig.

Session wählen. Starte eine temporäre Session statt eines gespeicherten Profils, wenn du keinen Zustand zwischen Besuchen brauchst. Nutze ein verfügbares Browser-Image, das zur Prüfung passt. Melde dich nicht mit einem privaten oder produktiven Konto an, und verschiebe verdächtige Downloads nicht auf dein Gerät. Manche Seiten erkennen Analyseumgebungen. Eine beim Test harmlos wirkende Seite kann sich gegenüber dem eigentlichen Opfer anders verhalten.

Beweise planen. Browser.lol stellt einen gestreamten Browser bereit, aber keine automatischen Session-Aufzeichnungen, Paketmitschnitte oder SIEM-Exporte. Halte Notizen und Bildschirmbilder mit freigegebenen Werkzeugen fest, sofern eure Regeln das erlauben. Notiere Zeitpunkt, URL, beobachtete Weiterleitungen und eigene Schritte. Für belastbare Netzwerkspuren oder Malware-Analyse nutze dafür vorgesehene Werkzeuge deines Teams.

Ein wiederholbarer Prüfablauf

Gehe nur so weit, wie es die Beweislage erfordert. Hat bereits jemand Zugangsdaten eingegeben oder eine heruntergeladene Datei geöffnet, eskaliere sofort.

  1. 1

    Meldung sichten

    Bewahre die ursprüngliche Nachricht auf und kläre, ob jemand den Link geöffnet, sich angemeldet oder eine Datei heruntergeladen hat. Zugangscodes in Links, Kontotokens und Browser-Session-IDs gehören nicht in gewöhnliche Tickets.
  2. 2

    URL vor dem Öffnen prüfen

    Kopiere die URL als Text, ohne sie aufzurufen. Vergleiche den tatsächlichen Hostnamen mit dem angeblichen Absender und prüfe vorhandene Berichte. Löse Kurzlinks nicht im Alltagsbrowser auf. Entscheide, ob ein externer Scanner die vollständige URL erhalten darf.
  3. 3

    Methodisch interagieren

    Ist ein Live-Blick nötig, starte eine temporäre entfernte Session und gib die URL dort ein. Beobachte Weiterleitungen und Formularanfragen. Gib für eine kurze Linkprüfung keine echten Zugangsdaten ein, bestätige keine MFA-Anfragen und führe heruntergeladene Dateien nicht aus.
  4. 4

    Indikatoren extrahieren

    Notiere die finale Domain, sichtbare Eingabeaufforderungen und angebotene Downloads. Halte nur fest, was du wirklich beobachtet hast. Bildschirmbilder und Browser-Entwicklertools können helfen, liefern in Browser.lol aber kein automatisches forensisches Protokoll.
  5. 5

    Session beenden und eskalieren

    Beende die entfernte Session über ihre Steuerung. Lege Belege und ihre Grenzen im Fallbericht ab. Bei Verdacht auf gestohlene Zugangsdaten oder ausgeführte Schadsoftware eskalierst du nach eurem Verfahren, auch wenn Reputationsprüfungen kein eindeutiges Ergebnis lieferten.

Was du festhalten solltest

Browserfenster mit vier kleinen Etiketten, die über feine Linien mit ihm verbunden sind

Ein Indikator ist nur nützlich, wenn seine Herkunft klar ist. Unterscheide die URL aus der ursprünglichen Nachricht von Weiterleitungen, die ein Scanner oder Browser beobachtet hat. Kennzeichne Vermutungen getrennt von eigenen Beobachtungen.

Infrastrukturmerkmale können den ursprünglichen und den finalen Hostnamen, beobachtete Weiterleitungen, DNS-Antworten und Zertifikatsangaben umfassen. IP-Inhaber oder Registrierungsdaten geben zusätzlichen Kontext. Eine gemeinsam genutzte Hosting- oder CDN-Adresse identifiziert aber keinen Angreifer. Ergebnisse können sich je nach Zeitpunkt und Netzwerk unterscheiden.

Verhaltensmerkmale sind etwa Formulare für Zugangsdaten, MFA-Anfragen, Download-Aufforderungen, nachgeahmte Marken und Weiterleitungen nach einem Klick. Liefert ein spezieller Scanner HTTP-Transaktionen oder einen DOM-Schnappschuss, ordne diese Daten dem Scanner zu. Sein Besuch kann anders aussehen als der des Meldenden. urlscan.io beschreibt seine getrennten APIs für Ergebnisse und Bildschirmbilder.

Beobachtungen verständlich berichten

Ein kurzer Bericht soll der nächsten Person ermöglichen, deine Überlegungen nachzuvollziehen. Nenne die ursprüngliche Meldung, durchgeführte Prüfungen, Beobachtungszeitpunkt und eingesetztes Werkzeug oder Browser. Halte auch fest, was du nicht prüfen konntest, etwa Seiten hinter einer Anmeldung, standortabhängige Inhalte oder Einmallinks.

Trenne beobachtete Domains und Handlungen von Vermutungen über Täter oder Absicht. Füge Bildschirmbilder nur hinzu, wenn ihr Inhalt für die Empfänger des Falls freigegeben ist. Für die Weitergabe ausserhalb des Teams gelten eure Regeln; das Traffic Light Protocol von FIRST erklärt, wie TLP-Kennzeichnungen die Weitergabe begrenzen. Zugangscodes in Links und Session-Zugangsdaten gehören nicht in breit zugängliche Datenbestände.

Schliesse mit einer Entscheidung: ein bestätigtes Ziel blockieren, verwandte Aktivitäten beobachten, weitere Belege anfordern oder den Fall als unklar abschliessen. Teile der meldenden Person mit, was sie tun soll, falls sie geklickt hat. Eine Seite, die wie Phishing aussieht, beweist für sich allein weder eine Dateneingabe noch eine Gefährdung des Geräts.

Den Ablauf ins SOC einbinden

Nimm die Fragen zur ersten Einschätzung und die Felder für Belege ins normale Ticket auf. Gib dem Team eine klare Regel dafür, wann eine Reputationsabfrage genügt und wann kontrolliertes Browsen oder eine Vorfallbearbeitung nötig ist.

Baut dein Team eine Automatisierung, nutze freigegebene APIs und verwalte Fallreferenzen im eigenen System. Browser.lol bietet APIs für Sessions, aber keinen fertigen Knopf fürs Ticketsystem, keine Vorfallmarkierungen und keinen automatischen Beweisexport. Prüfe Zugriffsrechte und Datenverarbeitung jeder Integration, bevor sie eine gemeldete URL verarbeitet.

Lege Eskalationsgründe im Voraus fest: Jemand hat Zugangsdaten eingegeben, eine unerwartete Anmeldung bestätigt oder eine heruntergeladene Datei ausgeführt; oder der Fall passt zu einer bekannten Kampagne. Ein angebotener Download ist etwas anderes als ausgeführte Schadsoftware. Ein angezeigtes Formular beweist noch keinen Diebstahl von Zugangsdaten.

Prüfe eine Auswahl abgeschlossener Fälle anhand der ursprünglichen Meldungen und verfügbaren Belege. Suche nach übersehenen Weiterleitungen, allzu sicheren Urteilen und sensiblen URLs, die an öffentliche Scanner gingen. Browser.lol stellt keine Aufnahme zum späteren Abspielen bereit. Falls eine spätere Prüfung nötig ist, sichere zugelassene Belege schon während der Untersuchung.

Den Prozess messen

Wähle Kennzahlen, die dein Team aus eigenen Fällen erheben kann. Sie sollen Lücken sichtbar machen und keine pauschale Sicherheit versprechen.

Zeit

von der Meldung bis zur ersten Einschätzung

Abdeckung

Fälle mit dokumentierter Quelle, Prüfung und Grenzen

Exposition

Fälle, in denen jemand geklickt oder Daten eingegeben hat

Vergleiche diese Werte über die Zeit mit gleichbleibenden Definitionen. Ein schnelleres Urteil ist kein Fortschritt, wenn dabei eine Person übersehen wird, die Zugangsdaten eingegeben hat. Ein entfernter Browser kann eine Art Belastung des lokalen Geräts verringern, beweist aber nicht, dass jede bösartige Seite oder jeder Download eingedämmt wurde.

Setze den Ablauf in der Praxis ein

Beginne mit der Prüfung ohne Seitenaufruf und beachte, welche Daten der Link offenlegen könnte. Wechsle nur dann zum kontrollierten Browsen, wenn es eine konkrete Frage beantwortet. Für Dateien oder forensische Erfassung brauchst du dafür vorgesehene Analysewerkzeuge.

Browser.lol kann den entfernten Browser für diesen Sichtungsschritt bereitstellen. Beende die Session ausdrücklich, halte Beobachtungen mit zugelassenen Werkzeugen fest und benenne im Bericht auch, was die Umgebung nicht zeigen konnte.

Brauchst du für deine nächste Aufgabe eine isolierte Session?

Starte eine isolierte Session direkt im Web.

Session starten

Keine Browserinstallation nötig • Funktionen je nach Plan

Für Recherche und Tests
Desktop-Browser im Browserfenster
In wenigen Schritten startklar

Neueste Beiträge

Alle Beiträge