Your Canary's file share service doesn't rely on user accounts — it accepts any credentials to catch attackers searching for data in your network.
Under the hood, this works by mapping all authentication attempts to a "guest" session.
You may have run into issues when trying to connect to your Canary's share and wondered why that happens.
Recent versions of Windows prevent end users from mounting remote file shares using a "guest" session and instead requires a valid account to be authenticated against.
While this policy doesn't affect attacker tools or Linux clients, it does prevent Windows users from accessing the share directly.
How can I tell if this affects me?
This can be easily checked by trying to browse to your Canary's fileshare.
You can map a Canary's file share from a Windows computer using either the GUI:
Or through the command line:
If you're prompted with an error mentioning unauthenticated guest access policies, then you're affected by this.
What now?
The easiest fix for this, is to simply Domain Join your Canary. A domain joined Bird makes it easier for attackers to discover your honeypot, as well as enables seamless authentication for your domain users to browse the Canary's share.
Alternatively, if domain joining your Canary is not feasible, feel free to reach out to support here, who can enable a few user accounts onto your Canary's fileshare.
This means that the fileshare service will continue to behave as usual, however will also accept specific user credentials of your choice which map to a real "user" and allow access to the fileshare.
Limitations:
- There is a limit of 10 user accounts per Canary.
- All accounts must share the same password.