Articles by "Computer"
Showing posts with label Computer. Show all posts
Tectuner is a Technology Releated website. Tectuner is a about the science,technology.Blogger template, Android, computer, Online Earning, tips tricks
HiddenWasp Malware





Beware the HiddenWasp in Linux!









Overview

Intezer has discovered a new, sophisticated malware that we have named “HiddenWasp”, targeting Linux systems.

• The malware is still active and has a zero-detection rate in all major anti-virus systems.

• Unlike common Linux malware, HiddenWasp is not focused on crypto-mining or DDoS activity. It is a trojan purely used for targeted remote control.

• Evidence shows in a high probability that the malware is used in targeted attacks for victims who are already under the attacker’s control or have gone through a heavy reconnaissance.

• HiddenWasp authors have adopted a large amount of code from various publicly available open-source malware, such as Mirai and the Azazel rootkit. In addition, there are some similarities between this malware and other Chinese malware families, however, the attribution is made with low confidence.

• We have detailed our recommendations for preventing and responding to this threat.



1. Introduction

Although the Linux threat ecosystem is crowded with IoT DDoS botnets and crypto-mining malware, it is not very common to spot trojans or backdoors in the wild.

Unlike Windows malware, Linux malware authors do not seem to invest too much effort writing their implants. In an open-source ecosystem, there is a high ratio of publicly available code that can be copied and adapted by attackers.

In addition, Anti-Virus solutions for Linux tend to not be as resilient as in other platforms. Therefore, threat actors targeting Linux systems are less concerned about implementing excessive evasion techniques since even when reusing extensive amounts of code, threats can relatively manage to stay under the radar.

Nevertheless, malware with strong evasion techniques does exist for the Linux platform. There is also a high ratio of publicly available open-source malware that utilizes strong evasion techniques and can be easily adapted by attackers.

We believe this fact is alarming for the security community since many implants today have very low detection rates, making these threats difficult to detect and respond to.

We have discovered further undetected Linux malware that appears to be enforcing advanced evasion techniques with the use of rootkits to leverage trojan-based implants.

In this blog, we will present a technical analysis of each of the different components that this new malware, HiddenWasp, is composed of. We will also highlight interesting code-reuse connections that we have observed to several open-source malware.

The following images are screenshots from VirusTotal of the newer undetected malware samples discovered:


HiddenWasp


2. Technical Analysis


When we came across these samples we noticed that the majority of their code was unique:
hidden virus

Similar to the recent Winnti Linux variants reported by Chronicle, the infrastructure of this malware is composed of a user-mode rootkit, a trojan and an initial deployment script. We will cover each of the three components in this post, analyzing them and their interactions with one another.



2.1 Initial Deployment Script:


When we spotted these undetected files in VirusTotal it seemed that among the uploaded artifacts there was a bash script along with a trojan implant binary.


linux hidden

We observed that these files were uploaded to VirusTotal using a path containing the name of a Chinese-based forensics company known as Shen Zhou Wang Yun Information Technology Co., Ltd.


Furthermore, the malware implants seem to be hosted in servers from a physical server hosting company known as ThinkDream located in Hong Kong.



hidden

Among the uploaded files, we observed that one of the files was a bash script meant to deploy the malware itself into a given compromised system, although it appears to be for testing purposes:




Thanks to this file we were able to download further artifacts not present in VirusTotal related to this campaign. This script will start by defining a set of variables that would be used throughout the script.


Among these variables we can spot the credentials of a user named ‘sftp’, including its hardcoded password. This user seems to be created as a means to provide initial persistence to the compromised system:


Furthermore, after the system’s user account has been created, the script proceeds to clean the system as a means to update older variants if the system was already compromised:


The script will then proceed to download a tar compressed archive from a download server according to the architecture of the compromised system. This tarball will contain all of the components from the malware, containing the rootkit, the trojan and an initial deployment script:


After malware components have been installed, the script will then proceed to execute the trojan:



We can see that the main trojan binary is executed, the rootkit is added to LD_PRELOAD path and another series of environment variables are set such as the ‘I_AM_HIDDEN’. We will cover throughout this post what the role of this environment variable is. To finalize, the script attempts to install reboot persistence for the trojan binary by adding it to /etc/rc.local.


Within this script we were able to observe that the main implants were downloaded in the form of tarballs. As previously mentioned, each tarball contains the main trojan, the rootkit and a deployment script for x86 and x86_64 builds accordingly.


