PowerLZY's Blog

一、特征交叉-从LR到DeepFM

提到LR->FM->FFM->Wide & Deep->DeepFM这一发展，必然离不开点击率CTR(click-through rate)和转化率CVR(conversion rate)。

这里再补充一下从MF到FM，矩阵分解MF(Matrix Factorization)基本原理：

主要是将用户-物品矩阵分解为用户矩阵(实质为用户的embedding矩阵)和物品矩阵(实质为物品的embedding矩阵)，有了用户表征向量和物品表征向量我们就可以计算任意用户和物品之间的联系。

1.1 LR->FM

线性模型：

从公式中我们就可以看出，线性模型中默认假设特征之间是相互独立的，但是在现实中基本不可能存在，因此线性模型会丢失很多组合信息。

多项式模型：

多项式模型中增加了特征的组合信息，但是又引入了新的问题，参数爆炸，复杂度太高，在实际推荐中特征可能是上万甚至更高维，单单二阶的特征交叉就是 ，更不用说更高阶特征交叉。此外，在CTR任务中，特征是特别稀疏的（如图2），进行特征交叉以后也都是0，这将导致模型训练不能充分。

FM主要的优化有两个方面：

（1）将复杂度从 降到了 ；

（2）可以在稀疏数据中学习到组合特征，甚至是那些数据中没有观测值的组合特征。

一、DeepFM

吃透论文——推荐算法不可不看的DeepFM模型 - 梁唐的文章 - 知乎 https://zhuanlan.zhihu.com/p/343343016

DeepFM: A Factorization-Machine based Neural Network for CTR Prediction，翻译过来就是DeepFM：一个基于深度神经网络的FM模型。这篇paper的作者来自哈工大和华为，不得不说在人工智能领域的很多论文都是国产的，作为从业者还是非常欣喜能看到这点的。

1.1 简介

对推荐场景来说，CTR是最关键的指标，除了广告系统会按照CTR x bid来进行排序之外，推荐系统一般都会严格地按照预估的CTR进行排序。所以这其中的关键问题就是准确地预估CTR。

常规的推荐系统当中的特征分为四个部分：

• 用户特征：关于用户的一些信息。比如是男是女，是否是高收入群体，是否是高消费群体，成为平台的用户多久了，偏好平台当中什么类目的商品等等。
• 商品特征：关于item的一些信息，比如价格、类目、折扣、评价等等。
• 上下文特征：比如当前的时间，是早上还是晚上，比如item展示的位置等等。
• 用户实时的行为：比如用户在浏览这个商品之前还看过哪些其他的商品，他登陆平台多久了，等等。

显然用户是否会点击某一个item是由以上这四个部分的信息共同作用的，也就是说商品的特征和用户的特征之间是存在逻辑上的关联的，我们一般称为特征的交叉。

这些交叉信息往往是隐式的，也就是我们不能直接描述和形容出来的。人的喜好是很复杂的，我们很难用固定的规则去描述。所以这就需要模型能有这样的能力去学习这些特征之间的潜在联系，对这些潜在交叉信息把握越好的模型，一般也都拥有越好的效果。

比如我们分析了主流的app store市场之后发现，在饭点的时候，用户经常会下载外卖类的app，这说明了app的类别和时间之间存在交叉关系。再比如我们发现年轻的男生往往喜欢设计类游戏，这说明了app的类别与用户的性别之间也存在交叉关系。像是这样的交叉信息还有很多，从Wide & Deep模型的经验当中我们可以学到考虑低维和高维交叉特征之后，模型的效果会更好。

1.2 算法

训练集当中一共有 \(n\) 条样本, 每一条样本可以写成 \((\chi, y)\) 。其中的 \(\chi\) 是一个 \(m\) 个field组成的向量, 包含了用户和 item组成的特征。 \(y \in\{0,1\}, y=0\) 表示用户没有点击，相反， \(y=1\) 表示用户点击。 - 类别特征：比如性别、地理位置、收入情况等等。 - 连续性特征, 比如平均花费、平均停留时间等等

类别特征 (categorical feature) 一般被表示成一个one-hot之后的向量, 而一个连续特征, 一般就是表示它自 己, 当然也可以离散化成one-hot向量。我们把这些特征全部处理完之后, 整个向量会转化成 得x向量变得非常稀疏。所以我们要做的就是在这样特征比较稀疏的样本上简历一个CTR预测模型。

1.3 DeepFM

我们希望能够设计模型能够更好地学习低维和高维特征之间的交互，基于这点，我们在深度模型的基础上结合了FM，推出了DeepFM模型。它的整体结构如下图：

这张图看起来可能会有点乱，我们可以先忽略一些局部的细节，先从整体上把握。这个模型可以分成两个部分，分别是FM部分以及Deep部分。这两个部分的输入是一样的，并没有像Wide & Deep模型那样做区分。

• 神经网络也就是Deep的部分用来训练这些特征的一维的关联以及联系
• FM模型会通过隐藏向量V的形式来计算特征之间的二维交叉的信息。最后一维和二维的信息汇总到一起，进入sigmoid层，获得最终的结果。

用公式来表达的话，大概是这样：

\[ \hat{y}=\operatorname{sigmoid}\left(y_{F M}+y_{D N N}\right) \]

1.4 FM部分

FM部分其实就是因子分解机, 我们在之前的文章当中曾经专门剖析过。FM会考虑所有特征之间两两交叉的情况, 相当于人为对左右特征做了交叉。但是由于 \(n\) 个特征交叉的组合是 \(n^2\) 这个量级, 所以FM设计了一种新的方案, 对 于每一个特征i训练一个向量 \(V_i\), 当i和 \(\mathrm{j}\) 两个特征交叉的时候, 通过 \(V_i \cdot V_j\) 来计算两个特征交叉之后的权重。这样 大大降低了计算的复杂度。 这当中涉及一些公式的推导和计算, 我们在之前的文章当中已经详细推导过了, 这里就不多㥿述了。最终我们可以 得到这部分的公式: \[ y_{F M}=<w, x>+\sum_{i=1}^d \sum_{j=i+1}^d<V_i, V_j>x_i \cdot x_j \]

1.5 Deep部分

Deep部分就是经典的前馈网络，用来学习特征之间的高维交叉。

图3展示的就是模型当中Deep这个部分，从图中我们可以看到，所有的特征都会被转化成embedding向量作为Deep部分的输入（ 每个01向量对应自己的嵌入层，不同向量的嵌入过程相互独立）。CTR预估的模型和图片以及音频处理的模型有一个很大的不同，就是它的维度会更大，并且特征会非常稀疏，还伴有类别连续、混合、聚合的特点。在这种情况下，使用embedding向量来把原始特征当中的信息压缩到低维的向量就是一种比较好的做法了，这样模型的泛化能力会更强，要比全是01组成的multi-hot输入好得多。

这张图展示了这个部分局部的结构，我们可以看到所有特征转成的embedding向量拥有相同的维度k。并且和FM模型当中的维度也是一样的，并且这个embedding的初始化也是借用FM当中的二维矩阵V来实现的。我们都知道V是一个d x k的二维矩阵，而模型原始输入是一个d维的01向量，那么和V相乘了之后，自然就转化成了d x k的embedding了。

这里要注意的一点是，在一些其他DNN做CTR预估的论文当中，会使用预训练的FM模型来进行Deep部分的向量初始化。但这里的做法略有不同，它不是使用训练好的FM来进行初始化，而是和FM模型的部分共享同样的V。这样做会有两个非常重要的好处：

• 它可以同时学习到低维以及高维的特征交叉信息，预训练的FM来进行向量初始化得到的embedding当中可能只包含了二维交叉的信息。
• 这样可以避免像是Wide & Deep那样多余的特征工程。

##### 数据选择

我们选择了两份数据用来评估DeepFM与其他模型的性能，一份是Criteo数据集，其中包含了4500w用户的点击数据，由13个连续型特征以及26个类别特征组成。我们把90%做成训练数据，10%做成测试数据。第二份数据是公司内部（华为）的数据，由连续7天用户在华为app store游戏中心的点击数据组成训练数据（约10亿条），1天的数据作为测试数据。

##### 评估指标

我们主要评估模型的指标有两个，一个是AUC另一个是Logloss（交叉熵）。从这个评估指标上来看是比较中肯的，没有像有一些paper当中自己定义一种新的评估指标。

DeepFM Q&A

DeepFM对连续特征的处理?

deepfm原文提到，连续变量可以直接作为单个值输入，或者离散化作为一个向量输入。那么目前可获取的包 deepctr中的deepfm是怎样处理的？

这里直接看源码，红色方框：

可以看到连续特征（dense_value） 直接作为DNN的输入，不参与FM的输入。我们也可以连续变量离散化后，同时作为DNN和FM的输入，这样连续变量也和类别变量有二阶特征交互，或许可以带来更多的信息，增强模型表达。

Forecasting Malware Capabilities From Cyber Attack Memory Images

• 项目：https://www.usenix.org/conference/usenixsecurity21/presentation/alrawi-forecasting
• 文章：https://arxiv.org/abs/1907.07352

摘要

