The digital threat landscape is perpetually evolving, with adversaries constantly refining their tradecraft to evade detection and maximize the impact of their attacks. Among the most pernicious and effective techniques observed in modern cyber campaigns, particularly those associated with state-sponsored actors and sophisticated ransomware groups, is One-to-One Cached Fishing. This method represents a significant evolution beyond simple credential harvesting, combining elements of social engineering, technical reconnaissance, and a deep understanding of Windows authentication mechanisms to achieve silent, persistent access. This discussion will provide a technical dissection of the technique, tracing its operational workflow, underlying protocols, defensive bypass mechanisms, and mitigation strategies. **Deconstructing the Technique: From Phishing to Caching** The term "One-to-One Cached Fishing" is a portmanteau that accurately describes its two-phase nature. It is not a single action but a multi-stage attack chain. **Phase 1: The "Fishing" Component - Credential Acquisition** The initial phase is a classic spear-phishing campaign, but with a critical twist. The attacker's goal is not to install a payload immediately but to capture the victim's domain credentials (username and password). This is typically achieved through one of two highly convincing methods: 1. **Adversary-in-the-Middle (AiTM) Phishing:** The attacker sets up a proxy server between the victim and the legitimate service they wish to impersonate (e.g., Microsoft 365 login portal). When the victim enters their credentials on the fake login page, the proxy forwards them to the genuine service. If Multi-Factor Authentication (MFA) is enabled, the proxy captures the session cookie or token returned after a successful MFA challenge. This allows the attacker to bypass MFA entirely by replaying this session, effectively hijacking the authenticated session. 2. **Credential-Harvesting Phishing:** A more straightforward approach uses a meticulously crafted fake login page that mimics a corporate Single Sign-On (SSO) portal. The submitted credentials are sent directly to the attacker's command-and-control (C2) server. While this method fails if MFA is required, it remains effective against targets with legacy authentication protocols or in cases where the attacker can trigger a conditional access policy exception. The key outcome of Phase 1 is the possession of a valid set of primary credentials (and potentially an MFA-bypass token) for a domain user. **Phase 2: The "One-to-One Cached" Component - Credential Reuse and Persistence** This is where the technique demonstrates its sophistication. Instead of using the stolen credentials to access cloud resources directly from an untrusted IP (which would trigger risk-based alerts), the attacker leverages them to gain initial access to a resource *inside* the corporate network. The objective is to force the creation of a cached credential on a specific, targeted machine. Cached credentials are a legacy feature of Windows domains, designed to allow users to log into their domain-joined machines when a Domain Controller (DC) is unavailable. Upon a successful interactive logon (e.g., logging onto a laptop at the office), the system caches a derivative of the user's NT hash (using the Data Protection API or DPAPI) locally in the Security Account Manager (SAM) database, within the registry hive `HKLM\SECURITY\Cache`. This cached verifier is not the plaintext password but a hash of the user's password combined with the username and other data, suitable for local validation. The "One-to-One" aspect refers to the attacker's deliberate action to place this cached credential on a specific host. The workflow is as follows: 1. **Lateral Movement to Target Machine:** Using the stolen credentials, the attacker authenticates to a machine they already control (e.g., a compromised workstation) and then uses a technique like Pass-the-Hash (PtH) or Windows Remote Management (WinRM) to access the *target* workstation or server. This target is often chosen for its high value, such as a developer's machine, an IT administrator's workstation, or a server with critical data. 2. **Triggering an Interactive Logon Simulation:** To write the cached credential to the target machine's registry, the attacker must simulate an interactive logon. This is achieved by executing a process or command in the context of the stolen credentials *on the target machine* that requires interaction with the Winlogon service. Common methods include: * Using `runas /netonly` is insufficient as it does not cache credentials. Instead, attackers use APIs that trigger the caching mechanism. * Leveraging the `cmdkey` utility to add the credentials to the Windows Vault for a specific network resource, which can sometimes trigger caching. * Using scheduled tasks configured for interactive sessions. * Executing a service that runs in the user context and interacts with the desktop. * A highly effective method is using the Remote Desktop Protocol (RDP). By initiating an RDP session to the target machine *from a machine they control on the internal network* using the stolen credentials, the attacker forces a full interactive logon sequence. Even if they immediately disconnect, the act of a successful RDP logon will populate the cache. Once this is complete, the targeted machine now holds a cached version of the victim's credentials. The attacker now has a persistent foothold that is independent of the original stolen password. If the user's password is changed, if the account is locked, or if conditional access policies are modified to block the initial access vector, the cached credential on the target machine remains valid for offline logons. **Technical Underpinnings: NTLM, DPAPI, and the LSASS** To fully appreciate the defense evasion capabilities of this technique, one must understand its interaction with core Windows security subsystems. * **NTLM Authentication and the Cache:** The cached credentials are based on the NTLM one-way function (OWF). When a user logs on interactively and the DC is available, the Local Security Authority Subsystem Service (LSASS) receives the user's NT hash from the DC. It then computes a version-specific hash (e.g., `NL$KM` for the older format) and stores it securely. The exact format has evolved from the weaker DES-based `NL$` version to the more secure `CacheV` versions that leverage SHA-256 and PBKDF2, making offline brute-forcing more difficult, though not impossible for determined adversaries with sufficient resources. * **LSASS as the Keystone:** LSASS is the central repository for all active security principals and their associated credentials, including both primary tokens (for interactive logons) and cached ones. Any attempt to extract these credentials, a technique known as "Dumping LSASS," is a primary goal for attackers post-compromise. Tools like Mimikatz have modules specifically designed to decrypt and extract the cached domain passwords from the LSASS memory or the SECURITY hive, provided the attacker has acquired appropriate privileges (usually `SYSTEM` or `DEBUG` privileges). * **Persistence and Evasion:** The power of this technique lies in its operational security. By using cached credentials for lateral movement *within* the network, the attacker's activity blends in with normal user traffic. There are no anomalous logons from unfamiliar countries or IP ranges. The authentication requests originate from internal IPs, making them far less likely to trigger security alerts based on geolocation or impossible travel scenarios. Furthermore, by relying on a cached artifact, the attacker becomes resilient to certain account-level remediations. **Mitigation and Detection Strategies** Defending against One-to-One Cached Fishing requires a defense-in-depth approach that addresses both the initial phishing vector and the subsequent lateral movement and persistence. **Phase 1 Mitigation (Preventing the "Fish"):** * **Phishing-Resistant MFA:** The most critical control. Implement FIDO2 security keys or Windows Hello for Business, which are inherently resistant to AiTM phishing attacks as they rely on public-key cryptography and do not emit a reusable secret. * **Conditional Access Policies:** Enforce strict policies that block legacy authentication protocols and require compliant, hybrid Azure AD-joined, or specific trusted locations for access. * **User Training:** Continually educate users on identifying sophisticated phishing attempts, though this should be considered a secondary layer of defense. **Phase 2 Mitigation (Preventing the "Cache"):** * **Restrict Cached Logons via GPO:** The most direct mitigation is to limit or disable the storage of cached credentials. This can be configured via Group Policy under `Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> "Interactive logon: Number of previous logons to cache (in case domain controller is not available)".` Setting this value to `0` disables cached logons entirely, though this must be balanced against operational requirements for mobile users. * **Privileged Access Workstations (PAWs):** Implement dedicated, hardened workstations for administrative and high-privilege users. These PAWs should have cached credentials disabled and have severely restricted internet and email access, breaking the attack chain. * **Application Control and EDR:** Deploy robust Endpoint Detection and Response (EDR) solutions and application whitelisting (e.g., AppLocker, Windows Defender Application Control) to prevent the execution of credential dumping tools like Mimikatz. * **Credential Guard:** Enable Windows Defender Credential Guard, which uses virtualization-based security (VBS) to isolate the LSASS process and protect derived domain credentials and secrets from extraction attempts. This makes dumping cached hashes significantly more difficult.