Authenticating legitimate users of mobile devices in a manner that is both reliable and convenient is hard, which is why companies continue to experiment with approaches that try balance security and convenience. A freshly-minted Coin app asks users to authenticate by touching the phone’s screen to enter a sequence of short and long taps in the style of Morse code.
When starting the Coin app for the first time, the user needs to login using the traditional username/password pair. After that, the app asks the person to select a private Tap Code, which is “a Morse code-like sequence that you’ll use each time you open the Coin app. The Tap Code is a series of 6 taps, short or long.”
Anticipating the need to train people how to properly specify a Tap Code, the app requires users to practice entering a Tap Code before selecting their own, requesting that they “get a feel for long and short taps by practicing the pattern above.” Sadly, I failed several practice tests before eventually tapping in the right sequence. Tapping short and long codes is harder than you might think!
When the Coin app launches, it prompts the user to enter the “six element tap code.” The general approach of providing a quick way to authenticate to the app in lieu of typing the full password is present in many financial and other applications. However, those apps generally ask the user to enter a numeric PIN, rather than to tap a Morse-style code.
As a user of the Coin app, I struggled with the taps. Perhaps my thumb lacked the dexterity, or maybe my brain was intentionally sabotaging the experience to avoid the concentration that remembering and entering my tap sequence requires. Also, I kept forgetting my Tap Code.
When I failed to enter the correct sequence three times in a row, the app prompted for a full password as a way of deterring Tap Code guessing.
I applaud Coin’s attempt to provide an alternative to traditional PIN-based shortcut authentication approaches. Unfortunately, I find that the uniqueness of its Tap Code method negatively impacts the user experience, at least in the company’s present implementation of the mechanism. Though not as sexy, numeric PINs are familiar to people and work reasonably well. Authentication approaches based on gestures might be more familiar to users, too, especially on Android devices.
If innovative approaches to mobile authentication is interesting to you, check out these articles:
Without much fanfare, Google entered the domain registration business by announcing the private beta of its new Google Domains service in June 2014. Once invited to join the program, you can use Google Domains to purchase new domains and transfer existing ones at $12 per year. The service offers private domain registration, which lets you to keep contact details private, without additional fees.
I transferred one of my existing domains from GoDaddy to Google Domains to get a feel for the experience and to start experimenting with the service. The process was relatively painless and smooth, with Google’s browser-based tool stepping me through the necessary steps. Here’s what it was like.
Preparing the Domain for Transfer
After I entered the name of my domain into the tool, Google Domains presented an outline of 4 steps that I needed to follow to prepare the domain for transfer:
I was surprised by the need to turn off the private aspect of the domain at the originating registrar (step “b”). After submitting the transfer request, the transaction will take several days to complete, which means the contact details will be temporarily exposed. This was, perhaps, the only unpleasant aspect of the transfer process.
Importing Domain Settings
Once the preparatory steps above have been completed, Google Domains offers the opportunity to automatically transfer existing domain records and related settings:
It’s a good idea to click the “Review or edit resource records” button to tweak the settings, in which case the tool presents the following screen:
Google Domains allows you to add, edit and delete domain records. In addition, it offers a convenient way to define “synthetic records" for automatically configuring the domain to use Google App Engine or Google Apps you can also configure URL forwarding.
Keeping Domain Contacts Private
Closer to the end of the transfer application, Google Domains offers to conceal contact details that would normally be visible to the public via Whois:
Google Domain’s inclusion of the private registration option without additional fees helps this service stand out from the competition. This feature might push the established domain registrars to follow suit or at least lower their pricing to remain competitive.
Completing the Domain Transfer Process
Once the application has been submitted, Google Domains emails the administrative contact presently on file for the domain to approve the request:
"We have received your request to transfer your domain to Google Domains. We’ll need you to confirm that you’d like to proceed. Please take a moment to read the following instructions from ICANN, the nonprofit organization that oversees the use of Internet domains."
The email message includes a “Confirm Transfer” link. If the recipient doesn’t click it within 5 days, the transfer will be aborted. Note that this message is in addition to the one that the originating registrar might send out. Once the transfer has been approved, Google Domains presents the following message on its Incoming Transfers page:
"We have asked your current registrar to release redacted.com to us. The transfer of your domain will complete immediately after your registrar releases it to us. However, your registrar may take up to five days (redacted) to process your transfer request.”
What happens next? I guess I’ll find out in up to five days. In the meantime, you can learn more about Google Domains by reviewing its Help section of Google’s support website, which is available to everyone. If this piques your curiosity, you can request an invite to the beta program from Google by filling out a sadly unofficial-looking form. (Watch out, I bet scammers will start a phishing campaign around this sooner or later.)
I set up a brand new web server to see what type of connections it will receive. Since the server had no “production” purpose, all attempts to access it could be considered suspicious at best. Such requests are associated with scans, probes and other malicious activities that tend to blend into the background of web traffic. Here’s what I observed.
An Internet-Mapping Experiment by PDR Labs
The web server began receiving the following unexpected HTTP requests once or twice per day:
HEAD / HTTP/1.1
User-Agent: Cloud mapping experiment. Contact firstname.lastname@example.org
These connection attempts stood out because the HTTP requests were missing the “Accept” header and included the server’s IP address, rather than hostname in the “Host:” field (not shown here). This tends to occur with bots.
Searching the web for “pdrlabs.net” led to www.pdrlabs.net, which contained a bare-bones page stating:
"We are conducting an ongoing experiment to map the Internet in its entirety. Our crawling is not malicious in intent and does nothing more than attempt the connection; no further information is mined."
These connections originated from different IP addresses, all of which were hosted at Amazon Elastic Compute Cloud (EC2). These included 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52 and 184.108.40.206.
I didn’t find any other suspicious connections associated with these IPs so I am not too worried about this activity. Still, what are PDR Labs up to and who is behind this project? Perhaps some day these secrets will be revealed to us.
Scans for Open Web Proxies
Another set of anomalous requests, unrelated to the connections above, looked like this:
GET http:// hotel.qunar. com/render/hoteldiv.jsp?&__jscallback=XQScript_4 HTTP/1.1
Referer: http:// hotel.qunar. com/
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36
These requests stood out because the client attempted to retrieve a page from hotel.qunar.com, which was unrelated to my web server. Such connections, regardless the third-party URL they attempt to retrieve, tend to be scans for open proxies. If my web server was configured as an open proxy, it would retrieve the requested URL and present it to the client.
According to the Httpd Wiki, such open proxies could be misused to “manipulate pay-per-click ad systems, to add comment or link-spam to someone else’s site, or just to do something nasty without being detected.” Open proxies are also used to bypass corporate or government access restrictions.
I observed these connections roughly every other day. They originated from different IP addresses, all of which were registered in China. These included 220.127.116.11, 18.104.22.168 and 22.214.171.124.
Why do these scans use the hotel.qunar.com URL for its tests? I doubt the person behind them is intent on finding a way to make anonymous hotel reservations through this site. Any URL would do. However, hotel.qunar.com is specifically mentioned as an example in the onlineProxy.js tool:
* a proxy with totoro, to test online page.
step1: totoro -R http:// 10.211.55. 2:9998/proxy?target=hotel.qunar.com -a mocha
step2: this proxy, request the target url, add mocha script and case to response
step3: response the added html to totoro server
This tool is a module for Totoro, which is a free, “simple and stable cross-browser testing tool.” Perhaps the scanner was implemented by using Totoro and onlineProxy.js, with the person behind it using the example above when launching the scans. Another mystery of the web unraveled!
This wasn’t the only set of proxy connections that the server encountered. Another probe came from 126.96.36.199, which attempted to retrieve:
GET http:// www. k2proxy. com//hello.html
The connecting client specified the following User-Agent string: “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)”. The connection came from the system that, according to Spamhous CBL was infected with Torpig malware. The K2 proxy website, authored in Chinese, seems to be an effort to locate and document open proxies and appears to be maintained by email@example.com.
Yet another proxy probe came from 188.8.131.52, an IP address classified as being potentially malicious by Project Honey Pot:
GET http://www.baidu.com/ HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
A couple of seconds before submitting this HTTP request, the attacking system also attempted to connect to the server on TCP ports 135 and 1433, both of which are associated with Microsoft SQL Server activity.
Probes from Potentially-Infected Systems
Let’s move to another unusual set of connections Approximately every other day the web server received the following request:
HEAD / HTTP/1.0
These connections stood out because they were missing all other headers typically present in an HTTP connection. The requests came from different IPs, which included 184.108.40.206, 220.127.116.11, 18.104.22.168 and 22.214.171.124. These IPs were located in the US, Japan and Taiwan.
Several of these IP addresses were flagged on the Spamhous Composite Blocking List (CBL) as being associated with infected hosts. According to CBL, some of these systems were running Gameover Zeus and Hesperbot malware. Perhaps these bots were directed to scan the web looking for web servers to infect—I’m not sure, but if you have promising theories, please let me know.
Scans for phpMyAdmin Vulnerabilities
The web server also saw several requests associated with User-Agent “ZmEu”. They looked like this:
GET /MyAdmin/scripts/setup.php HTTP/1.1
Accept-Encoding: gzip, deflate
These connections stood out because they attempted to access PHP pages not present on the server and specified an unusual User-Agent. Also, they provided a “Host:” header (not shown here) that specified the web server’s IP address, rather than its hostname.
These probes came from 126.96.36.199 in Bulgaria. According to Spamhous CBL, this IP was associated with Gameover Zeus malware. The infected system attempted to access pages used by phpMyAdmin, a popular MySQL administration tool. The scanner looked for vulnerabilities in phpMyAdmin that it could exploit.
According to Phil Riesch, User-Agent “ZmEu” is used by “a security tool used for discovering security holes” in phpMyAdmin. Older web probes associated with this tool included a reference to its potential origin and pointed to a now-defunct website:
Made by ZmEu @ WhiteHat Team - www. whitehat.ro
Someone seemed to be using a bot network to scan for vulnerable phpMyAdmin systems, though the reference to “ZmEu” could have been added regardless of whether that was the tool that the attacker actually employed.
This completes the overview of the suspicious activities I observed recently on a brand new web server that should not have seen any connections. Such probes are easy to notice on a non-production system like that. On most real servers, they probably go unnoticed, blending into the noise that comprises today’s Internet traffic.
Microsoft Office documents offer a convenient way to infect systems through the use of macros. However, the attacker needs to persuade victims to enable macros after opening the booby trapped file. Social engineering is an important aspect of these attack strategies.
The defense mechanism that such malware authors need to bypass is typically the yellow security warning that Microsoft Office applications display to explain that “Macros have been disabled.” How would you persuade the document’s recipient to click the enticingly-named Enable Content?
Misrepresent the Meaning of the Security Warning
One approach attackers have employed to deal with the warning involves convincing victims that the security message indicates that the document has been somehow secured to safeguard its contents. This is a clever way of using the pretext of security, which most users don’t understand, to persuade individuals. Kimberly’s post on the use of macro viruses presents several real-world examples that utilize this approach; these documents “explained” to victims:
As convincing as such text can be for some people, sometimes victims might require additional guidance to the activate macros.
Provide Detailed Instructions for Enabling Macros
Recognizing that some of the victims might not be tech-savvy, adversaries have been known to offer step-by-step instructions for enabling macros. This helps address scenario where the person’s Microsoft Office is globally configured to disable all macros.
For instance, take the real-world malicious Word document described by Dmitry Bestuzhev. The file was called DIAN_caso-5415.doc. When victims opened this file, they saw a nicely-formatted message that the adversary embedded in the document, explaining why the content could not be shown. The text is in Spanish, because this file was sent to recipients in Spanish-speaking countries:
The text advised that to view the document’s contents, the person need to enable macros. The malicious document included step-by-step instructions for accomplishing this. The instructions accommodated multiple versions of Microsoft Word and Excel and include detailed steps and screenshots like this:
If the Approach Works, Keep Using It
According to Dmitry, the document above was sent to victims in Colombia under the guise of a tax fraud notice. Interestingly, another malicious document that incorporated the same macro-enabling instructions was observed a month later by UNAM - CERT in Mexico. In that case, the context was a bank withdrawal notification. The file was called RETIRO-COMPRA_29882.doc.
As I explained in an earlier post about SRP streams, the analysis of SRP streams in both files reinforces the notion that these documents were probably used by the same adversary to pursue victims in multiple Spanish-speaking countries, including Colombia, Mexico and Chile. In each case, the document was crafted to social-engineer the recipient to enable macros and allow the malicious code to infect the system.
If you’re like to take a closer look at these two malicious documents, you can download them from the Malwr repository links I provided above for each file. Just be careful to conduct your examination on a properly-isolated laboratory system.
P.S. For those who like this stuff, let it be know that I’ll be teaching an online malware analysis course at SANS Institute starting July.
It’s my pleasure to announce the availability of version 5 of REMnux, a Linux distribution popular among malware analysts. The new release adds lots of exciting free tools for examining malicious software. It also updates many of the utilities that have already been present in the distro. Here is a listing of the tools added to REMnux v5.
Examine Browser Malware
Examine Document Files
Extract and Decode Artifacts
Handle Network Interactions
Process Multiple Samples
Examine File Properties and Contents
Investigate Linux Malware
In addition to the newly-installed tools above, REMnux v5 includes updates to core OS components as well as numerous other utilities present in earlier versions of the distro, including Volatility, peepdf, Network Miner, OfficeMalScanner, MASTIFF, ProcDOT and others. For a full listing of REMnux v5 tools, see the XLSX spreadsheet or the XMind mind map.
A huge thank you to David Westcott, who set up and upgraded many of the packages available as part of REMnux v5, thoroughly tested them and help with the documentation. I’m also very grateful to the beta testers who reviewed early versions of this release. As always, thank you to the developers of the malware analysis tools that I am able to include as part of REMnux.
You can download the new version from REMnux.org. It’s available as a virtual appliance in VMware and OVF/OVA formats, as well as an ISO image of a live CD.
P.S. I expect the next major REMnux release to be based on a Long Term Support (LTS) version of Ubuntu and employ a modular package architecture to support incremental updates.
"You Have Been Selected for Family Resettlement to Australia," began the email that included the seal of the Embassy of Australia. "You are among the list of nominated for 2014 resettlement visa to Australia." The signature line claimed that the message had been sent by Hon Thomas Smith and came from "Australia Immigration Section <firstname.lastname@example.org>."
This was a scam, of course.
"What do I need to do?" I responded, curious what might come next. Hon Thomas Smith responded within a few hours, this time from email@example.com.
Request for Personal Information
The message attempted to mimic the letterhead of the Australian Department of Immigration and Citizenship and welcomed me “to Australia visa office.” It explained that:
"every year certain number of people are selected through our electronic ballot system for resettlement by Australia Government as part of support to Countries regarded as war zone area."
The miscreant requested that I submit a scanned copy of my travel passport, a recent photo and my phone number. In addition, I was to email a scanned white paper sheet with my fingerprints on it.
The email message included a PDF attachment that claimed to be Visa Form File/10121L-2014, which requested details such as date of birth, mother’s name and address. The PDF file didn’t have an exploit, as far as I can tell, and was merely designed as a place where the scammer’s target could conveniently provide personal information.
The scammer was pursuing this information probably with the goal of performing identity theft. Also, future interactions with the scammer would probably include a request for money to process the bogus application.
Free Sub-Domain Registration
The domain from which the scammer sent the application, immigrationsection.com.au.pn, is considered malicious by some security companies, according to VirusTotal. It redirects webs visitors to www-dot-popnic-dot-com, which some sources consider malicious.
Popnic-dot-com seems to be a front for Unionic-dot-com, which provides free domain registration, email forwarding, web hosting, URL forwarding, etc. under unusual TLDs such as .tc, .mn, .ms and others. More specifically, it offers registration under second-level domains that resemble TLDs assigned to major countries such as .uk.pn, .us.pn, .ca.pn, .au.pn, and others. No wonder it’s attractive to scammers, who want to get a domain that at a first glance seems legitimate.
With the increasing variety of TLDs available, scammers will have an easier job selecting domain names that catch the victims’ attention or evoke trust. Regardless of the domain used by the sender of the email message, if the offer sounds too good to be true and involves supplying sensitive information, it’s probably a scam.
If you are looking to get started with malware analysis, tune into the webcast series I recorded to illustrate key tools and techniques for examining malicious software:
Since the best way to learn malware analysis involves practice, I am happy to provide you with malware samples from each of these webcasts. Just send me an email after you’ve watched the webcast and confirm that you will be taking precautions to properly isolate your laboratory environment.
Examining malicious software involves a variety of tasks, some simpler than others. These efforts can be grouped into stages based on the nature of the associated malware analysis techniques. Layered on top of each other, these stages form a pyramid that grows upwards in complexity. The closer you get to the top, the more burdensome the effort and the less common the skill set.
The easiest way to assess the nature of a suspicious file is to scan it using fully-automated tools, some of which are available as commercial products and some as free ones. These utilities are designed to quickly assess what the specimen might do if it ran on a system. They typically produce reports with details such as the registry keys used by the malicious program, its mutex values, file activity, network traffic, etc.
Fully-automated tools usually don’t provide as much insight as a human analyst would obtain when examining the specimen in a more manual fashion. However, they contribute to the incident response process by rapidly handling vast amounts of malware, allowing the analyst (whose time is relatively expensive) to focus on the cases that truly require a human’s attention.
Static Properties Analysis
An analyst interested in taking a closer look at the suspicious file might proceed by examining its static properties. Such details can be obtained relatively quickly, because they don’t involve running the potentially-malicious program. Static properties include the strings embedded into the file, header details, hashes, embedded resources, packer signatures, meta data such as the creation date, etc.
Looking at static properties can sometimes be sufficient for defining basic indicators of compromise. This process also helps determine whether the analyst should take closer look at the specimen using more comprehensive techniques and where to focus the subsequent steps. Analyzing static properties is useful as part of the incident triage effort.
VirusTotal is an example of an excellent online tool whose output includes the file’s static properties. For a look at some free utilities you can run locally in your lab, see my posts Analyzing Static Properties of Suspicious Files on Windows and Examining XOR Obfuscation for Malware Analysis.
Interactive Behavior Analysis
After using automated tools and examining static properties of the file, as well as taking into account the overall context of the investigation, the analyst might decide to take a closer look at the specimen. This often entails infecting an isolated laboratory system with the malicious program to observe its behavior.
Behavioral analysis involves examining how sample runs in the lab to understand its registry, file system, process and network activities. Understanding how the program uses memory (e.g., performing memory forensics) can bring additional insights. This malware analysis stage is especially fruitful when the researcher interacts with the malicious program, rather than passively observing the specimen.
The analyst might observe that the specimen attempts to connect to a particular host, which is not accessible in the isolated lab. The researcher could mimic the system in the lab and repeat the experiment to see what the malicious program would do after it is able to connect. for example, if the specimen uses the host as a command and control (C2) server, the analyst may be able to learn about specimen by simulating the attacker’s C2 activities. This approach to molding the lab to evoke additional behavioral characteristics applies to files, registry keys and other dependencies that the specimen might have.
Being able to exercise this level of control over the specimen in a properly-orchestrated lab is what differentiates this stage from fully-automated analysis tasks. Interacting with malware in creative ways is more time-consuming and complicated than running fully-automated tools. It generally requires more skills than performing the earlier tasks in the pyramid.
For additional insights related to interactive behavior analysis, see my post Virtualized Network Isolation for a Malware Analysis Lab, a my recorded webcast Intro to Behavioral Analysis of Malicious Software and Part 3 of Jake Williams’ Tips on Malware Analysis and Reverse-Engineering.
Manual Code Reversing
Reverse-engineering the code that comprises the specimen can add valuable insights to the findings available after completing interactive behavior analysis. Some characteristics of the specimen are simply impractical to exercise and examine without examining the code. Insights that only manual code reversing can provide include:
Manual code reversing involves the use of a disassembler and a debugger, which could be aided by a decompiler and a variety of plugins and specialized tools that automate some aspects of these efforts. Memory forensics can assist at this stage of the pyramid as well.
Reversing code can take a lot of time and requires a skill set that is relatively rare. For this reason, many malware investigations don’t dig into the code. However, knowing how to perform at least some code reversing steps greatly increases the analyst’s view into the nature of the malicious program in a comp
To get a sense for basic aspects of code-level reverse engineering in the context of other malware analysis stages, tune into my recorded webcast Introduction to Malware Analysis. For a closer look at manual code reversing, read Dennis Yurichev’s e-book Reverse Engineering for Beginners.
Combining Malware Analysis Stages
The process of examining malicious software involves several stages, which could be listed in the order of increasing complexity and represented as a pyramid. However, viewing these stages as discrete and sequential steps over-simplifies the steps malware analysis process. In most cases, different types of analysis tasks are intertwined, with the insights gathered in one stage informing efforts conducted in another. Perhaps the stages could be represented by a “wash, rinse, repeat" cycle, that could only be interrupted when the analyst runs out of time.
If you’re interested in this topic, check out the malware analysis course I teach at SANS Institute.