正在进行的网络攻击的补救依赖于及时的恶意软件分析，其目的是发现尚未执行的恶意功能。不幸的是，这需要在不同工具之间重复切换上下文，并且会给分析员带来很高的认知负荷，从而减慢调查速度，并给攻击者带来优势。我们提出了Forecast，这是一种事后检测技术，可使事件响应者自动预测恶意软件的执行能力。预测基于概率模型，该模型允许预测发现能力，并根据其相对执行可能性（即预测）对每个能力进行权衡。 Forecast利用当前攻击的执行上下文（来自恶意软件的内存映像）来指导恶意软件代码的符号分析。我们进行了广泛的评估，有6727个真实世界的恶意软件和旨在颠覆预测的未来主义攻击，显示了预测恶意软件能力的准确性和鲁棒性。

Forecast is based on a probabilistic model that allows Forecast to discover capabilities and also weigh each capability according to its relative likelihood of execution

一、说明

网络攻击响应需要对抗阶段性恶意软件功能（即尚未执行的恶意功能），以防止进一步的损害[1]、[2]。不幸的是，检测后预测恶意软件功能仍然是手动的、繁琐的和容易出错的。目前，分析师必须重复执行多个分类步骤。例如，分析员通常会将二进制文件加载到静态反汇编程序中，并执行内存取证，以组合静态和动态工件。这一艰苦的过程需要在二进制分析和取证工具之间进行上下文切换。因此，它给分析员带来了很高的认知负荷，减慢了调查速度，给攻击者带来了优势。

为了自动化事件响应，符号执行很有可能用于恶意软件代码探测，但缺少先前的攻击执行状态，而这种状态在事后可能无法重新实现（例如，来自C&C活动的具体输入）。特定于环境的条件（如预期的C&C命令）限制了动态和协同技术（如[3]–[14]）预测无法访问的能力。此外，这些技术依赖于剖析独立恶意软件二进制文件或在沙箱中运行它。然而，已知恶意软件会删除其二进制文件或将自身锁定为仅在受感染的计算机上运行（硬件锁定）。更糟糕的是，研究人员发现，无文件恶意软件事件（即，仅驻留在内存中）继续增加[1]、[15]、[16]。

有权访问正确的执行上下文对于引导恶意软件显示其功能是必要的。恶意软件在内部收集来自特定环境源的输入，例如注册表、网络和环境变量，以便做出行为决策【11】、【17】、【18】。因此，恶意软件的理想和实用输入公式可以根据内存中的该内部执行状态进行调整，其中包含已收集的输入工件。事实证明，在检测到恶意进程后，反病毒和IDS已经收集了该进程的内存映像。恶意软件内存映像包含被调查的特定攻击实例特有的这种内部具体执行状态。

在我们的研究过程中，我们注意到，如果我们可以在内存图像中设置代码和数据页的动画，并根据捕获的快照执行向前的代码探索，那么我们就可以重用这些早期的具体执行数据来推断恶意软件的下一步。此外，通过分析这些具体输入如何在代码探索期间诱导路径，我们可以根据恶意软件捕获的执行状态预测哪些路径更有可能执行功能。基于这一思想， 我们提出用通过内存图像取证获得的具体执行状态对恶意软件的预阶段路径进行符号探索。通过这一点，我们克服了分析员之前必须进行的艰苦而繁重的认知过程。

我们介绍了Forecast，这是一种后检测技术，使事件响应者能够从捕获的内存图像中预测可能的功能。Forecast根据发现的每个功能的执行概率（即预测）对其进行排序，以使分析师能够确定其修复工作流的优先级。为了计算这种概率，Forecast会衡量每条路径对具体数据的相对使用情况。这种方法基于内存映像执行状态的具体程度（或DC）的形式化模型。Forecast从内存映像中的最后一个指令指针（IP）值开始，通过象征性地执行每条指令的CPU语义来探索每条路径。在此探索过程中，预测建模符号和具体数据的混合如何影响路径生成和选择。基于这种混合，沿路径计算每个状态的“具体性”分数，以得出每个发现能力的预测百分比。DC（s）还通过动态调整循环边界、处理符号控制流和修剪路径来优化符号分析，以减少路径爆炸。

为了自动识别每个功能，我们开发了几个模块化的功能分析插件：代码注入、文件过滤、滴管、持久性、键和屏幕监视、反分析和C&C URL连接。每个插件根据API序列、它们的参数以及它们的输入和输出约束如何连接每个API来定义一个给定的功能。Forecast插件是可移植的，可以很容易地扩展以捕获基于目标系统API的其他功能。值得注意的是，Forecast的分析只需要一个法医记忆图像，允许它对无文件恶意软件工作，使其非常适合事件响应。

我们使用涵盖274个家族的6727个真实恶意软件（包括打包和解包）的内存图像评估Forecast。与人工专家手动生成的报告相比，Forecast可提供准确的能力预测。此外，我们还表明，Forecast对旨在颠覆Forecast的未来主义攻击具有鲁棒性。我们表明，预测的检测后预测是由早期的具体输入准确诱导的。我们将预测与S2E【6】、angr【22】和Triton【23】进行了经验比较，发现预测在识别能力和减少路径爆炸方面优于它们。预测可在线访问：https://cyfi.ece.gatech.edu/.

“S2E: A platform for in-vivo multi-path analysis of software systems,” 2011

“SoK: (State of) The Art of War: Offensive Techniques in Binary Analysis,” 2016

“Triton: A Dynamic Symbolic Execution Framework” 2015

二、概述

本节介绍了结合记忆图像取证和符号分析技术的挑战和好处。以DarkHotel事件[2]为例，我们将展示事件响应者如何利用预测加快调查并补救网络攻击。

运行示例：DarkHotel APT。DarkHotel是一种APT，通过矛式网络钓鱼攻击C&C服务器【2】。感染后，DarkHotel会从受害者的文件系统中删除其二进制文件，与C&C服务器通信，将线程注入Windows资源管理器，并最终过滤侦察数据。当IDS检测到受感染主机上的异常活动时，终端主机代理会捕获可疑进程内存（即DarkHotel内存），终止其执行，并生成通知。此时，事件响应者必须从不同的可用取证来源（网络日志、事件日志、内存快照等）快速了解DarkHotel的能力，以防止进一步的损坏。

动态技术【11】–【14】可能需要一个激活的C&C以诱使恶意软件二进制文件显示其功能，然而该C&C可能已被取下。由于DarkHotel只驻留在内存中，这些通过在沙盒中运行恶意软件而起作用的技术无法应用。

• 只有内存图像，分析员可以使用取证工具，如Volatility【24】，来“切割”内存图像代码和数据页。基于提取的代码页，符号分析可以模拟恶意软件的执行，以探索所有潜在的路径。
• 不幸的是，现有的符号工具需要一个格式正确的二进制文件，并且没有针对内存图像进行优化[7]、[22]、[23]。

理想情况下，分析员可以手动将这些代码片段投影到符号分析中，并从数据页中获取具体值，以告诉哪一个代码分支会导致某个功能。然而，这种用提取的内存工件“缝合”代码的来回过程涉及符号执行和取证工具之间的上下文切换。这给分析员带来了很高的认知负担。分析员还必须处理路径爆炸、API调用模拟[4]、[22]、[25]–[27]和具体化API参数（例如攻击者的URL）等挑战，这些挑战可能无法在内存映像中静态访问。最后，分析师必须沿每条路径手动检查API，以推断高级功能。

2.1混合事件响应

事件响应者依靠内存取证来识别内存图像中的攻击瑕疵。然而，仅仅是基于签名的记忆取证，由于高漏报率，会遗漏重要的数据结构【21】。另一方面，符号执行可以正向探索代码，但会遇到路径爆炸等问题[22]。为了解决这些限制，Forecast通过反馈循环将符号执行和内存取证结合起来，以解决这两种技术的缺点。

上下文感知记忆取证。符号分析提供代码探索上下文，以准确识别内存取证遗漏的数据构件。例如，DarkHotel内存图像的传统法医解析遗漏了C&C URL字符串，因为它们通过自定义编码方案进行了混淆。然而，对引用这些字节作为参数的指令（如strncpy API）进行的后续符号分析允许Forecast正确识别和利用内存映像中的这些数据瑕疵。此外，有针对性的恶意软件可能会采用旨在颠覆预测的策略，使用反取证和反符号分析，这是我们在设计和评估中仔细考虑的。

内存图像取证提供了具体的输入，可以帮助符号分析执行地址具体化、控制流解析和循环边界。此外，内存取证可以识别内存中加载的库地址，从而允许Forecast执行库函数模拟。

路径概率。给定一个内存映像，目标是利用可用的具体数据来探索潜在的代码路径，并预测沿途的功能。通过分析具体内存图像数据是如何产生不同路径的，Forecast可以得出一条路径相对于其他路径达到某种能力的概率。Forecast基于建模具体和符号数据操作如何影响路径生成和选择来计算此概率。Forecast还利用此概率度量作为一种启发式方法来修剪具有最少具体数据的路径。

2.2 Incident Response with Forecast

Forecast可识别来自自动管道中恶意软件内存映像的功能。为了证明这一点，我们模拟了DarkHotel的攻击和内存捕获，其中包括使用DarkHotel的网络签名设置IDS并执行高级持久性威胁（APT）。检测完成后，IDS向终端host agent发出信号，以捕获DarkHotel进程内存。然后，我们输入该内存图像进行预测以进行分析。在459秒内， Forecast显示了DarkHotel的功能：C&C通信（即mse.vmmnat.com）、文件过滤（即主机信息）和代码注入（即注入Windows Explorer）。

