Linux CTF比赛中，还有重要的一项就是分析ELF文件，复杂一点都会遇到，我也是刚学没多长时间，我就把我的一些思路写出来，也欢迎大家一讨论，一起进步。Linux ELF 文件安全分析/恶意样本分析，我一般是按照“静态 → 动态 → 行为 → 逆向 → IOC → 溯源”这条线来做。对于应急响应、CTF 和 Linux 恶意软件分析都比较实用。

一、先建立整体分析流程

                    ELF 样本
                       │
             ┌─────────┴─────────┐
             ↓                   ↓
         文件信息              哈希/IOC
        file/readelf           sha256sum
             │
             ↓
       ┌───────────────┐
       │   静态分析    │
       └───────┬───────┘
               │
     ┌─────────┼──────────┐
     ↓         ↓          ↓
   strings   readelf     objdump
     │         │          │
     └─────────┼──────────┘
               ↓
         函数/导入/段
               │
               ↓
       ┌───────────────┐
       │   动态分析    │
       └───────┬───────┘
               │
     ┌─────────┼──────────┐
     ↓         ↓          ↓
   strace     ltrace     gdb
     │         │          │
     └─────────┼──────────┘
               ↓
        网络/文件/进程行为
               │
               ↓
       ┌───────────────┐
       │   逆向分析    │
       └───────┬───────┘
               ↓
      Ghidra / IDA / Binary Ninja
               │
               ↓
       IOC + 攻击行为 + TTP

二、第一步：确认 ELF 基本信息

拿到样本以后，不要直接运行。

首先：

file sample

例如：

ELF 64-bit LSB pie executable, x86-64
dynamically linked
interpreter /lib64/ld-linux-x86-64.so.2
for GNU/Linux 3.2.0

然后：

sha256sum sample
md5sum sample

建议保存：

SHA256
MD5
文件大小
文件名
首次发现时间
来源

三、检查 ELF Header

最基础：

readelf -h sample

重点看：

Class
Data
Machine
Entry point address
Type
OS/ABI

例如：

Class:        ELF64
Data:         2's complement, little endian
Type:         DYN
Machine:      Advanced Micro Devices X86-64
Entry point:  0x1050

这里可以判断：

1. 32 位还是 64 位

ELF32
ELF64

2. 架构

x86
x86-64
ARM
AArch64
MIPS
RISC-V

对于 Linux 恶意软件尤其重要，因为现在 IoT / Botnet 样本经常出现：

ARM
MIPS
ARM64

四、检查 ELF Sections

readelf -S sample

重点观察：

.text
.rodata
.data
.bss
.plt
.got
.dynamic
.dynsym
.dynstr

正常情况下：

.text       代码
.rodata     只读数据
.data       初始化数据
.bss        未初始化数据

如果发现非常奇怪的 section，例如：

.upx
.packer
.shellcode
.xxx

就需要进一步判断是否：

UPX
自定义 packer
shellcode
加密数据
恶意 payload

不过异常 section 名字本身不能直接证明恶意。

五、检查程序段 Program Headers

这个比 section 更重要。

readelf -l sample

重点观察：

LOAD
R E
RW
RWX

特别关注：

RWE
RWX

例如：

LOAD 0x... R E
LOAD 0x... RW

比较正常。

如果存在：

LOAD 0x... RWE

就值得进一步调查。

因为：

W = Writable
X = Executable

意味着某段内存：

可写 + 可执行

可能与：

JIT
unpacking
self-modifying code
shellcode
exploit payload

有关。

但同样不能仅凭 RWX 就判定恶意。

六、检查 ELF 安全机制

这是 Linux ELF 安全分析非常重要的一部分。

可以使用：

checksec --file=sample

例如：

RELRO           Partial RELRO
Stack Canary    No canary found
NX              NX enabled
PIE             PIE enabled
RPATH           No RPATH
RUNPATH         No RUNPATH
Symbols         No

