---
# System prepended metadata

title: MS16-075 變種 Rotten Potato 本地堤權
tags: [window提權, potato提權]

---

# MS16-075 變種 Rotten Potato 本地堤權 
###### tags: `potato提權` `window提權`

影響版本：< win10 1809 和 < windows server 2019



已下介紹不會太詳細，只是記錄自己學習到重點知識和過程，更詳細的說明可以查看作者文章:
https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/



### 先了解幾個知識點

* RPC:
就是把本地【進程內】的函數調用，放到同一機器的另一進程，或者不同機器的進程的技術。這個技術減輕分佈式開發負擔，使分佈式開發標準化。 RPC主要涉及通信和序列化兩部分。
https://zhuanlan.zhihu.com/p/187560185



* COM 和 DCOM:
是以RPC (Remote Procedure Call)使不同的行程可以相互的溝通，所謂的DCOM則是可以進行跨機器的溝通，這也是COM+的基礎。 (好文分享)
https://dotblogs.com.tw/gelis/2010/12/07/19954




* CLSID:
CLSID是指windows系統對於不同的應用程式，檔案類型，OLE對象，特殊資料夾以及各種系統組件分配的一個唯一表示它的ID代碼，用於對其身份的標識和與其他對象進行區分。
https://www.cnblogs.com/boltkiller/articles/4791503.html


* BITS(後台智能傳輸服務) 
是Microsoft Windows操作系統中的一個系統組件
CLSID 為 {4991d34b-80a1-4291-83b6-3328366b9097}
https://zh.gov-civil-braga.pt/advantages-disadvantages-windows-10-fast-startup-feature

BITS 服務是system 權限
https://xz.aliyun.com/t/7935
程序員和系統管理員使用後台智能傳輸服務 (BITS)從 HTTP Web 服務器和 SMB 文件共享中下載或上傳文件。關鍵是BITS實現了IMarshal接口並允許代理聲明強制 NTLM 身份驗證。

---
### RPC的驗證模型：

RPC的驗證模型其實是在外部包一層SSP (Security Support Provider)的載入可安全模組來執行的，所有的SSP都是根據一組稱為SSPI (Security Support Provider Interface)的標準API來撰寫而成的，其他廠商也可以根據此標轉來撰寫自己在Windows Server下的SSP，在Windows 2000之後提供了Windows NTLM SSP與Kerberos Version 5 SSP。


| 驗證等級 | 意義 | 
| -------- | -------- |
| (無)     | Text     |
|預設值 | 表示由SSP指定的驗證等級。 |
| 連線 | 驗證只有在第一次連線建立時會發生(這是目前的預設值)。 |
| 呼叫 | 驗證是在每個函式第一次被呼叫時發生。 |
| 封包 | 每個函式，包含每個呼叫的封包都會被驗證 |
| 封包完整性 | 除了封包的驗證等級之外，再加上對每一個收到的封包進行Cryptographic Checksum的檢查。 |
| 封包私密性 | 除了封包完整性的驗證等級外，再加上一些對封包私人的編碼。 |


以上訊息出自:
https://dotblogs.com.tw/gelis/2010/12/07/19954

---


### 角色:

1.dcom (客戶端)

2.中間人 (localhost:6666)

3.rpc 端口135 (服務端)


