Ein Eintrag von aocr.org als Referrer in deiner Besucherstatistik beweist weder einen echten Besuch von dieser Website noch einen Angriff auf deinen PC. Die Verweisquelle kann von einem normalen Seitenaufruf stammen, durch einen Bot vorgetäuscht oder lediglich in die Webanalyse eingeschleust worden sein. Prüfe zuerst, ob zu den auffälligen Statistikdaten passende Zugriffe in den Server- oder CDN-Protokollen existieren. Erst danach lässt sich entscheiden, ob du nur deine Auswertung bereinigen oder zusätzlich Anfragen an deine Website begrenzen solltest.
Allein aus dem Domainnamen lässt sich aocr.org nicht belastbar als schädlich oder als Spam-Absender einstufen. Eine gefälschte Verweisangabe kann außerdem eine unbeteiligte Domain nennen. Für die Diagnose sind daher das Verhalten der vermeintlichen Besucher und die technische Herkunft der Messdaten maßgeblich, nicht der bloße Name im Bericht.
aocr.org in der Besucherstatistik: Diese Prüfung kommt zuerst
Der kürzeste sinnvolle Prüfweg führt vom einzelnen Statistikeintrag zum tatsächlich beobachteten Websitezugriff. Öffne aocr.org dafür nicht vorschnell im Browser: Ein Besuch der angezeigten Verweisquelle ist für diese Untersuchung nicht erforderlich.
- Öffne den Bericht mit den auffälligen Verweisen und grenze den betroffenen Zeitraum ein. Notiere die Zeitzone, die angezeigte Quelle, die Zielseite auf deiner Website und die Zahl der Sitzungen beziehungsweise Aufrufe. Diese Messgrößen sind nicht gleichbedeutend.
- Prüfe, ob aocr.org als Sitzungsquelle, als vollständiger Seitenverweis oder nur in einer benutzerdefinierten Auswertung erscheint. Ein Quellenname ist nicht automatisch der unveränderte HTTP-Header einer Anfrage.
- Suche für denselben Zeitraum im Zugriffsprotokoll deines Hosters, Webservers oder vorgeschalteten CDN nach passenden Anfragen. Vergleiche Zielpfad, Zeitpunkt und gegebenenfalls den protokollierten Referrer.
- Bewerte das Ergebnis: Passende Requests sprechen für tatsächlichen Traffic, aber noch nicht für menschliche Besucher. Fehlen passende Requests trotz vollständiger Protokolle, untersuche die Messdatenerfassung, bevor du eine Serversperre einrichtest.
Falls du keinen Zugriff auf solche Protokolle hast, bitte deinen Hosting-Anbieter um die Access-Logs des betroffenen Zeitraums einschließlich Referrer und User-Agent. Der User-Agent ist die vom anfragenden Programm übermittelte Browser- oder Softwarekennung. Auch diese Angabe lässt sich fälschen und ist allein kein Identitätsnachweis.
Was ein Referrer tatsächlich aussagt
Ein Referrer beschreibt die vorherige Seite, die ein Browser beim Aufruf einer anderen Seite mitteilt. Der zugehörige HTTP-Anfrageheader heißt historisch Referer, obwohl der allgemeine Begriff Referrer mit zwei r geschrieben wird. Browser können diese Information abhängig von der Referrer-Policy kürzen oder ganz weglassen.
Ein Bot muss sich nicht wie ein Browser verhalten. Er kann einen beliebigen Wert in diesen Header schreiben und dabei aocr.org nennen, ohne diese Website zuvor besucht zu haben. Im Serverprotokoll steht dann zwar ein echter Request an deine Website, aber die behauptete Herkunft ist nicht belegt.
Davon zu unterscheiden ist die Aufbereitung im Analysewerkzeug. Eine Sitzungsquelle kann aus Referrer-Daten, Kampagnenparametern oder Regeln zur Zuordnung von Besuchen entstehen. Die sichtbare Quelle aocr.org und ein im Access-Log gespeicherter Referrer sind deshalb zwei getrennte Prüfpunkte.
Auch die IP-Adresse gehört zu einer anderen Ebene: Sie beschreibt die Netzwerkadresse, von der die Verbindung bei deinem Server oder vorgeschalteten Dienst ankommt. Der Domainname im Referrer ist nicht automatisch der Rechner, der die Anfrage gesendet hat. Eine DNS-Sperre für aocr.org auf deinem Windows-PC verhindert daher keine entsprechend beschrifteten Anfragen an deinen Webserver.
Drei mögliche Erklärungen für die auffälligen Verweise
Ein tatsächlicher Verweis oder eine Weiterleitung
Normale Besucher können über einen Link oder eine Weiterleitung auf deine Website gelangen. Dafür sprechen passende Zielseiten, nachvollziehbare zeitliche Muster und anschließende Aktionen, etwa weitere Seitenaufrufe oder ein Formularaufruf. Diese Merkmale machen menschliche Nutzung plausibel, beweisen sie jedoch nicht.
Ein Referrer muss zudem nicht dauerhaft reproduzierbar sein. Ein Link kann entfernt worden sein, nur angemeldeten Nutzern angezeigt werden oder über eine Weiterleitung geführt haben. Dass du bei einer späteren Prüfung keinen Link findest, reicht daher nicht aus, um den ursprünglichen Besuch als Spam einzuordnen.
Ein Bot sendet aocr.org als gefälschten Referrer
Bei klassischem Referral-Spam ruft automatisierte Software deine Website auf und hinterlässt eine auffällige Domain als Verweisquelle. Ein mögliches Ziel ist, dass Websitebetreiber diese Domain aus Neugier öffnen. Der einzelne Eintrag belegt allerdings weder diese Absicht noch eine Beteiligung des Domaininhabers.
Hinweise auf automatisierte Zugriffe sind gleichförmige Anfragen in kurzen Abständen, wiederholte Aufrufe desselben Pfades oder zahlreiche Anfragen an nicht vorhandene Seiten. Ein fehlender Abruf von Bildern und Skripten kann ebenfalls dazu passen. Browser-Caches, blockierte Ressourcen und bestimmte Anwendungen können aber ähnliche Spuren hinterlassen.
Entscheidend wird das Gesamtbild: Wiederholen sich dieselben technischen Merkmale über viele Anfragen, ist eine Bot-Hypothese belastbarer als bei einem einzelnen kurzen Besuch.
Die Messdaten enthalten Ereignisse ohne passenden Seitenabruf
Beim sogenannten Ghost-Spam erscheinen Daten im Analysewerkzeug, obwohl kein entsprechender Seitenabruf an deiner Website stattgefunden hat. Je nach Messsystem können manipulierte Erfassungsanfragen oder fehlerhafte Integrationen ähnliche Ergebnisse verursachen. Eine öffentlich sichtbare Messkennung allein beweist keine solche Manipulation.
Weitere mögliche Erklärungen sind ein auf einer fremden Website eingebundenes Tracking, eine falsch konfigurierte serverseitige Erfassung oder Daten aus einer Testumgebung. Prüfe deshalb auch den aufgezeichneten Hostnamen: Gemeint ist hier die Domain, auf der das gemessene Ereignis angeblich stattfand, nicht die Referrer-Domain.
Fehlende Servereinträge sind nur dann aussagekräftig, wenn die Protokolle vollständig sind. Ein CDN kann Seiten aus seinem Cache ausliefern, ohne dass dein Ursprungsserver jeden Abruf sieht. Auch verkürzte Aufbewahrung, abweichende Zeitzonen oder ein Logformat ohne Referrer können den Vergleich verfälschen.
Zugriffsprotokolle unter Windows gezielt durchsuchen
Wenn du die Access-Logs als Textdateien heruntergeladen hast, kannst du sie mit PowerShell durchsuchen. Die folgende Suche liest ausschließlich vorhandene Dateien; sie verändert weder die Protokolle noch die Serverkonfiguration. Administratorrechte sind nicht erforderlich, sofern dein Windows-Konto Leserechte für den Ordner besitzt.
Lege die zu untersuchenden, bereits entpackten Logdateien in diesem Beispiel unter folgendem Ordner ab:
C:\LogsDie folgende Suche berücksichtigt Dateien mit der Endung .log direkt in diesem Ordner und gibt Fundstellen mit Dateiname und Zeilennummer aus:
Get-ChildItem -LiteralPath C:\Logs -Filter *.log -File | Select-String -SimpleMatch -Pattern aocr.orgBei IIS-Protokollen beschreibt die Zeile #Fields: die Reihenfolge der Felder. Ist das Referrer-Feld aktiviert, wird es als cs(Referer) bezeichnet. Bei Apache- oder Nginx-Protokollen hängt die Feldreihenfolge von der eingerichteten Protokollierung ab. Fehlende Treffer sagen wenig aus, wenn der Referrer gar nicht gespeichert wurde oder deine Dateien eine andere Endung haben.
Vergleiche bei Treffern den Zeitpunkt, den angefragten Pfad und den HTTP-Status. Viele Antworten mit Status 404 bedeuten, dass die angeforderten Ressourcen nicht gefunden wurden. Status 200 zeigt eine erfolgreiche Antwort, aber weder einen erfolgreichen Angriff noch einen menschlichen Besucher.
Die Statistik bereinigen, ohne die Ursache zu verdecken
Beginne mit einer ausblendbaren Berichtsauswahl statt mit einer dauerhaften Änderung der Datenerfassung. So bleiben die ursprünglichen Daten für spätere Vergleiche erhalten. Die Bereinigung eines Berichts und das Blockieren von Websitezugriffen lösen unterschiedliche Probleme.
Google Analytics 4: Sitzungsquelle und Seitenverweis getrennt betrachten
Für eine erste Untersuchung eignet sich in Google Analytics 4 der Bericht zur Traffic-Akquisition. Verwende die Dimension Sitzungsquelle/Medium und prüfe, ob aocr.org tatsächlich als Quelle mit dem Medium referral erscheint. Die Navigation und verfügbaren Anpassungen können sich je nach Property und Berechtigung unterscheiden.
Erstelle für die Auswertung einen Berichtsfilter oder eine explorative Datenanalyse, die den exakt erfassten Quellenwert ausschließt. Vergleiche die Kennzahlen mit der ungefilterten Ansicht. Beziehe Unterdomains nur ein, wenn sie in deinen Daten auftreten und ebenfalls untersucht wurden. Ein pauschaler Textfilter kann sonst unbeteiligte Werte erfassen.
Die Einstellung für unerwünschte Verweise findest du in den Einstellungen des Web-Datenstreams unter den Google-Tag-Einstellungen; gegebenenfalls musst du weitere Einstellungen einblenden. Diese Funktion dient der Quellenzuordnung, beispielsweise bei Rückkehr von Zahlungsdiensten. Sie ist keine Firewall und kein allgemeiner Löschfilter für Spam-Ereignisse.
Ein dort eingetragener Verweis blockiert keine Anfragen an deine Website und entfernt auch nicht rückwirkend die betreffenden Messdaten. Für die Bewertung von aocr.org ist eine getrennte Berichtsauswertung daher der nachvollziehbarere erste Schritt.
Matomo: Einzelbesuche statt nur die Verweisliste prüfen
In Matomo hilft das Besucherprotokoll, um die hinter einer Verweisquelle liegenden Besuche zu untersuchen. Prüfe die aufgezeichneten Aktionen, Zielseiten und Zeitpunkte der Einträge mit aocr.org. Ein Segment für die entsprechende Verweisquelle ermöglicht den Vergleich mit den übrigen Besuchen, ohne die Rohdaten zu löschen.
Ausschlüsse über IP-Adressen oder User-Agents solltest du erst nach der Logprüfung erwägen. Geteilte IP-Adressen können auch legitime Besucher betreffen, und ein Bot kann seine Kennung wechseln. Eine einzelne vermeintliche Bot-Adresse ist daher keine dauerhafte Lösung für jeden Eintrag mit diesem Referrer.
Tatsächliche Bot-Anfragen begrenzen: Sperre nach Befund wählen
Eine serverseitige Maßnahme ist sinnvoll, wenn die Protokolle reale unerwünschte Requests zeigen. Nutze dafür möglichst eine vorhandene WAF oder die Sicherheitsfunktionen deines CDN beziehungsweise Hosters. Eine Web Application Firewall kann Anfragen nach Bedingungen prüfen, protokollieren, begrenzen oder blockieren.
Beginne, wenn verfügbar, im Protokollierungsmodus. Prüfe die erkannten Anfragen und aktiviere eine Blockierung erst, wenn die Treffer zum untersuchten Muster passen. Teste danach deine Startseite, wichtige Unterseiten und Formulare. Speichere die Regel so, dass du sie bei Fehlalarmen gezielt deaktivieren kannst, ohne andere Schutzfunktionen abzuschalten.
Bei hoher Zugriffslast ist eine reine Referrer-Sperre leicht zu umgehen: Der Bot kann den Header ändern oder weglassen. Rate-Limits und verhaltensbasierte Regeln können dann zweckmäßiger sein. Die Schwelle muss zum normalen Traffic deiner Website passen; ein pauschaler Grenzwert könnte legitime Besucher oder regelmäßig abrufende Dienste treffen.
Eine entsprechende Regel in der Windows-Firewall deines Arbeitsplatzrechners erreicht dieses Ziel nicht. Sie kontrolliert nicht die HTTP-Header von Verbindungen, die bei einem extern gehosteten Webserver ankommen. Auch eine Änderung der lokalen Hosts-Datei bereinigt weder die Webstatistik noch stoppt sie solche Serveranfragen.
Wann aus dem Referrer ein Sicherheitsfall wird
Ein fremder Verweis in einer Statistik ist für sich genommen kein Hinweis auf eine Infektion deines Windows-PCs oder auf eine kompromittierte Website. Eine weitergehende Sicherheitsprüfung wird erforderlich, wenn unabhängige Auffälligkeiten hinzukommen: unbekannte Administratorkonten, unerklärliche Dateiänderungen, manipulierte Weiterleitungen oder erfolgreiche unberechtigte Anmeldungen.
Sichere in diesem Fall zuerst verfügbare Protokolle und die betroffenen Zeitpunkte. Prüfe anschließend die Konten und Sicherheitsmeldungen deines Hosters sowie die Benutzerverwaltung deines Content-Management-Systems. Bei sichtbaren Manipulationen solltest du den Hosting-Support einbeziehen, statt lediglich aocr.org aus dem Bericht auszublenden.
Hast du die Verweisquelle bereits geöffnet, rechtfertigt der Seitenaufruf allein noch keine Neuinstallation. Wurde jedoch eine Datei heruntergeladen und gestartet, eine Erweiterung installiert oder wurden Zugangsdaten eingegeben, liegt ein anderer Prüfbedarf vor. Kontrolliere dann Downloads und Erweiterungen, führe einen Scan mit Microsoft Defender durch und ändere betroffene Zugangsdaten bei Verdacht von einem vertrauenswürdigen Gerät aus.
Woran du erkennst, ob die Maßnahme wirkt
Die Erfolgskontrolle richtet sich nach dem Eingriff. Bei einem Berichtsfilter müssen die verdächtigen Einträge in der gefilterten Auswertung fehlen, während die Originalansicht unverändert bleibt. Bei einer WAF-Regel müssen deren Ereignisse zeigen, dass passende Requests erkannt und entsprechend behandelt werden. Bei einer korrigierten Messkonfiguration sollten neue Ereignisse nur noch den vorgesehenen Hostnamen und Datenquellen zugeordnet sein.
Beurteile neue Daten erst nach der üblichen Verarbeitungszeit deines Analysewerkzeugs und vergleiche gleich lange Zeiträume. Das Verschwinden von aocr.org allein beweist nicht, dass ein Bot verschwunden ist: Er könnte lediglich einen anderen Referrer verwenden. Maßgeblich ist, ob die unerwünschten Zugriffsmuster oder fehlerhaften Messereignisse zurückgehen und legitime Besucher deine Website weiterhin nutzen können.
