Bank robbers 2.0: digital thievery and stolen cryptocoins

Imagine running down the street (and away from law enforcement) with 2,000 pounds of gold bars. Or 1,450 pounds in $100 bills. With both of these physical currencies amounting to roughly US$64 million, you’d be making quite a steal…if you could get away with it.

That’s exactly what the next generation of thieves—bank robbers 2.0—did in December 2017, when they stole more than $60 million in Bitcoin* from the mining marketplace NiceHash. It turns out stealing Bitcoin is a lot less taxing on the body.

*Disclaimer: I used the value of Bitcoins as they were at the time of the robbery. Current values are volatile and change from minute to minute.

Crime these days has gotten a technical upgrade. By going digital, crooks are better able to pull off high-stakes sting operations, using the anonymity of the Internet as their weapon of choice. And their target? Cryptocurrency.

Old-school bank robbers

The amount of money stolen from NiceHash is comparable to arguably the biggest physical heist to date, the theft of nearly $70 million from a Brazilian bank in 2005. Noted in the Guinness Book of World Records, the robbers managed to get away with 7,716 pounds of 50 Brazilian real notes. There were 25 people involved—including experts in mathematics, engineering, and excavation—who fronted a landscaping company near the bank, dug a 78-meter (256-foot) tunnel underneath it, and broke through 1 meter (about 3.5 feet) of steel-reinforced concrete to enter the bank vault.

The largest bank robbery in the United States, meanwhile, was at the United California Bank in 1972. The details of this bank robbery were described by its mastermind, Amil Dinsio, in the book Inside the Vault. A gang of seven, including an alarm expert, explosives expert, and burglary tool designer, broke into the bank’s safe deposit vault and made off with cash and valuables with an estimated value of $30 million US dollars.

What these robberies have in common is that, in order to pull them off, there were large groups of criminals involved with various special skills. Most of the criminals of these robberies were either caught or betrayed—physical theft leaves physical traces behind. Today’s physical robbers run the risk of getting hurt or hurting others, or leaving behind prints or DNA. And they are often tasked with moving large amounts of money or merchandise without being seen.

heavy loot

Bank robbers 2.0

So here comes the bank robbers 2.0. They don’t have to worry about transporting stolen goods, fleeing the crime scene, digging or blowing things up. They are in no—immediate—physical danger. And if they’re smart enough, they work alone or remain anonymous, even to their accessories. Their digital thievery has been proven successful through several methods used to obfuscate their identity, location, and criminal master plan.

Social engineering

One of the most spectacular digital crimes targeted 100 banks and financial institutions in 30 nations with a months-long prolonged attack in 2013, reportedly netting the criminals involved over $300 million. The group responsible for this used social engineering to install malicious programs on bank employees’ systems.

The robbers were looking for employees responsible for bank transfers or ATM remote control. By doing so, they were able to mimic the actions required to transfer money to accounts they controlled without alerting the bank that anything unusual was going on. For example, they were able to show more money on a balance than was actually in the account. An account with $10,000 could be altered to show $100,000 so that hackers could transfer $90,000 to their own accounts without anyone noticing anything.

The alleged group behind this attack, the Carbanak Group, have not yet been apprehended, and variants of their malware are still active in the wild.

Ponzi schemes

Bitcoin Savings & Trust (BST), a large Bitcoin investment firm that was later proved to be a pyramid scheme, offered 7 percent interest per week to investors who parked their Bitcoins there. When the virtual hedge fund shut down in 2012, most of its investors were not refunded. At the time of its closing, BST was sitting on 500,000 BTC, worth an estimated $5.6 million. Its founder, an e-currency banker who went by the pseudonym pirateat40, only paid back a small sum to some beneficiaries before going into default. It was later learned that he misappropriated nearly $150,000 of his clients’ money on “rent, car-related expenses, utilities, retail purchases, casinos, and meals.”

Hacking

Even though details are still unclear, the NiceHash hack was reported as a security breach related to the website of the popular mining marketplace. Roughly 4,732 coins were transferred away from internal NiceHash Bitcoin addresses to a single Bitcoin address controlled by an unknown party. The hackers appear to have entered the NiceHash system using the credentials of one of the company’s engineers. As it stands now, it is unknown how they acquired those, although it’s whispered to be an inside job.

Stolen wallet keys

In September 2011, the MtGox hot wallet private keys were stolen in a case of a simple copied wallet.dat file. This gave the hacker access to not only a sizable number of Bitcoins immediately, but also the ability to redirect the incoming trickle of Bitcoins deposited to any of the addresses contained in the file. This went on for a few years until the theft was discovered in 2014. The damages by then were estimated at $450 million. A suspect was arrested in 2017.

Transaction malleability

When a Bitcoin transaction is made, the account sending the money digitally signs the important information, including the amount of Bitcoin being sent, who it’s coming from, and where it’s going. A transaction ID, a unique name for that transaction, is then generated from that information. But some of the data used to generate the transaction ID comes from the unsigned, insecure part of the transaction.As a result, it’s possible to alter the transaction ID without needing the sender’s permission. This vulnerability in the Bitcoin protocol became known as “transaction malleability.”