The deployment script has interesting insights of further features that the malware implements, such as the introduction of a new environment variable ‘HIDE_THIS_SHELL’:


We found some of the environment variables used in a open-source rootkit known as Azazel.


It seems that this actor changed the default environment variable from Azazel, that one being HIDE_THIS_SHELL for I_AM_HIDDEN. We have based this conclusion on the fact that the environment variable HIDE_THIS_SHELL was not used throughout the rest of the components of the malware and it seems to be residual remains from Azazel original code.

The majority of the code from the rootkit implants involved in this malware infrastructure are noticeably different from the original Azazel project. Winnti Linux variants are also known to have reused code from this open-source project.


Within this function, we can see that eventually, control flow falls into a function in charge to resolve a set of dynamic imports, which are the functions it will later hook, alongside with decoding a series of strings needed for the rootkit operations.



We can see that for each string it allocates a new dynamic buffer, it copies the string to it to then decode it.

It seems that the implementation for dynamic import resolution slightly varies in comparison to the one used in Azazel rootkit.

When we wrote the script to simulate the cipher that implements the string decoding function we observed the following algorithm:


We recognized that a similar algorithm to the one above was used in the past by Mirai, implying that authors behind this rootkit may have ported and modified some code from Mirai.



After the rootkit main object has been loaded into the address space of a given process and has decrypted its strings, it will export the functions that are intended to be hooked. We can see these exports to be the following:


For every given export, the rootkit will hook and implement a specific operation accordingly, although they all have a similar layout. Before the original hooked function is called, it is checked whether the environment variable ‘I_AM_HIDDEN’ is set:


We can see an example of how the rootkit hooks the function fopen in the following screenshot:


We have observed that after checking whether the ‘I_AM_HIDDEN’ environment variable is set, it then runs a function to hide all the rootkits’ and trojans’ artifacts. In addition, specifically to the fopen function it will also check whether the file to open is ‘/proc/net/tcp’ and if it is it will attempt to hide the malware’s connection to the cnc by scanning every entry for the destination or source ports used to communicate with the cnc, in this case 61061. This is also the default port in Azazel rootkit.


The rootkit primarily implements artifact hiding mechanisms as well as tcp connection hiding as previously mentioned. Overall functionality of the rootkit can be illustrated in the following diagram:


2.3 The Trojan:

The trojan comes in the form of a statically linked ELF binary linked with stdlibc++. We noticed that the trojan has code connections with ChinaZ’s Elknot implant in regards to some common MD5 implementation in one of the statically linked libraries it was linked with:


In addition, we also see a high rate of shared strings with other known ChinaZ malware, reinforcing the possibility that actors behind HiddenWasp may have integrated and modified some MD5 implementation from Elknot that could have been shared in Chinese hacking forums:


When we analyze the main we noticed that the first action the trojan takes is to retrieve its configuration:


The malware configuration is appended at the end of the file and has the following structure:


The malware will try to load itself from the disk and parse this blob to then retrieve the static encrypted configuration.


Once encryption configuration has been successfully retrieved the configuration will be decoded and then parsed as json.

The cipher used to encode and decode the configuration is the following:


This cipher seems to be an RC4 alike algorithm with an already computed PRGA generated key-stream. It is important to note that this same cipher is used later on in the network communication protocol between trojan clients and their CNCs.

After the configuration is decoded the following json will be retrieved:


Moreover, if the file is running as root, the malware will attempt to change the default location of the dynamic linker’s LD_PRELOAD path. This location is usually at /etc/ld.so.preload, however there is always a possibility to patch the dynamic linker binary to change this path:


The patch_ld function will scan for any existent /lib paths. The scanned paths are the following:


The malware will attempt to find the dynamic linker binary within these paths. The dynamic linker filename is usually prefixed with ld-<version number>.


Once the dynamic linker is located, the malware will find the offset where the /etc/ld.so.preload string is located within the binary and will overwrite it with the path of the new target preload path, that one being /sbin/.ifup-local.


To achieve this patching it will execute the following formatted string by using the xxd hex editor utility by previously having encoded the path of the rootkit in hex:


Once it has changed the default LD_PRELOAD path from the dynamic linker it will deploy a thread to enforce that the rootkit is successfully installed using the new LD_PRELOAD path. In addition, the trojan will communicate with the rootkit via the environment variable ‘I_AM_HIDDEN’ to serialize the trojan’s session for the rootkit to apply evasion mechanisms on any other sessions.


