Windows 11 Trojan Problems and UEFI.

Tae Song

Member
Joined
Oct 30, 2025
Messages
2
Trojan injection. It's showing some kind of network shared drive. Only local drives can be used for System Protection/Restore. I have Antivirus ESET NODE32.

It (Windows App Compatibility/Reputation based) tried to prevent me from installing ClamAV. There's no partition repair, Disk Doctor like in the old days.

Added to that, UEFI / Secure Boot is not reliable. The perpetrator is changing BIOS settings (Boot Order). UEFI / Windows arbitrarily changing/adding UEFI partition or allowing anyone with access through UEFI to add and change them.

UEFI Unified Extensible Firmware Interface. Why does firmware (BIOS) need to be extensible? It's got more holes than Swiss cheese. It takes almost 2mins to even POST, indicating it's maybe running a smaller computer/OS before it even gets to POSTing.


System Protection tab showing available drives, with one volume's protection Off.
 

Last edited by a moderator:
Solution
Hi Tae — thanks for the clear description and screenshot. You’ve raised two related but different concerns: (A) the strange volume entry shown in System Protection (the \?\Volume{GUID} one) and (B) the firmware/UEFI / Secure Boot concerns (possible firmware tampering, long POST, boot-order changes). Below I’ll explain what’s probably happening, why UEFI is extensible, and give a prioritized, safe step‑by‑step plan you can follow (with commands) to investigate and harden the machine. I’ll also warn about risky actions and how to undo them.
Short summary / TL;DR
  • \?\Volume{…} is a Windows volume GUID path (usually a local partition, VHD, or mounted volume without a drive letter). System Protection only works on local volumes that...
Hi Tae — thanks for the clear description and screenshot. You’ve raised two related but different concerns: (A) the strange volume entry shown in System Protection (the \?\Volume{GUID} one) and (B) the firmware/UEFI / Secure Boot concerns (possible firmware tampering, long POST, boot-order changes). Below I’ll explain what’s probably happening, why UEFI is extensible, and give a prioritized, safe step‑by‑step plan you can follow (with commands) to investigate and harden the machine. I’ll also warn about risky actions and how to undo them.
Short summary / TL;DR
  • \?\Volume{…} is a Windows volume GUID path (usually a local partition, VHD, or mounted volume without a drive letter). System Protection only works on local volumes that are eligible — that GUID entry being “Off” is normal for non-eligible volumes. Don’t delete partitions blindly.
  • UEFI is “extensible” because it supports modules, drivers and pre-boot apps (bootloaders, remote management), but that adds complexity/attack surface. You can reduce risk by locking firmware (UEFI admin password), enabling Secure Boot + TPM + BitLocker with PIN, and keeping firmware updated.
  • If you suspect an active, persistent attacker who can change firmware/boot order, treat this as a serious compromise: isolate the PC, make a disk image, use offline rescue media to scan, and consider re‑flashing firmware from the vendor or replacing hardware if firmware is proven compromised.
Part A — The \?\Volume{GUID} entry in System Protection
What that is
  • \?\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\ is the NT volume GUID path Windows uses internally to identify volumes. It’s not a network UNC (\server\share) — it is a local volume identifier.
  • Windows System Protection (Restore) lists local volumes; it shows GUID paths for volumes that have no drive letter or are mounted to a folder. “Protection: Off” for that GUID just means System Protection is not enabled on that volume (common for recovery partitions, OEM partitions, or mounted VHDs).
How to identify what that GUID corresponds to (safe, non‑destructive)
  1. Open an elevated Command Prompt (Run as Administrator).
  2. Run:
    • mountvol
      • This prints each volume GUID and any drive letters or mount points mapped to it. Match the GUID from your screenshot.
    • diskpart
      • then at diskpart prompt: list volume
      • find the volume number that matches the GUID (detail may show the mount point); use select volume <n> then detail volume.
    • In PowerShell (Admin): Get-Volume | Format-List DriveLetter, FileSystemLabel, ObjectId, Size
      • ObjectId includes the \?\Volume{GUID} format.
  3. Check Disk Management (diskmgmt.msc) — look for volumes without letters, VHDs, or volumes mounted to folders.
If it’s a VHD or a folder-mounted volume
  • If it’s a mounted VHD you didn’t intentionally mount, investigate how it was mounted (some applications mount VHDs). In diskpart you can use: list vdisk. Be cautious before dismounting.
How to remove/unmount a mountpoint safely
  • If you confirm it’s a mountpoint (not a needed recovery partition) and want to remove the mountpoint (not delete data):
    • Using diskpart (Admin)
    • select volume <n>
    • remove letter=<Letter> (or remove the mount point)
    • Or: mountvol X: /D (removes the mount point for drive X:)
  • DON’T delete partitions unless you are 100% sure what they are — back up first.
Part B — UEFI / Secure Boot / firmware concerns and long POST
Why UEFI is “extensible”
  • UEFI replaced legacy BIOS to provide a standard pre‑OS environment that supports:
    • modular drivers for different hardware before Windows loads,
    • standardized bootloaders (EFI apps) and multiple filesystems,
    • secure remote management and vendor utilities,
    • faster/modern boot features and 64‑bit pre‑OS code.
  • The downside: more functionality means more code and a larger attack surface. That’s why attackers sometimes target firmware.
Why long POST could happen
  • Modern UEFI can run many initialization routines and built‑in diagnostic/management features (and vendor security checks). If the UEFI runs additional firmware modules, network management interfaces, or does deeper device initialization, POST can take noticeably longer. That doesn’t prove compromise but can be a sign to investigate.
Hardening and recovery steps (prioritized)
1) IMMEDIATE — isolate and don’t use online
  • Disconnect from the network (unplug Ethernet, disable Wi‑Fi). If you suspect compromise, do not log into online accounts from that machine.
  • If this is an office/critical machine, inform IT/security and consider bringing in incident response.
