Who hacked us – A forensic story of attribution

Written 14-May-2025 13:45:00 by Simon Krogh Bjerre

Most people who have dabbled in the world of digital forensic investigations will agree that one of the hardest challenges is to place the suspect “behind the keyboard."

Often when we investigate a case, the question is raised as to who is responsible for the attack. After all, it is very human to want to identify the real-life hackers behind the keyboard in order to pursue legal action or otherwise. But while the desire to de-mask the perpetrators is understandable, the itm8 CSIRT usually advises customers that it is wiser to spend precious time and resources focusing on the areas required to reestablish business operations rather than determining who is responsible for the attack. The reality is that most threat actors are sitting in jurisdictions outside the reach of law enforcement, due to lack of mutual legal assistance treaties or extradition agreements.

However, while identifying the threat actor is not at the forefront of most investigations, sometimes the stars align, and attributable evidence falls directly into the lap of analysts, to a point where you can’t help but dig a bit deeper.

Here is the story of one such forensic investigation, where we will look at some of the more visual forensic artifacts and the tooling that can be used to perform incident response. This story will show the investigative methods used by the itm8 CSIRT team, which led to an unusual geographical attribution, that gets us just a bit closer to answering the question “Who hacked us?” 

A call and a clue 

Our story starts on a quiet morning, as the CSIRT team is just getting settled in with a fresh cup of coffee when suddenly the IR phone rings. The call is from a new walk-in customer who was hit hard by ransomware. Their infrastructure has been completely encrypted, and their business operations have come to a grinding halt.

As usual, the team quickly follows the normal investigative tracks to find the initial point of entry, escalation techniques, persistence, signs of data exfiltration, and so on. But already early on (before the main questions have even been answered), the team stumbles upon a piece of attributable evidence that may ultimately lead to the identification of the threat actor. This evidence seems to have been unintentionally left behind by the adversary, which is often how most attribution starts.  

Bitmap cache – a digital window into the attacker’s screen 

While conducting a forensic investigation, analysts may encounter well over 100 different artifacts ranging from normal logfiles to super specific telemetry data. One specific artifact that may be examined is the Remote Desktop “Bitmap” cache. To better explain: When using a remote desktop, the screen is refreshed several times a second to give the user a smooth experience. But sending images over the network requires a fair bit of bandwidth. To compensate for this, Windows only transmits the parts of the screen that change, and the rest of the image is filled in by fragments of how the screen looked in the past. These fragments are all stored in what is known as the bitmap cache.

Luckily the investigation of the compromise found that the threat actor had used the terminal server as their primary foothold inside the compromised environment, and as such had initiated outgoing RDP connections to many of the other servers, unknowingly leaving the CSIRT with a nice set of Bitmap Cache files to examine.

From binary blobs to visual insight

By default the Bitmap files are stored as binary data, meaning that a person looking plainly at the files would be hard pressed to interpret the contents. To process the binary data into pictures, a variety of premade tooling exists. In this case the analysts used the BMC-Tool, to convert the binary data into viewable images, the tool is available on GitHub: https://github.com/ANSSI-FR/bmc-tools

One neat feature of the BMC-Tool is that it will output a collage of the images extracted from the Bitmap. This in turn gives analysts a glimpse of the threat actor’s activity while remoting around the compromised environment.  

During this particular investigation, besides observing a picture of the normal tooling and activities used by the threat actor in the Bitmap, one key discovery was a deviation from what would be the normal English language settings found on the servers. The abnormalities are highlighted below in red.   

Language detection – and a linguistic lead 

Using the always handy snipping tool, to combine a couple of the pictures that included the abnormalities in language use, we can construct a crude language sample for recognition testing.

By panning over the language snippets, using Google Lens (with the language autodetect option enabled), we learn that the non-default language can be interpreted as Persian, with parts of the snippet translating to “Unlock the file.” This contextually makes sense considering we are investigating a ransomware attack. With the indication that the threat actor speaks or at least can work with Persian language settings, the investigation continues.  

The disappearing ransomware