处理法医记忆图像有六个阶段，如图1所示。1 Forecast以取证方式解析内存映像，并通过将最后一个CPU和内存状态加载到符号环境中进行分析来重建先前的执行上下文。在分析内存映像时，Forecast检查加载的库，以识别导出的函数名和地址。接下来，2 Forecast继续探索可能的路径，利用内存映像中可用的具体数据来具体化路径约束。3预测模型和权重每个路径如何由具体数据归纳，并为每个生成的路径分配概率。4 Forecast然后使用此概率作为权重来调整循环边界并修剪错误路径，从而允许Forecast缩小诱导能力相关路径的范围。5 Forecast将已识别的API与功能分析插件库相匹配，以向分析师报告功能。最后，6 Forecast确定了三种能力，并从路径概率中得出了它们的预测百分比，分别为31%、15%和54%。

词嵌入-GloVe-基于全局共现词频信息的词嵌入

词嵌入-GloVe-基于全局共现词频信息的词嵌入 - Glenn1Q84的文章 - 知乎 https://zhuanlan.zhihu.com/p/485447934

CS224n笔记[3]:共现矩阵、SVD与GloVe词向量 - 蝈蝈的文章 - 知乎 https://zhuanlan.zhihu.com/p/147312345

why? From LSA(latent semantic analysis) and skip-gram to GloVe

• LSA: 基于全局词频的稀疏矩阵, 在词义推理任务上表现较差

ELMO-具有上下文语境的词嵌入

https://zhuanlan.zhihu.com/p/504527165

1.从静态词嵌入到动态词嵌入（具有语境的词嵌入）

词嵌入：将词用一个具有语义信息的多维向量来表示

静态词嵌入：多维稠密向量来表示，是一个固定的向量，不会根据语境的差异发生改变， 没办法结合语境给出正确的词向量，即一词多义的问题

动态词嵌入：根据不同的上下文语境调整词的语义，能较好的应对一词多义(polysemy)问题

如何做到动态词嵌入呢？NAACL 2018 best paper ELMO(Embeddings from Language Model)能给你一个较好的答案

2.ELMO：Deep Contextualized Word Representations

可以看到模型整体由 前向+后向LSTM 与 CNN 字符嵌入组成，详情见下图，还是非常直观的

• CNN字符嵌入: 输入一句话(多个word) 先由CNN字符嵌入进行编码 得到每个word的词向量,简单来说就是把一个词分解成字母，然后对字母进行卷积操作获得词向量;
• 将词向量按照顺序分别输入到前向 后向 LSTM中进行嵌入：其实就是基于已知的词预测下一个词，对词的编码采用LSTM架构（不熟悉LSTM的话就简单看成是一个编码器就行了）前向+后向分别是从前到后和从后到前，注意：前向和后向的LSTM之间并不连接，why? 假如连接了预测过程就相当于泄题了，这个地方比较抽象，让我再深入一下：
  • 假如这里有一句话，由N个词组成 组成,LSTM具有较好的记忆能力，能够记忆已经给出序列的信息，前向LSTM从前向后扫的时候会不停的记忆已知的信息，每一时刻预测结果出来以后会将其信息存储起来，这样每次预测下一时刻信息的时候都会已知前面词的信息，比如：预测 时已知 ；预测 时已知 .
  • 相应的，后向LSTM也一样，只不过词的输入顺序反过来了，在这里是从 当t=N-1的时候,（就相当于前向LSTM的t=2时刻）， 后向LSTM会存储着 的信息
  • 对于前向LSTM来说，在t=3时刻，预测x_3, 后向LSTM存储着的 信息，由于前向LSTM与后向LSTM的连接给了两者信息交互的机会（泄题的机会)，因此这时候后向的LSTM会告诉前向LSTM：嘿 boy，不要再猜了，答案就是X3
• 将CNN层的输出与多个LSTM层的输出拼接在一起 就得到一个词的表示了

马尔可夫模型

如何用简单易懂的例子解释条件随机场（CRF）模型？它和HMM有什么区别？ - Scofield的回答 - 知乎 https://www.zhihu.com/question/35866596/answer/236886066

一、概念

1.1 随机过程

随机过程就是一些统计模型，利用这些统计模型可以对自然界的一些事物进行预测和处理，比如天气预报，比如股票，比如市场分析，比如人工智能。它的应用还真是多了去了。

1.2 马尔可夫链 （Markov Chain）

马尔可夫链 （Markov Chain）是什么鬼 - 车卡门的文章 - 知乎 https://zhuanlan.zhihu.com/p/26453269

马尔可夫链就是这样一个任性的过程，它将来的状态分布只取决于现在，跟过去无关！实际上就是一个随机变量随时间按照Markov性进行变化的过程。

1.3 马尔可夫模型（Hidden Markov Models）

既是马尔可夫模型，就一定存在马尔可夫链，该马尔可夫链服从马尔可夫性质：即无记忆性。也就是说，这一时刻的状态，受且只受前一时刻的影响，而不受更往前时刻的状态的影响。在这里我们仍然使用非常简单的天气模型来做说明。

在这个马尔可夫模型中，存在三个状态，Sunny， Rainy， Cloudy，同时图片上标的是各个状态间的转移概率（如果不明白什么是转移概率，那建议先去学习什么是马尔可夫再来看HMM）。

现在我们要说明什么是 HMM。既是隐形，说明这些状态是观测不到的，相应的，我们可以通过其他方式来『猜测』或是『推断』这些状态，这也是 HMM 需要解决的问题之一。

举个例子，我女朋友现在在北京工作，而我还在法国读书。每天下班之后，她会根据天气情况有相应的活动：或是去商场购物，或是去公园散步，或是回家收拾房间。我们有时候会通电话，她会告诉我她这几天做了什么，而闲着没事的我呢，则要通过她的行为猜测这几天对应的天气最有可能是什么样子的。

以上就是一个简单的 HMM，天气状况属于状态序列，而她的行为则属于观测序列。天气状况的转换是一个马尔可夫序列。而根据天气的不同，有相对应的概率产生不同的行为。在这里，为了简化，把天气情况简单归结为晴天和雨天两种情况。雨天，她选择去散步，购物，收拾的概率分别是0.1，0.4，0.5， 而如果是晴天，她选择去散步，购物，收拾的概率分别是0.6，0.3，0.1。而天气的转换情况如下：这一天下雨，则下一天依然下雨的概率是0.7，而转换成晴天的概率是0.3；这一天是晴天，则下一天依然是晴天的概率是0.6，而转换成雨天的概率是0.4. 同时还存在一个初始概率，也就是第一天下雨的概率是0.6， 晴天的概率是0.4.

西湖论剑-告警误报检测

2020西湖论剑Ai大数据安全分析竞赛思路分享 - 杨航锋的文章 - 知乎 https://zhuanlan.zhihu.com/p/295179638

滴滴安全运营之自动编排 (SOAR) 的探索

DiDi:https://www.secrss.com/articles/25896

困难和挑战

• 海量异构的日志数据源
  • 覆盖广：通过各类sensor采集的数据，覆盖了办公网和客服网的终端，以及测试网生产网的服务器，还有公有云的虚拟机等等。
  • 来源多：HIDS，网络层的NTA，终端EDR，还有VPN的认证日志，DNS的解析记录，802.1x的认证，AD域控的日志，还有防火墙邮件服务器密罐的日志等等。
  • 量级大：每天用于安全审计的原始日志达到了10Tb及以上的量级。
  • 异构性：Hive、ElasticSearch、Kafka等等，而有些日志是设备通过Syslog和Webhook的方式打给我们的，这些日志都是异构的。
• 有效的告警会淹没在误报当中
  • 黑名单的规则来定义异常，无法感知未知；白名单规则，通过定义正常来发现异常；
  • 统计规则阈值的选取也和误报息息相关；
  • 在甲方日常的安全运营中，团队可能会受 KPI的影响
• 告警研判推理的挑战
  • 如果我们缺少有效的关联分析能力，就很难从各个孤立的告警中还原出攻击者的一次战术动作。
  • 告警研判过程中存在重复低效的二次取证的工作
  • 不完备的资产实体库
  • 研判过程中还缺乏知识的指引

如何针对事件检测响应去建构知识体系？

• 知识模型：STRIDE的模型、kill Chain杀链模型、ATT&CK模型
• 知识交换：指交换威胁情报和lOC识别的知识，目前业内比较通用的有像==STIX2.0==，还有TAXll协议。
• 知识运用：如何运用知识来指导我们做lOC规则的开发，如何做研判策略的设计，以及如何制定事件处置的SOP流程等等。
• 知识迭代：知识模型自身的迭代，比如说近期ATT&CK模型也推出了Sub-techniques，就是子技术的概念。另一方面就是日常运营的案件如何反馈到知识模型来做迭代。

如何建立科学的度量和评价体系？

我们在事件检测运营中有很多指标，比如围绕资产实体的，有HIDS部署的覆盖率，比如终端EDR的安装覆盖率，还有跨网络、跨安全域网络边界、南北向流量检测覆盖率等等。

还有围绕运营流程的，比如像比较核心的MTTD/MTTR指标。还有围绕能力矩阵的，比如ATT&CK矩阵的覆盖率。指标的选取，它关系到能否把控安全态势的全局以及能否做好牵引能力的建设，因此选取有效的度量和评价体系，也是存在挑战的。