重点关注：

防护	作用
NX	防止数据段执行
PIE	地址随机化
ASLR	运行时地址随机化
RELRO	GOT 保护
Canary	栈溢出检测
FORTIFY	部分 libc 函数强化

如果你分析的是漏洞利用样本，这些信息尤其重要。

例如：

No PIE
No Canary
NX disabled
Partial RELRO

意味着攻击面可能比较大。

七、检查动态链接库

ldd sample

以及：

readelf -d sample

重点：

NEEDED
RPATH
RUNPATH

例如：

libc.so.6
libpthread.so.0
libdl.so.2
libcrypto.so
libssl.so

如果出现：

libpcap
libcurl
libssh
libcrypto
libssl

可以结合后续行为判断它可能具备：

网络通信
抓包
SSH
TLS
加密

八、重点：strings

这是 ELF 初步恶意分析最有效的手段之一。

strings -a -n 6 sample

建议分类看。

URL

strings sample | grep -Ei 'https?://'

IP

strings sample | grep -Eo \
'([0-9]{1,3}\.){3}[0-9]{1,3}'

Shell 命令

strings sample | grep -Ei \
'bash|sh |curl|wget|chmod|chown|nohup|systemctl|crontab'

SSH

strings sample | grep -Ei \
'ssh|authorized_keys|known_hosts'

持久化

strings sample | grep -Ei \
'cron|systemd|rc.local|init.d|profile'

可疑路径

strings sample | grep -E \
'/tmp/|/dev/shm/|/etc/|/var/tmp/'

尤其值得注意：

/tmp
/dev/shm
/var/tmp

因为 Linux 恶意程序经常利用这些位置。

九、检查导入函数

readelf --dyn-syms sample

或者：

nm -D sample

重点搜索：

system
execve
popen
fork
vfork
clone
ptrace
dlopen
dlsym
socket
connect
send
recv
open
read
write
unlink
chmod
setuid
setgid

例如：

readelf --dyn-syms sample | grep -E \
'system|execve|popen|socket|connect|ptrace'

如果出现：

socket
connect
recv
send

说明存在网络通信能力。

如果同时存在：

fork
execve

就需要进一步观察是否：

下载 payload
执行 shell
创建子进程

十、检查是否被 UPX 等工具加壳

upx -t sample

或者：

strings sample | grep -i upx

也可以：

readelf -S sample

观察：

UPX0
UPX1
UPX2

如果确认是 UPX：

cp sample sample.bak
upx -d sample

然后重新分析。

十一、动态分析：千万不要直接在宿主机运行

建议准备一个隔离环境：

分析机
 │
 ├── Ubuntu VM
 │
 ├── 无互联网 / 受控网络
 │
 ├── Snapshot
 │
 └── 样本目录

如果样本来源不明，最好：

VirtualBox / VMware / KVM
        +
独立网络
        +
快照

十二、第一工具：strace

这是分析 ELF 行为非常好用的工具。

strace -f -o strace.log ./sample

然后：

grep -Ei \
'openat|execve|connect|socket|unlink|chmod|ptrace' \
strace.log

例如发现：

openat(... "/etc/passwd" ...)
openat(... "/etc/shadow" ...)
socket(...)
connect(...)
execve("/bin/sh", ...)

那么行为就非常值得关注。

十三、网络行为

可以使用：

strace -f -e trace=network ./sample

或者：

tcpdump -i any -nn

更方便：

tcpdump -i any -nn -w sample.pcap

然后用 Wireshark 分析：

DNS
TCP
HTTP
HTTPS
TLS
IRC
自定义 C2

重点寻找：

C2 IP
C2 Domain
DNS
User-Agent
HTTP URI
特殊协议
Beacon 周期

十四、进程行为

运行：

ps aux

然后：

pstree -ap

重点看：

sample
 ├── sh
 ├── curl
 ├── wget
 └── another_process

如果恶意 ELF：

