Beacon on a Host With Defender ASR and Falcon

Choice: a custom unmanaged loader that decrypts the .NET assembly or shellcode in memory and loads it without touching disk, using indirect syscalls and sleep obfuscation.

Why not the obvious options:

• In-memory AMSI patch: patching amsi.dll inside PowerShell or a .NET process is a well-known behavioral signature. It also does nothing about ETW/.NET event tracing or Falcon's user-mode hooks, so you silence one sensor and leave the more important one intact. It also requires PowerShell, which is high-signal on a workstation.
• InstallUtil: it is a signed LOLBin, but Defender and Falcon both flag InstallUtil.exe launching a non-Microsoft assembly, and the assembly has to exist on disk for the default path. The write-to-disk event plus the command line is a strong detection.
• No code-signing certificate: signing is not an option, so any signed-binary path must use an existing Microsoft binary, which narrows you to heavily monitored LOLBins.

The custom loader gives you control over disk writes, import resolution, and memory permissions. Use RW memory for the payload, flip to RX only at execution, avoid CreateRemoteThread into a foreign process, and keep the beacon inside a process that is normal for this host (for example, a user-facing application process rather than rundll32). The tradeoff is development time and the risk that Falcon's memory scanner flags unbacked executable pages; sleep obfuscation and module stomping reduce but do not eliminate that risk.

Use the DA's own RDP session instead of dumping LSASS.

Because you have local admin, you can create a service to run as SYSTEM, then enumerate sessions with query user around the 09:00 window. If the DA is connected over RDP, use tscon <session-id> /dest:console to hijack the session. That gives you the DA's interactive desktop and, more importantly, the DA's logon session and Kerberos tickets on that host.

From inside the hijacked session, run your tooling in the DA's context. You do not need the cleartext password: use the DA's ticket material to perform a DCSync (the DA has replication rights) or to access the member server directly. This avoids the ASR LSASS rule and the Falcon credential-theft alert entirely.

This is a judgement call because session hijacking is itself visible: tscon and service creation are logged. But it is far less likely to trigger the ASR rule than opening LSASS, and it uses a legitimate Windows feature rather than a known credential-dumping binary. If the DA connects over RDP but you cannot get SYSTEM, fall back to a scheduled task that runs in the DA's session only after the session exists, and avoid touching LSASS.

The most likely detection is Falcon's memory scan of unbacked executable memory and suspicious thread creation, followed by Defender's behavioral engine seeing a process making network connections shortly after loading an unsigned module.

Reductions that matter, in order:

• Avoid RWX and avoid VirtualAlloc/CreateThread combinations that are classic shellcode patterns. Allocate RW, write, then VirtualProtect to RX immediately before execution.
• Prefer module stomping or loading into a legitimately backed image region so the executable pages have a file backing on disk.
• Encrypt the beacon in memory while sleeping and use indirect syscalls so user-mode hooks see normal call stacks.
• Keep the process and command line consistent with the host's normal activity; do not spawn powershell.exe from an Office process.
• Limit network beacons to the same egress path the host normally uses; a new destination IP on 443 from a workstation may be caught by network analytics even if the endpoint sensor misses it.

No single technique is guaranteed against both products; the judgement is to minimize distinct high-signal events (disk write, AMSI patch, LSASS access, RWX) rather than to rely on one bypass.