写在最前面，由于篇幅有限、同时不想跑题太远，文章中很多内容没有进一步展开讨论，如果读者感兴趣，可以私聊或者在评论区讨论。

一、背景

ATT&CK攻击矩阵(Enterprise)共有11列，将不同环节、不同打击目标的攻击技术分别拆分并归纳，这对于防守方有很大的借鉴意义，SOC可以将安全设备、防御手段、检测规则、情报等的覆盖能力映射在矩阵中，从而感知当前SOC的检测和防御能力，并规划未来的前进方向。

然而ATT&CK矩阵不是银弹，这里也有很多问题值得思考:

(一)防御和检测能力的矩阵覆盖评估，应该是0和1吗？

(二)针对某个技术环节，当前已经能够完全防御或检测了，未来是否不需要再关注、投入人力了？

(三)针对某个攻击技术，企业不同区域环境(总部和分支、各种供应商、BYOD)是否具有相同的防御和检测能力？

(四)矩阵中的11列，对于防守方的资源投入来说，是否具有相同的重要程度？如果不同，优先顺序是怎么样的？

(五)矩阵每一列中的不同技术、子技术，对于防守方的资源投入来说，是否具有相同的重要程度？如果不同，优先顺序是怎么样的？

本系列文章，笔者将详细分析ATT&CK矩阵的技术，并深入讨论每个技术，以及针对这些技术，企业环境应该做出的防御和检测部署。

本篇文章，让我们进入ATT&CK矩阵的第四列：Execution，详细分析其中的技术有哪些，涉及企业安全工作建设中的哪些内容。

二、技术总体介绍

(一)Command and Scripting Interpreter

命令和脚本解析器，笔者认为，是Execution这个Tactics中的重头戏，无论是成功打点前的钓鱼、欺骗执行，还是Initial Access成功之后的恶意程序执行、持久化、数据外泄等等环节，都少不了对系统命令和脚本解析器的利用。

现在仅仅讨论Execution的利用，通过Windows中的cmd、powershell，Linux中的各种shell都可以完成恶意程序的执行。同时Windows系统中自带了Visual Basic，JScript，Powershell等脚本解析器，使得攻击者有很大的发挥空间，完成脚本混淆、编码、恶意程序下载，绕过基础防御，很多Linux系统中还默认安装了Python、PHP、Ruby、Perl等等强大的脚本解析器，不但可以进行高级的脚本混淆，也有更多的支持库，可以完成更加难以检测和防御的执行动作。

(二)Container Administration Command

利用容器管理员权限完成执行，注意这里利用的是容器管理员这个权限完成执行动作，那么理所当然执行点应该是在容器内，也就是完成容器内的恶意程序执行，具体如何完成呢？可以通过利用拥有容器管理员权限的服务，如Docker daemon、Kubernetes API server，也可以通过修改容器的entrypoint添加恶意程序的执行，或者通过高权限下的docker exec或kubectl exec命令完成执行。

但是利用的前提是在一个部署了容器或者K8S的环境，否则容器管理员权限也无从谈起，所以这里攻击的对象主要是服务器而不是个人终端，相信无论大企业还是小公司，容器化部署服务都是未来的趋势，这里不再赘述。

(三)Deploy Container

部署容器，不同于在已有容器中进行恶意程序的执行，通过已有权限在所处环境中部署新的容器，可以绕过防守者对容器环境的监控，同时可以精心配置"不恰当"的权限，从而完成其他的攻击利用，例如在K8S环境中，可以部署一个权限不当的pod结点，并且挂载node结点的文件系统，从而完成对node结点的攻击。

不要小瞧了这种看似多此一举的攻击方式，笔者在企业环境中进行应急响应时发现，传统的物理机或者虚拟机部署服务遭受攻击时，定位机器、确定漏洞、确定Initial Access时间是相对容易的，同时相关日志(如web应用访问日志、系统登录日志、命令行history等等)的收集工作往往是比较完善的，所以整个攻击的溯源相对容易。但是K8S环境中情况完全不一样，首先pod结点是飘来飘去的，发生攻击和发现攻击时，很有可能已经不在同一个node上，导致定位很困难，另外相关日志的收集通常是缺失的，导致无法有效的对攻击事件进行分析和溯源。

(四)Exploitation for Client Execution

