L's tale


  • 首页

  • 归档

  • 标签

  • 分类

  • 关于

关于主动防御方案的一些思考

发表于 2020-11-15

前言

长期以来由于攻防信息不对称、攻防面不对称,被动防御的效果已经发展到了瓶颈,安全行业慢慢期望从防守角色转换成攻防对抗的角色,于是主动防御体系的概念就被提了出来。虽然国内的主动防御体系还不够标准和成熟,但个人依旧认为未来的防御体系一定会纳入许多主动防御战术。下图是我对主动防御的的一些思考,我将主动防御分成了三种能力:

情报能力:获取可能未来会对自己构成威胁的能力

感知能力:发起内外部正在对自己构成威胁的能力

作战能力:对抗外内部正在对自己构成威胁的能力

主动防御

情报能力

漏洞情报:监控各厂商、平台的漏洞通告,核对企业内部资产受影响范围,更新规则库,保证第一时间的感知能力。

APT技战术:通过APT报告、Att&Ck框架、NSS框架等获取 APT技术的更新,更新规则库,保证第一时间的感知能力。

情报IOC:通过APT报告、各路情报源的IOC信息,核对企业是否遭受相关攻击,保证第一时间的感知能力。

情报联盟:通过建立情报联盟共享情报信息,企业自己捕获的情报数据质量较高,同行业具备一定潜在共性,如针对行业的APT攻击。

情报可以高效的驱动感知能力提升,但是目前的情报生态也存在一定问题,例如:

  1. 情报IOC质量得不到保证,一是情报本身是错误的,二是情报的信息量太少,虽然情报有标准的标准的STIX格式,但在情报的高维度信息识别方面目前仍存在问题,无法给出情报相关的攻击者信息、攻击意图、攻击目标、攻击方法等信息
  2. 情报联盟无法建立,一是由于情报IOC质量本身无法保证,导致无法确保联盟情报池质量,久而久之就失去了建立热情。二是由于国情容易构建资源壁垒。

感知能力

建设:

​ 安全体系建设(事前):通过建设完善的安全体系,增加空间复杂度,当黑客进入网络后在没有信息源的情况下,提高攻击技术成本,攻击时间成本。为事中识别、事后作战提供了更多的时间。常见的安全体系有:河防体系、塔防体系、纵深防御、零信任,可根据实际情况建立适合自己的安全体系。此类文章交流也是比较多的,可以多参考。

​ 识别(事中):能够识别网络中的攻击者、受害者、攻击手段、攻击者基础设施、攻击意图、攻击能力等信息,可以有效的对安全事件进行评级,并产生高质量的情报源。攻击识别的能力是安全防御的基础,高效精准的识别,才能执行有效的防御方案。

​ 作战(事后):当识别到攻击时,则要启动对应的作战方案。详细作战能力后面单独细说

狩猎:

​ 基线建立:业务运转的日常基线建立

​ 异常算法:偏离基线的检测能力,给予安全分析人员分析的起点(避免告警过多,无法运维问题,分批分场景逐步实现监控)

​ 情报驱动:验证新的情报IOC、攻击技战术、漏洞,是否在企业中已经遭受攻击

​ 威胁猎人:资深的安全分析人员、攻防研究人员是威胁狩猎的主要驱动力,它们可以根据日志、流量、内存等证据中去寻找攻击痕迹。

作战能力

​ 诱导:诱导是目前主动防御最常见的技术,MITRE新发布的主动防御框架shield大部分技术也是围绕诱导展开,其背后的核心产品就是蜜罐。诱导我分为目标诱导、内容诱导、结果诱导、动态诱饵几个方面。

  • ​ 目标诱导

    • 蜜网:建立真实、丰富的诱饵网络,诱敌深入

    • 蜜罐:蜜罐的种类贴近真实环境部署,建议部署诱惑力较大的系统,例如:核心运维系统(AD、堡垒机、终端管理、安全设备)、核心业务系统(数据库、核心业务)、脆弱系统(漏洞系统、弱口令系统、未授权访问系统)

    • 诱饵账号:在操作系统、应用系统防止无人使用的诱饵账号,诱饵账号的可以伪装为管理员、敏感人员(财务、人事、高层等)
  • ​ 内容诱导

    • 真实性:多采用高交互蜜罐,避免低交互蜜罐被轻易发现,提高攻击者警惕
    • 感兴趣内容:多添加符合业务的数据、提高蜜罐的真实性
  • ​ 结果诱导

    ​ 当检测到具体攻击时可将流量牵引到对应类型的蜜罐或者蜜网中,并返回攻击成功结果,主动让攻击者进入陷阱。该实现需要基于一定的识别能力,识别攻击方法、攻击目标,将流量牵引到正确的蜜罐上

  • ​ 动态诱饵

    ​ 为了更好控制资源,根据攻击者技战术,动态产生相关的诱饵,捕获攻击

​ 反制:在遭受攻击时正真意义上的反击工作,目前比较常见的方法为反打C2、后台,通过钓鱼方式getshell

  • ​ 基础设施反击

    ​ 该工作目前在GA业务中较为常见,针对一些菠菜、黑产的反向打击、证据提取,主要目标为攻击者的C2服务器、钓鱼站点、后台等黑客基础设施。这部分工作目前大多数是人工进行。

  • ​ 社会工程

    • 攻击者信息收集:通过jsonp、cors等跨域信息收集方式(该方法已经被一些插件识别,思路不变,方法可以换,这就体现了对抗性)
    • 钓鱼蜜罐:通过一些精心布置的蜜罐,反向钓鱼攻击者。例如HVV中常用的VPN客户端下载界面,将后门伪装成VPN客户端等待攻击者下载,人员名单列表文件,利用office漏洞反向攻击
    • 警告:通过收集的攻击者信息发送邮件、短信警告,停止攻击,情节严重者报警处理

​ 自动化\半自动化:

  • ​ SOAR:SOAR本是该在安全运营中的模块,但主动防御的过程中自动化能力是至关重要的一步,人不能24小时值班,需要借助平台能力自动执行流程。

    • 流程制定:制定企业风险处理流程、当发生风险是按照具体流程自动\半自动化执行。
    • 运营经验固化为流程:依托于SOAR平台,根据日常运营经验优化、新建,分析、处置、响应流程,持续增强安全运营能力。
    • 能力服务化、标准化:将企业安全能力服务化,通过SOAR建立能力中台,提供南北向接口,南向对接设备,北向提供服务。外部调用API即可调用企业安全能力。将企业安全能力标准化,将不同厂家不同设备,相同的能力标准化,对外提供统一接口,通过该接口可调用具备该能力的所有设备。
  • ​ 响应

    • 权限限制

      当账号失陷后,可自动化降权、关闭,避免重要资产信息泄露。

    • 访问限制

      当主机失陷后,可自动化阻断,避免攻击者横向移动。

