12 KiB
Raw Blame History

マルウェア解析

{{#include ../../banners/hacktricks-training.md}}

フォレンジック チートシート

https://www.jaiminton.com/cheatsheet/DFIR/#

オンラインサービス

オフラインのアンチウイルスおよび検出ツール

Yara

インストール

sudo apt-get install -y yara

ルールの準備

このスクリプトを使用して github からすべての yara malware rules をダウンロードしてマージしてください: https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9
rules ディレクトリを作成して実行してください。これにより、malware のすべての yara rules を含む malware_rules.yar というファイルが作成されます。

wget https://gist.githubusercontent.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9/raw/4ec711d37f1b428b63bed1f786b26a0654aa2f31/malware_yara_rules.py
mkdir rules
python malware_yara_rules.py

スキャン

yara -w malware_rules.yar image  #Scan 1 file
yara -w malware_rules.yar folder #Scan the whole folder

YaraGen: Check for malware and Create rules

ツール YaraGen を使って、binary から yara rules を生成できます。次のチュートリアルを参照してください: Part 1, Part 2, Part 3

python3 yarGen.py --update
python3.exe yarGen.py --excludegood -m  ../../mals/

ClamAV

インストール

sudo apt-get install -y clamav

スキャン

sudo freshclam      #Update rules
clamscan filepath   #Scan 1 file
clamscan folderpath #Scan the whole folder

Capa

Capa は実行ファイルPE、ELF、.NET内の潜在的に悪意のある capabilities を検出します。したがって、Att&ck の戦術や以下のような疑わしい機能を見つけます:

  • check for OutputDebugString error
  • run as a service
  • create process

入手は Github repo で。

IOCs

IOC は Indicator Of Compromise の略です。IOC は潜在的に望ましくないソフトウェアや確定した malware を識別する一連の conditions that identify です。Blue Teams はこの種の定義を使って、systemsnetworks 内のこの種の悪意あるファイルを search for this kind of malicious files します。
これらの定義を共有することは非常に有用です。なぜなら、あるコンピュータでマルウェアが特定されそのマルウェア用の IOC が作成されると、他の Blue Teams はそれを使ってマルウェアをより速く特定できるからです。

IOC を作成または修正するツールには IOC Editor. があります。
Redline のようなツールを使って、デバイス内で定義された IOCs を search for defined IOCs in a device することができます。

Loki

Loki は Simple Indicators of Compromise を対象としたスキャナです。
検出は四つの検出方法に基づいています:

1. File Name IOC
Regex match on full file path/name

2. Yara Rule Check
Yara signature matches on file data and process memory

3. Hash Check
Compares known malicious hashes (MD5, SHA1, SHA256) with scanned files

4. C2 Back Connect Check
Compares process connection endpoints with C2 IOCs (new since version v.10)

Linux Malware Detect

Linux Malware Detect (LMD) は、GNU GPLv2 ライセンスで公開されている Linux 向けの malware scanner で、共有ホスティング環境が直面する脅威を想定して設計されています。ネットワークエッジの侵入検知システムからの脅威データを用いて、実際に攻撃で使用されている malware を抽出し、検出用のシグネチャを生成します。さらに、脅威データは LMD checkout feature を使ったユーザー提出や malware コミュニティのリソースからも得られます。

rkhunter

Tools like rkhunter can be used to check the filesystem for possible rootkits and malware.

sudo ./rkhunter --check -r / -l /tmp/rkhunter.log [--report-warnings-only] [--skip-keypress]

FLOSS

FLOSS は、様々な手法を用いて実行ファイル内の obfuscated strings を見つけようとするツールです。

PEpper

PEpper は実行ファイル内部の基本的な項目をチェックしますbinary data, entropy, URLs and IPs, some yara rules

PEstudio

PEstudio は Windows executables の情報imports, exports, headersを取得でき、virus total の確認や潜在的な Att&ck techniques の検出も行います。

Detect It Easy(DiE)

DiE はファイルが encrypted かどうかを検出し、packers も検出するツールです。

NeoPI

NeoPI は Python スクリプトで、様々な statistical methods を使用して text/script files 内の obfuscated および encrypted コンテンツを検出します。NeoPI の目的は、detection of hidden web shell code を支援することです。

php-malware-finder

PHP-malware-finderobfuscated/dodgy code や、malwares/webshells でよく使われる PHP 関数を使用しているファイルの検出に尽力します。

Apple Binary Signatures

いくつかの malware sample を確認する際は、署名されたバイナリの check the signature を常に行ってください。署名した developer が既に related with malware. である可能性があります。

#Get signer
codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier"

#Check if the apps contents have been modified
codesign --verify --verbose /Applications/Safari.app

#Check if the signature is valid
spctl --assess --verbose /Applications/Safari.app

検出手法

ファイルスタッキング

もし特定のフォルダが last updated on some date だったことが分かっている場合、そのフォルダが web server の files を含んでいるなら、web server 内のすべての files の作成日・更新日を Check し、日付に suspicious な点があればそのファイルを確認してください。

ベースライン

フォルダ内の files が本来 shouldn't have been modified はずであれば、フォルダ内の original fileshash を計算して current なものと compare します。変更されているものは suspicious です。

統計分析

情報が logs に保存されている場合、check statistics like how many times each file of a web server was accessed as a web shell might be one of the most といった統計を確認できます。


Android アプリ内ネイティブテレメトリ (no root)

Android では、他の JNI ライブラリが初期化される前に小さな logger library をプリロードすることで、ターゲットアプリのプロセス内の native code にインストルメントを仕込み、system-wide hooks や root を必要とせずに native の挙動を早期に可視化できます。一般的なアプローチとして SoTap があり: 適切な ABI 向けに libsotap.so を APK に入れ、早い段階で System.loadLibrary("sotap") を挿入(例: static initializer や Application.onCreateし、internal/external paths からログを収集するか Logcat をフォールバックとして利用します。

セットアップ手順とログパスの詳細は Android native reversing ページを参照してください:

{{#ref}} ../../mobile-pentesting/android-app-pentesting/reversing-native-libraries.md {{#endref}}


難読化された動的制御フローの復号化 (JMP/CALL RAX Dispatchers)

現代の malware ファミリーは Control-Flow Graph (CFG) の難読化を多用します。直接的な jump/call の代わりに実行時に宛先を計算して jmp raxcall rax を実行します。小さな dispatcher通常9命令ほどが CPU の ZF/CF フラグに応じて最終ターゲットを設定し、静的な CFG 復元を完全に破壊します。

この手法は SLOW#TEMPEST loader によって示された例のように、IDAPython と Unicorn CPU emulator のみを用いる3ステップのワークフローで対処できます。

1. Locate every indirect jump / call

import idautils, idc

for ea in idautils.FunctionItems(idc.here()):
mnem = idc.print_insn_mnem(ea)
if mnem in ("jmp", "call") and idc.print_operand(ea, 0) == "rax":
print(f"[+] Dispatcher found @ {ea:X}")

2. ディスパッチャのバイトコードを抽出する

import idc

def get_dispatcher_start(jmp_ea, count=9):
s = jmp_ea
for _ in range(count):
s = idc.prev_head(s, 0)
return s

start = get_dispatcher_start(jmp_ea)
size  = jmp_ea + idc.get_item_size(jmp_ea) - start
code  = idc.get_bytes(start, size)
open(f"{start:X}.bin", "wb").write(code)

3. Unicornでそれを2回エミュレートする

from unicorn import *
from unicorn.x86_const import *
import struct

def run(code, zf=0, cf=0):
BASE = 0x1000
mu = Uc(UC_ARCH_X86, UC_MODE_64)
mu.mem_map(BASE, 0x1000)
mu.mem_write(BASE, code)
mu.reg_write(UC_X86_REG_RFLAGS, (zf << 6) | cf)
mu.reg_write(UC_X86_REG_RAX, 0)
mu.emu_start(BASE, BASE+len(code))
return mu.reg_read(UC_X86_REG_RAX)

run(code,0,0)run(code,1,1) を実行して、falsetrue の分岐先を取得します。

4. 直接ジャンプ/コールをパッチで戻す

import struct, ida_bytes

def patch_direct(ea, target, is_call=False):
op   = 0xE8 if is_call else 0xE9           # CALL rel32 or JMP rel32
disp = target - (ea + 5) & 0xFFFFFFFF
ida_bytes.patch_bytes(ea, bytes([op]) + struct.pack('<I', disp))

パッチ適用後、IDAに関数を再解析させ、フルCFGとHex-Raysの出力を復元させる:

import ida_auto, idaapi
idaapi.reanalyze_function(idc.get_func_attr(ea, idc.FUNCATTR_START))

5. 間接APIコールにラベルを付ける

すべての call rax の実際の宛先が判明したら、IDAにそれが何であるかを教えることで、パラメータの型や変数名が自動的に復元されます

idc.set_callee_name(call_ea, resolved_addr, 0)  # IDA 8.3+

実用的な利点

  • 実際の CFG を復元する → 逆コンパイルは 10 行から数千行に増える。
  • 文字列のクロスリファレンス & xrefs を有効にし、挙動の再構築を容易にする。
  • スクリプトは再利用可能:同じ手法で保護された任意の loader に投入すれば使える。

AdaptixC2: 設定抽出と TTPs

専用ページを参照:

{{#ref}} adaptixc2-config-extraction-and-ttps.md {{#endref}}

参考資料

{{#include ../../banners/hacktricks-training.md}}