Transaction malleability was a hot topic in 2014, as researchers saw how easily criminals could exploit it. For example, a thief could claim that his transactions didn’t show up under the expected ID (because he had edited it), and complain that the transaction had failed. The system would then automatically retry, initiating a second transaction and sending out more Bitcoins.

Silk Road 2.0 blamed this bug for the theft of $2.6 million in Bitcoins in 2014, but it was never proven to be true.

Man-in-the-middle (by design)

In 2018, a Tor proxy was found stealing Bitcoin from both ransomware authors and victims alike. A Tor proxy service is a website that allows users to access .onion domains hosted on the Tor network without having to install the Tor browser. As Tor proxy servers have a man-in-the-middle (MitM) function by design, the thieves were able to replace the Bitcoin address that victims were paying ransom to and insert their own. This left the ransomware authors unpaid, which in turn left the victims without their decryption key.

Cryptojacking

Also known as drive-by mining, cryptojacking is a next-generation, stealthy robbing trick that covers all mining activities completed on third-party systems without the users’ consent. Stealing little amounts from many can amount to large sums. There are so many methods to achieve this that Malwarebytes’ own Jérôme Segura published a whitepaper about it.

Unlike drive-by downloads that push malware, drive-by mining focuses on utilizing the processing power of visitors’ computers to mine cryptocurrency, especially those that were designed to accommodate non-specialized processors. Miners of this kind come to us in advertisements, bundlers, browser extensions, and Trojans. The revenues are hard to guess, but given the number of blocks Malwarebytes records on Coinhive and similar sites daily, criminal profit margins could be potentially record-breaking.

Physical stealing of digital currency

This last one brings us full circle, as someone actually managed to steal Bitcoins the old-fashioned way. In January 2018, three armed men attempted to rob a Bitcoin exchange in Canada, but failed miserably as a hidden employee managed to call the police. However, others have had more success. The Manhattan District attorney is looking for the accomplice of a man that robbed his friend of $1.8 million in Ether at gunpoint. Apparently this “friend” got hold of the physical wallet and forced the victim to surrender the key needed to transfer the cryptocurrency into his own account.

Summary

As we can conclude from the examples above, there are many ways for cybercriminals to get rich quick. With a lot less risk of physical harm and even less hard labor, they can score larger amounts for less risk than the old-fashioned bank robbers. The only pitfall to robbing digital currency is how to turn it into fiat money without raising a lot of suspicion or losing a big chunk to launderers.

While the diminished use of violence is reassuring, it’s still beneficial to think about how we can avoid becoming a victim. Much of it has to do with putting too much trust in the wrong people. We are dealing with a very young industry that doesn’t have a lot of established names. So how can you avoid getting hurt by these modern thieves? Here are a few tips:

  • Don’t put all your eggs in one basket.
  • Use common sense when deciding who to do business with. A little background check into the company and its execs never hurt anyone.
  • Don’t put more money into cryptocurrencies than you can spare.

Additional links

The post Bank robbers 2.0: digital thievery and stolen cryptocoins appeared first on Malwarebytes Labs.

Go to Source
Author: Pieter Arntz

Analyzing malware by API calls

Over the last quarter, we’ve seen an increase in malware using packers, crypters, and protectors—all methods used to obfuscate malicious code from systems or programs attempting to identify it. These packers make it very hard, or next to impossible to perform static analysis. The growing number of malware authors using these protective packers has triggered an interest in alternative methods for malware analysis.

Looking at API calls, or commands in the code that tell systems to perform certain operations, is one of those methods. Rather than trying to reverse engineer a protectively packed file, we use a dynamic analysis based on the performed API calls to figure out what a certain file might be designed to do. We can determine whether a file may be malicious by its API calls, some of which are typical for certain types for malware. For example, a typical downloader API is URLDownloadToFile. The API GetWindowDC is typical for the screen-grabbers we sometimes see in spyware and keyloggers.

Let’s look at an example to clarify how this might be helpful.

Trojan example

Our example is a well-known Trojan called 1.exe with SHA256 0213b36ee85a301b88c26e180f821104d5371410ab4390803eaa39fac1553c4c

detection packed

The file is packed (with VMProtect), so my disassembler doesn’t really know where to start. Since I’m no expert in reverse engineering, I will try to figure out what the file does by looking at the API calls performed during the sandboxed execution of the file.

This is the list of calls that we got from the sandbox (Deepviz):

API list

For starters, let’s have a look at what all these functions do. Here’s what I found out about them on Microsoft:

GetModuleHandle function

Retrieves a module handle for the specified module. The module must have been loaded by the calling process. GetModuleHandleA (ANSI)

GetProcAddress function

Retrieves the address of an exported function or variable from the specified dynamic-link library (DLL).

_wtoi

Convert a string to integer.

CreateStreamOnHGlobal function

This function creates a stream object that uses an HGLOBAL memory handle to store the stream contents.  This object is the OLE-provided implementation of the IStream interface.