After seeing the rootkit’s functionality, we can understand that the rootkit and trojan work together in order to help each other to remain persistent in the system, having the rootkit attempting to hide the trojan and the trojan enforcing the rootkit to remain operational. The following diagram illustrates this relationship:


Continuing with the execution flow of the trojan, a series of functions are executed to enforce evasion of some artifacts:


These artifacts are the following:


By performing some OSINT regarding these artifact names, we found that they belong to a Chinese open-source rootkit for Linux known as Adore-ng hosted in GitHub:


The fact that these artifacts are being searched for suggests that potentially targeted Linux systems by these implants may have already been compromised with some variant of this open-source rootkit as an additional artifact in this malware’s infrastructure. Although those paths are being searched for in order to hide their presence in the system, it is important to note that none of the analyzed artifacts related to this malware are installed in such paths.

This finding may imply that the target systems this malware is aiming to intrude may be already known compromised targets by the same group or a third party that may be collaborating with the same end goal of this particular campaign.


With the help of this function we where able to understand the structure of the communication protocol employed. We can illustrate the structure of this communication protocol by looking at a pcap of the initial handshake between the server and client:


We noticed while analyzing this protocol that the Reserved and Method fields are always constant, those being 0 and 1 accordingly. The cipher table offset represents the offset in the hardcoded key-stream that the encrypted payload was encoded with. The following is the fixed keystream this field makes reference to:



After decrypting the traffic and analyzing some of the network related functions of the trojan, we noticed that the communication protocol is also implemented in json format. To show this, the following image is the decrypted handshake packets between the CNC and the trojan:


After the handshake is completed, the trojan will proceed to handle CNC requests:


Depending on the given requests the malware will perform different operations accordingly. An overview of the trojan’s functionalities performed by request handling are shown below:


2.3. Prevention and Response

Prevention: Block Command-and-Control IP addresses detailed in the IOCs section.

Response: We have provided a YARA rule intended to be run against in-memory artifacts in order to be able to detect these implants.

In addition, in order to check if your system is infected, you can search for “ld.so” files — if any of the files do not contain the string ‘/etc/ld.so.preload’, your system may be compromised. This is because the trojan implant will attempt to patch instances of ld.so in order to enforce the LD_PRELOAD mechanism from arbitrary locations.



4. Summary

We analyzed every component of HiddenWasp explaining how the rootkit and trojan implants work in parallel with each other in order to enforce persistence in the system.

We have also covered how the different components of HiddenWasp have adapted pieces of code from various open-source projects. Nevertheless, these implants managed to remain undetected.

Linux malware may introduce new challenges for the security community that we have not yet seen in other platforms. The fact that this malware manages to stay under the radar should be a wake up call for the security industry to allocate greater efforts or resources to detect these threats.

Linux malware will continue to become more complex over time and currently even common threats do not have high detection rates, while more sophisticated threats have even lower visibility.        



IOCs


103.206.123[.]13
103.206.122[.]245
http://103.206.123[.]13:8080/system.tar.gz
http://103.206.123[.]13:8080/configUpdate.tar.gz
http://103.206.123[.]13:8080/configUpdate-32.tar.gz
e9e2e84ed423bfc8e82eb434cede5c9568ab44e7af410a85e5d5eb24b1e622e3
f321685342fa373c33eb9479176a086a1c56c90a1826a0aef3450809ffc01e5d
d66bbbccd19587e67632585d0ac944e34e4d5fa2b9f3bb3f900f517c7bbf518b
0fe1248ecab199bee383cef69f2de77d33b269ad1664127b366a4e745b1199c8
2ea291aeb0905c31716fe5e39ff111724a3c461e3029830d2bfa77c1b3656fc0
d596acc70426a16760a2b2cc78ca2cc65c5a23bb79316627c0b2e16489bf86c0
609bbf4ccc2cb0fcbe0d5891eea7d97a05a0b29431c468bf3badd83fc4414578
8e3b92e49447a67ed32b3afadbc24c51975ff22acbd0cf8090b078c0a4a7b53d
f38ab11c28e944536e00ca14954df5f4d08c1222811fef49baded5009bbbc9a2
8914fd1cfade5059e626be90f18972ec963bbed75101c7fbf4a88a6da2bc671b


