Futaba _ Webs πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

Confluence LockBit Ransomware (Pt 2) πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

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 Mode

πŸŽƒ Article Glossary

πŸ•Έ Synopsis πŸ•Έ

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!

πŸ•Έ Article Topics πŸ•Έ

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!

πŸ•Έ Key Links πŸ•Έ

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

πŸŽƒ Confluence LockBit Ransomware (Part 2)

The Attack Tree πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

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.


portfolio img

The CVE-2023-22527 Exploit πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

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.


Establishing a CLEAN shell πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

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.


Access GRANTED πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

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.




Take Over 5 πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

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!


Rclone’s Turn πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

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.


The LockBit Exploit πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

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 πŸ•ΈπŸ•ΈπŸŽƒπŸ•ΈπŸ•Έ

portfolio img

πŸŽƒ CONTACT ME

AnOnYmOuS

futaba.webs@gmail.com

New York, NY United States