PHP-malware-finder 是一款优秀的检测webshell和恶意软件混淆代码的工具,比如以下组件都可以被检测发现。

Best PHP Obfuscator Carbylamine Cipher Design Cyklodev Joes Web Tools Obfuscator P.A.S PHP Jiami Php Obfuscator Encode SpinObf Weevely3 atomiku cobra obfuscator phpencode tennc web-malware-collection webtoolsvn novahot

工作原理

PHP-malware-finder的检测原理是基于YARA规则爬取文件系统和测试文件,如可以发现经过两次编码、解压的危险参数。

使用方法

两种使用方法:

$ ./phpmalwarefinder -h
Usage phpmalwarefinder [-cfhtv] [-l (php|asp)] <file|folder> ...
    -c  Optional path to a configuration file
    -f  Fast mode
    -h  Show this help message
    -t  Specify the number of threads to use (8 by default)
    -v  Verbose mode
    -l  Set language ('asp', 'php')
也可以这样:
$ yara -r ./php.yar /var/www
$ yara -r ./asp.yar /var/www
可以通过修改yar文件添加规则:

屏幕快照 2017-03-06 下午1.33.40.png

使用测试:

屏幕快照 2017-03-06 下午1.35.20.png

查杀一下自己平时收集到的免杀shell,覆盖度还是蛮高的。

下载地址

github地址:

https://github.com/nbs-system/php-malware-finder *本文作者:六翼,转载须注明来自FreeBuf.COM

近期,曾通过链接重定向方法劫持川普Twitter的比利时黑客@securinti,发现了从Facebook查找注册用户手机号码的方法,我们一起来看看。以下是@securinti发表的博客: 上个月,我发现,通过Facebook可以轻而易举地获取到一些比利时名人和政治家的手机号码。目前,尽管这种方法貌似只对像比利时这样只有1120万人左右的小国家有效,但这种简单而有效的方法,却会让很多人的用户隐私受到影响。当我把这个情况向Facebook的安全团队报告之后,却得到了一个失望的回复,他们竟然认为这根本不是一个安全问题。

2.jpeg

但我觉得用户隐私至上,所以,在此我就公开来谈谈这个问题。

我认为的问题

如果在Facebook设置中,其隐私一栏,其“谁可以通过手机查找到我”(Who can look you up using the phone number you provided?)是everyone状态,那么可能就能通过我的方法查找出你的手机号码。

4.png

这里存在两方面的问题:
首先,该选项的everyone状态是默认设置; 其次,即使你在个人资料中将手机号码设置为“个人可见”(Only me),但只要“Who can look you up using the phone number you provided?”是“everyone”状态,一样存在手机号码泄露问题。

3.png

“通过手机查找到我”本质上来说,是想查找你的人已经知道你的手机号码,而他可以通过你的手机号码查看到你的Facebook账户,但在这里的选项中,根本没有“only me”。

6.png

为了方便登录和找回密码,Facebook会不断地提醒用户绑定手机号码,但如果你的Facebook账号绑定了手机号码,那么你的手机号码可能就存在泄露隐患。

7.jpeg

测试实现

在这里我需要用到的是Faceook在2013年推出的搜索引擎Graph Search,当你在搜索框中输入一个手机号码之后,可能就会得到一个相关用户:

8.jpeg

这样的方式,如果手工测试的话,费时又麻烦,而且在执行了1000次左右的搜索之后,Facebook就会作出查询限制;当然,即使是用botnet方式,估计Facebook也会有相应限制措施。为了验证,我以查找比利时内政部长Jan Jambon的手机号码为例进行测试。

STEP 1:使用密码重置功能排除手机号码最后两位(1分钟)

基于此,我必须找到一种批量测试电话号码的方法,测试的位数越少,获取的手机号码可能就越多,查找到目标的可能性也就越大。所以,可以使用Facebook的密码重置功能排除掉手机号码最后两位:

9.png

STEP2:了解不同运营商手机号码格式(5-35分钟)

如04PPXXXX50,这就是一个典型的比利时手机号码,其中X为0-10的任意数字,PP为运营商代号号码。而且,不同的电话运营商都有的固定的号段,如0468、047、048和049:

