从南部公园系列拍摄
我们通过他的笔迹认出了他
在JSOC成立期间，我们面临着不同的IT基础架构和不同的客户需求，希望通过监控来覆盖他们的IT领域。例如，经常发生这样的情况：客户只想监视服务器，从而使自己失去了查看被监视段周围正在发生的情况的机会。当大多数基础结构已经受到威胁时，此方法可能导致较晚的攻击检测。而且，如果我们现有的客户没有这种情况，那么在试点项目中，这就是一个常识。
因此，在其中一个试点期间，客户正在重建自己的IT格局，并希望了解SOC如何适应其新的基础架构和流程。由于超出我们控制范围的各种情况，我们没有连接单个网络源，
发生了什么？我们看到的第一件事是将新帐户添加到Domain Admins组。但是还有另外一个规则起作用，即我们已经遇到的可疑帐户名称。攻击者
不幸的是，第一台受感染的计算机不在连接源的范围内，因此无法记录启动脚本本身的时间。创建帐户之后，我们在本地防火墙上捕获了一条规则更改，该更改允许使用特定的远程管理工具，然后创建了该工具的代理服务。顺便说一句，客户使用的防病毒软件无法识别此工具，因此我们通过创建相应的服务并启动该过程来对其进行控制。
最重要的是将合法的加密实用程序分发给了受感染的主机。他没有时间将其上传到所有主机。首次触发此事件后23分钟，攻击者被“踢出”基础架构。
当然，客户和我想获得事件的完整图片并找到攻击者的切入点。根据我们的经验，我们要求从网络设备获取日志，但是不幸的是，登录级别并不能得出任何结论。但是，在从管理员那里收到边缘网络设备的配置后，我们看到了以下内容：
源静态tcp“灰色地址”
内部的ip nat 22“白色地址” 9922源静态tcp“灰色地址”内部的ip nat内部3389“白色地址” 33899
从中得出的结论是，很可能配置了此NAT的服务器之一成为入口点。我们分析了这些服务器的日志，并在admin帐户下看到了成功的身份验证，启动了Mimikatz，然后启动了创建域管理员的脚本。通过此事件，客户对防火墙规则，密码和安全策略进行了完整的修订，并确定了其基础架构中的更多缺陷。我还对为什么组织需要SOC有了更系统的理解。
远程和家庭路由器-黑客的天堂
显然，在公司转向远程控制的情况下，监视终端设备上的事件变得更加困难。有两个关键原因：
- 大量员工使用个人设备工作；
- VPN , .
显而易见的事实是，即使是经验丰富的攻击者也已对家庭网络产生了兴趣，因为这是目前渗透到企业外围的理想点。
我们的一位客户将90％的员工切换到了远程工作模式，并且所有人都拥有域便携式计算机-因此，我们当然可以继续监视终端设备-当然，要考虑到上述第2点。正是这一点对我们不利。
自我隔离期间的一个用户几乎整天都未连接到VPN。最终，他仍然需要访问公司资源。他使用了VPN，我们从他的工作机上获得了日志，看到了一些奇怪的东西。在Task Scheduler中创建了一个可疑任务：它在每个星期三17:00启动一个特定文件。他们开始了解。
跟踪导致两个文档文件：其中一个创建了任务，第二个是任务中的可执行文件。用户从Google云端硬盘下载了它们。
在我们搜索的这个阶段，客户的安全服务已经连接好并开始内部调查。事实证明，用户收到了一封个人信件，其中包含指向Google云端硬盘的链接，该文件是从此处下载的。逐渐地，我们到达了用户的路由器-当然，它的登录名/密码是admin \ admin（好像是这样吗？）。但是，最有趣的是在路由器的DNS服务器的设置中发现的：在那里显示了欧洲国家之一的IP地址。我们将此地址放入VirusTotal-大多数资源都以红色点亮。调查结束后，客户向我们发送了两个文件进行研究，我们发现任务启动的文件开始“遍历”各个目录并从那里下载数据。
事件发生的时间顺序如下：攻击者获得了对用户路由器的访问权，更改了其中的设置，将自己的服务器指定为DNS服务器。有一段时间，我看着我的“受害者”，并给用户的个人邮件写了一封信。在这一步，我们找到了它，但不允许我们深入企业基础架构。
他们也打破了他们的
在使用外包SOC的初始阶段，我们始终建议分阶段连接事件源，以便客户方面调试过程，明确定义责任范围，并且通常会习惯这种格式。因此，在我们的一个新客户中，我们首先连接了基本资源，例如域控制器，防火墙，代理，各种信息安全工具，邮件，DNS和DHCP服务器以及其他几个不同的服务器。我们还提供了在本地日志级别连接总部管理员的机器的功能，但是该客户表示，目前这是不必要的，他相信自己的管理员。实际上，我们的故事就从这里开始。
一天，事件停止了。我们从客户那里获悉，据称，由于大规模DDoS攻击，他的数据中心“崩溃了”，现在他正从事恢复工作。这立即引发了很多问题-毕竟，DDoS保护系统已与我们连接。
分析师立即开始挖掘她的日志，但在那里没有发现任何可疑的东西-一切都在正常模式下进行。然后，我查看了网络日志，注意到平衡器的奇特工作，平衡器将负载分配在处理传入流量的两个服务器之间。负载均衡器没有分配负载，相反，它仅将负载定向到一台服务器，直到“阻塞”为止，然后才将流重定向到第二个节点。但是，更有趣的是，只要两台服务器都崩溃了，这种流量就会进一步扩大，并“放”所有的东西。在进行恢复工作的同时，客户发现谁搞砸了。这似乎是事件的结束：它与信息安全无关，只是与
有趣的是，事件发生前几周，该管理员已成为我们调查的对象。他从本地网络访问端口22上的外部主机。然后将此事件标记为合法，因为禁止管理员使用外部资源来自动化他们自己的工作或测试任何新设备设置。也许永远不会注意到数据中心崩溃和对外部主机的呼叫之间的这种联系，但是又发生了另一件事：从测试段的一台服务器到管理员以前联系过的Internet上同一主机的呼叫-客户也注意到了这一事件作为合法的。查看了管理员的活动后，我们看到测试部门对该服务器的不断请求，并要求客户对其进行测试。
这就是麻烦-在该服务器上部署了Web服务器，该服务器实现了客户主网站的部分功能。事实证明，管理员正计划将一些传入流量重定向到他的假站点，以便为自己的目的收集用户数据。
结果
尽管已经到2020年，但许多组织仍未遵守信息安全的常识，其员工的不负责任可能导致灾难性后果。
在这方面，这里有一些提示：
- 切勿将RDP和SSH暴露在外部，即使您将它们隐藏在其他端口后面也无济于事。
- 调整可能的最高日志记录级别，以加快入侵者的检测速度。
- Threat Hunting . TTPs , . .
- , . , , .
, Solar JSOC (artkild)