這篇文章是來自SEC Consult Vulnerability Lab的
ReneFreingruber (@ReneFreingruber)，分享了過去幾年從各種博客文章中收集的或者是他自己發現的文件系統技巧，這些技巧不可以直接被利用。但是它們會在特殊情況下間接地產生可以被攻擊者利用的漏洞。
請注意，這篇文章只說明有關於如何利用這些問題以及影響的信息(沒有關於Windows API的技術底層細節)，因為這樣會超出本篇文章的技術範圍。
第一個文件系統技巧(技巧1 - CVE-2018-1036)被微軟修補了，其他技巧還有沒有安全補丁。
技巧1：創建沒有權限的文件夾(CVE-2018-1036/NTFS EOP)
在Windows上，可以為文件夾分配「特殊權限」，例如允許用戶在文件夾中創建文件但不允許創建文件夾的權限。
此類文件夾的一個示例是C:\Windows\Tasks\，用戶可以在其中創建文件，但不允許創建文件夾：
圖1：Windows10，Win7界面不一樣。示例為Windows10
而管理員或程序可能會配置這樣的權限，並假設用戶不允許在其中創建文件夾。
這個ACL策略可以在用戶創建文件時被繞過。如果在文件名的末尾添加「::$INDEX_ALLOCATION」將創建一個文件夾而不是一個文件。Windows當前不包含對該類情況的檢查。
圖2：創建test文件夾
如上圖所示，已成功創建了一個文件夾，用戶可以在這個文件夾中創建任意的文件或文件夾（如果管理員/程序認為缺少權限而無法執行創建文件夾的操作，這個技巧可能會導致特權提升 ）。
附註：如果應用程式只允許刪除文件，:: $ INDEX_ALLOCATION技巧也可用於刪除文件夾。
譯者註：使用以下命令即可刪除文件夾。
rd test::$INDEX_ALLOCATION
你可能想知道為什麼上面的方法有效。
<文件名>:<數據流名稱>:<類型>
如果我們創建一個名為test的文件。它將在內部存儲為test.test::$DATA，因為數據流名為空，且$DATA是默認類型。第一個技巧的原理是將數據流類型更改為INDEX_ALLOCATION，而INDEX_ALLOCATION對應於文件夾類型，所以創建了一個文件夾。
但是，也可以將數據存儲在不同的流中。(這就是所謂的Alternate Data Stream – ADS)。如果我們寫的例子是「test.txt」，我們在實際寫入的是「test.txt::$DATA」(數據流名稱為空)。我們也可以寫入「test.txt:foo」 或「test.txt:foo:$DATA」（兩者都相同，因為$DATA是默認類型）。
也可以使用不同的流名稱用於存儲文件的信息。如果你從網際網路下載文件(或通過電子郵件接收)，Windows系統會通過流名稱悄悄地添加區域標識符（如果你想執行會顯示出一個附加的警告對話框）例如，如果我們下載「putty.exe」，Windows也會創建「putty.exe:Zone.Identifier:$DATA」。使用dir /r命令可以看到這些流名稱：
圖3：將zone.identifier放到putty.exe中，然後嘗試讀取出來。
正如我們所看到的，帶有數據流的文件是不能通過type命令直接讀取的(使用更多的命令就可以了)，如果我們使用notepad讀取文件，那麼可以忽略冒號最末尾的$DATA類型。我們還可以把重要的信息(包括應用程式!)在ADS中存儲。例如putty.exe就可以複製到ADS中，然後通過wmic調用(不可以用start直接調用)：
圖4：運行test:Putty.exe
附註:本文撰寫於2018-03-01，並報告給微軟。與此同時，微軟的Windows Defender被更新以檢測WMIC進程調用。
你可能會問為什麼有人會這樣做?首先，ADS可以用來隱藏數據（dir沒有使用/r開關不會顯示文件中的ADS;explorer.exe也不會顯示ADS;稍後介紹如何能夠隱藏dir /r開關的內容…）而ADS還有一個很好的特性——我們可以在文件夾中添加ADS。這樣做的前提是在文件夾裡擁有「創建文件夾」的權限(而且文件夾名稱不能是數字)。這樣做可以使文件夾上的ADS看起來像是來自父文件夾的文件!
在Windows上一個普通用戶無法在C:\Windows創建文件(只有管理員可以寫這個文件夾)。因為只有管理員可以創建這些文件,所以應用有可能認為文件在C:\Windows\是可以受信任的。可是普通用戶在C:\Windows\Tracing文件夾中是可以創建文件和文件夾的，因此普通用戶可以創建一個ADS在這個文件夾中。
假設用戶寫入文件C:\Windows\Tracing:test.dll。如果這個路徑現在被傳遞給一個遍歷文件夾的Windows API，這個API將從路徑的末尾開始，直到找到第一個「\」。將「\」中剩下的所有內容作為文件夾返回。而C:\Windows\Tracing:test.dll 將返回C:\Windows\作為文件夾。正如前面提到的,一個普通用戶不允許使用這個技巧創建文件在Windows文件夾。但是我們可以通過這個方法創建了一個文件，而且是存儲在C:\ Windows文件夾內 !
這裡是不同Windows函數遍歷文件夾的輸出(我們可以看到它總是C:\ Windows):
圖5：遍歷文件夾
注:上述存儲dll可以開始與Windows內置的control.exe應用程式啟動，命令為：
control.exe C:\Windows\tracing:foobar.dll
此行為可用於繞過某些應用程式白名單解決方案，也可以在各種情況下繞過安全檢查。例如程式設計師認為檢查文件是否存儲在特定的文件文件夾中就足夠了並且假設當管理員通過設置ACL後寫入這個文件夾。
考慮應用程式允許上傳數據，上傳的數據存儲在applicationFolder \ uploadedData \中。而應用程式允許從applicationFolder\啟動腳本/應用程式，而不允許從applicationFolder \uploadedData(使用黑名單方法)啟動腳本/應用程式。如果用戶上傳一個名為「:foo.ps1」的文件，系統將創建一個類似於applicationFolder\uploadedData:foo.ps1的ADS。此文件似乎存儲在applicationFolder\中，因此繞過安全檢查。
另一個有趣的事情是ADS可以包含通常文件名禁止使用的「或*符號(必須使用本機Windows API創建這些文件;cmd.exe會過濾這些字符):
圖6：特殊符號
這本身就可能導致幾個問題。（例如，如果文件名以「開頭和路徑被」包圍結尾，正如James Forshaw在他的博客中提到的方法;請參見參考資料部分）。另一個有趣的攻擊向量可以是XSS(或命令注入)。假設一個網站在IIS上運行並允許上傳文件，並且很容易出現CSRF。上傳文件後，將顯示包含文件名的成功對話框。如果文件名未被處理，這可能會導致XSS，但是如果文件名不允許包含像<或>之類的符號(因此我們不能用它來執行JavaScript代碼)。如果允許ADS文件包含這些符號，那麼攻擊者可以嘗試使用ADS文件名發送上傳請求：
圖7：ADS的XSS利用
每個文件夾都包含默認的兩個特殊條目，也就是指當前文件夾「.」文件夾和指向父文件夾（父目錄）「..」文件夾。在Windows上不能用名稱中的點創建文件/文件夾，最有可能防止將解析器與點混淆的攻擊。
圖8：創建...文件夾測試
上面的截圖顯示,不能創建一個「…」或「....」的文件夾。但是可以使用上面提到的:$INDEX_ALLOCATION技巧來繞過:
圖9：ADS創建....文件夾
「…」文件夾是用上面提到的技巧創建的，但是這樣的文件夾也可以將名稱傳遞兩次來創建，如「…」示例中所示。(mkdir 「....\ ....\「 創建文件夾」....」,但裡面還有一個文件夾「….」。僅僅通過mkdir 」....\xyz\「不起作用。)。
使用第二個技巧，我們還可以輸入這些文件夾，在那裡存儲文件，甚至從這個位置執行程序:
圖10：向...文件夾寫入文件的方法
如圖所示，無法僅使用名稱進入文件夾(例如:「cd …」或「cd …\」或「cd …\…」不起作用)，必須使用「cd …\…\」的語法。進入文件夾之後可以在這個文件夾裡創建文件。(有趣的是:如果你在這個文件夾裡輸入「cd .」，你又會回到這個文件夾，因為路徑是混亂的)。
此外，也不可能從GUI (explorer.exe)打開這個文件夾。我遇到了兩種不同的情況。在某些情況下，雙擊這樣的文件夾沒有影響(保持在當前文件夾中，路徑保持不變)，在其他情況下，我們將保持在文件夾中，但是資源管理器中的路徑發生了更改。例如，在「打開」文件夾17次之後(注意路徑中的「…」 ):
圖11：...文件夾顯示在地址欄的情況
可以嘗試根據需要隨時進入該文件夾 ，可無法在GUI中的文件夾中看到這些文件 。也無法通過在上圖中的路徑輸入欄位傳遞「C:\test\…\…\」來打開文件夾。
(附註:如果試圖從GUI中刪除該文件夾，explorer.exe會崩潰;我們將看到一個對話框，其中Windows正在計算文件夾中的文件以及它所在的位置「很多文件」 ；不要在工作系統上試試這個... )
通過GUI (explorer.exe)搜索這個文件夾中的文件也不起作用，例如GUI搜索「123.txt」文件，圖形用戶界面實際上是被掛起/搜索，而不會查找文件 。
請注意， 通過cmd進行搜索是沒有問題的：
圖12：命令行下搜索文件
但是大多數人現在都使用Powershell，而使用Powershell又找不到這個文件，因為它會陷入無限循環:
圖13：Powershell搜索
(輸出被截斷，因為命令總是循環列印這兩個文件夾...)
搜索「123.txt」(例如「Get-ChildItem -Path C:\test -Filter 123.txt -Recurse -ErrorAction SilentlyContinue -Force」)將永遠不會找到該文件(並且永遠不會結束)。
我還用不同的AntiVirus產品進行了測試，這些產品似乎都可以正常工作(我將惡意軟體樣本放在這個...的特殊文件夾中，經過測試AntiVirus產品可以找到它們)。有些人仍然對這條路徑感到困惑，例如在「C:\test\…\」中搜索病毒時，他們會在「C:\test\」中搜索。使用os.walk()的python代碼似乎也能正常工作。
請注意，只是創建一個目錄連接指向它自己的父文件夾不會在cmd或Powershell中導致無限循環 。
目錄連接是一個非常有用的NTFS功能，可以為攻擊者找到安全漏洞。使用它可以創建(使用普通用戶權限)到目標文件夾的符號連結。
解釋目錄連接的最佳安全漏洞是AVGater，攻擊者將一個文件放在x文件夾中，然後將該文件標記為病毒，並且已安裝的AntiVirus解決方案將其移至隔離區。之後攻擊者刪除文件夾x，並用一個名為「x」的目錄連接替換它，該連接指向C:\windows\System32\。如果攻擊者現在單擊「恢復」按鈕，AntiVirus解決方案會將把文件複製到x文件夾，該文件夾現在指向具有SYSTEM權限的system32(直接導致EoP)。
如果目標應用程式包含競爭條件類型漏洞(TOCTOU漏洞——檢查使用時間)，則目錄連接會被濫用。
使用mklink實用程序和/J參數創建一個目錄連接。可以將它與::$INDEX_ALLOCATION技巧結合使用，創建一個名為「…」的目錄連接:
圖14：創建目錄連接
第一個目錄連接「test1」是用一個普通的名稱創建的，因此目標在「dir」輸出中被正確地顯示。但是，在「…」目錄連接的情況下，不再顯示目標(而是顯示[…];見紅框)。還請注意，你可以讓連接點1指向連接點2，指向連接點3，以此類推，直到最後一個指向真正的目的地。
由於路徑混淆，您可以使用上面提到的「cd…\…\」技巧(在system32文件夾中)進入結點，但 「.」會指向「C:\test8」:
圖15：在...目錄執行dir命令
dir命令從system32文件夾列印文件（紅色標記請注意，第一個命令在C:\test8\創建了hello.bat文件）
圖16：執行hello.bat結果
紅色標記的文件是system32文件夾中的最後一個文件(dir命令的最後一個輸出)。在藍色中我們可以看到執行的是當前目錄 (「.\」)中的「hello.bat」 ，由於路徑混淆，執行了C:\test8\hello.bat (綠色方塊)而不是C:\windows\system32\hello.bat。我不確定這是否對安全性產生直接影響。因為我們可以在任何文件夾中啟動文件。但是它可能會被用來繞過應用程式使用白名單腳本文件的白名單解決方案。
如前所述，可以通過dir命令中的/r開關查看ADS。而streams.exe是Sysinternals裡的一個工具，它也可以查看數據流：
圖17：streams.exe查看ADS
在舊版本的Windows中，可以使用保留名作為基本名稱來隱藏ADS (例如: CON, NUL, COM1, COM2, LPT1, …)。而在Windows 10上就做不到了，但「…」仍然有效：
圖18：測試保留名隱藏ADS
「…」上的ADS是成功創建的，但是沒有被streams.exe工具列出。在COM1上創建ADS會導致錯誤，在NUL上創建ADS沒有任何提示(ADS沒被創建)。
請注意，還可以在驅動器上創建一個ADS，比如「echo 123 > C:\:abc.txt」。將隱藏在C:\ 中的「dir /r」 命令中。但是，它將在「..」目錄的C：\子文件夾中顯示ADS。例如：
圖19：在C:創建ADS的效果
紅色標記的部分ADS是由 C:\:abc.txt 創建。如果直接在C:\上調用 ,那麼通過Sysinternals工具流也看到ADS。因此，為了避開這兩種工具，應該使用「…」技巧。
所以還存在可用於隱藏工具的第二技巧。在Windows上可以添加「.<空格>.」在文件的末尾，Windows將會自動刪除它(規範化將其刪除)。
圖20：添加...的技巧，echo 123 > "abc. ."
但是我們可以用ADS創建這樣的文件！用工具不能打開這個文件，因為像「xyz. .」這樣的路徑會自動地更改為「xyz」，而這個文件不存在。
這是證明：
圖21：「xyz. .」文件被創建
創建的ADS foobar.txt通過工具是無法找到的：
圖22：foobar.txt
附註1：此類文件也可以通過以下方式創建： echo test > 「test. .::$DATA」
附註2：請注意「..:abc.txt」是在「C:\:abc.txt」上創建的ADS。
我們還可以創建一個名為「. .」 的目錄，如下所示：
圖23：創建一個名為「. .」 的目錄
這個文件夾是不可以進入的：
圖24：不可以進入名為「. .」 的目錄
前面提到過(像cd . .. .\ 無法正常使用)，但是cd 「. .::$INDEX_ALLOCATION」 是可以使用的(雙引號很重要)。
如果我們可以在文件夾名之間添加空格，那我們也可以在末尾添加空格，如 「b 」 或「.. 」 或「. 「。
圖25：文件夾末尾添加空格
說明:有一個「b」和一個「b 」文件夾，一個名為「a」的文件，一個名為「a 」的文件，兩個默認的目錄「.」和「..」和「. 」和「. .」。
名稱為「.. 」的目錄可以使用我們已經討論過的技術進行寫入文件：
圖26：寫入文件到「. . 」目錄中
附註1：如果在文件夾上單擊兩次，可以通過文件管理器打開該文件夾。也會正確顯示文件夾的內容。但是由於路徑錯誤，無法打開其中的文件（explorer.exe 使用 C:\test22.. .. \123.txt 而不是 C:\test22.. \123.txt）。在搜索這樣的文件夾時，Powershell將再次陷入無限循環。
附註2：還可以在一個名為「abc」的文件夾上創建ADS。然後可以將文件夾重命名為僅包含數字的名稱(如「1」)。之後你仍然可以看到ADS，但是你不能打開它。(用數字作為名稱的文件夾上的ADS不起作用)。要打開ADS數據，必須首先將文件夾重命名為「abc」。
文件系統與反病毒產品/取證軟體：
我快速驗證了上述針對AntiVirus產品的技巧，以驗證它們是否可以捕獲濫用技巧的惡意軟體。最值得關注之處是文件/文件夾以 「. .」結尾產生的變化。例如我將eicar(測試病毒)儲存在一個文件夾中，並用以下命令複製：
copy eicar.com > "123. .::$DATA"
copy eicar.com > tester
echo 123 > "foo. .::INDEX_ALLOCATION"
cd "foo. .::$INDEX_ALLOCATION"
copy ..\eicar.com .
copy ..\eicar.com .\eicar
之後，我重新啟用了AntiVirus解決方案並掃描了該文件夾，所有AntiVirus解決方案都在此文件夾中找到了「eicar.com」和「tester」，而不是「123. .」 中的eicar病毒或「foo. .」 文件夾中的兩個文件。但是進入該文件夾並啟動文件時，AntiVirus產品會找到它們(因為內容是從文件系統加載到內存的)。Windows Defender的「刪除」操作無法刪除文件，因此沒有影響。
但是Emsisoft的「刪除」操作可以刪除文件夾中的tester病毒（譯者註：Emsisoft是來自澳大利亞的殺毒軟體）。Emsisoft刪除了 「foo. .」 文件夾中的 「eicar.com」 文件，「eicar」文件沒有被刪除，內容可以毫無問題地讀取（Emsisoft回應我們，只有映射為可執行文件的文件才會被掃描，有些特定的文件擴展名如.com除外）。這種行為可以在文件保護設置中通過切換到「徹底掃描」來讀取就可以進行查殺；另一方面，Windows Defender也阻止了將「eicar」作為文本文件讀取)。
我還對Autopsy 4.6.0（免費取證軟體）進行了一個簡短的測試。通過將「logical files 」模式加載到工具中（從正在運行的系統;不是一個磁碟映像），可以輸入「…」 文件夾，但是不能輸入「foo. .」 文件夾。我創建了兩個文件，一個命名為「valid」，內容為「valid」，還有一個文件命名為「valid.」，內容為「secret」。Autopsy 顯示了兩個文件的內容「valid」(而不是「secret」的內容)。在「logical files 」模式下雙擊「.. 」文件夾(末尾有空格)後被轉化為「..」 。在磁碟鏡像(raw)模式下，一切都顯示正確(在live模式中，Autopsy使用Windows API訪問數據，才會出現問題。）
技巧6：隱藏進程二進位
正如上面已經討論過的:Windows會在文件的末尾自動刪除「. .」 。如果我們可以以「file1. .」 這樣的名稱來啟動一個進程呢?好吧，那就會在「file1」執行的情況發生檢查(例如:來自AntiVirus產品的籤名檢查)。讓我們試試以下命令:
圖27：複製了三個文件
我們創建了3個文件：
我們現在需要一種方法來從 「file. .」 二進位文件啟動進程，這不是一項簡單的任務，因為所有Microsoft Windows API調用都會自動從文件名中刪除「. .」，然後啟動「file」(taskmgr)。為了解決這個問題，我們使用以下代碼：
圖28：解決自動從文件名中刪除「. .」的代碼
上面的代碼只是調用CreateProcessA來從「filex x」(WinSCP)創建一個進程。如果我們編譯這個應用程式並啟動它，最終將執行的是WinSCP。可我們不能正常啟動這個文件。相反，我們在調試器內啟動應用程式（例如：WinDbg）。現在我們在函數中設置一個斷點，它將產生相關的系統函數調用，調用:「bp ntdll!NtCreateUserProcess」。我們可以使用 「g」 (go) 命令在調試器中啟動程序並命中斷點。在斷點處，可以dump當前堆棧 (「dq rsp」) 。堆棧上的第12個指針很重要，應該被dump。這個地址的第四個值是指向文件名的指針。
圖29：windbg
文件名(綠色框)現在是標準化顯示(以\??\C:\… 開頭)。這種標準化還需要從文件名末尾刪除 「. .」 ——這就是為什麼上面的C代碼不使用「file. .」 作為進程名的原因。但是由於文件已經被改變為標準化，現在可以修改這個值。讓我們用「.」 覆蓋 「x」 字符。(命令「eb」用於編輯字節)：
圖30：編輯字節為"."
然後繼續執行「g」。猜猜會發生什麼?
「file. .」 (惡意軟體)被執行。但如果用戶右鍵單擊任務管理器中的進程並選擇「屬性」，則顯示「file」 (taskmgr) 的Microsoft籤名。
圖31：顯示「file」 (taskmgr) 的Microsoft籤名。
但是「filex x」 （WiSCP）是什麼呢？是的，這個文件也顯示為正在運行的進程，即進程資源管理器(因為路徑是在調用NtCreateUserProcess之前設置的)。
圖32："filex x"運行情況
與PowerShell有什麼關係？是的，也是錯誤的二進位文件：
圖33：Powershell顯示情況
這是不是安全問題得視情況而定。首先，攻擊者可以啟動一個進程(惡意軟體)，重命名/刪除它，然後將一個有效的文件重命名為相同的名稱。在taskmanager和process explorer中也會出現上述效果。但是不同之處在於，使用上述技巧，得在進程啟動的同時發生。
例如，如果在雲中已知二進位哈希，請考慮已經安裝的端點保護檢查每個已啟動的進程。通過此技巧，端點保護可能會使用錯誤的二進位文件來驗證哈希是否為白名單。另外還要注意創建此類進程並不需要調試器，應用程式可以掛鈎 NtCreateUserProcess函數並在鉤子中就可以實現修改。
WINDOWS CMD的技巧：
這些技巧與文件系統技巧沒有任何關係，但是我認為它們很適合這篇博文。在Windows cmd中，可以在命令中的任何位置寫入^符號，CMD將完全忽略掉這個符號。例如,「calc.exe」 和「ca^l^c」效果相同。^是不是最後一個符號不重要，並且兩個^符號在相鄰時無法使用。使用雙引號"隔開就沒有限制了（它可以是最後一個字符或多次使用）。例如，^ca^「^」^lc^「將啟動計算器。
這同樣適用於零長度環境變量。可以通過％name％訪問環境變量。如果環境變量的長度為零，則「cal％name％c」將與「calc」相同。由於環境變量的默認值長度不為零，因此不能直接使用。但是，可以使用特殊語法（:~start,end）在環境變量上調用substring。下圖顯示了「windir」環境變量以及子字符串如何與negativ值一起使用以獲取返回的零長度變量：
圖34：環境變量取字符
下圖顯示了這些技術的組合，以隱藏Powershell在版本2中啟動（這些技巧在之前很有用，但在最新的Windows 10系統上應該是實現不了）：
圖35：運行Powershell技巧
可以看到使用^和環境變量技巧（%os:~0,-56%），還使用版本「00000000002.0000」（而不僅僅是2）並且參數是「?ver 」不是「-ver」（注意，這不是正常的？符號，它是U+2015 ;光使用?不起作用）。
在Windows上除了「\」 也可以把「/」作為路徑使用。例如，C:\Windows/\//\system32\calc.exe 與C:\Windows\system32\calc.exe 相同。 而且還可以通過UNC路徑訪問二進位文件不用 「C:\」模式： \\127.0.0.1\C$\windows\system32\calc.exe。
通常可以使用類似的技巧來突破使用黑名單的方法（例如，如果禁止使用Powershell.exe，則攻擊者可以調用Power^shell.exe來繞過限制。或者如果禁止使用calc，則可以執行：
^"%LOCALAPPDATA:~-3%^%SYSTEMROOT:~0,1%^"
啟動calc.exe等）。
這篇博客文章由RenéFreingruber (@ReneFreingruber) 代表SEC Consult Vulnerability Lab撰寫。James Forshaw(@tiraniddo)將一系列的技術列表文檔化。Alex Inführ (@insertScript) 在他的博客文章中記錄了一些ADS隱藏技巧。有關ADS之前的參考文獻，請參閱以下參考資料部分。
參考文獻：
https://msdn.microsoft.com/en-us/library/dn393272.aspx
https://tyranidslair.blogspot.co.at/2014/05/abusive-directory-syndrome.html
https://tyranidslair.blogspot.co.at/2014/06/addictive-double-quoting-sickness.html
https://googleprojectzero.blogspot.co.at/2016/02/the-definitive-guide-on-win32-to-nt.html
https://googleprojectzero.blogspot.co.at/2015/12/between-rock-and-hard-link.html
https://googleprojectzero.blogspot.co.at/2015/08/windows-10hh-symbolic-link-mitigations.html
http://insert-script.blogspot.co.at/2012/11/hidden-alternative-data-streams.html
https://bogner.sh/2017/11/avgater-getting-local-admin-by-abusing-the-anti-virus-quarantine/
附錄：
譯者註：經過測試Windows XP後微軟就禁止用戶從ADS裡執行程序了。不允許執行，但是寫入，讀出操作都可以。其實只是禁用了OWASP中提到的start命令，文章中用WMIC運行就很巧妙的繞過封堵，測試方法如下（需要使用絕對路徑）。
wmic process call create "C:\ProjectCode\test\test:putty.exe"
文中的zone.identifier是一個文本文件，然後作為數據流存放到了putty.exe裡。ADS並不是一個新的話題了，在翻譯過程中發現國內有許多相關資料寫得都不錯，國人很棒棒。根據目前知識量的儲備在WinDBG調試部分翻譯的詞彙翻譯不夠準確，根據需求請參考原文。
文章來源
1）https://www.sec-consult.com/en/blog/2018/06/pentesters-windows-ntfs-tricks-collection/
2）OWASP alternate_data_stream
3）https://www.owasp.org/index.php/Windows_::DATA_alternate_data_stream
4）一個用ADS（供選數據流）隱藏Windows後門的方法
5）http://www.freebuf.com/articles/73270.html
6）文件流-MSDN說明
7）https://msdn.microsoft.com/en-us/library/dn410405.aspx
8）https://docs.microsoft.com/zh-cn/windows/desktop/FileIO/file-streams
9）Hidden Alternative Data Streams的進階利用技巧
10) http://www.4hou.com/technology/4783.html
本文由看雪論壇 lipss 原創，轉載請註明來自看雪社區