Die binsec GmbH sucht aktuell Verstärkung im Bereich Penetration Testing (als Teilzeit) – und geht dabei einen Weg, der in der Branche eher selten ist:
Ein echtes 3-Wochen-on und 1-Woche-off-Arbeitsmodell.
Das bedeutet:
Du arbeitest drei Wochen ganz normal an Kundenprojekten – und bekommst anschließend eine komplette Woche frei, zusätzlich zu deinem regulären Urlaub. Keine Bereitschaft, keine Meetings, kein „nur mal kurz“: eine echte Off-Week.
Warum machen wir das?
Pentesting ist kognitiv fordernd. Gute Arbeit entsteht nur, wenn man regelmäßig Raum bekommt, runterzufahren. Wir wollen ein Umfeld, in dem man langfristig leistungsfähig bleibt und gleichzeitig ein Leben außerhalb der Arbeit führen kann. Für uns gehört das zu professioneller Arbeitskultur.
Wir suchen erfahrene Penetration Tester (m/w/d) die Lust haben auf:
Alle paar Monate werde ich dieselbe Frage gestellt: „Was findet ihr eigentlich typischerweise in einem Web-Pentest?“
Statt anekdotisch zu antworten, habe ich die aggregierten Daten der letzten 12 Monate aus unseren Webanwendungstests (inklusive angebundener APIs) bei der binsec GmbH ausgewertet. Das Ergebnis ist die untenstehende Grafik – und sie bestätigt die Muster, die sich seit Jahren wiederholen.
Konfigurationsfehler: Das ewige Low-Hanging-Fruit
Ein großer Teil der Findings entsteht durch einfache Konfigurationsfehler: unsichere Webserver-Defaults, fehlende Security-Header, veraltete TLS-Versionen oder schwache Cipher-Suites. Diese Schwachstellen sind leicht auffindbar und meist nicht kritisch, zeigen aber ein wiederkehrendes Problem: vielen Deployments fehlt eine grundlegende Sicherheitsbaseline. Eine einfache Checkliste würde die meisten dieser Probleme direkt vermeiden.
Session-Management: Alte Probleme in modernen Anwendungen
Fehler im Session-Handling treten überraschend häufig auf. Ein typisches Beispiel ist, dass beim Logout nur die Session im Browser entfernt wird, die serverseitige Session jedoch aktiv bleibt. Wird ein Session-Token kompromittiert, kann ein Angreifer die Session weiter nutzen – auch wenn der Nutzer sich bereits abgemeldet hat.
Wo die kritischen Schwachstellen liegen: Autorisierung
Die meisten kritischen Findings entstehen im Bereich der Autorisierung, insbesondere bei:
fehlender Objekt- und Ressourcenfreigabe,
unzureichender Rollenprüfung,
Privilege Escalation,
mangelnder Tenant-Isolation in SaaS-Systemen.
Moderne, frontend-lastige Anwendungen verstärken dieses Problem. Der Browser ruft im Hintergrund zahlreiche API-Endpunkte auf, und jeder einzelne Endpunkt benötigt eine explizite Zugriffskontrolle. Frameworks übernehmen diese Aufgabe selten automatisch. Die Implementierung erfolgt manuell. Manuelle Prozesse führen dabei zwangsläufig zu Inkonsistenzen.
Die Klassiker, die nicht aussterben
SQL Injection und Cross-Site Scripting (XSS) treten heute seltener auf, sind aber keineswegs verschwunden. ORMs, Prepared Statements und automatisches Escaping entschärfen viele Risiken, doch sobald jemand sie in der Entwicklung „nur kurz umgeht“, tauchen diese Klassiker wieder auf.
Business Logic: Selten, aber mit hoher Wirkung
Business-Logic-Schwachstellen sind weniger häufig, haben jedoch meist erhebliche Auswirkungen, wenn sie auftreten. Beispiele sind das Umgehen von Freigabeprozessen, das Manipulieren von Berechnungen oder das Überspringen notwendiger Validierungsschritte. Diese Schwachstellen erscheinen in keinem Scanner und erfordern ein tiefes Verständnis der Geschäftsprozesse.
Fazit
Die Daten bestätigen, was viele Sicherheitsteams längst wissen:
Die meisten Schwachstellen sind vermeidbar durch klare Konfigurationsrichtlinien und saubere Deployments.
Kritische Findings konzentrieren sich fast immer auf Autorisierungsfehler, nicht auf exotische Angriffstechniken.
TISAX (Trusted Information Security Assessment Exchange) ist der branchenspezifische Sicherheitsstandard der Automobilindustrie – entwickelt vom VDA und betrieben durch die ENX Association. Er stellt sicher, dass Unternehmen nachweislich ein hohes Niveau an Informationssicherheit erfüllen und dieses vertrauenswürdig mit Partnern teilen können.
Im Rahmen von TISAX ist die regelmäßige Durchführung von Penetrationstests ein zentraler Bestandteil des technischen Sicherheitsnachweises. Sie dienen dazu, die Wirksamkeit der implementierten Schutzmaßnahmen praktisch zu überprüfen und Sicherheitslücken frühzeitig zu erkennen. So wird sichergestellt, dass Unternehmen nicht nur Richtlinien erfüllen, sondern ihre Systeme tatsächlich gegen reale Angriffe abgesichert sind.
Im Katalog Information Security Assessment 6.0.2 (ISA6 DE 6.0.2) des VDA werden an zwei Stellen die Durchführung von Penetrationstest gefordert. Das erste mal im Punkt 5.2.6Inwieweit werden IT-Systeme und -Dienste technisch überprüft (System- und Dienst-Audit)?
Grundsätzlich gilt: Es sind System- und Dienstaudits verbindlich durchzuführen, im Voraus zu planen und mit allen Beteiligten abzustimmen. Ihre Ergebnisse müssen nachvollziehbar dokumentiert, dem Management berichtet und für die Ableitung geeigneter Maßnahmen genutzt werden. Zusätzlich sollten System- und Dienstaudits regelmäßig und risikobewusst geplant sowie von qualifiziertem Fachpersonal mit geeigneten Werkzeugen durchgeführt werden – sowohl aus dem internen Netzwerk als auch vom Internet aus. Nach Abschluss ist zeitnah ein Auditbericht zu erstellen. Auch wenn ein Penetrationstest hilft, diese Anforderungen umzusetzen, kommt die konkrete Forderung danach erst bei den Zusatzanforderungen bei hohem Schutzbedarf:
Für kritische IT-Systeme oder -Dienste wurden zusätzliche Anforderungen an das System- oder Dienst-Audit identifiziert, die erfüllt werden (z. B. dienstspezifische Tests und Werkzeuge und/oder Penetrationstests, risikobasierte Zeitintervalle)
Die nächste Erwähnung findet im Punkt 5.3.1 Inwieweit wird Informationssicherheit bei neuen oder weiterentwickelten IT-Systemen berücksichtigt? statt.
Grundsätzlich gilt: Bei Planung, Entwicklung, Beschaffung und Änderung von IT-Systemen müssen die Anforderungen an die Informationssicherheit stets ermittelt, berücksichtigt und in Sicherheits-Abnahmetests überprüft werden. Lastenhefte sollten Sicherheitsvorgaben, bewährte Verfahren und Ausfallsicherheit enthalten und vor dem produktiven Einsatz geprüft werden. Der Einsatz produktiver Daten zu Testzwecken ist zu vermeiden oder durch gleichwertige Schutzmaßnahmen abzusichern. Bei den Zusatzanforderungen bei sehr hohem Schutzbedarf wird dann wieder auf einen Penetrationstest referenziert:
Die Sicherheit von für einen bestimmten Zweck speziell entwickelter Software oder von in erheblichem Umfang maßgeschneiderter Software wird geprüft (z. B. Penetrationstests), während der Inbetriebnahme, im Falle wesentlicher Änderungen und in regelmäßigen Abständen.
Die Anforderungen an einen Penetrationstest sind zur Erfüllung von 5.2.6 vergleichsweise unspezifisch. Wird keine eigene Softwareentwicklung betrieben – weder intern noch im Auftrag – beschränkt sich der Test in der Regel auf einen externen Penetrationstest zur Überprüfung öffentlich erreichbarer Dienste (z. B. der Website) sowie auf die Analyse des internen Netzwerks. Bei klassischen IT-Landschaften liegt der Fokus dabei meist auf dem Active Directory, der Firewall und den intern erreichbaren Systemen.
Die Durchführung erweiteter Pentests wie z.B. inklusive Social Engineering, Phishing, physische Sicherheitsüberprüfungen oder DDoS-Tests sind im überschaubaren Normalfall in der Regel nicht erforderlich.
Die Idee zu PTDoc entstand während des Wachstums des binsec-Teams: Wie lässt sich die Qualität konstant hochhalten, obwohl einzelne Penetrationstester unterschiedliche persönliche Schwerpunkte setzen? Und wie stellt man sicher, dass das Ergebnis eines Pentests immer identisch bleibt – unabhängig davon, welcher Senior Penetration Tester den Auftrag durchführt?
Vor PTDoc stand binsec vor der typischen Herausforderung: Soll man Berichte in Word schreiben oder mit LaTeX erstellen? Anfangs fiel die Entscheidung auf LaTeX, wodurch zwar technisch saubere, aber optisch eher „typische“ LaTeX-Dokumente entstanden. Mit PTDoc hat sich dies grundlegend geändert – heute werden daraus professionell gestaltete Reports, die im Hintergrund weiterhin auf umfangreichem LaTeX-Code basieren, jedoch über eine komfortable Oberfläche gesteuert werden können.
Kernidee des Tools ist es, für unterschiedliche Zielsysteme – etwa Active Directory, mobile Anwendungen (z. B. Android Apps) oder Netzwerke – eine einheitliche und standardisierte Vorgehensweise bereitzustellen. Das binsec-Team pflegt und erweitert die Methodik kontinuierlich und integriert etablierte Standards wie den OWASP Testing Guide, MASVS oder OSSTMM. Auf diese Weise wird eine gleichbleibend hohe Qualität sowie die exakte Wiederholbarkeit von Penetrationstests sichergestellt.
In den letzten Jahren hat sich gezeigt, dass durch diese strukturierte Vorgehensweise regelmäßig Schwachstellen identifiziert werden, die bei vorherigen Tests übersehen wurden. Ein Kunde formulierte es sogar so, dass er alle früheren Prüfungen anderer Anbieter nicht mehr als „richtige“ Penetrationstests bezeichnet.
PTDoc deckt alle drei Phasen der Pentest-Dokumentation ab:
Durchführung des Tests – das strukturierte Abarbeiten der definierten Vorgehensweise.
Erstellung der Findings – inklusive Beschreibung für den Management-Teil, detaillierter technischer Analyse, Risikobewertung (qualitativ per Ampelsystem oder quantitativ per CVSS) sowie Verwaltung von Screenshots und Evidences.
Berichtsgenerierung – automatische Erstellung eines konsistenten, revisionssicheren Berichts.
Auch das Nachtesten ist integriert: Stellt der Pentester fest, dass ein Kunde eine Schwachstelle behoben hat, dokumentiert er den Proof of Fix direkt im Finding. Beim erneuten Berichtsbau wird das Finding automatisch als behoben markiert und auch die Management-Zusammenfassung entsprechend aktualisiert.
Darüber hinaus unterstützt PTDoc die Erstellung von deutschen und englischen Berichten. Damit ist es für Kunden besonders einfach, Reports auf Wunsch auch in beiden Sprachen zu erhalten.
Fazit: Mit PTDoc können sich Pentester vollständig auf ihre eigentliche Arbeit – die Durchführung des Tests – konzentrieren. Gleichzeitig ist das Erstellen der Berichte einfach und schnell geworden, sodass Kunden ihre Ergebnisse zeitnah nach Abschluss des Pentests erhalten.
Die neue NIS2-Richtlinie der EU ist seit Anfang 2023 in Kraft. Sie betrifft nicht mehr nur klassische KRITIS-Betreiber, sondern auch eine breite Palette „wichtiger Einrichtungen“, darunter:
mittelgroße und große Unternehmen in Energie, Transport, Finanzwesen, Gesundheitswesen,
Hosting-Provider, Rechenzentren, DNS-Dienste,
(fast) jedes Tech-Unternehmen, das „wesentliche Dienste“ erbringt.
Die NIS2 schreibt Penetrationstests nicht explizit vor, verlangt aber Maßnahmen, deren Umsetzung ohne Penetrationstests kaum sinnvoll und prüfbar ist. Artikel 21 der Richtlinie definiert eine zentrale Pflicht:
Die Mitgliedstaaten stellen sicher, dass wesentliche und wichtige Einrichtungen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen ergreifen, um die Risiken für die Sicherheit der Netz- und Informationssysteme, die diese Einrichtungen für ihren Betrieb oder für die Erbringung ihrer Dienste nutzen, zu beherrschen und die Auswirkungen von Sicherheitsvorfällen auf die Empfänger ihrer Dienste und auf andere Dienste zu verhindern oder möglichst gering zu halten.
Die Richtlinie nennt Penetrationstests nicht namentlich, aber sie impliziert sie mehrfach, nämlich durch die regelmäßige Prüfungen der Wirksamkeit der Maßnahmen und nach dem Stand der Technik ist das eben die Durchführung eines Penetrationstests.
Was genau an personenbezogenen Daten bei einem Penetrationstest verarbeitet wird, hängt stark vom Testgegenstand ab. Grundsätzlich kann man aber die folgenden Kategorien unterscheiden.
1. Ansprechpartner beim Kunden
Ohne geht’s nicht: Der Pentester braucht Ansprechpersonen. Typischerweise werden hier Name, Position, dienstliche Mailadresse und Telefonnummer verarbeitet – in Mails, im Kalender, im Bericht. Diese Informationen sind meist ohnehin öffentlich (z. B. im Impressum oder auf LinkedIn) und dienen nur der Kommunikation. Sie werden immer verarbeitet, sind aber unkritisch.
2. Weitere Mitarbeitende des Unternehmens
Sobald das Zielsystem ein internes Netzwerk ist – vor allem mit Active Directory –, kommt man an weiteren personenbezogenen Daten kaum vorbei. Namen, Benutzernamen, oft auch Passwort-Hashes oder sogar Klartextpasswörter landen temporär auf dem Pentest-System. Das ist kein Zufall, sondern Teil der Aufgabe: Rechteausweitung, horizontale Bewegungen, Domäne-Übernahmen.
Was dabei wichtig ist: Es besteht keinerlei Grund, personenbezogene Daten dauerhaft zu speichern oder auf weitere Systeme des Dienstleisters zu übertragen. Alles, was lokal verarbeitet wird, bleibt lokal. Nur der Bericht enthält Auszüge – und auch da gilt: So wenig wie nötig. Identitäten lassen sich anonym oder pseudonymisiert darstellen.
3. Kundendaten des Auftraggebers
Wenn produktive Systeme getestet werden – zum Beispiel ein Onlineshop – kann es passieren, dass echte Kundendaten kurz sichtbar werden. Ziel ist es nicht, diese Daten zu speichern, sondern Schwachstellen zu identifizieren: Kann man z. B. fremde Bestellungen einsehen? Wenn ja, werden einzelne Datensätze für den Moment verarbeitet. Das lässt sich nicht vermeiden, ist aber so minimalinvasiv wie möglich.
Empfehlung: AV-Vertrag bei produktiven Daten
Sobald interne Systeme oder produktive Umgebungen getestet werden, sollte ein Vertrag zur Auftragsverarbeitung abgeschlossen werden. Entscheidend ist: Datenminimierung. Der Pentest soll nicht Daten sammeln, sondern Schwachstellen aufzeigen. Und das geht auch, ohne ganze Datenbanken zu kopieren.
Subdomains verraten oft, welche internen Systeme, Webseiten oder Plattformen ein Unternehmen betreibt. Das Auffinden von Subdomains ist ein wichtiger Bestandteil von Sicherheitsanalysen, Penetrationstests oder allgemeinen Recherchen, weil dadurch mögliche Angriffspunkte entdeckt werden können, die sonst verborgen bleiben.
Er greift auf die CertWatch-Datenbank von binsec.tools zurück – eine Sammlung öffentlicher SSL/TLS-Zertifikate, in denen oft Subdomains auftauchen.
Zusätzlich werden DNS-Abfragen durchgeführt, bei denen ein vordefiniertes Subdomain-Wörterbuch verwendet wird, um häufig genutzte Subdomains systematisch zu testen.
Darüber hinaus werden gezielte Suchanfragen an google.com gestellt, um weitere Subdomains zu finden, die in öffentlichen Suchergebnissen auftauchen und sonst vielleicht übersehen würden.
Auf binsec.tools ist nun auch ein Tool online, dass die eigene öffentliche IPv4- und IPv6-Adresse anzeigt. Technisch keine neue Meisterleistung, aber ohne Werbung und ohne Tracking: Wie ist meine IP-Adresse?
Am 11. Februar 2025 erhielt die binsec GmbH eine „Ausschreibung der Emirates Group“ von vendor.registration@theemirategroup.com:
Dear Valued Vendor, Greetings from Emirates Group, We invite you to register as a vendor with Emirates Group. A leading aviation company in UAE. Our goal is to build a diverse and qualified vendor base to support our business needs. This will open up opportunities to provide goods and services to our projects and developments. Our projects are open for all companies. And this is a special consideration towards your participation for the ongoing registration To register, Kindly confirm your interest by requesting for Vendor Questionnaire and EOI. We look forward to potentially working with you! Best Regards Mr. Sameh Bakier Vendor Coordinator Group Procurement & Contract Shared Services Center of The Emirates Group
Wenn man auf diese E-Mail antwortet und dabei behauptet, interessiert zu sein, erhält man eine E-Mail mit drei PDF-Dokumenten, darunter beispielsweise die Emirates Vendor Assessment Policy. Tatsächlich sehen diese Dokumente gut und authentisch aus. Die Mail enthält auch eine „Vendor Regisgtration Acceptance Form“:
Sie verlangen also eine Zahlung von AED 57.850 (entspricht 15.000 €), um den Prozess zu starten. Die Domain, von der die E-Mails gesendet werden, ist theemirategroup.com, die Original-Domain von The Emirates Group ist theemiratesgroup.com. In der Domain fehlt ein „s“…
Du suchst nach einem kostenlosen Online-Tool, um die SSL/TLS-Konfiguration auf einem bestimmten benutzerdefinierten Port zu prüfen, der nicht 443 ist? Dann probiere SSLCheck von binsec.tools aus – da kannst du den zu testenden Port angeben, z. B. 8443. Der SSLScan von binsec.tool gibt einen Überblick über die Protokolle und Chiffren der TLS-Konfiguration und prüft das Sicherheitsniveau. Es unterstützt sogar das Testen von StartTLS für SMTP, IMAP und LDAP.