MTTD = 故障与检测之间的总时间/事件数量

MTTA = 指从系统产生告警到人员开始注意并处理的平均时间。

安全编排自动化与响应SOAR，它能为安全事件检测与响应流程带来哪些改善?

SOAR分为安全编排自动化，安全事件响应平台，以及威胁情报平台三种技术工具的融合。

SOAR如何加速事件检测和响应

首先在IDR运营流程中，我们接收到一个异常的事件Event，我们如何通过SOAR的思想来处理这个事件，从而提升IDR流程的效率？

• 告警分诊:一个原始的告警里边可能只包含了少量的事件信息，我们需要在这个阶段使告警丰富化，也就是 Enrichment概念——将原始告警中的IP服务器，终端ID这样的字段，在我们内部的资产库当中查询出详细的信息，并且自动补充到告警信息中。
• 初步决策，比如有些字段命中了白名单库，或者威胁情报显示这是一个非恶意的良性的特征。将告警作为误报直接关闭，减少后面人工审计的运营负担。
• 调查取证：通过SOAR的自动调用能力，可以调用后台的数据，收集更多的IOC信息，我们也可以调用沙箱这个能力对可疑文件进行动态的检测，得到检测结果，从而实现证据的自动收集。
• 溯源关联分析：实现告警事件的上下文相关联事件的聚合。

比如说同一个告警事件，它发生在不同的资产实体上，或者说同一个资产实体，它在一定的时间段内，发生了多类的告警事件.

经过前期的告警分诊、误报关闭、调查取证的几个阶段，原始的事件event就转化为了一个需要人工验证的incident案件。在这个环节安全工程师会根据前面SOAR自动补充和取证的信息做出研判，进入到对这个事件的响应的流程。响应阶段也可以利用SOAR自动地执行安全处置的动作，包括邮件IM通知员工，或创建处置或漏洞工单，或是向防火墙/终端EDR下发安全策略（比如封禁）等等。这样我们就通过SOAR完成了一次告警事件的检测与响应的流程。

剧本编排的概念

以钓鱼邮件检测与响应的剧本为例。

• 检测钓鱼邮件时，首先是提取邮件的信息，包括发件人、收件人、正文里可点击的url链接列表、附件等等。
  • 从AD里查询出员工的相关信息，可以自动去邮件服务器的访问日志里面去查看员工近期有没有异常的登录行为，比如说异地登录，或者是使用非常设备登录等等。
  • URL链接，我们首先去威胁情报里查一下有没有命中情报样本。针对可疑的URL链接，我们可以结合像Whois信息，像域名的信息，对 URL进行评分。
  • 针对邮件的附件也可以做静态分析，看是否包含 office鱼叉。我们还可以利用Cuckoo这样的动态沙箱对邮件附件里的可执行文件做行为检测。我们还可以利用外部的比如Virus Total这样的样本分析平台，来看是否命中恶意样本。
• 经过信息的自动化收集和分析的动作，我们进入到最后的人工审计环节。这个时候安全工程师会结合前面自动收集的信息去做研判。一旦安全工程师识别出这是一个有效的钓鱼邮件，也会通过剧本的方式去执行后续的这些自动化的动作，包括向员工发送告警工单，要求他修改域账号的密码。我们还可以将发件人的邮箱加入邮件安全网关的发件人黑名单列表里，防止他再给其他员工继续发邮件。我们也可以将恶意的或可疑的钓鱼邮件链接的域名加入到我们DNS封禁列表里，来防止进一步的扩散。

结合滴滴的实践经验和探索，介绍贴合甲方实际场景的SOAR建设思路

需要明确SOAR在事件检测响应体系中的定位，也就是它与SIEM/SOC/安全事件响应平台SIRP之间的关系，还有它与TIP威胁情报平台之间的关系。SOAR可以理解为是事件响应平台或者是SOC的扩展能力。 当然SOAR也可以作为一个独立的平台，与SOC和TIP实现打通。

根据Gartner的定义，SOAR是一系列技术的合集，它能够帮助企业和组织收集安全运营团队监控到的各种信息，也包括各种安全系统产生的告警，并对这些信息进行告警分诊和事件分析。

SOAR在甲方如何落地，主要考虑三方面：

• 实现路径:
  • 可以采用商业化的产品，近期我们也看到很多国内外知名安全厂商陆续推出了SOAR这款产品。
  • 我们也可以基于开源工具做二次开发，比如说剧本编排引擎，它特别类似于一个Workflow的工作流引擎，我们可以基于开源的像Activity或者是Airflow这样的工作流引擎去做二次的开发。
  • 使用自研的方式。
• 技术选型：主要是考虑可视化剧本的编排引擎，还有剧本的执行引擎。
• 系统设计：SOAR虽然是一个扩展的能力，但是从系统设计的角度来说，一旦我们引入SOAR，就会将它串联到我们整个的 IDR流程当中。所以SOAR自身的稳定性，还有一些其他的技术指标，比如像EPS每秒处理的事件数，SLA，包括一些其他的benchmark等等，这些也是我们关注的重点。刚才也提到SOAR会串联到IDR流程里，所以它有可能会引入或导致一个单点问题，所以我们也会考虑分布式的部署。还有降级，一旦SOAR不可用的时候，我们的SOC或者事件响应平台能否降级到没有SOAR的状态。

如何评估SOAR的效果和收益？

• 对IDR核心运营指标MTTD和MTTR的提升，它能让我们技术运营投入更少的人力去做更多的事，提升人效。
• 他能否通过SOAR来识别攻击者完整的战术动作，也就是TTP。
• 通过将剧本的引入，将流程案件知识固化下来，牵引我们能力侧的建设。

结合滴滴的经验和探索，介绍一下SOAR的系统设计思想？

首先我们从各个sensor采集到的数据经过ETL存储在大数据的组件当中。我们的策略规则是作用在这些大数据的计算引擎上，像 Spark，Hadoop，还有Flink这样实时的引擎，也包括我们自研的异常检测的引擎，最终产生的异常告警事件会打到我们的event gateway通用事件网关上。这一阶段被我们称为异常检测阶段。

事件网关主要做两个事：一，做标准化，将这些异构的数据源产生的各种类型的告警里的字段格式和数据类型做标准化，以便后面我们在做SOAR编排的时候降低成本。二， 在这个环节我们会做 index，把原始的告警事件索引到数据库里，以便我们后面做关联分析，或者我们可以回溯的时候去实时地查询历史的告警事件数据。

【告警分诊】经过事件网关以后，我们紧接着做两个事情，一个是做Enrichment丰富化，第二个是做威胁情报。我们在丰富化这个阶段会补齐像服务器地址、员工信息、终端信息和调研我们内部的核心的资产库，将告警信息做丰富化。 第二就是我们会初步匹配告警字段里边比如像域名，像文件哈希，去我们本地的威胁情报库里面做匹配。

【调查取证】接下来就进入到我们的核心检测阶段SOAR编排环节，在这个环节我们将各种检测能力抽象成为各种检测引擎，比如像攻击检测引擎、误报检测引擎、调查取证引擎和关联分析引擎等等。

• 【黑名单】攻击检测引擎是做什么？主要是根据告警事件里的一些字段去我们本地的黑名单库列表里做匹配，一旦确认命中我们的黑名单，就可以不需要做后面一些列复杂的调查取证和关联分析工作，可以直接交给人工来做研判，甚至对它可以绕过人工来做自动化响应。

• 【白名单】误报检测是根据字段里边的一些特征，以及我们之前配置的白名单规则，命中了白名单，这个事件我们可以把它自动关闭掉，以减少后面调查取证的负担。

• 调查取证我们是将一些通用的外部接口和能力封装成一些函数或者脚本，来做自动化的调用。而这些封装的能力之间，我们也是以一个子剧本的方式来进行编排，它可以根据剧本流程的配置来做自动化的执行和调用。

• 关联分析引擎也是基于我们配置好的一些关联分析的规则，来针对这一个告警事件的上下文，或者一段时间内它同资产的一些其他告警事件来做关联和聚合，上报给人工去做研判。

这些不同的检测引擎之间，我们也是通过剧本的方式把它进行一个整体的编排。有些我们可以先经过攻击检测引擎，误报检测引擎，再做调查取证和关联分析；而有一些告警类型，我们通过剧本的编排，它就不需要去做攻击检测了，比如他通过误报检测就可以直接到调查取证检测。这些其实都是通过剧本来实现一个动态编排。

【人工验证】经过这个阶段的检测，原始事件就形成了一个具体的需要人工验证的案件，也就是incident。从原始的事件到案件，这个阶段我们称它为是检测阶段的SOAR编排。【自动处置】这阶段经过人工的验证，如果是一个有效的案件需要经过处置的话，它就会进入到后续的自动处置的流程里面。而这一阶段我们也是通过剧本的方式，将各种处置能力封装来自动编排上。这里边包括像通过邮件和IM消息的方式来通知用户，也包括我们调用工单系统，还有就是我们调用 EDR/IPS/防火墙的一些封禁策略等等，把它封装成自动的脚本，通过剧本的方式做编排，做自动的调用。

在做SOAR系统设计的时候，是如何把知识体系来融合到系统设计里的呢？

在上文提到的情报交互里有一个STIX2.0协议，STIX2.0有很多个构件，其中有几个构件其实是可以指导我们去做异常检测规则的开发，以及SOAR编排里的关联分析和处置动作的。

