Stealthy G... Malware(?) API(?) DLL(?) - Have you seen me?

[rcmaehl]

Hi all,
 

Recently I've been seeing more and more topics on various forums about a mysterious "G" roaming around on Windows PCs, such as the image below:
 

Google search even pulls up 7 MILLION results, although I'm sure some are not relevant

Recently I did a clean install of Windows and next day, LOAD AND BEHOLD, I too have G running as the title of several applications....
 

 

People, including myself, have scanned with several types of anti-malware suites, done clean installs and various other tricks. No one seems to know what it is. Is this a new Windows API issue? Rootkit? DLL? If you've seen this issue let me know. If you have this issue, include some specs about your system (Windows Build number, installed applications, anything else you think is useful).

 

Thanks!

[Tabs]

Is this how it appears in task manager/resource monitor, or is it hidden from there?

 

I don't have this issue on 1803, and haven't had this issue on any previous version of Windows 10. 

[rcmaehl]

3 minutes ago, Tabs said:

Is this how it appears in task manager/resource monitor, or is it hidden from there?

 

I don't have this issue on 1803, and haven't had this issue on any previous version of Windows 10. 

Doesn't appear in task manager, resource monitor, or process explorer. HOWEVER, if you are adept at programming and pull all Window Handles on the system and then get the title of each one, it easily shows up. If you trust random powershell scripts, here's what I have in powershell for getting "G" window handles

 

$TypeDef = @"

using System;
using System.Text;
using System.Collections.Generic;
using System.Runtime.InteropServices;

namespace Api
{

 public class WinStruct
 {
   public string WinTitle {get; set; }
   public int WinHwnd { get; set; }
 }

 public class ApiDef
 {
   private delegate bool CallBackPtr(int hwnd, int lParam);
   private static CallBackPtr callBackPtr = Callback;
   private static List<WinStruct> _WinStructList = new List<WinStruct>();

   [DllImport("User32.dll")]
   [return: MarshalAs(UnmanagedType.Bool)]
   private static extern bool EnumWindows(CallBackPtr lpEnumFunc, IntPtr lParam);

   [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
   static extern int GetWindowText(IntPtr hWnd, StringBuilder lpString, int nMaxCount);

   private static bool Callback(int hWnd, int lparam)
   {
       StringBuilder sb = new StringBuilder(256);
       int res = GetWindowText((IntPtr)hWnd, sb, 256);
      _WinStructList.Add(new WinStruct { WinHwnd = hWnd, WinTitle = sb.ToString() });
       return true;
   }   

   public static List<WinStruct> GetWindows()
   {
      _WinStructList = new List<WinStruct>();
      EnumWindows(callBackPtr, IntPtr.Zero);
      return _WinStructList;
   }

 }
}
"@

Add-Type -TypeDefinition $TypeDef -Language CSharpVersion3

[Api.Apidef]::GetWindows() | Where-Object { $_.WinTitle -like "G" } | Sort-Object -Property WinTitle | Select-Object WinTitle,@{Name="Handle"; Expression={"{0:X0}" -f $_.WinHwnd}}

 

[Tabs]

I'm curious if this is specific to non-English localised versions of Windows...

 

The title isn't a core part of a running program - more of a user aid than anything else. It seems unlikely that a piece of malware is causing this, since if it was malware and is advanced enough to remain undetected by every modern virus or malware scanning engine for this long, it's also advanced enough to not be visible to the user in such an obnoxious way.

 

Have you run something like VMMap from Sysinternals on any of the running executables with the weird G as title to get a full list of all loaded dll's in each process? 

[2FA]

Not sure if it's actually this trojan since it's just the compiled executable name we're going off of but my searching led me to a family of trojans called Backdoor.Graybird that has used that executable name in the past.

 

If you open file explorer and go to the root of your C:/ drive, try using the search box to find 

g.*

The search will take a while as it's going to be going through millions of files.

[rcmaehl]

Just now, Tabs said:

I'm curious if this is specific to non-English localised versions of Windows...

 

The title isn't a core part of a running program - more of a user aid than anything else. It seems unlikely that a piece of malware is causing this, since if it was malware and is advanced enough to remain undetected by every modern virus or malware scanning engine for this long, it's also advanced enough to not be visible to the user in such an obnoxious way.

 

Have you run something like VMMap from Sysinternals on any of the running executables with the weird G as title to get a full list of all loaded dll's in each process? 

Working on it now. I'm hoping for a dll in common or I'm once again going to be a loss.

[rcmaehl]

1 minute ago, 2FA said:

Not sure if it's actually this trojan since it's just the compiled executable name we're going off of but my searching led me to a family of trojans called Backdoor.Graybird that has used that executable name in the past.

 

If you open file explorer and go to the root of your C:/ drive, try using the search box to find g.exe. The search will take a while as it's going to be going through millions of files.

It's not a file called g.exe though, it's just window titles which is the mystery to begin with

[2FA]

1 minute ago, rcmaehl said:

It's not a file called g.exe though, it's just window titles which is the mystery to begin with

I edited my post to be more clear

[rcmaehl]

6 minutes ago, 2FA said:

I edited my post to be more clear

There are 11,182 results for files on C:\ using "g.*". However, files aren't Window Handles... If I went to http://linustechtips.com I'm not going to find "chrome.exe" by searching "Forums - Linus Tech Tips". I already know what processes/files have the title of "g" and where they're located. They're normal files belonging to normal programs. This could be possibly be DLL injection @Tabs is implying but it's definitely not just "g.*"

[2FA]

2 minutes ago, rcmaehl said:

There are 11,182 results for files on C:\ using "g.*". However, files aren't Window Handles... If I went to http://linustechtips.com I'm not going to find "chrome.exe" by searching "Forums - Linus Tech Tips". I already know what processes/files have the title of "g" and where they're located. They're normal files belonging to normal programs. This could be possibly be DLL injection @Tabs is implying but it's definitely not just "g.*"

I just tried that search myself and that is not the behavior I expected.

 

I'll try that Powershell script in a VM and see what it shows for me. (I don't like doing testing on my host)

