Picking up from where we left off, now that we have a proper understanding of HOW all the tools threat actors used to compromise Confluence data servers, letβs dive into the official case study of how it all went down. If youβre behind on my coverage of the DFIR report, check out the first part here! HOWEVER, if by some sheer luck he does finally speak out regarding the situation with CONCRETE evidence, I'll happily retract everything in this article. I doubt it, BUT, let's move on!
π Article π Glossary π Catalog π Home π Search ModePicking up from where we left off, now that we have a proper understanding of HOW all the tools threat actors used to compromise Confluence data servers, letβs dive into the official case study of how it all went down. If youβre behind on my coverage of the DFIR report, check out the first part here!
I'll be discussing the following topics in order: π The Attack Tree π The CVE-2023-22527 Exploit π Establishing a CLEAN shell π Access GRANTED π Take Over 5 π Rcloneβs Turn π The LockBit Exploit You can click on any of the topics to simply check that one out if it interests you! NOTE: Articles are read from LEFT to RIGHT via 2 columns! Read the first column all the way down and then move to the next one!
Here's a quick run down on all the main links that are in the article in case you want to check them out first. π LinkedIn Version π Part 1
In order to give you a more visual perspective of whatβs going on, reference this model here, and as I discuss each section of the initial access to the system, reference it to the best of your ability here. If you have any further questions the best way to reach me is via my discord server.
After threat actors were able to successfully compromise Confluence data servers via OGNL injection and establish RCE to the data servers, they tried the most common initial commands to check if the had access to the server, stuff like: whoami(tells you the user name on the system), net(which shows file share servers mapped to the system on the network), etc.
Iβve mentioned this before in one of my past research articles, but one of the most common things threat actors like to do once they gain access to the system is setup a clean shell.
As security professionals, one of our main concerns is to deter this. You see, you wonβt ALWAYS prevent threat actors from gaining access, BUT, when or should they do, you want to render their access as infeasible as possible. Essentially, make their access useless.
Threat actors initially tried the classic old curl command to βwgetβ anydesk and run it on the system which initially failed, so they decided to use a windows binary program called βmshtaβ which is another means to retrieve the correct stagger they needed via metasploit in order to establish a CLEAN shell to the data server.
Within the first 10 mins of compromising Confluence data servers, threat actors did and initial check of any and all processes running on the system.
Why? For starters: to check if there are any important processes on the system that could allow them to deal more damage to the system, to check if there are any security processes running on the system, and lastly, to check if anyone else has access to said system and boot them.
Itβs been assessed that prior access from other threat actors might have existed on the server, so threat actors decided to pull the plug on them to maintain clean access for themselves without any further disturbance.
Once everything was checked, they killed their own shell (in the process of said checks), connecting back to the system in order to create administrative accounts on the system, elevating their privileges.
A clever thing the threat actors did next, very fascinating, was they used the local account in order to RDP into admin areas of access, even going as far as to take advantage of the trusted system on the network theyβve compromised, leveraging SoftPerfects network scanner, using it against them.
In simpler terms, they used their own security scanners against them to find all targets on the network, a trusted tool whose probes wonβt be blocked on the network. This is what we would call Living off the land, where threat actors bypass detection systems by using ONLY what is trusted by the network itself.
How do you defend against this? Well, itβs quite simple. Not every system should be trusted to do certain things. If you detect a system that has no need to run said scans, block the probes!
How did they get the credentials to do this in case they might have needed it? Remember Mimikatz? Yeah, they used it in order to scope out and enumerate all needed credentials, allowing them to do anything they want with administrative privileges!
Next, threat actors leveraged data backups by enumerating Veeam credentials via a powershell script, which allowed them to excavate all files from the server via Rclone, a tool designed to clone and transfer all files from a file system remotely.
Essentially they created their own File sharing server, and then cloned the files there using Rclone.Once threat actors fully cloned all the files from the server, the next thing they did was deploy the ransomware. They did this using LockBit against them, a FDE encryption at rest algorithm that encrypts all files on the system upon shutdown, preventing threat actors from utilizing said data.
They did this in a clever way by leveraging PDQ, a deployment software system, in order to fully deploy the ransomware script via SMB file shares. That way whenever anyone accessed the SMB file share servers, they wouldnβt suspect a thing, executing the ransomware exploit!
In total time the exploit took about 2 hours to complete!
Thanks for reading folks!
If you enjoyed this post give it a thumbs up! Iβll be keeping track of whose reacting from now on as there is a βspecialβ reason for it. Just know the more you support my content the more there is in stored!
- The Hacker Who Laughs πΈπΈππΈπΈ