10.png

由于Proximus是比利时政府通讯业务的主要服务商,所以大部份政府部门雇员都使用047号段,所以我就专门写了个程序来枚举这个号段的目标号码,如有10000种号码组合的0479号段,以下是自动生成的号码表:

11.png

之后,向Facebook“好友查找”功能中导入以上生成的号码表进行查找,此时,找到了以”Jan”开头的大量用户,但他们都不是Jan Jambon。(在出现的Facebook反馈结果中,会提示说:You have 500 file_upload contacts on…,可以不用管)

12.png

之后,以这种方法,在继续尝试了0479号段之后,终于发现了目标账户使用的运营商代号和号段:0477,现在的号码为:0477XXXX50,目标范围逐渐缩小,目标号码就在这剩下的10000种组合中。

13.png

STEP3: 缩小范围(10-15分钟)

最后,需要解决的就是一些简单的数学问题了,我们先测试10000种可能中的一半号码,即0477 0000 50 — 0477 5000 50,可以看出目标账户出现在这个范围中:

13.png

这意味着目标账户手机号码的第5位只可能是0,1,2,3,4中的一位,所以再继续使用半分测试法进行,先对0477 0000 50 – 0477 2500 50进行测试,可以看到目标账户未出现在这个区间:

15.png

那么,最后就剩下0477 2500 50 – 0477 5000 50区间了,使用之前的方法,继续在1250、750、325、162和81区间进行半分测试,一直可以测试到40个号码,20个号码,10个号码到最终的5个号码,之后,发现目标。

STEP4:发现目标账户和与其匹配的手机号码(1分钟)

16.jpeg

其实如果最后剩下40个可能的号码,我们都可以手动进行验证

后记

我尝试着将这个问题告知了比利时内政部长Jan Jambon,而他表示并不知道Facebook泄露了他的手机号码,只要不存在滥用情况,他自己也不介意。 另外,我们还与一家当地电台合作,在直播中拨打了一位比利时知名人士的手机,并告知他我们可以通过Facebook找出他的手机号码,我们就此聊得非常愉快,之后他便从Facebook上删除了绑定的手机号码。 有人指出,利用PayPal可以发现用户的后四位手机号码,所以如果目标用户把PayPal和手机绑定的话,利用以上我的方法,可以发现很多国家受影响的用户个人手机号码。有兴趣的话,可以自行尝试。

FAQ

这主要是什么问题?

由于Facebook隐私安全项“who can look me up by phone(通过手机号查找到我)”的默认设置为“everyone”,所以你的手机号码都会存在泄露风险。对于一些小国家来说,由于移动运营商提供的手机号码段空间范围较小,所以通过Facebook来查找目标用户电话号码相对来说比较容易。Facebook在个人资料中提供的将手机号码设置为“only me”(对自己可见)”其实并没有什么用。

哪些人会受到影响?

一些小国家绑定了手机号码的Facebook用户,如果没有修改默认的隐私设置,可能会受此问题影响。如果目标手机号码低于十位数,而通信运营商号段范围空间较小,以上测试方法就容易实现。

如何知道自己是否受到影响?

点击这里,检查“who can look me up by phone(通过手机号码查找到我)”查看设置,如果设置成了“Everyone”则受此影响。

如果受到影响应该如何设置?

这是一个很矛盾的问题,因为双因素身份验证功能需要用到手机号码,而目前这也算是一种比较安全的账户防护措施,所以可行的方法还是将“who can look me up by phone(通过手机号码查找到我)”设置为“only friends“(仅对好友可见)。 *参考来源:hackernoon,FB小编clouds编译,转载请注明来自FreeBuf.COM.