自己运行
 ↓
fork
 ↓
execve /bin/sh
 ↓
curl 下载
 ↓
chmod
 ↓
执行第二阶段 payload

那么基本可以构造完整行为链。

十五、Linux 恶意 ELF 特别需要检查的持久化

这是应急响应中非常重要的一部分。

Cron

crontab -l
cat /etc/crontab
ls -la /etc/cron.d/

systemd

systemctl list-unit-files
systemctl list-timers

重点：

find /etc/systemd -type f

SSH

find /home /root -name authorized_keys -type f -exec ls -l {} \;

Shell profile

cat ~/.bashrc
cat ~/.profile
cat /etc/profile

rc.local

cat /etc/rc.local

十六、进一步进入逆向

当：

file
readelf
strings
strace

已经确定存在可疑行为后，再进入：

Ghidra

适合：

ELF
C/C++
Go
Rust
 stripped binary

IDA

适合深入：

函数分析
交叉引用
复杂 ELF
反编译

GDB

动态调试：

gdb ./sample

常用：

info functions
info registers
disassemble main
break main
run
x/20gx $rsp

十七、如果是 stripped ELF

很多恶意 ELF 会：

strip

导致：

没有函数名

例如：

readelf -s sample

可能只剩：

.dynsym

这时候可以利用：

字符串
↓
XREF
↓
调用点
↓
函数边界
↓
反编译

例如在 Ghidra 中：

"authorized_keys"
        ↓
XREF
        ↓
某函数
        ↓
分析该函数调用链

这是分析 Linux 恶意样本非常常见的方法。

十八、特别关注几类 ELF 恶意行为

Linux 恶意 ELF 我建议重点建立下面这个分类：

                    ELF Malware
                         │
       ┌─────────────────┼─────────────────┐
       ↓                 ↓                 ↓
    Downloader          Botnet           Backdoor
       │                 │                 │
     curl/wget        C2通信             shell
       │                 │                 │
       └────────────┬────┴─────────────────┘
                    ↓
                 Persistence
                    │
        ┌───────────┼───────────┐
        ↓           ↓           ↓
      cron       systemd      SSH key

另外还要特别注意：

Cryptominer
Rootkit
Botnet
DDoS malware
Ransomware
Credential stealer
Webshell loader
Downloader
Backdoor
Proxy
Tunnel

十九、建立 IOC

最终不要只得到一句：

“这个 ELF 是恶意的。”

应该形成结构化 IOC：

SHA256:
xxxx

Filename:
xxxx

C2 IP:
1.2.3.4

C2 Domain:
example.com

URL:
/update/check

User-Agent:
xxxx

File:
 /tmp/.xxx
 /dev/shm/.xxx

Persistence:
 /etc/cron.d/xxx

Process:
 xxx → /bin/sh

Command:
 curl http://...

Mutex:
 ...

Config:
 ...

然后可以进一步转成：

YARA
Sigma
Suricata
Snort
IOC
STIX

二十、如果你要系统学习 ELF 安全分析

结合你之前做的 Linux 应急响应、CTF、恶意代码分析，我建议直接按照这个实验路线：

Level 1
file
sha256sum
readelf
strings
objdump
nm
ldd
checksec

        ↓

Level 2
strace
ltrace
tcpdump
ps
/proc

        ↓

Level 3
GDB
Ghidra
IDA

        ↓

Level 4
ELF Malware
Downloader
Botnet
Miner
Backdoor

        ↓

Level 5
Rootkit
LD_PRELOAD
ptrace
eBPF
Kernel Module

        ↓

Level 6
自动化分析
YARA
Capa
FLOSS
Ghidra script
沙箱
IOC 自动提取

**我现在IDA和Ghidra一直搞得不太行，也就会一些初步的分析，学起来脑袋有点炸。**大家要是有好的学习资源也可以分享出来，或者好的学习方法，目前在看雪论坛和52pojie论坛上学习。

- END -