In this series of blog posts we will deal with the investigation of an engineering workstation running Windows 10 with the Siemens TIA Portal Version 15.1 installed. In this first part we will cover some selected classic Windows-based evidence sources, and how they behave with regards to the execution of the TIA Portal and interaction with it. The second part will focus on specific evidence left behind by the TIA Portal itself and how to interpret it. Extracting information from a project and what needs to be considered to draw the right conclusions from this data will be the focus of the third post. Last but not least we will look at the network traffic generated by the TIA portal and what we can do in case the traffic is not being dissected nicely by Wireshark.
For the scope of this series of blog posts we look at the Siemens TIA (Totally Integrated Automation) Portal as the software you can use to interact with, and program PLCs. This is a simplified view, but it is sufficient to follow along with the blog posts. A PLC, or Programmable Logic Controller, can be viewed as a specially designed device to control industrial processes, like manufacturing, energy production and distribution, water supply and much more. The Siemens Siematic S7-1200, we will mention later in this series, is just one example of the many representatives of this family.
If you approach your first engagement looking at a Windows system running the TIA Portal, you might have the same thought as I had: “Will some of the useful evidences, which I know and used in other Windows-based investigations, be there waiting to be unearthed?” Since it is always better to know such things before an actual incident takes place, we will cover some of the more standard evidences and how they behave in regards of the TIA Portal. Please note, we will not elaborate on the back and forth of every Windows-based evidence we mention, as this is not meant to be a blog post explaining standard evidence.
Evidence of Execution is available as you would expect. If you know what to look for, it perhaps helps in forming answers faster and more precise.
The Prefetch artifact, if enabled on the system, would be written for “SIEMENS.AUTOMATION.PORTAL.EXE” and can be parsed like any other prefetch file. Additionally, the prefetch file for “SIEMENS.AUTOMATION.DIAGNOSTIC” also gets written or updated when the TIA Portal is started. If we have a look at the ShimCache (aka AppCompatCache) we can try to find the last time of execution by investigating the SYSTEM registry hive. In case of newer Windows systems, like in our example a Windows 10 system, you are out of luck in regards of the last time of execution. It is no longer recorded.
Investigating a Windows 10 system and having the System registry hive already open, the BAM key (ControlSet00x\Services\bam\State\UserSettings\$SID) will provide us with information on date and time for application execution. Knowing the executable name (“Siements.Automation.Portal.exe”) and using it in a simple search quickly reveals the information we are looking for.
Reviewing more user related evidence, by analyzing the NTUser.dat for the user accounts in scope of the investigation, leads us to the UserAssist key. Reviewing the subkeys starting with: “CEBFF5CD…” and “F4E57C4B…” will give us the expected information, like run count, last executed time and so on. Just make sure you are looking into the correct values for each subkey. In the subkey starting with “F4E57C4B…” it is shortcuts we are looking into. In our installation the .lnk files are named “TIA Portal V15.1.lnk”, which is the default value, as it was not renamed by us.
For the second subkey (“CEBFF5D…”) we are looking at the executables, so the actual executable name is what we should search for.
But what about finding projects that have been present or opened on the machine you are investigating?
First of all we should have an idea how a project looks like. Usually it is not a single file, instead it is a structure of multiple folders and subfolders. Furthermore it contains a file in the root directory of the project folder which you are using to open the project in the TIA Portal. The file extension of these files changes with the Version of the TIA Portal: “.apVERSION” is the current schema. This would mean, a file created with the TIA Portal Version 15.1 will have “ap15_1” as file extension, if created with TIA Portal Version 13 it will be “ap13” as file extension.
The following screenshot shows the file extensions which can be opened with the TIA Portal Version 15.1 and provides further examples of the naming schema.
Below you can see an overview of the files and the directory structure of a test project, in our case created with Version 15.1 of the TIA Portal:
Equipped with this information we can check if and how the “.ap15_1” extension show up in classic file use and knowledge artefacts.
Reviewing the recent files for a user, by investigating the RecentDocs key in the corresponding NTUSER.dat hive shows a subkey for the “.ap15_1” extension.
The second screenshot shows an excerpt of the “.ap15_1” key parsed by Registry Explorer. Please note, that if a project file is opened via the “Recently used” projects listing, shown on the starting view of the TIA Portal, the RecentDocs key is not updated.
While we are dealing with user specific evidence, we can also check if Jump Lists are available as we would expect. We can use the tool JLECmd by Erik Zimmermann to parse all Jump Lists and review the results in Timeline Explorer. By applying a filter to only show files ending with “.ap” we get the overview shown below.
Here you can clearly see that we can parse out entries related to “.ap15_1” files for “Quick Access” and also for an App Id not known to JLECmd. This App Id is related to the TIA Portal and we can now also identify the automatic destinations file to open or parse the specific file if we want or need. It will be “4c28c7c161e44256.automaticDestinations-ms”, in our case stored under “C:\Users\nviso\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations”. If a project is created and saved in the TIA Portal it will not show up in the Jump List. Further if you choose to open a project from the “Recently used” projects list, like described above, the Jump List of the TIA Portal will not be changed.
In figure 9 we demonstrated the potential differences between the Jump List (1.) and the “Recently used” projects in the TIA Portal (2.). Obviously the two most recent projects listed by the TIA Portal are missing in the Jump List. The “testproject12.ap15_1” file relates to an already existing project opened via the TIA Portal functionality and the “Pro_dev_C64_blast” project was created via the TIA Portal. The content of the Jump List is shown via the Windows Start menu in this example. Reviewing the Jump List with JLECmd validates these results.
The OpenSaveMRU, also user account specific evidence, is another a place where we can look for the “.ap*” file extension and review activity. Opening the NTUSER.dat for the user account in focus and following the path down to the “OpenSavePidlMRU” key already shows the subkey for a file extension of interest. As always you need to be aware of the evidence you are looking at, the OpenSaveMRU is maintained by the Windows shell dialog box, projects will be showing up here based on if they are opened or saved via the dialog box or not. Double-clicking a “.ap15_1” file will not make it show up here, luckily for us we have the Jump List and the “RecentDocs” key mentioned above. Also note, that opening a project via the “Recently used” projects lists of the TIA Portal, mentioned above in the section discussing “RecentDocs”, will not change the OpenSaveMRU.
Needless to say that you can also search the $MFT for files with the extension of interest.
A few things need to be mentioned in regards of managing expectations:
- The evidence produced by the Windows Operating System or the TIA Portal is not there for forensic or incident response investigations. It usually servers a different purpose than we are using it for. That being said, it should be understood that evidence might behave completely different after software updates or in older/newer versions of the software.
- Further it is not guaranteed that the software will produce the same evidence in any imaginable edge case.
- The blog posts are based on our observations and testing results.
Conclusion & Outlook
The standard evidences on a Windows System can already bring some good insights into activities around the TIA Portal. However, we must be aware that the TIA Portal offers its own functions for opening and creating projects, which do not update the jump list, for example. For these cases we can review the “Settings.xml” file. We will focus on the “Settings.xml” file and information we can get out of raw project files in the upcoming blog posts.
About the Author
Olaf Schwarz is a Senior Incident Response Consultant at NVISO. You can find Olaf on Twitter and LinkedIn.
You can follow NVISO Labs on Twitter to stay up to date on all out future research and publications.
3 thoughts on “Investigating an engineering workstation – Part 1”