「就職面接」によってハッキングされそうになった

2025年10月15日原文(blog.daviddodda.com)

概要

LinkedIn経由の偽面接 でマルウェア感染寸前の体験談
リアルな企業・人物を装った巧妙な詐欺手口 の詳細
AIによるコードチェック で被害回避
開発者が狙われやすい 新たな攻撃ベクトル の警告
安全対策の重要性 と具体的な防御策の提案

偽ブロックチェーン企業による面接詐欺体験談

LinkedInでMykola Yanchii （SymfaのChief Blockchain Officer）からスカウトメッセージ受信
Symfaは実在企業、プロフィールも本物らしく、1,000人以上のコネクション保持
「BestCity」という不動産向けプラットフォーム開発の パートタイム案件 を提案
8年のフリーランス経験 を持つ筆者でも「本物」と錯覚する巧妙なアプローチ
面談前に「テストプロジェクト」 （React/Nodeのコードベース）を送付される

仕掛け

Bitbucketリポジトリ はプロフェッショナルな外観、READMEやドキュメントも完備
一般的なコーディングテスト に見せかけて、30分間コードを確認・修正
普段は Dockerなどで隔離実行 するが、今回は急いでいて未実施
コードを実行する直前、 AI（Cursor AI agent）に「怪しいコードがないか」チェックを依頼
userController.js内に難読化された不審なスクリプト を発見

マルウェアの正体

byteArrayからデコードしたURL （https://api.npoint.io/2c458612399c3b2031fb9）にアクセスし、外部からコード取得・即時実行
サーバー権限で管理者ルートに埋め込み、実行されれば全データ流出リスク
URLは24時間で消滅、証拠隠滅も徹底
VirusTotalでの解析結果も「危険」、ウォレット・パスワード・ファイル全てが標的

詐欺オペレーションの特徴

LinkedInプロフィールは完璧、実在の肩書・経歴・投稿内容も本物そっくり
企業ページも充実、社員やフォロワーも多数
初期連絡やプロジェクト内容も自然、Calendlyで面談調整
悪意のあるコードはサーバーコントローラに巧妙に埋め込み

心理的トリック

「面接前にテスト提出を」 という緊急性の演出
LinkedIn認証済みアカウント・企業 による信頼感
「よくあるコーディングテスト」 という親近感
実在企業の社会的証明 による安心感
開発者心理を巧みに利用、普段は警戒心が強い人も騙されやすい

学びと警鐘

AIによるコードレビュー が救いの一手
高価なセキュリティツールよりも「怪しいコードをAIで確認」 が有効
開発者は日常的に外部コードを実行 するため、標的として最適
サーバーサイドで実行されるマルウェア は、環境変数・DB・ウォレット・ファイル全てにアクセス可能

攻撃規模とリスク

同様の手口で多数の開発者が標的 になっている可能性
開発者マシンは「王国の鍵」 （本番認証情報・ウォレット・顧客データ）を保有
LinkedIn等による信頼性の偽装・標準的な面接プロセス でカモフラージュ
多層難読化・リモートペイロード・証拠自動消去 など技術的にも高度
一度感染すれば、企業システムや顧客データが一気に危険に晒される

開発者へのアドバイス

未知のコードは必ずサンドボックス実行 （Docker、VM等）
AIでのパターンチェック を習慣化、実行前に30秒で確認
「本物のLinkedInプロフィール」や「企業ページ」も信用しすぎない
急かされて実行を促されたら要注意
「コーディングチャレンジ」送付時は常に警戒心を持つこと

まとめ

開発者向けの新たな標的型攻撃 が急増中
AI活用とサンドボックス運用 が自己防衛の鍵
LinkedInやBitbucket等の信頼性を過信せず、常に疑う姿勢 が重要
「自分は大丈夫」と思わず、すべての開発者が警戒を強める必要性

参考：該当Bitbucketリポジトリ

https://bitbucket.org/0x3bestcity/test_version/src/main/
※アクセス可能期間は不明、証拠隠滅のため早期削除の可能性あり

Hackerたちの意見

AIは彼を救わなかった。彼の直感が救ったんだ。

こういうことにはLittle Snitchに頼るようになったよ。常にアラートモードか拒否モードで動かしてる。ネットに接続しようとするものがこんなに多いなんて、ちょっと驚きだよね。たとえば、vscodeのClineプラグインにはテレメトリをオフにするオプションがあるけど、それでも毎回プロンプトのたびにサーバーに話しかけようとするんだ。ローカルのollamaを使ってるときでもね。

