なんとWindows Updateを偽装する防御方法の無い攻撃手法が出現／唯一の防御方法はWindowsPCを使わない事だ

【投稿者コメント】

【キーワード】

[Window更新悪用]､[検知不可]､[WinPCは使えない]

【件名】

｢【重要告知】ついに､Windows Updateを悪用する､防御方法の無い攻撃手法が出現！／Windows Updateに偽装する､完全に検出不能なPowerShellバックドアを発見／Microsoftが､Windows8.1で､破壊したWindowsOSがついに､終わりを迎えるのか？／唯一の防御方法は､WindowsPCを使わないことだ！｣

【投稿本文】

果ての無い､深刻なバグ･デグレートが頻発する､MicrosoftのWindows Updateの事を､ジョークで､｢Windows Updateは､最大､最強､最凶､最恐のマルウェアだ！｣と云っていたが､なんと､ついに､そのジョークが事実となる事象･事件が出現した！

以下の【以下転載１】と【以下転載２】では､

『Windowsの更新プロセスの一部として自身を偽装するという新しいアプローチを悪用した｢完全に検出不能｣なPowerShellバックドアが出現した｡

このマルウェアの攻撃チェーンは､悪意のあるPowerShellスクリプトを起動させるマクロコードが含まれたMicrosoft Word文書から始まっており､Word文書は｢Apply Form.docm｣と云うファイル名となっており､2022年8月25日にヨルダンからアップロードされた｡

PowerShellスクリプトは2つあって､最初のPowerShellスクリプト(Script1.ps1)はリモートのコマンド＆コントロールサーバに接続して､2番目のPowerShellスクリプト(temp.ps1)を使用して､侵入先のPCで起動するコマンドを取得するように設計されている』

と報告している｡

ウィルス･悪性アプリ･マルウェア等に悪用される､WindowsOSの脆弱性･欠陥を改修･修復するための､Windows Updateを攻撃に悪用して､しかも､Windows Updateの更新プロセスに成りすますのが､検知･防御不可能と云うから､一旦､標的にされたら､やられ放題になってしまう！

『唯一の防御方法は､WindowsPCを使わないことだ！』

【追　記】(2022年10月22日)

上記の指摘をことさらに､Microsoftを標的にした､いわれなき攻撃だと云う､Microsoftの提灯持ち･太鼓持ち･幇間に云いたい｡

どんなに､割り引いても､事情を勘案しても､情状酌量しても､

Microsoftは､コンプライアンスや製造責任や顧客重視を尊重･実行する企業とは､云い難い､企業行動ばかりが目に付く｡

下記の【以下転載３】のMicrosoftのクラウドサービスのAzure Cloudでの､運用ミスに依る､大規模な顧客情報漏洩事件に於いても､

漏洩の事実をMicrosoftへ通報してくれたセキュリティベンダーへ､恩を仇で返す様な､悪態を突いて､クレーム･非難を返し､事件について問い合わせた顧客ユーザへは､情報提供を拒否すると門前払いにして､事件を隠蔽しているなどと､まともな企業にはあるまじき､異常な行動･反応を見せており､腐れ切ったのは､製品のWindowsOSだけでなく､組織･企業体としての､Microsoftも既に､詰(つ)んでいる！

最高経営責任者の日本Microsoft_CEOが､日本医師会や日本政府を深刻バグ放置で激怒させて､左遷させられたら､懲りて､少しは､その｢隠蔽体質｣や｢無責任体質｣や｢顧客無視の姿勢｣や｢企業エゴ優先の姿勢｣や｢品質無視の利益優先姿勢｣は､改まって当然なのに､ますます､ひどくなるばかりだから､救いようが無い！

【以下転載１】

https://news.mynavi.jp/techplus/article/20221021-2485873/
｢Windowsアップデートに偽装､完全に検出不能なPowerShellバックドアを発見｣
　　　　　　　　　　マイナビニュースTECH+ 著者：後藤大地 2022/10/21 13:29

SafeBreachは10月18日(米国時間)､｢SafeBreach Uncovers Fully Undetectable PowerShell Backdoor｜SafeBreach｣において､これまで文書化されていなかった新たなPowerShellのバックドアを発見したと伝えた｡

これは巧妙かつ未知の脅威者によって作成され､Windowsの更新プロセスの一部として自身を偽装するというユニークな手法を使用していることが調査によって判明している｡