*原创作者:tgfreebuf,本文属Freebuf原创奖励计划,未经许可不得转载 (本文仅做技术探讨,请勿用于非法用途) 闪存盘普及,已经成为最常用的移动存储设备,不过也正因其体积小巧,易丢失,因此也容易成为泄密工具。为防范闪存盘意外丢失引起的资料泄密,市面上出现了带有加密区功能的闪存盘,这种闪存盘一般把物理存储空间分成两个区:其一为公共区,另一个为加密区,用户通过运行特定软件输入正确口令,加密区才可用于存取数据。在没有输入正确口令之前,加密区不能用于存取资料。这样闪存盘即使在丢失后,对于不知道加密区口令的人来说是无法查看到加密区存储的内容。不过它真的可以做到万无一失吗?如果发生问题,该如何更好的做出防范呢?下面我们通过一个真实案例来看看对于闪存盘加密区攻防的实战 本次演示案例的软硬件环境如下图

1.png

本次案例中使用慧荣主控的闪存盘加密区的密码创建我们尝试采用了两种方式:一种是直接在量产工具中创建时设定,比如本文案例中针对该部分会使用的量产选项如下图,注意红框处公共区盘符为p,加密区盘符为s,密码为4个0

2.png

另一种是使用像uDiskToolBar这样的工具软件进行创建或修改过的,软件运行后第一个按钮即为加密区创建或调整用;第二个按钮为加密区登入登出(这里需要指出,不管是使用量产方式创建加密区还是用uDiskToolBar创建的加密区都需要用到该按钮的功能,才能实现加密区的登入登出,这就是本文开头部分所指的特定软件)

3.png

下面首先让我们来看看攻的一方—如何实现窥探加密区密码的实现方法

即通过运行对应版本的SMI MPTool量产工具的Debug模式达到查看目的,点击SMI MPTool界面中的Debug按钮输入密码1111

4.png

然后按Read WPRO查看地址栏00000040对应的行内容:01代表激活加密区密码;04代表密码长度,同时在右边字符串栏可见到0000的明文密码

5.png

如果你的闪存盘加密区通过uDiskToolBar进行过密码的修改,那么该处的数值将不会是明文,而是加密的,不过这并不影响下文中的移除密码的操作。

6.png

移除密码的操作非常简单,就是将地址栏00000040这行全部填零,然后点击Write WPRO按钮进入写入操作

7.png

之后使用uDiskToolBar进行尝试登入操作,可能会有一些提示(比如登入失败),不过你不用理会

8.png

 之后即可登入加密区s,查看到加密区的内容(之前我们事先拷入四个图片文件,由图可见已可正常打开)

9.png

至此加密区密码破解操作完成。 

接着来讲讲防的部分,如果遇到类似问题我们该如何做出防范:

我们知道就加密而言,并不存在绝对的无法破解的加密技术,有效的办法往往是通过几种加密方式的组合加强暴力破解的难度,比如:银行网银一般会采用一组私人密码加上硬件Key随机密码,二者组合的方式达到安全防护的目的。在本例中我们可以使用VeraCrypt创建文件型加密盘,然后将其再放入加密区,这样即使加密区失守,不怀好意的人得到的也是经VeraCrypt加密的文件。 VeraCrypt是从TrueCrypt衍生出来的。加密算法部分,由下图可见不光支持算法的”单重加密”,还支持多个算法组合成”双重加密”甚至”三重加密”。一般建议:如果你要制作的加密盘是用来备份个人的隐私或敏感文件,并且这个加密盘平时不常使用,那可以选择强度最高的”三重加密”。如果考虑兼顾加解密性能,使用单重加密即可。另外哈希算法部分,哈希值的长度越大,”人为碰撞”和”随机碰撞”的概率就越小,这里一般选择默认即可。

a.png

加密盘格式部分,相较TrueCrypt 原格式,VeraCrypt的新格式支持 PIM 功能(“Personal Iterations Multiplier”的缩写),这个 PIM 参数有助于提升加密盘的安全性——主要是对抗“暴力破解”。更多VeraCrypt方面的使用方法请上网搜寻即可。

b.png

结语:

存储的本质是数据,数据的安全是保护盾。面对泄密,多种方式组合的加密移动存储安全性会更高,不过有关数据安全方面的攻防会一直延续下去,我们还将在不断学习的道路上! *原创作者:tgfreebuf,本文属Freebuf原创奖励计划,未经许可不得转载

大约在两年前,Tim Medin提出了一种新的攻击技术,他称之为“Kerberoasting”。尽管在这种攻击技术发布时我们还没有意识到其全部的含义,但这种攻击技术已经改变了我们的交战游戏。

