从威胁堆栈导出数据以进行自定义分析
Threat Stack 现在是F5 分布式云应用基础设施保护(AIP)。 立即开始与您的团队一起使用分布式云 AIP。
此主机是否已被攻陷？ 这位主持人一直都是这样吗？
每个从事运营/工程/安全工作的人都曾遇到过出现意外行为的服务器。 它可能正在运行奇怪的进程，消耗比预期更多的内存，接受请求，与 GitHub 建立连接，等等。
对事件进行分类的第一步是了解您有一个事件。 有许多数据源可能会将你指向特定的主机服务器：
- 测量磁盘和内存空间等的监控工具
- 安全入侵检测系统生成警报
- application日志显示无法连接特定主机
此时，我们想要访问某个服务器并获取更多信息。 假设每条系统数据不一定适合我们的 SIEM，那么下一个合乎逻辑的步骤就是连接到主机并开始直接查询操作系统以了解其正在做什么。 根据您对环境的熟悉程度，这可以是 uname 和 vmstat 等工具，也可以是 ps 和 lsof 等更具体的项目。 无论哪种情况，你都会看到主机当前正在做的事情。 这个过程存在以下问题： 您实际上并不关心当前状态；您想知道发生了什么变化。 就像在 git 中获取拉取请求一样，您不想检查整个代码库，而只想检查已修改的部分。
数据可移植至 Amazon S3
在 Threat Stack Cloud SecOps Program℠ 中，我们 SOC 中的安全分析师已经开发出一种解决方案来帮助我们为客户解答这些类型的问题。 Threat Stack Cloud Security Platform® 具有我们称之为数据可移植性的巧妙功能。 从高层次上讲，这使我们能够获取从主机收集的遥测数据，包括正在运行的可执行文件、用户、命令行参数、连接等，并将它们存储在 S3 存储桶中。
S3 blob 的优点在于它们是一种存储大量数据的廉价方式。 问题在于利用大量非索引数据。 为此，我们最终使用 Amazon EMR 创建了 Jupyter PySpark 笔记本，以使用 Apache Spark DataFrames 和 Python pandas DataFrames 创建一个强大的工具，用于将机器的当前状态与我们保留的任何先前状态进行比较。
ETL（大家最喜欢的）
在查看我们的代码示例之前，请注意以下几点。 表和模式引用保存在 AWS Glue 中，并与Threat Stack 的 Linux 系统原始事件格式相匹配。 您可以将此数据附加到现有的数据湖。 然后为 Spark 集群定义一个设置，告诉它从 Glue 读取以了解哪些表和列可用。 然后，当创建集群时，您可以引用 JupyterLab 笔记本中的表。
笔记： 下面的代码完全是真实的；这种情况是人为的。 情人节那天的某个时间，一位安全分析师被要求入侵一台运行着我们代理的主机。 目标是弄清楚做了什么。
让我们进入代码
我们需要创建的第一件事是 SparkSession 和 SparkContext。 令人高兴的是，当使用 PySpark 笔记本时，我们运行第一个单元时它们会自动实例化。
设置我们的 PySpark 笔记本。
我们得到了一个稍后会引用的对象 spark，我们还得到了 sc，也就是我们的 spark 上下文。 然后我们可以使用它来加载pandas和Matplotlib 。
安装软件包。
在下一步中，我将通过创建基于 Glue 表的spark.table()来确认列名，然后显示我继承的模式。
读取从 AWS Glue 加载的列的结构。
太好了，现在我可以看到有哪些列和类型可以开始运行我的 SQL 查询。 我现在可以选择任何服务器和任何我想要的时间范围并进行比较。 在这里，我创建了两个 Spark DataFrames，收集事件前调查和事件后取证所需的数据：
从 compact.audit_v4 中选择 date_key、时间戳、tsEventType、系统调用、连接、用户、命令、exe、参数，其中 date_key >= '2020-02-05-00' 并且 date_key < '2020-02-14-00' 并且 organization_id = '5a8c4a54e11909bd290021ed' 并且 agent_id = 'b0f6bdb2-9904-11e9-b036-25972ec55a45' 按 date_key、时间戳、tsEventType、系统调用、连接、用户、命令、exe、参数分组 从 compact.audit_v4 中选择 date_key、时间戳、tsEventType、系统调用、连接、用户、命令、exe、参数，其中 date_key >= '2020-02-14-00' AND date_key < '2020-02-17-00' AND organization_id = '5a8c4a54e11909bd290021ed' AND agent_id = 'b0f6bdb2-9904-11e9-b036-25972ec55a45' 按 date_key、时间戳、tsEventType、系统调用、连接、用户、命令、exe、参数分组
围绕我们的妥协日期 2 月 14 日对数据进行分组。 （为了便于阅读，此处将一些笔记本单元显示为 GitHub Gists。）
现在，快速检查一下我收集了多少数据：
计算两个 Spark DataFrames 中的记录数，以确保调查的数量合理。
看起来是对的。 与postCompromiseDf相比，我的preCompromiseDf的时间范围要大得多。 （“Df” 是为了帮助我记住这些是 Spark DataFrame 对象——只是一个命名约定。）
Apache Spark DataFrames 非常棒，因为它们将整个 DataFrame 存储在集群中。 这对于海量数据集来说非常棒，但在这种情况下，我实际上想要比较的记录数量相对较少。 为此，我运行toPandas()将数据移动到笔记本电脑的内存中，这将允许更快的计算。
由于我们不处理“大数据”，因此在这种情况下在本地运行其余分析会更快。
开始分析
现在我可以开始做一些强大的事情，比如检查自 2 月 14 日午夜以来在此服务器上运行的新可执行文件有哪些。
/tmp/EXCITED_WHILE /usr/bin/wget /tmp/FRONT_RUN /tmp/UNUSUAL_COMB /tmp/SURROUNDING_LOCK /tmp/nmap /usr/bin/scp /tmp/sliver /tmp/sliver2 /tmp/PROUD_THUMB
该服务器上当晚运行的可执行文件的列表。
你好，一些随机的大写可执行文件名称：nmap、scp、wget 和称为 sliver 的程序。 稍微谷歌一下就会发现，sliver 很可能与https://github.com/BishopFox/sliver相关，并且是一个支持对多种协议进行命令和控制的植入框架。
我有证据证明我的服务器已经被入侵，但我想尽职调查，看看这些可执行文件实际上是如何处理的。 使用我的列表作为针对同一 DataFrame 的过滤器，我可以提取其他详细信息和妥协指标 (IoC)：
exe 参数 80 /tmp/EXCITED_WHILE ./EXCITED_WHILE 162 /usr/bin/wget wget https://github.com/andrew-d/static-binari... 255 /tmp/EXCITED_WHILE ./EXCITED_WHILE 256 /tmp/FRONT_RUN ./FRONT_RUN 359 /tmp/UNUSUAL_COMB ./UNUSUAL_COMB 360 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 464 /tmp/nmap 494 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 533 /tmp/EXCITED_WHILE ./EXCITED_WHILE 589 /tmp/FRONT_RUN ./FRONT_RUN 603 /tmp/EXCITED_WHILE ./EXCITED_WHILE 658 /tmp/EXCITED_WHILE ./EXCITED_WHILE 660 /tmp/FRONT_RUN ./FRONT_RUN 671 /usr/bin/scp scp -t /tmp/ 699 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 738 /tmp/UNUSUAL_COMB ./UNUSUAL_COMB 762 /tmp/sliver ./sliver 816 /tmp/SURROUNDING_LOCK ./SURROUNDING_LOCK 834 /tmp/sliver2 ./sliver2 878 /tmp/nmap /tmp/nmap 909 /tmp/EXCITED_WHILE ./EXCITED_WHILE 937 /tmp/FRONT_RUN ./FRONT_RUN 992 /tmp/FRONT_RUN ./FRONT_RUN 1023 /tmp/FRONT_RUN 1040 /usr/bin/scp scp -t /tmp/ ...
提取与我的可疑可执行文件列表相关的任何相关参数。
因此，scp 用于移动文件，wget 从 GitHub 拉下一些代码（转到该行向我展示了 nmap 进入系统的方式），并且其他文件的执行详细信息包含在文件本身内，因为它们没有收到命令行参数。 此时，拍摄主机快照作为证据并终止实例是有意义的。
最后一步是确认环境中的其他主机没有受到攻击。 为此，我们将从之前的 IoC 列表中取出一些项目并在所有服务器上进行检查。
从 compact.audit_v4 中选择 date_key、时间戳、tsEventType、系统调用、连接、用户、命令、exe、参数、agentId、tty、会话、cwd，其中 date_key >= '2020-01-01' 且 date_key <= '2020-02-29' 且 organization_id = '5a8c4a54e11909bd290021ed' 且 tsEventType = 'audit' 且 syscall = 'execve' 按 date_key、时间戳、tsEventType、系统调用、连接、用户、命令、exe、参数、agentId、tty、会话、cwd 分组
52
该查询返回整个环境中 52 个可疑 nmap 和 sliver 活动的结果。 我们可以通过进入 pandas DataFrame 并按每个服务器对结果进行分组来进一步缩小此视图：
开始使用您自己的威胁堆栈分析
感谢您一直陪伴我读完这篇文章。 我对这些数据提供的可能性以及找到探索它的新方法感到非常兴奋。 如果您目前利用威胁堆栈平台，您可以以本文档为指南设置您自己的数据可移植性。 好处是您可以根据自己的业务需求决定保留的适当级别的数据。
对于利用我们的 Threat Stack Oversight℠ 服务的用户，我们拥有 30 天的事件数据，并且很乐意与您合作，在您没有数据湖的情况下利用此工具集对您的环境进行更深入的取证。
Threat Stack 安全运营团队的下一步是开始寻求整合更多的图形和图表，以帮助在我们下次使用数据科学笔记本进行分析时以视觉方式解析数据。 接下来还有更多内容，但这是首次对一些 IP 进行地理定位（每个圆圈的密度表示连接的数量）。
Threat Stack Security 团队即将推出更多分析可视化功能！
Threat Stack 现在是F5 分布式云应用基础设施保护(AIP)。 立即开始与您的团队一起使用分布式云 AIP。