文講解了如何解決使用Access開發的過程中，數據庫文件的各種異常及損壞問題。

望聞問切：了解并收集問題現象。

大約是為了和 Office 其它組件統一，Access 有一個特色：它把所有對象和數據都放在同一個文件中。而不像其它開發工具，每個模塊都是一個或多個文件。

因此當我們使用 Access 進行開發時，不可避免會對同一數據庫文件進行反復修改。

但修改的次數一多，就會出現各種奇奇怪怪的問題。比如下面這些：

注意！這些只是我當前能收集到的一些具有代表性的問題，而不是前面所說的奇奇怪怪的問題的全部！

當遇到這些讓你摸不著頭的對話框時，實際上是 Access 在向你傳達了一個不幸的消息：很遺憾，你的數據庫文件出現了異常或損壞，Access 無法正常進行工作。

辨證施治：找出問題發生的原因和解決辦法。

Access 數據庫出現問題，最簡單的辦法自然就是壓縮修復了，但如果是出現前面所講的問題，壓縮修復基本不能解決問題。實際上仔細觀察上面的錯誤信息，可以粗略得出一個規律：都和修改 VBA 代碼有關。

實際上對于數據對象（主要是表）的損壞，壓縮修復是很有用的手段。但對于作為客戶端使用的數據庫文件，絕大多數奇奇怪怪的問題都是由于編譯狀態異常造成的，而不少初學者寫代碼不夠仔細 ，會有一個不太好的習慣：過度依賴編譯功能來排錯。而過于頻繁地進行編譯，就會造成編譯異常不斷積累（VBA的編譯器比較爛的）。

那么有什么辦法可以消除編譯狀態異常呢？這就要用到一個 Access 的命令行開關：

/decompile

最常規的用法是，按 Win+R 組合鍵，打開運行對話框，然后輸入以下包含 /decompile 開關的命令行并回車運行：

msaccess "D:\測試\Main.mdb" /decompile

注意中間的文件路徑名，要改成你實際的文件路徑名。

療效跟蹤：為什么仍然不能修復已損壞的數據庫文件？

實際上 Access 數據庫文件的損壞，就和人生病一樣，根據病癥的的輕重程度不同，同樣的治療方法療效也不一樣。病情輕微時，可以很容易治好。而隨著病情加重，就越來越難以治好了。到最后可能就變成了：癌癥晚期，治不了，準備后事吧！

如果出現本文開頭那些錯誤信息，說明文件損壞已經挺嚴重了！

所以，解決 Access 由于編譯異常而造成的損壞，也和治病的思路一樣：預防為主，治療為輔。

但這里有一個問題，由于 Access 的單文件特性，在出現明顯的錯誤之前，我們不知道是否存在編譯異常及文件損壞；即使出現了明顯的錯誤，有時候往往也無法判斷究竟是哪個或哪幾個對象的有問題。正如很多癌癥早期沒有任何癥狀，很難發現，當發現明顯癥狀時已經是晚期了。

因此，最正確的用法是：不能把反編譯當成一個出現問題之后的治療手段，而是當成一個日常養生保健手段。

當然事無絕對，在 Access 中，我們也不是完全沒有半點檢查手段。這里有一個檢測窗體（或其它對象）是否損壞的方法：

一般來說，越復雜的對象，越容易出問題。因此在 Access 中，最容易損壞的多半是比較復雜的窗體。

我們可以先用 SaveAsText 方法將窗體另存為文本文件，再用 LoadFromText 方法將文件文件加載為窗體（自動替換已有窗體）。這2個步驟任何一個無法完成，就說明這個窗體有異常或損壞。

當然這個操作要一個一個窗體進行處理，就很繁瑣，最好是要自己寫一個循環代碼來處理。

如果你使用盟威軟件快速開發平臺，那么可以打開 SysFrm_DevTool_ObjectRepair 窗體，這個是現成工具的，并且是開源的，直接使用即可。

優化改進：怎么簡單方便地使用反編譯命令行？

現在我們知道反編譯命令的好處，也知道了應該經常性地使用它。但每次都要打開“運行”對話框，然后輸入命令行，再回車打開文件，感覺好麻煩啊！怎么辦？

