Anti-Virus industry has changed a lot during that past 4-7 years, we like other companies, used to be very file signature and file scanning oriented back in 2008 or so. And as that obviously did not scale, we moved into detecting more useful patterns of attacks, and started focusing on preventing infections in the first place rather than trying to detect files dropped by already successful attacks.
Doing things the smart way requires good visibility, so we had to start doing big data. Or should we say big information, since any fool can collect massive amount of data, the trick is in converting big data into small and understandable information. However in order to do data mining we have to collect data from our users, which can be a problematic from privacy point of view. Which has lead into people asking just what kinds of data we are collecting and how we are processing it.
So in order to answer these questions we wrote a white paper detailing information collected by our Internet Security range of products. The whitepaper is readable here.
The basic principle of our data collecting is to collect only what we need and anonymize it as early as possible. All data that can be sanitized in the client is already stripped there so that we get system data, but will not taint our database with anything that looks like users personal data. The data that cannot be sanitized at the client, such as client IP address, will be stripped out in the first server that processes the data. We also run regular cleanups in our customer data to remove any user related data that would have escaped multiple layers of import sanitization.
We do continue out work on knowing everything that is needed to stop attacks, but still making sure that we do not end up knowing anything about our users.
Our Mobile Threat Report for Q1 2014 is out! Here's a couple of the things we cover in it:
The vast majority of the new threats found was on Android (no surprise there), which accounted for 275 out of 277 new families we saw in this period, leaving 1 new malware apiece on iOS and Symbian.
In Q1, our Mobile Security product users mostly reported encountering trojans that did some form of silent SMS-sending (mainly from the Fakeinst and SMSSend families). It should be interesting to see how the 4.2 update to the Android OS (which requires user confirmation when premium-rate SMSes are sent) impacts these trojans.
This was an active quarter for mobile malware development, with a number of "firsts" reported. There was Trojan:Android/Torsm.A, the first one to use Tor to hide its communications with its command and control server. The first bootkit, Trojan:Android/Oldboot.A, was reported, as well as a trojan that tries to turn the phone into a silent cryptocurrency miner (Trojan:Android/CoinMiner.A).
Then there is the Dendroid toolkit, which promises to make creating Android trojans as simple as clicking a few buttons - and apparently comes with a lifetime warranty too. Much like virus construction kits and exploit kits did before for PC-based threats, Dendroid would make malware creation much more accessible to anyone without the technical skills to do it themselves.
And this is all just in the first three months of 2014.
More details are in the Mobile Threat Report, which is available on the Labs site, or by clicking on the images below. There's two versions of it available:
In a surprising turn of events, it appears that Browlock is now targeting Russians.
If for some reason, some unfortunate fellow ends up in an infected site that has been prepended with the Browlock link.
This "browser locker" will be served after 5 seconds of being on the infected page:
The page appears to be in very well written Russian that is loosely translated to: Ministry of Russian Federation Internal Affairs (Police Ministry)
[The ministry] detected that your computer has been used for doing wrong things which are illegal such as looking at materials related to violence, gay pornography and pedophilia.
Such activities are forbidden in accordance with [some law being quoted]. Such activity will cause a penalty of 800 to 4000 Rubles and if you don't want to pay, you will go to prison in accordance with [some law being quoted].
As it is already done, you now have to pay 1000 rubles. The payment of this penalty can be done via any mobile terminal (sample of this below) or you can put this sum to the phone number: +79054014516. You have to perform this payment in 12 hours.
After completing the payment, you will be given a confirmation of payment and there you'll see the unlocking code which should be entered in the field below. If you don't want to pay, then all the materials about these illegal activities will be sent to the prosecutor's office for initiating criminal proceedings. And a group of policemen will be sent to your place of residence.
Here is a sample mobile terminal image that was referred above:
When the user attempts to close the browser or tab, this will appear:
The "browser locker" page appears to render the browser unusable, however, it's just an elongated dialog box and a simple pressing of the ENTER key will close the browser and no harm will be done to your computer.
So far, it has only worked on the Chrome Browser but the page loads properly when accessed from different countries including Russia.
Browlock page has now been blocked by Browsing Protection.
On Sunday, Android Police (a popular news and review site) published a post on "Virus Shield" — an app which reached top ranking in Play, and yet, was a complete fraud. In a follow up, DailyTech did some digging and believes the app was written by a 17 year-old Texan. Apparently he's good at SEO.
Whether he's the guy or not… it fits the typical profile. A young person with good SEO skills pushing a rather useless app.
Lame "SEO apps" are prevalent on Google Play. They're easy to find if you look.
Best and SAFE link to one "developer" — while Skulls and Shnarped Hockey link to another.
Though there are two different developers… the apps are identical apart from their name. The apps appear to be based on a template (there are markets for app templates) and all the so-called developers have done is to add their own graphics.
Android apps: no developer skills required.
So what do the apps do?
Well, the "antivirus" open sa screen label "anti spyware".
Hmm, the terms changed. That ought to be a warning sign.
Click "Start Scan" and the app does a basic scan of permissions for installed apps. Apps with a large number of permissions are categorized as a risk and those with a low number of permissions are called safe. And if you want to see the details? Well, then you need to buy the "full" version of the app for about a buck. In our humble opinion, the folks who bought the full versions (more than one thousand) completely wasted their money.
Google Play: caveat emptor.
P.S. If you want an app that does an advanced scan of permissions and provides excellent details entirely FREE of charge…
As you have to update your SSL anyway, why not make sure your configuration is up to modern standards?
There has been plenty of noise about Heartbleed, so if you're an admin, you already know what to do.
1. Find everything you have using vulnerable versions of OpenSSL 2. Update to the latest OpenSSL version 3. Create new private keys and SSL certificates as the old ones may have leaked 4. Revoke old certificates
But since you have to touch your server configuration and create new SSL certificates, we would recommend that you also go through certificate generation settings and server configuration. Heartbleed is not the only problem in SSL/TLS implementations, a poorly chosen protocol or weak cipher can be just as dangerous as the Heartbleed bug.
Now that we got our hands on a sample of the latest Word zero-day exploit (CVE-2014-1761), we can finally address a frequently asked question: does F-Secure protect against this threat? To find out the answer, I opened the exploit on a system protected with F-Secure Internet Security 2014, and here's the result:
Our Internet Security 2014 blocked the threat using the exploit interception feature introduced in DeepGuard version 5. And the best part is we didn't need to add or modify anything — the zero-day was blocked by the exact same detection that was already included in the initial release of DeepGuard 5 in June 2013. This means that our users were protected against this threat long before we even got a sample, and also several months before the attack was reported by Microsoft. DeepGuard 5 shows the power of proactive, behavior based protection again (and again).
And the good news is: a patch for the Word vulnerability appears to be in the pipeline. It's critical that everybody still using Office 2003 apply this update. Why? Because it will only take days for the patch to be reversed and for related exploits to be injected into exploit kits. At which point, browsing the web becomes considerably more hazardous for anybody with Office installed. Particularly if your browser is configured to "open" RTF files.
So prepare to patch next Tuesday! Do it.
Do you still have plans to use XP post-April 8th? Check out this Safe and Savvy post:
Malware that targets search engine results is nothing new. Malicious browser extensions are also familiar (which typically contribute to stuff such as Facebook scam campaigns). But very recently, we've identified a noteworthy malware family that attempts to do both. We've named it: Coremex. It takes advantage of plugin functionality provided by browsers to hijack different search engine results � taking on online advertising giants such as Google and Yahoo.
Coremex comes as a single NullsoftInstaller executable file which acts as both dropper and downloader. Upon execution of the executable, the downloader will start collecting basic information from the infected machine. For example: the username, the infected workstation name, processor, memory, et cetera. The information will be sent to a command-and-control (C&C) server address, 178.86.17.32, which is hard-coded in the binary. The information is encrypted with RC4 with a key of "2AJQ8NA4" and the final result will be encoded with Base64.
There are some anti-sandbox features implemented by Coremex that prevents it from downloading the main payloads, such as the browser extension scripts, from the C&C server. These features consist of checking blacklisted process names and looking for well-known sandbox fingerprints such as a "VMware" string on the infected machine by using Windows Management Instrumentation (WMI).
Figure 1. Blacklisted process name in hash:
Figure 2. Anti-Sandbox name in hash:
If the anti-sandbox component does not raise a red alert, Coremex will then proceed to download additional payloads from the C&C server. However, the author uses a different C&C server to download payloads (at least during the time of our analysis).
After the payload is downloaded successfully, they will be silently installed by Coremex. Afterwards, the browser extension will reside in the browser process whenever the victim opens Chrome or Firefox.
Coremex's JavaScript is highly obfuscated with 3 layers of obfuscation to make the analysis harder. Behind the scenes, Coremex's JavaScript will register a couple of events using the API provided by the browser and wait for these events to be triggered.
One of the event listeners will be run once in an hour. Upon execution of the event callback function, it will start connecting to the following bogus search engine websites:
• onlinetrack.org • zvtracker.com
While the other event listeners are responsible to parse the URL that the affected browser is going to visit. The callback function of these event listeners will look for the search query entered to the following search engine platforms:
Figure 4. A list of search engine platforms targeted by Coremex:
When a targeted search engine platform is found and after successfully parsing the search query from the URL, Coremex first transforms the victim's entered search query into a JSON format:
The JSON object will then be encrypted with RC4 algorithm with key "http" and the result will be encoded with Base64. The Base64 encoded string will be sent to presumably the author's controlled search engine platform:
In the server's response, it contains an encrypted JSON object with a list of destination website that will determine where a webpage that has ads-like URL will be redirected to. An example of Google AdWords URL might look like this:
Figure 5. Code responsible to parse Google AdWords URL pattern:
The decrypted JSON object might look like:
The following screenshot shows Coremex script in action when an ad's URL is clicked by the victim which leads to the ad's page being hijacked and redirected to author's intended destination website.
Figure 6. Google AdWord URL is being hijacked:
Click image to embiggen.
Figure 7. Google AdWord page is hijacked with IFRAME:
Click image to embiggen.
Regarding the injected IFRAME to the hijacked ad's page: during analysis, the server never replied with the destination website. So we have not yet seen examples of where the hijacked Ad will be redirected. But it is clear that the author's intention is to take advantage of popular online advertising services.
Lets start by stating that we know this blog post is dated April 1st. However, this is not an April Fools joke.
In 2013, a series of attacks against European governments was observed by Kaspersky Lab. The malware in question, known as MiniDuke, had many interesting features: it was tiny in size at 20KB. It used Twitter accounts for Command & Control and located backup control channels via Google searches. It installed additional backdoors onto the system via GIF files that embedded the malware.
As most APT attacks, MiniDuke was distributed via innocent looking document files that were emailed to targets. In particular, PDF files that exploited the CVE-2013-0640 vulnerability were used.
To investigate similar cases, we have created a tool for extracting the payloads and the decoy documents from MiniDuke PDF files. With this tool we were able to process a large batch of potential MiniDuke samples last week. While browsing the set of extracted decoy documents, we noticed several ones that had references to Ukraine. This is interesting considering the current crisis in the area.
Here are for examples of such documents:
The attackers have collected some of these decoy documents from public sources. However this decoy file that resembles a scanned document is unlikely to be found from any public source:
The document is signed by Ruslan Demchenko, the First Deputy Minister for Foreign Affairs of Ukraine. The letter is addressed to the heads of foreign diplomatic institutions in Ukraine. When translated, it's a note regarding the 100th year anniversary of the 1st World War.
We don't know where the attacker got this decoy file from. We don't know who was targeted by these attacks. We don't know who's behind these attacks.
What we do know is that all these attacks used the CVE-2013-0640 vulnerability and dropped the same backdoor (compilation date 2013-02-21).
We detect the PDF as Exploit:W32/MiniDuke.C (SHA1: 77a62f51649388e8da9939d5c467f56102269eb1) and the backdoor as Gen:Variant.MiniDuke.1 (SHA1: b14a6f948a0dc263fad538668f6dadef9c296df2).
Updated to add: These examples were found by mining old samples. The cases above are from 2013. So far, we haven't found Ukraine-related Miniduke samples that would have been used in 2014.
