SOC アナリスト 小池 倫太郎の記事です。
Operation KiyaによるDridex実行までの挙動
はじめに
前回の記事[1]でOperation Kiyaの概要を紹介しましたが、今回はDridexが実行されるまでの流れ、特にKoadicによる侵害に着目して紹介します。 Operation Kiyaの特徴の1つとして、アンチウイルスソフト等での検知が困難であることが挙げられます。我々が発見した初期検体は3種類ありますが、最初にVirusTotalに投稿されたときの検知率は3つとも0%でした。(図1) その後2つはいくつかのアンチウイルスソフトによって検知されるようになりましたが、1つは本投稿を執筆している時点でも検知率0%です。
図1 VirusTotal検出結果
この高い検知回避力の原因として考えられることは、Excel 4.0 Macroを用いていることが挙げられます。今回発見した3つの初期検体は全てExcel 4.0 Macroによって不正挙動を開始しています。初期検体はxlsbという拡張子が付いたExcelファイルです。これを開くと「コンテンツの有効化」をクリックするような文字列が表示されます。(図2)
図2 Excelファイルを開いた時のキャプチャ
実際には「Macro1」という名前の隠しシートが存在しており、そこにExcel 4.0 Macroが仕込まれています。(図3)
これによって3つの方法でKoadicが実行されると推測されます。我々が攻撃を観測したとき、1行目と2行目のmshta.exeは正常に動作しKoadicが実行されましたが、3行目のregsvr32.exeはC2からの応答がありませんでした。また、2行目の/shopのKoadicは初期コマンド(後述する環境情報を送信する処理)が実行されただけで、その後の動きは観測されませんでした。そのため、以降は1行目の/salesのKoadicの動きを紹介します。 また、KoadicはGitHub上でコードが公開されているOSSです。以下の説明ではGitHub上のコードを参照することがあります。リポジトリはこちら[2]にありますので、適宜ご覧ください。
詳細な挙動
Koadicはサーバ側はPython、クライアント側は主にWSH(JScriptやVBScript)で動作します。KoadicのStagerがC2から取得するHTMLには難読化されたJScriptが含まれています。難読化と言っても非常に簡単なxorで、/core/loader.pyで定義されています。それをStagerがデコードする際の処理は以下のとおりです。(図4)
図4 JavaScriptコード(decode)
一番最初に実行されるのは/data/stager/js/stage.jsとstdlib.jsです。これによって環境情報を収集し、C2へ送信します。収集される情報は以下のとおりです。
- ドメイン
- ユーザ名
- コンピュータ名
- OSバージョン・ビルド
- DCName
- アーキテクチャ
- カレントディレクトリ
- ローカルIP
- コードページ(ACPとOEMCP)
KoadicのStagerがコマンドを実行するとき、Koadic.work.forkを実行しますが、今回は以下のような実装になっていました。(図5)このように、rundll32.exeのRunHTMLApplicationを使ってHTAを実行しています。この動きをEDRログで見ると、mshta.exeが起動していないにも関わらず同様の挙動が発生しており、一見すると奇妙に見えるため注意が必要です。
図5 JavaScriptコード(Koadic.work.fork)
環境情報を収集する他、/data/implant/persist/schtasks.js を使ったPersistence処理や、/data/implant/gather/enum_domain_info.js を使ったさらなる環境調査などが行われました。その後、攻撃対象であると判断されると、/data/implant/manage/exec_cmd.js を用いてコマンドが実行されます。実行されるコマンドは、PowerShellでCobalt Strikeのビーコンを実行するものでした。 その後、Cobalt Strikeによって様々な処理が行われますが、その過程でKoadicが起動されます。なぜ再びKoadicを使い始めたのか詳細は分かりませんが、先程と同じC2を用いて攻撃を続行しました。先程と同じように環境情報を収集したり、Persistence設定などを行ったあと、/data/implant/elevate/ bypassuac_compdefaults.js を使ってUACバイパスを行います。(図6)
図6 JavaScriptコード(bypassuac_compdefaults.js)
また、Cobalt StrikeはAdFind.exeを作成し、実行します。AdFind.exeの結果はkiya.csvというファイルに出力されていました。その後、PowerSploitのビーコンも実行されましたが、それによる操作は失敗していると思われます。 攻撃者はKoadicとCobalt StrikeとPowerSploitを用いて環境の調査やクレデンシャルを盗もうとしたりしますが、それらが上手くいかなかったためか、Koadicの/data/implant/util/upload_file.jsを使ってA5.binというファイルを作成します。 (図7)
図7 JavaScriptコード(upload_file.js)
その後、Cobalt StrikeによってA5.binはwindows.exeという名前にリネームされて実行されますが、A5.binを書き込む際の処理にバグが存在し、正常にexeファイルとして書き込めなかったためにwindows.exeの実行に失敗していました。我々はそのことに気がついたため、すぐに正常なwindows.exeを作成して実行しましたが、その後攻撃者からの操作は行われませんでした。このwindows.exeはDridexで、C2はTwitter等で既に情報共有[3]されているものでした。
最後に
このように、メールに添付されたxlsbファイルからKoadicが起動し、Cobalt StrikeやPowerSploitなどが使用された後、Dridexが作成・実行されました。初期検体であるxlsbファイルはExcel 4.0 Macroが使用されており、既存のアンチウイルスソフトによる検知は期待できません。また、攻撃者はKoadicだけではなく、Cobalt StrikeやPowerSploitを並行して組み合わせて実行しており、例えばKoadicで作成したファイルをCobalt Strikeで実行するような挙動がありました。最終的に攻撃者が何をしたかったのか、はっきりとは分かりませんが、今後もOperation Kiyaによる攻撃には注意が必要です。
インディケータ(更新版)
- 初期検体(xlsbファイル)
- 3df14d5ad31b209b82d6c0f996d494bf
- fdead4062c66ebed339b557bdde58b11
- b1e1cbbe8d9512ae68eaec9948042adb
- Koadic
- 206[.]189.191.187
- theelder[.]site (157[.]245.225.119)
- 157[.]245.92.178
- germes[.]site (157[.]245.11.146)
- Cobalt Strike
- 209[.]97.190.80
- 165[.]227.85.160
- AdFind.exe
- 53ca6d9c75197f3b6a46e310df4429b4
- windows.exe
- 75edf31f4aa130f1481a1c164992e07f
- 176[.]10.250.88:443
- 209[.]40.205.12:4433
- 79[.]143.178.194:3309
- 188[.]165.247.187:691
参考
[1] 建築業界を狙ったサイバー攻撃オペレーション「kiya」について
[3] Twitter VK_Intel