The Dual-Homed Server With Only WinRM Open

I would choose WinRM from APP01. The firewall already permits 5985 from APP01 to the server VLAN, and appsvc is in Remote Management Users on SQL01, so a native PowerShell remoting or winrs session from APP01 to SQL01 uses an existing service and an allowed protocol. A netsh portproxy on APP01 would also work technically, but it changes host configuration and may be logged; it is unnecessary because I do not need to expose SQL01 back to the Linux attack host. An SSH tunnel would require an SSH server on APP01 and a listener, which adds attack surface and likely fails because no SSH service is mentioned. I would not use a commercial C2 because of the explicit constraint and EDR. The decision is driven by permitted egress, the existing WinRM authorization for appsvc, and the requirement to avoid service creation. If WinRM from APP01 is blocked by local policy, portproxy is the fallback, not the first move.

Use WinRM's native remoting rather than psexec, smbexec, or wmiexec, because those create services or named pipes that EDR is watching for. From APP01, start a session to SQL01 as appsvc with Enter-PSSession or Invoke-Command over 5985. Keep the commands simple and native: whoami, hostname, net localgroup administrators, and file listings. Avoid uploading binaries and avoid invoking encoded PowerShell. If PowerShell remoting is restricted, use winrs with the same credentials; winrs still uses WinRM and does not create a service. Do not attempt SMB or RDP because they are blocked and would generate failed-connection noise. If appsvc is not a local admin on SQL01, the session will be low-integrity; that is acceptable for the first step. Use it to enumerate local configuration and look for a controlled escalation path, rather than immediately attempting privileged operations that EDR may flag.

If authentication succeeds but the session is denied, I would check whether appsvc is actually in Remote Management Users on SQL01, whether WinRM has an explicit allow list, and whether the WinRM listener is bound to the expected IP. A domain account is not subject to the local-account UAC remote restriction, so that is not the first suspect. The fallback is a limited netsh portproxy on APP01 using the local admin context, forwarding a high local port to SQL01:5985, then connecting from the Linux host to APP01 on that port. That preserves the allowed protocol but changes APP01 configuration, so it should be time-boxed and documented. I would not attempt SMB or RDP scans; they are blocked and noisy. I would not create a service or scheduled task on SQL01 to bypass WinRM, because EDR explicitly alerts on service creation and it violates the low-noise constraint. If no allowed path works, report the blocker rather than escalating noise.