While a threat actor with the end goal of deploying ransomware, doesn’t necessarily put too much thought into being “stealthy” and minimizing evidence, in some circumstances, ransomware operators are known to remove their tooling from the compromised systems. We learned through our investigation, that our threat actor had been removing tools, including the ransomware binaries (fittingly named “Ransomware.exe”) as can be seen from the USN Journal.  

For the sake of speed, no full disk images were collected for the incident response investigation, this in turn meant that carving for the deleted ransomware file on the disk was not an option.

However, having not fully given up on the idea of recovering the ransomware executable, the investigation continued. In the event logs for one of the compromised servers, an eventID 1117 was present. EventID 1117 is captured whenever Microsoft Defender Antivirus performs a protective action for the endpoint.  Looking in the aggregated event showcased below, we learn that a file named “Ransomware.exe_” was successfully quarantined by the AV product. 

Extracting the malware from quarantine 

The next step was to correlate the file “Ransomware.exe” to “Ransomware.exe_.” The USN journal is a great artifact for this exact purpose since it records file system changes. The analysts were able to use this artifact to learn that “Ransomware.exe_” was later renamed to “Ransomware.exe.”

This is great news! since we now have confirmed an alternate location from which we can retrieve the ransomware executable (namely the defender quarantine folder), which is normally collected during our triage process.

Once again, we refer to GitHub for tooling to help our investigation, this time we need a tool that will allow us to recover a quarantined file. Fortunately for us there exists a nifty python script for our exact use case, the project defender-dump, can be downloaded from the following page: https://github.com/knez/defender-dump  

Running the defender-dump tool against our triage images shows that in the quarantined folder exists a file named “Ransomware.exe_”, just as indicated by the event log. Appending the flag for file extraction(-d) and running the tool again leaves us with the malware ready for analysis.  

A deeper look into the executable

After moving the extracted malware to our malware analysis machine, a quick initial look at the “Ransomware.exe_” file shows that we are dealing with a Windows 32-bit portable .NET executable. 

The next step in analyzing the malware was to load it into a .NET decompiler of choice. For this case we will be using dnSpy, which can be found on the following link: https://dnspy.org

Going through the code of the decompiled ransomware, it is immediately clear that the threat actor did not put any effort into obfuscating the code itself, and with the ransomware being written in .NET, it is easily readable. Sifting through functions such as “stopBackupServices” and “UltraSecureKeyGenerator,” we arrive at our next clue for the attribution puzzle.  

Strings, errors – and a name? 

In the function “EncryptLongString,” after an implementation of RSA cryptography (at the very bottom) we see the developer left some error handling in the code.

The error handling contains a string of characters that appear like the ones uncovered in the bitmap cache, which were previously confirmed to be Persian. 

Again, referring to the autodetect capabilities of Google translate, we paste in the string from the error message found in “Ransomware.exe_” into Google translate. We again come to learn that the error message could be interpreted as Persian and translates to “Encryption error.” This translation makes sense based on where we extracted the string from.  

Now we have another indication of the origins of our ransomware operator. However, we are not even done with analyzing the malware binary yet. 

Final attribution – the “Soldier” variable 

It is quite common for ransomware lockers to have configurable parameters, which are changed to suit the individual attacker, either when building the ransomware, or with a separate configuration file. The configurability is especially common when the ransomware lockers sold as part of a Ransomware-as-a-Service (RaaS) solution, as the individual extorsion groups want to be able to configure the malware to act and present in a distinguishable fashion.   

With this knowledge, the CSIRT continues following methods for disabling volume shadow copies, various antivirus products, and backup services. When they finally arrive at an internal class named “config,” this is where they find the next piece in the attribution puzzle. In the config class there are 4 strings instantiated. A quick glance shows two email addresses being configured as email_1 and email_2. The two email strings are used later in the script as part of the extension for encrypted files.  

The CSIRT also sees a longer string containing expressive language and newline characters. This is of course the ransom-note left behind post encryption. But out of all the strings, the very first one with the variable name “Soldier” is the most interesting, as it is not used anywhere else in the ransomware code, but simply instantiated.  The Soldier variable is assigned the string “Mehrdad.” Even though the attribute soldier might not directly indicate it, the character combination “Mehrdad” is certainly a name.  