└

同意するよ、こういう状況ではすごく価値があるけど、ダメージを最小限に抑えることしかできないね。Littlesnitch/OpenSnitchのユーザーへ：すべてのアプリに適用される許可ルールは避けた方がいいよ。マルウェアは、Github Gistsのような信頼できるウェブサイトを使って秘密を暴露することもあるからね。どんな場合でも、ファイアウォールが守ってくれても、マシンは侵害されたものとして扱わなきゃいけないよ。

└

… みんながインターネット接続を前提にした自動ビルドシステムについて文句を言う俺を狂ってると思ってるんだよね…。

└

うん、Malwarebytes WFCは本当に安心できる。

怖いのは？この攻撃ベクトルは開発者にとって完璧なんだ。私たちは一日中コードをダウンロードして実行している。GitHubのリポジトリ、npmパッケージ、コーディングチャレンジ。ほとんどの人はすべてをサンドボックスに入れるわけじゃない。この攻撃の話には（願わくば）すべてのプログラマー（OPだけじゃなく）への真剣な教訓が含まれている。ランダムな依存関係やコードを引っ張ってきて、そのまま自分のコードベースに突っ込むことのリスクについて。自分のプロジェクトの依存関係にも微妙なマルウェアが含まれているかどうか、どうやって確認するの？すべて見たことある？更新した後に定期的に監査してる？他にどんなSDKを使ってるか知ってる？彼らがアクセスするエンドポイントの完全なリストを知ってる？最初の深刻なAIコーディングエージェントの毒攻撃まで、どれくらいの時間があるんだろう？誰かがコーディングアシスタントを騙してマルウェアを挿入させる方法を見つけたとき、コードをレビューしないバイブコーダーは全く気づかないだろうね。

└

最初の深刻なAIコーディングエージェントの毒攻撃まで、どれくらいの時間があるんだろう？誰かがコーディングアシスタントを騙してマルウェアを挿入させる方法を見つけたとき、コードをレビューしないバイブコーダーは全く気づかないだろうね。先週にShai-Huludがあったばかりだし、これにはAIはいらないよね。

└

だから、私の視点から見ると、今のテクノロジーはほとんどすべてがめちゃくちゃだよ。ワークステーションのプロジェクト依存関係をアップデートする時、どうするかって？悪意のあるコードが含まれてないことを賭けたり、祈ったりするか、各プロジェクトごとに隔離されたVMを用意するか、もうそのまま全部捨てて、夜もぐっすり眠れるような本当に儲かって持続可能な仕事（配管工とか電気工、大工とか）を作りに行くか、どれかだね。

└

分散型の監査インフラにアテステーションって需要あるかな？ChatGPTにファイル（コンテンツハッシュ）を既知の良いプロンプトで監査させて、その全会話の証拠としてリンクを共有できたら、リスクを減らすのに役立つかな？もし各開発者が自分の依存関係ツリーの一部を監査して、以前のキャッシュされた監査を再利用できるなら、実際にすべてのコードに「目を通す」ことが可能になるかも。もちろん人間の監査には敵わないけど、コスト/効果のパレートフロンティアを改善できるかも（つまり、平均的なウェブ開発者のノーフリクションユースケースをより安全にできる）。

└

俺はリポジトリを見て、どれくらい人気があって、最近のもので、どれだけアクティブなプロジェクトかを感じ取る。そしたらロックして、依存関係は年に一回か、特定の問題に対処する必要があるときだけ更新する。リスクは管理するもので、排除するものじゃない。リスクはプロジェクトのリスク許容度によって変わるから、正しいアプローチは一つじゃないよ。

└

みんな自分は大丈夫だと思ってるんだよね。「悪いことは他の人にしか起こらない」って。

└

ほとんどの人は、すべてをサンドボックスに入れるわけじゃないよね。俺は全部サンドボックスに入れるけど、複雑なんだ。多くのプロジェクトは最新のOSでしかコンパイルできないようになってて、サンドボックス化がさらに難しくなるし、VMでは実際に不可能なんだ。これが赤信号だよ。だからサンドボックスには入れるけど、実行できるところまで行けないから、無能だと思われるかもしれないし、コンピュータや暗号資産がめちゃくちゃになるのを避けられるんだ。

Hacker Newsで議論の続きを見る

ハクソク