ATT&CK Execution技术攻防

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

一、背景

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

1657377256_62c991e837592241eb4ce.png!small?1657377256726

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

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

1657377213_62c991bdadff33f412f18.png!small?1657377214309

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

1657377211_62c991bb6b94016bda3ba.png!small?1657377212103

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

BITS Jobs–T1197安全设备覆盖防御能力检测能力
北京总部EDR DLP
上海分公司DLP
广州分公司

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

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

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

本篇文章,让我们进入ATT&CK矩阵的第四列:Execution,详细分析其中的技术有哪些,涉及企业安全工作建设中的哪些内容。1657376973_62c990cda2b4537639b7a.png!small?1657376974199

二、技术总体介绍

(一)Command and Scripting Interpreter

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

1657376967_62c990c7e901c20e597c9.png!small?1657376968433

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

1657376964_62c990c4d668f8db9548e.png!small?1657376965311

(二)Container Administration Command

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

1657376961_62c990c148b1376df11e8.png!small?1657376961747

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

(三)Deploy Container

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

1657376955_62c990bb5e5940a267403.png!small?1657376956027

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

1657376950_62c990b653b054083d978.png!small?1657376950880

(四)Exploitation for Client Execution

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

https://www.freebuf.com/news/338299.html
1657376945_62c990b17330baced421e.png!small?1657376946093

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

1657376941_62c990ad94775fc790592.png!small?1657376942192

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

(五)Inter-Process Communication

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

1657376933_62c990a58035075b62af5.png!small?1657376934093

(六)Native API

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

1657376930_62c990a2bc47100a71211.png!small?1657376931538

(七)Scheduled Task/Job

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

1657376925_62c9909dde289acde8f9f.png!small?1657376926576

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

1657376922_62c9909a81b9d631f0c41.png!small?1657376923300

(八)Shared Modules

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

1657376919_62c990976380cff3038e7.png!small?1657376920058

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

1657376914_62c990920901dcd5bad65.png!small?1657376914740

(九)Software Deployment Tools

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

1657376910_62c9908e8503a3e2243b5.png!small?1657376911131

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

(十)System Services

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

1657376905_62c9908900803cbdea357.png!small?1657376905625

(十一)User Execution

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

1657376902_62c99086a94a720920410.png!small?1657376903158

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

1657376897_62c990812ca65e67668a6.png!small?1657376897677

(十二)Windows Management Instrumentation

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

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

1657376894_62c9907e277a19b13709f.png!small?1657376894673

三、归纳和延伸

(一)Execution内容归纳

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

序号攻击类型特点
1欺骗用户点击完成执行社会工程学结合其他技术手段
2利用终端漏洞完成执行不需要提前投递恶意样本或者获取系统权限
3利用已经获取的认证凭据执行需要已有的系统权限

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

(二)攻击技术延伸

1.利用终端漏洞执行

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

1657376884_62c99074858c465dd790f.png!small?1657376885122

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

1657376881_62c99071664474619a01a.png!small?1657376882045

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

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

1657376876_62c9906cec76ca6a19913.png!small?1657376877674

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

1657376873_62c990699597e29436b46.png!small?1657376874320

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

1657376868_62c99064eb651973630fb.png!small?1657376869564

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

2.欺骗用户点击执行

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

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

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

1657376861_62c9905d1615a561371a2.png!small?1657376861635

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

1657376857_62c99059f2b86460ca04e.png!small?1657376858673

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

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

1657376854_62c990568ae7a2608b00e.png!small?1657376855185

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

1657376849_62c9905179274c0e1299a.png!small?1657376850060

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

1657376847_62c9904f45b7ca0ef6f80.png!small?1657376847779

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

1657376841_62c990497836d71fdc72a.png!small?1657376842165

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

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

1657376834_62c990427c9795ddd6e91.png!small?1657376835211

为了防御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。

1657376828_62c9903c35b97472fdacc.png!small?1657376828808

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

1657376825_62c99039e2d1e522caeee.png!small?1657376826679

为什么恶意攻击者喜欢通过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的检查

1657376820_62c99034af5291f328e09.png!small?1657376821265

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

1657376816_62c99030d9a7f80686752.png!small?1657376817551

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

1657376812_62c9902c4316a985489c0.png!small?1657376812788

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

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

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

Applocker

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

WDAC(Windows Defender Application Control)

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

1657376803_62c990230d821ed59b08f.png!small?1657376803705

WDAC vs Applocker

核心不同:WDAC是基于设备的,Applocker是基于用户的。配合使用效果更佳!

1657376795_62c9901b4442212b25ae5.png!small?1657376795895

SRP(software restriction policies)

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

1657376790_62c9901670702b70df270.png!small?1657376791182

本文作者:翁迪丁HAC, 转载请注明来自FreeBuf.COM

主题测试文章,只做测试使用。发布者:1869,转转请注明出处:https://community.anqiangkj.com/archives/19417

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022年7月11日 下午7:49
下一篇 2022年7月12日 上午10:33

相关推荐