添付図１_SafeBreachが､完全に検出不可能なPowerShellバックドアを発見｜SafeBreach

Windowsの更新プロセスの一部として自身を偽装するという新しいアプローチを利用した｢完全に検出不能(FUD: Fully UnDetectable)｣なPowerShellバックドアが､SafeBreachのセキュリティ専門家チームの調査によって発見された｡このPowerShellバックドアおよび関連するコマンド＆コントロール(C2:Command and Control)ツールは､約100名の被害者をターゲットにした未知の脅威者によるものであると分析されている｡

このマルウェアの攻撃チェーンは､悪意のあるPowerShellスクリプトを起動させるマクロコードが含まれたMicrosoft Word文書から始まっている｡Word文書は｢Apply Form.docm｣というファイル名となっており､2022年8月25日にヨルダンからアップロードされている｡

添付図２_応募フォームの内容.docm｜SafeBreach

PowerShellスクリプトは2つあり､最初のPowerShellスクリプト(Script1.ps1)はリモートのコマンド＆コントロールサーバに接続し､2番目のPowerShellスクリプト(temp.ps1)を使用して､侵入先のマシンで起動するコマンドを取得するよう設計されている｡

この新たな脅威について認識を高めてもらうため､SafeBreachはこのマルウェアに関する情報およびセキュリティ侵害インジケータ(IoC:Indicator of Compromise)を公開している｡また､この脅威に対して組織やユーザが公開された情報を利用して適切に検知し､保護できることが望まれている｡

【以下転載２】

https://www.safebreach.com/resources/blog/safebreach-labs-researchers-uncover-new-fully-undetectable-powershell-backdoor/
｢SafeBreach Labsの研究者が､完全に検出不可能な新しいPowerShellバックドアを発見｣

SafeBreach､セキュリティ･リサーチ･ディレクター Tomer Bar　2022年10月18日

このツールは､洗練された一見未知の攻撃者によって作成され､Windows更新プロセスの一部として自身を偽装する独自のアプローチを使用しています｡

著者：Tomer Bar､SafeBreach､セキュリティリサーチディレクター

新しい脅威を発見し､Hacker's Playbookが最も包括的な攻撃のコレクションを提供するようにするための独自の調査を実施するという継続的な取り組みの一環として､SafeBreach Labsの調査チームは最近､偽装の新しいアプローチを利用する新しい完全に検出不可能な(FUD)PowerShellバックドアを発見しました｡Windows更新プロセスの一部としてそれ自体｡秘密裏に開発されたツールと関連するC2コマンドは､約100人の被害者を標的にした､洗練された未知の攻撃者の仕業のようです｡

この調査レポートでは､このFUD PowerShellバックドアの概要と､最初に出現した時期とその機能について説明します｡また､各被害者の暗号化されたC2コマンドにアクセスして解読するために論理的に悪用できたツールの責任者である脅威アクターによって犯された運用セキュリティの誤りについての洞察も提供します｡コマンドの1つは､Active Directoryユーザの列挙とリモートデスクトップの列挙のための完全なPowerShellコードの実行です｡これは､後のラテラルムーブメントフェーズで使用される可能性があります｡最後に､SafeBreachがこの情報をセキュリティコミュニティとどのように共有しているかについて詳しく説明します｡

■初期アクセス

攻撃は､未知のPowerShellスクリプトを起動するマクロコードを含む悪意のあるWordドキュメントから始まります｡Word文書の名前は｢申請書.docm｣です｡悪意のあるWordドキュメントは､2022年8月25日にヨルダンからアップロードされました｡

図1：VirusTotalへの悪意のあるドキュメントのアップロード

図2：Apply Form.docmの内容

ファイルのメタデータは､このキャンペーンがLinkedInベースの求人応募のスピアフィッシングルアーと疑われるものに関連していたことを示しています｡

図3：Apply Form.docmのドキュメントプロパティ

マクロはupdater.vbsを投下し､Windowsアップデートの一部を装ったスケジュールされたタスクを作成します｡このタスクは､｢%appdata%\local\Microsoft\Windows｣へ作成｡

図4：新しいスケジュールタスクの登録

図5：スケジュールされたタスクのxmlファイル

updater.vbsスクリプトは､PowerShellスクリプトを実行します｡