MSF-HTTPS默认证书检测

发表于 2020-10-09 | 分类于 安全建设

MSF-HTTPS默认证书检测

前言

进行过MSF的默认payload专项测试后,其他明文传输的payload方式或多或少都可以找到相关的流量特征,而HTTPS走的是标准TLS格式,数据完全加密,这样想检测HTTPS的payload难度就非常的大了。但是在TLS传输加密数据之前的证书交换协商过程却是明文传输的,我们可以从这部分入手来尝试检测MSF的HTTPS证书。

代码分析

经过生成多个payload样本后发现,样本的证书貌似是随机生成的,这样我们就需要去后台查看MSF的源代码找到证书的生成逻辑。

1
2
3
06/09/2020-15:35:55.502904 10.50.1.183:52691 -> 10.50.1.175:8888  TLS: Subject='C=US, ST=OH, O=Bosco-Kovacek, OU=multi.byte, CN=bosco.kovacek.org/emailAddress=multi.byte@bosco.kovacek.org' Issuerdn='C=US, ST=OH, O=Bosco-Kovacek, OU=multi.byte, CN=bosco.kovacek.org/emailAddress=multi.byte@bosco.kovacek.org'
06/12/2020-17:22:46.618026 10.50.1.183:58063 -> 10.50.1.175:8888 TLS: Subject='C=US, ST=NC, O=McKenzie, Cummerata and Vandervort, OU=input, CN=mckenzie.cummerata.vervort.net/emailAddress=input@mckenzie.cummerata.vervort.net' Issuerdn='C=US, ST=NC, O=McKenzie, Cummerata and Vandervort, OU=input, CN=mckenzie.cummerata.vervort.net/emailAddress=input@mckenzie.cummerata.vervort.net'
06/12/2020-17:22:46.979553 10.50.1.183:58064 -> 10.50.1.175:8888 TLS: Subject='C=US, ST=NC, O=McKenzie, Cummerata and Vandervort, OU=input, CN=mckenzie.cummerata.vervort.net/emailAddress=input@mckenzie.cummerata.vervort.net' Issuerdn='C=US, ST=NC, O=McKenzie, Cummerata and Vandervort, OU=input, CN=mckenzie.cummerata.vervort.net/emailAddress=input@mckenzie.cummerata.vervort.net'

MSF证书生成代码在文件lib/msf/core/cert_provider.rb里,代码如下:通过调用faker库的Address.state_abbr、Address.city、Company.name、Internet.domain_suffix等list,从中随机选择相关的词汇生成证书。

image-20200701104200259

检测方案

在了解证书的生成过程后,我们使用逆向思维同时也利用faker的list,将证书Subject进行拆分,逐个匹配faker list中的字典,查看是否均存在于字典中,若都存在则判断为MSF HTTPS SSL证书。

suricata lua脚本如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
suffix_list = {"Inc", "and Sons", "LLC", "Group"}

ou_list = {"auxiliary", "primary", "back.end", "digital", "open.source", "virtual", "cross.platform", "redundant", "online", "haptic", "multi.byte", "bluetooth", "wireless", "1080p", "neural", "optical", "solid.state", "mobile", "driver", "protocol", "bandwidth", "panel", "microchip", "program", "port", "card", "array", "interface", "system", "sensor", "firewall", "hard.drive", "pixel", "alarm", "feed", "monitor", "application", "transmitter", "bus", "circuit", "capacitor", "matrix", "back.up", "bypass", "hack", "override", "compress", "copy", "navigate", "index", "connect", "generate", "quantify", "calculate", "synthesize", "input", "transmit", "program", "reboot", "parse"}

