We discovered an issue on October 24th (the Diwali Public Holiday in Singapore) when our Ransomware and Malware management system reported that the “White Rabbit” malware software dropper had been activated inside our Singapore network and was actively being blocked and immediately killed and removed on a number of servers inside our network.
No Australian infrastructure was impacted at any time.
The servers were not compromised by the attempt, but we immediately identified the trusted SAP Partner account that was the source of the attack, and it was disabled.
We then shut down the network and commenced our forensic investigation utilising all the tools at our disposal, and we were able to determine the source of the ransomware attack.
We also forced a password change on all partner accounts and customer accounts and replaced all administration accounts on our servers however this was done as a proactive step.
We were able to restore the service on our network after a period of 4 hours once we were sure that there had been no lateral movement, threat, or permission elevation on any accounts other than the initial account, which was deleted and the data exfiltration path had been terminated and blocked.
We then forced all partners to activate our 2-factor authentication as some were still providing reasons why they could not do it. We introduced a no-exceptions Zero Trust policy across our entire organisation, including blocking all outbound traffic, excluding HTTPS, DNS and SMTP traffic.
All customers of those partners had already had 2-factor authentication enforced previously, as the expectation was that IT partners would be more security aware and “prepared” than customers so we allowed the partner requested exceptions and tolerated the lack of compliance on the basis they would become compliant within a short period of time.
This has proven not to be the case, unfortunately.
Inbound traffic was already protected via our next-generation firewall, which reported no inbound intrusions or threats and continued to perform as expected. Our internal defences monitoring held firm, and no data was modified, encrypted and no other accounts showed any signs of modification in the 90 days prior that was the scope of our forensic investigations.
All data backups were not impacted and have since gone through a complete refresh cycle, and the level of encryption on all backups has been upgraded as well.
During the ongoing investigation, we studied all the traffic entering and exiting our network and identified a pattern of data being sent from an SAP Partner authenticated session via SSH to a server that appeared to be in Israel, but the IP address was registered as being an ISP in the Netherlands in the days prior to the ransomware attack.
It should be noted that it is not uncommon for our partners to retrieve data from our servers and transfer that data to their own servers or to partner servers via SSH/FTP – we have now actively blocked that traffic to all unknown /non-whitelisted endpoints. We did not treat this outbound traffic as unusual, as it was being executed with a valid and authenticated partner account.
There was no evidence of any accounts on the network triggering or attempting malicious activity other than the identified accounts, which belonged to a partner whose employees had left the organisation, but we were not notified. As well as malicious activity from another partner account where we determined during our investigations that the consultant’s laptop had also been compromised and was not protected with anything other than Windows Defender.
No SMB Solutions accounts or partner accounts were compromised during the incident other than the originally compromised accounts that originated from malware attacks on the partners infrastructure.
The Legal Side of the Ransomware Attack
As an Australian legal entity, we have also been in touch with the Australian Signals Directorate and the Australia Office of the Information Commissioner and ensured that all our legal reporting obligations have been met and have communicated with all our Singaporean and Malaysian partners to ensure they have been made aware of the breach, the circumstances of the breach and we have provided recommendations on how they should respond and interact with local agencies. However, as they are independent organisations, we have no ability to enforce any actions on their behalf, and we are not authorised to contact their customers directly.
All detailed information regarding the breach, malware, ransomware attack vectors and subsequent extortion attempts has been shared with the ASD/Department of Defence however, their approach has been that as the breach occurred in the Singaporean data centre and did not impact Australian entities, then they have no concerns other than performing a best practices advisory role.
Even though this in no way impacted our Australian data centre, we have undertaken the same forensic investigation and found no evidence of any data breaches, password breaches, unauthorized access or data exfiltration.
We have identified a number of medium-risk practices with the sharing of data when requested by partners and have added additional security steps on our side, including stronger data encryption practices to make sure that all data is protected up to the time it leaves our control and passes into the hands of the external partners and or customers.
This may generate a bit of extra work and time in fulfilling these requests but in the context of our current world and the cybersecurity environment it is worth while doing.
Should you or your customers have any concerns regarding this or any other matter, please email us via firstname.lastname@example.org, and our team will respond to your questions.