通过客户端软件完成执行，由于B/S架构的盛行，首当其冲的就是浏览器，毕竟相比C/S架构每个软件有自己不同的客户端，B/S架构的服务全都由浏览器提供，虽然使用上简单方便，但是万一浏览器出了什么漏洞，影响面也是巨大的，可以说是一荣俱荣,一损俱损。历史上IE就出过大量漏洞，当让不止是IE，目前市场占有率比较高的Chrome，前两天又爆出了可以任意命令执行的漏洞……

https://www.freebuf.com/news/338299.html

针对客户端软件的利用并不完全是通过漏洞，除了浏览器，还有很多经常被利用的客户端软件，比如office套件，通过word、excel进行钓鱼，也是hw中最喜闻乐见的打点方式，这种钓鱼其实是结合了Command and Scripting Interpreter完成的。

除此之外，ActiveX组件、Adobe Reader、WinRAR、甚至某些EDR软件，也是经常被攻击的客户端软件。

(五)Inter-Process Communication

进程间通信，通过与其他进程、组件的交互、调用，可以完成执行、提权、持久化等等攻击，同时进程间交互不一定是本地的，也可以与远程计算机上的进程进行交互，例如可以使用DCOM在远程机器上执行恶意程序。

(六)Native API

系统原生API，系统原生API提供了更加接近系统底层的函数、功能，例如创建进程、创建线程、开辟内存、写内存地址等。很显然，如果攻击者可以接触到系统API，那么执行自定义的恶意程序就是很容易的事情了，甚至还有在系统安装服务、注入其他进程、检测系统环境、检测调试器活动、监听文件系统操作等等"卑鄙"的手段。

(七)Scheduled Task/Job

通过计划任务执行，当系统配置不当时，例如普通用户权限可以修改管理员的计划任务中的目标可执行程序，可以通过计划任务的执行完成提权。另外攻击者常常通过计划任务的执行完成持久化，msf、empire等等攻击框架中都有现成的模块可以使用。

具体来说，Windows系统可以通过at命令(已废弃)、计划任务程序、powershell提供的cmdlet等方式部署计划任务。Linux系统可以通过Systemd Timers、crontab添加、修改计划任务，K8S环境中也有Container Orchestration Job。

(八)Shared Modules

通过共享模块完成执行，通俗来讲，就是Windows系统可以通过UNC(Universal Naming Convention)加载远程DLL文件，通过路径名加载本地dll文件，完成恶意程序的执行。

那么远程加载DLL文件前，是不是首先要在远程放置一个可以访问得到的恶意DLL文件呢？是的。看上去绕远了，其实不然，看看去年爆出的CVE-2021-1675和CVE-2021-34527，就是在添加打印机驱动时，可以通过高权限加载远程DLL，所以攻击者只要在网络可达处部署SMB服务，并放置恶意DLL，就可以完成攻击。

(九)Software Deployment Tools

通过软件部署工具完成执行，这里的场景是企业环境中存在批量下发软件的运维工具，获取管理端的控制权后，可以向终端下发程序执行。实际上，不一定是专门的软件部署工具，企业环境内，有很多拥有高权限且部署广泛的软件，比如EDR、EPP、DLP，或者一些企业内自研的终端管理软件，都有能力完成攻击。

另外，能够下发命令、管理区域内所有终端、拥有较高的权限，似乎AD域也符合这个特征……

(十)System Services

通过系统服务完成执行，类似于通过计划任务执行，同样可以进行提权和持久化(也可以完成一次性的执行动作)，同样也可以在拥有权限的情况下，远程给其他机器部署恶意服务。

(十一)User Execution

用户执行，没错，这个技术就是骗用户执行，骗用户点击进入某个网页、骗用户双击某个可执行文件、骗用户通过邮件正文中的密码解压加密压缩的邮件附件、骗用户在弹出的窗口点击"确定"按钮、骗用户在word文档中脱离保护视图等等。

虽然看上去都是社会工程学的内容，但实际上骗也是有技术含量的，要尽可能的做到一击必杀(点一下后完全自动化执行)，无感知（中招后没有明显的"不良反应"），轻量级（诱骗信息和日常看到的提示信息类似，事后不容故意回忆起事件的特殊之处）。为了达到这些目的，往往需要利用其他Initial Access和Execution技术，比如通过HTML Smuggling技术完成恶意程序的下载、通过powershell脚本完成恶意程序的执行等等。

(十二)Windows Management Instrumentation

WMI，熟悉域渗透的同学对WMI肯定不陌生，在完成认证的上下文中，可以进行大量的主机信息收集，并可以在本地或者远程进行恶意程序的执行。