last_name_list = {"Abbott", "Abernathy", "Abshire", "Adams", "Altenwerth", "Anderson", "Ankunding", "Armstrong", "Auer", "Aufderhar", "Bahringer", "Bailey", "Balistreri", "Barrows", "Bartell", "Bartoletti", "Barton", "Bashirian", "Batz", "Bauch", "Baumbach", "Bayer", "Beahan", "Beatty", "Bechtelar", "Becker", "Bednar", "Beer", "Beier", "Berge", "Bergnaum", "Bergstrom", "Bernhard", "Bernier", "Bins", "Blanda", "Blick", "Block", "Bode", "Boehm", "Bogan", "Bogisich", "Borer", "Bosco", "Botsford", "Boyer", "Boyle", "Bradtke", "Brakus", "Braun", "Breitenberg", "Brekke", "Brown", "Bruen", "Buckridge", "Carroll", "Carter", "Cartwright", "Casper", "Cassin", "Champlin", "Christiansen", "Cole", "Collier", "Collins", "Conn", "Connelly", "Conroy", "Considine", "Corkery", "Cormier", "Corwin", "Cremin", "Crist", "Crona", "Cronin", "Crooks", "Cruickshank", "Cummerata", "Cummings", "Dach", "D'Amore", "Daniel", "Dare", "Daugherty", "Davis", "Deckow", "Denesik", "Dibbert", "Dickens", "Dicki", "Dickinson", "Dietrich", "Donnelly", "Dooley", "Douglas", "Doyle", "DuBuque", "Durgan", "Ebert", "Effertz", "Emard", "Emmerich", "Erdman", "Ernser", "Fadel", "Fahey", "Farrell", "Fay", "Feeney", "Feest", "Feil", "Ferry", "Fisher", "Flatley", "Frami", "Franecki", "Friesen", "Fritsch", "Funk", "Gaylord", "Gerhold", "Gerlach", "Gibson", "Gislason", "Gleason", "Gleichner", "Glover", "Goldner", "Goodwin", "Gorczany", "Gottlieb", "Goyette", "Grady", "Graham", "Grant", "Green", "Greenfelder", "Greenholt", "Grimes", "Gulgowski", "Gusikowski", "Gutkowski", "Gutmann", "Haag", "Hackett", "Hagenes", "Hahn", "Haley", "Halvorson", "Hamill", "Hammes", "Hand", "Hane", "Hansen", "Harber", "Harris", "Hartmann", "Harvey", "Hauck", "Hayes", "Heaney", "Heathcote", "Hegmann", "Heidenreich", "Heller", "Herman", "Hermann", "Hermiston", "Herzog", "Hessel", "Hettinger", "Hickle", "Hilll", "Hills", "Hilpert", "Hintz", "Hirthe", "Hodkiewicz", "Hoeger", "Homenick", "Hoppe", "Howe", "Howell", "Hudson", "Huel", "Huels", "Hyatt", "Jacobi", "Jacobs", "Jacobson", "Jakubowski", "Jaskolski", "Jast", "Jenkins", "Jerde", "Johns", "Johnson", "Johnston", "Jones", "Kassulke", "Kautzer", "Keebler", "Keeling", "Kemmer", "Kerluke", "Kertzmann", "Kessler", "Kiehn", "Kihn", "Kilback", "King", "Kirlin", "Klein", "Kling", "Klocko", "Koch", "Koelpin", "Koepp", "Kohler", "Konopelski", "Koss", "Kovacek", "Kozey", "Krajcik", "Kreiger", "Kris", "Kshlerin", "Kub", "Kuhic", "Kuhlman", "Kuhn", "Kulas", "Kunde", "Kunze", "Kuphal", "Kutch", "Kuvalis", "Labadie", "Lakin", "Lang", "Langosh", "Langworth", "Larkin", "Larson", "Leannon", "Lebsack", "Ledner", "Leffler", "Legros", "Lehner", "Lemke", "Lesch", "Leuschke", "Lind", "Lindgren", "Littel", "Little", "Lockman", "Lowe", "Lubowitz", "Lueilwitz", "Luettgen", "Lynch", "Macejkovic", "MacGyver", "Maggio", "Mann", "Mante", "Marks", "Marquardt", "Marvin", "Mayer", "Mayert", "McClure", "McCullough", "McDermott", "McGlynn", "McKenzie", "McLaughlin", "Medhurst", "Mertz", "Metz", "Miller", "Mills", "Mitchell", "Moen", "Mohr", "Monahan", "Moore", "Morar", "Morissette", "Mosciski", "Mraz", "Mueller", "Muller", "Murazik", "Murphy", "Murray", "Nader", "Nicolas", "Nienow", "Nikolaus", "Nitzsche", "Nolan", "Oberbrunner", "O'Connell", "O'Conner", "O'Hara", "O'Keefe", "O'Kon", "Okuneva", "Olson", "Ondricka", "O'Reilly", "Orn", "Ortiz", "Osinski", "Pacocha", "Padberg", "Pagac", "Parisian", "Parker", "Paucek", "Pfannerstill", "Pfeffer", "Pollich", "Pouros", "Powlowski", "Predovic", "Price", "Prohaska", "Prosacco", "Purdy", "Quigley", "Quitzon", "Rath", "Ratke", "Rau", "Raynor", "Reichel", "Reichert", "Reilly", "Reinger", "Rempel", "Renner", "Reynolds", "Rice", "Rippin", "Ritchie", "Robel", "Roberts", "Rodriguez", "Rogahn", "Rohan", "Rolfson", "Romaguera", "Roob", "Rosenbaum", "Rowe", "Ruecker", "Runolfsdottir", "Runolfsson", "Runte", "Russel", "Rutherford", "Ryan", "Sanford", "Satterfield", "Sauer", "Sawayn", "Schaden", "Schaefer", "Schamberger", "Schiller", "Schimmel", "Schinner", "Schmeler", "Schmidt", "Schmitt", "Schneider", "Schoen", "Schowalter", "Schroeder", "Schulist", "Schultz", "Schumm", "Schuppe", "Schuster", "Senger", "Shanahan", "Shields", "Simonis", "Sipes", "Skiles", "Smith", "Smitham", "Spencer", "Spinka", "Sporer", "Stamm", "Stanton", "Stark", "Stehr", "Steuber", "Stiedemann", "Stokes", "Stoltenberg", "Stracke", "Streich", "Stroman", "Strosin", "Swaniawski", "Swift", "Terry", "Thiel", "Thompson", "Tillman", "Torp", "Torphy", "Towne", "Toy", "Trantow", "Tremblay", "Treutel", "Tromp", "Turcotte", "Turner", "Ullrich", "Upton", "Vandervort", "Veum", "Volkman", "Von", "VonRueden", "Waelchi", "Walker", "Walsh", "Walter", "Ward", "Waters", "Watsica", "Weber", "Wehner", "Weimann", "Weissnat", "Welch", "West", "White", "Wiegand", "Wilderman", "Wilkinson", "Will", "Williamson", "Willms", "Windler", "Wintheiser", "Wisoky", "Wisozk", "Witting", "Wiza", "Wolf", "Wolff", "Wuckert", "Wunsch", "Wyman", "Yost", "Yundt", "Zboncak", "Zemlak", "Ziemann", "Zieme", "Zulauf"}


state_abbr_list = {"AL", "AK", "AZ", "AR", "CA", "CO", "CT", "DE", "FL", "GA", "HI", "ID", "IL", "IN", "IA", "KS", "KY", "LA", "ME", "MD", "MA", "MI", "MN", "MS", "MO", "MT", "NE", "NV", "NH", "NJ", "NM", "NY", "NC", "ND", "OH", "OK", "OR", "PA", "RI", "SC", "SD", "TN", "TX", "UT", "VT", "VA", "WA", "WV", "WI", "WY"}


function string.trim(s)
return (string.gsub(s, "^%s*(.-)%s*$", "%1"))
end

function in_array(b,list)
if not list then
return false
end
if list then
for k, v in ipairs(list) do
if v == b then
return true
end
end
end
end


function init (args)
local needs = {}
needs["buffer"] = tostring(true)
return needs
end

function match(args)
subject = tostring(args["buffer"])
if subject ~= nil then
if string.match(string.trim(subject),"C=(%w+),%sST=(%w+),%sO=(.*),%sOU=(.*),%sCN=") ~= nil then
C,ST,O,OU = string.match(string.trim(subject),"C=(%w+),%sST=(%w+),%sO=(.*),%sOU=(.*),%sCN=")
if C == "US" then
-- SCLogInfo("detection tls_c")
-- SCLogInfo(ST)
if in_array(ST, state_abbr_list) then
-- SCLogInfo("detection tls_st")
if in_array(OU, ou_list) then
-- SCLogInfo("detection tls_ou\n")
if string.match(string.trim(O),"(%w+)%s+(%w+)") ~= 'nil' then
last_name, suffix = string.match(string.trim(O),"(%w+)%s+(%w+)")
if in_array(suffix, suffix_list) then
if in_array(last_name, last_name_list) then
return 1
end
end
end

if string.match(string.trim(O),"(%w+)-(%w+)") ~= 'nil' then
last_name1, last_name2 = string.match(string.trim(O),"(%w+)-(%w+)")
if in_array(last_name1, last_name_list) then
if in_array(last_name2, last_name_list) then
return 1
end
end
end
if string.match(string.trim(O),"(%w+),%s+(%w+)%s+and%s+(%w+)") ~= 'nil' then
last_name1, last_name2, last_name3 = string.match(string.trim(O),"(%w+),%s+(%w+)%s+and%s+(%w+)")
if in_array(last_name1, last_name_list) then
if in_array(last_name2, last_name_list) then
if in_array(last_name3, last_name_list) then
return 1
end
end
end
end
end
end
end
end
end
return 0
end
return 0