思科Talos安全团队最近发现一款Powershell恶意程序,用DNS进行双向通信

前言

DNS是企业网络中最常用的Internet应用层协议。DNS提供域名解析,这样用户就可以通过域名而非IP地址来访问网络资源。许多企业会严格监控web流量,但对基于DNS的威胁的防护就比较少。攻击者也注意到了这点,经常将其他协议封装进DNS协议中来躲避安全监测。
攻击者利用DNS协议一般都是要获取信息。思科Talos团队最近分析了一个很有趣的恶意程序样本,利用DNS TXT记录查询和响应来创建双向的C2通道。攻击者可以通过DNS通信来向感染设备提交命令,并将命令执行结果返回给攻击者。这在远程访问工具中相当罕见,而且隐蔽性较高。此恶意程序中使用了多阶段Powershell脚本,其中许多阶段都是完全无文件的,这就说明攻击者为了避开检测也是很努力的。 讽刺的是,这款恶意程序的作者在代码中高调叫板SourceFire,于是就被思科的Talos团队揪出来了。

正传

说起来,这个故事缘起于一条推特。 推特用户@Simpo13在2月24号发布了一则推文,文中提到他正在分析的一段Powershell恶意脚本,其中包含一段base64编码的字符串“SourceFireSux”(SourceFire sucks的谐音,意为SourceFire烂暴了)。

C5cDCoXXMAEcyfx.jpg

Simpo的推特图片

SourceFire正是思科于2013年用27亿美元收购的。因此“SourceFireSux”的字眼引起了思科威胁情报团队Talos的注意,而Talos团队中也刚好有SourceFire漏洞研究团队的原班人马,于是他们决定深挖这段恶意脚本。

注意.jpg

他们搜索了推文中提到的base64编码值“UwBvAHUAcgBjAGUARgBpAHIAZQBTAHUAeAA=”,发现在公共恶意程序分析沙盒Hybrid Analysis中有一个样本。另外,他们在对编码字符串搜索的过程中还定位到了一条Pastebin条目,其中列出了一写哈希,根据这些,他们找到了一个公共沙盒中的一个恶意Word文件,由此揭开了一个名为“DNSMessenger” 的多阶段感染过程。 在这个特殊案例中,团队先分析了那段被当作VBScript文件提交到公共沙盒中的Powershell文件,他们将之称为为“第三阶段”。他们发现,前面提到的“SourceFireSux”字符串被用作互斥量,如图1所示。

F1.png

第一阶段恶意Word文档

前面提到Talos团队找到了感染链的源头,也就是那个恶意Word文档。这个文档是通过钓鱼邮件传播的。有趣的是,这个Word文档会伪装成被McAfee保护的“受保护文件”。因为McAfee的名气,受害者打开文件并启用宏的概率也就有所提升。打开后,该文档便诱使用户启用内容。

2.png

文档用Document_Open()调用另一个VBA函数。这个VBA函数就会设置一个长字符串,其中包含一个Powershell命令和将执行的代码。然后调用Windows管理界面(WMI)的Win32_Process对象的Create方法,执行上述命令。 通过命令行传递给Powershell的代码基本上是base64编码的,并用gzip压缩的,只有尾部一小部分没有编码。没有编码的这段会被用于解压缩该代码,并传递给Invoke-Expression Powershell cmdlet(IEX)执行。通过这一步骤,代码不需要被写入受感染设备的文件系统,就可以执行。 团队还发现防病毒软件对这个样本的检测率比较低,为6/54,其中ClamAV能够成功检测这个样本。

3.png

第二阶段Powershell

第一阶段中的IEX执行Powershell脚本后,Talos团队开始观察到感染设备上出现了一写比较有趣的活动。第一阶段中描述的Powershell脚本末端有一个函数,定义了第二阶段的指令和三阶的相关特性。第二阶段中的代码经过了混淆处理,团队将这个阶段中用到的主函数称为“pre_logic”,将第三阶段中的函数称为“logic”。 “pre_logic”函数支持两个switch参数。第一个用于决定在下一个感染步骤中是否要实现持久性。如果选择实现持久性,第二个switch就会决定第三阶段代码要不要执行。