StrStr function

Finds the first occurrence of a substring within a string. The comparison is case-sensitive. StrStrA (ANSI)

wsprintf function

Writes formatted data to the specified buffer. Any arguments are converted and copied to the output buffer according to the corresponding format specification in the format string. wsprintfA (ANSI)

WinHttpOpen function

This function initializes, for an application, the use of WinHTTP functions and returns a WinHTTP-session handle.

GetModuleFileName function

Retrieves the fully qualified path for the file that contains the specified module. The module must have been loaded by the current process. GetModuleFileNameW (Unicode)

LoadLibrary function

Loads the specified module into the address space of the calling process. The specified module may cause other modules to be loaded. LoadLibraryA (ANSI)

LocalAlloc function

Allocates the specified number of bytes from the heap.

LocalFree function

Frees the specified local memory object and invalidates its handle.

GetModuleFileName function

Retrieves the fully qualified path for the file that contains the specified module. The module must have been loaded by the current process. GetModuleFileNameA (ANSI)

ExitProcess function

Ends the calling process and all its threads.

The key malicious indicators

Not all of the functions shown above are indicative of the nature of an executable. But the API WinHttpOpen tells us that we can expect something in that area.

Following up on this function, we used URL Revealer by Kahu Security to check the destination of the traffic and found two URLs that were contacted over and over again.

GET http://twitter.com/pidoras6

POST http://www.virustotal.com/vtapi/v2/file/scan

This POST is what the VirusTotal API expects when you want to submit a file for a scan.

The link to an old and abandoned Twitter handle was a bigger mystery, until I decided to use the Advanced Search in Twitter and found this Tweet that must have been removed later on.

removed tweet

In base64, this Tweet says: https://w0rm.in/join/join.php. Unfortunately that site no longer resolves, but it used to be an underground board where website exploits were offered along with website hacking services around the same time the aforementioned Twitter profile was active.

This was a dead end on trying to figure out what the malware was trying to GET. So we tried another approach by figuring out what it was trying to scan at VirusTotal and used Wireshark to take a look at the packets.

VT packet

In the packet, you can see the API key and the filename that were used to scan a file at the VirusTotal site. So, reconstructing from the API calls and from the packets we learned that the malware was submitting copies of itself to VirusTotal, which is typical behavior for the Vflooder family of Trojans. Vflooder is a special kind of Flooder Trojan. Flooder Trojans are designed to send a lot of information to a specific target to disrupt the normal operations of the target. But I doubt this one was ever able to make a dent in the VirusTotal infrastructure. Or the one on Twitter for that matter.

The Vflooder Trojan is just a small and relatively simple example of analyzing API calls. It’s not always that easy: We’ve even seen malware that added redundant/useless API calls just to obfuscate the flow. But analyzing API calls is a method to consider for detecting malware trying to hide itself. Just keep in mind that the bad guys are aware of it too.

The post Analyzing malware by API calls appeared first on Malwarebytes Labs.

Go to Source
Author: Pieter Arntz

Netflix scam warning

Always be on your toes

While we are used to receiving scam attempts pretending to be from banks, online shops, credit card companies, and international courier services that does not mean all the other emails are safe. Far from it. To demonstrate this point we will show you a scam aimed at Netflix customers which has been used in the Netherlands and is now doing the rounds in the UK but could just as easily spread to the US.

The mail in question

The sender address, in this case, was supportnetflix@checkinformation[.]com and the content of the email informs us that there has been a problem with our last payment. Obviously to those of us who are not customers of Netflix this is the first red flag. The fact that the domain name checkinformation[.]com does not belong to Netflix is another big red flag. In fact, the domain is for sale at the moment of writing.

phishing mail

Netflix

Account disabled!

Dear User,

We’re having some trouble with your current billing information. We’ll try again. But in the meantime you may want to update your payment details. During the next login process, you will be required to provide some informations like (billing info, phone number, payment info)

So the email asks us to fill out our payment details on a site. This should always be a red flag for everyone. A security-aware company does not provide you with a clickable button to their site. They will tell you to log into their site and provide you with instructions on how to proceed. They will not provide a direct link to a page with a form to fill out asking for billing information and what not.

Pay attention to

When you have to provide such details always look for the green padlock in the address bar of your browser.

green padlock

Remember that the green padlock is not the sole condition, but it is a must before you proceed.

Another telltale sign is spelling errors, but again, the lack of them is not a definite green light to proceed. Scammers have learned that their efficiency goes up if they pay attention to their spelling.

Also never judge a site by its looks, because phishers are masters in the art of copying the layout and images from legitimate sites. In fact, they usually link to the actual layout and images of the website they are pretending to be.

Links

The Guardian: Watch out for Netflix email scam that looks like the real deal

In January another Netflix scam was analyzed by FireEye.

Guideline to help determine whether a website is legitimate.

Pieter Arntz

The post Netflix scam warning appeared first on Malwarebytes Labs.

Go to Source
Author: Pieter Arntz