结论

当然,只要换了证书,本方法就不适用,只能从其他方面入手检测了。

Covenant源码调试分析-ExecuteStage

发表于 2020-05-05 | 分类于 源码分析

Covenant源码调试分析-Execute

在上篇分析StagerCode时,我们就获取到了ExectuteCode的源码。本篇我们来调试一下Execute的源码,了解其工作过程。经过分析Execute主要负责两个功能,注册信息提交以及任务监听。

Execute工作流程

image-20200501182134068

源码分析

调试准备

在StagerCode调用ExectuteCode时,需要传入一些参数并且利用Assembly.Load在内存中加载数据,为了方便调试我们直接将获取的ExectuteCode源码与StagerCode合并在一个程序中,直接调用ExectuteCode中的Execute方法。

image-20200501182134068

注册信息提交

  1. 在ExecuteCode刚运行时候会收集本机的主机名、IP地址、操作系统类型、进程名、进程完整性级别、用户域、用户名属性上传至Server端。

    image-20200501182437640

  2. Server端收到Client提交的信息后,进行解码、解密,提取相关的注册信息,最后push到缓存读进数据库。

    image-20200502082621477

    image-20200502083633727

任务监听

  1. 任务监听是核心功能用于接收远程任务执行命令,ExecuteStage中利用一个无限while循环进行任务监听。任务类型分为4种:

    • SetOption:设置会话属性
    • Jobs:查看当前任务
    • Exit:结束会话
    • default:执行监听到的任务
  2. Server端在创建任务时读取Web传递的参数创建对象,传递给CreateGruntTasking方法

    image-20200502085407529

  3. 当传入任务参数后,Server根据任务的ID去数据库中寻找payload,进行编译下发。

    image-20200502090808000

    image-20200502090904237

  4. Client在执行任务时调用TaskExecute方法,该方法提取参数和Assembled进行内存执行,并且返回执行结果。

    image-20200502091242320

总结

至此,利用三篇小短文对Covenant从创建launchers->LoadStager->ExecuteStager的流程跑个通,Covenant中还有很多为了支持此流程写的校验、API等,限于文章篇幅就不一一叙述了。由于covenant目前的payload都是基于.net core的,后续为了支持我会尝试在此架构上添加Python、c的payload。

Covenant C2源码调试分析-Grunt

发表于 2020-04-25 | 分类于 源码分析

Covenant C2源码调试分析-Grunt

在上篇Covenant创建Launcher时,我们就获取到了Grunt的源码。本篇我们来调试一下Grunt的源码,了解其工作过程。

Grunt工作流程

经过我前期的调试大概了解了一下Grunt的主要工作内容,因为Covenant使用的是非堆成加密,所以Grunt的主要工作就是先进行密钥的交换进行身份验证,然后加载ExecuteStage。

通信过程如下图:

image-20200425223213884

源码分析

Grunt身份验证密钥交换过程分为Stage0、Stage1、Stage2三个步骤。三个步骤的通信内容如下:

  • Stage0:Client提交Rsa密钥,Server使用Rsa密钥加密下发协商密钥
  • Stage1:Client使用协商密钥加密挑战密钥C1发起身份验证请求,Server使用协商密钥加密返回挑战密钥C1+C2
  • Stage2:Client使用协商密钥加密挑战密钥C2,Server解密后验证C2一致则完成认证,返回ExecuteStage

Stage0:

  1. 将预设的共享密钥是作为AESKEY

    image-20200425225309663

  2. 使用共享密钥加密RSA密钥,发送给服务器

    image-20200425225604567

  3. 揭秘获得RSA密钥,并创建协商密钥

    image-20200425225742110

  4. 使用RSA密钥加密协商密钥,发送给客户端

    image-20200425225941487

  5. 客户端收到后解密,获取协商密钥将其作为AES加密密钥

    image-20200425230217162

Stage1:

  1. 客户端使用协商密钥加密4位挑战密钥发送给服务器

    image-20200425230336071

  2. 服务器收到挑战密钥1后新增挑战密钥2,将1、2密钥拼接发送客户端,进行身份认证

    image-20200425230624103

Stage2:

  1. 客户端收到回复后解密信息,验证密钥1是否一致,将挑战密钥2发送给服务器,进行身份认证

    image-20200425230915567

  2. 服务器收到客户端挑战密钥2后进行验证,如果通过,则调用编译ExecuteStageAPI返回ExecuteStage代码

    image-20200425231155096

  3. 客户端收到ExecuteStage后进行内存加载

    image-20200425231439675

总结

本次的源码分析只给出了最核心的密钥交换、身份验证、ExecuteSatge加载过程。其实在分析的过程中还牵扯到框架内互相调用的过程、API的调用、code是如何替换编译的等等,等后期分析完源码后我会写一个Convnant的架构图,可以更清晰的快速了解架构调用逻辑。本人也没有系统的学习的C#在分析代码的过程中,花了一些力气才完全弄懂,心情舒畅了很多。

Covenant源码调试分析-CreateLaunchers

发表于 2020-04-12 | 分类于 源码分析

Covenant源码调试分析-CreateLaunchers

以前一直有想法去自己写一些攻击框架,正好趁着这次工作需求先调研一些攻击框架的工作过程。由于Covenant是C#编写,其编码成本低,容易二次开发,并且对Windows的支持尚佳,就从此框架先入手。

Launcher生成流程

image-20200412205313645

入口获取下断点

  1. 使用浏览器调试工具获取交互接口,URL如下:
1
2
3
4
5
6
7
8
9
/launcher/binary
/launcher/powershell
/launcher/msbuild
/launcher/installutil
/launcher/wmic
/launcher/regsvr32
/launcher/mshta
/launcher/cscript
/launcher/wscript
  1. Covenant项目的launcher模块前端交互处理逻辑在Controllers/ViewControllers/LauncherController.cs,这里先以Binary类型的Launcher为例

    image-20200412182839069

BinaryLauncher分析

EditBinaryLauncher方法

  1. 进入EditBinaryLauncher方法,从方法名和代码内容来看主要是对BinaryLauncher做了做了一个修改更新的操作,最后返回新的BinaryLauncher。

image-20200412184830764

  1. 进入GetBinaryLauncher方法查看,该方法去数据库提取当前BinaryLauncher的配置

image-20200412190055476

  1. 在生成新的Launcher时,我修改了ConnectAttempts的值,最后通过SaveChangesAsync保存

image-20200412191305853

GenerateBinaryLauncher方法

  1. GenerateBinaryLauncher方法主要分为两个部分定义Grunt的属性和生成Grunt代码并编译

image-20200412193849526

