When intrusions near completion, adversaries commonly exfiltrate any data they can put their hands on. Among the many exfiltration techniques, MEGAsync has been a widely employed web service given its end-to-end encryption and associated privacy reputation.
Performing forensics on MEGAsync and associated artefacts can provide valuable insights into an intrusion such as identifying which data has been exfiltrated. In this blog post, we’ll cover how MEGAsync forensics can be leveraged to identify exfiltrated files, additional victims and, subsequently, perform attribution.
The absence of evidence is not evidence of absence
As part of a June incident response, the forensic analysis of MEGAsync logs did not yield the expected exfiltration evidence. Naturally this raised the question on whether logs were incomplete (rotated, truncated, …) or whether the eradication of the adversary occurred just-in-time prior to MEGAsync exfiltration. To support this negative claim, we decided to analyze the MEGAsync Statecache, an action which inadvertently allowed us to identify additional victims and, subsequently, attribute the intrusion.
MEGA’s Statecache database
Software interacting with MEGA (e.g., MEGAsync) can rely on MEGA-published libraries (SDK, Software Development Kit) to implement core functionalities such as the synchronizing of files. To ensure the state of the files remain coherent, MEGA’s SDK employs a SQLite database titled Statecache.
On Windows, the MEGAsync Statecache can be found at the following location where {version} represents the MEGA SDK version (currently 14) and {name} the pseudo-random database name.
%LocalAppData%\Mega Limited\MEGAsync\megaclient_statecache{version}_{name}.db
Within the Statecache database, the nodes table contains information on each file and folder (a.k.a. node) synchronized by MEGA. For each node, the entry references their respective parent (i.e., folder), the node’s name, their size, the associated creation and modification time as well as other information such as flags, tags and description.
As an example, the following sample Statecache outlines the favourite.txt node to be a child of the NVISO node.
Noteworthy is that the MEGA Statecache’s nodes table contains a mimetype column which employs the nonstandard getmimetype SQLite function. As such, this column is known to crash common SQLite viewers if included in the result.
Node Types
By default, the Statecache nodes table contains 3 top-level entries whose names seem uncommon (i.e., CRYPTO_ERROR) and type appear unique. As defined in the MEGA SDK, these are the vault, root and rubbish top-level nodes.
// node types:
typedef enum {
TYPE_NESTED_MOUNT = -5,
TYPE_SYMLINK = -4,
TYPE_DONOTSYNC = -3,
TYPE_SPECIAL = -2, // but not include SYMLINK
TYPE_UNKNOWN = -1,
FILENODE = 0, // FILE - regular file nodes
FOLDERNODE, // FOLDER - regular folder nodes
ROOTNODE, // ROOT - the cloud drive root node
VAULTNODE, // VAULT - vault, for "My backups" and other special folders
RUBBISHNODE, // RUBBISH - rubbish bin
} nodetype_t;
Using the above node types, we can state that the favourite.txt file is a child of the NVISO folder and that this folder is located within the top-level root node. As seen in figure 1, the rubbish.txt file on the other hand is located within the top-level rubbish node.
Tooling
Based on this information, we have assembled mega-statecache.py; Enabling forensic examiners to perform a directory listing of MEGA’s Statecache.
Results
Inspecting the Statecache recovered throughout the investigation corroborated the logs; No organization data had yet been exfiltrated through MEGAsync.
As incident responders certainly know, it is not uncommon for threat actors to reuse techniques and infrastructure. MEGA being a cloud service, the Statecache not only provides evidence on locally-synced files, but also on remotely available files (i.e. downloadable). As such, the Statecache-analysis uncovered that the attacker’s MEGA account additionally contained data from previous and ongoing exfiltration campaigns. Correlating these additional victims with public information permitted the attribution of the intrusion to a LockBit affiliate, as can be observed in the figures below.
While there is no doubt law enforcement recently disrupted LockBit through the Operation Cronos efforts, evidence obtained through the Statecache-analysis highlighted that LockBit affiliates remain active and continue to employ legitimate services for exfiltration.
Maxime Thiebaut
Maxime Thiebaut is a GCFA-certified Incident Response & Digital Forensics Analyst within NVISO CSIRT. He spends most of his time performing defensive research and responding to incidents. Previously, Maxime worked on the SANS SEC699 course. Besides his coding capabilities, Maxime enjoys reverse engineering samples observed in the wild.
Published