With PRTG version 18.3.43 (stable release August 14th, 2018; in preview since July 31st), we fundamentally revised the way PRTG writes logfiles.

What are logfiles for?

If you contact our technical support to analyze an unusual behavior or monitoring problem together with us, we usually need logfiles from the PRTG system. The information from these files helps colleagues from the technical support team to better and more quickly understand what is going on in the core and the probe. Many logfiles are already included in the "Support Bundle" that you can send us from within your PRTG installation, but sometimes we also request additional files from you.

We revised our logfile system for three major reasons:

1. Our previous logging component lacked numerous technical functions.
2. A consistent format with synchronized timestamps across all files allows us to assist you in finding solutions even faster.
3. With the new system, we have paved the way to support more file systems in the future. In this context, we have also revised the way we set the access rights for all log targets.

Are there any security considerations?

Our changes to the logging system have also invalidated an attack vector that exploits a Windows vulnerability described by Microsoft:

Users who have the Create symbolic links user right could inadvertently or maliciously expose your system to symbolic link attacks. Symbolic link attacks can be used to change the permissions on a file, to corrupt data, to destroy data, or as a DoS attack.

(Source: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links)

With direct access to the machine running the PRTG server, an attacker with a local account and appropriate rights could use a "symbolic link" (symlink) to force PRTG to create a file in an arbitrary location, for example, in the notification folder, using the user context of the PRTG service (by default, SYSTEM). This could possibly have been used for a chained attack vector.

This again shows that it is absolutely crucial that PRTG administrators make sure that no untrusted users have access to the machines running PRTG services.