図6：PowerShellスクリプト

スケジュールされたタスクを実行する前に､Script.ps1とTemp.ps1という名前の2つのPowerShellスクリプトが作成されます｡PowerShellスクリプトの内容は､Word文書内のテキストボックスに保存され､%AppData%\Local\Microsoft\Windows\Updateと云う同じ偽の更新ディレクトリに保存されます｡

図7：2つのPowerShellスクリプトの作成

どちらのスクリプトも難読化されており､VirusTotalでの検出が0のFUDです｡

図8：各スクリプトのVirusTotalリスト

Script1.ps1はC2サーバーに接続し､HTTP GET要求をhxxp://45.89.125.189/getに送信して実行するコマンドを取得します｡これにより､被害者の一意のIDが返されます｡最初にテストしたとき､ID番号は70 でした｡これは､テスト前におそらく69人の被害者がいたことを意味します｡スクリプトは2番目のHTTP POSTリクエストを同じURLに送信し､C2サーバーは､次の暗号化キーを使用してAES-256 CBCによって暗号化された実行コマンドで応答します｡

｢17 1d 84 e8 41 ae e4 c0 ff fb a2 7c 86 d1 ec 82 b8 80 7c b8 c3 79 9a 11 b8 fa 2d b7 78 1f d1 5a｣

そして､次のIV値：

｢18 3c ed 6f b3 34 9f 9a c6 f9 8 f9 29 de 35 52｣

POSTリクエストに対するC2サーバーの応答は､CyberChefを使用して復号化されます｡

図9：POST要求に対するC2応答コンテンツのCyberChef AES復号化

コマンド､(添付図9-1_コマンド構成)

0!@#EWQ796¦+.x7.powershell -command Get-Process^%$RTY:

ここに赤色("0")で示されているタイプ番号で始まります｡可能な値は0､1､または2の3つですが､これについては後で説明します｡この場合のタイプ0の値は､PowerShellコマンドを実行することが期待されていることを示します｡青色("!@#EWQ")のセクションはセパレータ､緑色("powershell -command Get-Process")のセクションは実行するコマンド式､茶色("^%$RTY")のセクションはコマンド間のセパレータ､最後の紫色の｢:｣は実行するコマンドが他にないことを意味します｡

スクリプトはコマンドを解析し､cという名前のパラメーターを使用して各コマンドに対してTemp.ps1スクリプトを実行します｡

図10：C2サーバーから受信したコマンドでTemp.ps1を実行するScript1.ps1

コマンドが2で始まる場合､C2 応答から受信したコマンドを､同じくC2によって提供されたファイルパスに保存します｡次に､次の式のパラメーターを使用してTemp.ps1を実行します｡

‘RES!#%’ + $<command converted to base64>

Temp.ps1スクリプトはbase64コマンドをデコードし､コマンドの種類をチェックします ｡

・値が0の場合､invoke-expressionを使用して実行し､同じ暗号化キーを使用してコマンドの出力を暗号化し､HTTP POST要求を使用してhxxp://45.89.125.189/putにアップロードします｡

・値が1の場合､C2レスポンス内で受信したパスから実行するコマンドを読み取り､実行します｡

・値が2の場合､実行するコマンドをパスに書き込み､コマンドを実行します｡

ここで､脅威アクターは､予測可能な被害者のIDを使用することで､運用上の重大なセキュリティ上のミスを犯しました｡私たちは､各被害者になりすましてC2応答(コマンド)をpcapファイルに記録するスクリプトを開発し､開発した2つ目のツールを実行して､pcapから暗号化されたコマンドを抽出しました｡

図11：2022年9月2日にすべての被害者0～101のすべてのC2コマンドを収集するスクリプト

ここでは､被害者49のスクリプトからの出力を確認できます｡CyberChefにコピーすると､復号化されたコマンドが提供されます｡

図12：CyberChefの被害者49の復号化されたコマンド

被害者ごとにコマンドを実行したところ､被害者を待っている各コマンドタイプの次の割合が見つかりました｡

・66%：抽出プロセスリストコマンド

・23%：空のコマンド – アイドル状態(コマンドは｢:｣で始まります)

・7%：ローカルユーザーの列挙 – whoamiおよびwhoami /all +プロセスリスト

