Forensic Investigation of the MEGAcmd Client
Double extortion is now the de-facto model for ransomware attacks.
Before data is encrypted – the point at which most attacks are first discovered – threat actors will often collect and exfiltrate sensitive data from the victim organization. The data exfiltrated may include internal employee personally identifiable information (PII), external customer invoices with banking information, and/or other forms of intellectual property.
To increase the likelihood of a ransom payment and to maximize the amount paid, threat actors threaten to release the exfiltrated data publicly. The ransomware operators often state how much data was exfiltrated from the environment and provide a small sample as “proof-of-life.”
Organizations need as much information and context as possible to make the appropriate business decision: Pay the ransom or take the risk of having the data exposed publicly, or possibly both.
It can be difficult to validate ransomware operator claims of exfiltrated data. What exactly was exfiltrated? And how much?
The cloud storage provider mega.nz (MEGA) is a common destination for exfiltration observed in recent ransomware attacks. This blog will focus on identifying forensically relevant artifacts related to the MEGAcmd client (version: 22.214.171.124) desktop client.
Host-based artifacts extracted from a Windows 10 Professional (2H20) desktop within a controlled lab environment combined with network artifacts captured and parsed by the Awake Security Platform will show the potential for validating ransomware operator claims of what, when, and how much data was exfiltrated from an environment.
All screenshots, data, and credentials shown are from a lab environment.
If the User-Interface install utility is used to install MEGAcmd, the default install location is in the user profile of the account that performed the installation.
NOTE: An install like this would generate forensic artifacts common to any software install (e.g. an Application Event log entry) – those will not be covered in this blog. Instead, we focus on the artifacts specific to MEGAcmd that would identify which file(s) were exfiltrated and when.
It is possible to run the MEGAcmd utility without installing – in which case the relevant files could be placed anywhere. Endpoint Detection and Response (EDR) queries to identify applications executed from any %USERPROFILE% path would help identify the MEGAcmd utility.
The MEGAcmd utility is composed of two core components: a MEGAcmdServer – the process responsible for handling client requests and interacting with the MEGA.io account, and MEGAcmd – a command-line shell that allows the user to interact with the server component.
In Task Manager, both will be found under the MEGAcmdShell application listing:
By default, on the first run of MEGAcmdServer – auto-update is enabled.
Auto-update is achieved via a Scheduled Task. MEGAcmd creates a Scheduled Task (Figure 2) named with the SID of the user that performed the MEGAcmd install. It is run daily, and every 2 hours thereafter for as long as the user logon session remains active.
The install time of the scheduled task corresponds to the first execution of the MEGAcmd client. The time may also correspond to the start of exfiltration if the user begins file transfers soon after client startup.
Figure 2 – Scheduled Task
Identify Exfiltration Timeframe
Figure 3 shows there is a hidden directory called .megaCMD in the same local directory as the MEGA* executables. .megaCmd contains a set of files that maintain configuration and state data for the MEGAcmdServer.
megaclient_statecache12_transfers_<random_string>_<random_string>.db is of particular importance in maintaining a history and status of file transfers. We will refer to this file as transfers.db.
Transfers.db is an encrypted SQLite database maintained for the duration of the MEGA cloud session. Because it is encrypted, it is not practical to read the data directly from the filesystem; however, there is still valuable context available while this file is present.
The transfers.db file is first created when a user authenticates with the MEGA Cloud service from the MEGAcmd console (Figure 4)
The NTFS Created Time will give the start of the authentication session. Figure 5 shows the transfer.db and the other metadata files in the .megaCMD directory at the time of session authentication.
When a transfer is started, the corresponding .db-wal file is updated. The .db-wal file is a journal of changes that are staged prior to being committed to the permanent database (.db) file. Figure 6 shows the .db-wal file modified time was updated when a transfer was started.
If the user explicitly signs out of the MEGA cloud account with the LOGOUT command, the .megaCMD/*.db files are deleted and the .megaCMD/session file is cleared; however, if the user simply closes the MEGAcmd window – the .megaCMD/session file is not cleared and the MEGAcmdServer process will continue running. The session file contains a session key unique to the current logon session with MEGA cloud.
If MEGAcmd.exe is started again while the .megaCMD/session file still exists, the authenticated session will be automatically resumed with no credentials required (Figure 7).
At this point, the user may transfer additional files. That action would update the Last-Modified timestamp on the transfers.db and related journal files. This pattern can continue for days or weeks.
At the time of forensic collection– the Create Time to Last-Modified time of the transfers.db file provides an approximate window for data exfiltration.
Having this window is good and may help identify pivot points for additional analysis, but how can we get a list of the file(s) transferred if the SQLite database is encrypted?
During an authenticated logon session, the MEGAcmd client command
‘transfers –show-completed` provides a list of completed file transfers is (Figure 8). For Incident Responders this could be the easiest method to find the list of files transferred if the following conditions are met:
- The Incident Responder has already identified a server running the MEGAcmdServer process
- The .megaCMD/Session file has not been cleared
- The Incident Responder launches MEGAcmd, and the previous session auto-resumes
Presumably, the MEGAcmdServer process reads this data from the transfers.db . This would mean that a decrypted version of the transfer.db file or at least some of the decrypted data may be available in the process memory.
At the start of an investigation – during evidence collection, the specific endpoint from which data was exfiltrated may not be known. It would then be advisable to include collection of memory from processes with potentially high value, like MEGAcmdServer, in a standard triage collector across a wide selection of endpoints.
There are multiple methods to capture the relevant process memory. A full system memory capture can be collected, and then a tool like Volatility can be used to dump the specific process memory – examples shown below. Alternatively, the process memory can be dumped directly by a tool like ProcDump or Velociraptor.
For this blog, a full system memory capture was achieved using WinPmem64 via the Velociraptor artifact Windows.Memory.Acquisition; however, a full capture may be overkill in your situation so as an alternative, you can dump a specific process memory with Velociraptor using the following command:
Awake Labs created a custom Velociraptor artifact to collect high-value process memory like MEGAcmdServer. The artifact can be retrieved from the Velocidex Artifact Exchange.
If a full system memory capture is collected, some additional steps are needed to first identify the MEGAcmdServer process ID (PID) and then dump the relevant process memory. Volatility version 3 was used in these examples.
Identify the MEGAcmdServer PID
In the results, the first column holds the process ID: 4552 for MEGAcmdServer.exe (Figure 9)
With the PID, the relevant memory sections can now be dumped using volatility plugin windows.memmap.
That command will output a file named pid.4552.dmp with the relevant data.
Extract Interesting Strings
Figure 8 above, showed that the Local File path for transfers is in the format \\?\<VOLUME>\<filepath> .
Run the strings utility against the pid.4552.dmp file and look for any string that matches the \\?\ prefix.
Figure 10 – Strings pid.4552.dmp
The screenshot shows a series of files from the H: and R: volumes were copied. These were likely mapped drives on the system (and maybe specific to the user) from which MEGAcmd was running; however, mapped drives are not required to copy files from network locations. The MEGAcmd client can also copy files directly from network shares as seen in Figure 11.
What else is in the process memory?
Awake Labs also identified the MEGA cloud account credentials in plain text in the MEGAcmdServer process memory dump. The relevant strings were slightly easier to identify in the process dumped directly by Velociraptor (Figure 12), but the data did exist in the memory dumped by Volatility as well.
The host artifacts discussed above can provide answers to when and which data was exfiltrated.
When host-based artifacts aren’t available for some reason, network artifacts can provide some insight as demonstrated here by capturing network traffic using the Awake platform. The network can serve as a near real-time detection of the exfiltration activity and provide an answer as to how much data was exfiltrated.
Auto Update Beacon
As mentioned in the Host Artifacts section, MEGAcmd creates a Scheduled Task that periodically checks for updates. Every 2 hours, while the Windows 10 user maintains an active logon session, the MEGAcmdUpdater.exe will send an HTTP request checking for available updates as shown in Figure 13.
This following model in the Awake platform identifies this activity:
MEGAcmd login and logout
If the login and logout events can be identified, then a window for exfiltration can be narrowed.
The login and logout communication between MEGAcmdServer and the MEGA.nz cloud infrastructure occurs over TLS. The JA3 hash (c12f54a3f91dc7bafd92cb59fe009a35) served as a clear identifier for this version of the MEGAcmd client TLS characteristics. In the examples shown in this blog, TLS activities correspond with the login/session start and logout/session end events.
In Figure 14 – the listed activities are ordered by Ending timestamp. The activity start time is displayed in the first column.
Row 1 represents the initial login command from the MEGAcmd client. This is a TLS connection to g.api.mega.co.nz lasting 28 seconds. This activity causes a persistent connection shown in Row 5. Row 5 starts at 04:03:58 and is a persistent connection (7 minutes and 11 seconds) while the MEGAcmdServer session remained authenticated and active.
Rows 2 occurs a few seconds after the session is established – and is an ephemeral transaction (duration 0 seconds). The purpose of this TLS connection is unclear.
Row 3 corresponds to the end of a file transfer. The exact purpose of this TLS connection is unclear, but it may be transfer-related metadata passed between the local client and MEGA.nz.
Row 4 is the first logout command issued in MEGAcmd. This causes the persistent connection (Row 5) to close.
Figure 15 shows the start and end times of Row 5:
The final row, row 6 of Figure 14 – is the next login command for a new authentication session.
These TLS activities are powerful indicators for potential exfiltration activity. Where the transfers.db NTFS timestamps provided a rough estimate of transfer activity for only the last active session – and only if the session was not explicitly closed – the Awake Platform was able to identify all the session activities over a period.
JA3 Hash values are derived from the TLS Client Handshake and can, in some cases, identify unique applications or software implementations of the TLS protocol. The MEGACmdServer.exe JA3 hash was: c12f54a3f91dc7bafd92cb59fe009a35. This hash is designated as a Win10-Socket and may not be unique in all environments but can serve to narrow down a set of TLS activities.
JA3S hash values are derived from the TLS Server Hello. In testing, the JA3S hash of the g.api.mega.co.nz service was: 1249fb68f48c0444718e4d3b48b27188
To hear more about using JA3 in encrypted traffic analysis, check out this Awake webinar.
MEGAcmd File Transfer
MEGAcmd used TLS for session setup and possibly some metadata exchange; however, when it transferred files to the MEGA cloud account, data was encrypted locally and then sent over HTTP POST requests.
Figure 16 shows the initial DNS and HTTP requests for a file transfer to *.userstorage.mega.co.nz
There are 3 consecutive DNS lookups for gfs302n100.userstorage.mega.co.nz – each with a unique transaction ID. This is a quirk of the MEGAcmd client perhaps, that it would send three identical DNS requests to the same DNS server, at the same instant.
The DNS answer is received, and the transfer begins. Each POST request contains an 8 MB chunk of encrypted file data.
The MEGAcmd client User-Agent from a Windows 10 endpoint is identified in the headers shown in Figure 17.
In the Awake Platform, the domain profile for mega.co.nz will show the total data transferred between device and destination servers hosted at the root domain *.mega.co.nz. This can help validate if and how much total data left the environment. Figure 18 shows 2.7 GB of data was transferred to various subdomains of mega.co.nz. The 2.7 GB value will include some of the session and metadata transactions but will be a very close approximation of the total size of file(s) transferred.
Figure 18 – mega.co.nz domain profile
The right forensic data, host, and network, is critical in incident investigations and will inform critical business decisions in the face of ransomware attacks. This blog has shown specific data of interest when the MEGAcmd client is used for data exfiltration.
Host-based forensic artifacts can identify when and which files were exfiltrated with the MEGAcmd client as long as a valid, authenticated session is active and the MEGAcmdServer.exe process is found running.
Network-based artifacts captured by the Awake Security Platform provide an opportunity for near real-time detection of data exfiltration as well as a historical analysis of when and how much data was exfiltrated.
Network Artifact Summary
TLS connections to *.api.mega.co.nz mark the start and end of authenticated sessions between the MEGAcmd client and the Mega.io cloud service.
HTTP POST requests to *.userstorage.mega.co.nz identify file transfers.
HTTP GET requests to *.static.mega.co.nz can identify auto-update beacons and will highlight which devices have MEGAcmd installed.
Host Artifact Summary
- Scheduled Task: “MEGAcmd Updater Task <user sid>”
- Identify where MEGAcmd is deployed in your environment
- Identify the first execution time of MEGAcmd
- .megaCMD/*.db file timestamps
- Identify session start time with the Created Timestamp
- Identify last transfer time with Last Modified timestamp
- If .megaCMD/session file is still populated
- Auto-resume a session and use built-in commands to get a listing of which files were exfiltrated
- Capture the MEGAcmdServer process memory to extract a listing of which files were exfiltrated and MEGA.nz account credentials
Thanks to Kieran Evans and Patrick Olsen for contributing to the research and blog post.
If you liked what you just read, subscribe to hear about our threat research and security analysis.
Incident Response Lead
Dig Deeper with These Resources
Awake Security 2 Minute Explainer Video
What if security could think? What if it could sense danger, calculate risk, and react quickly based…
The Internet’s New Arms Dealers: Malicious Domain Registrars
This report dives into the results of a multi-month investigation that uncovered a massive global surveillance campaign…