Ssh — CraftedSignal Threat Feed

Fortra GoAnywhere MFT SSH Key Brute-Force Vulnerability (CVE-2025-14362)

hello@craftedsignal.io — Wed, 22 Apr 2026 12:00:00 +0000

CVE-2025-14362 is a vulnerability affecting Fortra’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.

Attack Chain

Attacker identifies a GoAnywhere MFT server running a version prior to 7.10.0.
Attacker determines that the GoAnywhere MFT server allows Web Users to authenticate using SSH keys.
Attacker attempts to authenticate to the SFTP service using a series of generated SSH keys.
Due to the lack of login limit enforcement, the attacker can make unlimited authentication attempts without being locked out.
The attacker continues brute-forcing SSH keys until a valid key is guessed, or an exploitable weakness is found.
Upon successful authentication, the attacker gains unauthorized access to the GoAnywhere MFT server.
The attacker can then upload/download arbitrary files, execute commands, and potentially move laterally within the network.
The final objective is to exfiltrate sensitive data or establish a persistent foothold within the target environment.

Impact

Successful 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.

Recommendation

Upgrade Fortra GoAnywhere MFT to version 7.10.0 or later to patch CVE-2025-14362 (reference: Overview).
Implement rate limiting on SSH authentication attempts at the network or host level to mitigate brute-force attacks, even after patching (reference: Attack Chain).
Monitor 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).

UniFi Play Improper Access Control Allows SSH Enablement

hello@craftedsignal.io — Mon, 13 Apr 2026 22:16:28 +0000

CVE-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).

Attack Chain

The attacker gains initial access to the UniFi Play network through unspecified means (e.g., compromised credentials, network misconfiguration, or physical access).
The 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).
The attacker exploits the improper access control vulnerability (CVE-2026-22564) by sending a crafted request to the vulnerable device.
This request bypasses access controls, enabling SSH access on the device.
The 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).
Once authenticated, the attacker executes privileged commands via the SSH shell.
The attacker modifies system configurations, installs malicious software, or exfiltrates sensitive data.
The attacker maintains persistent access to the compromised device and potentially uses it as a pivot point for further attacks within the network.

Impact

Successful 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.

Recommendation

Immediately 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.
Monitor network traffic for suspicious SSH connections to UniFi Play devices, especially from unexpected sources. Implement the provided Sigma rule targeting SSH login events.
Conduct 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.
Review and harden default credentials on all network devices, including UniFi Play devices, to prevent attackers from easily gaining access after enabling SSH.

SSH Authorized Key File Modification Inside a Container

hello@craftedsignal.io — Thu, 02 Apr 2026 12:00:00 +0000

This 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.

Attack Chain