2) Make a full disk image (before major cleanup)
  • Use disk imaging software (e.g., Macrium Reflect Free, Clonezilla) to create a bit‑for‑bit image to an external drive. This preserves evidence and lets you restore later if needed.
3) Boot and scan from clean rescue media (offline)
  • Create bootable rescue media on a different, known-clean PC (ESET Rescue USB, Kaspersky Rescue Disk, or a vendor rescue ISO).
  • Boot the suspect PC from the rescue USB and run a full offline scan for rootkits/malware. This avoids the live system being able to hide itself.
  • Recommended offline tools: ESET Rescue, Kaspersky Rescue, Malwarebytes Anti-Rootkit (where available), TDSSKiller for rootkits.
4) Check firmware/Secure Boot state
  • In Windows (Admin PowerShell):
    • Confirm-SecureBootUEFI (returns True/False)
    • Get-TPM (shows TPM state)
  • Or open msinfo32 -> System Summary -> Secure Boot State and BIOS Mode.
  • If Secure Boot is off and you did not disable it, that’s suspicious.
5) Lock the firmware
  • In UEFI settings (access during POST), set a UEFI Administrator/Supervisor password (NOT the same as Windows password). This prevents casual changes to boot order and Secure Boot settings without that password.
  • Disable boot from external devices (USB/CD) if you do not need them.
  • Disable UEFI firmware update via non‑vendor signed methods if your firmware supports it.
  • NOTE: Keep the password safe — losing it can lock you out of firmware controls.
6) Update / reflash firmware from vendor
  • Download the latest firmware/BIOS/UEFI from the motherboard or PC vendor site (from a known-good PC). Follow vendor instructions to update/reflash.
  • If you suspect the firmware is already infected, re-flashing with an official vendor image is a reasonable remediation. Some vendors provide recovery tools that verify digital signatures.
7) Protect boot integrity: TPM + BitLocker + PIN
  • Enable TPM in firmware (if present) and enable BitLocker with TPM + PIN to protect the disk and detect pre‑boot tampering. If someone changes the boot path or firmware, BitLocker can prevent access to the plaintext drive unless the attacker also has your TPM/keys/PIN.
  • Use a pre‑boot PIN if you want stronger protection (requires entering PIN on boot).
8) Examine Windows boot configuration
  • From Admin Command Prompt:
    • bcdedit /enum all
    • This shows Windows boot manager entries; look for unexpected entries.
  • Check Event Viewer -> System for firmware/boot related events (not all firmware changes are logged).
9) If malware persists: reinstall Windows from known-good media
  • Wipe the disk and do a clean install from a Windows USB created by Microsoft’s Media Creation Tool on a clean computer. If firmware was compromised, reflash firmware first (step 6) and ensure Secure Boot + TPM + BitLocker before restoring data.
  • Restore files only after scanning them on a clean system.
About reputation-based blocking (ClamAV install blocked)
  • Windows Defender SmartScreen and reputation-based protection can block apps that are uncommon or unsigned. That is a security measure to prevent unknown apps from running.
  • If you trust the vendor and installer signature, you can temporarily allow it, but if you are on a system you suspect is compromised, do the offline scans first and prefer a rescue scan or vendor-supplied signed installers. ESET may also block installers — check ESET’s logs/quarantine and temporarily disable real-time protection only if you are sure the file is clean (but don’t do that on a suspect machine).
Useful commands (copy/paste from Admin elevated windows)
  • Identify volume GUIDs and mount points:
    • mountvol
    • diskpart
    • list volume
    • select volume <n>
    • detail volume
  • PowerShell volume info:
    • Get-Volume | Format-List DriveLetter, FileSystemLabel, ObjectId, Size
  • Check Secure Boot / TPM:
    • Open PowerShell as Admin: Confirm-SecureBootUEFI
    • powershell Get-TPM
  • Check network-mapped drives:
    • net use
  • Boot configuration:
    • bcdedit /enum all
How to undo common safe changes
  • Removing a drive letter or mount point is reversible by assigning a drive letter back in Disk Management.
  • Firmware password can be removed in the same UEFI settings area (you must know the admin password to remove it). Keep documentation of the password.
When to call a professional / replace hardware
  • If after rescanning from clean rescue media you still see signs of persistent firmware tampering (firmware settings changed while Secure Boot and a firmware password were enabled, or vendor tools show tampered firmware signature), you should consider professional incident response. Some firmware/rootkits can only be fully removed by re‑flashing the chip with verified firmware or by replacing the motherboard.
One immediate safe checklist you can do now
  1. Unplug network.
  2. Make a disk image to external drive.
  3. Build ESET/Kaspersky rescue USB on another machine.
  4. Boot rescue USB and run full scan + rootkit checks.
  5. In Windows (if you re‑boot back), run Confirm-SecureBootUEFI and Get-Volume (PowerShell) and match the GUID to diskmgmt/diskpart.
  6. Set a UEFI admin password, disable external boot, update firmware from vendor site.
  7. If malware remains, wipe, re‑flash firmware and reinstall OS from known-good media.
If you want, I can:
  • Walk through the exact mountvol/diskpart/Get-Volume output if you paste the results here (copy/paste the command output). That will let us identify exactly what that GUID volume is and whether it’s safe to remove the mountpoint.
  • Provide step-by-step instructions for creating a rescue USB (ESET or Kaspersky) and running the offline scan.
  • Help with the exact commands to lock UEFI or enable BitLocker for your system model (tell me PC make/model or motherboard).
Would you like to start with the volume identification (mountvol / Get-Volume output)? Paste the results here and I’ll point to which volume that GUID is and the safe next step.
 

Solution
Back
Top