這里本公子教大家一個進行反編譯最簡單的方法：使用VBS腳本來執行命令行。

假設數據庫文件名是 Main.mdb，新建一個文本文件，然后將其重命名為“反編譯打開Main.vbs”，右鍵點擊然后在快捷菜單中選擇“編輯”菜單項，用記事本打開它，打開后輸入以下代碼：

strName="Main.mdb"

strPath=CreateObject("Scripting.FileSystemObject").GetFolder(".").Path & "\"

CreateObject("WScript.Shell").Run "MSACCESS """ & strPath & strName & """ /decompile"

然后我們每次打開 Main.mdb 的時候，不再直接雙擊Main.mdb 來打開，而是改為雙擊這個“反編譯打開Main.vbs”的腳本文件來打開。

這樣沒有增加任何額外操作！是不是方便多了？

注意事項：只是為了提醒你們不要馬虎！

1. 腳本中使用了相對路徑，因此 vbs 腳本文件必須和 Access 數據庫文件放在同一文件夾中。

2. 腳本中第1行代碼指定的文件名，必須和要打開的數據庫文件名相同。

復盤總結：前事不忘，后事之師。

解決 Access 的各種異常及損壞，其實無非就是三板斧，別無它法：

1. 反編譯；

2. 壓縮修復；

3. 導出所有對象到空的新建數據庫文件中。

但這些就像是武術中的基本招式，運用之妙，存乎一心！水平的體現，就是看你能不能把基本招式玩出花來。

反編譯主要用于解決非數據異常損壞問題。

壓縮修復主要用于解決數據異常損壞，當然非數據問題最好也壓縮修復一下。

如果用了前面兩招，仍然有問題，那么就用導出所有對象到空的新建數據庫文件中這一招。

最后的最后，再次強調一句：多備份！多備份！多備份！

者：WisFree

預估稿費：200RMB

投稿方式：發送郵件至linwei#360.cn，或登陸網頁版在線投稿

在這篇文章中，我們將給大家演示攻擊者如何利用惡意HTML應用程序（HTA）[1]文件來繞過傳統的代理過濾。除此之外，我們還會告訴大家一些相應的防御措施來抵御這種類型的攻擊技術。

背景知識

我們在幫助客戶進行紅隊安全測試的過程中，我們通常會嘗試使用惡意Payload來獲取代碼執行權限，因為這種方式與現實生活中攻擊者所采用的方式是一樣的。

隨著網絡安全防御技術的不斷發展與提升，再加上廠商越來越注重安全防御端產品的研發了，導致攻擊者不得不去尋找更加新穎的攻擊技術來在他們的目標主機中執行惡意代碼。在此之前，很多攻擊者都是通過使用惡意Java Applets以及Adobe Flash漏洞來執行惡意代碼，但這種方式現在已經有些過時了，因為目前絕大多數的瀏覽器都采用了“點擊播放”功能，有些甚至還完全移除了對上述這兩種功能的支持[2]以防止其被攻擊者濫用。

除此之外，用戶現在還可以通過組策略[3]來屏蔽Office宏，而這也是過去攻擊者及其依賴的一種攻擊向量。對象連接與嵌入（OLE）同樣也是一種在過去非常流行的攻擊向量，它允許攻擊者在一份Office文檔中嵌入惡意的可執行內容，不過可能是因為這種技術以前使用得過于頻繁了，所以現在很多安全防護產品都提供了緩解方案以專門針對這種基于宏文件的安全威脅。微軟公司隨后也很快意識到了這些問題，并對Office文檔中可嵌入的文件類型進行了嚴格的限制[4]，他們也希望通過這種方式來進一步降低Office的攻擊面。

在了解到上述這些內容之后，那么當大家聽到IE瀏覽器（Internet Explorer）或Edge瀏覽器目前仍然支持HTA（HTML應用程序）文件時，想必大家也不會感到驚訝了吧？這是一種非常古老的攻擊技術了，但目前仍然有攻擊者會使用這種方式來進行攻擊。

近期安全研究人員發現，Hancitor惡意郵件活動背后的攻擊者就在他們的攻擊鏈中使用了這種惡意HTA文件，而這些惡意HTA文件會在目標用戶的計算機中注入能夠用戶盜竊密碼的惡意軟件。除此之外，HTA文件還可以被當做漏洞CVE-2017-0199[5]（該漏洞影響范圍同樣非常大）的利用向量來使用。

你也已經看到了，無論是安全廠商還是微軟公司目前都將注意力放在了惡意Office宏以及OLE嵌入的問題上了，但你可能會問：為什么HTA文件目前仍然還是我們的威脅呢？答案就是：雖然這種HTA文件已經存在了有很長一段時間了，但是隨著網絡攻擊技術的不斷發展，這些HTA文件被用于網絡攻擊的情況也是廠商和第三方最近才發現的。因此HTA文件目前仍然是可以正常工作的，而攻擊者只需要找到阻力最小的攻擊途徑，就能夠輕松地完成攻擊任務，這對惡意攻擊者來說絕對是一個福音。

HTA文件是什么？

一般來說，HTA（HTML應用程序）文件是由HTML代碼和類似JScript或VBScript這樣的腳本代碼組成的，我們也可以直接將其理解成普通的Web頁面。但與Web頁面不同的是，HTA文件不僅能夠以完全受信任的模式運行，而且還能夠訪問普通Web頁面所不能訪問的功能和權限，例如ActiveX控制（通常會被標記為‘不安全’）等等。

這也就意味著，如果一名攻擊者能夠通過一個惡意頁面來提交一個HTA文件，并想辦法誘使用戶點擊該文件，那么攻擊者就可以在目標用戶的計算機中執行惡意代碼了。而且值得注意的是，整個攻擊過程完全不需要利用任何的漏洞或繞過任何的安全防御措施。

攻擊實現

從攻擊者的角度來看，能夠阻攔你的Payload順利抵達目標主機的東西一般來說就是類似Web內容檢測代理或URL掃描‘沙盒’之類的安全防護產品。這些安全產品會一直關注和掃描所有的可執行內容，例如通過用戶瀏覽器所下載的可執行文件或腳本，一旦發現了可疑對象，安全產品便會立刻屏蔽這些內容。某些安全產品還會采用沙盒分析環境，這也就意味著你的惡意內容將會被安全產品下載并在虛擬機環境中運行，而這些文件的惡意活動都會被暴露在‘聚光燈’之下。因此，這些客戶端的安全防護機制就是攻擊者需要想辦法解決的對象。

綜上所述，為了解決目前面臨的困難，我們創建了Demiguise【下載地址】，一款專門針對HTA文件的加密工具。

我們近期曾為一名客戶進行了紅隊安全測試，這名客戶的環境中部署了各種安全專家所建議采用的安全控制措施，并且還部署了沙盒以及內容檢測Web代理。這也就意味著，我們需要想辦法繞過Web代理（防止惡意可執行內容被屏蔽），并將我們的惡意HTA文件發送給用戶。當然了，理想情況下我們也不希望這些HTA文件在沙盒環境下被執行。

Demiguise可以創建一個HTML文件，該文件中會包含加密版本的HTA Payload（你提供的HTA文件）。這也就意味著，文件內容將會作為一個單獨的HTTP請求（內容類型為html/text）發送，這也是代理非常樂意看到的東西。當HTML內容呈現在目標用戶的瀏覽器中時，嵌入其中的JavaScript將會被拆包，并在調用msSaveBlob[6]（它可以直接通過用戶的瀏覽器下載未拆包的文件）之前解密HTA內容。

接下來，系統將會提示用戶運行HTA文件（提示兩次），如果他們兩次都點擊了‘同意’，那么HTA文件將會成功運行。

環境控制

為了提升攻擊的效果，并避免被沙盒產品檢測到，該工具還支持‘環境密鑰’的概念。

這種概念的原理為：我們不會將Payload加密密鑰直接硬編碼進HTML源代碼中，而是嘗試從用戶當前所在環境中的某個對象那里獲取密鑰。這種對象應該是某種我們能夠通過JavaScript腳本來區分不同用戶主機的東西，并且這個東西在其他地方將不會起效,比如說用戶簽名。一種比較好的方法就是通過JavaScript腳本在目標所在網絡中找到某種只能夠在該網絡中解析的對象，例如內網托管的鏡像文件、或目標用戶的外網IP地址。

至于如何去選取‘環境密鑰’，我們在本文中就不做深入探討了，這個就留給攻擊者自己去考慮吧！不過我可以給大家推薦兩款非常有用的工具- BeEF[7]【下載地址】和WebFEET[8]【下載地址】，它們可以幫助你對用戶的環境進行指紋提取，你可以在測試之前完成指紋提取活動。

下面給出的是Demiguise的使用樣例[9]：

防御措施

由于攻擊者可以對代碼進行混淆處理，所以想要對這種攻擊技術進行識別會有一定的困難，因此最佳的防御方按就是完全屏蔽HTA文件的執行了。我們可以通過使用軟件限制策略（SPR[10]）或Device Guard來完成屏蔽HTA文件執行的操作。

另一種比較簡單的方法就是修改.hta文件的文件處理程序，將系統默認的.hta文件打開方式修改為類似notepad.exe之類的程序，這樣也可以緩解惡意HTA文件所帶來的影響。

參考資料

[1] https://msdn.microsoft.com/en-us/library/ms536471(VS.85).aspx

[2] https://blog.chromium.org/2017/07/so-long-and-thanks-for-all-flash.html?m=1

[3] https://blogs.technet.microsoft.com/mmpc/2016/03/22/new-feature-in-office-2016-can-block-macros-and-help-prevent-infection/

[4] https://twitter.com/enigma0x3/status/888443907595526144

[5] https://www.fireeye.com/blog/threat-research/2017/04/cve-2017-0199-hta-handler.html

[6] https://msdn.microsoft.com/en-us/library/hh779016(v=vs.85).aspx

[7] https://github.com/beefproject/beef

[8] https://github.com/nccgroup/WebFEET

[9] https://github.com/nccgroup/demiguise

[10] https://technet.microsoft.com/en-gb/library/bb457006.aspx

[11] https://docs.microsoft.com/en-us/sccm/protect/deploy-use/use-device-guard-with-configuration-manager

：概述

通過plink SSH 做Windows IE proxy 數據轉發。

二：腳本

strMachines="127.0.0.1:9988"
aMachines=split(strMachines, ";")
For Each machine2 in aMachines
machinearr=split(machine2, ":")
machine=machinearr(0)
Set objPing=GetObject("winmgmts:{impersonationLevel=impersonate}")._
ExecQuery("select * from Win32_PingStatus where address='"_
& machine & "'")
Set objwss=WScript.CreateObject("WScript.Shell") 
For Each objStatus in objPing
If IsNull(objStatus.StatusCode) or objStatus.StatusCode<>0 Then
WScript.Echo(machine2 & " is not reachable")
else
WScript.Echo(machine2 & " is OK")
if confirm("設置代理為"& machine2 &"？") then
msgbox SetIEProxy(1,machine2)
end if
End If
Next
Next
function confirm(s)
confirm=(msgbox(s,vbYesNo,s)=6)
end function
Function SetIEProxy(ProxyEnable,ProxyIP)
On Error Resume Next
Const HKEY_CURRENT_USER=&H80000001
strComputer="."
Set objReg=GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}\\" & strComputer & _
"\root\default:StdRegProv")
strKeyPath="Software\Microsoft\Windows\CurrentVersion\Internet Settings\"
strEntryName="ProxyEnable"
dwvalue=ProxyEnable
objReg.SetDWORDValue HKEY_CURRENT_USER, strKeyPath, strEntryName,dwValue
strEntryName="ProxyServer"
dwvalue=ProxyIP
objReg.SetStringValue HKEY_CURRENT_USER, strKeyPath, strEntryName,dwValue
If Err=0 Then
SetIEProxy=True
Else
SetIEProxy=False
End If
End Function
objwss.RUN "plink 111.230.10.80 -P 50332 -l guige -pw zhangXXX -L 9988:111.230.10.80:9988"

三：執行結果

四：分享