另外大名鼎鼎的无文件后门，也是通过WMI的事件订阅完成。

三、归纳和延伸

（一）Execution内容归纳

ATT&CK中Execution的12个技术(Techniques)，整体可以总结为三个类型，其中大多数技术可以归类到"利用已经获取的认证凭据完成执行"，这种攻击技术的特点是已经获取到了某些权限，但因为需要躲避检测、权限提升、横向移动、权限维持、远程利用等等原因，使用了不同的execution手段；第二类是"欺骗用户点击完成执行"，特点是暂时没有获取用户或机器的权限，但是已经完成恶意样本的投递，接下来需要欺骗用户完成点击，并且尽量不留痕迹；第三类是"利用终端客户端漏洞完成执行"，特点是无需接触用户，只要网络单向可达(受害者能访问到攻击者或者攻击者能访问到受害者)，便可以完成攻击，其中可能需要利用到软件漏洞。

那么这些不同类型的攻击技术具体有哪些攻击程序(Procedures)、应该如何防御(Mitigations)、应该如何检测(Detection)呢？接下来我们开始进行详细分析。

（二）攻击技术延伸

1.利用终端漏洞执行

为了利用终端客户端软件的漏洞，首先需要和软件完成"触碰"，而"触碰"无外乎两种方式，一是客户端软件读取到攻击者的恶意输入触发漏洞，二是客户端软件开放服务端口，攻击者访问后实现漏洞利用。

永恒之蓝这个BUG级的"漏洞武器"就属于后者，Windows终端的445端口历史上也不止永恒之蓝这一个大漏洞，只要攻击者想办法进入同网段，就可以"一键"拿下系统。低版本Redis也是类似，默认开启后，开放0.0.0.0:6379，无需认证即可进入，并且"贴心"的提供了系统命令执行的功能，只要在同一网段内，同样是一击必杀。

如果把弱口令也归类为漏洞，那么SSH、RDP、MySQL、Web管理后台等等服务，同样容易被攻陷。

由此就不得不思考一个问题了，通常服务器网段内不同的C段之间的网络通信会通过防火墙策略做限制，仅通过五元组开通必要的策略，那么服务器网段同C段内的网络通信是否也需要通过防火墙策略做限制呢？更应该思考的问题是，办公区机器之间的网络通信是不是也应该进行管控？甚至进一步说，办公区机器之间，是否可以阻断一切网络通信？

服务器之间通常有业务需要的正常网络通信，比如分布式服务的任务下发、数据传输，运维工具的批量执行、Zabbix等监控系统的心跳检查、CI/CD等等。所以服务器区是无法对网络流量一刀切的，另外运营防火墙策略也会有不小的成本，可以考虑微隔离产品：基于历史数据学习出服务器之间的"正常"通信，建立模型检查之后的通信流量，可以对"不正常"的通信进行报警，也可以直接添加主机防火墙策略，阻断"不正常"的通信。

办公区机器之间是否有必要建立网络连接呢？取决于具体的企业环境，但笔者认为，总的来说是不需要的。如果实在有必要，也可以为有特殊的需求的机器搭建网络代理、网关，通过二次认证或白名单等方式实现安全性。

扯得有点远了，网络限制并不能完全防御或者检测Exploitation for Client Execution，要做的还有很多，比如权限控制、保证默认配置的安全性、通过UEBA检测异常流量、检测网络扫描、对办公区终端和服务器实行无差别定期漏洞扫描等等

2.欺骗用户点击执行

"暂时没有获取目标环境内的任何权限，甚至没有进入内网，也不知道环境内的用户在使用哪些客户端软件"，这才是常见的攻击者视角。但是通过信息收集，获取目标环境内用户的邮箱、微信、QQ却是相对容易的，与目标取得联系、投递恶意程序欺骗用户点击的过程中主要涉及的技术主要是User Execution和Command and Scripting Interpreter。

投递恶意程序的格式主要有两种：可执行文件和脚本文件

正常的业务环境中，通过邮箱或者通讯软件传递可执行文件其实是比较不常见的，所以环境条件允许的情况下，其实可以直接在邮件网关、七层防火墙、网络DLP、上网行为管理等设备上做限制，禁止通过邮件附件或即时通讯软件传递可执行文件。

有条件的话，也可以在域环境中启用applocker和SRP，并配置定制化的执行策略，做到对潜在的恶意可执行程序进行限制。

