一、背景

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命令完成执行。


(三)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，前两天又爆出了可以任意命令执行的漏洞……


针对客户端软件的利用并不完全是通过漏洞，除了浏览器，还有很多经常被利用的客户端软件，比如office套件通过wordexcel
进行钓鱼，也是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完成。