[Tabs]

1 minute ago, rcmaehl said:

There are 11,182 results for files on C:\ using "g.*". However, files aren't Window Handles... If I went to http://linustechtips.com I'm not going to find "chrome.exe" by searching "Forums - Linus Tech Tips". I already know what processes/files have the title of "g" and where they're located. They're normal files belonging to normal programs. This could be possibly be DLL injection @Tabs is implying but it's definitely not just "g.*"

Indeed. Let us know what you find - the files themselves are unlikely to have been tampered with in any way, so it's most likely to be a dll that's been registered, if anything.

 

 I have a few different Windows images available in case you wish to verify any individual file checksums - let me know and I'll try to help.

 

There's the possibility also that this is some issue with language packs, I haven't yet spent a lot of time looking through the google results, but all of the ones I've seen so far are on non-English versions of Windows. Possibly a glitch in some MUI deployments?

 

Is your own install using any MUI's?

[rcmaehl]

2 minutes ago, Tabs said:

Indeed. Let us know what you find - the files themselves are unlikely to have been tampered with in any way, so it's most likely to be a dll that's been registered, if anything.

 

 I have a few different Windows images available in case you wish to verify any individual file checksums - let me know and I'll try to help.

 

There's the possibility also that this is some issue with language packs, I haven't yet spent a lot of time looking through the google results, but all of the ones I've seen so far are on non-English versions of Windows. Possibly a glitch in some MUI deployments?

 

Is your own install using any MUI's?

I personally haven't installed any. I've only got en-US (verified under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MUI\UILanguages)

Regardless, I'm thinking this might be input related as the only thing that acts similar is "Default IME" or the default input layer provided by Windows. 

I'm working on grabbing all the info from VMMap currently and I'll compare it once I get done, https://docs.google.com/spreadsheets/d/1FCvqeKZu_QyfL66AchKNl0Tp4Z17QhuQDlqEPZKar1A/edit?usp=sharing

[Tabs]

6 minutes ago, rcmaehl said:

I personally haven't installed any. I've only got en-US (verified under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MUI\UILanguages)

Regardless, I'm thinking this might be input related as the only thing that acts similar is "Default IME" or the default input layer provided by Windows. 

I'm working on grabbing all the info from VMMap currently and I'll compare it once I get done, https://docs.google.com/spreadsheets/d/1FCvqeKZu_QyfL66AchKNl0Tp4Z17QhuQDlqEPZKar1A/edit?usp=sharing

That's a great idea, and interesting diagnostic format. You may be able to get more relevant results if you filter VMMap by "image" and then sort by "Details", as that will then arrange the dll's by image path and allow you to very easily exclude images that aren't common to all of the programs you're testing.

[2FA]

So I just tested the PS script in my VM. Windows 10 .iso was freshly downloaded within a Linux VM, temporarily moved to host so it could be installed into a VM.

 

 

I can only conclude that this is part of Windows as I doubt my .iso could be injected within seconds of directly being placed on my host.

[rcmaehl]

9 hours ago, 2FA said:

So I just tested the PS script in my VM. Windows 10 .iso was freshly downloaded within a Linux VM, temporarily moved to host so it could be installed into a VM.

 

 

I can only conclude that this is part of Windows as I doubt my .iso could be injected within seconds of directly being placed on my host.

So it's a part of Windows but we still don't know what it is. Microsoft is doing undocumented stuff again... 

[rcmaehl]

From another forum:
 

It appears Windows is doing stuff with unmanaged resources... what specifically is yet to be found...