{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/ssh/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[{"cvss":7.3,"id":"CVE-2025-14362"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["goanywhere","mft","bruteforce","ssh"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2025-14362 is a vulnerability affecting Fortra\u0026rsquo;s GoAnywhere MFT servers prior to version 7.10.0. The vulnerability arises because the login limit is not enforced on the SFTP service when a Web User is configured to authenticate using an SSH key. This lack of enforcement allows attackers to conduct brute-force attacks against the SSH key, attempting to guess the key through repeated authentication attempts. Successful exploitation grants unauthorized access to the GoAnywhere MFT server, potentially leading to data breaches, system compromise, and other malicious activities. Defenders should prioritize patching vulnerable GoAnywhere MFT instances to version 7.10.0 or later.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker identifies a GoAnywhere MFT server running a version prior to 7.10.0.\u003c/li\u003e\n\u003cli\u003eAttacker determines that the GoAnywhere MFT server allows Web Users to authenticate using SSH keys.\u003c/li\u003e\n\u003cli\u003eAttacker attempts to authenticate to the SFTP service using a series of generated SSH keys.\u003c/li\u003e\n\u003cli\u003eDue to the lack of login limit enforcement, the attacker can make unlimited authentication attempts without being locked out.\u003c/li\u003e\n\u003cli\u003eThe attacker continues brute-forcing SSH keys until a valid key is guessed, or an exploitable weakness is found.\u003c/li\u003e\n\u003cli\u003eUpon successful authentication, the attacker gains unauthorized access to the GoAnywhere MFT server.\u003c/li\u003e\n\u003cli\u003eThe attacker can then upload/download arbitrary files, execute commands, and potentially move laterally within the network.\u003c/li\u003e\n\u003cli\u003eThe final objective is to exfiltrate sensitive data or establish a persistent foothold within the target environment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2025-14362 can lead to unauthorized access to sensitive data managed by the GoAnywhere MFT server. This could include financial records, customer data, intellectual property, and other confidential information. The number of victims is dependent on the exposure of vulnerable GoAnywhere MFT servers. Sectors commonly using MFT solutions, such as finance, healthcare, and government, are at increased risk. The impact of a successful attack can range from data breaches and financial loss to reputational damage and legal liabilities.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Fortra GoAnywhere MFT to version 7.10.0 or later to patch CVE-2025-14362 (reference: Overview).\u003c/li\u003e\n\u003cli\u003eImplement rate limiting on SSH authentication attempts at the network or host level to mitigate brute-force attacks, even after patching (reference: Attack Chain).\u003c/li\u003e\n\u003cli\u003eMonitor SFTP logs for excessive failed authentication attempts originating from the same source IP address using a Sigma rule similar to the one provided below (reference: Rules).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-22T12:00:00Z","date_published":"2026-04-22T12:00:00Z","id":"/briefs/2026-04-goanywhere-bruteforce/","summary":"Fortra's GoAnywhere MFT prior to 7.10.0 is vulnerable to brute-force attacks on SSH keys because the login limit is not enforced on the SFTP service when Web Users are configured to log in with an SSH Key.","title":"Fortra GoAnywhere MFT SSH Key Brute-Force Vulnerability (CVE-2025-14362)","url":"https://feed.craftedsignal.io/briefs/2026-04-goanywhere-bruteforce/"},{"_cs_actors":[],"_cs_cves":[{"cvss":9.8,"id":"CVE-2026-22564"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["critical"],"_cs_tags":["cve-2026-22564","unifi-play","access-control","ssh"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-22564 is a critical vulnerability affecting UniFi Play PowerAmp (version 1.0.35 and earlier) and UniFi Play Audio Port (version 1.0.24 and earlier) devices. This improper access control flaw allows a malicious actor, who has already gained access to the UniFi Play network, to enable SSH access on the affected devices. This unauthorized SSH access can then be leveraged to make arbitrary changes to the system configuration, potentially leading to full device compromise and further network exploitation. Successful exploitation requires network access to the UniFi Play devices. The vulnerability was reported by HackerOne and affects devices that have not been updated to the patched versions (PowerAmp 1.0.38 or Audio Port 1.1.9).\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the UniFi Play network through unspecified means (e.g., compromised credentials, network misconfiguration, or physical access).\u003c/li\u003e\n\u003cli\u003eThe attacker identifies vulnerable UniFi Play PowerAmp or Audio Port devices on the network running versions 1.0.35 or earlier (PowerAmp) and 1.0.24 or earlier (Audio Port).\u003c/li\u003e\n\u003cli\u003eThe attacker exploits the improper access control vulnerability (CVE-2026-22564) by sending a crafted request to the vulnerable device.\u003c/li\u003e\n\u003cli\u003eThis request bypasses access controls, enabling SSH access on the device.\u003c/li\u003e\n\u003cli\u003eThe attacker uses an SSH client (e.g., OpenSSH) to connect to the device using the enabled SSH service, likely with default or easily guessable credentials (not specified in source, but common).\u003c/li\u003e\n\u003cli\u003eOnce authenticated, the attacker executes privileged commands via the SSH shell.\u003c/li\u003e\n\u003cli\u003eThe attacker modifies system configurations, installs malicious software, or exfiltrates sensitive data.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistent access to the compromised device and potentially uses it as a pivot point for further attacks within the network.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of CVE-2026-22564 allows an attacker to gain unauthorized SSH access and make arbitrary changes to vulnerable UniFi Play devices. This can result in complete device compromise, allowing for data theft, installation of malware, and disruption of services. The vulnerability has a CVSS v3.1 score of 9.8 (Critical), indicating a high potential for severe impact. The scope of impact depends on the network configuration and the data handled by the compromised UniFi Play devices.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eImmediately update UniFi Play PowerAmp devices to version 1.0.38 or later and UniFi Play Audio Port devices to version 1.1.9 or later to patch CVE-2026-22564.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for suspicious SSH connections to UniFi Play devices, especially from unexpected sources. Implement the provided Sigma rule targeting SSH login events.\u003c/li\u003e\n\u003cli\u003eConduct a thorough review of the UniFi Play network to identify and remediate any potential initial access vectors that could be exploited to reach the vulnerable devices.\u003c/li\u003e\n\u003cli\u003eReview and harden default credentials on all network devices, including UniFi Play devices, to prevent attackers from easily gaining access after enabling SSH.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-13T22:16:28Z","date_published":"2026-04-13T22:16:28Z","id":"/briefs/2026-04-unifi-play-ssh-enable/","summary":"CVE-2026-22564 is an improper access control vulnerability in UniFi Play PowerAmp and Audio Port devices that allows an attacker with network access to enable SSH and make unauthorized system changes.","title":"UniFi Play Improper Access Control Allows SSH Enablement","url":"https://feed.craftedsignal.io/briefs/2026-04-unifi-play-ssh-enable/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["medium"],"_cs_tags":["container","persistence","lateral-movement","privilege-escalation","ssh"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eThis detection focuses on identifying malicious actors who modify SSH authorized_keys files inside containers to gain unauthorized access. SSH authorized keys are used for public key authentication, and modification of these files allows attackers to maintain persistence or move laterally within a containerized environment. The rule specifically looks for file creation and modification events of authorized_keys files within Linux-based containers. Introduced as part of the Defend for Containers integration in Elastic Stack version 9.3.0, this detection is crucial because unauthorized SSH access can lead to significant compromise within cloud environments and containerized workloads. Defenders need to be aware of unexpected SSH key modifications as indicators of compromise inside containerized environments.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker gains initial access to a container, possibly through a software vulnerability or misconfiguration.\u003c/li\u003e\n\u003cli\u003eThe attacker executes commands within the container to locate the SSH authorized_keys file (typically located at \u003ccode\u003e/home/\u0026lt;user\u0026gt;/.ssh/authorized_keys\u003c/code\u003e or \u003ccode\u003e/root/.ssh/authorized_keys\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eThe attacker modifies the authorized_keys file, adding their own SSH public key to the file using commands like \u003ccode\u003eecho \u0026quot;ssh-rsa AAAAB3Nz...\u0026quot; \u0026gt;\u0026gt; /root/.ssh/authorized_keys\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the newly added SSH key to authenticate and log into the container without needing a password.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the SSH session to execute further commands, potentially escalating privileges or moving laterally to other containers or systems.\u003c/li\u003e\n\u003cli\u003eThe attacker maintains persistence by ensuring their SSH key remains in the authorized_keys file, allowing them to re-access the container at any time.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of the authorized_keys file enables persistent, unauthorized SSH access to the compromised container. This can lead to lateral movement within the container environment, privilege escalation, data exfiltration, or further attacks on other systems. The rule aims to detect these modifications early, preventing significant damage. While the number of specific victims isn\u0026rsquo;t stated, a successful attack targeting containers can affect critical cloud infrastructure and applications.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect unauthorized modifications of SSH authorized_keys files within containers (rule: \u003ccode\u003eSSH Authorized Key File Activity\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eEnable \u003ccode\u003eElastic Defend for Containers\u003c/code\u003e integration (minimum version 9.3.0) to provide the necessary file event data for the Sigma rule to function correctly.\u003c/li\u003e\n\u003cli\u003eInvestigate any alerts generated by the Sigma rule, focusing on the process and user context of the file modifications, as outlined in the rule\u0026rsquo;s description (rule: \u003ccode\u003eSSH Authorized Key File Activity\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003eImplement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future, as recommended in the incident response section.\u003c/li\u003e\n\u003cli\u003eCreate exceptions for known update processes or deployment scripts that regularly alter these files to reduce false positives, as suggested in the false positive analysis.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-02T12:00:00Z","date_published":"2026-04-02T12:00:00Z","id":"/briefs/2026-04-ssh-authorized-keys-modification-inside-a-container/","summary":"The rule detects the creation or modification of an authorized_keys file inside a container, a technique used by adversaries to maintain persistence on a victim host by adding their own public key(s) to enable unauthorized SSH access for lateral movement or privilege escalation.","title":"SSH Authorized Key File Modification Inside a Container","url":"https://feed.craftedsignal.io/briefs/2026-04-ssh-authorized-keys-modification-inside-a-container/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["Github"],"_cs_severities":["medium"],"_cs_tags":["github","ssh","certificate","initial-access","persistence","privilege-escalation","stealth","t1078.004"],"_cs_type":"advisory","_cs_vendors":["Github"],"content_html":"\u003cp\u003eAttackers can abuse SSH certificate authorities in GitHub to gain unauthorized access to repositories. By creating or disabling SSH certificate requirements, attackers can bypass existing security controls and establish persistent access. This activity is logged in the GitHub audit logs, specifically when \u003ccode\u003essh_certificate_authority.create\u003c/code\u003e or \u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e actions are performed. Successful exploitation allows attackers to commit malicious code, steal sensitive data, or disrupt development workflows, impacting the integrity and confidentiality of the organization\u0026rsquo;s resources. The GitHub audit log streaming feature must be enabled to detect this activity.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Compromise:\u003c/strong\u003e An attacker gains initial access to a GitHub organization, potentially through compromised credentials or social engineering.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation:\u003c/strong\u003e The attacker escalates their privileges to an organizational role capable of managing SSH certificate authorities.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSSH Certificate Authority Creation:\u003c/strong\u003e The attacker creates a new SSH certificate authority within the GitHub organization (\u003ccode\u003essh_certificate_authority.create\u003c/code\u003e).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDisable SSH Certificate Requirement:\u003c/strong\u003e Alternatively, the attacker disables the requirement for members to use SSH certificates to access organization resources (\u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e). This action allows attackers to bypass security controls that enforce SSH certificate usage.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUnauthorized Access:\u003c/strong\u003e The attacker utilizes the newly created SSH certificate authority or the disabled requirement to access repositories without proper authorization.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLateral Movement:\u003c/strong\u003e The attacker moves laterally within the GitHub organization, accessing additional repositories and resources.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eData Exfiltration/Malicious Code Injection:\u003c/strong\u003e The attacker exfiltrates sensitive data or injects malicious code into the organization\u0026rsquo;s repositories.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePersistence:\u003c/strong\u003e The attacker maintains persistent access by using the created SSH certificate authority or the disabled requirement for future unauthorized activities.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful modification of SSH certificate configurations in GitHub can lead to unauthorized code commits, data breaches, and supply chain attacks. This could result in financial losses, reputational damage, and legal repercussions for the affected organization. The number of affected repositories and the severity of the impact depend on the scope of the attacker\u0026rsquo;s access and the sensitivity of the compromised data.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eEnable the GitHub audit log streaming feature to capture SSH certificate configuration changes (logsource: github, service: audit, definition).\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect \u003ccode\u003essh_certificate_authority.create\u003c/code\u003e or \u003ccode\u003essh_certificate_requirement.disable\u003c/code\u003e events in the GitHub audit logs (rule: Github SSH Certificate Configuration Changed).\u003c/li\u003e\n\u003cli\u003eRegularly review GitHub audit logs for any unauthorized modifications to SSH certificate configurations.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-11-02T14:00:00Z","date_published":"2024-11-02T14:00:00Z","id":"/briefs/2024-11-github-ssh-cert-config-changed/","summary":"Attackers can modify SSH certificate configurations in GitHub organizations to gain unauthorized access, persist in the environment, escalate privileges, and operate stealthily.","title":"GitHub SSH Certificate Configuration Changed","url":"https://feed.craftedsignal.io/briefs/2024-11-github-ssh-cert-config-changed/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["OpenCanary"],"_cs_severities":["high"],"_cs_tags":["honeypot","ssh","reconnaissance"],"_cs_type":"advisory","_cs_vendors":["Thinkst"],"content_html":"\u003cp\u003eThe OpenCanary SSH Connection Attempt alert signifies that an SSH service on a deployed OpenCanary node has received a connection attempt. OpenCanary is a low-interaction honeypot designed to detect reconnaissance and lateral movement activities within a network. This event, logged as logtype 4000 by default, suggests that an attacker is actively scanning for or attempting to exploit SSH services. This alert is crucial for defenders because OpenCanary nodes are deliberately placed to attract malicious activity, meaning any interaction is highly suspicious. The alert helps identify potential breaches early, allowing security teams to respond quickly. The configuration of services monitored by OpenCanary is detailed in the project\u0026rsquo;s documentation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eInitial Reconnaissance: The attacker conducts network scanning using tools like Nmap or Masscan to identify open ports and services, including SSH (port 22).\u003c/li\u003e\n\u003cli\u003eTarget Identification: The attacker identifies the OpenCanary node, mistaking it for a legitimate SSH server, due to its exposed SSH port.\u003c/li\u003e\n\u003cli\u003eConnection Attempt: The attacker attempts to establish an SSH connection to the OpenCanary node using a tool like \u003ccode\u003essh\u003c/code\u003e or a custom script.\u003c/li\u003e\n\u003cli\u003eAuthentication Probe: The attacker might attempt to authenticate using default credentials, common usernames and passwords, or brute-force techniques.\u003c/li\u003e\n\u003cli\u003eCredential Compromise (Simulated): The OpenCanary node logs the failed or successful (simulated) login attempt, triggering the alert. OpenCanary may simulate a successful login for further interaction logging.\u003c/li\u003e\n\u003cli\u003eLateral Movement (Attempted): If the attacker believes they have successfully authenticated, they may attempt lateral movement to other systems within the network.\u003c/li\u003e\n\u003cli\u003ePrivilege Escalation (Attempted): The attacker could attempt to escalate privileges on the \u0026ldquo;compromised\u0026rdquo; system (OpenCanary) to gain further access.\u003c/li\u003e\n\u003cli\u003eData Exfiltration/System Damage (Prevented): Because it\u0026rsquo;s a honeypot, OpenCanary prevents actual data exfiltration or system damage but logs all attempted actions for analysis.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eAn SSH connection attempt on an OpenCanary node, while not directly causing damage, indicates active reconnaissance or attempted unauthorized access within the network. The number of alerts generated can highlight the frequency of malicious scans targeting SSH services. Successful exploitation (simulated on the honeypot) could lead to lateral movement, privilege escalation, and data exfiltration if the attacker were to compromise a real system. This activity is valuable for understanding attacker behavior and improving overall security posture.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the provided Sigma rule to your SIEM to detect SSH connection attempts to OpenCanary nodes, focusing on \u003ccode\u003elogtype: 4000\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eReview OpenCanary logs in conjunction with other security logs (firewall, endpoint) to correlate the SSH attempts with other suspicious activities.\u003c/li\u003e\n\u003cli\u003eInvestigate the source IP addresses from which SSH connection attempts originate to identify potential threat actors.\u003c/li\u003e\n\u003cli\u003eConsult the OpenCanary documentation to ensure proper configuration of the SSH service and logging capabilities.\u003c/li\u003e\n\u003cli\u003eUse network segmentation to limit the potential impact of a successful breach, even if only simulated on the OpenCanary node.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-08T14:30:00Z","date_published":"2024-05-08T14:30:00Z","id":"/briefs/2024-05-opencanary-ssh-attempt/","summary":"An SSH connection attempt to an OpenCanary node indicates a potential adversary probing for vulnerable services or attempting unauthorized access within a network.","title":"OpenCanary SSH Connection Attempt","url":"https://feed.craftedsignal.io/briefs/2024-05-opencanary-ssh-attempt/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":["OpenCanary"],"_cs_severities":["high"],"_cs_tags":["honeypot","ssh","initial-access"],"_cs_type":"advisory","_cs_vendors":["thinkst"],"content_html":"\u003cp\u003eOpenCanary is a low-interaction honeypot designed to detect attackers on a network. This brief focuses on detecting SSH login attempts on OpenCanary nodes, which are designed to mimic real SSH servers but log any interaction. While the OpenCanary project itself has been around for several years, its integration with modern detection strategies makes it a valuable tool for defenders. An SSH login attempt against an OpenCanary instance signifies that an attacker is actively scanning or attempting to compromise systems within the network. This activity might be part of a broader campaign, including lateral movement, privilege escalation, or data exfiltration. The detection of such attempts allows for timely incident response and mitigation.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eThe attacker gains initial access to the network, possibly through phishing, exploiting a vulnerability, or compromised credentials.\u003c/li\u003e\n\u003cli\u003eThe attacker performs network scanning to identify potential targets, including the OpenCanary node masquerading as a legitimate SSH server.\u003c/li\u003e\n\u003cli\u003eThe attacker attempts to establish an SSH connection to the OpenCanary node, attempting to authenticate using various usernames and passwords.\u003c/li\u003e\n\u003cli\u003eThe OpenCanary service logs the failed SSH login attempt, recording the source IP address and attempted credentials.\u003c/li\u003e\n\u003cli\u003eSecurity monitoring tools ingest the OpenCanary logs and trigger an alert based on the detected SSH login attempt.\u003c/li\u003e\n\u003cli\u003eSecurity analysts investigate the alert, analyzing the source IP address and other relevant information to determine the scope and severity of the potential breach.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eA successful SSH login attempt on a real server could lead to complete system compromise, data exfiltration, and disruption of services. While OpenCanary is designed to be a honeypot, detecting login attempts early allows for proactive measures to prevent attackers from reaching critical assets. Identifying the attacker\u0026rsquo;s source IP address and attempted usernames can provide valuable insights into their tactics and objectives, preventing damage.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026ldquo;OpenCanary - SSH Login Attempt\u0026rdquo; to your SIEM to detect unauthorized SSH login attempts on OpenCanary nodes.\u003c/li\u003e\n\u003cli\u003eInvestigate and block any identified malicious source IP addresses from network access using firewall rules.\u003c/li\u003e\n\u003cli\u003eReview OpenCanary configuration to ensure it is deployed in strategically valuable network segments (references: OpenCanary documentation).\u003c/li\u003e\n\u003cli\u003eCorrelate OpenCanary alerts with other security events to identify potential broader attack campaigns.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2024-05-02T14:30:00Z","date_published":"2024-05-02T14:30:00Z","id":"/briefs/2024-05-opencanary-ssh-login/","summary":"Detects instances where an SSH service on an OpenCanary node has had a login attempt, indicating potential reconnaissance, privilege escalation, or lateral movement.","title":"OpenCanary SSH Login Attempt Detection","url":"https://feed.craftedsignal.io/briefs/2024-05-opencanary-ssh-login/"}],"language":"en","title":"CraftedSignal Threat Feed — Ssh","version":"https://jsonfeed.org/version/1.1"}