JSOC CERT我们正在调查事件。 总体而言，JSOC的所有170个人都在进行调查，但是最具技术挑战性的案例由CERT专家掌握。 例如，如果清除了攻击者，如何检测恶意软件的痕迹？ 如何找到一个从向导未正确配置日志记录的文件服务器中删除重要业务文档的“向导”？ 好吧，甜点：攻击者如何在不渗透网络的情况下从数十个不相关的域帐户中获取密码？ 细节一如既往地削减。
工作日JSOC CERT
通常，我们必须评估客户网络的实际危害，为此，我们执行以下操作：
- 硬盘和内存映像的回顾性分析，
- 恶意软件逆向工程
- 如有必要，可以紧急部署监视和扫描主机的漏洞和入侵痕迹的指标。
在业余时间，我们会编写详细的摘要，技术和剧本，从本质上讲，它们可以帮助扩展甚至是复杂的调查，例如 您可以半自动对它们进行操作。
有时，在事件响应期间-在灭火时，您还必须充当“心理支持服务”。 一旦我们被邀请帮助抵抗大型组织的子网感染。 该网络由两名承包商提供服务，在这种情况下，他们无私地
将自己扔到风扇上，彼此之间互相参与，但没有寻找恶意蠕虫。 为了减少歇斯底里的程度，我不得不坐在桌旁
让每个人都
拿毛巾和一瓶波旁威士忌，并清楚地说明现在不是认罪的时候了。 他们确定了分发程序，进行了额外的审核，并开始系统地一起清理感染。
在调查过程中，我们经常不得不选择磁盘和内存映像以在其中找到活动的恶意软件。 为了使该过程可预测和客观，我们将几种方法进行了形式化和自动化，以进行回顾性磁盘分析，并以已经很经典的
SANS方法为基础-在原始版本中它是非常高级的，但是如果使用得当，它可以非常高精度地检测活动感染。
显然，执行全部检查需要时间和对操作系统各个组件的功能有深入了解的专业知识（并且专门软件需要很多）。
如何简化检查磁盘是否受到主动感染？ 我们分享生活技巧-为此，可以对其进行动态检查（如在沙箱中）：
- 一点一点地复制可疑主机的硬盘；
- 使用此实用程序将生成的dd图像转换为VMDK格式；
- 在Virtual Box / VMware中运行VMDK映像；
- 并像生活系统一样进行分析，专注于交通。
但是，总有一些事件没有编写详细的说明，并且技术也不是自动化的。案例1.会计师与它无关，也与我们搜索恶意软件的方式无关
客户要求我们检查会计师的计算机中是否存在恶意软件：某人向未知地址下了几笔付款单。 会计声称他没有参与其中，并且计算机以前的运行方式也很奇怪：鼠标有时会从字面上移动到屏幕本身-实际上，我们被要求检查这些指示。 发现的问题是，针对1C的木马做了一些恶作剧并清除了感染，并且经过了将近一个月的感染-在此期间，勤奋的enikeyschik投放了一堆软件，擦除了未分配的磁盘空间，从而最大程度地降低了调查成功的可能性。
在这种情况下，只有经验丰富，细致的分析师和广泛的，自动更新的Threat Intelligence数据库才能提供帮助。 因此，在扫描启动文件夹期间，一个可疑标记引起了人们的注意，该标记指示所谓的反病毒更新实用程序：
不幸的是，无法从磁盘还原特洛伊木马的尸体，但实际上是从
Superfetch缓存中“相同的”文件夹启动远程管理实用程序的事实：
将它们与事件发生时间进行比较，我们证明了窃取金钱的不是会计师，而是外部攻击者。
情况2。谁删除了我的文件？
我们的大部分调查和事件响应都与恶意软件检测，使用多模块实用程序的针对性攻击以及存在外部攻击者的类似故事有关。 但是，有时会有更多平凡的事物，但是有趣的研究也不少。
客户端具有最普通的旧文件服务器，其多个部门可以访问其公用文件夹。 在服务器上放置了许多非常重要的商业文件，有人拿走了这些文件并将其删除。 我们很晚才意识到-备份超载之后。 他们开始寻找罪恶感。
如果您曾经尝试通过Google搜索如何确定哪个用户删除了该文件，那么您可能会遇到Windows日志中所有提示，如果事先对其进行了正确配置（顺便说一句，我们已经提供了
一些提示 ，说明如何删除该文件）。配置日志）：
来源但实际上，很少有人进行文件系统审核，因为文件操作很多，日志很快就会磨损，并且需要单独的服务器来存储日志...
我们决定将任务分为两部分：首先，确定何时删除文件； 其次，-世卫组织在删除时已连接到服务器。 如果您对NTFS的功能有所了解，那么您就会知道，在此文件系统的大多数实现中，删除文件时，该文件所占用的空间会被标记为空闲，并且其时间戳不会更改。 因此，乍一看，无法设置删除时间。
但是，文件系统不仅包含文件，还包含文件夹。 此外，文件夹具有特殊属性$ INDEX_ROOT，该属性将文件夹的内容描述为B树。 自然地，删除文件会更改文件夹的属性$ INDEX_ROOT，从而更改其时间戳，尤其是在$ STD_INFO的结构中。 因此，可以确定由于
MFT（主文件表）中的异常而删除大量文件和文件夹的大概时间：
在找出文件被大约删除的时间后，您可以尝试找出当时在北方工作的人，以缩小犯罪嫌疑人的范围。 想到以下方法：
- 通过服务器本身的日志-通过具有EventID 4624/4625的事件，在用户连接和断开连接时可见；
- 通过域控制器日志-EventID 4768可让您确定特定用户已请求访问服务器；
- 按流量-netflow /内部路由器日志-您可以找出谁通过smb通过网络主动与此服务器进行了通信。
在我们的例子中，该数据不再存在：已经过了太多时间，日志被轮换了。 在这种情况下，还有另一个不是很可靠的方法，而是一种方法，或者是注册表项
Shellbags 。 它存储有关信息，尤其是有关用户上次访问哪种文件夹的信息：表格，列表，大图标，小图标，内容等。 并且同一密钥包含时间戳记，可以高度自信地将其解释为上次访问该文件夹的时间。
找到了一种方法，剩下的就是从必要的主机收集注册表并对其进行分析。 为此，您需要：
具体来说，在此事件中，删除文件的时间与用户访问已删除文件夹的根的时间一致，这使我们能够将可疑范围从300个缩小到1个。
这位员工接下来发生的事情-这个故事是沉默的。 我们只知道那个女孩承认自己是偶然做的，并继续在公司工作。
情况3：密码管理员：几秒钟（甚至更快）“窃取”
攻击者进入了一个客户端网络，该客户端请求我们通过VPN提供帮助，并立即被检测到。 这不足为奇，因为进入后，他立即开始使用漏洞扫描程序扫描子网-烟壶像圣诞树一样闪烁。
锁定帐户后，客户端的安全人员开始解析VPN日志，发现攻击者已使用20多个不同的域帐户进行渗透（大多数他已成功登录，但对于某些身份验证未成功）。 逻辑上出现了一个问题：他是如何从这些帐户中找出密码的？ 我们邀请了来自JSOC CERT的人员来寻找答案。
在
先前的一篇文章中，我们已经说过，在调查中应随着假设概率的降低而形成并验证假设。 因此，我们这次做了，开始描述典型的帐户盗窃媒介：
我们检查了很多版本，但没有任何迹象表明存在攻击。 并不是说调查陷入僵局，而是内在的声音和常识表明有些地方出了问题-您需要退后一步，放宽视野。
的确，乍看之下，所有这些账目都毫无关联。 他们的所有者来自不同的，地理位置分散的部门。 通常，他们使用一组非重叠的公司服务。 甚至IT素养的水平也不同。 是的，仅退后一步还不够-需要再退一步。
到这个时候，我们设法从企业的不同系统收集了大量日志，并确定攻击者留下的痕迹。 他们开始分析它的出现位置（我记得：他积极扫描了公司的内部网络）。 我们注意到，在攻击行为均匀分布的网络噪音的背景下，对密码恢复服务的请求异常多。 可从Internet访问的服务。 嗯...
如果您正在监视安全事件，那么您可能知道，由于Internet的干扰，分析攻击外部可访问服务器的尝试通常是没有意义的：通常很难将真正严重的攻击与众多脚本犯罪尝试区分开。 但并非总是如此。
在Web服务日志上花费了一些时间之后，我们能够对服务进行以下攻击：
- 用Acunetix扫描
- SQLmap扫描
- 对一页的大量请求。
乍一看，第三种攻击类似于残酷的用户登录。 但是事实并非如此，因为至少可以通过这样的事实来保护服务免受此攻击：至少密码是用散列的形式存储着salt-是否？ 有必要快速检查它。
下图显示了密码重置服务的典型方案：
有趣的是，密码并非总是以安全的形式存储-在应用程序打开后立即执行之前，在公共域中有时会存在密码！ 事实证明，对一页的大量查询不是蛮力也不是扫描，而是使用SQL注入的高频查询，其目的是在更改密码时提取密码。
因此，在对服务的攻击进行建模之后，将Web服务器的日志，密码更改日志和多个网络设备中的信息进行比较，我们仍然可以找到企业中攻击者的渗透点。
因此，同事们，请深入研究原始数据，并可能与您同在！
