This does indeed look like an attacker gained access to one of your authentication tokens and used it to attempt to scan your server for non-Plex-related data.
From your subsequent posts (and the audit logs for your account), it looks like you’ve already taken the appropriate action to protect your account from further abuse, but I’ll reiterate them here for anyone who hasn’t seen it:
If you encounter strong signs of unauthorized access to your server, go to Account Settings on app.plex.tv and reset your password, making sure to check the “Sign out connected devices after password change” box. You should use a password manager (there’s one built into most modern web browsers, and third-party options are also available) to generate a random password, rather than creating a memorable (and potentially guessable) one. Always use a unique password; never reuse the same password across several services.
@flow, going by your audit logs, I don’t see any signs of an actual unauthorized login (and if there had been one, you would’ve received an email about it). Therefore, the compromise likely wasn’t of your password, but instead of an auth token. Unfortunately, PMS’s existing logging doesn’t provide enough information to tell us which token was compromised.
These kinds of issues are often a result of insecure third-party tools leaking tokens, but they can also be caused by a compromise of any device signed-in as your user account.
To help audit these kinds of compromises more thoroughly in the future, we’re planning on making some changes to PMS’s logging facilities in a future release:
- Logs will be improved by including the name of the device associated with the token used to authenticate each request.
- Additional restrictions will be placed on requests to reduce the server’s log level. This may mean requiring a server restart, only allowing level downgrades if the request came from the local network, and/or other additional controls (TBD). Once we’ve decided on how to move forward and made the relevant changes, PMS release notes will include details on the new restrictions.
- Certain low-usage-frequency security-critical requests (preference management, library section creation, filesystem location management…) will be logged at the
INFOlevel (rather thanDEBUG), so that logging of these requests cannot be disabled (by the user or by an attacker).
