=Start=
缘由：
收集、整理一下首届DataCon大数据安全分析比赛的writeup和相关资料，学习一下这些获奖选手的解题思路和方法，方便以后要用的时候快速参考。
正文：
参考解答：
DataCon的比赛背景：
为积极探索网络安全人才选拔和培养机制，网络安全相关比赛正如火如荼地开展。然而，目前国内的比赛大多以CTF（夺旗赛）类比赛为主，偏重漏洞挖掘，同质化较为严重，大数据安全分析在却鲜被提及。据相关统计数据显示，与大数据安全分析相关的比赛仅占1%左右，存在极大空白。
为填补这一空白，推动网络安全产业健康发展，由360企业安全集团和清华大学主办、贵州师范大学协办，并且联合北京大学、中科院软件所、复旦大学、西安交通大学、吉林大学等20余所全国知名高校共同举办的DataCon大数据安全分析比赛即将召开，线上报名于3月11日正式开启。
比赛题目方向：
方向1：DNS恶意流量检测
攻防演练过程中发现大数据会议官网无法正常访问、无法注册、发布会议及活动信息。主办单位已采集到大会DNS流量，请从中分析出恶意流量。
方向2：恶意代码行为检测
攻防演练过程中发现会议主办单位部分电脑遭遇恶意代码攻击，并感染会议现场的用于演讲和展区展示的电脑，影响会议运行。主办单位已通过沙箱分析出所有软件的行为数据，并已对其中部分已知恶意样本进行了标注。请分析已标注的训练样本，从测试样本中识别出所有恶意代码及其家族。
方向3：攻击源与攻击者分析
在大数据会议举办期间，重保小组发现了大量针对政府、大型企业网站、数据库发起攻击的可能攻击源。重保小组通过大网上的多维度数据，把与这些攻击源相关的线索全部串联起来。尝试对所有可能的攻击源进行分析。
DataCon排行榜说明：
1、DNS恶意流量检测方向的题目评审以80%客观得分和20%WriteUp得分计算两道题目的总得分并进行排名，其中题目一得分占总分的60%，题目二得分占总分的40%。
2、恶意代码行为检测方向的题目评审以80%客观得分和20%WriteUp得分计算两道题目的总得分并进行排名，其中题目一得分占总分的50%，题目二得分占总分的50%。
3、攻击源与攻击者分析方向的题目评审综合了三道题目的总得分并进行排名，其中题目一得分占总分的20%，题目二得分占总分的40%，题目三得分占总分的40%。得分要点主要考察选手们对日志中攻击的识别的准确性以及识别的攻击种类数；选手们对数据的敏感程度、数据视野以及同源分析能力和思路，能否从多个维度来体系化的对攻击者/组织进行同源分析；以及选手们的数据分析能力，选手们是否通过比赛提供的数据全面的，从更多维度来综合评价一个攻击者/组织的网络攻击能力。
以上是比赛的背景、题目类型的相关说明，下面摘录一些选手的部分解题策略和思路，方便快速查阅和学习：
Q1 DNS恶意流量检测
- 解题思路：结合专家经验在多个维度做统计特征，滤出超越统计基线3sigma的异常行为，人工检验异常数据确认攻击，然后编写规则滤出该类攻击全部数据包。
通过对数据的初步人工浏览和简单可视化分析发现：
……
据此，我的解题策略为：
原始日志->特征工程->异常检测->人工验证(得到部分答案)->pattern提取->规则匹配->全部答案。
接下来开始思考本题的特征维度。根据我的安全经验，将DNS攻击分为三种建模：
1、密集请求型：例如随机子域名DDoS、反射型DDoS。其特征为QPS高、时序特征强，一般能够可视化观察到波峰。
2、漏洞攻击型：例如针对DNS server的已知漏洞攻击。其特征为数量少、受DNS type影响，适合分类统计。如果批量PoC的话，则特征同1。
3、数据传输型：例如DNS Tunnel、Malware DGA、PoC中的DNS回显、SSRF重绑定等。其特征在于域名文本特征明显、适用于规则匹配。
将DNS日志的Request和Response join到一起，然后做统计特征和文本特征：
- DNS请求时序分布
- QPS min/max/avg
- QPS均值
- QPS波动性
- 连接成功率
- DNS响应率
- TCP报文占比
- 请求响应比
- 单域名平均访问次数
- 单目标高频访问
- 多级子域名变化率
- DNS type时序分布
- DNS type源IP分布
- 长随机域名
- DNS Tunnel特征
- 部分DNS RCE
- 心跳包
异常检测
将以上统计特征通过全量数据建立基线，然后在每个特征维度滤出超越3sigma的异常值。
总结：
从结果来看，本题最高效的特征如下：
1、DNS type。
2、src_ip维度的统计分析特征（QPS、域名数量、请求响应数），因为出题人将src_ip的行为做的非常干净，找到了IP就找到了攻击。
分析方法只用了3sigma异常基线一种，人工排序观察Top的异常结果，确认攻击后写规则捞出全部同类攻击。
Q2 DGA域名检测与家族聚类
- 解题思路：首先通过专家经验做强关联社区发现洗出一部分DGA域名，以此为正样本训练二分类模型识别DGA域名，然后对结果分别进行社区发现、社区聚合、标签传播扩展与降噪，最终得到结果。
主要问题和待提高的地方
- 结合malware reverse engine进行辅助和分析确认。我们队在比赛过程中针对这道题的现实意义进行了讨论，dga检测与识别，毫无疑问是要进行实时防御，或者说是准实时防御，即dns sinkhole，这就是一个典型的“双百场景”，即“recall 100% + precision 100%”。
- dga C&C本质上是黑客的一种隐蔽通信手段，如果不能100% recall识别，漏报一个等于防御失败。反过来，dns域名是一个互联网核心基础设施，如果在骨干网设备上产生拦截误报，影响是非常巨大的。这和Xorddos马的自我繁殖防御类似。从这个角度来说，这道题我们没有拿到100%，等于防御失败了。
- 在工程化中，这道题最有效的方法是是对dga malware进行监控和逆向分析，通过精确的dga generate function，提前预知未来可能产生的dga域名，从而进行提前防御，当然也要关注dga生成算法与常规域名的碰撞问题。
- 社区节点间边权重计算方式需要优化：在实际场景中，一台机器可能中多个木马，而且在中马的同时可能正在进行其他的高频业务访问行为，因此只基于简单的共享同一个肉鸡ip的社区边定义很容易引入像msn.com这种误报，对边权重的计算需要引入更多肉鸡-域名行为时序上的特征。
参考链接：
- DataCon-攻击源与攻击者分析-writeup
https://github.com/ReAbout/datacon - DataCon 2019: malicious DNS traffic & DGA analysis
https://bithack.io/forum/258 - DataCon 的 DNS 恶意流量检查一题回顾
- 必看！国内首届DataCon大数据安全分析比赛正式启动啦
https://www.butian.net/datacon - 访谈 | DataCon国内首届大数据安全分析比赛
=
- https://github.com/rrenaud/Gibberish-Detector
- https://pc.nanog.org/static/published/meetings/NANOG71/1444/20171004_Gong_A_Dga_Odyssey__v1.pdf
- https://cloud.tencent.com/developer/article/1142855
- https://github.com/360netlab/DGA/tree/master/code
- https://www.botconf.eu/wp-content/uploads/2015/12/OK-P06-Plohmann-DGArchive.pdf
- https://www.usenix.org/sites/default/files/conference/protected-files/security16_slides_plohmann.pdf
- https://github.com/rmariko/security-ids/blob/0696255b7f2600429a3129bdc1b271d3c4db20ae/ids.py
- https://github.com/LittleHann/DGA-1/blob/master/dga_algorithms/Conficker.cpp
- https://github.com/andrewaeva/DGA/blob/master/dga_algorithms/Matsnu.py
- https://github.com/LittleHann/dga-collection/tree/master/dgacollection
- https://github.com/360netlab/DGA/tree/master/code
- https://github.com/baderj/domain_generation_algorithms/tree/e2ed68a9813b2265652a79291a74b4c23fc13bf0
- https://www.cdxy.me/?p=805
- https://github.com/shyoshyo/Datacon-9102-DNS
- http://momomoxiaoxi.com/数据分析/2019/04/24/datacondns1/
- =
- Python–实现密码强度检测器
https://blog.csdn.net/xushao_Movens/article/details/53844013 - 几点基于Web日志的Webshell检测思路
https://my.oschina.net/bluefly/blog/626132 - 利用机器学习检测HTTP恶意外连流量
https://www.anquanke.com/post/id/107124 - Webshell检测
- webshell检测－日志分析
http://tanjiti.lofter.com/post/1cc6c85b_10c4e356 - Web日志安全分析系统实践
https://xz.aliyun.com/t/2136 - Web日志安全分析浅谈
https://xz.aliyun.com/t/1121 - 安全科普：Waf实现扫描器识别%20彻底抵挡黑客扫描
- Detecting Bots in Apache & Nginx Logs
https://tech.marksblogg.com/detect-bots-apache-nginx-logs.html - Struts2 历史RCE漏洞 EXP汇总 常用工具流量特征分析
https://xz.aliyun.com/t/4607 - 大话蜜罐日志分析
http://zhuanlan.51cto.com/art/201702/531001.htm - =
- DNS 解析的过程是什么
https://www.zhihu.com/question/23042131 - DNS 服务器能遭受到的 DDNS 攻击类型
https://www.cnblogs.com/cobbliu/p/3383135.html - 反射 DDOS 攻击防御的一点小想法
https://www.freebuf.com/column/138163.html - 测试 DNS 区域递归漏洞以及避免 DNS 放大攻击
https://www.anquanke.com/post/id/83245 - DNS 中的协议字段详细定义
https://www.cnblogs.com/549294286/p/5172448.html
=END=
《 “DataCon 2019大数据安全分析比赛writeup收集” 》 有 8 条评论
python异常数据预警之3sigma
https://zhuanlan.zhihu.com/p/36297816
`
3sigma原理一般在工程科学中比较常用，我们在故障预警中用过这个原理，数据是用传感器采集的数据，这些数据假定符合正态分布，然后在进行模型识别后用3sigma原则来对异常数据进行准确定位。在实际应用中可以根据业务场景来确定 k sigma中的k值。
3sigma原理可以简单描述为：若数据服从正态分布，则异常值被定义为一组结果值中与平均值的偏差超过三倍标准差的值。即在正态分布的假设下，距离平均值三倍 \sigma （为标准查）之外的值出现的概率很小（如下式），因此可认为是异常值。
P(|x-μ|>3σ)≤0.003
若数据不服从正态分布，也可以用远离平均值的多少倍标准差来描述（这就使该原理可以适用于不同的业务场景，只是需要根据经验来确定 k sigma中的k值，这个k值就可以认为是阈值）。
`
正态分布中什么是1 sigma原则，2sigma原则，3sigma原则
https://zhidao.baidu.com/question/1693646488397754788.html
`
σ是希腊字母，英文表达sigma，汉语译音为“西格玛”。
在正态分布中σ代表标准差，μ代表均值x=μ即为图像的对称轴。
三σ原则即为：
数值分布在（μ—σ,μ+σ)中的概率为0.6526
数值分布在（μ—2σ,μ+2σ)中的概率为0.9544
数值分布在（μ—3σ,μ+3σ)中的概率为0.9974
可以认为，数值分布几乎全部集中在(μ-3σ,μ+3σ)区间内，超出这个范围的可能性仅占不到0.3%.
`
正态分布及3Sigma原理
https://www.cnblogs.com/hellochennan/p/6706884.html
实战攻防之红队视角下的防御体系突破
https://www.qianxin.com/threat/reportdetail/32
`
第一章 什么是红队
第二章 红队三板斧——攻击的三个阶段
一、第一阶段：情报收集
二、第二阶段：建立据点
三、第三阶段：横向移动
第三章 红队也套路——常用的攻击战术
一、利用弱口令获得权限
二、利用社工来进入内网
三、利用旁路攻击实施渗透
四、秘密渗透与多点潜伏
第四章 红队三十六计——经典攻击实例
一、浑水摸鱼——社工钓鱼突破系统
二、声东击西——混淆流量躲避侦察
三、李代桃僵——旁路攻击搞定目标
四、顺手牵羊——巧妙种马实施控制
五、暗渡陈仓——迂回渗透取得突破
第五章 红队眼中的防守弱点
一、资产混乱、隔离策略不严格
二、通用中间件未修复漏洞较多
三、边界设备成为进入内网的缺口
四、内网管理设备成扩大战果突破点
附录 奇安信红队能力及攻防实践
`
大数据安全分析平台搭建&相关经验分享
https://mp.weixin.qq.com/s/hvLN83rPiNLw6cmrYDRPpA
`
在大数据应用普及以及信息安全上升为国家高度后，信息安全能力落地的挑战日益增多。一方面，企业内部的安全体系架构日益复杂，各式各样的安全数据越来越多，传统分析方法难以奏效。另一方面，传统分析方法无法有效的检测新型攻击手法。同时，在大数据时代下对威胁的判断以及响应有着更高的要求。为此，本文介绍如何通过开源组件搭建一个大数据安全分析平台，并且分享部分相关经验。本文主要从以下六个方面进行介绍：
1.平台框架
2.数据库设计
3.离线数据准备
4.Python2->3的升级
5.归一化注意事项
6.安全分析准备
`
安全人员的代码水平
https://strcpy.me/index.php/archives/797/
`
# 安全研发
如果一个人安全也懂一些，研发也懂一些，那就是符合安全开发这个岗位了，这个岗位在各大公司中主要是做扫描器引擎、WAF/IPS引擎、风控类、网络测绘、内部安全体系建设等等。
在长亭的这几年，后端和安全开发都做过一些，也面试过很多人，真正让人满意的安全研发是太太太稀缺了，很多安全比较厉害的人，研发就是上面的水平，很多研发还可以的人，是不怎么懂安全的。当然，我一直认为，一个研发大佬学习安全是没太大难度的，最主要的还是缺少安全大佬积累的奇技淫巧、对安全技术的热情等等，这些都阻碍着招聘的进度。一种解决方案是将安全研发拆分为安全研究和研发，安全研究团队负责研究技巧。给出思路和 demo 实现，然后由研发团队去进行产品化的实现。
`
系列第一篇：新技术加速隐私暴露，如何应对？（一）
https://mp.weixin.qq.com/s/VnLNtqqKxIhyD4-FXxkVrQ
系列第二篇：新技术加速隐私暴露，如何应对？（二）
https://mp.weixin.qq.com/s/Mi6flr8QQVAGmd9LbGDcWw
系列第三篇：新技术加速隐私暴露，如何应对？（三）
https://mp.weixin.qq.com/s/9–JnP0ligtmoTOgCBmH8A
原创 | 新技术加速隐私暴露，如何应对？（四）《个人金融信息保护技术规范》影响几何？
https://mp.weixin.qq.com/s/CdQHexFvQNGf_4KyToQ1RQ
腾讯安全威胁情报中心“明炉亮灶”工程：自动化恶意域名检测揭秘
https://mp.weixin.qq.com/s/QV8ErKHow3b-AMp6HMzKQg
`
构建恶意域名检测引擎，对海量域名进行自动化检测并识别出恶意域名，让威胁情报的检测和运营变得更智能、更高效，以缓解威胁情报分析师分面对海量威胁数据的分析压力。
随着互联网体量的急剧增大，基于网络访问的各种网络攻击、木马、蠕虫等威胁潜藏在海量的网络事件中，这让专注情报分析的威胁情报分析师不堪重负，而如果能通过自动化的威胁感知和检测技术，实现从海量数据中自动发现和检测威胁，将能够有效减轻威胁情报分析师运营负担，并极大增强威胁情报检测和运营的效率。
其中，恶意域名情报是威胁情报的重要组成部分，包括恶意域名检测（Malicious Domains Detection）[1]、域名生成算法识别（DGA Recognition）[2]等。相比于一般的文本、图像等算法任务，安全领域的恶意域名检测受困于缺乏可靠的评测数据，当前并没有出现突破性且可复现的学术进展。
得益于腾讯安全在网络安全领域海量数据积累和众多网络安全领域专家，使得恶意域名检测的自动化实现，有了充实的数据和专家知识基础。
本文所述的恶意域名检测引擎 (Malicious Domain Detection Engine, MDDE) ，实现了对恶意域名的自动检测，并为威胁情报智能化检测和运营提高了效率。
`
DataCon2020题解：通过蜜罐与DNS流量追踪Botnet
https://www.cdxy.me/?p=829
`
DataCon2020 今年由于精力有限仅做了botnet方向，该方向共四题。本文为第一题的writeup。此题考察能力全面，汇集了代码审计、样本分析、数据分析等知识点，且需要选手对botnet运行机制的深入理解，贴近实战场景，个人认为是最有趣的一题，分享给各位。
# 原题信息
* 背景
* 数据说明
# 初步理解
# Botnet建模
* Botnet常规模型
* 哪些阶段会触发DNS流量？
* 蜜罐的攻击流量来自谁？
* XGoAhead是什么鬼？
* 传播模型
# 解题过程
* 假设
* 岔路排除
* 蜜罐HTTP数据探索
* 已修复的GoAhead漏洞
* XGoAhead源码审计
* RCE 初步分析
* RCE payload挖掘
* 样本逆向分析
* 域名访问拓扑分析
* 继续样本分析
# 总结
* 复盘与建议
* 公有云Botnet检测延伸阅读
* 工具
* 致谢
`
基于机器学习的Web管理后台识别方法探索
https://security.tencent.com/index.php/blog/msg/176
`
# 背景
长期以来，Web管理后台一直是攻击者觊觎的目标。部分信息安全意识薄弱的业务在未作任何安全加固（设置IP白名单、强口令、二次认证、验证码、请求频率审计等）的情况下直接将Web管理后台暴露到互联网，而管理后台由于本身的管理和敏感属性，外部一旦攻击成功，则极大可能造成数据泄露和服务器被入侵。
所以，Web管理后台的检测一直是Web漏洞扫描器规则中比较重要的组成部分，而传统识别方法基于关键字，误报和漏报的问题比较突出，规则一旦形成，除非人为更改，否则长期处于停滞状态，灵活性较差。此外目前大量网站基于动态网页进行展示，传统扫描器如果不进行JS渲染，则漏报严重；而逐个渲染，则时间花销大、成本又非常高。
于是我们将目光转向利用机器学习来识别Web管理后台。此外，笔者所在的团队是基于流量来进行安全分析建设工作的，所以如何利用流量的优势实现对Web管理后台的识别，也是本文一大重点。
# 传统 VS AI
我们当然也可以选择其中一些字段作为关键字去匹配。但是随着业务拥抱开源，这些页面层出不穷，与此同时，他们的规则也不尽相同，如果每次都需要人工制定规则，其消耗无疑是巨大的。同理，Web管理后台的种类也纷繁复杂，这也就是我们为什么要利用机器学习来识别Web管理后台和高危页面的原因。
机器学习方案由于不依赖关键字，具有良好的泛化能力，能识别传统基于关键字方案漏报的部分；同时，模型可通过不断迭代自进化，灵活度高；在识别能力上，机器学习模型是通过综合学习多维特征，建立各维度关联关系，从而指导决策，具备更缜密的判断逻辑。新的识别方案上线之后，也确实有很多意外收获，比如识别出了Django的调试页面等等。
# 一、识别与落地
该模块从公司流量平台获取到的流量作为输入，之后经过两个步骤的处理，第一步是直接利用流量中的响应内容来判定是否为Web管理后台，如果是Web管理后台的话则直接存储；如果判定为非Web管理后台，则进入步骤二。在步骤二中，为了防止漏报，我们需要落地疑似管理后台url用于后续扫描之后再进行判定，这里我们通过四种特征规则来确定：
* 据登陆行为
提交登录请求中，大多数的请求都比较有类似的特征，这里以GET登录请求，我们限定其中一种登录行为模式为(以正则为例)：
URL匹配\wpass\w=\w+和\wuser\w=\w+到该类模式则认为是目标URL，其他模式不再赘述。
* 根据cookie
登录前后的cookie值不同，可以根据header头中的set_cookie字段。
* 根据关键字
常见的URL有比较明显的特征，比如admin、login、sign等
* 根据状态码
登录之后的跳转具有302跳转特征码等。
# 二、URL扫描
这里主要是接收识别与落地模块的URL进行扫描。扫描这里自动化方案比较多，比如常见的Selenium、Chrome等等，我们采用的是pyppeteer+Chrome的方案。
这块比较简单，不再赘述，但是也有一些小tips可以跟大家分享，比如扫描速度优化，因为pyppeteer这个库是原生支持asyncio的，所以我们这里采用了多进程+异步的模式来加快扫描速度。
# 三、机器学习识别
如图3，在模型训练阶段，我们收集了大量页面样本，包括各类管理后台、高危页面等，为模型训练提供丰富与多样化的数据支撑。同时，线上模型将进行定期的更新以保证模型始终保持良好的判别能力，并引入正负反馈机制配合AI模型训练，基于模型识别的情况针对性调优，进一步提升模型准确率。下面简单聊聊各阶段涉及的相关技术。
3.1 数据预处理
3.2 算法选择与模型训练
3.3 线上部署与调优
# 四、告警
在上述验证完成之后，识别为Web管理后台的URL会进入告警模块中去，告警模块除了直接告警以外，还肩负着弱口令检测的责任。告警模块会根据URL从疑似登录的流量中检查是否存在该登录接口的弱口令，其识别方法和登录行为的识别模式基本一致，在此不再赘述。当发现管理后台存在弱口令之后，一是可以附带弱口令到告警中去，第二也可以针对性做分级运营。
# 写在最后
基于机器学习分类算法，模型可以自动学习页面特征，效果远远超过传统方案。同时，模型具备良好的泛化性能，除了对管理后台的识别，甚至可以实现对其它特定类型页面的识别，比如框架报错页面等。
此外随着开源组件应用的增多，尤其是部分应用默认未授权可访问，基于以上原因，其实模型也需要具有与时俱进的学习能力，所以我们也集成了反馈处理模块，通过对识别的结果进行反馈实现针对模型的不断优化。当然后续还有很多工作要做，比如跟SOC工单系统打通，可以直接根据业务的处理和反馈情况进行模型调优。
`