Your Canary's fileshare service doesn't use any user accounts and instead is able to accept any set of credentials to catch attackers looking for data in your network.
Under the hood, this works by mapping any authentication attempts to a "guest" session.
You may have run into trouble when trying to connect to your Canary's share, and wondering why is that?
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 tooling and linux clients from connecting, it does prevent your Windows users from being able to access the share.
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@canary.tools 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.