It’s important to associate the suspect with digital evidence and not have concerns that an attacker could have placed incriminating evidence. While finding direct evidence is important, it’s also important to rule out remote access.

This blog posts covers how an attacker could place evidence and what artifacts to look at. It’s easy for a suspect to claim that some mythical attacker placed evidence there (without evidence of an attack) and we want to make it almost as easy to look for signs of remote access. We also want to make sure that innocent people are not wrongly accused because of a real attacker.

The Trojan Defense in Digital Evidence

The trojan defense is when the suspect claims they are innocent and that someone else placed the digital evidence on their device. It’s also referred to as “Some Other Dude Did It (SODDI)” and “Not My Pants” (which is a reference to when drugs are found in someone’s pants pockets).

In US criminal trials, the suspect does not need to have evidence to make this claim. They can simply make the claim to introduce doubt in the jury.

To counter the claim, the prosecution’s experts should be able to testify that they looked for remote access evidence and didn’t find any.

Looking For Exculpatory Evidence

While the main topic of this article is about countering a trojan defense, it’s important to remember that it is possible for someone to remotely access a computer and save data to it.

This happens to ransomware victims every day around the world. The ransomware encryption tool is downloaded and runs on the victim’s system. Attackers could similarly download evidence of a crime, such as child exploitation material, to a system.

Investigators should proactively look for remote access to increase their confidence that the device owner is who caused the evidence to be created. They should also look for evidence to link user-specific activity with the evidence.

Example Scenarios

Let’s cover some high-level scenarios where an attacker could copy evidence onto a suspect’s system.

Malware RAT: The attacker causes the suspect to run a piece of malware that then gives the attacker remote access. The malware could have been delivered by email or the suspect was tricked into downloading it. These are often called Remote Access Tools (RATs).
Commercial Remote Access: There are several commercial tools that exist to allow IT people to remotely access a system or a computer user to remotely login. Examples include AnyDesk, LogMeIn, and Windows Remote Desktop. Attackers could cause users to install one of these tools or exploit one that is already installed.
Remote Windows Access: If the attacker is on the same network as the suspect, they could guess a Windows account password and either mount a drive share or use PowerShell Remote to copy and download files. These are capabilities that come with Windows.

All of these have different forms of challenges, whether it’s causing the user to install a program or guess passwords. They all also leave evidence of the access.

Types of DFIR Remote Access Artifacts

There are three categories of artifacts to look for when reviewing a system for remote access. We’ve recently done full length talks about this at the National Cyber Crime Conference (NCCC) and Techno Security East, but here are the key points.

Malicious RATs

To find these, look at the running or past processes on the system and analyze them for malware and other suspicious behaviors. Past processes include those that are listed in Prefetch and other similar artifacts.

Attackers will also likely to want to retain access and therefore you should check the “AutoRuns” locations and other triggered tasks that could cause programs to periodically start.

Having a diverse set of malware detection engines is important because not all of them flag the same things.

This is the most common thing that law enforcement does to look for remote access. They will mount the image and scan it using a single anti-virus tool.

One downside of mounting the image is that it is possible that you could accidentally launch malware on your own system if it was on the suspect’s computer. It’s better to keep those files contained in the disk image container.

If a RAT is found, you’ll need to look at when it was installed and compare that with the evidence on the system. These RATs do not typically have log files to show when and where connections came from.

Commercial Remote Access Software

Finding commercial tools is similar to malicious RATs. After all, they are both processes that need to run so the attacker can access them.

So, you should look at current and past processes as well as the triggered tasks. In this case though, these programs will not get flagged as malware by AV tools. You’ll need a list of remote access applications to use and see if they exist.

If you find these commercial tools, you’ll need to determine if they are supposed to be there and, if so, if all of the connections are expected. These tools all have a log file that you can parse to identify when the connections existed and from where they came.

Windows Authentications and Logs

Lastly, you should look at Windows event logs, especially the Security log. This will contain information about when the Windows authentication infrastructure was used. This infrastructure is used by both Windows and 3rd party applications, so the data here may overlap with other commercial remote access logs.

The main idea here is to look for Event ID 4624 with external IP addresses. These events show when Windows created a logon session, which is required when the local drives are mounted, PsExec or Powershell Remote are used, or the user logs into the system. We previously covered what the Network Logons means in this log file.

There are other logs that also show additional Remote Desktop information, which we’ve covered in the past.

Any access from an external IP should be understood. Unfortunately, it can be hard to identify why a Network Logon session was created.

The other important note for this topic is log roll over and audit settings. Not all computers are configured to log when these authentications are successful or failed. And they may roll over after a few weeks of activity.

So, if the logs do not go back very far, there is no log evidence to support or refute remote access before that date.

Detecting Remote Access with Cyber Triage

Cyber Triage’s automated analysis will look for all three categories of remote access artifacts. You can simply add a disk image or other data source into Cyber Triage and it will:

Look for malicious RATS
Look for commercial remote access software
Analyze and cluster logon sessions

To look for malicious RATs, enable malware scanning. Ideally, you allow Cyber Triage to upload file content for files that have not been seen before, but you can also use the new ImpHash feature to do fuzzy matching.