・2%：パブリックフォルダーからファイルを削除＋ネットアカウント＋コンピューター名､IP 構成・・・

・1%：特別なフォルダー内のファイルを一覧表示します – プログラムファイル､ダウンロード､デスクトップ､ドキュメント､appdata

・1%：ADユーザー列挙およびRDPクライアント列挙のスクリプト全体(付録Bを参照)

以下に､いくつかのわかりやすい例を示します｡

図13：被害者2 – 2つのコマンド – system32フォルダーのwhoamiとdirlist

図14：被害者X – 複数のコマンド – whoami /all, curl ident.meは被害者の外部IPアドレスを返します

図15：被害者 Y – PowerShellスクリプト全体が実行される

悪意のあるスクリプトは､すべてのユーザーとすべての管理者についてドメインコントローラーに問い合わせます｡

図16：C2サーバーからコマンドとして送信される悪意のあるPowerShellスクリプト

次に､ログイン履歴をチェックします｡

図17：C2サーバーからコマンドとして送信された悪意のあるPowerShellスクリプト (続き)

次に､PowerShellコマンドでターミナルサーバーを列挙します:

Get-ChildItem “Registry::HKCU\Software\Microsoft\Terminal Server Client\Servers”

図18：publicユーザー配下のすべてのファイルを削除し､ネットアカウントを収集する

■結論

SafeBreachは､グローバルレベルでのセキュリティの向上に情熱を傾けており､組織として､私たちの研究をより広範なセキュリティコミュニティとオープンに共有することに取り組んでいます｡このFUD PowerShellバックドアの発見に関する具体的な情報を共有することで､VirusTotal.comにあるすべてのセキュリティベンダーのスキャナーを回避することができた､認識されていないこの新しいタイプのマルウェアについての認識を高めることが､私たちの目標です｡

さらに､この脅威アクターによるこのオペレーションのセキュリティミスの発見は､他の研究者やブルーチームが今後のデジタルフォレンジックおよびインシデントレスポンス(DFIR)の調査に使用される可能性があると考えています｡最後に､組織や個人が､付録Aに記載されている侵害の痕跡(IOC)を使用して､この脅威をより適切に検出し､防御できることを願っています｡