4.png

除了两个switch外,“pre_logic”函数还支持四个参数,这四个参数随后将传递给下一阶段的“logic”函数。这些参数决定,下一个感染阶段发送DNS TXT记录查询时,要使用哪些子域。 随后,“pre_logic”函数会解压第三阶段中用到的Powershell脚本,就是包含在该脚本当中的一个base64编码的blob。该函数还会定义后续阶段将用到的一些代码,包括函数调用和参数。 如果 “pre_logic”函数被调用时,选择了实现持久性,函数将会查询感染系统,决定如何最好地实现持久性。根据恶意程序运行时使用的用户账户相应的访问权限,恶意程序将查询恶意程序实现持久性最常用的注册路径。 如果使用的是管理员权限账户,那么脚本会查询并设置: $reg_win_path: “HKLM:Software\Microsoft\Windows\CurrentVersion” $reg_run_path: “HKLM:Software\Microsoft\Windows\CurrentVersion\Run\” 如果使用的是一般用户帐户,脚本则会查询并设置: $reg_win_path: “HKCU:Software\Microsoft\Windows” $reg_run_path: “HKCU:Software\Microsoft\Windows\CurrentVersion\Run\”

5.png

然后根据系统所用的Powershell版本,第三阶段payload将写至不同位置。如果受感染系统用的是Powershell 3.0或者更高版本,第三阶段payload将写至“%PROGRAMDATA%\Windows\”中的ADS流文件中,并命名为“kernel32.dll”。 如果系统用的是较早的Powershell,第三阶段payload将被编码并写至$reg_win_path指定的位置,键名为“kernel32”。随后,用来解压并执行第三阶段payload的代码也会被写至$reg_win_path分配的注册表位置,键名为“Part”。

6.png

这个步骤完成之后,攻击脚本会再次检查并确定用户访问权限。如果是管理员权限,那么被感染系统中的“_eventFilter”、“CommandLineEventConsumer”和“_filtertoconsumerbinding”等WMI事件订阅将会被移除。然后该恶意程序会创建自己的WMI永久事件订阅,筛选出“Win32_LogonSession”事件,并锁定“CommandLineEventConsumer”。受感染系统中每创建一个新的登录会话,之前储存在ADS中的第三阶段payload就会被读取并执行。第三阶段payload默认在30分钟后运行“onidle”。如果在这个阶段开始时,与其执行相关的switch参数被传递至“pre_logic”函数,那么payload就会立即执行。

7.png

如上图所示,该恶意程序还在系统中创建了一个预定任务,任务名为“kernel32”,该任务关系到第三阶段payload储存于ADS还是注册表。Talos团队在分析其他与此攻击有关的样本发现,不同样本当中该预定任务可能会有相应的调整。

第三阶段Powershell

第二阶段中执行的第三阶段Powershell,主要是用一些略显傻气的函数名和变量名进行混淆的(比如${script:/==\/\/\/==__/==},而不是$domains)。整个脚本从头到尾也都是base64编码的。Talos团队反混淆之后发现,脚本中包含许多硬编码域名,然后将随机选出其中一个,用于后续的DNS查询。有点必须要注意的是,第三、四阶段的Powershell脚本,都包含两组域,只有在样本使用第二组域名出现问题时才会使用第一组域名。

8.png

第三阶段Powershell脚本中的“Logic”函数会从脚本中的第二组域中随机选择一个C2域,并用这个域进行初始查找。如果这个初始DNS TXT记录请求的返回值为空,或者说查找失败,那么将调用“do_lookup”函数,并从第一组域中随即选取一个域。 第三阶段脚本还会使用一些特定的子域,与初始DNS TXT记录查询中使用的域相结合。恶意程序用响应的TXT记录内容,来决定下一步动作。比如说,第一个子域为“www”,并且TXT记录查询响应结果包含“www”,就会指示脚本继续。其他指令则会被认为“空”或者“停止”。

9.png

