.png){kind=avatar}
We have learned a lot from this attack and identified a serious security flaw within Atlassian products. Check it here
GMT 4.30 PM Dec 6th.
We are investigating a targeted cyber attack on CloudSEK. An employee’s Jira password was compromised to get access to our confluence pages. Additionally, the attacker has some internal details like screenshots, bug reports, names of customers and schema Diagrams.
No database or server access was compromised. We are investigating the details, and more information will be shared with you when we uncover them. Thank you for your trust. We always believed in transparency. Hence we are starting a blog to update you with live information as we investigate the details.
GMT 6.15 PM Dec 6th.
We suspect a notorious Cyber Security company that is into Dark web monitoring behind the attack. The attack and the indicators connect back to an attacker with a notorious history of using similar tactics we have observed in the past.
A threat actor, ‘sedut’, recently joined multiple cybercrime forums on 5th and 6th December – claiming to have access to CloudSEK networks, which allegedly led to the compromise of XVigil, Codebase, Email, JIRA and social media accounts. The attacker has zero reputation on Darkweb and created the dark web market account specifically to post CloudSEK-related information.
No ransom was demanded from CloudSEK, nor were there any signs of a typical cybercrime group.
GMT 7.54 PM Dec 6th.
Here are the claims of the actor and the comments against each claim from CloudSEK based on the investigations we have done so far.
| Incident Name | Threat Actor Claim Summary | CloudSEK comment |
|---|---|---|
| Access to Confluence and Jira | The threat actor claimed to have access to Jira. | This is correct and validated. |
| Access to PO of customers | The threat actor claimed to have access to customer purchase orders. | Certain PO information that was available on Jira was accessed. |
| Access to the Twitter account | The actor claimed to have access to social media (Twitter). | CloudSEK main social media accounts were not breached. Instead, a social media account we used to perform takedown action was compromised. A few of our clients were tagged via tweets. A few media personals were tagged via tweet. The attacker’s intention was not to exfiltrate data but rather create brand/reputation damage. CloudSEK main Twitter account- https://twitter.com/cloudsek Compromised Twitter account –https://twitter.com/CloudsekXvigil |
| VPN Access to Xvigil and Bevigil | The threat actor claims to have access to our VPN. | No access to VPN – Screenshots taken from Jira/Confluence training pages. |
| Access to Database | The threat actor claims to have access to our database. | No access to Database. Screenshots taken from Jira/Confluence training pages |
| Access to ElasticSearch | The threat actor claims to have access to our elastic search database. | No access to Database – Screenshots taken from jira/confluence training pages |
Access to Code Base
|
The threat actor claims to have access to the source code. | No suspicious activity was found. |
| Access to XVigil | The threat actor claims that he can also “add clients.” | No access to the platform – Screenshots taken from Jira/confluence training pages |
| Access to Project X | Threat actor claims to have access to ProjectX | No access to the platform – Video/Screenshots taken from Jira/confluence training pages |
| Client data from XVigi | The threat actor shared 2 excel files in an archive that are from XVigil- | The files were attached to Jira tickets. These are subdomains auto-discovered by CloudSEK. This information is public. The actor must have used it as sample information to generate fear. |
| Client Data from Xvigil. | The threat actor shared 2 excel files in an archive. | The files were attached to Jira tickets. This information is public. The actor must have used it as sample information to generate fear. |
GMT 2.06 AM Dec 7th.
- We have confirmed that a Jira user account was compromised.
- We also know that the Jira user never used a password (only used SSO), and his email was behind an MFA.
- Hence no Jira password was compromised, nor was any compromise of the user email account.
- We suspect that the session cookies of the Jira user were compromised, which led to an account takeover.
- We are investigating how the attackers got the session cookies to that particular Jira user.
GMT 2.29 AM Dec 7th
What sort of customer data was leaked?
- Customer Names, Customer PO for 3 companies.
- Multiple screenshots of the product dashboards.
What is not compromised?
- No access to customer data.
- No access to customer login information.
- No credentials used on the portal are compromised.
GMT 9.00 AM
Investigation of Unauthorized Access to CloudSEK JIRA Account
21 Nov 2022: An employee faced laptop performance issues.
22 Nov 2022: CloudSEK engaged a third-party vendor (Axiom) to check the issue. The vendor took the laptop out of CloudSEK premises for servicing. The laptop was returned with a new copy of Windows and a stealer log malware (Vidar Stealer ) installed. CloudSEK admin handed the laptop to the employee.
24 Nov 2022: The stealer log malware uploaded the passwords / cookies on the employee’s machine to a darkweb marketplace. The attacker purchased the logs the same day. The attacker was unable to use the other passwords due to MFA. Hence he used the session cookies to restore jira sessions.
GMT 9.15 AM
FAQs
How did the leaked JIRA credentials impact CloudSEK?
The leaked Jira credentials gave the threat actor access to
- Training and internal documents.
- VPN and Endpoint IP address which are accessible with VPN configuration.
- Confluence pages where the threat actor used the search term ‘password’ to search for sensitive data.
All the screenshots and purported accesses shared by the threat actor can be traced back to JIRA Tickets and internal confluence pages. Even the screenshots of Elastic DB, mySQL database schema, and XVigil/PX are from training documents stored on JIRA or Confluence.
What sort of customer data was leaked?
- Names and purchase orders (POs) of 3 customers.
- Multiple screenshots of the product dashboards.
What was not affected?
Contrary to the threat actor’s claims:
- No VPN credentials were leaked.
- No access to customer data.
- No access to customer login information.
- No credentials used on the portal are compromised.
CloudSEK doesn’t store critical information about their customers. CloudSEK is a SaaS company whose products leverage public data to provide external threat intelligence in the form of initial access vectors and TTPs. No data from this breach can be used to launch supply chain attacks on customers.
What is the change in the process after the incident?
The following process changes were made as well as improved security controls. We are Sharing the security controls we had before and our improved security controls.
- Green – Improved Security Control.
- Red – Previous Security Control.
- Black – No changes in the process
| Security Controls/Processes before the incident | Improvised Controls/Processes post the incident. |
| Serviced machines are handed over to employees. | All on-boarded new and serviced machines are to be quarantined for Maliciousness and Sanity Check for 1 week.
Updated Process to ensure EDR systems are active during the quarantined time period. |
| Sharing of Passwords on Jira, Slack, Confluence | No sharing of passwords on Jira, Slack, or Confluence.
Implement a tool to monitor public workspaces for credentials and notify the security team. |
| Employees can access multiple internal documents on JIRA/Confluence/Slack channels etc. | Limit scope and authorization by revoking permission from JIRA/Confluence. (Need to Know Basis)
Authorization and Permission on Slack Channel based on Employee Profile and Role. |
| Fleet/Inventory management using word processing tools. | Fleet/Inventory management using Fleet DM. |
| Device Security Revamp – Employee Device Security (Physical Devices used by employees including Laptop, Desktop, Routers and more) | Device Security Revamp – Employee Device Security (Physical Devices used by employees including Laptop, Desktop, Routers and more)
Encryption of Disks List of Standard tools and software for all the machines. Monitoring Telemetry in near real-time using SentinelOne EDR FleetDM Fleet DM Rules – Automated Compliance Telemetry, Implementation and Check. Fleet DM – Automated Patch management for all the employee devices. |
| CloudSEK security products are deployed for internal security. Shared resources to monitor CloudSEK tools and other security tools. | CloudSEK security products are deployed for internal security. Dedicated resources to monitor CloudSEK tools and other security tools. |
| High-profile account monitoring. | Identify and list High-Risk accounts and set up regular monitoring. |
| Periodic Operating System Update | Periodic Operating System Update |
| Fire drill exercises periodically to test BCP and Resilience | Fire drill exercises periodically to test BCP and Resilience. |
| Periodic Pentesting, Red Teaming exercises, Phishing simulation, and Bug Bounties. | Periodic Pentesting, Red Teaming exercises, Phishing simulation and Bug Bounties. |
| Employee Onboarding & Exit Policies | Employee Onboarding & Exit Policies |
| Vendor Background checks. | Vendor Background checks. |
| Strict and Automated checking of 2FA/MFA implementation | Strict and Automated checking of 2FA/MFA implementation |
| Playbook for different types of Security Incidents | Playbook for different types of Security Incidents |
| Business Continuity Plan | A business Continuity Plan already exists. |
We have learned a lot from this attack and identified a serious security flaw within Atlassian products. Check it here