脚本文件的投递和执行，有很多攻击技巧和防御方式：

VBScript和JScript通过WSH(Windows Script Host)引擎运行，真正的执行点是vbscript.dll和jscript.dll，可以通过注册表完全禁用WSH，或者禁用wscript.exe和cscript.exe。

html文件--HTA(HTML Application)由mshta.exe执行，支持vbscript、jscript等多种脚本语言。

可以通过WDAC禁用mshta.exe，也可以通过组策略修改脚本文件的默认解析程序-->全都修改为通过notepad打开，而不是通过对应的脚本解析器打开。

VBA十分强大，可以直接与系统原生API交互，破坏力强于上述的vbscript、jscript。所以微软也十分重视，可以在微软信任中心对宏进行安全设置，保证默认情况下宏无法自动运行；另外还将来自互联网(查看方式-->notepad.exe .\xxx.doc:Zone.Identifier)的文档文件在"受保护的试图"中运行，这种模式下，不会执行代码，而脱离"受保护的试图"，需要用户的点击，当用户确定脱离该模式时，会启动一个新的word进程通过正常模式访问文档和宏。

然而对抗就是你来我往的过程，防守方尽量保护用户不要轻易点击，而攻击方就是想尽办法骗用户点击，并且尽可能的绕过防御策略，比如将word文档压缩后传输给用户，就可以避免被打上"来自互联网"这个标签。

Powershell，这位更是重量级，甚至还开发出了empire、PowerSploit这种完全基于powershell的攻击利用框架。powershell除了支持系统API、ActiveX外，还支持.NET框架，无论对于运维人员还是恶意攻击者来说，都是一把利剑。

为了防御powershell带来的攻击，微软也做了不少工作，默认情况下禁止运行ps1脚本，默认情况下双击ps1脚本就是通过notepad打开，Powershell Constrained Language Mode模式，AMSI扫描接口等。

Powershell Constrained Language Mode模式，在变量中“$ExecutionContext.SessionState.LanguageMode”定义，开启后powershell被禁止访问.NET脚本、WIN32API、COM对象的调用。可以直接在企业范围内通过applocker配置开启。

举例来说，启用了这个模式，PowerSploit中的powerup.ps1脚本将会无法运行，因为它在调用.NET。

无论恶意脚本进行怎样的混淆和编码，在脚本解析引擎中执行时还是会解码为明文，而AMSI就是通过RPC机制在解析引擎中进行检测，从而发现恶意脚本。

为什么恶意攻击者喜欢通过V2版本的powershell执行恶意脚本？因为Powershell Constrained Language Mode和AMSI都不支持在V2版本使用！所以一定要禁用V2版本的powershell！

另外powershell.exe只是.NET程序集system.management.automation.dll的解释器，ps脚本与AMSI的交互也是在system.management.automation.dll中，如果攻击者能够替换这个dll文件，则可以逃避AMSI的检查

笔者认为，完全阻断恶意脚本的执行是不现实的，所以检测工作需要和防御工作同步进行，检测的前提是充分的日志收集，针对恶意脚本检测，需要收集的日志不限于：ID为4688和4104的Windows系统日志，powershell script block log，powershell transcripts，applocker log，进程启动命令行日志……

有了日志后，就需要有针对性的检测规则，比如检测脚本引擎进程的启动，检测powershell中关键的函数名及别名，例如-noprofile，-encodedcommand，-command，Invoke-expression，Invoke-command，iex等等(如果读者对这部分感兴趣，之后可以单独写一篇文章进行介绍)

3.利用已经获取的认证凭据执行

已经有凭据，能够认证进入系统或者远程执行命令，就有很多technique可以完成execution了

但其实得到指定用户的凭据(能在特定机器完成execution)，本身并不是一件容易的事，通常还是要靠以上两种类型结合横向移动的各种技术，下面主要介绍一下微软提供的软件控制策略

Applocker

生成阻断规则，可以禁止运行某个路径下的程序，applocker的阻断记录也会留下日志，规则开始运行前，最好先观察一段时间日志，确定规则范围是合适的。

WDAC（Windows Defender Application Control）

可以通过组策略、powershell进行部署，比Applocker更加细粒度。

WDAC vs Applocker

核心不同：WDAC是基于设备的，Applocker是基于用户的。配合使用效果更佳！

SRP（software restriction policies）

Applocker和WDAC无法阻断某个具体后缀名文件的执行，可以通过SRP完成。