文讲解了如何解决使用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"

三：执行结果

四：分享