IT-Sicherheit · IT-Forensik · Incident Response
Sie wurden gehackt – oder haben ein komisches Gefühl?
Wir helfen Ihnen. Mit strukturierter IT-Forensik, Incident Response und verständlicher Dokumentation klären wir, was sich mit den verfügbaren Belegen feststellen lässt – und welche Schritte jetzt sinnvoll sind.
Erst einordnen, dann handeln
Ob akuter Vorfall, unklare Auffälligkeit oder Vorbereitung auf den Ernstfall: Wir beginnen mit einer sauberen Einordnung und greifen nicht ungefragt in Ihre Systeme ein.
Entscheidungshilfe
Welcher Einstieg passt zu Ihrer Situation?
Akuter Vorfall
Ihre Website leitet unerwartet weiter, ein System ist nicht mehr erreichbar, unbekannte Konten sind aufgetaucht oder es gibt konkrete Hinweise auf Manipulation.
- relevante Spuren nicht versehentlich überschreiben
- betroffene Systeme und Abhängigkeiten eingrenzen
- Eindämmung und Wiederherstellung sinnvoll priorisieren
- bestätigte Befunde von Vermutungen trennen
- die nächsten Schritte nachvollziehbar dokumentieren
Die Auswahl kennzeichnet die Situation, begründet aber keine zugesagte Reaktionszeit.
Verdacht prüfen lassen
Etwas wirkt anders als sonst, aber Sie wissen nicht, ob es ein Sicherheitsproblem, ein technischer Fehler oder eine harmlose Änderung ist.
- bestätigt: durch Belege nachvollziehbar
- unklar: mit den verfügbaren Daten nicht abschließend bewertbar
- nicht gefunden: nur innerhalb des benannten Suchraums und mit Gegenprobe
- empfohlen: priorisierte nächste Schritte mit Begründung
Sie erhalten keine dramatische Vermutung, sondern eine belastbare Einordnung.
Prävention
Es ist nichts passiert, und genau deshalb ist jetzt der günstigste Zeitpunkt: Härtung, Vorbereitung und Beweissicherungsfähigkeit lassen sich in Ruhe aufbauen.
- Website- und Server-Hardening entlang benannter Prüfrahmen
- Security-Analyse technischer Abhängigkeiten
- Incident Readiness mit erreichbaren Verantwortlichkeiten
- Logging-, Backup- und Wiederanlaufkonzepte
- Beratung zu Verschlüsselung, Schlüsseln und Secrets
Prävention ersetzt keinen Vorfall-Ausschluss. Sie senkt Wahrscheinlichkeit und Schadenshöhe.
Nach dem ersten Gespräch
Erst einordnen, dann handeln
Was ist tatsächlich belegt?
Wir dokumentieren Quellen, Zeitbezug und Prüfbereich. So bleibt erkennbar, worauf eine Aussage beruht – und wo eine Schlussfolgerung noch offen ist.
Was muss jetzt passieren?
Sie erhalten priorisierte Maßnahmen statt einer unstrukturierten Liste technischer Einzelbefunde: zuerst Schäden begrenzen, dann Ursachen und Reichweite klären, anschließend belastbar härten.
Was darf warten?
Nicht jede Auffälligkeit ist ein Notfall. Wir helfen dabei, akute Risiken von technischen Altlasten und normalen Verbesserungen zu trennen.
Was bleibt unklar?
Gute Forensik benennt Grenzen. Fehlende Logs, überschriebene Daten oder externe Plattformen können eine eindeutige Rekonstruktion verhindern. Das wird transparent festgehalten.
Leistungen
Sechs Bausteine – einzeln oder aufeinander aufbauend
IT-Forensik
Was ist passiert – und was lässt sich davon belegen?
- zeitliche Rekonstruktion aus verfügbaren Artefakten
- Analyse von Dateien, Konfigurationen, Logs und Weiterleitungen
- Abgleich von Domains, Diensten und technischen Abhängigkeiten
- Integritäts- und Plausibilitätsprüfungen
- klare Kennzeichnung von Fakten, Hypothesen und Beleglücken
- technischer Befundbericht für die weitere Bearbeitung
Incident Response
Wie begrenzen wir den Vorfall und kommen kontrolliert weiter?
- Lagebild und abgestimmter Scope
- Priorisierung von Eindämmung, Sicherung und Wiederherstellung
- Koordination technischer Maßnahmen innerhalb der erteilten Freigaben
- Dokumentation getroffener Entscheidungen
- Nachbereitung mit Ursachen- und Maßnahmenübersicht
Security-Analyse
Wo liegen nachvollziehbare Risiken und Abhängigkeiten?
- Angriffsfläche und öffentlich sichtbare Exposition
- Rollen, Konten und Berechtigungen
- Drittanbieter, Tracking, Consent und externe Ressourcen
- DNS-, TLS-, Header- und Weiterleitungskonfiguration
- Update-, Backup- und Monitoring-Prozesse
- priorisierte Handlungsempfehlungen
Server-Hardening
Wie reduzieren wir vermeidbare Angriffsflächen?
- Dienste und Zugänge auf das notwendige Maß begrenzen
- Rechte nach dem Least-Privilege-Prinzip ordnen
- Update- und Patchpfade nachvollziehbar machen
- sichere TLS-, Header- und Secret-Konfiguration
- Backups und Wiederherstellbarkeit prüfen
- Logging und Alarmierung auf den tatsächlichen Bedarf ausrichten
Incident Readiness
Sind wir vorbereitet, wenn etwas passiert?
- Verantwortlichkeiten und Eskalationswege
- erreichbare Kontakt- und Entscheidungslisten
- Logging-, Backup- und Beweissicherungsanforderungen
- kompakte Response-Runbooks
- Übungen anhand realistischer Szenarien
- überprüfbare Übergabe- und Wiederanlaufkriterien
Kryptografie-Beratung
Wo schützt Verschlüsselung wirklich – und wie werden Schlüssel sicher verwaltet?
- Verschlüsselung bei Übertragung und Speicherung
- Schlüssel-, Zertifikats- und Secret-Lebenszyklen
- Hashes, Signaturen und Integritätsnachweise
- Rotation, Widerruf und Wiederherstellung
- Auswahl etablierter Verfahren statt selbst erfundener Algorithmen
- verständliche Entscheidungsgrundlagen für Technik und Organisation
Prüfrahmen
Woran wir prüfen: anerkannte Prüfrahmen
Eine Prüfung ohne benannten Rahmen ist eine Meinung. Wir arbeiten deshalb entlang öffentlich dokumentierter Referenzen und machen sichtbar, welcher Teil davon im jeweiligen Auftrag tatsächlich geprüft wurde.
OWASP Top 10:2021
Ordnungsrahmen für Anwendungs- und Konfigurationsrisiken.
OWASP ASVS
Raster für die Prüftiefe, wenn eine Anwendung strukturiert geprüft werden soll.
OWASP Web Security Testing Guide
Methodenreferenz für einzelne Prüfschritte.
CIS Benchmarks
Härtungsleitfäden für Betriebssysteme und Dienste, alternativ die Vorgaben des jeweiligen Herstellers.
BSI IT-Grundschutz
Einordnungshilfe für organisatorische Fragen.
Diese Rahmenwerke sind frei verfügbare Referenzen. Ihre Verwendung ist keine Zertifizierung, keine Akkreditierung und kein Audit-Testat. Wir treten nicht als zertifizierte Prüfstelle auf und stellen keine Konformitätsbescheinigung aus.
Typische Szenarien, geordnet nach OWASP Top 10:2021
Die folgenden Beispiele beschreiben, wie sich diese Risikoklassen im Alltag von Websites, Shops und Serverumgebungen zeigen. Sie sind Anschauung, keine Aussage über Ihr System.
A01 · Fehlerhafte Zugriffskontrolle
Ein ausgeschiedener Mitarbeiter erreicht über einen alten Direktlink weiterhin Kundendaten, oder eine Bestell- beziehungsweise Buchungsansicht lässt sich durch Ändern einer Nummer in der URL für fremde Vorgänge öffnen.
A02 · Kryptografische Schwächen
Backups oder exportierte Formulardaten liegen unverschlüsselt, eine veraltete TLS-Konfiguration ist noch aktiv, oder Zugangsdaten sind mit einem überholten Hashverfahren gespeichert.
A03 · Injection
Ein Kontaktformular, ein Suchfeld oder ein Filterparameter reicht Eingaben ungeprüft an Datenbank, Mailversand oder Systembefehle weiter.
A04 · Unsicheres Design
Ein Prozess besitzt keine Missbrauchsgrenzen: Gutscheine, Terminslots, Registrierungen oder Versandvorgänge lassen sich automatisiert in Masse auslösen.
A05 · Sicherheitsrelevante Fehlkonfiguration
Eine Debug- oder Adminoberfläche ist öffentlich erreichbar, ein Standardzugang ist noch aktiv, Verzeichnisse sind auflistbar, Security-Header fehlen oder eine CORS-Regel ist zu weit gefasst.
A06 · Verwundbare und veraltete Komponenten
Ein CMS, ein Plugin, ein Theme oder ein JavaScript-Paket steht auf einem Stand mit öffentlich dokumentierter Schwachstelle.
A07 · Fehler bei Identifikation und Authentifizierung
Der Administrationszugang hat keine zweite Faktorstufe, Loginversuche sind nicht begrenzt, oder bestehende Sitzungen bleiben nach einem Passwortwechsel gültig.
A08 · Integritätsverletzungen in Software und Daten
Ein eingebundenes Drittanbieter-Skript wird an der Quelle verändert, oder ein Auslieferungsweg akzeptiert Artefakte ohne Integritätsprüfung.
A09 · Lücken bei Logging und Monitoring
Der Vorfall fällt erst Wochen später auf, weil Protokolle fehlen, zu früh rotiert wurden oder nie ausgewertet werden. Das ist zugleich der häufigste Grund, warum eine spätere Rekonstruktion nur eingeschränkt möglich ist.
A10 · Server-Side Request Forgery
Eine Serverfunktion ruft Adressen ab, die von außen bestimmt werden können, und erreicht darüber interne Dienste, die nicht öffentlich erreichbar sein sollten.
Hardening-Prüfpunkte
Für Server- und Website-Hardening prüfen wir überprüfbare Einzelpunkte statt eines Gesamteindrucks. Dazu gehören je nach Umgebung:
- erreichbare Dienste und offene Ports gegen den tatsächlichen Bedarf
- Fernzugänge, Passwortanmeldung, Schlüsselverwaltung und Rechtetrennung
- Patchstand und der Weg, auf dem Sicherheitsupdates künftig ankommen
- TLS-Version, Cipher-Auswahl, Zertifikatskette und Weiterleitungsverhalten
- Security-Header wie HSTS, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy und Permissions-Policy
- Ablage und Rotation von Secrets, Tokens und Zugangsdaten
- Backups einschließlich einer tatsächlich durchgeführten Rückspielprobe
- Logumfang, Aufbewahrungsdauer und Alarmierung entlang des realen Bedarfs
Ablauf
So läuft die Zusammenarbeit ab
Situation eingrenzen
Sie schildern knapp, was beobachtet wurde, welche Systeme betroffen sein könnten und ob bereits Änderungen vorgenommen wurden. Im Erstkontakt reichen die notwendigen Eckdaten; sensible Belege werden nicht ungefragt per Formular übertragen.
Scope und sichere Arbeitsweise festlegen
Wir klären Zugriffsrechte, Ansprechpartner, Systeme, Zeitraum, erlaubte Maßnahmen und die Form der Dokumentation. Aktive Eingriffe erfolgen erst nach ausdrücklicher Abstimmung.
Belege sichern und prüfen
Je nach Fall werden vorhandene Artefakte gesichert, technische Zusammenhänge rekonstruiert und Befunde gegengeprüft. Der geprüfte Umfang wird als Nenner dokumentiert.
Maßnahmen priorisieren
Akute Eindämmung, Wiederherstellung und langfristige Härtung werden getrennt bewertet. Jede Empfehlung erhält einen nachvollziehbaren Grund und eine Priorität.
Ergebnisse übergeben
Sie erhalten eine verständliche Zusammenfassung, technische Details, offene Punkte und einen umsetzbaren Maßnahmenplan. Wo eine Aussage nicht möglich ist, steht das ausdrücklich dabei.
Arbeitsweise
Vertrauen ohne Show-Siegel
Belege statt Bauchgefühl
Eine Aussage wird auf ihren Suchraum, ihre Quelle und ihren Zeitbezug zurückgeführt. Ein Nullbefund wird nicht mit „existiert nicht“ verwechselt.
Fakten bleiben von Hypothesen getrennt
Auch naheliegende Erklärungen werden nicht als Tatsachen verkauft. Das schützt Entscheidungen und vermeidet vorschnelle Schuldzuweisungen.
Passive Prüfung zuerst
Wo möglich, beginnen wir lesend und nicht-invasiv. Veränderungen an Systemen benötigen einen klaren Scope und eine ausdrückliche Freigabe.
Datensparsame Kommunikation
Im Erstkontakt werden nur die Informationen abgefragt, die für die Einordnung notwendig sind. Passwörter, private Schlüssel und vollständige Datenbestände gehören nicht in ein Kontaktformular.
Übergabefähige Dokumentation
Die Ergebnisse werden so strukturiert, dass interne Technik, Hosting, Datenschutz, Rechtsberatung oder weitere Spezialisten gezielt anschließen können.
Was ein technischer Bericht enthalten kann
- Kurzfassung für Entscheider
- Scope, Zeitraum und untersuchte Systeme
- Timeline relevanter Beobachtungen
- Befunde mit Quelle und Evidenzklasse
- technische Abhängigkeiten und mögliche Wirkungsketten
- offene Fragen und Grenzen der Analyse
- priorisierte Sofort-, Folge- und Präventionsmaßnahmen
Der konkrete Inhalt richtet sich nach Auftrag, Datenlage und erteilter Freigabe. Ein Bericht ersetzt keine Rechtsberatung und verspricht keine gerichtsfeste Täterzuordnung.
Wofür wir nicht der richtige Partner sind
- Sie erwarten eine namentliche Täterzuordnung als zugesagtes Ergebnis.
- Sie brauchen eine rechtliche Bewertung, eine Meldeentscheidung oder ein Gutachten für ein laufendes Verfahren.
- Sie erwarten aktive Tests gegen ein Produktivsystem ohne abgestimmten Scope und ohne Freigabe.
- Sie suchen ein Siegel oder eine Zertifizierung statt einer Prüfung mit benanntem Umfang.
- Sie erwarten eine Garantie, dass danach nichts mehr passieren kann.
Häufige Fragen
Fragen, die vor dem Erstkontakt aufkommen
Nein. „Etwas stimmt nicht“ ist ein ausreichender Ausgangspunkt. Zuerst wird geprüft, welche Beobachtungen belastbar sind und welche harmlosen oder technischen Erklärungen ebenfalls infrage kommen.
Zum Beispiel ein unerwarteter Ausfall, unbekannte Administratorkonten, manipulierte Inhalte, schädliche Weiterleitungen oder konkrete Hinweise auf unbefugten Zugriff. Ob tatsächlich ein Angriff vorliegt, wird erst nach der Einordnung behauptet.
Eine kurze Beschreibung der Beobachtung, den ungefähren Zeitpunkt, die betroffene Systemart und einen erreichbaren Ansprechpartner. Zugangsdaten und sensible Dateien werden im Kontaktformular nicht benötigt.
Nein. Erst werden Scope, Berechtigung und Ziel abgestimmt. Aktive Änderungen erfolgen nur nach ausdrücklicher Freigabe und mit Blick darauf, relevante Spuren nicht unnötig zu verändern.
Manchmal lassen sich technische Ursprünge oder Wirkungsketten eingrenzen. Eine sichere Zuordnung zu einer Person oder Organisation ist jedoch häufig nicht möglich und wird nicht versprochen.
Nein. Absolute Sicherheit und Erfolgsgarantien wären unseriös. Ziel ist, belegbare Risiken zu reduzieren, Entscheidungen zu verbessern und Wiederholungen weniger wahrscheinlich zu machen.
Ja. Server-Hardening, Security-Analysen, Incident Readiness, Response-Runbooks und Kryptografie-Beratung setzen vor einem Vorfall an.
Wir nutzen die OWASP Top 10, den ASVS und den Web Security Testing Guide als öffentlich dokumentierten Prüfrahmen und als gemeinsame Sprache für Befunde. Das ist eine Arbeitsgrundlage, keine Zertifizierung und kein Konformitätsnachweis.
Nicht automatisch. Ein Großteil der Arbeit beginnt lesend und nicht-invasiv. Aktive Tests gegen ein laufendes System benötigen einen abgestimmten Scope, eine ausdrückliche Freigabe der berechtigten Stelle und ein vereinbartes Zeitfenster. Ohne diese Grundlage wird nicht aktiv getestet.
Nein. Eine einzelne Zahl verdeckt, was geprüft wurde und was nicht. Sie erhalten stattdessen den geprüften Umfang als Nenner, die Befunde mit Evidenzklasse und eine begründete Priorisierung.
Nein. Wir liefern technische Befunde und unterstützen die technische Aufarbeitung. Rechtliche Bewertung, Meldepflichten und individuelle Rechtsfragen gehören zu entsprechend qualifizierten Stellen; die technische Dokumentation kann deren Arbeit unterstützen.
Das hängt von Systemumfang, Datenlage, Zugängen und Fragestellung ab. Nach der ersten Einordnung lässt sich festlegen, welcher Prüfbereich sinnvoll ist und welche Schritte voneinander abhängen.
Je nach Auftrag eine strukturierte Befundübersicht, eine Timeline, offene Punkte und priorisierte Maßnahmen. Umfang und Format werden im Scope festgelegt.
Sie müssen noch nicht wissen, wie der Vorfall heißt.
Beschreiben Sie kurz, was Sie beobachtet haben. Wir helfen Ihnen dabei, den richtigen Einstieg zu finden – akuter Vorfall, Verdachtsprüfung oder Prävention.
Bei Fragen gerne anschreibenBitte senden Sie über das Kontaktformular keine Passwörter, privaten Schlüssel, Backups oder vollständigen Logdateien. Falls sensible Unterlagen erforderlich sind, stimmen wir dafür einen geeigneten Übertragungsweg ab.