Monday, January 07, 2019

Mystery Hacked System

Ali was gracious enough to make several of the challenges that he put together for his students available online, as well as for allowing me to include the first challenge in IWS.  I didn't include challenge #3, the "mystery hacked system" in the book, but I did recently revisit the challenge.  Ali said that it would be fine for me to post my findings.

As you can see, the challenge is pretty admin found a message "written on their system", and reported it.  The questions that Ali posed for the challenge were:
  1.  How was the system hacked?
  2. What evidence did you find that proved your hypothesis?
  3. How did you approach and solve the case?
  4. Anything you would like to add?
Below are my responses:

Question 1
Based on what I observed in the data, I would say that the system was not, in fact, hacked.  Rather, it appears that the Administrator user logged in from the console, accessed the C:\Tools folder and created the readme.txt file containing the message.

Question 2
I began with a visual inspection of the image, in order to verify that it could be opened, per SOP.  An initial view of the image indicated two user profiles (Administrator, master), and that there was a folder named "C:\Tools".  Within that folder was a single file named "readme.txt", which contained the text in question.

From there, I created a timeline of system activity, and started my analysis by locating the file 'C:\Tools\readme.txt' within the timeline, and I then pivoted from there.

The readme.txt file was created on 12 Dec 2015 at approx. 03:24:04 UTC.  Approx. 4 seconds later, the Automatic JumpList for Notepad within the Administrator profile was modified; at the same time, UserAssist artifacts indicated that Administrator user launched Notepad.

At the time that the file was created, the Administrator user was logged into the system via the console.  Shellbag artifacts for the Administrator account indicated that the account was used to navigate to the 'C:\Tools' folder via Windows Explorer.

Further, there were web browser artifacts indicating that Administrator account was used to view the file at 03:24:09 UTC on 12 Dec 2015, and that the 'master' account was used to view the file at 03:27:23 UTC on the same day.

Question 3
I created a timeline of system activity from several sources extracted from the image; file system metadata, Windows Event Log metadata, and Registry metadata.  In a few instances, I created micro-timelines of specific data sources (i.e., login events from the Security Event Log, activity related to specific users) to use as "overlays" and make analysis easier.

Question 4
Not related to the analysis goal provided were indications that the Administrator account had been used to access the Desktop\Docs folder for the 'master' user and created the 'readme.txt' file in that folder.

In addition, there was a pretty significant change in the system time, as indicated by the Windows Event Log:

Fri Dec 11 17:30:37 2015 Z
  EVTX     sensei            - [Time change] Microsoft-Windows-Kernel-General/1;
*Time was changed TO 2015-12-11T17:30:37 FROM 2015-12-12T03:30:35

Finally, there was some suspicious activity on 12 Dec, at 03:26:13 UTC, in that magnify.exe was executed, as indicated by the creation and last modification of an application prefetch file. This indicates that this may have been the first and only time that magnify.exe had been executed.

Several seconds before that, it appeared that utilman.exe had been executed, and shortly afterward, net.exe and net1.exe were executed, as well.

Concerned with "Image File Execution Option" or accessibility hijacks, I searched the rest of the timeline, and found an indication that on 11 Dec, at approx. 19:18:54 UTC, cmd.exe had been copied to magnify.exe. This was verified by checking the file version information within magnify.exe.  Utilman.exe does not appear to have been modified, nor replaced, and the same appears to be true for osk.exe and sethc.exe.

Checking the Software hive, there do not appear to be any further "Image File Execution Option" hijacks.

I should note that per the timeline, the execution of magnify.exe occurred approx. two minutes after the message file was created.

After I posted this article and Ali commented, I found this blog posted by Adam which also provided a solution to the challenge.  Adam had posted his solution on 2 Jan, so last week.  I have to say, it's great to see someone else working these challenges and posting their solution.  Great job, Adam, and thanks for sharing!

Addendum, 9 Jan:
Based on a whim, I took a look at the USN change journal, and it proved to be pretty fascinating...more so, it showed that following the use of the net.exe/net1.exe, no files were apparently written to the system (i.e., output redirected to a file).  Very cool.


B!n@ry said...

I liked how you considered the "readme.txt" as a pivot point and started your investigation from there. This approach has been previously mentioned in your books too, which proves what is written there, is what you approach in a daily life scenario and wasn't just for the sake of writing!

Also, what I liked here is the time changes that happened and was discovered. There are some points that could be discussed offline, but the work done, how it was done, all was really impressive.

Thank you for your time and efforts working on this.

H. Carvey said...


Thank you for posting the challenge. I enjoy working the "puzzles" and keeping my fingers in the DF work. Thanks!

Adam Ferrante said...


I really like your approach and checking for Image File Execution Option hijacks. This is something that can tell us a lot. I've played with this in the past, but really happy to see it here being looked into further. I need to take a further dive in for future cases. Awesome read, and great job on figuring this out. Always interesting to see alternative ways of reaching the same conclusion!

Also, I've linked this post in my post as well. The more solutions the better!

H. Carvey said...


Thanks for the comment.

I'll admit, the Image File Execution Option hijack was "on my mind" my current role, I get to 'see' what adversaries are up to, and I recently saw where an adversary attempted several times to set just such a hijack; it took them several attempts due to misspellings. Once they got it set, they tried to use it, but the attempts were blocked by the EDR tool.

Something I didn't mention in the blog post was that I did look at other things...AppCompatCache, SRUM, etc. I didn't get any new data, nor a new perspective on the 'case' from these sources.

Also, the use of overlays made things much easier...Windows systems themselves are extremely 'noisy', and in one instance, all I wanted to see was the logins recorded in the Security Event Log, without all of the other activity around the events. This made analysis much easier.

Again, thanks, and I'm definitely looking forward to more articles on your blog! ;-)