恶意程序收到初始DNS响应后,就会迭代至下一个子域,即“mail”。恶意程序会在另一个DNS TXT记录查询中使用这个域,来尝试获取与当前阶段相关的第四阶段payload。这个DNS请求得到响应后,将获取第四阶段payload,储存在TXT记录中,如图10和图11所示。因为第四阶段payload比较大,这次传输过程用了TCP。

10.png

下图是Wireshark对上述payload的分析

11.png

与第四阶段相关的代码随后会被清理并传递至Invoke-Expression Powershell cmdlet (IEX),并在第三阶段的语境中执行。第四阶段payload并不能自主执行,如果仅尝试执行第四段payload,就会失败,因为第四段payload依赖于第三段Powershell脚本中的解码函数。

12.png

这个函数还有其他几个功能。这个函数会用DNS查询响应结果中获得的代码,定义一个包含该代码的字符串变量。然后,第三阶段中的解码函数会被调用,并将解码的字符串传递给IEX,来扩展Powershell环境。这一步完成后,将调用新扩展环境中的一个函数,来执行第四阶段代码,并设置特定参数。这些参数包含后续将用到的第四阶段C2域名和将执行的程序,即Windows命令行处理器(cmd.exe)。这一步相当有意思,因为这样,第四阶段payload其实是从未被真正写至感染系统的文件系统中。

第四阶段Powershell

如前文所述,四阶Powershell payload是由三阶中的“dec”函数解码。第四阶段payload尾部调用了其中的“cotte”函数,该函数提供了其他一些参数,包括将用到的C2域和将执行的程序(cmd.exe)。当执行cmd.exe时,函数会将STDIN、STDOUT和STDERR重定向,允许payload在命令行处理器中读写。 提供给这个函数调用的域将用来生成DNS查询,用于主要的C2操作。与前面的脚本一致,第四阶段payload当中也有两组硬编码域,但貌似只会用到第二组。

13.png

主C2服务器每发回301个DNS响应,样本就会单独发送一个DNS TXT解析请求到前面提到的第二组中随机选择的域。这个C2请求会决定此恶意程序应不应该在受感染系统上继续运行。跟前面步骤当中类似,这个请求也是发送给次级C2域中的“web”子域的。

14.png

如果次级C2服务器返回包含字符串“stop”的TXT记录,此恶意程序就会停止活动。

15.png

受感染系统向主C2服务器发送“SYN”消息,建立主C2通道。

16.png

这一步完成后,先前从Windows命令行处理器中捕获到的STDOUT和STDERR输出会通过“MSG”消息发出。借此,攻击者发送的命令能够被命令处理器直接执行,攻击者全靠DNS TXT请求和响应就能接收命令的输出结果。下文将详细描述此通信过程。

17.png

将DNS查询请求解码,我们就能看到发送给C2服务器的是命令行处理器的输出结果。

18.png

攻击者就这样建立了一个互动的C2信道,来执行系统命令,并获取命令的输出结果。

C2通信

恶意Word文档中与此感染链相关的C2域注册于2017年2月8日。与Hybrid Analysis中的Powershell样本相关的域注册于2017年2月18日。其中许多域注册时使用的邮箱地址如下: valeriy[.]pagosyan[@]yandex[.]com 其他域时通过NameCheap代理注册服务注册的。 根据Umbrella的分析,与Powershell样本使用的域有关的大部分DNS活动集中出现于2017年2月22日至2月25日。Word文档使用的域则少有活动,其少量的活动集中于2月11日。

19.png

此恶意程序中的所有C2通信都是通过DNS TXT查询和响应完成的。要有互动的“MSG”查询,就必须要建立C2信道,而C2信道建立的先决条件是“SYN”查询。这些消息是由以下元素组成的:
$session_id – 感染设备产生的四位数字,这个数字一直保持不变,而且所有的后续DNS查询和响应中都包含了这个数字。 $sequence_num – 感染设备产生的四位数字,在C2通信过程中定期变化,变化后的新值会被添加至下一个查询中。 $acknowledgement_num – “SYN”消息响应中产生的四位数字,值似乎不会变化,而且必须包括在所有后续的“MSG”查询中。 DNS查询和响应中的第5和第6个字节决定了消息类型,可能是以下值中的任意一个:     00 – ‘SYN’ message     01 – ‘MSG’ message     02 – ‘FIN’ message 其中,用于发送执行命令和返回命令输出的“MSG”查询是十六进制编码的,每30个字节用点分隔。
下图就是整个C2通信的过程。注意在通信过程中,可能有许多个“MSG”查询和响应,这取决于攻击者想要在感染设备上执行的命令。