Persian clues point toward attribution 

While it is somewhat common to find code comments etc. in various languages, the Soldier attribute containing the name of the potential ransomware operator is unique and certainly a first for me.  

Reverting to our favorite digital forensics tool Google, a quick search provides some contextual information about the name Mehrdad. From the Wikipedia article we learn that not only does the name Mehrdad have Persian origins, but it is also commonly given to males in the country of Iran. 

At this point, one might attest to the theory that the threat actor was likely of Iranian origin, as the person was not only fluent in the Persian language but also had a distinct Iranian name. If you are still not fully convinced, let me present the final piece of evidence puzzle. 

Remote login after deployment

Moving chronologically to a time shortly after the ransomware was deployed — but before the intrusion was identified and the infrastructure was isolated. Usually, this is where the customer environment goes somewhat quiet (aside from all the operational errors), as the servers are struggling to keep running — if even alive — and the normal business operations of the company are most certainly disrupted.

Shortly after midnight, an EventID 22 was recorded by the Microsoft-Windows-TerminalServices-LocalSessionManager/Operational event provider on one of the previously ransomed servers. This particular type of event ID is recorded when an interactive login session is initiated on the machine. In this case, it was recorded because the threat actor remoted into the server’s Administrator user.

The threat actor returns

Now whether the threat actor decided to revisit to confirm the malware executed successfully, ensure that all the important data was exfiltrated, or to admire his work is uncertain. But what is for certain is that a remote desktop session was initiated to an external public IP address.

In and of itself, the fact that the remote session was initiated may not look like a huge finding in terms of attribution, since the team already noted that the threat actor was connecting repeatedly from all kinds of VPS services located all over the world. However, digging deeper into the IP address recorded in the event, something uncommon likely occurred. It appears that in the threat actor’s rush to finish the job, he had forgotten to use his privacy measures (i.e., the VPS infrastructure) and instead connected directly from his personal internet connection.

Looking up the IP address logged in EventID 22, it is apparent that it belongs to an IP range used by Iran Telecommunication Company (TCI), which, among other things, provides data services to private and business customers in the country of Iran.

A clean IP and an opsec failure

Taking it a step further and querying the Iranian IP address against reputation databases such as VirusTotal or AbuseIPDB, we learn that the IP address still has a “squeaky-clean” reputation at the time of writing this blogpost. The fact that this IP address is unknown in terms of reputation supports the theory that this IP address had not previously been used for malicious campaigns and rather was only uncovered in the investigation due to the threat actor’s error — in which they briefly forgot to use their anonymous infrastructure.

Pulling the pieces together

Now, this was a long process of piecing together different bits of attributable information. We explored the types of artifacts operator error may leave behind, along with a whole set of forensic tooling that can be used to extract valuable artifacts — all just to get a tad bit closer to the age-old question: “Who hacked us?”

Let’s summarize what we know: There were multiple indicators that the threat actor has some level of fluency in the Persian language, which is commonly used in Iran and adjacent countries. Evidence shows we are likely dealing with a man named Mehrdad, which again points to Iranian origins; and due to an opsec error, the CSIRT identified that the threat actor is likely a customer at the Iranian internet provider TCI — further cementing the idea that the person is a resident of Iran.

Why attribution still matters

Even though the information gathered from the investigation will not enable anyone to run up to a particular person on the streets of Iran, point fingers and yell “you did it!”, it’s enough to start painting a picture of the threat actor.

Taking a step back and looking at attribution work in a grander context, we recognize that having a good idea of the people behind a threat actor group can matter. While it is true that attribution is rarely the primary focus of an incident response investigation, there are still lesser-acknowledged values in knowing your threat actor.

First, if the customer decides to initiate contact with the threat actor, a professional negotiations team will be better equipped to communicate and negotiate simply by being aware of cultural differences and tendencies. Secondly, looking at a wider scope than just the one incident, attribution artifacts help other investigative teams fingerprint and more easily recognize the same threat actor in future campaigns.

Want to go deeper?

Note: This blogpost is a companion piece. For the story of how the encryption can be broken, refer to the blogpost: “Decrypting Jett Ransomware: When hackers make coding mistakes.”