### 流程圖:
![](https://i.imgur.com/HFBYfHP.png)

potato 會透過 com API 調用指定了 BITS CLSID  {4991d34b-80a1-4291-83b6-3328366b9097}

設定了 127.0.0.1:6666 端口

#### 目的:告訴com 說我要使用 從 127.0.0.1:6666 拿到 BITS 的 對象

```com 
public static void BootstrapComMarshal()
{
IStorage stg = ComUtils.CreateStorage();
 
// Use a known local system service COM server, in this cast BITSv1
Guid clsid = new Guid("4991d34b-80a1-4291-83b6-3328366b9097");
 
TestClass c = new TestClass(stg, String.Format("{0}[{1}]", "127.0.0.1", 6666)); // ip and port
 
MULTI_QI[] qis = new MULTI_QI[1];
 
qis[0].pIID = ComUtils.IID_IUnknownPtr;
qis[0].pItf = null;
qis[0].hr = 0;
 
CoGetInstanceFromIStorage(null, ref clsid, null, CLSCTX.CLSCTX_LOCAL_SERVER, c, 1,       qis);
}
```

中間會交換蠻多包的(我自己也不懂細節)，總之我們只需要知道最後 com 會發出 NTLM 驗證


#### 最終 COM 將嘗試通過發送 NTLM type 1（協商）消息向中間人發起 NTLM 身份驗證


### 中間人拿到 type 1（協商）後 要做兩件任務:

* 任務1
調用函數API AcquireCredentialsHandle 來獲取我們需要的數據結構的句柄。
在調用 AcceptSecurityContext 此函數的輸入將是 NTLM Type 1（協商）消息。輸出將是一條 NTLM Type 2（質詢）消息


![](https://i.imgur.com/OKr9n4y.png)


* 任務2
轉發type 1 到 rpc 135 讓他返回一個  NTLM Type 2（質詢）消息




### 中間人會拿到兩個 type 2（質詢）消息 

* 任務1 是為了使用 NTLM 驗證 正確使用 AcceptSecurityContext 
* 任務2 是一開始com 就是用RPC 發出的type 1 理所當然 com 也期望收到 rpc 返回的 type 2



### 中間人會拿到兩個 type 2 後修改一下再轉給 com


![](https://i.imgur.com/TCfnNDM.png)

左邊為 rpc 135 的 type 2 包，我們用這個包的架構，在修改一下
NTLM Server Challenge”及其下方的字段“Reserved”值，變成右邊的包

這個修改的內容來自於  AcceptSecurityContext 輸出。



### 為啥要這樣做? 原因是 任務2 的 AcceptSecurityContext 

“Reserved”字段實際上是對一個SecHandle的引用，當SYSTEM賬號收到NTLM Type 2消息後，會在內存中進行後台認證。

“Challenge”和“Reserved”字段與“AcceptSecurityContext”的輸出相匹配代表驗證成功。

如果是用原本的 "Challenge"和"Reserved" 他會跑去 rpc 135 驗證



完成後，COM 代表 SYSTEM 帳戶將向我們發回 NTLM type 3（身份驗證）數據包。
但實際上是空的（因為這裡所有的實際身份驗證都發生在內存中），總之需要用他調用AcceptSecurityContext，最後返回的結果在調用ImpersonationToken 获得一个模拟令牌

### AcceptSecurityCoNtext 函數
https://learn.microsoft.com/zh-tw/windows/win32/secauthn/acceptsecuritycontext--general


返回值:SEC_E_OK
代表:如果函式產生輸出權杖，則必須將它傳送至用戶端進程。



### 調用  ImpersonationToken
模擬令牌（Impersonation Token）：在默認的情況下，當線程被開啟的時候，所在進程的主令牌會自動附加到當前線程上，作為線程的安全上下文。而線程可以運行在另一個非主令牌的訪問令牌下執行，而這個令牌被稱為模擬令牌。而指定線程的模擬令牌的過程被稱為模擬


###  ImpersonationToken 這塊我也不懂，只能先挖坑了。

屬於 windows token 之類的領域
介紹:
https://cloud.tencent.com/developer/article/1021371#:~:text=%E6%A8%A1%E6%8B%9F%E4%BB%A4%E7%89%8C%EF%BC%88Impersonation%20Token,%E8%BF%87%E7%A8%8B%E8%A2%AB%E7%A7%B0%E4%B8%BA%E6%A8%A1%E6%8B%9F%E3%80%82




總之這篇粗淺的簡介，可以幫助我快速的理解，因為這塊領域我沒有真正的了解


### 最後原作者堤到:
果我們想模擬令牌，我們最好以具有 SeImpersonate 權限（或同等權限）的帳戶身份運行。幸運的是，這包括 Windows 中的許多服務帳戶，滲透測試人員通常最終以這些帳戶運行。例如，IIS 和 SQL Server 帳戶。





### Lonely Potato
是Rotten Potato的改編，不依賴meterpreter和Decoder做的“incognito”模塊。

Lonely Potato 已被棄用，有跡象表明要移至Juicy Potato。










### 參考:

https://jlajara.gitlab.io/Potatoes_Windows_Privesc

https://decoder.cloud/2017/12/23/the-lonely-potato/

https://cn-sec.com/archives/659470.html

http://moonflower.fun/index.php/2022/05/01/329/

https://www.freebuf.com/articles/web/249782.html