In this second post we will focus on specific evidence written by the TIA Portal. As you might remember, in the first part we covered standard Windows-based artefacts regarding execution of the TIA Portal and usage of projects.
The TIA Portal maintains a file called “Settings.xml” under the following path: C:\Users\$USERNAME\AppData\Roaming\Siemens\Portal V15_1\Settings\. Please remember we used version 15.1 only. The path contains the version number for the TIA Portal, so at least the path will most likely change for different versions. It is also possible that the content and the behaviour of the nodes discussed below changes with different versions of the TIA Portal.
The file can be investigated with a text editor of your choice as it has a plain XML structure. Many nodes contain readable strings, although there are some exceptions that contain encoded binary data.
A few nodes are of specific interest:
- “LastOpenedProject”
- “LRUProjectStorageLocation”
- “LRUProjectArchiveStorageLocation”
- “LastProjects”
- “ConnectionServices”
- “LoadServices”
We will look at each of these nodes, what information they contain and how they behaved in our testing. As the file is present for a specific user, everything in it is related to that specific user account. So if we state that some information represents the last opened project, it is meant for the specific user the Settings.xml file belongs to and not globally for the entire system.
LastOpenedProject
Description
This node is located under the SettingNode named “General” and contains one child node. As you can see from the screenshot above, this child node is a full path to an “.ap15_1” file. As the name already implies, this is the last project opened with the TIA Portal. In this example the project root folder is “testproject_09”, the storage location of the project is located at “C:\Users\nviso\Documents\Automation\” and the file used to open the project “testproject_09.ap15_1”.
Content
Last opened project
Behaviour
- If the TIA Portal is opened and closed without opening a project, the child note will be empty. This also represents exactly what happened: no project was opened.
- The value is not affected if a project is removed from the recently used projects in the TIA Portal. Removing a project from this list is a native build in function of the TIA Portal.
LRUProjectStorageLocation
Description
This node is located under the SettingNode named “General”, as a neighbour of the “LastOpenenProject” node we discussed earlier. It also contains only one child node representing the path to the location where the most recently opened project is located. More precisely to the location of the root folder of the project.
Content
Path to folder containing the most recently opened project
Behaviour
- The value of the child node is not affected if the TIA Portal is opened & closed without opening any project.
- The value is not affected if a project is removed from the recently used projects in the TIA Portal.
LRUProjectArchiveStorageLocation
Description
This node is located under the SettingNode named “General”, as a neighbour of the “LastOpenenProject” node we discussed earlier. If a project file is opened in the TIA Portal and the archive function is used (Main menu bar: Project -> Archive…) the full path to the folder specified in the “Target path” field is written to this value.
Content
Full path to the most recent folder specified to archive a project.
Behaviour
- The value is overwritten if a different location is chosen while archiving a project.
- Unless the archive function is used, the node is not present in the “Settings.xml” file.
LastProjects
Description
The “LastProjects” node is a child node of the SettingsNode named “ProjectSettings”. The “ProjectSettings” node is located at the same level as the “General” node discussed earlier. As shown in the excerpt above, the node contains a list of full path entries for “.apXX” files. This list shows the opened projects represented in chronological order, with the most recent project on top.
Content
Chronological orders list of opened projects
Behaviour
- The content of this node is not affected when the TIA Portal is opened and closed without opening a project.
- If a project is removed from the list of recently used projects, the corresponding “String” node containing the full path to the project is removed from the list. The chronological order will still be intact afterwards.
- Entries in this list are unique. If a project already present in the list is opened again, the entry will be moved to the top position.
- In our testing we have seen 10+ child nodes for opened projects. We did not test for a maximum value of projects that are tracked in the “LastProjects” node.
- If a new project is created and saved in the TIA Portal, it will show up in this list, but not show up in the Jump List. (We covered this in part 1 of the series)
ConnectionService
Description
The “ConnectionService” node is a neighbour of the “ProjectSettings” and the “General” node. It contains child nodes named after the full path of projects. These child nodes can contain the creation date and time of the project in UTC, stored in a child node called “CreationTime”. Further they can contain a child node called “ControllerConfiguration” which might have several child nodes for configured PLCs. Theses PLC nodes (“{1052700-1391}” in the example above) shows information how to communicate with the PLC, in the node named “OamAddress”. As demonstrated in the screenshot the “OamAddress” node can give us information like the IP-Address and subnet-mask used to reach the PLC.
Content
List of projects that were worked on within the TIA Portal. Under certain circumstances creation time of the project in UTC and connection information for configured PLCs is shown.
Behaviour
- The content of this node and its child’s is not affected when the TIA Portal is opened and closed without opening a project.
- The content of this node and its child’s is not affected if a project is removed from the recently used projects in the TIA Portal.
- A “SettingNode” entry for a specific project is not added directly after an empty project is created, neither is it added when an empty project is re-open again.
- A “SettingNode” including the project creation timestamp in UTC is created when you start to configure the project, for example by adding a PLC to it.
- The creation timestamp is taken from within the project, so if a project file is copied to a different host and opened there, the creation date and time of the original project is listed.
- The “SettingNode” for a specific project is extended with a “SettingNode” named “ControllerConfiguration” if communication with a configured PLC has been performed, in example using the “go online” function or downloading logic to the PLC.
- If multiple PLCs are configured, the “ControllerConfiguration” node contains multiple child nodes representing the configuration for each of the PLCs.
- Our testing has shown that the child nodes containing the information per PLC are not randomly named. If the same PLC is used in multiple projects, the node will get the same name. Applying this to our example above means, that if the PLC is added to three different projects, you will find a SettingNode named “{1052700-1391}” in all three “ControllerConfiguration” sections. Of cause only if the conditions to write a “ControllerConfiguration” are met.
- If a PLC is removed from a project, the corresponding child node under “ControllerConfiguration” is not removed.
LoadServices
Description
The “LoadService” node is a neighbour of the “ProjectSettings” and the “General” node. It contains child nodes named after the full path of projects. As shown above, the child nodes given an ID as name, like we already saw within the “ConnectionServices” section.
Content
List of projects that were worked on within the TIA Portal.
Behaviour
- The content of this node and its child’s is not affected when the TIA Portal is opened and closed without opening a project.
- The content of this node and its child’s is not affected if a project is removed from the recently used projects in the TIA Portal.
- A project will only show up under “LoadServices” if a PLC is added to the project and configuration is done to communicate with the PLC, like setting an IP-Address to its interface.
- According to our testing, the child nodes of a project node under “LoadServices” are not randomly named and behave the same way as mentioned in the “ConnectionServices” section. The screenshot above shows the same PLC added to two different projects. The name does not match with the named assigned for a PLC in the “ConnectionServices” node section.
- If a PLC is removed from a project, the corresponding child node under “LoadService” is not removed.
- If a complete project, with PLCs configured is copied to a different location on the same machine, opened and an interaction to the PLC is initiated with the “go online” function, no additional entry in the “LoadService” section for the copied project is created. If the IP-Address configuration for the PLC is changed in the project, an entry will be created though. At the moment it is unclear why this happens. A theory could be that the configuration of the IP-Address creates the entry and the first interaction with the PLC just updates the entry if it exists. If it does not find a matching entry nothing is done.
Tool
Manually searching in .xml files and highlighting the important notes is a cumbersome process. In order to provide some help for extracting the interesting parts of a “Settings.xml” file I took the liberty and created a small python tool. You can download the tool from my GitHub repository.
By invoking it with the command below, the discussed nodes are extracted:
python3 ./parse_tSettings.py -f PATH_TO_SETTINGS.XML
At the end of this second blog post some general notes on the “Settings.xml” file. This file belongs to the user, no additional privileges would be needed to change or delete the file. If you delete the file and start the TIA Portal, it will automatically create a fresh “Settings.xml” file. So it seems pretty easy to manipulate or clean this file. Still the user (or the adversary) first needs to be aware that this file exists and which information it stores! The file is written as part of the tasks performed when the TIA Portal is closed normally. If the TIA portal crashes, or the process get killed by other means, the file will not be updated.
Conclusion & Outlook
In this second part we have shown that the “Settings.xml” does store valuable information and should be considered when analysing machines running the TIA portal. Further we have introduced a free tool to extract this data and as a small bonus a KAPE target to collect the “Settings.xml” file.
In the third part of this series of blog posts, we will have a look at what data we can extract from projects created with the TIA Portal.
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.