Tectuner is a Technology Releated website. Tectuner is a about the science,technology.Blogger template, Android, computer, Online Earning, tips tricks
Are you getting a “USB device not recognized” error whenever you plug in a USB mouse, keyboard, camera, or another device? I can’t live without USB ports and currently have 5 ports on my computer so that I can connect my mouse, keyboard, camera, phone, and printer to it all at once!

For those of you with even more USB gadgets, you probably have connected a USB hub to one of your USB ports so that can you connect even more devices. Most of the time this works great, but occasionally your computer might stop recognizing USB devices. The odd thing about this error is that the ports are working just fine, as I was able to still charge my cell phone without a problem, but couldn’t get my camera recognized using the same port.


how to solve usb device not recognized, usb device, usb device not recognized

After spending a lot of time and trying a bunch of different ways to fix the problem, only one solution ended up working for me. I’ll mention that solution first, but will also mention the other possible solutions, as the first solution may not fix the problem for everyone.






Method 1 – Unplug Computer

So how did I finally fix the problem? Well, if you are lucky, it’s a super simple solution! Try this method first and if it works, you’ll have saved a lot of time.

Simply unplug your computer from the power supply. Yes, that is it! Note that this does not mean just turning off your computer using the power button because most modern computers don’t actually turn off completely and the motherboard will still get power. This is useful sometimes if you want to remotely wake up a computer, etc.

The motherboard is where all of the hardware of the computer connects to, including the USB ports. Sometimes the motherboard needs to be “rebooted” because things can go wrong, i.e. all or some USB ports suddenly stop working. The small microprocessor on the motherboard will reload the drivers and your USB ports should hopefully be recognizing devices again.

So first turn off your computer using the Shut Down option in Windows or pressing the power button and then UNPLUG the PC from the wall outlet. Let it sit for several minutes and then plug it back in.


Method 2 – Update Device Driver

If Windows is not able to recognize the device, you may also see in Device Manager that the device shows up as an “Unknown Device”. You can get to Device Manager by clicking on Start and typing in devmgmt.msc or by going to Control Panel and clicking on Device Manager.

USB Device Not Recognized in Windows, Device Not Recognized


In that case, you should right-click on Unknown Device, click on Properties, then the Driver tab and then click Update Driver.

update driver usb, usb problem

If this doesn’t work, you can also try to download the driver for your device from the manufacturer’s website. If the USB device is just a flash drive, then it’s probably not a driver issue. However, if you are installing a USB printer, drawing pad, etc, then it might be worth downloading the driver for that specific device.


Method 3 – Restart & Disconnect USB Devices

The next thing you can try is to disconnect all USB devices and then restart the machine. once you have restarted, try to connect the USB device that was causing the problem.

If that particular USB port doesn’t recognize it, try another one. If the device is recognized by a different USB port, there could be a hardware problem with one of the USB ports. If no USB port recognizes the device, then keep reading because it’s probably something else.


Method 4 – USB Root Hub

Another thing you can try is to open Device Manager, expand USB Serial Bus Controllers, right-click on USB Root Hub and then click on Properties.

                                                               
USB Root Hub solution

Click on the Power Management tab and uncheck the Allow the computer to turn off this device to save power box. If you have more than one USB Root Hub listed, you need to repeat these steps for each one.

usb root hub problem solution

Click OK and then restart your computer. Try to reconnect the USB device and see if it is recognized. If not, go back to the power management tab for each one and check the box again. If it does recognize the device, then leave them unchecked.


Method 5 – Connect Directly to PC

A friend of mine ran into this issue and the cause ended up being his USB hub. He only had three USB ports on his computer, so he bought a hub where he could connect an additional 8 USB devices.

I guess this proved too much for his computer and it just started sporadically not recognizing various devices. After removing the hub and connecting the device directly to the computer, it worked just fine.

We haven’t really been able to find any other solution to this problem other than reducing the number of items connected to the hub. Actually, one other solution worked, but it meant having to buy a new USB hub with more power.

If you are having this problem with Windows 8 or Windows 8.1, then you might be in luck. Microsoft has released a fix for Windows 8 not detecting USB devices properly. Make sure to install this hotfix if running Windows 8.


Method 6 – USB Troubleshooter

If nothing has worked so far, you can download the Windows USB Troubleshooter Fixit tool. It’s a free tool that works with Windows XP, Vista and 7.

USB Troubleshooter

