Not all malware is ransomware, even though ransomware hogs the spotlight these days.Keyloggers are still popular in the cyberunderworld, because they help crooks to steal your passwords.
Armed with your email password, for example, crooks can pull off much more audacious crimes than ransomware, such as business email attacks, also known a CEO fraud or wire-wire scams.
That’s where a crook logs in with a stolen password to send an email that doesn’t just look as though it came from your CEO’s account, it really did come from her account.
The fraudulent email in a wire-wire scam won’t be a demand for $300 in bitcoins, which is a typicalprice-point in ransomware, but an official-sounding corporate instruction to put through a massive funds transfer.
The amount may be $100,000 or even more, and the email will typically claim that that the funds are part of time-critical business venture such as an acquisition, to justify both the large sum and the urgency.
In other words, there’s still big money in keyloggers.
One of the most popular keyloggers these days is KeyBase, a product that was originally sold as a legitimate application before being abandoned in apparent disgust by its author:
But KeyBase lives on, with cybercrooks giving it a new home all over the cybercriminal underground.
Dishonour among thieves
Sometimes crooks turn on their own kind, as happened here.
A user on the popular underground site leakforums, going by the name pahan12, popped up offering a PHP Remote Access Trojan called SLICK RAT:
The SLICK RAT download contained an installer:
But newbie crooks who ran the installer didn’t get what they paid for.
They ended up infected with the KeyBase data stealer instead, and their stolen passwords were sent off to a data-collection website. (The “Pahan” connection continued here, because the URL contained the text pahan123.)
Our guess is that Pahan was after his victims’ logins for leakforums and other hacker sites, in order to build up his rank in the underground.
He went after users on other crime forums, too, like this offensivecommunity post offering the same RAT with the same screenshot:
As it is a php rat it doesnot required any port forward.
those having problem to port forwarding or those are in restricted network firewall try this…
its having all features like othr rat
IF anyone need this email me its cost 20$
Interestingly, Pahan has a history of this sort of double-cross, promoting one cybercrime tool but infecting it with another.
Here’s an example from November 2015, when pahan was offering a malware scrambling tool called Aegis Crypter:
Cryptors take an existing malware program as input, and churn out a modified, scrambled, compressed and obfuscated program file as output, in the hope that this will bypass basic virus-blocking tools.
But Pahan’s version of Aegis included its own “secret sauce”: a zombie Trojan called Troj/RxBot than hooks up infected computers to an IRC server from which remote command-and-control instructions can be sent to the network of zombies.
The IRC channels on the server that were used by Pahan’s zombie were pahan12 and pahan123.
And in March 2016, a user going by pahann was promoting a version of the KeyBase toolkit, which can be used to generate keylogger files to order:
This KeyBase malware generation toolkit was itself infected, in a weird sort of “malware triangle”:
Amusingly (if cybercriminality can ever truly be funny), the COM Surrogate warning you can see in the popup warning above installed the very same Troj/RxBot zombie variant as the turncoat version of Aegis Crypter, as well as installing a completely different keylogger called Cyborg.
By this time, things were getting quite complicated for Pahan, who had samples of SLICK RAT for sale that were infected with KeyBase; of Aegis Crypter infected with Troj/RxBot; and of KeyBase infected with COM Surrogate, which delivered Troj/RxBot and Cyborg.
What next?
Things didn’t go so well for the duplicitous Pahan, a.k.a. Pahan12, a.k.a. Pahan123, a.k.a. Pahann, after that.
Last week [2026-08-11], when we were looking around to see what Pahan had been up to recently, we found this intriguing screenshot amongst the data and postings relating to him:
Click on image for full screen view.
We can’t be certain, but we think it’s pretty likely that Pahan/12/123/n has managed to infect himself with one or more of the malware samples he’s been juggling recently.
We think the screenshot above was grabbed from his own computer.
So, if you’ve ever wondered what a cybercrook keeps up his sleeve, this might give you some ideas: we can see a ransomware sample, various pre-prepared malware binaries, scanners, a sniffer, remote access tools and more.
Mirai evolves from the source code of Gafgyt. A new trojan named Mirai has surfaced, and it’s targeting Linux servers and IoT devices, mainly DVRs, running Linux-based firmware, with the purpose of enslaving these systems as part of a large botnet used to launch DDoS attacks.
According to security researcher MalwareMustDie! (MMD), Mirai is an evolution of an older trojan, also used for DDoS attacks, known under many names, such as Gafgyt, Lizkebab, BASHLITE, Bash0day, Bashdoor, and Torlus.
Mirai’s predecessor is no joke. According to a Level 3 report from last week, Gafgyt had infected over one million IoT devices during the past months, and there’s one crook running a Gafgyt-powered botnet of over 120,000 bots.
Mirai targets Linux Busybox firmware
Mirai’s mode of operation is largely the same as Gafgyt, targeting IoT devices running Busybox, a slimmed down version of the Linux kernel, used to power IoT devices.
The trojan also targets only a specific set of platforms, such as ARM, ARM7, MIPS, PPC, SH4, SPARC, and x86, on which IoT devices are usually built.
Mirai infects devices via brute-force attacks on the Telnet port, using a list of default admin credentials, trying to exploit cases where device owners have forgot to change the built-in password.
Once it infects a device, it reports to the C&C server and awaits commands. Mirai comes with support for launching DDoS attacks, but also brute-force attacks, used spread itself to other IoT devices.
Mirai mainly targets DVRs and IP cameras
Based on the “/dvrHelper” string found in Mirai’s source code, MMD suspects the trojan was specifically built to target DVRs and IP cameras.
The researcher also says that Mirai is either coded by the same Gafgyt crew, or its creators have copy-pasted a large chunk of its codebase into Mirai.
“ELF Linux/Mirai is the next generation of what they called it as ‘GayFgt/LizKebab/Torlus’ or what we call it as ‘Bash0day, Bashdoor, or Bashlite’ in the past,” MMD writes. “Which is desigend [sic] to be more sophisticated in aiming Linux boxes in internet for the botnet purpose (obviously for the DDoS attack cannons).”
For server administrators and sysadmins, some mitigations are available in order to filter Mirai brute-force traffic and avoid getting your servers and IoT devices compromised.
In the past few months, other researchers have spotted DDoS botnets made up of DVRs and CCTV systems, some of them as big as 25,000 bots. Other Linux trojans that have targeted IoT devices and Linux servers to enslave in DDoS botnets include PNScan and Remaiten.
Just recently I stumbled upon an Android app that lets you receive free products in various pubs, restaurants or cafes in exchange for points accumulated with previous purchases. When the purchase is made, you let the vendor know that you want to receive points. In the app you select the types of products you bought. The eligible types of products may be “Beer”, “Lunch” or“Spent 50 PLN”. It all depends on the place. In order to verify the purchase, the vendor needs to swipe a physical beacon device over your phone (or enter a PIN if that doesn’t work) and the application magically approves the transaction, granting you points.
As an example, one of the places offers you a free beer for 5 points and each purchased beer grants you 1 point. That gives you a free beer for every 5 purchased beers in that place.
Everyone likes free beer, so the first thing I thought about is how secure the purchase verification process is and how exactly do these magical beacons work?
More importantly, was there any way to get around the application’s security and get a taste of free beer?
I intentionally don’t want to mention the name of the application as it only operates in my home country (in Poland). My goal is to give you an idea of what flaws similar applications may have, how to find them and how to better secure such applications. I’ve retained all technical details on how the application works, occasionaly replacing some easy to identify IDs or private information with random data.
In this post I will use a fictional name for the discussed application – “EatApp”.
With that out of the way, let’s get started!
Doing the research
The first thing I was most curious about was the beacon technology that is used with the application. The beacons apparently communicate with the mobile phone over bluetooth as the application made it clear that bluetooth needs to be turned on for the beacon swipes to work.
After a very short time I found the company that manufactures the same beacons that I saw working with EatApp. The company is Estimote and this is what they write about their beacon technology:
Estimote Beacons and Stickers are small wireless sensors that you can attach to any location or object. They broadcast tiny radio signals which your smartphone can receive and interpret, unlocking micro-location and contextual awareness.
With the Estimote SDK, apps on your smartphone are able to understand their proximity to nearby locations and objects, recognizing their type, ownership, approximate location, temperature and motion. Use this data to build a new generation of magical mobile apps that connect the real world to your smart device.
Estimote Beacons are certified Apple iBeacon™ compatible as well as support Eddystone™, an open beacon format from Google.
Apparently EatApp application detects the restaurant’s beacon in close proximity, retrieves some identification values from the device and uses them to authorize the registration of new points with EatApp server.
Thankfully Estimote has released an SDK with a very detailed documentation.
That allowed me to learn more about what information the beacon transmits. More technical information says that:
Estimote Beacon is a small computer. Its 32-bit ARM® Cortex M0 CPU is accompanied by accelerometer, temperature sensor, and what is most important—2.4 GHz radio using Bluetooth 4.0 Smart, also known as BLE or Bluetooth low energy.
I’ve also learned that beacons broadcast the following values:
UUID – most commonly represented as a string, e.g. “B9407F30-F5F8-466E-AFF9-25556B57FE6D”
Major number – an unsigned short integer, i.e., an integer ranging from 1 to 65535, (0 is a reserved value)
Minor number – also an unsigned short integer, like the major number.
Great! They also provide their own Android library to make it very easy for any application to listen to beacon broadcasts. Here is one of the example code snippets from the tutorial on how to set up the beacon listener:
Java
beaconManager =newBeaconManager(getApplicationContext());// add this below:
beaconManager.connect(newBeaconManager.ServiceReadyCallback(){@OverridepublicvoidonServiceReady(){
beaconManager.startMonitoring(newRegion("monitored region",
UUID.fromString("B9407F30-F5F8-466E-AFF9-25556B57FE6D"),22504,48827));}});
It looks to me that the UUID number must be constant and unique to the application using it. Major and Minor numbers on the other hand can describe the product, so in EatApp scenario they must be unique for every restaurant.
Whenever the application waits for the vendor to swipe their beacon over the phone, it listens for packets with specific UUID. If the broadcast packet is detected, it uses signal strength value to measure the beacon’s proximity to the Android device. If the beacon’s signal strength indicates that the device is close enough, it uses the Major and Minor numbers from the packet as validation keys, which are sent with the authorization packet to the EatApp’sserver.
I wondered what was the maximum range over which, the beacon was able to transmit its packets. The application must be constantly listening for beacon broadcast messages as it even gives you a push notification when you enter the restaurant where EatApp beacon is present. I didn’t have to search long for an answer:
Estimote Beacons have a range of up to 70 meters (230 feet). The signal, however, can be diffracted, interfered with, or absorbed by water (including the human body). That’s why in real world conditions you should expect range of about 40–50 meters.
Wow. Up to 70 meters? That means that in theory the security keys (UUID,Major and Minor numbers), that are very likely used for authorizing the rewards, are broadcasted in clear air! That can’t be good.
Knowing that beacon broadcast packets can be received over such range, I needed to find a way how to receive the packets and read their contents. It would probably take me few days to write my own Android app using Estimote SDK, but thankfully Estimote provides their own Estimote Developer App for debugging and troubleshooting problems. From the screenshots I could tell that it gathers all the critical information.
At that moment, obtaining the beacon information would not do me much good without any insight on how the application communicates with the server. It was time to set up a small lab for intercepting and decrypting HTTPS communication from the mobile phone.
The Fiddler in the Middle
For intercepting mobile phone traffic, I’ve used a Windows box. The best and free HTTP/HTTPS Windows proxy for inspecting and forging new packets, that I know of, is Fiddler.
Setting up Fiddler
In order to enable HTTPS interception in Fiddler, open Tools > Telerik Fiddler Options > HTTPS and make sure Capture HTTPS CONNECTs and Decrypt HTTPS traffic is checked. Also make sure that under Tools > Telerik Fiddler Options > Connections, you ticked the Allow remote computers to connectoption.
You will also need to export Fiddler’s Certificate Authority certificate. In the same tab, click Actions and click Export Root Certificate to Desktop like so:
This will put a file named FiddlerRoot.cer on your desktop. This is the root certificate that Fiddler will use to generate forged certificates for every HTTPS connection that goes through the proxy. Obviously Fiddler’s generated root certificate won’t be on your phone’s list of trusted certificate authorities and any HTTPS connection that goes through the proxy will be blocked. That’s why you need to import Fiddler’s certificate on your phone and add it to trusted CA storage.
To do that, first copy the FiddlerRoot.cer to the SD card on your phone by any means. On your phone open Settings > Security and select Install from SD card:
Find and pick Fiddler’s certificate file in order to import it. Now your phone will trust Fiddler’s proxy and you will be able to intercept and decrypt HTTPS traffic. You need to make sure that both your phone and your Windows box with Fiddler are running on the same network.
Before you proceed, find out which port Fiddler’s proxy listens on, by openingTools > Telerik Fiddler Options > Connections and checking the port box:
Next, find out the local network IP address of your Windows box. Open upcmd.exe command line prompt and type in ipconfig. You should be able to find your current IP address under the section with the network interface that you are currently using.
On your Android phone, open up Settings > Wi-Fi and find the wireless network that you are connected to. Touch the network entry for 2 seconds and select Modify network from the drop-down menu. In the dialog tick Advanced options and scroll down to proxy settings. For the proxy type you need to setManual and under hostname and proxy port enter the IP address of your Windows box and the Fiddler’s proxy port. I entered 192.168.0.14 as the hostname and 9090 as the proxy port number.
Now if everything went fine, you should be able to see the outgoing mobile phone traffic in Fiddler.
Capturing traffic
With this setup I was able to intercept EatApp’s traffic as the application didn’t implement certificate pinning. Otherwise, it would require more work to be done. I’d have to decompile the application, remove the certificate comparison check and recompile the application.
I opened up EatApp and opened up Earn Points dialog for randomly picked restaurant. As I didn’t have the restaurant’s Estimote Beacon on me (duh!), I had to use the option to enter the PIN number to verify the point rewards. I entered the random PIN number and checked the intercepted packets in Fiddler.
The request is not complicated. Parameters are sent as JSON data, there are no hash values being sent as a form of anti-tampering method with account state verification and the PIN is sent just in plain-text. The parameters are pretty self explanatory:
authentication_token – This is the account’s authentication token that was received from the server during the login process. This value is unique to every EatApp account and won’t change.
promoted_products_ids – the array of product type IDs that we are earning points for.
pin – the PIN number that we’ve entered.
place_id – the unique ID of the restaurant where we want to earn points.
isDoneByGesture – this one is a mystery, but I believe it is set to true only when you spend your points.
longitute and latitude – These are the last known GPS location values that were retrieved recently, letting the server know user’s exact geographical location. This could be used as a security measure to detect if we are not too far away from the restaurant we are receiving points in.
At this point I wanted to try out if the application is vulnerable to PIN brute-forcing. After all, there are only 10’000 possible PIN combinations. Unfortunately after sending about 5 requests with different PIN values, I started to receive the following reply from the server:
HTTP
HTTP/1.1 422 Unprocessable Entity Server: nginx
Date: ...
Content-Type: application/json; charset=utf-8
Content-Length: 289
Connection: keep-alive
Vary: Accept-Encoding{"status":"422 Unprocessable Entity","code":"pinTooManyAttempts","title":"Too many pin code attempts","header":"Account locked","message":"Earning and spending points and redeeming deals using your account has been locked for the next 30 minutes. Please let us know if this is a mistake."}
Unless I had hundreds of EatApp accounts that I could switch between during the brute-force process, the 30 minutes account lockdown is a pretty strong deterrent.
Looking at the parameters of the verification request, I wondered what would the parameters be if the verification was done with the beacon swipe rather than with entering the PIN.
One idea of how free points could be earned, would be to remotely intercept the request packet with the correct PIN value entered by the restaurant’s staff. Intercepting the packet remotely would also give me an opportunity to find the exact request parameters if beacon swipe was used instead of the PIN.
Main obstacle in performing this task is that I had to intercept the request from the mobile device, while I was at the restaurant.
That was a great opportunity to try setting up the interception VPN that would be used with 3G/4G connection on my mobile phone. The VPN server would then intercept and decrypt the HTTPS traffic the same way Fiddler did.
The Evil VPN
First of all, I required a VPS where I could install the VPN software. The fastest, easiest and most reliable way to set up a Linux box VPS is Digital Ocean (you will get 10$ credit if you sign up from this link). I created the cheapest Debian 8 1CPU 512MB RAM droplet for 5$/month or 0.007$/hour. This had to be more than enough for my needs.
I had to decide which VPN protocol I wanted to use. Android officially supports PPTP and L2TP types of VPN protocols. I’ve learned though that although PPTP is supported, it is considered insecure and Google doesn’t trust it enough to enable Always-On feature for this kind of VPN. Always-On VPN feature in Android makes sure that your phone will reconnect to the VPN whenever the connection breaks and makes sure that no other packet will ever be sent NOTthrough the VPN. This is very important as I wanted to be absolutely sure that every single packet gets intercepted and decrypted.
Finding a good tutorial that would teach me how to install L2TP VPN on Debian 8 was very hard as most tutorials were written for Debian 7 and apparently in the later version of the system some dependencies changed and the tutorials became outdated.
Finally I found a perfect way to install IPsec/L2TP VPN with auto setup scripts. This is basically all I had to do on the server:
Bash
wget https://git.io/vpnsetup -O vpnsetup.sh
nano -w vpnsetup.sh
[Replace with your own values: YOUR_IPSEC_PSK, YOUR_USERNAME and YOUR_PASSWORD]sudo sh vpnsetup.sh
YOUR_IPSEC_PSK – this should be you preshared key phrase (e.g. mysecretpskforvpn). YOUR_USERNAME and YOUR_PASSWORD – your username and password to login into the VPN.
All done in fire and forget manner! The VPN was up and running. Now it was time to set up the VPN connection on my phone. I went to Settings > Wireless & Networks (More) > VPN and added a new VPN and filled the settings as follows:
Now that the VPN was added, I clicked the triple-dot Settings button in the same window and clicked Always-On option and then picked the newly created VPN connection.
This is when I ran into a problem on my Android 6.0. No matter how hard I wanted the VPN to connect, it would always show connection error. I tried on another Android 4.4 device and it worked perfectly, so I knew something was wrong with the latest version of Android. The Github page of the auto script did mention a workaround for Android 6 Marshmellow:
Note: Android 6 (Marshmallow) users should edit /etc/ipsec.conf on the VPN server and append ,aes256-sha2_256 to both ike= and phase2alg= lines. Then add a new line sha2-truncbug=yes immediately after those. Indent lines with two spaces. When finished, run service ipsec restart.
That didn’t work, so I removed that “fix” from the server config files. Shortly after, I found a feature in the VPN profile settings called Backwards-compatible mode. I set that to Enable and *bang* – finally everything started to work.
Now that I had a working VPN, it was time to set up the interception and decryption of HTTPS packets. For that I decided to use SSLsplit software. Installation was easy:
Bash
wget http://mirror.roe.ch/rel/sslsplit/sslsplit-0.5.0.tar.bz2
tar jxvf sslsplit-0.5.0.tar.bz2
cd sslsplit-0.5.0
makesudomakeinstall
The IPSec/L2TP installation script created some advanced firewall settings for my new VPN setup and honestly I was not able to adjust it in such a way that allowed me to redirect HTTP/HTTPS packets to sslsplit proxy. I decided to completely purge the iptables settings and replace the iptables config file with the clean one, including some settings for redirecting packets to sslsplit.
Packet forwarding should already have been enabled (and should be re-enabled at every boot), because of the VPN auto setup script, but in order to be sure, you could run:
Bash
echo 1 > /proc/sys/net/ipv4/ip_forward
Next, I prepared the directory structure for sslsplit log files and created thesslsplit root certificate that will be used for generating forged HTTPS certificates the same way that Fiddler did before:
I had to download sslsplit/certs/ca.crt root certificate from the VPS, copy it my phone’s SD card and import it as trusted certificate authority. That way my Android phone would allow any forged certificate generated by sslsplit to be accepted. You could easily download ca.crt file from your VPS via SSH protocol on Windows using WinSCP.
In order to easily turn on and off our HTTP/HTTPS interception, on the server, I decided to create two small shell scripts (my sslsplit directory was put in /root/):
Now whenever I wanted to start intercepting packets, I’d run ./start.sh and if I wanted to stop, ./stop.sh. Simple. The sslsplit was configured to run as a daemon and it would log all raw packets into separate files in /root/sslsplit/logs/ directory. The logging feature of sslsplit is not perfect as it doesn’t fully decode saved HTTP packets, it doesn’t group packets in request/reply order and will put several packets into one file if they are sent at the same exact second, but for my needs it had to do fine. I will later describe how I overcame the HTTP decoding issue.
With the VPN setup done and HTTPS interception in place, I was finally able to drive to town, eat something and do some live packet capturing!
Trip to town
I visited three places and ordered some food in each one of them. During checkout I asked the vendor to register some EatApp points for the products I just had. At that point my phone was all the time connected to the interception VPN and the authorization packets were logged on the server by sslsplit.
I found out that if the location permission was turned off, the beacon proximity feature wouldn’t work, thus in two places the staff had to use the PIN authorization. I retrieved two packets with correct PIN values in the first two places and in the third place I was able to capture the beacon authorization packet, after I enabled the location permission for the app.
Finally I had an opportunity to check out the official Estimote developer’s app that was supposed to detect nearby beacon broadcasts and retrieve the broadcasted UUID, Major and Minor. It turned out my theory was correct:
I still had to confirm at home if the broadcasted authorization keys were really used in the authorization packet, by analyzing the sslsplit log files.
Connecting the dots
I downloaded the sslsplit log files from the server. The issue with sslsplit is that it will log all HTTP packets in their raw form. Meaning that if the Transfer-Encoding is chunked or packet is compressed with gzip, the packets won’t be logged in decoded plain-text form.
I have released a small script that is supposed to decode the sslsplit packets into clear text form. Please note that script uses a quite buggy http-parserlibrary that I decided to use for parsing HTTP packets. For simple needs, though, it is “good enough”. You can find splitparse.py on Github here.
Jackpot! I confirmed that the UUID, Major and Minor numbers were exactly the same in the request authorization packet and detected live with the Estimote developer’s app. That meant my theory was correct and the verification keys are constantly being broadcasted over the air in every EatAppsupported restaurant.
To summarize, here is the step-by-step guide on how to get free EatApp points in restaurant ZZZ:
Walk into restaurant ZZZ.
Open up Estimote developer’s app and detect the closest nearby beacon.
Save the screenshot with the visible UUID, Major and Minor values.
Go home.
Set a breakpoint in Fiddler to intercept EatApp packets with /users/ path in GET requests.
On your phone, select the ZZZ restaurant and set EatApp to await PIN authorization for earned points.
Enter any PIN.
Modify the intercepted packet in Fiddler, removing the "pin":"NNNN" entry and replacing it with the valid "main_beacon":{...} content containing the beacon keys captured with Estimote app.
Let the modified packet through to EatApp server.
Enjoy your free points!
Of course it would be much better to write you own tool to directly communicate with application’s server API while implementing proper location spoofing. The method I described is just quicker and easier for testing purposes.
Conclusion
Broadcasting authorization keys publicly over the air is never a good idea. Here is the list of things that could be done to improve EatApp’s security:
Send a hash value of account’s current state as an additional request parameter (points for every restaurant, account name, last sent GPS location etc.). The server would then verify if the hash is correct and only then authorize the request. Finding out how the hash parameter is formed would not be possible without disassembling and reverse engineering the application’s code. That would add additional difficulty.
In order to make reverse engineering harder, the application’s code should be obfuscated. If the additional hash verification parameter was implemented, it would greatly increase the difficulty of reverse engineering the application’s code.
@FabricatorGeneral mentioned in the comment section that it is possible to enable Secure UUID feature in Estimote’s beacons that would broadcast the beacon keys in encrypted form. That way only applications with the correct API key would be able to decrypt it. Bypassing that would require writing a custom mobile application implementing Estimote SDK, that would listen to broadcasts, decrypting them with application’s API key, that would have to be retrieved first by reverse engineering the application’s code.
Certificate pinning should be implemented to make it harder to intercept the HTTPS connection using forged certificates. This security feature could also be bypassed, but it would involve reverse engineering the application, finding where the certificate verification check is done, removing it and recompiling the application again.
Not sure if that is possible with Estimote Beacon’s, but it would be good to provide restaurants with a second beacon that would be used only for authorizing transactions with maximum broadcast range of half meter.
Never trust the client’s device! For maximum security, client’s device should only send the reward request to the server, without any authorization keys. Afterwards, the server would send the authorization request to vendor’s dedicated tablet behind the counter, requesting him to authorize the point rewards with proper keys. Beacon swiping or entering the PIN would only be done on vendor’s device, thus making it impossible for the client to intercept the request that he could later use to create forged packets.
A new ransomware that pretends to be from a fake organization called the Central Security Treatment Organization has been discovered by security researcher MalwareHunterTeam. When the Central Security Treatment Organization, or Cry, Ransomware infects a computer it will encrypt a victim’s files and then append the .cry extension to encrypted files. It will then demand approximately 1.1 bitcoins, or $625 USD, in order to get the decryption key.
Payment Site Header
Based on analysis by myself, MalwareHunterTeam, and Daniel Gallagher, this infection exhibits some interesting characteristics not commonly seen in ransomware. For example, like Cerber, this ransomware will send information about the victim to the Command & Control server using UDP. Furthermore, it will also use public sites such as Imgur.com and Pastee.org to host information about each of the victims. Last, but not least, it will query the Google Maps API to determine the victim’s location using nearby wireless SSIDs.
This ransomware is still currently being analyzed and it may be discovered that decryption is possible. Therefore, victims may want to monitor the Central Security Treatment Organization Support Topic for updates.
As with many ransomware infections, it is hard to provide a descriptive name, so for the purposes of this article the ransomware will be referred to as the Central Security Treatment Organization Ransomware, CSTO Ransomware, or Cry Ransomware.
Command & Control Server Communication Methods
When a victim is infected, the ransomware will compile a variety of information such as the Windows version, the service pack installed, the Windows bit-type, the user name, the computer name, and the type of CPU installed in the computer. This information will then be sent via UDP to 4096 different IP addresses, with one of them being the ransomware’s Command & Control server. The use of UDP packets is probably being done to obfuscate the location of the Command & Control server so that authorities cannot seize it.
UDP Traffic
The Cry Ransomware will also upload the same information as well as a list of encrypted files to Imgur.com. It does this by compiling all of the information into a fake PNG image file and then uploading it to a designated Imgur album. Once the file has successfully been uploaded, Imgur will respond with a unique name for the filename. This filename then be broadcasted over UDP to the 4096 IP addresses to notify the Command & Control server that a new victim has been infected.
Finding a victim’s location based on nearby SSIDs
Using the Google Maps API, a user can determine the location of a querying device by the SSIDs of nearby wireless networks. This ransomware uses the WlanGetNetworkBssList function to get a list of nearby wireless networks and their SSIDs. It will then query the Google Maps API using these SSIDs to get the victim’s location.
It is unsure what this is currently being used for, but this information could be used to generate an image of the victim’s location using Google maps. This could then be used to further scare the victims into paying the ransom.
How the Central Security Treatment Organization Ransomware Encrypts Files
When this ransomware infects a computer it make a backup of certain shortcuts on the victim’s Windows desktop and save them in a folder on the desktop called old_shortcuts. The purpose of this folder is currently unknown.
The ransomware will now encrypt the victim’s files and append the .cry extension to encrypted files. The files currently targeted by this ransomware are:
During this process it will also delete the system’s Shadow Volume Copies using the command:
vssadmin delete shadows /all /quiet
In order to provide persistence, the ransomware will create a random named scheduled task that will trigger when the user logs into Windows.
Scheduled Task
Finally, the ransomware will create ransom notes named !Recovery_[random_chars].htmland !Recovery_[random_chars].txt on the victim’s desktop.
Ransom Note
This ransom note will contain the victim’s personal ID and instructions on how to access the TOR payment site as shown above. Information about this Payment site can be found Central Security Treatment Organization’s payment site can be found in the next section.
The Central Security Treatment Organization Ransomware’s TOR Payment Site
The ransom notes created by the Central Security Treatment Organization Ransomware contain links to a TOR payment site that has a Window title of User Cabinet. When a user visits this site, they will be prompted to login using the personal code from their ransom note.
Login Page
Once a victim logs in, they will be shown a page that states that it is part of some fake organization called the Central Security Treatment Organization and will contain the ransom amount that a victim must pay.
Tor Payment Site
Other sections on the site include a payment page that lists the bitcoin address that the payment must be sent to. There is also a support page that a victim can use to communicate with the malware developers.
Support Page
The payment site will also include a free decryption of one file to test that they can actually decrypt a victim’s files.
Free Decrypt
When a file is submitted to the free decryption, it will decode it while you wait.
Decrypting the Free File
In my tests, though, the free decryption failed and the decrypted file was not made available. With that said, if you do plan on paying the ransom, you may want to confirm that this feature works before doing so in order to test the decryption.
Files associated with the Central Security Treatment Organization Ransomware:
LuaBot is the latest addition to the Linux malware scene. A trojan coded in Lua is targeting Linux platforms with the goal of adding them to a global botnet, security researcher MalwareMustDie! has reported today.
For an operating system with a minuscule 2.11 percent market share, this is our third story on Linux malware in the past 24 hours, after previously reporting on the Mirai DDoS trojan and the Umbreon rootkit.
LuaBot falls into the same category as Mirai because its primary purpose is to compromise Linux systems, IoT devices or web servers, and add them as bots inside a bigger botnet controlled by the attacker.
LuaBot most likely used for DDoS attacks
At the time of writing, this botnet’s purpose is currently unknown, but MalwareMustDie told Softpedia on Twitter that the code for launching packet floods (DDoS attacks) is there, only that he wasn’t able to confirm the functionality yet.
At the moment, the LuaBot trojan is packed as an ELF binary that targets ARM platforms, usually found in embedded (IoT) devices. Based on his experience, this seems to be the first Lua-based malware family packed as an ELF binary spreading to Linux platforms.
Unlike Mirai, which is the fruit of a two-year-long coding frenzy, LuaBot is in its early stages of development, with the first detection being reported only a week ago and a zero detection rate on VirusTotal for current samples.
Since it’s only a one-week-old malware strain, details are scarce about its distribution and infection mechanism.
LuaBot author challenges security researchers
MalwareMustDie has managed to reverse-engineer some of the trojan’s code and discovered that the bot communicates with a C&C server hosted in the Netherlands on the infrastructure of dedicated server hosting service WorldStream.NL.
The researcher also found that LuaBot’s brazen developer left a message behind for all the infosec professionals trying to deconstruct his code. The message reads, “Hi. Happy reversing, you can mail me: [REDACTED .ru email address].”
Additionally, MMD also discovered code labeled as “penetrate_sucuri,” alluding to features capable of skirting Sucuri’s infamous Web Application Firewall, a cyber-security product that has stopped many web threats in the past.
MMD told Softpedia that “it seems the function is there […] coded with that purpose,” but the researcher later admitted that “I don’t know the Sucuri WAF much, so I can not test it.” Softpedia has reached out to Sucuri, and we’ll update the article if this function proves to be a successful firewall bypass or just an unfinished piece of code.
A mobile banking trojan called Trojan-Banker.AndroidOS.Gugi.c, or “Gugi” for short, found no problem bypassing a couple of the security measures introduced in Android 6.
The name of the game is social engineering when it comes to a Gugi infection.
According to Kaspersky Lab’s senior malware analyst Roman Unuchek, the trojan first infects a device by posing as a spam SMS message that reads as follows:
“Dear user, you receive MMS-photo! You can look at it by clicking on the following link.”
If clicked, the link begins downloading Gugi onto the device.
The malware then faces its first test.
In response to an expanding field of Android ransomware–which includes samples that havemasqueraded as adult apps, infected Android smart TVs, and demanded ransom in the form of iTunes gift cards–Google built into Android 6 a feature that requires an app to request permissions if it wants to overlay its window over another app.
For Gugi, that’s nothing a little social engineering can’t fix. As Unuchek explains:
“The first thing an infected user is presented with is a window with the text ‘Additional rights needed to work with graphics and windows’ and one button: ‘provide.’… After clicking on this button, the user will see a dialog box that authorizes the app overlay (‘drawing over other apps’).”
Flipping that switch surrenders control of the device to Gugi. Indeed, with the ability to overlay other apps, the trojan initiates a series of requests for additional permissions by abusing another feature of Android 6: a dynamic request capability that allows mobile apps to ask for additional permissions after they have been installed.
Among other things, Gugi requests to be made device administrator, a status which allows the malware to act as a regular mobile banking trojan by opening up phishing pages for banking credentials and stealing contacts/SMS messages off the device.
If the user denies Gugi’s requests, they face their own set of consequences, as Unuchek rightly notes:
“Should the user deny permission, subsequent requests will offer them the option of closing the request. If the Trojan does not receive all the permissions it wants, it will completely block the infected device. In such a case the user’s only option is to reboot the device in safe mode and try to uninstall the Trojan.”
Currently, Gugi is targeting users living in Russia primarily, but it could set its sights on other demographics in the coming weeks and months.
Kaspersky Lab intends to release a report on Gugi soon. In the meantime, users should protect themselves against an infection by exercising caution around suspicious links and email attachments, by reviewing app permission requests carefully, and by keeping an up-to-date antivirus solution installed on their devices.
According to security researcher Timothy Davies, a new version of the Locky Ransomware, aka Zepto, has been circulating since around the September 5th 2016 that includes an embedded RSA key. This key allows Locky to encrypt a victim’s computer without having to contact their Command & Control server. As many system administrators block Command & Control servers on their firewalls, by using an embedded RSA key, Locky can encrypt a computer regardless of what has been blocked at the edge.
Embedded RSA Key
The good news is that this version is having distribution problems as there attachments are not being named properly. For example, a current campaign is using ZIP attachments that contain JS files. When executed, these files are giving an error as seen below.
Scripting Error
This error is occurring because the attachments are actually HTA files and not JS files. Once the file is renamed to HTA, it works properly.
Other than that, this version continues to append the .ZEPTO extension to encrypted files and create ransom notes that are named %Desktop%\[number]_HELP_instructions.html, %Desktop%\_HELP_instructions.html, and %Desktop%\_HELP_instructions.bmp.
This version is targeting the following extensions for encryption:
The Dridex banking trojan might be involved in fewer attack campaigns, but its developers are still outfitting it with some new functionalities, including the ability to target crypto-currency wallets.
Nicholas Griffin, senior security researcher at Forcepoint, explains Dridex relies on two lists to target users’ banking credentials:
“These lists have gradually expanded over the months and years, and now include back-end payment and point-of-sale software, online banking software, and a recently added list of crypto-currency wallet managers.”
But that’s not all the latest version of the banking Trojan has to offer.
Dridex also collects several pieces of information from each infected computer and sends it to its command-and-control (C&C) server. That data includes the infected computer’s name, user name, OS installation date and version, and a list of installed software.
If that information passes a series of criteria, the C&C server responds with the malware payloads. If it doesn’t, it sends over a 403 HTTP error code. The C&C server can take it one step further and even blacklist a machine to prevent researchers from taking a look at the malware’s internals.
Finally, Dridex has moved to a multi-layered encrypted binary format to further complicate analysis.
But as Griffin explains, that doesn’t prevent researchers from accessing the malware’s main configuration file:
“Despite the protections put in place by the Dridex developer(s), it is still very much possible to reconstruct the Dridex settings configuration file received by the core module. This configuration file includes the list of banking websites to capture data from and inject code into when infecting a user’s browser.”
For years, Dridex has been one of the most prolific banking trojans. That changed in October 2015, when the UK’s National Crime Agency partnered with the FBI and other security partners to sinkhole the malware.
At that point, Dridex slowed down, but didn’t cease, its activity. The banking trojan experienced aresurgence in the late-2015, only to decline once again after the Necurs botnet temporarily went offline. It’s currently still active, but its distributors have since begun using their infrastructure to spread Locky ransomware instead.
Given Dridex’s persistence, users should exercise caution around suspicious email attachments and URLs and disable Microsoft Office macros by default.
Backdoor.OSX.Mokes.a is the most recently discovered OS X variant of a cross-platform backdoor which is able to operate on all major operating systems (Windows,Linux,OS X). Please see also ouranalysis on the Windows and Linux variants.
This malware family is able to steal various types of data from the victim’s machine (Screenshots, Audio-/Video-Captures, Office-Documents, Keystrokes)
The backdoor is also able to execute arbitrary commands on the victim’s computer
To communicate it’s using strong AES-256-CBC encryption
Background
Back in January this year we found a new family of cross-platform backdoors for desktop environments. After the discovery of the binaries for Linux and Windows systems, we have now finally come across the OS X version of Mokes.A. It is written in C++ using Qt, a cross-platform application framework, and is statically linked to OpenSSL. This leads to a filesize of approx. 14MB. Let’s have a look into this very fresh sample.
“Unpacked” Backdoor.OSX.Mokes.a
Its filename was “unpacked” when we got our hands on it, but we’re assuming that in-the-wild it comes packed, just like its Linux variant.
Startup
When executed for the first time, the malware copies itself to the first available of the following locations, in this order:
$HOME/Library/App Store/storeuserd
$HOME/Library/com.apple.spotlight/SpotlightHelper
$HOME/Library/Dock/com.apple.dock.cache
$HOME/Library/Skype/SkypeHelper
$HOME/Library/Dropbox/DropboxCache
$HOME/Library/Google/Chrome/nacld
$HOME/Library/Firefox/Profiles/profiled
Corresponding to that location, it creates a plist-file to achieve persistence on the system:
After that it’s time to establish a first connection with its C&C server using HTTP on TCP port 80:
The User-Agent string is hardcoded in the binary and the server replies to this “heartbeat” request with “text/html” content of 208 bytes in length. Then the binary establishes an encrypted connection on TCP port 443 using the AES-256-CBC algorithm.
Backdoor functionality
Its next task is to setup the backdoor features:
Capturing Audio
Monitoring Removable Storage
Capturing Screen (every 30 sec.)
Scanning the file system for Office documents (xls, xlsx, doc, docx)
The attacker controlling the C&C server is also able to define own file filters to enhance the monitoring of the file system as well as executing arbitrary commands on the system.
Just like on other platforms, the malware creates several temporary files containing the collected data if the C&C server is not available.
Hacking video demo shows government spyware in action.Have you ever wondered how does a government-sanctioned hacking actually work? Well, unless you are employed in a police department, or are a middleman who sells spyware software, or if you’ve worked in one of these companies, it is unlikely that you may have seen a live demo of how a spyware works.
However, a new 10-minute-video obtained by Motherboard, shows an Italian surveillance contractor called RCS Lab demo the hacking tool intended for use by police forces and government agencies. It also shows that the cops need very little technical knowledge to remove a scary level of information from a target’s computer.
The video shows off a software product from Italian firm RCS Labs called Mito3, which allows the RCS employee to set up these kinds of attacks with ease by just applying a rule in the software settings. RCS’s website explains this product as a “monitoring center” that “retrieves, decodes, processes and stores contents coming from virtually any kind of communication network.”
The RCS employee can select whatever site he or she wants to use as a vector, click on a dropdown menu and select “inject HTML” into an innocent-looking website. This then creates a malicious popup that prods the victim to download a Flash update. From there, the computer is hacked, even though a fake update appears to happen on screen to appease the user. Once the user downloads the fake update, he or she is infected with the spyware.
“All this installation process is, in reality, is completely a fake. It’s sort of a movie,” the RCS Lab employee says in the video. “Because in reality, at this point, he’s already infected.”
Mito3 allows the user easily hack a victim’s computer and gain access to the screen, intercept text messages, voice calls, video calls, social media activities, chats, microphone, webcam, and even GPS location. It even provides automatic transcription of the recordings, according to a confidential brochure obtained by Motherboard.
While the demo in the video doesn’t display any surprising hacking capabilities, it is the simple user interface and the speed at which it is done, which is shocking. Also, the video gives us an insight of how surveillance vendors try to sell their malware to governments around the world.
Movie and TV watchers who download pirated content have long been warned of the potential for malware that might accompany their chosen media. Now use is again being made of Digital Rights Management (DRM) functionality — designed to prevent piracy — to distribute malware.
The new attack, brought to Cyren’s attention by security researcher Amitay Dan, abuses a DRM popup message function that is built into Windows Media Player.
In normal legitimate operation the feature works like this:
A content provider embeds an authorization URL in their DRM protected content that will be displayed in the Media Player window, to allow the user to acquire a license to play the content
A content user opens (the legitimately downloaded) content in Media Player
Media Player pops up a message “You do not have rights to play this file” along with the authorization URL and a security warning.
The user needs to click on “OK” to open a window to the authorization URL, so that the user can enter credentials or pay to acquire the content
The content owner authorizes the content and the content user can now watch/listen to the legitimate content
The abuse of this DRM link functionality was first reported over 10 years ago (and it resurfaces every few years) – but it appears that the threat is little known and is now being used once again. The malware version goes like this:
User downloads infected media – in this case “War-Dogs-2016-720p-BrRip-x264-SiNNERS”. In this case the media was downloaded using BitTorrent – but could come from any download source.
When the .wmv file is opened in Media Player the DRM warning message pops up listing the URL of the malware distributors
Clicking on “Yes” opens up a similar small window, this time showing content created by the malware distributors with the message (given verbatim here), ”As this video is built in advanced 2016 .Xvid codec you might face difficulties playing the video without latest codecs. But for the quality of the Video the .Xvid codecs are essential. So If You want to play the video, Please download the Codec and after installing that you will be able to play almost all the video and audio files available till date.”
As shown, the window for “xvidcodecrepair.com” includes a prominent “Download Now” button. Clicking on “Download Now” results in download of an executable file “codecfix.exe”. Codecfix.exe is detected by Cyren as dropper/downloader malware. In addition to installing the dropper, the process also retrieves the latest Divx install — from the legitimate Divx servers — and starts a real Divx install, apparently to give the victim the impression that an actual codec is being installed.
The manufacturer USBKill.com has commercialized USB Kill 2.0, a USB dongle that is able to fry any computer through the USB ports.
The Hong Kong-based technology manufacturer USBKill.com has created a USB dongle that is able to fry any computer into which it’s plugged by using an electrical discharge. The attack is simple, the USBKill use to charge capacitors from the USB power supply, and then discharges 200 volts DC over the host device.
The designer of the USBKill presented a prototype last year, the USB device was able to destroy a laptop in a few seconds. Now they have presented the USB kill 2.0, a final release that is commercialized by USBKILL.com team.
“Our tests reveal that more than 95% of all devices using USB ports will be damaged permanently or completely destroyed by a USB power surge attack”. explained the researchers behind the project that explained they created the USB kill 2.0 for testing purposes. The unique device that passed the tests is the latest version of Apple’s MacBook, which uses surge-protected USB ports.
The company warns it has been “designed and tested to be safe,”, it “is a high-voltage device — it is not a toy — and is only intended for responsible adults.”
Hardware developers could use the USB device to evaluate the resilience of their machine against such kind of “devastating power surge attacks” and to prevent data theft via “juice jacking.”
“Any public facing USB port should be considered an attack vector. In data security, these ports are often locked down to prevent exfiltration of data, or infiltration of malware, but are very often unprotected against electrical attack!” reads the press release.
“When the USB Kill stick is plugged in, it rapidly charges its capacitors from the USB power supply, and then discharges — all in the matter of seconds,” the company said in a news release.
The Juice jacking is a cyber attack where wherein malware might be installed on to, or data surreptitiously copied from, a mobile device or other computer device using a charging port that doubles as a data connection.
Below a video PoC of the KillUSB 2.0.
The USB Kill 2.0 could cause serious damage to the host, despite it isn’t designed to wipe data depending on the hardware configuration it could have this effect by destroying drive controllers.
“When tested on computers, the device is not designed or intended to erase data. However, depending on the hardware configuration (SSD vs platter HDD), the drive controllers may be damaged to the point that data retrieval is impractical,” the company said in its marketing material.
USB Kill also said the device was created for use by hardware designers of public machines, such as photo booths, copy machines, airline entertainment systems and ticket terminals — anything with exposed USB ports that need to “ensure that their systems resist electrical attacks.”
“Finally, the general public, or anyone who wants to test or kill their own devices should equip themselves,” the company stated. “Penetration testers and security auditors should include the USB kill 2.0 to their arsenal of testing tools.”
The technology manufacturer USBKill.com also offer for sale a USB Protection Shield specifically designed to allow the testing of the USB Killer without damaging the host machine.
The USB Kill 2.0 stick costs around $56, meanwhile the Test Shield will go for about $15.70.
The USBKill.com “strongly condemns malicious use of its products.”
Malware authors have made around $86,400, so far. A malware variant named Mal/Miner-C (also known as PhotoMiner) is infecting Internet-exposed Seagate Central Network Attached Storage (NAS) devices and using them to infect connected computers to mine for the Monero cryptocurrency.
Miner-C, or PhotoMiner, appeared at the start of June 2016, when a report revealed how this malware was targeting FTP servers and spreading on its own to new machines thanks to worm-like features that attempted to brute-force other FTP servers using a list of default credentials.
Miner-C now specifically targets Seagate Central NAS hard drives
This same functionality is still present in the latest Miner-C version, but security researchers from Sophos say that recent Miner-C iterations are using a design flaw in the Seagate Central NAS devices to place a copy of itself on their public data folders.
NAS devices, which are network-connected hard drives, allow users to access files from the local network, but also via the Internet if the administrator chooses to open the NAS drive for remote access.
According to Sophos, Seagate Central devices contain a public folder accessible to all users, even anonymous non-logged-in users, which can’t be deactivated or deleted.
Miner-C tricks users into installing the cryptocurrency miner
Miner-C is copying files to this public folder on all Seagate Central NAS devices it can find. One of the files it copies is called Photo.scr, a script file that malware coders have modified to use a standard Windows folder icon.
Because Windows has a bad habit of hiding file extensions, whenever the device owner accesses their NAS, they see this file as a folder, fooled by the fake icon.
When they try to access the folder, they’re actually executing the Photo.scr file, which installs a cryptocurrency mining application on their PC.
Public and private folders on Seagate Central NAS drives
Miner-C also features a modular structure made of different parts that do different things, and it uses a unique method of loading its config file.
“Since it generates a new initialization file when it is launched, it helps the malware avoid security solutions. It also gives the botnet operators a chance to change the payload of the threat in the future, for example, dropping ransomware to the victim’s machine after the mining business is no longer profitable,” the Sophos team explains in a technical report.
Miner-C mines for Monero only
Right now, Monero is one of the most profitable cryptocurrencies from when it comes to mining operations. While Bitcoin mining difficulty has increased many times over the years, PC-based Bitcoin mining has ceased to be profitable in 2012 and is currently only an option if you’re using special hardware and dedicated data centers.
Monero is one of the few cryptocurrencies that can still be mined using regular PCs, hence the reason the crooks chose it.
There are around 5,000 Seagate Central NAS devices infected
According to telemetry data Sophos researchers gathered, Miner-C has infected around 70 percent of all Seagate Central NAS devices available on the Internet.
Researchers discovered around 7,000 Seagate Central NAS devices connected to the Internet, which means crooks managed to infect around 5,000 such devices.
Since all the accounts to which crooks collect Monero are stored in the malware’s config file, Sophos was able to estimate that they have made around €76,600 ($86,400) from their operations until now and are currently responsible for 2.5 percent of the entire Monero mining activity.
The quandary is that Seagate Central owners have no way to protect their device. Turning off the remote access NAS feature can prevent the infection, but also means they lose the ability to access the device from a remote location, one of the reasons they purchased the hard drive in the first place.
Experts from Dr Web discovered a new Linux Trojan called Linux.BackDoor.Irc.16 that is written in the Rust programming language.
It is a prolific period for Vxers working on Linux Trojan, a new strain was recently spotted by experts from Doctor Web. The new Linux Trojan has been named Linux.BackDoor.Irc.16 and is written in the Rust programming language.Rust is a general-purpose, multi-paradigm, compiled programming language promoted by Mozilla Research. It is designed to be a “safe, concurrent, practical language.”
“Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety. “
“Unlike the majority of its counterparts, Linux.BackDoor.Irc.16 is written in Rust, a programming language whose creation was sponsored by Mozilla Research. ” reported Dr. Web in a blog post.
The Linux.BackDoor.Irc.16 Linux Trojan implements the features of a classical backdoor that allow attackers to remotely control the infected system by sending it via the IRC (Internet Relay Chat) protocol.
Once the Linux Trojan is executed it connects to a specific public chat channel that is indicated in its configuration, then it waits for commands.
According to malware researchers from DrWeb, the Linux Trojan is able to execute just four commands: It can connect to a specified chat channel; send cybercriminals information about an infected computer; send cybercriminals data about the applications running in a
Connect to a specified chat channel;
Gather information on the infected host and send them back to the crooks;
Send crooks data about the applications running in the system;
Delete itself from an infected machine;
The experts spotted a first stable version in 2015, according to Dr Web, the Linux.BackDoor.Irc.16 backdoor was designed to be a cross-platform malware. The experts who have analyzed the threat speculate it is a prototype for an ongoing project, they noticed in fact that it Linux Trojan is not able to replicate itself and the IRC channel used as C&C infrastructure are no more active.
“Doctor Web’s analysts believe that Linux.BackDoor.Irc.16 is, in fact, a prototype (Proof of Concept), because it cannot replicate itself, and the IRC channel used by the Trojan to receive commands from cybercriminals is not currently active.” reported Dr Web.
Recently other Linux malware were spotted in the wild by security experts such as the Linux.Rex.1 that is capable of self-spreading and create a peer-to-peer botnet and Linux.Lady that is used by crooks to mine cryptocurrency.
These days, parents can easily end up installing RATs instead of legitimate parental control software. Parents looking for a way to monitor their child’s online activities may turn to malware known as Remote Access Trojans (RATs) due to their proliferation and low cost.
There’s a difference between RATs and parental control software, which some might also call spyware. Unlike the latter, RATs don’t come with blocking features.
Parental control software, while it’s as intrusive as RATs and logs certain details about how a child uses his device, does provide a parent with the ability to block certain apps from the device, proving to be useful in some other way than just spying on kids.
On the other hand, RATs don’t provide a similar feature. Parents looking into installing parental control software might cross the boundary from legitimate software to full-on malware due to a lack of understanding on what differentiates the two products.
It’s easy to end up on a RAT’s homepage these days
Parents looking at software packages like mSpy, TeenSafe, Mobile Fence, or PhoneSherrif, all legitimate parental control software, might very easily end up installing malware like Revenge, Orcus, Ozone, JBifrost (Adwind), Remcos, or Darktrack.
All of these are commercially available RATs advertised on legitimate-looking sites as remote administration tools or parental control software when they don’t provide anything outside the ability to sniff on the computers they infect.
They price points between which these products are sold is the same as for commercial parental control software.
Parents should stick with known & reviewed brands only
In some cases, RATs come backdoored out of the gate by the crook distributing it, so while the parent keeps an eye on his kid, the RAT author is keeping an eye on both. Parents should always do research before buying or installing anything on their kids’ devices.
There’s a growing trend around the world of parents deploying apps on their kids’ smartphones to monitor and block calls, SMS, and apps, just like there’s a trend for kids that install apps to hide their activities from parental control software.
Parents should be very careful about the products they choose to deploy. Telling kids that they keep an eye on the way they use their devices is also recommended because parents avoid losing the child’s trust and end up alienating them in the end.
High-pitched sound destroys bank’s data storage drives. Problems during a planned fire drill shut down ING Romania’s entire data center for ten hours on Saturday, in an event that looked like a MythBusters episode.
The fire drill involved the release of Inergen gas, a type of inert gas used to extinguish fires in data centers without damaging equipment.
Not everything went was planned during the release of the Inergen gas, which resulted in abnormal and high-pitched sound levels that resonated and affected the bank’s data storage hard drives, causing them problems writing and reading data from their disks.
Everything was down. Everything!
This resulted in the damaging of some equipment and the immediate shutdown of the entire bank’s suite of services. At around 13:00 local time, the bank’s entire ATM infrastructure stopped functioning, along with its PoS services, online payment system, Homebanking service, commercial website, and even internal email and ticketing support system.
This left the bank in the awkward position of not being able to communicate with its clients for a few hours.
The first to figure something was wrong were Softpedia’s Romanian forum users. Attempts from Softpedia to contact the bank at that time were unanswered.
This was not an ATM heist or SWIFT attack, even if it looked like one
Due to the wide-reaching and devastating blackout of its IT system, it took the bank over four hours to post its first message on its Facebook account. An ING spokesperson told Softpedia at the time that this was “a general technical issue.”
Users complained on Facebook, Twitter, and forums, and speculation about cyber-attacks was rampant. The bank’s website, which often came back online only to succumb a few minutes later, presented the classic signs of a DDoS attack.
The shutdown of its entire ATM and transactions service on a weekend day also made some speculate that a SWIFT attack or a coordinated ATM heist had taken place. These latter attacks often occur during weekends, when banks aren’t fully staffed.
Safety and security procedures delayed the data restoration process
Bank services started coming back online after 20:00 local time and were fully restored by 23:00 the same day. On Sunday morning, the bank issued a statement about what happened during the previous day.
ING Romania explained that while it would have been easy to restore from a backup and start services immediately, due to the highly sensitive data found on its data center’s storage servers, they had to follow a strict set of procedures and tests before putting each of its services online.
The bank is currently undergoing a diagnostics and analysis phase of the entire incident. ING Romania also apologized for its failure to inform customers of the issues earlier, but said this would have been practically impossible since it couldn’t reach its customer database at that point in time.
Bank officials say they’ll reimburse costs to all ING clients who used ATMs of other banks to withdraw money on Saturday.
Softpedia collaborated on this story with Andrada Fiscutean. You can read more about the science behind the data center’s failure in her Motherboard feature. Below is a video released by the bank’s PR staff from Saturday’s mini-crisis.
Targets foot hardware and electricity costs of mining Monero coins. Attackers are draining the CPU and power resources of thousands file transfer protocol servers by infecting them with malware that surreptitiously mints the relatively new crypto currency called Monero, researchers said.
A notable percentage of the 3,000 or so infected servers are powered by Seagate Central, a network-attached storage device that allows users to remotely retrieve files using FTP connections, according to a report published Friday by researchers from antivirus provider Sophos. The Seagate device contains a weakness that allows attackers to upload malicious files to any device that has been configured to allow remote file access, the report said. Once users inadvertently click on the malicious files, their systems are infected with Mal/Miner-C, the malware that mines the Monero coins.
Sophos Senior Threat Researcher Attila Marosi estimated that Mal/Miner-C has already mined Monero coins valued at 76,599 Euros (about $88,347) and has the ability to earn about $481 each day. While new crypto coins sold on the open market don’t always fetch their entire estimated value, the earnings are nonetheless significant, since virtually all the hardware and electricity costs are borne by the people hosting the infected servers. The researcher went on to calculate that the infected servers comprised about half of the monorepool.com pool. The estimate was based on the infected servers having the capacity to generate 431,000 hashes per second when mining Monero coins, while the overall pool as measured by monoepool.com was 861,000 hashes per second. That translated to about 2.5 of the entire mining community.
Just add social engineering
The malware has no known abilities to spread automatically. Instead it takes advantage of FTP servers that allow anonymous users to upload to a public folder. As it turns out, Seagate Central devices allow such anonymous usage whenever remote access has been enabled, a setting that Marosi said allowed them to host much of the malware found. Attackers who found such servers uploaded a file that was disguised to look like a screensaver installer. When end users clicked on it, their systems were infected.
Over the past six months, Sophos has seen about 1.7 million Mal/Miner-C detections from about 3,000 different IP addresses. The large number of detections is the result of malware running in multiple directories. Marosi also scanned the Internet and found about 2.1 million IP addresses actively hosting FTP servers. Of those, 7,263 servers had write access enabled and 5,137 were hosting Mal/Miner-C files.
“More than 70 percent of the servers where write access was enabled had already been found, visited and ‘borrowed’ by crooks looking for innocent-sounding repositories for their malware,” the Sophos report stated. “If you’ve ever assumed that you’re too small and insignificant to be of interest to cybercriminals, and thus that getting security settings right is only really for bigger organizations, this should convince you otherwise.”
Shark Ransomware Project rebrands as Atom. The Shark Ransomware Project has recently rebranded and switched to a new domain in an attempt to start from scratch, calling itself Atom – a ransomware affiliate program.
The change comes after a series of news articles that gave it a bad reputation, including ours, published last month, in which we called it “scammy-looking.”
When it appeared, Shark was unique among other RaaS (Ransomware-as-a-Service) offerings because it used a website hosted on the public Internet, instead of Tor, like most of its rivals.
Shark was offering users a ransomware builder that allowed them to create their own Shark ransomware version. Crooks could customize Shark to their liking, and then use spam or exploit kits to infect victims.
Users paying the ransom would send the money to Shark’s creator Bitcoin wallet, who would keep 20 percent and forward the rest to the person who infected the victim.
Atom comes with a GUI payload builder
When accessing Shark’s website today, we got redirected to a new website promoting the Atom ransomware affiliate program.
Under the hood, Atom works almost the same way as Shark. It offers a payload builder and uses the same 80-20 percent cut as Shark did before being taken down.
The glaring change is that Atom uses a nice graphical user interface to build the ransomware. Shark previously used a terminal-based builder with users having to pass customization settings via command-line options.
Atom now includes a web panel for displaying campaign statistics
This builder generates the ransomware payload, the final EXE file that crooks need to deliver to victims, but also prints out a ransomware campaign ID.
Crooks deploying the Atom ransomware can enter this ID on the Atom website and access a web panel that shows details about the number of infected victims and earned money.
We called this ransomware operation “scammy” in our first report, and we still stand by that opinion. The ransomware still requires victims to make Bitcoin ransom payments to Atom’s creator Bitcoin wallet, with no guarantee that Atom subscribers will receive their 80 percent cut. At any time Atom’s creator can have a change of heart and shut down his operation, keeping a big chunk of the funds.
In a report released today, Fortinet took a look at how a typical Atom ransomware infection works. You’ll find in it technical details regarding Atom’s C&C server communications, not included in this article.
It is a good day when a ransomware programmer channels their noobness and releases an insecure ransomware. This is the case with a new variant of the NoobCrypt Ransomware that was discovered by security researcher Jakub Kroustek. Living up to its name, the developer of NoobCrypt uses the same encryption key for every victim. This allowed Jakub to easily retrieve the password and post it on Twitter for victims to use.
NoobCrypt gets its name from taunts found in the executable’s source code. These taunts would be displayed when victim’s enter various passwords in the key field to try and decrypt their files. For example, as seen by the source code below, when a victim enters 123, the ransomware would display an alert that taunts them with the message “123 is not the code! You idiot. GO PAY IF U WANT UR PC BACK. NOOB HAH”.
Taunts in NoobCrypt Source Code
Looks like the joke is on the ransomware dev, as thanks to Jakub we have a list of known decryption keys that a victim can use to decrypt files affected by NoobCrypt.
Decrypting NoobCrypt
When a user is infected with NoobCrypt they will be shown a ransom lock screen like the one below. This lock screen will state “Your personal files are encrypted”, that it was “Made in R0MANIA”, the bitcoin address a payment must be paid to, and the amount of the ransom.
NoobCrypt Lock Screen
As each release of NoobCrypt has a specific bitcoin address and ransom amount that associated with that release, we can use this information and the table below to determine the decryption key. With the help of Jakub, the known list of passwords and how to identify what version you are infected with is below.
Version
Ransom Amount
Bitcoin Address
Decryption Key
1
$299
1JrYNuMaE4VXKrod2gA9keBo6nzPvtaoZ6
ZdZ8EcvP95ki6NWR2j
2
$100
1MCLTT5qAqpabSSuKnYecRt1ZQyF6aaQFe
ZdZ8EcvP95ki6NWR2j
3
$50
14YNpHUw3J2t6uhm2zcfQgrjVM5xR99iwE
lsakhBVLIKAHg
Once the associated decryption key is identified, a vicitm needs to enter it into the Key field of the ransom screen and then click the Check button. If the key is accepted, it will display a message and decrypt the victim’s files.
Key was accepted
If the key is not accepted, simply send us a sample of the executable and we will retrieve the key for you.
Number of DualToy infections is on the rise. A trojan targeting Windows computers is secretly sideloading mobile applications to any Android or iOS devices the user is connecting to infected PCs via USB cables.
The trojan, named DualToy, has been active since January 2015, but in its original form, it was only capable of infecting Android devices.
DualToy received support for infecting iOS devices six months later, but the number of real-world infections only recently spiked, according to a Palo Alto Networks report, reaching 8,000 different samples detected in the wild.
Trojan downloads and installs ADB, iTunes drivers for Windows
Under the hood, DualToy is coded in C++ and Delphi, and the first thing it does after infecting a computer is to download and install the Android Debug Bridge (ADB) and the iTunes drivers for Windows.
These two applications are used by the trojan’s process to interact with any device connected to the PC.
The trojan assumes that any device attached to the computer is the owner’s device. As such, the trojan uses pairing/authorization records already found on the user’s PC to try and authenticate on the mobile device that’s connected via a USB port.
Trojan downloads and installs rogue mobile apps
After successfully accessing the device, DualToy contacts it’s C&C server, gets a list of apps to install, downloads the apps, and then installs them on the user’s device.
To avoid complications with the app installation process, for Android devices, DualToy also downloads special code from the C&C server and runs it on the device. This code roots the device and gives DualToy the ability to install apps without user interaction, in the phone’s background.
For iOS devices, the trojan downloads and runs code that collects details such as IMEI, IMSI, ICCID, serial number and phone number. The purpose of this operation is currently unknown.
DualToy steals Apple IDs and passwords
Also for iOS devices, DualToy will collect the user’s Apple ID and password, and send it to its C&C server. Palo Alto notes that this behavior is similar to the AceDeceiver iOS trojan.
All the apps installed by DualToy are used to show ads, which generate a profit for the trojan’s operator.
DualToy isn’t harmless. If the user never connects a mobile device to the infected PC, the trojan will modify browser settings in order to inject ads in accessed websites.
“Although this attack vector’s capability can be further limited by additional mechanisms (e.g., ADB enabling, iOS sandbox) which make this threat not so severe, DualToy reminds us again how attackers can use USB sideloading against mobile devices and how malware can be spread between platforms,” Claud Xiao, security researcher for Palo Alto, said.
As it is a php rat it doesnot required any port forward.