image-20200412194654073

  1. 进入GruntTemplateReplace方法,可以看到传入的template.StagerCode参数内容,该代码位Grunt模板代码

image-20200412195100068

  1. 查看GruntTemplateReplace方法代码逻辑,根据通讯类型从配置文件中读取相应的值替换Stager代码,本次测试采用的HTTP信道,最后返回CodeTemplate

image-20200412195216286

  1. 进入CompileGruntCode方法,可以看到该方法调用了修改和编译方法来输出编译好的二进制数据

image-20200412200521636

  1. 由于Source的值无法调试获得,所以在方法外添加一条模板修改方法,查看替换后的结果。可以看到相关的值已经替换为配置文件中的属性

image-20200412201504316

image-20200412201353408

  1. 进入GetLauncher方法,逻辑只是把二进制数据编码返回(感觉传了很多没用的),最后将launcher对象保存,同步到数据库,至此BinLauncher生成完毕。

image-20200412201818815

总结

本次分析了BinaryLauncher的生成过程,过程比较简单。就是从数据库读取StagerCode模板,然后进行修改。我也看了其他Launcher的代码Binary是一样的。

Covenant C2框架调研及扩展

发表于 2020-04-04 | 分类于 渗透测试

Covenant C2框架调研及扩展

前言

这半年来BLOG都没有更新,这段事件主要的工作是忙于ATT&CK框架的应用落地,其中做的一块工作就是攻击模拟、规则提取、知识库总结。以前的攻击模拟都是自己写的散装脚本或程序,在真正到了项目需要落地或POC测试时,还是需要进行复现效果展示的,所以最近开始调研一些开源的攻击框架把攻击本都集成进去,帮助项目进行效果展示。

后来关注到Covenant这个C2框架,它使用DotNet编写所以天然对Windows的操作支持良好,利用DotNet已有的API可以快速编写Windows下的利用程序,故对Covenant做了一些调研和Demo。

Covenant介绍

Covenant分为4个核心的模块:Listeners、Launchers、Grunts、Tasks,模块都具备高自由度、扩展性。

Listeners:

和其他的框架类似Listeners的功能为设置C2框架的监听设置。Listeners可以在前端对于HTTP通信隧道的属性(Urls\Head\Useragent\PostRequest\Response)进行修改,操作非常简单,也可以利用Bridge开发自己自定义通信隧道。

Launchers:

该模块的功能为加载Stage的模块,相当于ShellCode Load的程序。Covenant在该模块提供了几个常见的白名单程序加载方案,虽然可能现在也不再“白”了:Binary、Powershell、MSBuild、InstallUtil、Wmic、Regsvr32、Mshta、Cscript、Wscript。

在前端未发现扩展Lunchers的按钮,如果要扩展加载模块可能需要在源码更改编译。

Grunts:

该模块的功能为管理上线的终端主机,可远程查看信息、执行命令等

Tasks:

该模块为后渗透模块,目前集合多种开源模块:Rebeus、Seatbelt、SharpDPAPI、SharpDump、SharpSploit、SharpUp、SharpWMI。

Covenant Task扩展

Covenant后渗透模块扩展,需要通过添加Reference Source Libraries被调用。调研初衷是想在ATT&CK落地项目中进行效果测试,那这样咱们的目标明确就是要做一个ATT&CK的模拟攻击DLL。

以Discovery战术下的IP地址获取为例,C#的DLL代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
using System.Net;
using System.Net.Sockets;

namespace AttAck.Discovery
{
public class Discovery
{
public static string GetHostAddress(string[] args)
{
string Output = "";
var host = Dns.GetHostEntry(Dns.GetHostName());
foreach (var ip in host.AddressList)
{
// 下面的判断过滤 IP v4 地址
if (ip.AddressFamily == AddressFamily.InterNetwork)
{
Output = Output + ip.ToString() + "\r\n";
}
}
return Output;
}
}
}

将C#的项目源代码目录放置到Covenant/Data/ReferenceSourceLibraries目录下

image-20200404122225637

在Covenant->Tasks模块下创建新的ReferenceSourceLibrary引用并选择支持的DotNet版本和引用的程序集

image-20200404122437800

image-20200404122741581

Covenant默认存在的程序集可在Reference Assemblies标签页查看,内置大部分常用的程序集,如果你需要新增的ReferenceSourceLibrary引用的程序集不在范围内需要自己将程序集复制到AssemblyReferences目录下。

在成功导入AttAck库后,新增Task任务调用DLL程序集中的方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
using System;
using AttAck.Discovery;

public static class Task
{
public static string Execute()
{
try
{
return Discovery.GetHostAddress();
}
catch (Exception e) { return e.GetType().FullName + ": " + e.Message + Environment.NewLine + e.StackTrace; }
}
}

添加Task后可以通过Grunts向上线主机发送task任务或者通过Interact命令行执行命令

image-20200404124523213

结论

Covenant在扩展性方面是友好的,开发成本低,速度快,界面简洁,操作门槛低,对于开发好的模块可以快速的实施测试。但是是基于DotNet开发的特性导致不适用于一些不满足DotNet环境的目标机器,这导致了在通用性有所欠缺,如果后续需要加入针对Linux平台的测试脚本,可能需要另外基于Python或perl开发新的Listeners模块和Grunts模块。在这方面可能Covenant就不如Empire,但是我依然非常喜欢C#。后面我会继续看一看Covenant的源码,了解其详细的运行原理,并记录。

Powershell v5脚本块审计能力探究

发表于 2020-04-02 | 分类于 安全建设

Powershell V5脚本块审计能力探究

前言:

这几天在测试SPN扫描的时候准备提取特征,寻思目前使用的两种比较常见的手法

  • Windows自带程序setspn
  • 脚本连接LDAP查询用户属性

心想如果一个SPN的Powershell脚本大概率会在脚本中过滤出serviceprincipalname字段,看了几个SPN的脚本也确实如此,这时准备从4104事件的scriptContent中做匹配。

利用脚本GetUserSPNs.ps1做POC测试提取日志样例时,Windows Powershell审计始终无法获得脚本内容。这情况以前没遇到,就开始排查为啥,和以前的脚本有什么区别。

发现:

怀疑过new-object新建对象问题,怀疑过是否只能监控cmdlet和Function函数块的问题。但是经过大量测试,最后发现居然是:当有传参传入时,Windows只能记录Function块里的内容,当没有参数时,则可以记录脚本所有内容!!!

找了半天也没人说这个问题,不知道Windows内部是如何实现的

截图:

image-20200402212847879

image-20200402212932189

无参数传入时,均可以记录

image-20200402212552869

image-20200402212608384

结论:

