Original link： https://decoder.cloud/2020/01/20/from-hyper-v-admin-to-system/

This time I will show you how it is possible to gain SYSTEM privileges on a Windows machine (a fully patched Win 10 in our case) with HYPER-V enabled and being a member of the special “Hyper-V Administrators” Windows group. I know what you are thinking about: Hey! Hyper-V admins are just like Administrators (or even more), so what are you telling us???

Well, that’s not true. Hyper-V Administrators are a special group which “only” grants to standard users the possibility to manage the Hyper-V environment (create, delete, start,stop VM’s and so on…) but no other special privileges on the underlying OS (https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/use/manage-virtual-machines)
Imagine our surprise when we (me and my friend @padovah4ck) discovered that it was really easy to exploit via hardlinks an arbitrary file overwrite with SYSTEM rights during a VM deletion process… but back to the beginning!

When you create a virtual machine, a “SetSecurity” call is made on the virtual harddisk file (.vhdx) in order to grant r/w permissions to special SID’s:

1. Microsoft Hyper-V Virtual Machine Bus Provider
   (S-1-15-3-1024-2268835264-3721307629-241982045-173645152-1490879176-104643441-2915960892-1612460704)
2. NT Virtual machine\<id of VM>
   
   

Note that the creator of the VM (user “simple”, member of Hyper-V Admin in this case) has full control over the file.

These operations are performed by the “vmms.exe” process (the Hyper-V management service) , which runs as SYSTEM user but impersonates during this operation the current user (“simple” in this case):

So far nothing strange or exploitable, do you agree?

But when you delete the VM, things are becoming more interesting… vmms.exe tries to reset the original permissions on the .vhdx file (which is not deleted). During this process, no impersonation takes place, so it’s done by SYSTEM!

I guess you already got it: hardlinks abuse!

Oh yes! If you remove the .vhdx file and replace it with a native hardlink pointing to a SYSTEM protected destination file, you should grant yourself full access to that file during the VM deletion, isn’t it?

Here we go: in this example I will grant to my user “simple” full control on “license.rtf” file, which normally is read only for standard users:

I have uploaded a small POC in powershell which automates the whole process, you can download it here . Yes. it’s really a piece of cake!

Once you have full control over a SYSTEM file, EOP is an easy task… for example, you can use it for overwriting the printconfig.dll

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！