At FDCA we have always strived to be transparent with everything we do, including taking our own medicine when it comes to releasing this post. On November 5th 2023, the Confluence server used for internal documentation at FDCA was unfortunately impacted by C3RB3R Ransomware. During the analysis of this incident, we were able to put into action everything that we have learned from being part of FDCA, including utilizing tools and processes picked up during our SagaLabs events and various other training opportunities. We decided to release our analysis, investigation and response in an effort to help ourselves and others learn from this case. To also show that the old adage is true “it isn’t a case of if, but when” in relation to whether an organisation has been hit by a cyber-attack.
On November 5, 2023, confluence.fdca.dk fell victim to the C3RB3R ransomware variant. Evidence of data exfiltration from the Confluence server remains elusive, however more sufficient logging is needed to ensure conclusive confirmation. The threat actors leveraged open-source exploits sourced from GitHub. Attribution of the threat actors remains elusive, yet according to multiple threat intelligence reports, we appear to be victims of an automated exploit campaign specifically targeting CVE-2023-22518. Fortunately, all systems and data were successfully restored, underscoring the efficacy of our robust data backup procedures.
Not gonna lie, this incident was very fun for members of FDCA to work on, as we are very eager to learn and experience incidents like this.
On the 14th of November, FDCA’s board members noticed strange behavior on the confluence server that was responsible for hosting our internal documentation.
Immediately our system administrator started investigating the incident and quickly observed that the system had been tampered with.
As shown in the image, most of the files are showing the
.L0CK3D extension, which is an indication of ransomware. When trying to access the files, it was confirmed that the files were encrypted. When looking into the impact of the cyber attack, all files in the Confluence directory were impacted.
As depicted in the image above, a
read-me3.txt file was deposited in the affected folders. We promptly isolated the system and obtained a disk image of the impacted server. Given that high availability is not a primary concern for this system, our investigators had the opportunity to meticulously scrutinize the system, focusing on acquiring logs such as access, audit, and Nginx logs. These logs were then ingested into our Elastic instance for in-depth analysis.
The next step involved searching for indications of persistence on the system and implementing mitigative measures. However, no evidence of persistence was identified.
When visiting the .onion site, we were presented with the screen above.
When looking at nginx, there were multiple requests made against the server coming from 193[.]176.179.41, which is present in C3RB3R Ransomware report from SentinelOne.
Looking to an earlier timestamp in the logs, it showed signs of external scanning for the vulnerability:
On 13:24:10 the same day, we can see that 202[.]64.1.232 did a GET-request against the Confluence API, specifically calling /server-info.action with the user-agent referring to CVE-2023-22515: Confluence Broken Access Control Exploit.
From the source code on this Github repo, we were able to confirm it was this CVE.
Further examinination of the source code, showed a highly likely next step that the threat actor would alter the
bootstrapStatusProvider.applicationConfig.setupComplete class to false. This modification causes Confluence to behave as if it has not been configured, thereby allowing the threat actor to create a new confluence account with elevated privileges.
We then focused on trying to identify this in the logs, and could confirm that it was done several hours later from 51[.]195.224.90.
We were unable to gain visibility into the contents of the POST request. However, it appears that the actor obtained initial access to the Confluence platform by establishing a new administrative account. Through analysis of various events, it became evident that the threat actor leveraged the new account to upload a Confluence plugin titled
web.shell.Plugin-key. Subsequently, this plugin was promptly deleted post initial access. According to open-source threat intelligence, this plugin appears to function as a straightforward web shell utilized for action on objectives.
Additionally, we suspect multiple threat actors may have compromised the system, as the timeframes and Command and Control (C2) IP addresses do not align. Our leading suspicion points to a ransomware actor potentially originating from the IP address 193[.]176.179.41, with the incident occurring on November 5, 2023, at 13:45, which also ties together with the ransomware note being written to disk at 13:47.
Fortunately, we possessed an external backup of our infrastructure, facilitating a seamless recovery process for both the servers and the data they housed. Since we able to identify the CVE being used, patching the Confluence server was straightforward too.
Since the Confluence server primarily served internal documentation purposes and was not highly active, no data loss occurred, and we were able to recover within a short time.
We promptly decided to notify Datatilsynet about the incident, as regulations mandate reporting within 72 hours of detecting the compromise. Upon assessing the extent of the impact, we identified the individuals whose data was stored on the Confluence server and notified them accordingly.
- https://isc.sans.edu/diary/Sporadic+scans+for+serverinfoaction+possibly+looking+for+Confluence +Server+and+Data+Center+Vulnerability+CVE202322515/30342
[Indicator of Compromise (IoC)]