Webinar Replay: Lessons Learned from 50+ MOVEit IR Investigations
October 25, 2023 | (Online Event)
A deep dive into the MOVEit exploitation and incident response, from reconnaissance to exfiltration and its impact on third parties, with lessons learned from the frontline.
The creation of a MOVEit account—was it consistent with all MOVEit cases investigated?
It was an automated attack, and the threat actors leveraged an automated script. This was consistent with how they were creating the account; hence, the big impact. As they leveraged an automated attack, they could take broadly from a lot of victims. We also noticed the attack was carried out extremely fast from beginning to end and the data exfiltration rate in this case was 100%. We did not find a client that was able to not have their data exfiltrated.
In your experience, were organizations able to prevent exfiltration by using security features in the MOVEit software, like IP whitelisting or the "immediate transfer off server" feature?
Organizations were not able to prevent data exfiltration. They were only able to catch it early and then mitigate the threat.
Did you have visibility into the directory structures that were exfiltrated, as in, was it a 1:1 clone of how the data was stored within MOVEit, or was it all lumped together into a single archive?
When the threat actors used the second method for data exfiltration a lot of times, they would take that data, compress it on the MOVEit server and then send it out. For the data exfiltration, the open session was fire and forget; they literally pointed at the directories and said, "Go.” The MOVEit server itself handle that data exfiltration, and it became a one-to-one broadly across the 95 percentile exfilteration method. It was a one-to-one replication from the MOVEit server up to CLOP’s cloud storage.
So what we saw was when the threat actors use the second method, a lot of times that they would actually take that data, compress it on the MOVEit server and then send it out. For the data exfiltration, the open session, really it was a fire and forget, they literally pointed at the directories and said, "Go." And just let the MOVEit server itself handle that data exfiltration. And so it really became a one-to-one across broadly across that 95 percentile, we just saw it was a one-to-one replication from the MOVEit server up to Clops cloud storage.
Was the data on the MOVEit server typically "to be transferred" or "already transferred"? Is one lesson that data "already transferred" or "already received" be removed from the MOVEit server?
That is one of the key takeaways; data that has been transmitted or transferred or up for a duration of time should be removed from the data server. Proper data pruning is something that can reduce that risk.
During investigations when we analyzed the database, we could see which data had been transferred. We did not necessarily investigate which data had been transferred and which data was stored, the goal was to identify data at risk. I can say that some of the data that we saw in the service did go back for quite some time and probably would have expired out of a portal if there were some policies in place.
How could EDR have prevented this?
Endpoint detection response (EDR) is not going to prevent a zero day where threat actors leverage the infrastructure in place to execute an attack. However, EDR is quite good at catching and identifying that activity early. Organizations that had EDR or Managed Detection Response (MDR) were able to identify that suspicious activity and then were able to transfer and cut off that activity.
One of the activities that we saw them catch was the web shell. When a web shell drops and is called, that web shell is compiled into a binary DLL (Dynamic Link Libraries) on that server and that is executed from there. So, EDR tools were able to catch the execution of that DLL as an executable.
Would encryption at rest and using private key to decrypt minimize the impact?
MOVEit is an application that is approved for government use and uses encrypted data at rest. So, the files that are on the MOVEit server are encrypted and have a private key that is stored in the MOVEit database to decrypt that data.
In the MOVEit server, when there is a session and someone logs in and says, "Transfer me this file." The file is taken, the MOVEit application decrypts that file, and it sends the user the decrypted file. The threat actors had to know the API calls to be able to do that manually, but they discovered that by letting the MOVEit application do all the decryption for them, they could get that data out quicker. If there was some other layer of encryption, it would help in minimizing the impact.
E.g., If you took a file, wrapped it in your private key, stored it on the MOVEit server where it was encrypted with the MOVEit server's key and transferred that data, then yes, the client would get it in its encrypted state. However, you would have to transfer the key to the client to be able to decrypt that data. However, that's above and beyond what you would consider normal or expected.
How did MDR play a role with the customers that had it vs. the customers that did not?
Customers that had EDR/MDR were able to identify and react quicker than the teams that did not. This attack happened over Memorial Day weekend, so you have a lot of teams that are disengaged, a lot of teams that are spending time with family or a lot of teams that have a skeleton crew.
Even though the team is away, the employees that had MDR and a 24-hour monitoring Security Operation Center (SOC) that would respond to alerts were the ones that they were able to identify it, react, be able to quarantine and isolate that server and take that server down, however, they chose to respond. So, even though CLOP got all the way through to mission execution and started exfiltrating data, teams with MDR/EDR saw a lot less data leave their environment than the teams that didn't have MDR/EDR in place.
How did you see evidence of target enumeration between July 2021 and June 2023?
The MOVEit application has two components: one is a backend database component, and the other is a frontend web server; those are the two pieces that we were able to pull at Kroll. When we do MOVEit analysis, we would grab the server or grab a backup of the database and then grab the actual frontend web server.
By April 2022, what we saw was threat actors calling guest access .aspx and passing in a very specific variable that was very consistent with the CLOP gang. The actual exploit is a chain of six calls that gets them what they want, and by April 2022, we saw the threat actors calling the first couple of calls and then getting, returning the organization ID.
From April 2022, all the way up until the MOVEit attack, up into a week or two before the attack, we see them using the same technique. They were likely testing and developing their automation scripts for making it all work and then really on the 27th was when we saw them gain access, and then leverage that access across the board. That's really when we saw them using it broadly.