在某种程度上,对脚本传入参数并且不适用函数则可以一定程度的逃避Windows 4104事件的审计。虽然这并不能逃避4103事件,但是4103事件是针对于单个cmdlet做审计,在分析过程中想要对此类事件进行分析挖掘,难度是较大的,没有4104脚本块内容来的直观。

ATT&CK与SIEM的结合应用思考

发表于 2020-03-19 | 分类于 安全建设

ATT&CK与SIEM的结合应用思考

​ AiLPHA安全分析团队

前言

要说今年安全圈里最火的词之一莫过于“ATT&CK”,ATT&CK也被列为今年Gartner SIEM魔力象限的参考指标之一。安恒Ailpha实验室专注于SIEM领域的探索,自然也时刻关注ATT&CK框架在SIEM领域的应用与实践。ATT&CK框架构建的知识库为安全行业提供了一个标准,对于已知的战技术收集也为安全产品的进步提供了帮助。本文从TTPs的作用、分析溯源等方面提出一些关于ATT&CK框架在SIEM产品中应用的理解,欢迎大家探讨。

一、ATT&CK框架的了解

先看一下“ATT&CK”的全称“Adversary Tactics and Techniques & Common Knowledge”,他设计初衷是构建一个攻击者战术和技术的共享知识库。记得在17年首次关注ATT&CK矩阵,那时只有近百个技术,没人会想到在今天ATT&CK会成为大部分安全从业者都在关注的一个词。MITRE成功了,ATT&CK也成功了,现在它逐渐成为一个业界公认的红蓝知识库,越来越多的从业者和厂商向框架内贡献技术点,使得这个框架的发展与应用更加快速。

提到ATT&CK框架就不得不提TTP,这是一个军事术语,现在被引用到网路安全领域。

  • 战术(Tactic):发起一个攻击的意图

  • 技术(Techniques):实施一个攻击的技术

  • 过程(Procedures):实施一个技术的流程

那么ATT&CK究竟能给安全行业带来什么?

  • ATT&CK框架可以成为业界的标准(能力可度量)

    目前ATT&CK框架主要包含终端相关安全知识,可以根据检测能力的矩阵覆盖率来评估部分安全产品的能力,例如:沙箱、EDR、SIEM等。

    如果顺利发展的话后期也可能加入Web安全相关安全知识,那时WAF、RASP、代码审计等Web相关安全产品也可以凭借框架进行评估。

    终端在检测漏洞利用方面的能力较弱,等漏洞利用子技术丰富后,流量设备是否可以借此来评估检测能力,虽然现在有一个现成的CVE库,但和知识库还有一些距离。当然这些只是个人的猜测,毕竟漏洞有点多,这是一个浩大的工程。

    能力的度量需要客观、统一的标准,而不是自说自话。当然这里的覆盖率只是指标之一,覆盖规则的质量也是非常重要的,但往往质量比数量更难评估~

  • ATT&CK框架可以成为业界的通用语言(威胁数据标签化)

    经过多年的安全分析工作,每天被不同厂家的不同版本的不同设备折磨。今天这个设备的告警叫”smb漏洞利用“,明天相同的告警叫”MS17-010“,这只是一个简单的例子,就仿佛分析师必须会两种语言甚至更多才能胜任其工作。语言多样性同时造成语言障碍,影响协作能力。 都说攻防不对称,但当面对强大的对手,防守方可能从未站在一个阵线 。如果不管是”smb漏洞利用“还是”MS17-010“,以后大家都称其为T1210-Exploitation of Remote Services,SubTxxxx-MS17010,每个人的一小步,却是行业的一大步。

ATT&CK模型是在洛克希德-马丁杀伤链的基础上,构建了一套更细化、更贴合实战的知识模型和框架,它主要分为3个矩阵:

​ PRE-ATT&CK:攻击前的准备,例如战略计划制定、武器化、信息收集、脆弱点发现等

​ Enterprise:攻击时的部分已知技术手段,例如初始权限获取、执行、防御逃避、横向移动等

​ Mobile:移动端的部分已知技术手段,移动框架和Enterprise类似,只是适用的平台不同

目前SIEM并没有涉及到太多的移动端安全问题,所以移动端就不放在本次的讨论范围之内。

PRE-ATT&CK目前对于防御者来说可见性比较低,目前大多数采用预防性防御方法,比如进行安全意识培训抵御社会工程学攻击,定期漏洞扫描来规避易被发现的脆弱点,定期的监控开源代码仓库有无泄露项目源代码、VPN账号、员工邮箱、敏感密码等

Enterprise既是当用户已经在内部有了驻足点后的行为矩阵,在这个矩阵中,企业数据探针较完善的情况下可见度是比较高的,可以更好的利用此矩阵内的数据源进行威胁的捕获与分析,因此Enterprise也是目前备受关注的矩阵,也是我们本篇重点讨论的矩阵。

image-20191105150106067

(图片来源于:网络)

二、SIEM产品与ATT&CK框架的结合应用

