Suspicious Strings in Memory

Usually during memory forensics, strings command is executed on images to identify any suspicious strings, which sometimes is helpful in putting together the the missing pieces of the puzzle and in some cases provide context and additional Indicators of Compromise. 

However, once we have a narrowed down list of suspicious strings from the memory, which we definitely would like to look into further, we should try to ascertain the physical offset of these strings in the raw memory image and to determine which process memory space contains those strings.

One of the first things we should always do is to create a text file containing all strings from memory with their physical offsets (in hex). This is beneficial and less costly as compared to running strings command multiple times on the image itself. 

Once we have the master file with all strings from memory, we can search for strings in this file, for example, I would like to search for all occurrences of the string "PSEXEC" in the master string file. Lets pick one of the physical offset. 232dda10

Next, I will run the volatility plugin called memap, which basically provides the overview of processes, their PID and the VO (Virtual Offset) and PO (Physical Offset) of memory pages allocated to that process, size of the page and PO of the page in the resultant file created when memdump volatility plugin is executed for a certain process.

Let us have a look at the contents of the memmap, which is created as a result of the above command. It shows the virtual offset, physical offset, size of the memory allocation blocks for various processes.

If we are able to find the physical offset of the string in this output, we will be able to determine, which process memory space contains the string of interest.

What I decided to do was to remove the first column (virtual offset), and then order the content of the resultant file by Physical Offset values.

Removing first column 

Now ordering by decimal value of the physical offset

I could then search the physical offset 0x232dda10 in the resultant file. I will be able to find the physical offset nearest to this offset in this file. In this case we can see that the nearest physical offset is 0x00000000232dd000, which is less than 0x232dda10

Once I get the nearest physical offset to the target offset, I will search for this nearest physical offset found again in the original file containing the output of memmap volatility plugin. Here we can see we have found the nearest physical offset along with virtual offset.

Once I find that offset in the original file, I can just reverse search for the string “PID”. The first hit will be the process, whose memory space will be containing the string.

Now let us verify this by dumping memory space of this process and searching for this string “PSEXEC”.

We can see some other suspicious strings near the string we are concerned with.

It is to be noted that the strings found could be remnants of anything (not necessarily related to strings in the process binary), as this could be part of some injected code or it could be remnants of any other process, which might have executed since machine was rebooted last time and happens to linger in the allocated memory space. Malloc doesn’t zero out the contents of memory when allocating memory to a process.

Investigating Further, we open the process memory dump in a hex editor and go to these physical offsets and try to determine if these are part of injected code or maybe we could get some indication of the nature of these strings.

Let is try to carve some files out of the process memory dump

We found following carved files with the psexec string:

Now after carving suspicious process memory space and carving files from that space, we can proceed to analyse the files and run tools like yara scanning, clamscan and VT submission to further identify malicious files.

However, we should always be careful in making assumptions and ensure that we beware of false positives. As we can see that the process, which we were investigating was a Symantec endpoint protection and no wonder the process space contains so many suspicious strings as these could be anything ranging from signatures to descriptions of malware etc.

In cases, where such strings are found in the memory space of winword.exe, cmd.exe, powershell.exe, explorer.exe, svchost,exe, taskhost,exe etc, then it would be worth looking at the carved files further or look around the strings to try to attain context and IOCs to hunt for in the environment.