Thinkst Canary¶
Thinkst Canary is a deception technology chosen by Cyderes to augment security programs with high fidelity detection points that can be spread across environments. Cyderes recommends Canaries be deployed and configured throughout the network -- these can be hardware, virtual, or cloud-based birds.
Why Use a Thinkst Canary¶
Most companies discover they’ve been breached way too late. Thinkst Canary fixes this: just three minutes of setup; no ongoing overhead; nearly zero false positives, and attackers can be detected long before they dig in.
Scope and Sizing¶
Thinkst Canaries come in packs of five or more of either hardware, virtual, or cloud-based deployments. There’s no limit on Canarytokens. Both Canaries and Canarytokens can be created in groups called Flocks.
Please Note: Cyderes will not respond to alerts in a flock that contains the words test or dev
What Canaries Are¶
Canaries can be physical devices but they aren't just hardware devices. Virtualized Canaries can be ran inside virtual infrastructure with the same features that a physical Canary brings.
Virtual Canary Requirements: All that's needed for a fully functioning bird:
- A valid Canary license
- Disk space larger than 10GB
- 2GB memory
- Single CPU core
What Canarytokens Are¶
As a Canary customer, free Canarytokens are available and generated alerts will show up in the console like any other. Canarytokens are a simple way to tripwire things. An old concept, they can be super useful (and are trivial to use) but require some background infrastructure to get working. This infrastructure is provided so tokens can be deployed in seconds and provide immediate benefit.
Web bugs are transparent images which track when someone opens an email. They work by embedding a unique URL in a page's image tag, and monitoring incoming GET requests.
Imagine doing that but for file reads, database queries, process executions or patterns in log files. Canarytokens do all this and more, allowing traps to be implanted in production systems rather than setting up separate honeypots.
How Thinkst Canaries Work¶
Order, configure and deploy Canaries throughout the network. Make one a Windows file server, another a router, and throw in a few Linux web servers. Each one hosts realistic services and looks and acts like its namesake.
Then, wait. Thinkst Canaries run in the background, waiting for intruders. Attackers prowling a target network look for juicy content. They browse Active Directory for file servers and explore file shares looking for documents, try default passwords against network devices and web services, and scan for open services across the network. When they encounter a Thinkst Canary, the services on offer are designed to solicit further investigation, at which point they’ve betrayed themselves, and the Canary will notify of an incident.
How Thinkst Canaries Communicate¶
Canaries are deployed inside the network and communicate with the hosted console through DNS. This means the only network access the Canary needs is to a DNS server that's capable of external queries, which is much less work than configuring border firewall rules for each device.
How Users Access the Canary Console¶
- Log into Cyderes Okta using email address and password
- Click on Canary
Canary Console¶
Each customer gets their own hosted management console which allows settings to be configured, Thinkst Canaries to be managed, and events to be handled.
Thinkst Canaries constantly report in and provide an up-to-the-minute report on their status (this is not another pane of glass that needs to be constantly monitored). Even customers with hundreds of Canaries receive just a handful of events per year. When an incident occurs, Thinkst can alert via email, text message, slack notification, webhook or old-fashioned syslog. These alerts are also sent over to Cyderes for Cyderes analysts to work as they are generated. Internal security teams can be contacted about relevant alerts as well.
Canary Deployment¶
Thinkst Canaries can be deployed with a number of different "personalities" to emulate common services in an environment.
Connectivity Requirements¶
| Destination | Port | Direction |
|---|---|---|
| *.cnr.io | TCP/53 UDP/53 | External Outbound |
Also validate connectivity to any services the Canary will listening on.
Canary Use Cases¶
Here are some favorite deployments for Canaries that can fit many situations:
Terminal Server (RDP)¶
- Canary type: Virtual
- Services: Windows File Share, RDP and Port Scan Detection
- Location: Data Center
- Details: This canary should should be placed on a network segment with other like devices. Device name, description, and comments should resemble other devices in the segment.
Domain Controller¶
- Canary type: Virtual
- Services: Windows File Share, WinRM, RDP, LDAP, Port Scan Detection and Custom TCP Ports (53, 88, 135, 389, 464, 593, 636, 3268, 3269)
- Location: Data Center
- Details: This canary should be placed on a network segment with other like devices. Device name, description, and comments should resemble other devices in the segment.
Cisco 1921 Router¶
- Canary type: Physical
- Services: Telnet, SSH, Web Server and Port Scan Detection
- Location: DMZ, Data Center and Office Locations
- Details: This canary can be placed on a network segment with other like devices. Device name, description, and comments should resemble other devices in the segment.
Windows Server 2016 Web Server¶
- Canary type: Virtual
- Services: HTTP, IIS, RDP, Windows File Share and Port Scan Detection
- Location: DMZ, Data Center
- Details: This canary should be placed alongside existing public facing website and be configured to match server settings as closely as possible.
Windows 10 Desktop Fileshare¶
- Canary type: Virtual
- Services: Windows File Share, RDP and Port Scan Detection
- Location: Corporate or Remote Office
- Details: The canary should be deployed embedded within the client segment at a corporate or remote office.
Standard Linux Server¶
- Canary type: Virtual
- Services: SSH, Telnet, VNC and Port Scan Detection
- Location: Data Center
- Details: This canary should be placed alongside existing servers with similar configurations and service availability.
NAS File Server¶
- Canary type: Virtual
- Services: NFS (Unix), SMB (Windows) and Port Scan Detection
- Location: Data Center or Remote Office
- Details: Device should be placed within the storage environment. Device name, share name, description, and comments should resemble other storage devices in the segment.
Windows Server 2012 Office Fileshare¶
- Canary type: Virtual
- Services: Windows File Share, RDP and Port Scan Detection
- Location: Data Center
- Details: This canary should be placed within the file sharing segment. Computer name, share name, description and comments should resemble other file shares in the segment.
SCADA Device¶
- Canary type: Physical
- Services: Modbus and Port Scan Detection
- Location: Corporate Office or Data Center
- Details: This canary should be placed alongside SCADA devices with similar configurations and service availability.
Linux Database¶
- Canary type: Virtual
- Services: SSH, MySQL and Port Scan Detection
- Location: DMZ or Data Center
- Details: This canary should be placed alongside an existing database server driving the public facing customer site. Alternative configurations should be considered if the platform is not currently running on MySQL.
Scheduling a Canary Demo¶
To schedule a Canary demo, use the following link: