{
	"id": "b9610e0a-7d62-4703-b807-15ddd00cf537",
	"created_at": "2026-04-06T00:19:26.772841Z",
	"updated_at": "2026-04-10T03:27:57.410915Z",
	"deleted_at": null,
	"sha1_hash": "9e3d0045c0e530b3e98c0a529b1ea42df83cec5a",
	"title": "Huntress Threat Advisory: The Dangers of Storing Unencrypted Passwords",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1770773,
	"plain_text": "Huntress Threat Advisory: The Dangers of Storing Unencrypted\r\nPasswords\r\nBy Michael Elford, Chad Hudson\r\nPublished: 2025-09-15 · Archived: 2026-04-05 22:35:57 UTC\r\nTL;DR: The threat actor entered through the organization’s SonicWall device. When searching through the host,\r\nthe threat actor found a plaintext file on the user’s desktop that contained the client's Huntress recovery codes. The\r\nthreat actor then used these codes to enter the client’s Huntress portal and began remediating reports and\r\nuninstalling hosts isolated by Huntress. \r\nKey takeaway: Avoid storing recovery codes or credentials in easily accessible plaintext files. Doing so\r\nsignificantly increases the risk of credential compromise, allowing threat actors to pivot to other platforms within\r\nthe organization. Not all services have safeguards in place to mitigate the impact of compromised accounts,\r\npotentially exposing the organization to further harm.\r\nFigure 1: Path of the observed attack\r\nWhat happened?\r\nhttps://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nPage 1 of 9\n\nThe Huntress APAC region’s Security Operations Center (SOC) detected multiple administrative users executing\r\ncommands to delete shadow copies across multiple hosts within an organization. Upon identifying this suspicious\r\nactivity, analysts initiated a mass isolation response to ensure the threat was contained and to prevent further\r\ncompromise.\r\nThe running process of the Akira ransomware binary w.exe from the user's desktop allowed the workstation to be\r\nencrypted. However, the deployment of mass isolation for containment hindered the entire environment from\r\nbeing encrypted.\r\nTriaging SOC analyst Michael confirmed through event log analysis that the affected user accounts were accessed\r\nfrom internal IP addresses in the 192.168.x.x range. These IPs didn't have a Huntress agent installed, likely\r\nbecause they were assigned via DHCP to systems controlled by the Akira threat actors following their compromise\r\nof the organization’s SonicWall VPN.\r\nThis technique is commonly used by threat actors to bypass endpoint detection and response (EDR) solutions. By\r\ngaining access through a corporate VPN, threat actors blend in with legitimate internal network traffic, often\r\nappearing as trusted users from sanctioned IP ranges.\r\nSince EDR agents are typically deployed only on known managed endpoints, any rogue systems introduced via\r\nVPN that lack the agent remain invisible to the EDR. Additionally, activity originating from a VPN-assigned IP\r\ncan appear as if it's coming from a valid internal source, hindering anomaly-based detections and allowing threat\r\nactors to move laterally without immediately raising red flags.\r\nAt this stage, the Huntress SOC issued a formal incident report to the organization, outlining the suspicious\r\nactivity observed and identifying the SonicWall VPN compromise as the likely root cause of the intrusion. The\r\nreport also provided justification for the immediate mass isolation response. Its purpose was to inform the\r\norganization of the threat and guide them through the initial phases of incident response and containment.\r\nFollowing the report, SOC analysts collaborated with the Threat Hunting \u0026 Response team to conduct a deeper\r\nanalysis of the activity and extent of the compromise. Their objective was to provide the partner with\r\ncomprehensive context and actionable intelligence regarding the active threat within their environment.\r\nCertificate export and abuse?\r\nWhile investigating the Domain Controller (DC), analysts observed that a compromised user executed commands\r\nto enumerate and export certificates from the local certificate store. Specifically, the attacker accessed the My\r\n(Personal) certificate store using the following command:\r\ncertutil -store My\r\nThis command will list certificates stored under the current user or the machine’s personal certificate store. These\r\ncertificates may potentially contain sensitive keys used for authentication, encryption, or signing.\r\nShortly after, the attacker exported a certificate identified by its thumbprint\r\n(1d967729be08ef8c4bf86874c9542b4e) to both C:\\temp\\cert.pfx and C:\\cert.pfx using:\r\ncertutil -exportPFX 1d967729be08ef8c4bf86874c9542b4e C:\\temp\\cert.pfx\r\nhttps://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nPage 2 of 9\n\ncertutil -exportPFX 1d967729be08ef8c4bf86874c9542b4e C:\\cert.pfx\r\nNote: Exporting a certificate in PFX format includes both the public and private keys. If the certificate is used for\r\nuser or device authentication (e.g., VPN or RDP with certificate-based auth), its compromise could allow threat\r\nactors to impersonate legitimate users or machines. This is a common post-exploitation tactic that enables\r\ncredential theft and lateral movement, especially in environments leveraging certificate-based authentication.\r\nThis activity is a strong indicator of a threat actor preparing for persistent access or further privilege escalation.\r\nHowever, we were unable to identify the root cause of this activity during the incident. \r\nHuntress recovery code plaintext\r\nAnalysts observed the threat actor actively enumerating administrative shares from the DC, likely in search of\r\nsensitive data for exfiltration. During this activity, the actor accessed a plaintext file containing Huntress recovery\r\ncodes located on an internal security engineer’s desktop.\r\n\"C:\\windows\\system32\\NOTEPAD.EXE\" \\\\192.168.1.51\\c$\\Users\\\u003credacted\u003e\\Desktop\\Huntress_recovery_codes-\r\n\u003credacted\u003e.txt\r\nThese recovery codes serve as a backup method for bypassing multi-factor authentication (MFA) and regaining\r\naccount access. If compromised, they effectively allow an attacker to circumvent MFA entirely, impersonate the\r\nlegitimate user, and gain full access to the Huntress console, significantly increasing the risk of further\r\ncompromise or tampering with detection and response capabilities.\r\nSuspicion of foul play\r\nWhile triaging the environment and collaborating with SOC Support, analysts noticed unusual activity tied to a\r\nsecurity engineer account that had begun resolving active incident reports via the Huntress portal. \r\nFigure 2: Immediate remediation of incident reports by a security engineer account\r\nhttps://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nPage 3 of 9\n\nGiven the context of the ongoing compromise, this behavior appeared anomalous and prompted immediate\r\noutreach to the partner.\r\nFigure 3: Partner outreach and initial concern raised\r\nSOC analysts quickly escalated their concerns to internal Huntress Support, flagging the suspicious remediations\r\nand correlating them with prior findings.\r\nShortly after the outreach, Huntress Support received confirmation from the partner: the activity attributed to the\r\nsecurity engineer account was not performed by their personnel. This revelation confirmed the threat actor had\r\nleveraged compromised credentials and recovery codes to access the Huntress portal.\r\nhttps://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nPage 4 of 9\n\nFigure 4: Confirmation of foul play\r\nWith this confirmed knowledge, the Huntress team reviewed portal activity. This analysis revealed that a known\r\nmalicious IP address, 104.238.221[.]69, previously associated with other SonicWall-related compromises, had\r\nsuccessfully accessed the Huntress portal using the compromised recovery codes.\r\nhttps://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nPage 5 of 9\n\nhttps://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nPage 6 of 9\n\nFigure 5: Huntress portal logon for the security engineer's account\r\nThis activity led to the threat actor manually closing active incident reports to suppress visibility and hinder the\r\npartner’s response. They tasked the de-isolation and the removal of Huntress agents from compromised systems.\r\nFigure 6: Recently Uninstalled Agents (last seven days) at the time of the incident\r\n   Figure 7: The path of uninstallation of the agents through the portal\r\nThis sequence of events underscores the importance of properly securing all forms of authentication mechanisms,\r\nparticularly recovery codes, which are often overlooked as “backup” credentials. In many systems, recovery\r\nhttps://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nPage 7 of 9\n\ncodes are designed to bypass MFA in situations where users lose access to their primary authentication device\r\n(e.g., a phone or hardware token). However, when improperly stored, these codes become a single point of failure\r\nand grant full access with no secondary challenge.\r\nIn this incident, the attacker’s ability to enumerate and access recovery codes in plaintext allowed them to:\r\nBypass MFA completely\r\nImpersonate a privileged user\r\nAccess the Huntress portal undetected\r\nSuppress incident visibility by closing alerts\r\nAttempt to remove endpoint protections (EDR)\r\nThe dangers of credentials stored in plaintext\r\nStoring credentials and recovery codes in plaintext and in an easily accessible location poses significant security\r\nrisks (ones that Huntress has seen time and again). Once obtained, these credentials give a threat actor the ability\r\nto compromise hosts within the network and access third-party applications and critical security platforms. This\r\nlevel of access can be weaponized to disable defenses, manipulate detection tools, and execute further malicious\r\nactions.\r\nIn this incident, the attacker used exposed Huntress recovery codes to log into the Huntress portal, close active\r\nalerts, and initiate the uninstallation of Huntress EDR agents, effectively attempting to blind the organization’s\r\ndefenses and leave it vulnerable to follow-on attacks. \r\nIt’s important to mitigate these risks. Organizations should treat recovery codes with the same sensitivity as\r\nprivileged account passwords. Here are some recommended practices for securing recovery codes and credentials.\r\nAvoid plaintext storage: Don’t save recovery codes in unprotected text files, shared drives, or unsecured\r\nfolders.\r\nUse a password manager: Store recovery codes and credentials in an encrypted password manager with a\r\nstrong passphrase (and without autofill).\r\nEncrypt offline storage: If you're unable to use digital password managers, store codes in an encrypted,\r\npassword-protected file on an encrypted USB drive or hard disk.\r\nRotate and monitor: Periodically regenerate recovery codes if available and monitor login access for\r\nunusual logins.\r\nRecovery codes should not be a secondary concern; they are a direct path to bypassing MFA and gaining access. \r\nIOCs\r\nhttps://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nPage 8 of 9\n\nItem Description\r\nw.exe\r\nSHA256\r\n6f1192ea8d20d8e94f2b140440bdfc74d95987be7b3ae2098c692fdea42c4a69 \r\nRansomware executable\r\n104.238.221[.]69 \r\nAttacker IP entered the\r\nHuntress platform\r\ncert.pfx Certificate Export\r\nSource: https://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nhttps://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.huntress.com/blog/dangers-of-storing-unencrypted-passwords"
	],
	"report_names": [
		"dangers-of-storing-unencrypted-passwords"
	],
	"threat_actors": [
		{
			"id": "8c8fea8c-c957-4618-99ee-1e188f073a0e",
			"created_at": "2024-02-02T02:00:04.086766Z",
			"updated_at": "2026-04-10T02:00:03.563647Z",
			"deleted_at": null,
			"main_name": "Storm-1567",
			"aliases": [
				"Akira",
				"PUNK SPIDER",
				"GOLD SAHARA"
			],
			"source_name": "MISPGALAXY:Storm-1567",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "910b38e9-07fe-4b47-9cf4-e190a07b1b84",
			"created_at": "2024-04-24T02:00:49.516358Z",
			"updated_at": "2026-04-10T02:00:05.309426Z",
			"deleted_at": null,
			"main_name": "Akira",
			"aliases": [
				"Akira",
				"GOLD SAHARA",
				"PUNK SPIDER",
				"Howling Scorpius"
			],
			"source_name": "MITRE:Akira",
			"tools": [
				"Mimikatz",
				"PsExec",
				"AdFind",
				"Akira _v2",
				"Akira",
				"Megazord",
				"LaZagne",
				"Rclone"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434766,
	"ts_updated_at": 1775791677,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9e3d0045c0e530b3e98c0a529b1ea42df83cec5a.pdf",
		"text": "https://archive.orkl.eu/9e3d0045c0e530b3e98c0a529b1ea42df83cec5a.txt",
		"img": "https://archive.orkl.eu/9e3d0045c0e530b3e98c0a529b1ea42df83cec5a.jpg"
	}
}