20.jpg

下图展示了不同的消息及其响应是如何形成的。

21.jpg

结论

从本文的例子中,我们可以看出,攻击者为了躲避检测,可以做到这种地步。本文的例子还说明,除了需要监测和过滤HTTP/HTTPS、SMTP/POC3等网络协议,DNS协议也应该得到应有的重视。企业网络中的DNS流量可以被攻击者利用,来建立双向的C2通信通道,而DNS监控和过滤类产品可有效拦截此类攻击。

IoC

哈希:
f9e54609f1f4136da71dbab8f57c2e68e84bcdc32a58cc12ad5f86334ac0eacf (SHA256) f82baa39ba44d9b356eb5d904917ad36446083f29dced8c5b34454955da89174 (SHA256) 340795d1f2c2bdab1f2382188a7b5c838e0a79d3f059d2db9eb274b0205f6981 (SHA256) 7f0a314f15a6f20ca6dced545fbc9ef8c1634f9ff8eb736deab73e46ae131458 (SHA256) be5f4bfa35fc1b350d38d8ddc8e88d2dd357b84f254318b1f3b07160c3900750 (SHA256) 9b955d9d7f62d405da9cf05425c9b6dd3738ce09160c8a75d396a6de229d9dd7 (SHA256) fd6e7fc11a325c498d73cf683ecbe90ddbf0e1ae1d540b811012bd6980eed882 (SHA256) 6bf9d311ed16e059f9538b4c24c836cf421cf5c0c1f756fdfdeb9e1792ada8ba (SHA256)
C2域
algew[.]me aloqd[.]pw bpee[.]pw bvyv[.]club bwuk[.]club cgqy[.]us cihr[.]site ckwl[.]pw cnmah[.]pw coec[.]club cuuo[.]us daskd[.]me dbxa[.]pw dlex[.]pw doof[.]pw dtxf[.]pw dvso[.]pw dyiud[.]com eady[.]club enuv[.]club eter[.]pw fbjz[.]pw fhyi[.]club futh[.]pw gjcu[.]pw gjuc[.]pw gnoa[.]pw grij[.]us gxhp[.]top hvzr[.]info idjb[.]us ihrs[.]pw jimw[.]club jomp[.]site jxhv[.]site kjke[.]pw kshv[.]site kwoe[.]us ldzp[.]pw lhlv[.]club lnoy[.]site lvrm[.]pw lvxf[.]pw mewt[.]us mfka[.]pw mjet[.]pw mjut[.]pw mvze[.]pw mxfg[.]pw nroq[.]pw nwrr[.]pw nxpu[.]site oaax[.]site odwf[.]pw odyr[.]us okiq[.]pw oknz[.]club ooep[.]pw ooyh[.]us otzd[.]pw oxrp[.]info oyaw[.]club pafk[.]us palj[.]us pbbk[.]us ppdx[.]pw pvze[.]club qefg[.]info qlpa[.]club qznm[.]pw reld[.]info rnkj[.]pw rzzc[.]pw sgvt[.]pw soru[.]pw swio[.]pw tijm[.]pw tsrs[.]pw turp[.]pw ueox[.]club ufyb[.]club utca[.]site vdfe[.]site vjro[.]club vkpo[.]us vpua[.]pw vqba[.]info vwcq[.]us vxqt[.]us vxwy[.]pw wfsv[.]us wqiy[.]info wvzu[.]pw xhqd[.]pw yamd[.]pw yedq[.]pw yqox[.]pw ysxy[.]pw zcnt[.]pw zdqp[.]pw zjav[.]us zjvz[.]pw zmyo[.]club zody[.]pw zugh[.]us cspg[.]pw
*参考来源:talosintelligence,本文作者:白熊,转载请注明来自FreeBuf