• indicator，就可以指导我们去做异常检测阶段的IOC规则开发；

• Attack Pattern，描述的其实就是TTP，可以指导我们在SOAR检测阶段去做关联分析规则；

• course of action构件，它是指导我们在做响应处置阶段的SOP的流程。

我们前面也提到了ATT&CK模型，其实ATT&CK模型和STIX2.0之间是有映射关系的，我们可以将我们的异常检测规则映射到ATT&CK模型上，主要是做两个事，第一个就是我们根据现有的检测点，可以总体来看我们对ATT&CK的覆盖率，这样它能牵引我们去做能力侧的建设，也就是检测策略建设。当我们发现缺少哪一部分的检测能力，我们就可以去部署新的sensor，开发新的IOC规则。

我们也可以结合ATT&CK模型去和我们的真实的日常运营中的案件做结合，去查看我们ATT&CK热力图，去从整体安全态势上看我们哪些场景是经常会被攻击的。我们也可以结合资产的重要性、等级和实际发生的案件，通过一个公式来计算出我们整体的风险值。

【异常检测评估指标】整个SOAR流程和指标体系也是紧密结合的，包括我们在异常检测阶段有能力矩阵的覆盖率这样的指标。还有我们在检测阶段的SOAR编排决定了我们的MTTD（平均检测时间）的指标，以及在响应阶段SOAR关联了我们的MTTR（平均响应时间）指标。

这样我们就围绕着SOAR的系统设计，将IDR事件检测与响应流程、SOAR的自动编排、知识体系和指标体系，都融合在了我们整个的SOAR的系统设计思想里。

DataCon2020-恶意加密流量检测

• 思科AISec’16：《Identifying Encrypted Malware Traffic with Contextual Flow Data》：https://www.cnblogs.com/bonelee/p/9604530.html

一、流量处理的工具

zeek

使用 Bro/Zeek 分析 PCAP

流量分析的瑞士军刀：Zeek

joy

CICFlowMeter：

二、A Novel Malware Encrypted Traffic DetectionFramework Based On Ensemble Learning

zeek:https://docs.zeek.org/en/master/logs/index.html zeek-flowmeter:https://github.com/zeek-flowmeter/zeek-flowmeter zeek-tls-log-alternative:https://github.com/0xxon/zeek-tls-log-alternative

概述：

在我们的工作中，有一些定义。首先，将5元组定义为源IP、源端口、目标IP、目标端口和协议。其次，前向流是从客户端到服务器具有相同5元组的数据包集。反向词流与正向流相似，但与五元组相反。最后，流动是向前流动和向后流动的结合。由于我们从流量中提取的特征是异构的，我们不能简单地将它们合并并以常见的方式将它们装配到单个分类器中。我们将不同的特征匹配到相应的分类器中，并进行多数投票以获得最终结果。同时，我们考虑了flowlevel和host级别的行为。对不同级别的特性进行聚合和分析，以提高框架的TPR和较低的FPR。图1：。概述了我们的框架。我们将介绍每个特性以及相应的分类器、实现和性能。

2.1 数据包级

（1）长度分布

根据Cisco的研究【17】，恶意软件和普通软件在正向流和反向流中的数据包长度分布不同。 例如，当我们使用谷歌搜索时，客户端向服务器发送少量数据包，然后服务器返回大量数据包。然而，恶意软件的作用恰恰相反：恶意软件通常让客户端将数据传输到服务器，然后服务器定期返回调度命令。无论是否加密，数据包长度始终可见，因此它适合作为一种功能。我们将数据包长度和方向编码为一维独立特征。我们推测，感染恶意软件的客户端和服务器之间的一些控制消息的长度总是相似且频繁的，这具有很好的区分程度。我们考虑每个可能的数据包长度和方向元组。由于Internet上的最大传输单元（MTU）是1500字节，并且数据包的方向有两个发送或接收方向，因此我们的长度分布特征是3000维。为了提取这些特征，我们计算具有不同长度的所有数据包的数量，并进行规范化以确保概率分布。我们使用随机森林（RF）算法来处理这些特征。因为它能更好地处理高维特征，并且具有可解释性。

（2）长度序列

第二部分，在不使用序列信息的情况下，我们只使用了数据包长度的统计特征，这可能会在时间上丢失一些信息，因此我们提取了数据包长度序列。我们在每个客户端的双向上取前1000个数据包长度，并将其放入TextCNN算法中以提取局部序列关系。因为该算法运行速度快，精度高。文本数据的卷积神经网络TextCNN【22】是一种用于句子分类任务的有用的深度学习算法。在这种情况下，我们将每个数据包的长度视为一个单词，长度序列相当于一个句子。

（3）服务器IP

在我们的数据集中，服务器IP地址是一个重要的标识符。我们假设，在同一地区，如果客户端感染了相同的恶意软件，则可能会导致其访问相同的服务器IP地址。因此，我们还考虑了对服务器IP地址的访问。值1或0表示是否访问了特定的服务器IP地址（一个热编码）。我们使用朴素贝叶斯（NB）算法来处理这些特征。由于朴素贝叶斯算法是一种非参数算法，其本质是寻找特征和标签之间的关系。因此，它可以被视为一个黑名单。

（4）词频分类器

X509证书在Internet上广泛使用。它们用于验证实体之间的信任。证书颁发机构通常将X509证书链接在一起。如图2所示。[23]，X509证书提供URL、组织、签名等信息。我们从培训集中每个客户端的TLS流中提取X509证书链，并获取证书中主题和颁发者中包含的单词。我们将所有单词组合在一起，并将客户的流量视为由这些单词组成的句子。与B部分类似，我们计算每个单词的数量并将其用作特征。0我们使用朴素贝叶斯（NB）算法来处理这些特征。如果测试集样本证书中的所有单词从未出现在训练集中，我们将直接推断它是恶意的。因为训练集包含最流行的域名。

==（5）TCP状态马尔可夫==

我们发现恶意流量和正常流量之间TCP连接状态的分布是不同的。表一说明了可能的TCP连接状态24:

我们按照流出现的时间对其进行排序，然后使用马尔可夫随机场转移矩阵（MRFTM）对该特征进行编码。MRFTM在建模连接状态序列时很有用。MRFTM[i，j]中的每个条目统计第i个和第j个状态之间的转换次数。最后，我们对MRFTM的行进行规范化，以确保适当的马尔可夫链。然后我们将其重塑为一维向量，也就是说，我们使用MRFTM的条目作为特征。我们使用随机森林（RF）算法来处理这些特征。

2.2 会话流级

（6）会话流量统计

在加密流量中，上述5种分类器在主机级使用不同的特征提取方法和分类方法。此外，为了进一步提高准确率，防止恶意软件由于缺乏领域知识而欺骗分类器，我们还提取了TLS握手中的明文信息。在这个分类器中，我们首先考虑流级特征。我们仅选择TLS流，并分析每个流。一旦推断流是恶意的，就会推断相应的客户端被感染。我们对TCP和TLS协议进行了深入分析，提取了1000多个维度的流级特征，包括以下部分：

• TCP连接状态特性：如F部分所述，我们对每个流的TCP连接状态进行一次热编码。
• 统计特征：我们还提取常规统计特征，表II显示了相关特征名称和描述。

• 长度马尔可夫特征：数据包长度序列的操作类似于F部分中的TCP连接状态序列。长度值被离散为大小相等的容器。长度数据马尔可夫链有10个箱子，每个箱子150字节。假设一个1500字节的MTU，任何观察到的大小大于1350字节的数据包都被放入同一个bin中。

• TLS握手功能：我们发现客户端和服务器的TLS协议版本在恶意和良性TLS流之间有不同的分布，因此我们对客户端和服务器的TLS版本进行了一次热编码。此外，由于恶意软件可能使用旧的密码套件，我们在客户端和服务器上都对密码套件和扩展进行n-hot编码，即将所有密码套件和扩展扩展扩展为一维0向量，如果当前流使用某个密码套件或扩展，则相应的位置集值为1。

• TLS证书特性：我们发现，在恶意流中，很大一部分叶证书是自签名的，或者自签名证书出现在证书链中。恶意软件喜欢利用的自签名证书的成本很低。因此，我们分析从服务器发送的证书：证书链是否包含自签名证书、叶证书是否过期、证书版本、证书有效期、公钥长度、是否发生警报。同时，考虑到之前的词频分类器，我们发现一些词无法区分恶意和良性，因此我们还将流词频添加到流特征中。

• 合并和适配：我们将上述功能合并到5元组（源IP、目标IP、源端口、目标端口和协议）中，并将其适配到随机林（RF）算法中。一旦流被推断为恶意，相应的客户端就会被推断为受到恶意影响。

在本节中，我们使用来自真实恶意软件的加密流量来评估我们的框架。首先，我们描述了数据集的格式。其次，我们分析了每个分类器的有效性以及集成后的有效性。然后，我们展示了我们的集成学习方法的优势。

数据表示：

如表三所示，列车数据包括3000台正常主机产生的正常流量和3000台恶意软件感染主机产生的恶意流量。我们的任务是检测测试数据中的客户端IP地址是否感染了恶意软件。