An attacker gains initial access to a container, possibly through a software vulnerability or misconfiguration.
The attacker executes commands within the container to locate the SSH authorized_keys file (typically located at /home//.ssh/authorized_keys or /root/.ssh/authorized_keys).
The attacker modifies the authorized_keys file, adding their own SSH public key to the file using commands like echo "ssh-rsa AAAAB3Nz..." >> /root/.ssh/authorized_keys.
The attacker uses the newly added SSH key to authenticate and log into the container without needing a password.
The attacker uses the SSH session to execute further commands, potentially escalating privileges or moving laterally to other containers or systems.
The attacker maintains persistence by ensuring their SSH key remains in the authorized_keys file, allowing them to re-access the container at any time.

Impact

Successful 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’t stated, a successful attack targeting containers can affect critical cloud infrastructure and applications.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect unauthorized modifications of SSH authorized_keys files within containers (rule: SSH Authorized Key File Activity).
Enable Elastic Defend for Containers integration (minimum version 9.3.0) to provide the necessary file event data for the Sigma rule to function correctly.
Investigate any alerts generated by the Sigma rule, focusing on the process and user context of the file modifications, as outlined in the rule’s description (rule: SSH Authorized Key File Activity).
Implement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future, as recommended in the incident response section.
Create exceptions for known update processes or deployment scripts that regularly alter these files to reduce false positives, as suggested in the false positive analysis.

GitHub SSH Certificate Configuration Changed

hello@craftedsignal.io — Sat, 02 Nov 2024 14:00:00 +0000

Attackers 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 ssh_certificate_authority.create or ssh_certificate_requirement.disable 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’s resources. The GitHub audit log streaming feature must be enabled to detect this activity.

Attack Chain

Initial Compromise: An attacker gains initial access to a GitHub organization, potentially through compromised credentials or social engineering.
Privilege Escalation: The attacker escalates their privileges to an organizational role capable of managing SSH certificate authorities.
SSH Certificate Authority Creation: The attacker creates a new SSH certificate authority within the GitHub organization (ssh_certificate_authority.create).
Disable SSH Certificate Requirement: Alternatively, the attacker disables the requirement for members to use SSH certificates to access organization resources (ssh_certificate_requirement.disable). This action allows attackers to bypass security controls that enforce SSH certificate usage.
Unauthorized Access: The attacker utilizes the newly created SSH certificate authority or the disabled requirement to access repositories without proper authorization.
Lateral Movement: The attacker moves laterally within the GitHub organization, accessing additional repositories and resources.
Data Exfiltration/Malicious Code Injection: The attacker exfiltrates sensitive data or injects malicious code into the organization’s repositories.
Persistence: The attacker maintains persistent access by using the created SSH certificate authority or the disabled requirement for future unauthorized activities.

Impact

Successful 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’s access and the sensitivity of the compromised data.

Recommendation

Enable the GitHub audit log streaming feature to capture SSH certificate configuration changes (logsource: github, service: audit, definition).
Deploy the provided Sigma rule to detect ssh_certificate_authority.create or ssh_certificate_requirement.disable events in the GitHub audit logs (rule: Github SSH Certificate Configuration Changed).
Regularly review GitHub audit logs for any unauthorized modifications to SSH certificate configurations.

OpenCanary SSH Connection Attempt

hello@craftedsignal.io — Wed, 08 May 2024 14:30:00 +0000

The 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’s documentation.

Attack Chain

Initial Reconnaissance: The attacker conducts network scanning using tools like Nmap or Masscan to identify open ports and services, including SSH (port 22).
Target Identification: The attacker identifies the OpenCanary node, mistaking it for a legitimate SSH server, due to its exposed SSH port.
Connection Attempt: The attacker attempts to establish an SSH connection to the OpenCanary node using a tool like ssh or a custom script.
Authentication Probe: The attacker might attempt to authenticate using default credentials, common usernames and passwords, or brute-force techniques.
Credential 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.
Lateral Movement (Attempted): If the attacker believes they have successfully authenticated, they may attempt lateral movement to other systems within the network.
Privilege Escalation (Attempted): The attacker could attempt to escalate privileges on the “compromised” system (OpenCanary) to gain further access.
Data Exfiltration/System Damage (Prevented): Because it’s a honeypot, OpenCanary prevents actual data exfiltration or system damage but logs all attempted actions for analysis.

Impact

An 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.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect SSH connection attempts to OpenCanary nodes, focusing on logtype: 4000.
Review OpenCanary logs in conjunction with other security logs (firewall, endpoint) to correlate the SSH attempts with other suspicious activities.
Investigate the source IP addresses from which SSH connection attempts originate to identify potential threat actors.
Consult the OpenCanary documentation to ensure proper configuration of the SSH service and logging capabilities.
Use network segmentation to limit the potential impact of a successful breach, even if only simulated on the OpenCanary node.

OpenCanary SSH Login Attempt Detection

hello@craftedsignal.io — Thu, 02 May 2024 14:30:00 +0000

OpenCanary 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.

Attack Chain

The attacker gains initial access to the network, possibly through phishing, exploiting a vulnerability, or compromised credentials.
The attacker performs network scanning to identify potential targets, including the OpenCanary node masquerading as a legitimate SSH server.
The attacker attempts to establish an SSH connection to the OpenCanary node, attempting to authenticate using various usernames and passwords.
The OpenCanary service logs the failed SSH login attempt, recording the source IP address and attempted credentials.
Security monitoring tools ingest the OpenCanary logs and trigger an alert based on the detected SSH login attempt.
Security analysts investigate the alert, analyzing the source IP address and other relevant information to determine the scope and severity of the potential breach.

Impact

A 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’s source IP address and attempted usernames can provide valuable insights into their tactics and objectives, preventing damage.

Recommendation

Deploy the Sigma rule “OpenCanary - SSH Login Attempt” to your SIEM to detect unauthorized SSH login attempts on OpenCanary nodes.
Investigate and block any identified malicious source IP addresses from network access using firewall rules.
Review OpenCanary configuration to ensure it is deployed in strategically valuable network segments (references: OpenCanary documentation).
Correlate OpenCanary alerts with other security events to identify potential broader attack campaigns.