How I got infected last time thread

I was infected by a Trojan from combatshell[.]com – here’s what happened (Full Malware Analysis)​


Hi everyone,

I want to share a recent experience I had involving a malicious executable I accidentally ran, which turned out to be a highly evasive and dangerous Trojan. The file was called CombatShell.exe and it came from the website http://combatshell[.]com.

After running it, the malware immediately bypassed Windows UAC (User Account Control), gaining administrator privileges silently. From there, it performed several suspicious actions:
  • Checked for virtualization/sandbox environments by scanning for VirtualBox and VMWare files, executables, and drivers.
  • Created persistence by dropping a startup file in the Windows startup folder.
  • Modified the Windows Registry to hijack .lnk (shortcut) file behavior and redirect them to the malware’s executable.
  • Enumerated detailed system information (BIOS, CPU vendor, browser info, IP address via external service).
  • Dropped multiple files inside Program Files, which is highly suspicious behavior.
  • Used dangerous Windows APIs like WriteProcessMemory, SetWindowsHookEx, and AdjustPrivilegeToken, possibly to inject code, escalate privileges, or even install a keylogger.
The malware hijacked msedge.exe (Microsoft Edge) and used it as a disguise to operate in the background — likely to evade detection by common antivirus programs.

Once I realized the extent of the infection through a sandbox analysis (Triage report linked below), I immediately disconnected the machine, wiped the system, and changed all my passwords. There’s still a concern about what information may have been leaked during the infection.

Here’s the full behavioral report from the sandbox I used, for those interested in technical details (includes TTPs, IOCs, memory writes, and more):
🔗 hxxp://combatshell[.]com | Triage


@Andy Ful Does using WHHL cant prevent lnk (shortcut) file behavior hijack and redirection to the malware’s executable? and would using "Block use of copied or impersonated system tools" rule prevent bypassing Windows UAC?
 
Last edited:
  • Like
Reactions: Andy Ful
Yes, WHHL (Windows Hardening Home Lockdown) can help prevent .lnk file behavior hijack and redirection to the malware's executable. It does this by enforcing stricter security policies and limiting the actions that can be performed by untrusted or potentially malicious software. However, it's not foolproof and should be used in conjunction with other security measures.
 
@Andy Ful Does using WHHL cant prevent lnk (shortcut) file behavior hijack and redirection to the malware’s executable? and would using "Block use of copied or impersonated system tools" rule prevent bypassing Windows UAC?

The author did not provide sufficient information to be sure. WHHL is intended to block shortcuts as an initial attack vector that mainly comes from UserSpace. The attack uses shortcuts after the system is compromised with high privileges, so the shortcut can be located in SystemSpace (allowed by WHHLight).
WHHLight could prevent this attack by blocking the initial malware or payloads.
 
The author did not provide sufficient information to be sure. WHHL is intended to block shortcuts as an initial attack vector that mainly comes from UserSpace. The attack uses shortcuts after the system is compromised with high privileges, so the shortcut can be located in SystemSpace (allowed by WHHLight).
WHHLight could prevent this attack by blocking the initial malware or payloads.
and bypassing Windows UAC? Any method to avoid?
 
  • Like
Reactions: Andy Ful
The most popular techniques:
  1. Elevated COM Object Abuse.
  2. Auto‑Elevated Executable & Registry Hijacking (I used it in some videos).
  3. DLL/Surrogate Hijacking (IFileOperation).
  4. Environment Variable and Directory Tricks.
  5. Task Scheduler and Service Exploits.
 
Any ASR rules or application control settings that can stop it?

Generally, all my tools can be useful to prevent/mitigate UAC bypasses.
When I bypassed Microsoft Defender a few years ago, the UAC bypass was blocked after some time by the updated ASR rule "Use advanced protection against ransomware".
UAC bypasses can be mainly prevented/mitigated by SWH/WDAC restrictions. In many cases, the UAC bypasses are applied via payloads downloaded from the remote locations (as files or filelessly), which can be prevented by FirewallHardening. In the case of MS Office applications, the DocumentsAntiExploit can also prevent many fileless UAC bypasses.
 
Never infected, I'm the best.
Morgan Freeman Applause GIF by The Academy Awards
 
  • Like
Reactions: simmerskool