表V显示了每个分类器的得分。我们将每个分类器与投票结果进行比较，发现集成后的最终效果优于任何单个分类器的得分。我们的方法得分为86.6，TPR为95.0%，FPR为8.4%。流量统计分类器得分最高，其次是长度序列分类器和长度分布分类器。我们在每个分类器中使用默认参数。由于流级特征包含最丰富的信息，因此流统计分类器的性能最好，正如我们所期望的那样。我们可以推断，数据包长度是一个重要特征。事实上，在流量分类（非恶意流量检测）领域，有很多优秀的作品使用数据包长度进行分类，并取得了很好的效果[11][25]。目前，已有的一些基于机器学习的工作[8][9]与我们的流统计分类器或流合并分类器相似，也就是说，它们只使用流级特征或主机级特征。经过实验，我们的最终效果已经超过了每一个分类器。这表明我们的框架是有效和健壮的。此外，框架可以很容易地调整每个分类器的概率阈值，以提高TPR或降低FPR，以适应不同的场景。

三、知乎-s1mple

DataCon2020加密恶意流量检测初赛Writeup及总结反思

• 特征选择（Feature Selection），选取对于区分正常/恶意流量有明显作用的 Features。

  • TLS客户端指纹信息
    • 客户端支持的加密套件数组（Cipher suites），服务器端选择的加密套件。
    • 支持的扩展（TLS extensions），若分别用向量表示客户端提供的密码套件列表和 TLS 扩展列表，可以从服务器发送的确认包中的信息确定两组向量的值。
    • 客户端公钥长度（Client public key length），从密钥交换的数据包中，得到密钥的长度。
    • Client version，the preferred TLS version for the client
    • 是否非CA自签名，统计数据表示，恶意流量约70%出现非CA认证服务器且自签名的情况，非恶意流量约占0.1%。此项判断的依据是：未出现 CA: True 字段（默认非 CA 机构）且 signedCertificate 中的 issuer 字段等于 subject 字段。

  在进行TLS握手时，会进行如下几个步骤：

  1. Client Hello，客户端提供支持的加密套件数组（cipher suites）；
  2. Server Hello，由服务器端选择一个加密套件，传回服务器端公钥，并进行认证和签名授权（Certificate + Signature）；
  3. 客户端传回客户端公钥（Client Key Exchange），客户端确立连接；
  4. 服务器端确立连接，开始 HTTP 通信。

  

  • 数据包元数据
    • 数据包的大小，数据包的长度受 UDP、TCP 或者 ICMP 协议中数据包的有效载荷大小影响，如果数据包不属于以上协议，则被设置为 IP 数据包的大小。
    • 到达时间序列
    • 字节分布
  • HTTP头部信息
    • Content-Type，正常流量 HTTP 头部信息汇总值多为 image/*，而恶意流量为 text/*、text/html、charset=UTF-8 或者 text/html;charset=UTF-8。
    • User-Agent
    • Accept-Language
    • Server
    • HTTP响应码
  • DNS响应信息
    • ==域名的长度==：正常流量的域名长度分布为均值为6或7的高斯分布（正态分布）；而恶意流量的域名（FQDN全称域名）长度多为6（10）。
    • ==数字字符及非字母数字(non-alphanumeric character)的字符占比==：正常流量的DNS响应中全称域名的数字字符的占比和非字母数字字符的占比要大。
    • DNS解析出的IP数量：大多数恶意流量和正常流量只返回一个IP地址；其它情况，大部分正常流量返回2-8个IP地址，恶意流量返回4或者11个IP地址。
    • TTL值：正常流量的TTL值一般为60、300、20、30；而恶意流量多为300，大约22%的DNS响应汇总TTL为100，而这在正常流量中很罕见。
    • 域名是否收录在Alexa网站：恶意流量域名信息很少收录在Alexa top-1,000,000中，而正常流量域名多收录在其中。

• 特征提取（Feature Extraction），从 pcap 文件中提取上述 Features，并转换为模型训练所需要的格式。我们选择的特征提取工具为 Zeek。特征提取我们采用的工具是 Zeek，它的前身是 Bro，一款网络安全监视（Network Security Monitoring）工具，它定义了自己的 DSL 语言，支持直接处理 pcap 文件生成各类日志文件，包括 dns、http、smtp 等：Zeek 网上有一些现成的脚本，我们采用的是 Zeek FlowMeter，它基于 OSI 七层协议的网络层和传输层，可以分析并生成一些 Packets 到达时间序列、Packet 字节大小和元数据等新特征。在使用时，我们需要在 local.zeek 配置文件中加入 @load flowmeter，这样 Zeek 在执行时会加载 flowmeter.zeek 并生成对应的 flowmeter.log，下面列出了 FlowMeter 提取出的一些特征，包括上下行包总数、包负载均值方差等。其他详细的特征请见 zeek-flowmeter GitHub官方文档。除 flowmeter.log 之外我们还需要关注 conn.log、ssl.log 和 X509.log。这几个日志共同字段 uid 是 Zeek 根据一次连接的源/目的 IP、源/目的端口四元组生成的唯一 ID。为了方便后续的处理，我们将这几个日志文件统一读入，使用 uid 字段连接后转成 csv 格式输出到文件。最终我们提取的特征如下：

  

• 模型训练（Model Training），选择合适的机器学习模型对三类 pcap 文件进行训练和预测。我们选择的 Python 机器学习库为 scikit-learn。

  • Anomaly Detector：在 black 数据集中同时存在恶意流量和正常流量，没有明确的标注，无法直接用于训练分类器。而 white 数据集中都是正常流量，可以先用 white 数据集来训练一个 Anomaly Detector 分类器。然后用这个分类器在 black 数据集中推理得到哪些是恶意流量。我们的模型选取的隔离森林 IsolationForest。
  • Misuse Detector：假设这些由异常检测器识别的可疑流量是恶意流量，我们就有了恶意流量的标注。接下来我们用这些恶意流量 labels，结合 white 数据集中的正常流量 labels，来训练一个 Misuse Detector。我们选取了 XGBoost 基于树的模型，目标选取为多分类问题（分类数为2）。

四 、加密恶意流量检测方向（清华大学HawkEye战队）

清华大学HawkEye战队：https://datacon.qianxin.com/blog/archives/122

4.1 概述

我们所采用的检测方法的总体结构是让多个分别利用不同的异构特征训练而成的分类器进行多数投票 (Majority Voting) 的方式来获取最终的判定结果。

由于我们所采用的多种特征是异构数据， 且具有不同的组织特点，我们并没有直接采用将这些特征统一编码并输入到集成学习分类器中的常规方式，而是针对各个特征的特点分别构建对应的分类器，并利用他们的分类结果进行投票，最终取得多数票的分类结果被定为最终的分类结果。

参与投票的多个模型中部分使用了多维特征综合分析，另一部分使用经过分析后黑白样本区分较大的、置信度较高的单维特征对多维特征中的潜在的过拟合和判断错误进行消解。同时，我们考虑到了数据包级、流级、主机级多维度的行为建模，将不同层次的数据进行聚合分析，提升对于黑白样本建模的准确度。图1展 示了我们方案的整体流程。下面我们将分别介绍我们所采用的特征及对应的分类器、投票机制、 实现和性能以及展望和总结。

4.2 特征选取与子分类器

下面我们将详细介绍六个参与投票的子模型中的每一个模型所采用的特征及对应的分类器， 以及设计的动机和意义。

（1）包长分布特征（3000维）

不同的软件在通信数据的体量上具有不同的特点，我们认为功能或实现相似的软件会具有 相同的数据包体量分布特点，正如视频软件的下行流量通常远大于上行流量，而恶意键盘记录 器的上行流量总是远大于下行流量一样。

将每一个可能的报文长度和方向的二元组视为包长分布特征中的一个独立的维度。由 于以太网最小帧长为64 字节，而互联网的最大传输单元通常是 1500 字节，报文的方向只有收发两个方向，我们的包长分布特征是一个维数约 3000 的概率分布。

编码方式与分类器：

对该特征的提取，我们采用 以频率估计概率的方式，统计每个流量样本中的各个长度和方向的报文的数量，并除以报文总 数得到其概率分布。

由于包长分布的特征本质上是一个离散概率分布，最直接的分类器应该是基于度量的分类 算法，通过度量分布之间的相似性大小来判断其类别所属。我们采用了 Hellinger 距离的度量方式与kNN分类算法，Hellinger 距离是在概率分布空间对欧氏距离的模拟。由于kNN算法并不需要训练过程，而在分类过程中需要计算待分类的样例与已有样本集中的每个样例的相似性度量结果，因此其运行效率十分低下，于是我们也考虑了采用随机森林的分类器来利用这一特征的方式。

（2）证书主体与签发者黑白名单特征

我们认为决定一个软件是否是恶意软件不仅仅取决于其通信内容，也取决于其通信的对象， 而通信内容由于加密无法作为可辨识的特征，因此我们着重考虑了客户端流量样本中的通信对象。

在 TLS 建立连接的过程中，服务端发来的证书中的叶子证书的 Subject 字段表明了客户端的直接通信对象，而 Issuer 字段则表明了该证书的直属签发机构。

Subject 字段里的 common name 通常是一个域名，我们认为这将是一个很重要的标识信息，因为恶意软件与恶意域名关联的可 能性较大。图3中展示了恶意和正常证书中主体和签发者的情况，可以看出黑白样本有明显区别 并都存在着访问频次较高的项。

编码方式与分类器：

我们对训练集中的每个流量样本统计了其中的叶子证书所涉及到的不同 Subject 和 Issuer 的 数量，并记录每个流量样本与他们通信的频数。

X509证书在Internet上广泛使用。它们用于验证实体之间的信任。证书颁发机构通常将X509证书链接在一起。如图2所示。[23]，X509证书提供URL、组织、签名等信息。我们从培训集中每个客户端的TLS流中提取X509证书链，并获取证书中主题和颁发者中包含的单词。我们将所有单词组合在一起，并将客户的流量视为由这些单词组成的句子。与B部分类似，我们计算每个单词的数量并将其用作特征。0我们使用朴素贝叶斯（NB）算法来处理这些特征。如果测试集样本证书中的所有单词从未出现在训练集中，我们将直接推断它是恶意的。因为训练集包含最流行的域名。

（3）通信 IP 地址黑白名单特征

除了证书中的 Subject 和 Issuer 信息外，服务端 IP 地址是另一个表示软件通信对象的标识 符。有少数流量样本中出现了缺少证书的情况，且我们认为同一地区遭受同类恶意软件感染很 可能会造成他们对相同的 IP 地址的访问，因此我们将流量样本中的远程 IP 地址的访问情况也 作为一个判断是否包含恶意流量的依据。

（4）流级荷载无关特征提取

对于黑样本的流标记问题存在一定问题，由于被感染的主机也可能会进行正常通信，而且 恶意软件也可能出现正常行为

我们首先考虑流级特征，由于 TCP 连接可以由流的四元组确定，所以恶意通信一般是指流 级别的，分析每条流的黑或白是十分合理的。我们综合考虑了已有相关工作 [1–3]，以及对 TCP、 TLS/SSL 协议进行深入分析，共提取了超过 1000 维与荷载无关的流级特征，包含如下几部分:

• 元数据（Metadata）：即单条流的基本统计数据，包含持续时间（duration）、总的流入（inbound）/流出（outbound）的字节数、数据包个数；
• 窗口序列统计特征：我们对出/入流量分别维护了包时间间隔和包长度的窗口，每个窗口提取统计特征，包含平均值、标准差、最大值、最小值；除此而外，我们发现仅仅关注一整个窗口的特征粒度不够细化，为了更加精细化的对流量行为进行捕获和建模，我们关注窗口中的每个数据包，并使用马尔科夫转移矩阵的方式捕获相邻包之间的关系。以构建包长窗口的马尔科夫矩阵为例，我们首先将包长均匀分成 15 个桶（bin），然后建立 15×15 的矩阵，每个元素表示从行转移到列所代表的的桶，最后对矩阵进行行的归一化处理，将其转化为概率形式；
• TLS/SSL 握手包特征：首先我们发现本赛题中客户端和服务器端都出现了多种不同的协议类型，而黑和白训练集中客户端和服务器不同版本的分布是不同的，因此协议版本可以 作为一个特征，我们将客户端和服务器端使用的 TLS 版本进行独热（one-hot）编码；同时 我们关注到 Hello 包中 GMT Unix Time 字段在黑/白训练集中的分布也有所不同，因此我 们将客户端和服务器端的 GMT Unix Time 的是否存在、是否使用随机时间编码为 0/1 的特征；此外，由于恶意软件和恶意服务器使用的加密套件和列表很有可能与正常的加密流量 有所区别， 我们将客户端与服务器端的加密套件（列表）和扩展列表进行独热编码，即将 所有可能的加密套件和扩展列出展成一维 0 向量，当前流使用的套件和扩展对应的位置赋 值为 1；
• TLS/SSL证书特征：服务器端证书对于区分正常和恶意流量有着重要的作用，如恶意通信的证书多采用自签名的方式。因此我们对服务器端证书进行了特征挖掘，主要选用如下的 0/1 特征： 是否自签名、是否过期、版本号、证书有效期、公钥长度；同时，我们考虑到之 前模型发现有些证书主体域名单一使用无法区分黑/白的情况，因此也嵌入到多维特征中， 使用独热编码对训练集常用证书主体域名进行独热编码。

（5）主机级荷载无关特征聚合 (流级统计信息)

单独的看每条流可能漏掉了流之间的关联行为即主机级别的行为，比如恶意软件在发出正常的访问谷歌流量后可能就要开始进行恶意传输。再比如，有少量正常流也会出现自 签名，如果我们单独看流，可能就会误判，但是如果我们基于主机提取特征发现同一 IP 下有多条流都是自签名，则我们就会有很大的信心认为这是恶意的。因此，我们将上一小节中流级别 的特征进行聚合，并以流为基本单位提取主机级别特征。

主机级特征聚合部分主要考虑了如下的特征:

• 总包个数，每条流的平均包个数，时间间隔、包长的均值，以及上一个小节中证书部分的相关特 征，即自签名流数量，过期流数量，有效期过长（比如 100年）的流数量及其均值。
• TLS 半连接 和无连接

Datacon2021 网络流量分析 Writeup

一、恶意流量分析

1.1 比赛题目

本题文件中提供了一段时间的失陷主机的通讯流量，参赛选手需审计该流量包，进行追踪溯源，找到真正的恶意服务器，最终获取key，此外本题还设有可以获得额外分数的彩蛋题目。

以主机端的网络流量为基础，通过流量审计和主动探测的方式，对攻击者进行追踪溯源和行为分析。

二、恶意攻击指令识别

1.2 比赛题目

本题中提供了一段时间的失陷主机的通讯流量和单个指令的流量样本的提供给参算选手，参赛选手需通过恶意软件通讯特征筛选出恶意流量，并通过提供的单一的下发指令流量作为样本，分析出通讯流量（http、dns、https）中下发的指令序列。

域前置技术：

各命令对应的数据流也有不同的特征。比如，screen 命令会有来自服务端和客户端双向的大流量，hash命令有来自服务端的大流量和客户端的小流量，sleep 命令仅有get数据包，没有post数据包等，如图所示。

三、加密代理流量分析

3.1 比赛题目-阶段一 【流量审计】

本题中，管理员获取了内网中由数个不明用户构建的加密代理节点，这些软件使用的通信协议不完全一致，管理员只分别提取了一定数量的样本。参赛选手需要通过不同的加密代理特征，按照样本对目标流量进行分类。

概述：本题共有11个加密代理。对应11个类别，其中11个类别共包含带标签样本51个。无标签样本1000个，需要们通过分析51个带有标签样本，找到11个类别所对应的具体的特征，从而对1000个测试样本进行分类。

由于此题类别数目较少，只有圱圱个类别，且每个类别对应的带标签样本数目也很少，因此我们采取规则匹配的方法来实现分类。我们的实验框架如图所示。

首先通过分析不同的类别特征制定每个类别对应的规则，从1000个测试样本的pcap包里根据规则从提取相应的数据，继而基于这些数据进行匹配分类。最终对于极少数没有匹配结果的样本，采用人工审查的方式进行分类。值得注意的是，由于同一个样本可能满足多个类别的特点，所以不同类别的规则匹配顺序会对分类结果有一定影响。

3.1.1 加密代理特点分析

加密流量的特征一般包含协议特征、数据元统计特征。尤其应该注意TLS协议的流量特点。

对于恶意加密流量和良性加密流量的区别，cisco的研究表明【6】显示，对于TLS协议特征，在ClientHello数据包中，恶意软件提供于普通客户端完全不同的一组密码套件，此外，这些密码套件通常很脆弱或已经过时。相比之下，几乎所有良性应用程序都提供相同的密码套件。除此之外，恶意软件通常提供很少的扩展，而正常用户最多有9个拓展。此外客户端的公钥长度也存在很大的差异。在ServerHello和Certificate中，恶意软件查询的服务器会选择不常见的密码套件，因为优先提供的密码套件的大小受到限制。此外，证书的有效期和SAN条目数量也存在区别，而且恶意服务器发送自签名证书的比例也比普通服务器高一个数量级。

对于数据元统计特征，恶意流量于良性流量的特征差异主要表现在数据信息、数据包的大小、到达时间序列和字节分布等。

3.1.2 特征分析与规则制定

基于上述加密代理的特点, 我们分析 51 个带标签的样本, 并着重关注了 TLS 特征。我们对协议信息、TLS 应用数据、TLS 握手信息、数据信息、数据 包大小等特征进行了分析, 找到了有效区分的方法。

其中有三个类别有明显的区别, 只关注协议信息即可区分开来

• 类别 0 对应的 pcap 包所有的通信流量只包含 UDP 协议, 而在 11 个类别中, 只有类别 0 具有此特点。
• 类别 6 中, 发现只有类别 6 的流量中同时出现了 TCP 和 UDP 协议, 此外, 只有类别 6 中出现了 OCSP 协议。
• 类别 8 中, 我们发现了 WireGuard 协议, WireGuard 是一种 VPN 协议, 它的大量出现使得类别 8 的特 征变得明显。通过以上方法, 我们可以通过协议信息将类别 0、类别 6、类别 8 区分出来。

剩下的 8 类需要我们做进一步区分, 我们发现类别 4、类别 5、类别 7、类别9 的通信流量中只包含 TCP 协议, 类别 1、类别 2、类别 3、类别 10 的通信流量 由 TCP+TLS 协议组成。

到了此时, 我们的进度开始变得缓慢, 因为剩下的 8 类 没有很明显的区分特征。但是在我们的不觖努力下, 我们逐渐有了突破, 我们 发现：

• 在类别 1 中, 存在 tls.app_data 字段的前 12 位为 00:00:00:00:00:00 的流量, 如图3.2所示;
• 在类别 7 中, 存在 data.data 字段的前 6 位为 00:00:00 的 流量;
• 在类别 5 中, 存在 data.data 字段的第 5 位到第 12 位为 \(48: 00: 02: 8 \mathrm{a}\) 的 流量, 如图3.3所示;
• 在类别 3 中, 存在 tls.handshake.extensions_length 字段值 为 156 的流量; 在类别 10 中, 存在 tls.handshake.ciphersuite 值为 \(0 \times 1301\) 并且 tls.handshake.type 值为 2 的流量;
• 在类别 2 中, 存在 tls.handshake.ciphersuite 值为 0x1303 并且 tls.handshake.type 值为 2 的流量;
• 在类别 4 中, 存在 frame.len 值为 1514 和 71 的流量, 值得注意的是, 当出现 frame.len 为 1514 时, 通常下一 条流量的 frame.len 为 71 ;
• 在类别 9 中, 存在 data.len 的值为 1424 的流量。 综上所述, 我们可以通过以上方法将 11 个类别区分出来, 文字描述略显繁 杂, 表3.1展示了我们制定的匹配规则。

3.2 比赛题目-阶段二

同一代理协议、少量样本标签

身份不明的用户或恶意软件可能使用未授权的加密代理进行通信，访问恶意网站或正常网站。确认这些行为的详细信息有利于对可疑用户行为和恶意软件进行分析，但截获的加密流量无法进行破解。

本题中，管理员使用机器自动产生了恶意软件与多个恶意网站（或正常网站）通信产生的，经过加密代理的流量。根据已知的信息，管理员提取了一部分可以确定类别的样本信息。参赛选手需要利用管理员生成的样本，标记每个流量包可能访问站点的标签。

3.2.1 概述

题目主要考察加密流量识别能力，需要选手根据提供的已知类别样本，识别测试数据可能可能访问何种恶意站点。经过对题目和数据的初步分析，我们发现所 提供加密流量数据均由同一加密代理软件产生，且数据包中并未观测到特殊应用层协议可供分析。因此，我们确定了从统计特征和行为特征两个角度角度对加密流量样本进行审计分析，深入挖掘标识访问不同恶意通信流量的有效特征，从而实现对恶意流量的自动化分类的基本思路。

图3.6展示了我们方案的整体流程。具体来讲，我们分别提取训练样本的多维统计特征及标识行为特征的包长序列特征，分别构建分类器，基于投票机制结合多维分类结果来获得最终判定结果，从而避免异构数据混淆和权重问题带来的误分类情况。接下来我们将分别介绍我们所采用的特征及对应的分类器、实现和性能以及展望和总结。

3.2.2 结题思路

数据分析：拿到数据后我们首先对提供的训练样本和测试样本进行初步分整理分析;train_data文件夹中， 共包含1401个流量样本，除第85类只有2个样本，29、52、94只有6个样本，平均每个家族都有13-15个样本。下面我们将详细介绍六个参与投票的子模型中的每一个模型所采用的特征及对应的分类器，以及设计的动机和意义。

（1）数据包特征

由于网络中不同的服务商提供的服务不同，导致数据流中的==数据分组大小==存在一定的差异，如流媒体的数据分组较小以提高播放流畅度而文件下载通常是以最大的负载进行传输[7]。由于数据分组大小与网络服务有关且不受加密技术的影响，因此可以根据数据分组的分布对加密流量进行识别。

我们根据方向的不同，首先针对每个pacp文件分别提取前向包有效负载长度序列和后向有效负载长度序列。然后每个序列分别提取方差、均值、四分位值、众数、平均数、最大值等特征从而描述分布特点。

由于包长分布的特征本质上是一个离散概率分布，特征值之间的差值可以很好的描述不同分布之间的差异，因此我们选择基于欧拉距离度量的KNN分类算法。KNN通过测量不同特征值之间的距离来讲待检测样本分类到训练样本之中，因此并不适用于特征维度过高的数据，我们所提取的圱圲维特征可以较好地应用于此。

(2) 流级特征

根据五元组（源IP、目的IP、源端口，目的端口，协议）划分得到的会话数据能够最大程度的保留客户端和服务端之间的通信特征信息，因此成为了流量分析领域常用的分析对象[8].通信双方的 会话级别的统计特征能够很好的反映不同类型应用的属性。

• 恶意通信往往具有持续时间短、传输速率快、出入站比例大等特点；
• 正常流量则往往具有持续时间长、包长分布均匀、数据包到达间隔稳定、出入站比例较小等特点。

本题中提供的加密流量只是对数据包的载荷进行加密，对流的特征属性的影响较小，因此可以根据流量的属性如间隔时间，报文大小，流持续时间等提取相应的流量特征，根据流量特征准确的识别出访问不同网站的加密流量的类别。如图所示，为题目提供训练样本中不同类别的加密流量在流级统计特征上的分布差异。

提取方式：

我们利用SplitCap工具按照（源IP、目的IP、源端口, 目的端口, 协议）五元组将提供的训练和测试数据分别拆分成单独的会话, 并过滤掉末完成三次握手的会话。我们认为末完成三次握手的会话可能是由于抓包或是题目设定原因出现了截断, 而这种不完整的会话若何混合在其他完整的会话中一同提取统计特征, 将会使特征变得混淆而不可用。因此我们从全部切分得到的46,667个会 话文件中过滤后得到可用于特征提取和模型训练的 22,211 条完整会话。

SplitCap划分pcap文件:将pcap拆分为较小pcap的文件。

在确定并获得训练数据后, 我们直接实现了从原始报文数据中的流量特征提取, 没有依赖tshark等第三方工具。具体来讲, 我们基于 python和dpkt库，直接将pcap文件作为二进制流读取并依据协议解析每个字段, 从而计算80+维的会 话统计特征。具体使用特征如表3.4所示:

dpkt:

scapy:

joy：

特征提取后, 我们选择XGBoost作为流级特征的分类算法。XGBoost (eXtreme Gradient Boosting）是基于Boosting框架的一个算法工具包 (包括工程实现), 在 并行计算效率、缺失值处理、预测性能上都非常强大。同时基于树的方法可以 直接对特征重要性进行评分, 这对于后续挑选重要特征、降低特征维度、删除冗余特征十分方便，同时还可以对max_depth参数进行限制防止特征过于细化和线性相关带来的过拟合风险。

(3) 网站行为特征

由于本题数据说明提到所有样本均由同一加密代理生成，差异在于访问了不同的目标网站。而恶意网站由于其目的和功能的不同，在通信过程中往往存在特定的通信模式和规律，通过分析比较有效负载长度序列的异同，可有效定位不同类别的访问流量【9】

与流级特征中提取的包长统计特征不同，该部分重点关注的是序列特征，通过数据包长度的时序性交错变化来反映不同网站的应用和业务特征。在加密代理不变且网站业务功能稳定的情况下，利用基于包长序列的网站应用行为特征进行加密网站流量分类具备相当的稳定性和精确度。

为证明该特征的有效性, 我们先将序列长度窗口设定为 11 , 在 1401 个训练样本中获得了1396个样本所包含的独特包长序列, 并基于匹配的强规则确定4734个样本的标签。此次提交获得了55.18分, 即提交内容获得了94%左右的 正确率，从根本上证明该特征的有效性。

在获得以上的验证结果后，我们开始思考如何将以上的匹配规则“软化” 成机器学习可以处理的形式。我们希望能够兼顾包长序列在莫以类别的出现频 率和 “特异程度”, 结合以往课程和信息检索相关知识,

我们想到了 TF-IDF(term frequency-inverse document frequency) 技术。即将包长序列视为 \(i\) tem, 拼接后形成 对应该类别的 “文档”, 随后基于tf-idf思想, 计算每个item的出现频率tf和特异性程度idf, 两者结合后用来代表该类别的特征向量。在本题提供的数据中, 我们共得到了1306维的特征, 也就是说1396的训练样本和8109的测试样本, 共出 现不同的包长序列1306个。

在获得特征向量后, 我们依然选择了在前面就已经取得良好表现的梯度提升树算法一XGBoost作为该部分的子分类器。主要是考虑到该部分特征向量维 度较高, 且容易出现过拟合的问题。因此, 我们在设定树模型的超参数时, 集中 调整了如max_depth、colsample_bytree、subsample以及eta、lambda、alpha等 控制数据采样和正则化程度的超参数。

3.2.3 结果验证与评估

我们基于 python的sklearn和dpkt库实现了相应的机器学习模型和特征提取。 由于所提供数据包规模不大, dpkt并为遇到内存爆炸无法打开的情况, sklearn中 所包含的KNN模型和XGBoost模型则均采用之前多次试验得到的较好的超参数设置。而且在流级特征分类时, 我们基于XGBoost树模型特有的特征重要度评分功能, 进行了一定程度的特征选择, 最终得到了纬度较低且精确度较高的模型作为最终使用的判定模型。

给予我们的多级别特征提取和分类器投票结果, 提交多次后发现并末达到理想的分数。因此后期我们又基于KNN算法和tf-idf特征进行进一步分类, 将多 个模型判定结果均相同的 2270 个测试样本提取出来补充相对较少的训练样本集 重新训练各部分子分类器, 最终达到了87分的结果。