TTP的标签
  1. 数据源的选择

    在利用ATT&CK的TTP来描述在环境中发现的威胁之前,需要接入相关数据作为底层的支持。在这次ATT&CKcon会议上看到的一张数据源排行榜,可见进程创建、进程命令、文件监控占了很大的比重。sysmon的数据目前可以基本满足需求

    (图片来源于:hxxps://pbs.twimg.com/media/EICsnZ_XYAAyyxd?format=jpg&name=medium)

  1. 数据标签化

    由于SIEM平台本身接入的数据量太大并且有很多没有分析价值的数据,平台需要抽象出一层关注的安全事件,这些事件不一定是恶意攻击,比如Powershell、CMD这些运维管理员也会使用的程序,抽象出的事件需要一个标签来描述事件的含义,这时TTP的ID就成了最好的标签。TTP的背后是完善的知识库,每个技术都可以追溯其利用原理、战术意图。

    通常使用规则将数据打上标签,所以需要先梳理技术对应的数据源,以下表为例

    image-20191105203041360

SIEM做的是数据分析,ATT&CK可以将数据添加一层标签,标签的生成来自与规则,标签化的流程与利用,如下图:

image-20191106104303010

ATT&CK的规则是ATT&CK框架应用的基础,也是难点。初步可以根据github上一些开源的项目进行实施和优化,例如:sentinel-attack、sysmon-config、sigma等。与其他产品类似,主要的问题在两个方面:

  • 规则的质量

    规则的质量一直是厂商头疼的问题,更是困扰安全分析师和运维人员的难题。当底层数据不可信时,分析的都是错数据,分析的结果又怎么能对呢。在开源规则的基础上我们可以在各种环境下测试规则的误报并进行调试,针对特定规则可能需要手动复现提取更加准确的特征。

  • 规则的覆盖率

    虽然ATT&CK框架号称是原子级技术分解,其实并没有达到这个程度,例如 T1055 -进程注入,虽然在它的知识库里也列出了几种注入的方法,但是真正的注入方法就不止10种。那当一个产品说我覆盖了 T1055 -进程注入,覆盖了其中一种技术还是十种技术对应的能力显然是不同的。为此MITRE也及时做出了调整推出Sub-Techniques的概念,这是真正意义上的原子级技术点。相对于现在的Techniques,Sub-Techniques才能客观的标识一个产品的检测能力覆盖面,让我们拭目以待。

    ECl3z_FXsAE892F

    (图片来源:hxxps://pbs.twimg.com/media/ECl3z_FXsAE892F?format=jpg&name=900x900)

  1. 标签的权重

    分析标签时和分析数据一般无二,有的数据只是用参考的,有的数据却标注着企业内部可能正在发生攻击行为。 我据规则的置信度、检测粒度将标签粗略分为:失陷告警、参考告警、审计信息三大类。

    image-20191106202335964

    • 失陷告警:极低误报率、确切高危行为的告警

    • 参考告警:存在误报情况的高危行为告警、较低误报率的中危告警

    • 审计信息:可能被攻击者利用也可能是用户自己操作的行为

举例:

​ Powershell目前被攻击者频繁利用,也是终端必须审计的数据源之一。

​ 若规则为定义如下,那么这只能算是一个审计信息。

1
2
> Image contains 'powershell.exe'
>

​ 若规则有了更细致的特征,那么可以定级为一个参考告警甚至失陷告警。

1
2
> Image contains 'powershell.exe' and CommandLine contains ('-w hidden' or '–Exec Bypass' or '-c' or '-Enc' or '–Nop' or 'DownloadFile')
>

​ 有了详细的特征为什么还需要使用宽泛的审计规则:世上没有完美的规则,规则总可能被绕过,这时还 有审计信息给予我们溯源的可能。

​ 审计规则可以记录所有动作为什么还要颗粒度更高的规则:权重!让机器帮你做初步的筛选,直接关注存 在的高风险问题,权重不同的告警在场景化过程中对结果的判断也会有影响。

分析溯源

无论是APT还是常规的渗透攻击,可能会用一些目前未知的技术手段或者0DAY,但也必然会用到其他已知的攻击手段,这时我们的标签化的数据就起到了分析的价值,可以根据标签进行行为分析、异常分析等

  1. 进程树的分析

    当我们触发告警时,可以溯源该告警进程的进程树。此时可将进程树的上所有进程附着的TTP标签作为数据,分析这个树是否为一条失陷的攻击链,在进程树生成后也会发现许多没有标签的进程,这些可能是你规则遗漏的检测点。

    举个简单一点的判断逻辑:

    a. 是否树上可以有多个权重较高的标记

    b. 是否树上有超过${Num}个不同的标记

    当然实际应用中可能需要其他更完善的算法。假想能否将一台主机上的所有进程导入图数据库,这样就可以获得单台机器某个时间段下全局进程图的视角,这比分析某个进程树来的更加直观和全面。

  2. 标签分布分析

    我们可以为每台主机维护一个矩阵图,把主机上的TTP标签作为数据,分析这个主机是否为一个失陷主机。

    举个简单一点的判断逻辑:

    a. 是否主机上可以有多个权重较高的标记

    b. 是否主机上有超过${Num}个不同的标记

    c. 是否主机上有超过${Num}个不同的战术意图

    image-20191106193234466

    当然光靠阈值可能依然存在一些误报情况,我们可以引入机器学习算法辅助确认主机是否失陷。在内网的运维过程中,我们收集以单台主机上的TTP标签分布为样本数据,对主机进行分析后,若手动判定为失陷则加入黑样本,其他认为是白样本。利用样本集训练模型作为一种辅助判断的手法,来提高风险主机的处理优先级。在客户运维的过程中,还可以利用主动学习算法不断的优化辅助模型。

  3. 内网的溯源

    当检测到失陷主机有进程访问内网其他机器时,展示该机器上检测到的TTP信息及摘要。可以根据此信息来判断是否为横向移动攻击,例如winrs是一种横向移动手段,发现主机10.50.10.100通过winrs连接到内网机器10.50.10.105,又发现主机10.50.10.105上有权重较高的标签T1060-Registry Run Keys / Startup Folder、T1003-Credential Dumping、T1191-CMSTP,那可能大概率横向移动的结果是成功的。

    image-20191107141144507

  4. 上下文描述

    可为每个标签添加更细节和通俗的描述作为场景化描述的基础语句,再将其组合起来成为完整的描述一个场景。以进程树为例,对每一层树中的操作进行战术分类后以时间轴的形式进行描述。

    2019/11/07 16:31:05 进程IJIurngei.exe通过漏洞CVE-2018-8120提升权限运行uziYaoqomsfT.exe,进进程用户由User提升到System,达到权限提升目的;

    2019/11/07 16:31:07 进程uziYaoqomsfT.exe连接远程域名download.microUpdate.com,疑似达到远控目的;

    2019/11/07 16:31:15 进程uziYaoqomsfT.exe释放文件svchost.exe,达到伪装目的;

    2019/11/07 16:31:18 进程svchost.exe连接远程域名ginni.go0gle.com,疑似达到远控目的;

    2019/11/07 16:31:23 进程uziYaoqomsfT.exe运行程序cmd.exe,达到执行目的;

    2019/11/07 16:31:24 进程cmd.exe运行程序tasklist.exe、systeminfo.exe、net.exe、net1.exe、whoami.exe,达到发现目的;

    2019/11/07 16:31:32 进程cmd.exe运行程序mimi.exe访问lsass.exe进程,达到凭证获取目的;

    2019/11/07 16:32:03 进程cmd.exe运行程序winrs.exe连接远程主机10.50.10.105,目标机器上存在3个较高权重的标签T1060-Registry Run Keys / Startup Folder、T1003-Credential Dumping、T1191-CMSTP,疑似达到横向移动目的;

红蓝知识库

虽说ATT&CK框架期望实现一个大而全的威胁知识库,但目前的阶段仅仅处在告诉你有这个东西。虽然MITRE建立一个Cyber Analytics Repository,但由于内容太少不足以提供丰富的检测能力。不过也有很多迫不及待的人已经提前动起了手,例如Red Teaming Experiments、atomic-red-team,但他们更注重的是Red Team攻击过程的复现,我们期望的是Red Team代码级复现+Blue Team威胁特征提取。

image-20191107105217738

  1. 威胁检测

    比起说红蓝知识库可以帮助威胁检测,倒不如说为了更好的检测才有了红蓝知识库。为了有更精确的告警采取复现攻击技术,红蓝知识库只是衍生总结出的产物。

  2. 用户赋能

    既然有了知识库自然要利用起来,SIEM是一个需要安全知识才能使用起来的安全产品,对于分析师的能力有要求,目前红蓝知识库可以提供给分析人员更多更详细的学习指导

小结

随着ATT&CK框架的快速发展,会有越来越多的应用方向。但在目前这个阶段我觉得帮助最大的还是恶意行为的检测和分析。万丈高楼始于垒土,踏踏实实致力于实战,若文中有描述不足的地方欢迎交流,开放才能更快的进步,共勉。

基于开源软件打造企业网络安全-读后感

发表于 2019-05-01 | 分类于 读后感

前言

最近读了兜哥的《企业安全建设入门:基于开源软件打造企业网络安全》,书的内容相对入门,主要介绍一些领域的开源软件和一些简单的配置,快速的过了一遍书上的内容后提炼精华的部分做成一个脑图,以便总结书中的内容。以后看脑图就知道书中内容,减少阅读时间。书中的干货不多,不建议购买。哈哈~ 希望安全领域可以多出一些有内容的新书分享给大家。
image

osquery-初步了解

发表于 2019-04-13 | 分类于 安全建设

前记

目前网络安全发展速度越来越快,传统的终端防护杀毒软件,已经无法达到企业对网络终端安全状况的感知期望。在数据驱动安全的背景下,EDR产品近两年较为火热,但国内并没有成熟的EDR产品问世。一些有实力的甲方企业会根据开源的EDR产品进行二次开发来满足企业需求,我们接下来说的osquery就是其中之一。
我是一个安全分析工程师,平时的工作就是对海量安全数据做分析工作,有的时候在网络流量、安全设备上发现蛛丝马迹后由于缺少终端信息,无法准确定位安全风险,所以我认为收集终端的信息来进行关联分析(XDR),异常算法是非常有价值的。

运行模式

osquery有两种运行模式分别为shell、daemon。shell模式为临时查询的CLI形式,daemon为服务模式长期运行在系统中。

  • shell
    1.数据存储在内存表中
    2.临时的CLI交互模式来查询系统当前状态

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    [root@localhost ~]# osqueryi
    Using a virtual database. Need help, type '.help'
    osquery> .help
    Welcome to the osquery shell. Please explore your OS!
    You are connected to a transient 'in-memory' virtual database.

    .all [TABLE] Select all from a table
    .bail ON|OFF Stop after hitting an error
    .echo ON|OFF Turn command echo on or off
    .exit Exit this program
    .features List osquery's features and their statuses
    .headers ON|OFF Turn display of headers on or off
    .help Show this message
    .mode MODE Set output mode where MODE is one of:
    csv Comma-separated values
    column Left-aligned columns see .width
    line One value per line
    list Values delimited by .separator string
    pretty Pretty printed SQL results (default)
    .nullvalue STR Use STRING in place of NULL values
    .print STR... Print literal STRING
    .quit Exit this program
    .schema [TABLE] Show the CREATE statements
    .separator STR Change separator used by output mode
    .socket Show the osquery extensions socket path
    .show Show the current values for various settings
    .summary Alias for the show meta command
    .tables [TABLE] List names of tables
    .width [NUM1]+ Set column widths for "column" mode
    .timer ON|OFF Turn the CPU timer measurement on or off
    osquery>
  • daemon
    1.在守护进程模式下运行数据存储在RocksDB数据库中
    2.以守护进程形式运行,可以记录操作系统的状态变化并生成日志(生产环境中主要的模式)
           
    举例:

       在配置文件的schedule中加入进程监控

1
2
3
4
"processes": {
"query": "SELECT pid,uid,name,path,cmdline from processes;",
"interval": 5
}

       生成记录日志

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
"name": "processes",
"hostIdentifier": "localhost.localdomain",
"calendarTime": "Tue Apr 9 14:28:40 2019 UTC",
"unixTime": 1554820120,
"epoch": 0,
"counter": 101,
"decorations": {
"host_uuid": "4EC54D56-FFDC-98EC-C263-9424C3FE03CE",
"username": "root"
},
"columns": {
"cmdline": "curl baidu.com",
"name": "curl",
"path": "/usr/bin/curl",
"pid": "1106",
"uid": "0"
},
"action": "added"
}

配置说明

  • options
    options记录osqueryd初始化启动参数,可以通过osqueryd –help来查看
  • schedule
    schedule是osquery的核心功能,通过配置定时任务监控系统信息
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    {
    "schedule": {
    "users_browser_plugins": {
    "query": "SELECT * FROM users JOIN browser_plugins USING (uid);",
    "interval": 60
    },
    "hashes_of_bin": {
    "query": "SELECT path, hash.sha256 FROM file JOIN hash USING (path) WHERE file.directory = '/bin/';",
    "interval": 3600,
    "removed": false,
    "platform": "darwin",
    "version": "1.4.5",
    "shard": 1
    }
    }
    }

       users_browser_plugins、hashes_of_bin为查询项的键名可自定义
       query:需要查询目标的SQL语句
       interval:查询动作的时间间隔
       removed:是否记录移除动作(进程结束等),默认true
       platform:查询动作仅在对应平台下运行
       version:查询动作仅在满足条件的osquery版本运行

  • packs
    packs相当于将一组相关的查询SQL打包为一个conf文件,这样的好处可以通过适用场景来发布配置文件
  • discovery queries
    发现查询是packs查询里的一个功能,主要的目的是当满足一定条件的情况下才启用查询,避免做无意义的动作
    发现查询默认1小时更新一下状态,通过修改pack_refresh_interval的值定义更新间隔
    同一个discovery组多个条件的关系为OR

注意问题

1.osquery存在瞬时动作漏报的情况,比如interval为3600s,若一个动作在3600s的间隔内开始并结束,则不会被记录
2.osquery在机器处于休眠状态时interval将停止计时

日志收集

osqueryd可以通过filesystem (default), tls, syslog (for POSIX), windows_event_log (for Windows), kinesis, firehose, and kafka_producer等方式来记录日志,在实施阶段可能使用较多的模式为filesystem、syslog、kafka_producer三种方式。

osqueryd有两种记录日志的模式Differential(差异记录)、Snapshot(快照记录)两种模式区别如下:
Differentia:在osqueryd第一次查询后,下一次查询只记录与上次查询结果不同的项
Snapshot:每次都保存全部查询结果

后记

这篇就是根据官方的Doc文档做一个初步的了解,后面会模拟一个osqueryd的实施架构,在思考一下根据osqueryd数据能做出哪些场景

参考

https://osquery.readthedocs.io/en/stable/
https://osquery.io/schema/3.3.2

123
L.Lawliet

L.Lawliet

24 日志
7 分类
29 标签
© 2020 L.Lawliet