写在前面的话
我也不是专业的自媒体作者，也不想通过写这些文字去谋求什么，就是把经历和想法记录下来，各位觉得好看就点个赞，觉得不好看就删除。
事件概述
Lapsus$ 应该是最近新出现的黑客组织。黑客组织于去年年底首次出现，但已经入侵了微软、英伟达、三星、OKTA和育碧等知名企业。
Lapsus$还直接放出了英伟达和微软的部分代码，有新闻报道英国警方已经抓获了7名该组织成员。
伦敦市警方表示：“7名年龄在16至21岁之间的人因涉嫌黑客组织活动而被捕。他们随后在调查中获释，但调查仍在进行中。”
事件看点
微软事件报告
Lapsus$不仅发布了控制微软内部账户的截图，还放出了部分微软产品的代码，如bing，Cortana等代码。
微软自己发布一份关于被黑的调查报告，给Lapsus$取名为DEV-0537，具体链接地址在文末附带有兴趣读者可以自己去看看。
自己发布自己被黑的调查报告也算勇气可嘉，不过内容上看的说很多东西都是悠着写，就是这样文章里还有不少有意思的地方可以看。
我大约整理了攻击事件上面的流程
除了大家喜闻乐见的钓鱼撞库偷凭据外，新花样还有收买目标公司员工或者权限，甚至直接入职目标公司来获得相应的进入权限。
进入手法上更是简单粗暴，也没啥后门木马反弹shell，直接来个anydesk这样的软件，内部网络系统全通，系统全开随便玩。
后门就是各路内网小王子熟悉的环节了，撸AD，干Jira，gitlab，Confluence等各种系统。翻内部的各种系统和资料寻找密码和凭据。
利用收集到的各种信息再去服务台各种坑蒙拐骗，重置某些特权账户的密码。
拖代码环节，也没啥好说的都是正式员工了同步代码根本不会被发现，被发现时因为发布消息时候惊动了微软，被微软安全调查出来封闭了部分账户。
利用权限把自己加入到很多云租户的管理系统内成为唯一管理者，并且加入office365系统盗取邮件。
Lapsus$会想办法利用内部账户的权限加入到安全响应的处理小组中去，偷窥响应处理过程，根据处理方案调整自己的攻击操作。
强化MFA，不能用短信这样弱的容易被劫持的，也不能用简易的MFA如简单语音或者简单的推送，要用强的如FIDO Tokens或者Microsoft Authenticator这样的。
扩大MFA范围，最好啥地方都用上，不要说那些互联网登陆啥的，就是可信网络可信设备也要上，甚至本地终端也要用上。所有用户也都要上，不能有的用户可以进入白名单里。
要上风控策略，不能有了MFA就不做管控了
VPN要加强管控，不仅要有新的认证机制还要有风控
终端要做可信设备控制，打开Defender的云查杀
云上要加强管控，这部分主要分两块一块是加强云上的用户管控，另外一块是要把云上的安全报警和管控都打开
加强对社会工程学攻击的认识和防护教育
密码安全使用，这段内容说实话都是说了几百年的东西
密码策略要足够强度，推荐了微软自己的Azure AD Password Protection
避免密码喷射攻击
免密码方案可以考虑
员工避免在不安全的地方保存密码
禁止员工间共享密码和MFA因素
禁止有任何在线保存密码的地方，一次性密码账户必须离线保存
避免密码策略出现一个人就可以绕过MFA
社工是攻击源头之一，但是这基本算是无解，微软也无奈只能建议加强教育。
密码和MFA应该是这次攻击的主要问题，从使用上到保存看来几乎有问题的可能全部被轮了一个遍，所以微软一下提了好多建议。
另外云上用户管理混乱的问题也是根源，估计微软有很多客户Azure账户在内部，于是被黑去拿走干坏事。
微软的云上全家桶问题也不少，这种saas服务被从上游打穿真是无解，让微软也没法只能建议你们打开报警有问题及时联系。
VPN这样源头也是问题，加强认证外还要有风控策略。
Okta事件报告
有意思的环节是微软的修补建议，我也整理一下
整体就报告内容来说，整个攻击流程中没有什么特殊的地方，基本都是比较普通常见的方法，但是就这样也算是把微软打穿了。
从应对方案上来看解决方案里面可以看出攻击重点有以下几个点：
整个事件我比较好奇的是，微软建议居然没提anydesk这样的软件问题如何解决，看起来微软自己内部很多这样的场景存在，没法搞一刀切。
另外微软也通篇没提一堆人在内网胡搞，为啥没有报警和相关安全处理的说明，建议倒是提了defender要打开，可是这好像有点太晚了吧。
Okta没有全文报告，推特上找到一个人贴了报告的两个截图，从截图可以看到Okta应该是买了Fireeye的产品和服务，事件处理也是Mandiant去做的然后出的报告。
别的不说贴图吧
虽然很多打码了，但是还是可以看到很多有意思的信息
Okta被控制的终端上应该是Fire eye家的EDR产品，感觉这也算标配终端软件，这个终端感觉就是发给员工使用的机器。
虽然没说明，但是我感觉这些操作应该是直接在办公机的终端上了。
黑客拿到了很多账户密码，而且权限还不低，登陆远程机器都是直接登陆就进行操作。
下载黑客软件时，EDR还是在工作中的，估计是直接杀掉了下载的软件，没办法只能终结掉EDR进程。
去找来mimikatz进行操作，dump出来一堆hash。
后面还创建一个规则把收到的所有邮件都转发到Lapsus$自己的账户里面去。
留的信息太少了也没啥好分析了，简直就是在终端上现场学习提权，哪里不行就干啥，居然这样折腾Fire eye好像睡着一样，也没出点啥报警。
而且就记录来看虽然进程终止了，但是信息记录还在说明应该终端软件还是在以某种方式在工作。
只能说Okta这么大的声势，但是内部安全感觉也没想象的敏感啊，有这么明显的敏感操作，也没进行相应的应急响应来处理这些报警。
事件总结
解读分析大约写完了，后面就是是要做的的老本行，根据事件反思对自己企业安全需要做的改进。
改进建议微软写了不少，但是感觉很多估计国内落地难度很大。我改进简化版算是贴近实际情况。
MFA的必要性，不能指望员工保护这些账户，如果没有MFA基本无法杜绝账户丢失后长期被恶意使用，很多内部账户长期出借也不是新闻。
风控策略不仅是普通业务使用，特别是统一认证系统还有VPN这样的地方也应该有相关策略，不然如果内部恶意配合就能绕过MFA。
内部系统也要打补丁，不能觉得躲到内网就安全了。
云上用户权限也应该有统一管理建议是全部最小权限，还有特别是类似Access Key的也应该遵循最小权限管理，而且应该可以经常更换。
内部信息平台应该严格管控权限，禁止共享类似密码密钥这样的敏感文件。
办公网内如果可以应该管控类似anydesk这样的软件。
加强社工攻击的教育和防护意识培训。
考虑部署EDR产品。
云安全产品要用起来，安全报警需要有人运营和跟进，虽然这件事情很难但是还是要做啊。
最后一点感慨
当时看完微软和okta事情让我第一想起2010年百度域名被黑的事件，说起来那个伊朗黑客纯靠和客服沟通最终说服客服，给了他百度的域名转移权限。
百度那次事情让大家很震撼，因为不要协商大家域名全部迁移到号称从来没黑过的markmonitor上面去了。
当时我记得最清楚的是markmonitor来介绍重点强调了他们进行域名转移超级复杂的流程，这样就不可能重新出现百度的事情。这次事件不知道能给大家带来什么改进。
附录
微软报告链接地址：
DEV-0537 criminal actor targeting organizations for data exfiltration and destruction