迄今为止，我已经主动或被动看到了至少10篇国内对SolarWinds供应链攻击事件的分析报告了。（为了凑够这个数字，我特地又搜了几篇）。
好几篇报告里面，上来就是一通样本分析，说这个被篡改的SolarWinds的dll样本是怎样怎样的，是怎么一个功能。
我就想问问，FireEye和微软不公开这件事之前，这个样本丢你面前，你能知道是个供应链后门么？就算你看到这个进程做了通信操作，你能确定这就是个恶意的样本么？
如果确认不了，你在这一通分析，有啥意义么？？？学习下怎么编写样本分析报告么？？？
FireEye在自己的博客里面给了几个检测建议，我觉得非常好，做甲方安全的同胞们好好看看，是不是对待这种狂酷炫拽吊炸天的供应链，我们就完全没辙了么？其实还是有机会搞一搞的，就看你认不认真了。
攻击者的后门用的是合法的SolarWinds的数字签名，没辙
攻击者的通信协议模仿的是SolarWinds的API调用，没辙
从进程树上看来，就是SolarWinds进程的操作，没辙
攻击者把他们的C2的hostname改成受害者环境里面的hostname，更容易迷惑处置人员。这个地方可以事后进行Hunting，没法事中进行检测。
可以据此使用网络测绘数据进行Hunting。例如使用zoomeye 或者 shodan ，查看全网里面RDP的证书是否有你们公司的。如果有的话，确认下是否真实是你们公司的资产。如果不是，十有八九被用来干你们的。（此处需@heige）
攻击者的C2 IP为了躲避检测，都用的跟受害公司同一个国家的VPS。如果攻击者使用C2 IP来访问被搞的账户，企业可以通过账户异常来检测到这个攻击。（这个地方搞黑产的好像都是共识了，使用被攻击账户的同一个省市的拨号IP，连账号异常都很难触发。实际检测中要结合设备环境信息和账户操作习惯信息来更好的判定）
攻击者通过获取的凭证进入网络后，他们会使用多个不同的账户凭证进行横向移动。用来横向移动的凭证不会和进入网络的账户凭证一致。避免横向移动被发现后，网络权限也被干掉了。
这里可以通过检测是否有一个系统对多个系统使用多个不同账号进行批量登录尝试的行为。
攻击者先把被控机器上合法的文件替换成他们的恶意文件，然后执行恶意文件，之后再把合法文件替换回去。例如，把你电脑上的notepad替换成他的恶意notepad，然后他执行下恶意notepad，执行完恶意notepad，再恢复到合法的notepad。
这个地方做检测的人应该会很有感触，如果EDR的日志里面只记录了进程调用信息，但没记录进程的MD5，光看日志，是识别不出来这次的恶意操作的。当然，如果替换的恶意notepad本身做的事情比较明显，也会被告警。如果做的动作没那么大，这个告警百分百会被忽略掉。即使记录了进程MD5，处置人员很可能也会忽略。没有几个人想到还去对比下前后MD5是否一致。
**这里FireEye给的建议是对这种短时间内创建执行删除再创建的行为进行告警。（**敲黑板，这个地方其实是让大家在检测里面多增加一种异常行为维度）
攻击者把原来合法的计划任务替换成他们要执行的文件，执行完再恢复到原始计划任务。
这里FireEye给出的建议是监控这种临时的计划任务修改，通过频率分析来识别这种异常计划任务更改。
上线使用DGA域名，这个地方大家可以深入看下。人工智能来解决安全问题前几年不是炒的很热么？检验你们成果的时刻到了
攻击者通过先前获取的管理员权限进一步获取被攻击的组织的 可信SAML token签名证书，通过这个他们可以伪造成组织内任何一个高权限账户的SAML token（可以理解成搞定了一个accesskey的生成证书）
使用这个可信的SAML token签名证书创建的SAML token，可以对信任该证书的任意云环境资源进行访问。因为该token是用他们的可信证书签名的，即使有告警，该异常也会被忽略（随意创建具备高权限的accesskey）。
**对待SAML token这种类似于云的api key，统统需要当成账户一样的资源来认认真真做下异常的“账户登录识别”，就是api key的使用异常识别（敲黑板**）。
对于供应链类的安全攻击，不要慌，并不是说被攻击者完全束手无策。供应链攻击解决了攻击者初始打点的问题，但攻击者进行横向移动的过程中还是有可能会被发现。供应链的安全问题，更加考验运营人员的能力。普通的安全事件，我们可能根据进程上下文和域名访问情况就能完全判定。但供应链类安全事件，我们需要观察更多的行为才能得出判断。当然，对于安全检测系统而言，也需要提供更丰富的Context来支持研判。