Event ID 1024

As i’m sure i’ve mentioned before, event logs are a great source of evidence when performing incident response. In particular, lateral movement can be one of the hardest things to identify when investigating network based intrusions.

Event ID 1024 in log file Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx is an event that can sometimes be overlooked and it relates specifically to ActiveX controls in remote desktop.

In built ActiveX controls allow an administrator to configure the RDP user experience by providing scriptable interfaces and can allow embedding RDP ActiveX control in web pages and configuring URL security zones, as a couple of examples.

Screen Shot 2019-09-22 at 1.00.34 pm

Event ID 1024 which contains the following message:

“RDP ClientActiveX is trying to connect to the server (IP.ADDRESS OR HOSTNAME)”

Whether IP or hostname display here, will depend on what is entered in “Computer” files in the GUI for remote desktop.

Screen Shot 2019-09-22 at 12.59.55 pm

This event ID appears (in testing) to be generated when a user initiates an RDP connection using the RDP client MSTSC.exe in Windows by pressing ‘connect’.

The great thing is, event 1024 entries will be created whether a session is connects or not.

This means while an attacker may not have successfully connected via RDP to another computer, we may still see evidence of their attempts. This log may also persist longer than other logs too, where a Security log may only cover a days worth of activity, you may find months worth of evidence in this log.

When paired with 4648 Security events and other remote computer RDP logs, this can show both attempted or successful connection and authentication to a remote (target) computer.

Reference:

https://nullsec.us/windows-rdp-related-event-logs-the-client-side-of-the-story/

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4648

https://ponderthebits.com/2018/02/windows-rdp-related-event-logs-identification-tracking-and-investigation/

 

Windows 10 Timeline – Initial Review of Forensic Artefacts

As you may be aware, there is already a plethora of forensic tools available for producing system timelines, all with their own capabilities and some with limitations. From Sleuth Kits FLS/Mactime, Plaso/Log2timeline, XWF, Axiom, Encase and more recently Timeliner for Volatility.  I’m sure many more have performed this function to varying degrees over the years but Microsoft hasn’t been one, until now.

Last patch Tuesday, Microsoft released Windows 10 update (1803) which has brought along a number of new features including a new Timeline function, which allows users to look back in time at their previous activities.

This got me thinking.

A built-in Windows utility which shows linear recent activity (within thirty days) on a computer system and runs under user context.

Very interesting… Let’s take a look!

File Creation/Opening

First I had to find out where Windows tracks all of this activity. A simple keyword search for a sample document name ‘This is a test document.docx’ exposed the following file as a potential area of interest:

C:\Users\User\AppData\Local\ConnectedDevicesPlatform\L.User\ActivitiesCache.db

Now, SQL is not my forte so I had a pretty rudimentary poke around by parsing it out to csv to see what I could find. The database file contains a number of tables and of initial interest, I would highlight the ‘Activity’ and ‘Activity_PackageID’ tables for a first look to interrogate this file.

Windows 10 Timeline

Windows 10 Timeline

 

In the ‘Activity’ table under ‘AppID’, Microsoft Word can be seen as the application used to open the file.

Screen Shot 2018-05-05 at 10.10.29 pm

From the ‘Payload’ entry you can identify further display options for the Timeline entry, including ‘Word’ and the display text being the filename.

screen-shot-2018-05-05-at-9-46-15-pm.png

Timestamps

Other notable entries found in the Activities Cache database are the associated timestamps. For our test document mentioned above, you can see the following timestamps which are stored in Unix format within the ActivitiesCache.db file:

Last Modified: Tue, 1 May 2018 20:28:18

Expiration Time: Thu, 31 May 2018 20:28:18

Start Time: Tue, 1 May 2018 20:28:18

Last Modified on Client: Tue, 1 May 2018 20:28:18

After some testing, I identified that the expiration time is as expected, thirty days from the entry start time. The timestamps do not appear to be updated after a file is deleted although the deleted file will remain visible in the Timeline (presumably for up to thirty days or when the database is purged). Timestamps do not appear to be updated within a twenty-four hour period, after modification to files.

Program Execution

The ‘Activity_PackageID’ table contains entries for applications which include paths for executables, executable names and also the expiration time for these entries. This activity not only shows applications that were executed within the last 30 days but by backdating the expiration timestamp, you may be able to identify a time when that application was run and by which user. This can obviously be correlated with other artefacts such as prefetch.

ActivitiesCache.db

This is just some initial testing and there is a wealth of further information in this file which will need further analysis to decode fully. It’s certainly nice to see some new functionality in Windows which not only serves a meaningful purpose for the end user but also provides examiners with another artefact showing user interaction, web browsing activity, program execution, file opening and creation.

Update:

Eric Zimmerman has written a tool now to parse this database and you can find that along with all his other amazing tools, here:

https://ericzimmerman.github.io/