PseudoSigner02LCCWin32DLLAnorganix

Hunt Hypothesis

This rule detects the presence of a specific Win32 DLL associated with the PseudoSigner02LCC tool, which adversaries use to create fake digital certificates to sign malicious executables and bypass security controls. Proactively hunting for this artifact in Azure Sentinel allows the SOC team to identify potential supply chain attacks or living-off-the-land techniques before the signed binaries are executed to establish persistence or evade detection.

YARA Rule

rule PseudoSigner02LCCWin32DLLAnorganix
{
      meta:
		author="malware-lu"
strings:
		$a0 = { 55 89 E5 53 56 57 83 7D 0C 01 75 05 E8 17 90 90 90 FF 75 10 FF 75 0C FF 75 08 A1 }

condition:
		$a0 at pe.entry_point
}

Deployment Notes

This YARA rule can be deployed in the following contexts:

• Microsoft Defender for Endpoint — Custom indicators / advanced hunting
• Email Gateway — Attachment scanning
• File Share Monitoring — Periodic scanning of shared drives
• YARA CLI — Manual threat hunting on endpoints

This rule contains 1 string patterns in its detection logic.

• Source Rule

False Positive Guidance

• Scenario: A developer or DevOps engineer uses a legacy build tool or custom C/C++ compiler (e.g., MinGW, TDM-GCC, or an older version of Visual Studio) to compile a small utility DLL for internal testing. These older toolchains often embed specific compiler signatures or lack modern Authenticode signing, which can match the “PseudoSigner” heuristic if the rule targets specific compiler artifacts or unsigned/weakly signed binaries.

  • Filter/Exclusion: Exclude files located in standard development directories (e.g., C:\Users\<user>\source\, C:\builds\, C:\dev\) or filter by parent process being a known IDE or compiler (e.g., devenv.exe, cl.exe, gcc.exe, msbuild.exe).

• Scenario: An enterprise application uses a third-party, open-source, or legacy Win32 DLL that is not digitally signed or is signed with a self-signed certificate. This is common in older line-of-business (LOB) applications or custom internal tools that were never updated to include a code-signing certificate.

  • Filter/Exclusion: Maintain a whitelist of known internal application directories (e.g., C:\Program Files\<InternalApp>\bin\) or exclude specific file hashes (SHA256) of known good internal DLLs that are confirmed to be legitimate.

• Scenario: A scheduled maintenance job or service (e.g., a custom backup agent, log rotation script, or hardware monitoring daemon) loads a DLL that was compiled in-house without a formal code-signing process. This often occurs in environments where IT teams write small C# or C++ helpers for automation that are deployed directly to the System32 or application bin folders.

  • Filter/Exclusion: Exclude DLLs loaded by specific service processes (e.g., `MyBackup