新たに特定された脅威と同様に､SafeBreachはこのFUD PowerShellバックドアのカバレッジをSafeBreachプラットフォーム( https://www.safebreach.com/our-platform/ )に追加したため､お客様はすぐにこの攻撃をシミュレートし､適切に保護されているかどうかを確認し､必要な是正措置を講じることができます｡

■付録 A: IOC

以下は､関連するIOCです｡

C2 サーバー – hxxp://45.89.125.189/put､hxxp://45.89.125.189/get

C2サーバーは2022年9月5日以降アクティブではありません｡

Apply Form.docm( https://www.virustotal.com/gui/search/name%253A%2522Apply%2520Form.docm%2522 ) -45f293b1b5a4aaec48ac943696302bac9c893867f1fc282e85ed8341dd2f0f50 Updater.vbs _

54ed729f7c495c7baa7c9e4e63f8cf496a8d8c89fc10da87f2b83d5151520514
Script.ps1

bda4484bb6325dfccaa464c2007a8f20130f0cf359a7f79e14feeab3faa62332
Temp.ps1

16007ea6ae7ce797451baec2132e30564a29ee0bf8a8f05828ad2289b3690f55

■付録B：PowerShellスクリプト

以下は､コマンドとしてバックドアに送信されたPowerShellスクリプトです｡

0!@#EWQ639¦+.x7.function Convert-LDAPProperty {

param(

    [Parameter(Mandatory=$True,ValueFromPipeline=$True)]

    [ValidateNotNullOrEmpty()]

    $Properties

)

・
　　　　　　　　・
　　　　　　　　・

$search.FindAll() | Where-Object {$_} | ForEach-Object {

# convert/process the LDAP fields for each result

Convert-LDAPProperty -Properties $_.Properties

} | out-string^%$RTY0!@#EWQ643!@#EWQGet-ChildItem “Registry::HKCU\Software\Microsoft\Terminal Server Client\Servers” | Out-String^%$RTY0!@#EWQ675!@#EWQRemove-Item C:\Users\Public*.*

Remove-Item C:\Users\Public\Update_Data

get-childitem C:\users\public\ | out-string^%$RTY

・
　　　　　　　　・
　　　　　　　　・

【以下転載３】

https://gigazine.net/news/20221021-microsoft-data-breach-misconfigured-storage-location/
｢Microsoftの設定ミスで2.4TBもの機密データが公開されていた､111カ国の6万5000もの企業が影響を受けた可能性｣
　　　　　　　　　　　　　　　　　　　　GIGAZINE　2022年10月21日 12時30分

Microsoftのクラウド用オブジェクトストレージサービスであるAzure Blob Storageの構成に設定ミスが存在し、合計2.4TBに及ぶMicrosoftの顧客の機密データが公開状態となっていたことが判明しました。問題を発見したセキュリティ企業のSOCRadarによると、公開されていたデータにはユーザー情報や業務に関するファイルが含まれており、111カ国の6万5000もの企業が影響を受けたとのことです。
　　　　　　　　　　・
　　　　　　　　　　・
　　　　　　　　　　・
　ウェブ上のデータ漏えいを継続的に監視していたSOCRadarは、2022年9月24日にAzure Blob Storageの構成ミスを検出し、誤って公開されたバケットに機密データが含まれていることを発見しました。この問題は「BlueBleed」と名付けられており、公開バケットに含まれる機密データは2.4TBという膨大な量だったとのこと。

機密データはMicrosoftおよび111カ国の6万5000もの企業に関連しており、33万5000件以上の電子メール、13万3000件のプロジェクト、54万8000人のユーザー情報が公開されていたとSOCRadarは述べています。誤って公開された機密データには、他にも製品の注文書・請求書・プロジェクトの詳細・知的財産に関する文書・パートナーへの内部評価といったものが含まれていたそうです。

SOCRadarの発見について、Microsoft Security Response Center(MSRC)も声明を発表し、「2022年9月24日、SOCRadarはMicrosoftに対してエンドポイント構成が間違っていることを通知しました。この設定ミスにより、Microsoftと潜在顧客の間でやりとりされたMicrosoftサービスの計画や実装など、一部のビジネストランザクションデータへの認証されていないアクセスが発生する可能性がありました。構成ミスが通知されるとエンドポイントはすぐに保護され、必要な認証でのみアクセスできるようになりました。私たちの調査では、顧客のアカウントやシステムが侵害された兆候は見つかりませんでした」と報告しました。SOCRadarも、Microsoftは通知から数時間以内にバケットを非公開にするよう再構成し、データ流出のリスクを軽減することに成功したと述べています。

Microsoftによると、今回の問題は意図しない構成ミスによるものであり、システムに脆弱(ぜいじゃく)性が存在するというわけではないとのこと。Microsoftはこの種の構成ミスを防止するプロセスの改善に取り組んでおり、Microsoftの全エンドポイントのセキュリティを調査・保証するために追加のデューディリジェンスを実行しているとのことです。

構成ミスがあったことを認める一方で、公開バケットの電子メールやプロジェクト、ユーザーデータには重複が存在しており、「SOCRadarは問題の範囲を大幅に誇張していました」とMicrosoftは反論しました。また、SOCRadarが今回の構成ミスに関するデータ漏えいをチェックできる「BlueBleed」というツールを公開したことについても、「顧客のプライバシーやセキュリティ確保に最善とは言えず、顧客を不必要なリスクにさらす可能性がある『検索ツール』を公開したことに失望しています」と非難しています。

これに対しSOCRadarは、BlueBleedでは一部データを検索エンジンがクロールしたものの、データはすべてシステムから削除されていると主張。SOCRadarのリサーチ担当ヴァイスプレジデントであるEnsar Şeker氏は、「このクエリページでは、企業は公開バケットでデータが公開されているかどうかを匿名で確認できます」「私たちは漏えいしたデータをまったく保持していません。世界的なサイバー災害を防ごうと協力および支援をしてきたにもかかわらず、MSRCがこのようなコメントおよび非難をしてきたことにとても失望しています」とテクノロジー系メディアのBleepeng Conputerに述べました。

また、Microsoftが影響を受けた顧客に対する通知をMicrosoft365メッセージセンター経由で行ったことや、影響を受けた顧客からの問い合わせに「この問題から影響を受ける特定のデータを提供できません」と回答したことについても、セキュリティ研究者から非難の声が上がっています。