You can either have the troubleshooter fix the problems for you or select the fixes yourself. I would just let it fix them for you since the choices can sometimes be confusing and technical for the novice user.


Method 7 – Update Generic USB Hub

If you are getting the Unknown Device error in Device Manager, you can also try one other thing. Open Device Manager and then expand Universal Serial Bus Controllers.

You should see at least one item called Generic USB Hub. On some computers, you might see two, three or more of these. Right-click on the first one and choose Update Driver Software.

Update Generic USB Hub



When the update dialog pops up, choose to Browse my computer for driver software.

pick-driver-easy-solution


Then click on Let me pick from a list of device drivers on my computer at the bottom.

generic-usb-hub-problem-easy-solution


From the list, select Generic USB Hub. Normally, there won’t be anything else listed except for that one choice. Click Next and then click Close once it finishes installing it.

At this point, the Device Manager screen should refresh and either the unknown device will still be there or it may now be recognized. If it’s still showing as not recognized, then you repeat the process for each Generic USB Hub listed.


Method 8 – Uninstall USB Devices

As a last resort, you can also try uninstalling all USB devices from your system and then restarting. I mention this last because even though Windows is supposed to automatically recognize the USB controllers, hubs and devices automatically, it can sometimes fail and you’ll end up with no USB ports working.

I had a computer with 6 USB ports and only one port would not work properly. I uninstalled everything under USB Serial Bus Controllers in Device Manager and restarted. Instead of re-detecting everything, I was left with no USB port working, so be careful when using this method.

Go to Device Manager and start uninstalling each item from under USB Serial Bus Controllers. Before you start with anything that is already working, uninstall the items with exclamation points or that are listed as Unknown Device.

Unknown usb Device



Method 9 – Uninstall Hidden Devices

By default, Device Manager doesn’t show all devices that have been installed to the system. It basically only shows the ones that are currently connected. However, if you installed a USB printer earlier and now no longer use it, it will still be installed, but won’t show up in Device Manager.

Certain hidden or ghost USB devices can cause conflicts with current USB devices and therefore lead to this error. You can view hidden devices in Device Manager by first opening a command prompt and then typing the following two commands:

Hidden Devices


set DEVMGR_SHOW_DETAILS=1

set DEVMGR_SHOW_NONPRESENT_DEVICES=1

start devmgmt.msc


Once Device Manager loads, you need to click on View and then click on Show Hidden Devices.


Show Hidden Devices

Now you want to expand Imaging Devices, Universal Serial Bus Controllers and Unknown Devices. If you see anything listed there that is greyed out or that says unknown device, go ahead and right-click on them and choose Uninstall. Hopefully, removing older devices will allow newer devices to work properly.


Method 10 – Restart

Sometimes, a simple reboot fix unrecognized USB device. Plug your USB device out, wait for a few minutes, then restart your computer. Plug your USB device back in again. 


Method 11 – Try a different computer

Try plug your USB device into a different computer. If it doesn’t work on the second PC, your device could be at fault. You may want to get it repaired or buy a new one. 


Other Possible Solutions

If nothing has worked until this point, it’s pretty safe to say there could be a problem with the actual hardware. The best thing to do is to connect the device to another computer and see if it works or not. If not, then it’s definitely an issue with the device.

Possible Solution #1 – The other possible solutions are to try a different USB cable if you have one lying around. If not, just buy a new cheap USB cable from Amazon: A to B, A to Micro B, A to Mini B, or A to A. This is a fairly rare problem, but I have seen it occur a few times over my many years doing technical support.

Possible Solution # 2 – Another possible solution is to take the device, connect it to another machine and if it does recognize the device properly, to then eject it properly from that computer before reconnecting it to the original computer. I’ve seen this problem occur with several flash drives that were unplugged without ejecting properly. After connecting them to another computer and ejecting them properly from there, they suddenly started to show up on the original computer that was not recognizing them.

Possible Solution #3 – A few people have had luck getting rid of this problem by updating the BIOS. I’ve already written an article about whether it’s a good idea or not to update the BIOS, but in this case, it might be worth a try. You can also go into the BIOS and disable USB, restart the computer and then enable USB again. The only thing you need to make sure is that you have a PS2 port on your computer, otherwise you won’t be able to do anything once you disable USB in the BIOS if your keyboard and mouse are connected via USB.

Hopefully, one of the many solutions above will solve your USB problem. If not, post a comment and I’ll try to help. Enjoy!


You can see this video