简介这是一份面向网络安全从业人员、安全分析师及初学者的实战型攻击溯源技术手册聚焦APT攻击识别、恶意软件分析与应急响应系统设计系统解决网络攻击事件中‘谁在攻击、如何攻击、从哪来’等核心问题。资源为单文件Word文档.docx共1个文件大小9.52MB内容结构清晰分为‘技巧篇’与‘实战篇’技巧篇详解攻击IP、恶意文件、C2地址等关键线索的优先级判定与多维画像构建方法实战篇覆盖威胁情报平台使用、域名/IP反查、跳板机与Webshell专项分析并嵌入真实钓鱼邮件与Web攻击溯源案例附常用工具链如微步云沙箱、Wireshark、IDA及动态调试、字符串提取等实操要点。目前已有98人学习下载适合安全人员快速建立标准化溯源流程、提升应急响应效率并作为日常工作的可检索技术字典持续复用。1. 网络安全实战派的“攻击者画像生成器”不是教你怎么查IP而是教你把零散线索串成一张有逻辑、能验证、可落地的攻击者关系网你刚收到一条告警某业务系统被扫描源IP是203.124.87.156类型为“HTTP目录遍历”时间戳精确到秒。运维甩来一个截图附言“赶紧看看是不是误报”。这时候翻手册——不是找“怎么查Whois”而是立刻判断这个IP大概率是VPS还是IDC要不要优先处理它背后有没有跳板机C2地址藏在哪段JS里这份《网络安全基于实战技巧的网络攻击溯源手册》干的就是这事它不讲OSI七层模型不画APT攻击链图谱而是一本带血丝的“现场作业手账”。你撕下一页贴在工位玻璃上就能对着Wireshark抓包、Process Monitor日志、微步情报页三屏联动操作你用它查到的不是“该IP归属某云厂商”而是“该IP段三个月内关联17个恶意域名其中3个与去年某金融钓鱼事件同源”。它把威胁情报当草稿纸用把沙箱报告当拼图碎片看把日志里的Accepted password for root和/var/log/secure里同一时间戳的systemctl start sshd连成线——最终输出的不是“疑似攻击者”而是“姓名/ID推断、地理位置三级定位、关联社交账号微博ID抖音昵称、跳板机IP已确认、C2通信特征AES-128-CBCBase64编码”。适合每天要处理5起告警的安全分析师、刚接手HW行动的蓝队新人、以及想把CTF解题思维迁移到真实攻防中的渗透测试员。它不承诺“100%锁定真凶”但保证每一步操作都有出处、每条线索都可回溯、每个结论都经得起交叉验证。2. 攻击信息四维拆解法从攻击IP、攻击类型、恶意文件、受攻击域名/IP出发建立可执行的优先级决策树2.1 攻击类型决定溯源路径为什么“命令执行”比“爬虫”值得你先花20分钟接到溯源任务时第一眼必须盯死攻击类型——它直接决定你打开哪个工具、查哪类日志、甚至是否需要立刻封禁。手册里把常见攻击类型按“线索密度”和“溯源效率”做了硬性分级这不是主观排序而是基于三年HW行动中217起真实事件的统计结果攻击类型线索密度★溯源耗时中位数关键突破口是否建议优先处理命令执行★★★★★8.2 分钟/tmp/.X11-unix/下残留shell脚本、/proc/[pid]/environ中环境变量是端口扫描★★★★☆12.5 分钟Nmap指纹识别结果、扫描源IP的ASN归属、历史扫描行为聚类是WebShell上传★★★★☆15.3 分钟access.log中POST请求体、/var/www/html/下可疑.php文件、/tmp目录下.sh临时文件是钓鱼邮件★★★☆☆28.7 分钟邮件头Received:字段链、附件MD5哈希、发件人邮箱注册时间否需配合恶意文件分析爬虫★★☆☆☆41.6 分钟User-Agent字符串、robots.txt访问记录、CDN节点IP反查否最后处理提示所谓“线索密度”指单位时间内能提取出有效溯源线索的数量。例如“命令执行”攻击必然留下进程、文件、网络连接三重痕迹而“爬虫”可能只有User-Agent和访问频率两个维度且极易伪造。以“命令执行”为例它的高优先级源于三个不可替代的物理证据层进程层ps aux --sort-%cpu | head -20能快速筛出CPU占用异常的进程结合ls -l /proc/[pid]/exe查看真实路径注意/proc/[pid]/exe是符号链接readlink /proc/[pid]/exe才是真路径文件层find /tmp -type f -mmin -60 -name *.sh -o -name *.py可捕获60分钟内创建的脚本再用strings [file] | grep -E (curl|wget|nc|bash)提取网络行为网络层netstat -tulnp | grep :[port]定位监听端口后用lsof -i :[port]反查PID再通过cat /proc/[pid]/cmdline | tr \0 \n还原完整启动命令。这三层证据链一旦闭合就能绕过威胁情报平台的误报干扰直接锁定攻击载荷来源。比如某次HW中netstat发现127.0.0.1:31337被监听lsof显示PID为12345cat /proc/12345/cmdline输出/usr/bin/python3 /tmp/.cache/update.py而strings /tmp/.cache/update.py里赫然出现https://c2-xyz[.]top/api/v1/report——此时C2地址已实锤无需再等微步情报更新。2.2 攻击IP的威胁情报三阶验证法为什么同一个IP在微步、360、VenusEye上显示不同归属威胁情报平台不是搜索引擎而是多源数据的“冲突仲裁器”。手册强调绝不单独信任任一平台的结论必须执行“三阶验证”——即同一IP在至少三个平台查询后对比其“IP归属”、“历史关联域名”、“恶意行为标签”三项核心字段的共识度。以IP203.124.87.156为例# 步骤1并行调用API需提前注册各平台API Key curl -s https://api.threatbook.cn/v3/ip/report?apikeyxxxip203.124.87.156 | jq .data.attributes.as_owner curl -s https://ti.qianxin.com/api/v1/ip?apikeyxxxip203.124.87.156 | jq .data.as_name curl -s https://api.venuseye.com/v3/ip/report?apikeyxxxip203.124.87.156 | jq .data.as_owner假设返回结果如下微步China Telecom360China Telecom BeijingVenusEyeChina Unicom此时共识度为2/3电信但VenusEye的“联通”结论需重点排查——因为该IP在微步和360的历史关联域名中xxooxxoo.xyz和scan-2023[.]top均使用Cloudflare CDN而Cloudflare的ASN常被错误标记为“联通”。验证方法用curl -v https://xxooxxoo.xyz 21 | grep X-CF-Powered-By确认CDN标识再查Cloudflare官方ASN列表AS13335即可排除VenusEye的误判。参数说明jq是JSON解析利器.data.attributes.as_owner是微步API的归属字段路径X-CF-Powered-By是Cloudflare的响应头标识存在即证明该域名走CDN其源站IP与CDN节点IP无地理关联。更关键的是“历史关联域名”字段。若三个平台均显示该IP曾解析到malware-dump[.]com已下线、apt-c2-2023[.]org活跃、test-scan[.]net3个月前活跃则说明该IP具备持续性攻击特征应立即加入内部黑名单并触发全网DNS日志回溯——查过去7天所有解析到该IP的域名再用dig short [domain] A验证当前解析状态形成动态威胁图谱。2.3 恶意文件分析的“动静双轨制”为什么IDA静态分析必须搭配Wireshark动态抓包恶意文件不是待解谜题而是攻击者的“数字分身”。手册要求任何PE/ELF文件必须同时走静态分析Static Analysis和动态分析Dynamic Analysis两条轨道缺一不可。静态分析解决“它能做什么”动态分析验证“它实际做了什么”。静态分析轨道以PE文件为例# 步骤1识别文件格式与加壳状态 file malware.exe # 输出malware.exe: PE32 executable (GUI) x86-64, for MS Windows # 步骤2计算多哈希值MD5/SHA1/SHA256 md5sum malware.exe sha1sum malware.exe sha256sum malware.exe # 输出示例a1b2c3d4... (MD5), e5f6g7h8... (SHA1), i9j0k1l2... (SHA256) # 步骤3提取字符串重点关注URL、域名、API调用 strings -n 8 malware.exe | grep -E (http|https|\.com|\.org|\.top|CreateThread|WinExec|ShellExecute) # 输出示例https://c2-xyz[.]top/api/v1/report, CreateThread, WinExec # 步骤4用PEiD查壳若显示UPX 3.96则需先脱壳 peid malware.exe # 若加壳用upx -d malware.exe -o malware_unpacked.exe 脱壳动态分析轨道沙箱本地调试# 步骤1上传至微步云沙箱https://s.threatbook.cn/获取网络行为报告 # 关键看DNS请求列表、HTTP POST目标、TCP连接目标IP及端口 # 步骤2本地用Wireshark抓包需关闭防火墙 wireshark -i eth0 -f host 192.168.1.100 and port 443 -w malware.pcap # 其中192.168.1.100是运行恶意文件的测试机IP # 步骤3用Process Monitor监控文件/注册表操作 procmon.exe /BackingFile C:\temp\malware.pml /Minimized /Quiet # 运行恶意文件后用Filter设置Path contains .tmp或Operation is RegSetValue逻辑说明静态分析的strings命令可能漏掉加密字符串如Base64编码的URL而动态分析的Wireshark能捕获解密后的明文流量反之动态分析可能因沙箱检测而触发反调试逻辑导致C2通信失败此时静态分析的导入表Import Table就成为唯一线索——WinExec函数的存在意味着该文件极可能执行外部命令InternetConnectA则暗示网络通信能力。真正有效的分析是让两条轨道的数据互相校验。例如静态分析发现https://c2-xyz[.]top/api/v1/report而Wireshark抓包显示实际连接的是192.168.3.11:443该IP在微步情报中被标记为c2-xyz[.]top的CDN节点此时就能确认C2地址的真实性并进一步用nslookup c2-xyz[.]top查看其DNS解析历史发现该域名3天前解析到104.28.1.2另一CDN节点从而构建C2基础设施的演进路径。2.4 受攻击域名/IP的“逆向拓扑重建”如何从一个被黑的Web服务器挖出背后的跳板机集群受攻击目标不是终点而是进入攻击者基础设施的“签证入口”。手册提出“逆向拓扑重建法”以被攻陷服务器为圆心向外辐射三层关联关系——直接解析层、历史解析层、SSL证书层。这三层数据共同构成攻击者的网络拓扑骨架。直接解析层当前DNS状态# 查询域名当前A记录注意需绕过本地DNS缓存 dig short example.com A 8.8.8.8 # 输出192.168.1.100被黑服务器IP # 查询CNAME记录常隐藏CDN或跳转 dig short example.com CNAME 8.8.8.8 # 输出example.cloudfront.net. # 用ping.chinaz.com全局Ping确认是否CDN curl -s http://ping.chinaz.com/example.com | grep -oP cdn.*?(\d\.\d\.\d\.\d) # 输出CDN节点IP 104.28.1.2历史解析层域名变更轨迹# 用whois.chinaz.com查历史Whois需人工截图API受限 # 关键字段Registrant Name注册人姓名、Registrant Email注册邮箱、Name ServerDNS服务器 # 用RiskIQ社区查历史解析https://community.riskiq.com/ # 输入example.com查看Passive DNS标签页导出CSV # 筛选条件Record Type A, First Seen 2023-01-01, Last Seen 2023-06-01 # 输出192.168.1.1002023-03-15, 10.0.0.52023-04-22, 172.16.0.102023-05-30SSL证书层加密通信锚点# 获取当前SSL证书信息 openssl s_client -connect example.com:443 -servername example.com 2/dev/null | openssl x509 -noout -text | grep -E (Subject|Issuer|DNS|CA Issuers) # 输出关键字段 # Subject: CN example.com # X509v3 Subject Alternative Name: DNS:example.com, DNS:www.example.com, DNS:admin.example.com # CA Issuers: URI:http://cacerts.digicert.com/DigiCertTLSRSA4096SHA3842021CA1-1.crt # 用crt.sh查该证书关联的所有域名证书透明度日志 curl -s https://crt.sh/?q%example.comoutputjson | jq -r .[].name_value | sort -u # 输出example.com, admin.example.com, api.example.com, backup.example.com参数说明dig short省略冗余输出8.8.8.8强制使用Google DNS避免本地污染openssl s_client的-servername参数启用SNI确保获取正确证书crt.sh是免费的证书透明度查询服务其JSON接口返回所有匹配域名。当这三层数据叠加时拓扑结构自然浮现若example.com当前解析到192.168.1.100历史解析显示10.0.0.5内网IP而SSL证书关联域名中包含backup.example.com且backup.example.com的历史解析指向172.16.0.10另一内网IP那么10.0.0.5和172.16.0.10极可能是同一内网中的跳板机。此时应立即登录192.168.1.100执行netstat -tulnp | grep :22查看SSH监听状态并用last -i查看最近登录IP——若发现10.0.0.5和172.16.0.10的登录记录则跳板机集群实锤。3. 溯源结果框架的“五维交叉验证法”如何把零散线索组装成经得起质询的攻击者画像3.1 姓名/ID的“社交图谱锚定术”为什么不能只靠QQ号反查而要构建邮箱→手机号→支付宝→微博的证据链溯源报告中最易被质疑的就是“姓名/ID”这一项。手册严禁单点突破强制要求“五维交叉验证”——即至少通过邮箱、手机号、支付宝、微博、微信五个独立渠道获取指向同一自然人的证据且每个渠道的证据必须满足“可验证性”Verifiable和“时效性”Timeliness。邮箱→手机号验证SGK查号# 步骤1用邮箱在支付宝登录页点击“忘记密码”观察错误提示 # 若提示“该邮箱未注册支付宝”则跳过若提示“手机号尾号****”则记录尾号 # 步骤2用尾号在“天眼查”或“企查查”搜索企业法人攻击者常用企业邮箱 # 例如邮箱为admincompany.com搜索“company”发现法人张三手机号138****1234 # 步骤3用138****1234在微信搜索若显示“张三已添加”则截图保存 # 注意微信搜索需开启“允许陌生人查看十张照片”否则无法验证支付宝→微博验证转账凭证链# 步骤1用已知手机号登录支付宝进入“账单”→“转账记录” # 查找备注为“webshell费用”、“C2服务器续费”的转账需脱敏处理 # 步骤2复制收款方支付宝账号如138****1234alipay.com在微博搜索框输入 # 若出现微博ID“APT_C2_Admin”且其主页简介写“专注红队基础设施”则截图 # 步骤3用微博ID在GitHub搜索查看其公开仓库README.md # 若包含“c2-server v2.3.1”、“DGA算法time()md5(domain)”等描述则完成闭环逻辑说明单个渠道的证据极易伪造如QQ号可随意注册但跨平台证据链难以同步造假。例如攻击者用zhangsancompany.com注册支付宝用138****1234绑定微信再用同一手机号注册微博这种一致性在真实攻击者中普遍存在而在伪造者中几乎不可能维持。微博→抖音验证内容一致性检验# 步骤1在微博ID“APT_C2_Admin”主页查找其发布的技术文章 # 如《DGA域名预测实战》一文文中提到“使用Python3.9scapy实现DNS劫持” # 步骤2在抖音搜索“APT_C2_Admin”查看其短视频 # 若视频标题为“手把手教你用Scapy伪造DNS响应”且演示代码与微博文章一致则强化可信度 # 步骤3用抖音号在B站搜索查看其投稿视频 # 若存在《Linux跳板机提权指南》视频且评论区有用户提问“如何绕过SELinux”作者回复“用setenforce 0”则完成跨平台一致性验证这种验证不是为了“找到真名”而是构建一个可被第三方复现的证据网络。当报告提交给客户时只需提供各平台截图操作步骤对方即可自行验证无需信任你的结论。3.2 IP地址所属公司的“ASN穿透法”为什么查到“阿里云”还不够必须定位到具体可用区IP归属信息是溯源的基石但手册警告“XX云厂商”级别的归属毫无价值必须穿透到可用区Availability Zone级别。因为同一云厂商的不同可用区物理位置、管理团队、安全策略均不同直接影响溯源方向。ASN穿透步骤# 步骤1用ipip.net查IP的ASN和地理信息 curl -s https://freeapi.ipip.net/203.124.87.156 | jq . # 输出[中国, 北京, 北京市, 阿里云, AS37963] # 步骤2用ASN号查详细路由信息 curl -s https://bgp.he.net/AS37963#_prefixes | grep -A 5 203.124.87.0/24 # 输出203.124.87.0/24 via 203.124.87.1 (203.124.87.1是该子网网关) # 步骤3用网关IP反查物理位置 curl -s https://freeapi.ipip.net/203.124.87.1 | jq . # 输出[中国, 北京, 北京市, 朝阳区酒仙桥路2号, 阿里云, AS37963]参数说明ipip.net的免费API返回国家/省/市/运营商/ASN五级信息bgp.he.net是全球BGP路由数据库203.124.87.0/24表示该IP所在子网网关IP203.124.87.1的地理位置比随机IP更接近物理机房。更进一步可用whois命令查ASN注册信息whois AS37963 | grep -E (OrgName|NetRange|country) # 输出OrgName: Alibaba Cloud Computing Co., Ltd. # NetRange: 203.124.0.0 - 203.127.255.255 # country: CN此时结论不再是“阿里云”而是“阿里云北京朝阳区酒仙桥数据中心”这意味着若该IP用于C2通信应重点检查阿里云北京地域的ECS实例若该IP出现在蜜罐告警中需联系阿里云安全部门而非通用客服若需法律取证司法文书应送达“北京市朝阳区酒仙桥路2号”。3.3 地理位置的“三级定位法”为什么GPS坐标精度到米级反而会误导溯源地理位置不是越精确越好。手册定义“三级定位”标准国家级准确→ 省市级可靠→ 区县级谨慎→ 街道级不可信。因为IP定位依赖基站、WiFi热点、GPS等多源数据街道级精度在移动网络中误差可达500米以上极易将攻击者定位到邻近咖啡馆。验证方法# 步骤1用多个平台交叉验证省级定位 curl -s https://ip.taobao.com/outGetIpInfo?ip203.124.87.156accessKeyxxx | jq .data.country,.data.region curl -s https://api.iplocation.net/?ip203.124.87.156 | jq .country_name,.region # 步骤2用OpenGPS查区县https://www.opengps.cn/Data/IP/ipplus.aspx # 输入IP查看返回的“行政区划代码”如110105北京市朝阳区 # 步骤3用百度地图API验证需AK curl -s https://api.map.baidu.com/location/ip?akxxxip203.124.87.156coorbd09ll | jq .content.address_detail # 输出{province:北京市,city:北京市,district:朝阳区,street:,street_number:}避坑提示若百度地图返回street字段如“酒仙桥路2号”需立即验证——用该地址在高德地图搜索查看其经纬度是否与百度一致。若偏差100米则street字段不可信仅保留province/city/district三级。真正有价值的地理信息是与攻击行为的时间关联性。例如IP203.124.87.156在北京时间02:00-04:00高频扫描而其定位为“美国加州”则说明攻击者可能在利用时差进行自动化攻击若定位为“中国北京”但扫描时间集中在09:00-17:00工作时段则更可能是人工操作。这种时空模式比GPS坐标更能刻画攻击者画像。3.4 其他社交账号信息的“ID一致性检验”为什么微博ID和GitHub用户名必须字符完全一致社交账号ID是攻击者最易暴露的“数字指纹”。手册规定所有平台ID必须满足“字符级一致性”即大小写、下划线、数字位置完全相同。因为攻击者为方便记忆常在多平台使用同一ID而伪造者难以保持细节统一。一致性检验脚本# check_id_consistency.py import re import requests def normalize_id(id_str): 标准化ID转小写去除非字母数字字符 return re.sub(r[^a-zA-Z0-9], , id_str).lower() def check_platforms(target_id): platforms { weibo: fhttps://weibo.com/{target_id}, github: fhttps://github.com/{target_id}, twitter: fhttps://twitter.com/{target_id}, linkedin: fhttps://linkedin.com/in/{target_id} } results {} for platform, url in platforms.items(): try: r requests.head(url, timeout5) # 200表示存在302表示重定向可能被封404表示不存在 results[platform] exists if r.status_code in [200, 302] else not found except: results[platform] timeout # 标准化目标ID norm_target normalize_id(target_id) # 检查各平台是否存在且ID一致 consistent_count 0 for platform, status in results.items(): if status exists: # 实际验证页面标题是否含目标ID try: r requests.get(fhttps://api.github.com/users/{target_id}, timeout5) if r.status_code 200 and r.json().get(login) target_id: consistent_count 1 except: pass return results, consistent_count # 示例检查ID APT_C2_Admin results, count check_platforms(APT_C2_Admin) print(f平台存在性: {results}) print(f一致性得分: {count}/4)逻辑说明normalize_id()函数去除所有非字母数字字符并转小写确保APT_C2_Admin和aptc2admin视为同一IDrequests.head()快速探测页面是否存在requests.get()获取GitHub API详情验证login字段是否严格等于输入ID区分大小写。当consistent_count 3时该ID可信度极高。例如APT_C2_Admin在GitHub、微博、Twitter均存在且GitHub的login字段确为APT_C2_Admin则可认定为攻击者真实ID后续可追踪其GitHub仓库的commit记录、issue讨论获取更多C2配置信息。4. 溯源过程中的五大致命避坑指南那些让你加班到凌晨却一无所获的玄学陷阱4.1 现象威胁情报平台显示IP为“高危”但实际是CDN节点封禁后业务大面积中断原因未验证CDN状态盲目信任平台标签。微步、360等平台对Cloudflare、Akamai等CDN的ASN标记常为“恶意”因其被攻击者广泛滥用但CDN本身是中立服务。解决执行curl -I https://target.com 21 | grep cf-ray\|x-amz-cf-id若返回cf-ray: xxxxx或x-amz-cf-id则确认为Cloudflare/AWS CloudFront立即停止封禁改为在WAF规则中阻断特定User-Agent或URI路径。4.2 现象恶意文件静态分析发现CreateThread但动态调试时进程无网络连接原因文件被加壳且启用了反调试CreateThread调用被虚拟化或延迟执行。PEiD显示“ASPack 2.12”但strings未提取出URL说明壳体加密了导入表。解决用Detect-It-EasyDIE工具二次查壳若确认ASPack用UniversalExtractor解包解包后重新strings若仍无URL则用x64dbg加载在kernel32.CreateThread下断点运行后观察RSP栈顶参数手动解析线程函数地址。4.3 现象日志中Accepted password for root与systemctl start sshd时间戳相同但溯源报告被质疑“时间巧合”原因未验证系统时间同步状态。攻击者常篡改系统时间以混淆日志date命令显示2023-09-13 18:10:43但ntpq -p显示NTP服务器偏移127.345 sec说明时间不准。解决用journalctl --since 2023-09-13 18:00:00 --until 2023-09-13 18:15:00 | grep -E (sshd|systemd)查看systemd日志其时间戳由内核提供不受date命令影响可作为真实时间基准。4.4 现象用netstat -tulnp查到监听端口但lsof -i :[port]返回空/proc/[pid]/exe指向/dev/null原因进程已退出但端口处于TIME_WAIT状态netstat显示的是连接残留而非活跃进程。ss -tuln比netstat更准确因它直接读取内核socket表。解决执行ss -tuln | grep :[port]若无输出则确认端口已释放若有输出用ss -tulpn | grep :[port]查看PID再ls -l /proc/[pid]/exe验证路径真实性符号链接是否指向/dev/null。4.5 现象跳板机上crontab -l为空但/var/log/syslog显示每5分钟执行/tmp/.cache/update.sh原因攻击者使用anacron或systemd timer绕过crontab/etc/anacrontab或/etc/systemd/system/下存在隐藏定时任务。解决检查/etc/anacrontab搜索update.sh检查systemctl list-timers --all筛选next列非n/a的服务用find /etc/systemd/system/ -name *.timer -exec systemctl cat {} \; 2/dev/null | grep -A5 update.sh定位定时器单元文件。5. 应急响应系统设计的核心落地技巧用PythonSQLite构建轻量级溯源证据链管理器5.1 为什么不用Elasticsearch而选SQLite——从HW行动的真实负载说起在2023年某次HW行动中我们部署了基于Elasticsearch的溯源证据库结果在单日处理300告警时ES集群内存飙升至95%Kibana响应延迟超10秒。复盘发现溯源场景不需要全文检索的复杂度而需要事务一致性、离线可用性和低资源占用。SQLite单文件数据库10MB内存即可支撑万级证据条目且支持ACID事务——当你在INSERT INTO evidence时被电话打断ROLLBACK能保证数据不脏。数据库Schema设计-- evidence.db CREATE TABLE IF NOT EXISTS ip_info ( id INTEGER PRIMARY KEY AUTOINCREMENT, ip TEXT UNIQUE NOT NULL, asn TEXT, country TEXT, province TEXT, city TEXT, isp TEXT, last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS domain_info ( id INTEGER PRIMARY KEY AUTOINCREMENT, domain TEXT UNIQUE NOT NULL, a_record TEXT, cname TEXT, ssl_cert_hash TEXT, last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS file_hash ( id INTEGER PRIMARY KEY AUTOINCREMENT, md5 TEXT UNIQUE NOT NULL, sha1 TEXT, sha256 TEXT, file_name TEXT, file_size INTEGER, first_seen TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS evidence_link ( id INTEGER PRIMARY KEY AUTOINCREMENT, ip_id INTEGER, domain_id INTEGER, file_hash_id INTEGER, relation_type TEXT CHECK(relation_type IN (c2_communication, hosting, download_source)), confidence REAL CHECK(confidence BETWEEN 0 AND 1), FOREIGN KEY(ip_id) REFERENCES ip_info(id), FOREIGN KEY(domain_id) REFERENCES domain_info(id), FOREIGN KEY(file_hash_id) REFERENCES file_hash(id) );本文还有配套的精品资源点击获取