Trend Micro to Deliver Threat and Data Protection for Microsoft Azure Customers
Expanded relationship will provide comprehensive security to companies transitioning workloads to the cloud
When Software Collides! What to do with your old antivirus program.
Running multiple antivirus programs on the same computer can cause conflicts resulting in false positives, a slowdown in performance, or system instability. Question of the week: Can I have more than one antivirus program on my computer at a time? This is a good question to ask the week that security geeks are discussing the […]
Privacy Fears Spawn New Generation of Low Profile Social Networks
Is the era of oversharing over? Recent revelations about state-sponsored surveillance and mega-breaches engineered by cybercrime gangs have put the issue of privacy in the spotlight. After more than a decade where people appeared to be sharing more and more details about themselves online, there is some evidence that a backlash is now underway. Certainly the founders of a number of new social networking services seem to think so and they have made privacy one of the main selling points of their offerings.
One effort at building a more anonymous social network is Secret. Its creators decided to move in the opposite direction to most social networks and minimize the personal information its users share. Available as either an iOS or Android app, it doesn’t use real names or profile photos. Users instead anonymously share text and images. Their posts are shared with other friends who are also on Secret, but users are not told which of their friends authored the post. They can choose to share those posts with their own friends and, if a post goes two degrees beyond its author, it is shared publicly and marked with its broad location (e.g. California).
Secret goes to some length to reassure its users of their privacy. For example, it markets itself with the fact that customer data is stored on Google servers – the same servers used in Gmail – and all communications are encrypted with TLS. Message data is encrypted before being written to its servers and keys are stored in an off-site keystore service that rotates keys. When the app connects a user with someone they know from their contacts book, it doesn’t send phone numbers or email addresses to Secret’s servers. Contact details are locally hashed with a shared salt and the server then compares them against other hashed values.
Secret’s arrival is a sign that social media moguls have spotted which way the wind is blowing. The app was developed by online publishing platform Medium, which was founded by Evan Williams and Biz Stone. Williams was a co-founder of blogging platform pioneer Pyra Labs (and credited with coining the phrase “blogger”) and was later a co-founder of Twitter.
The latest service to launch is Cloaq, which goes far beyond Secret in the level of anonymity it offers its users. Users don’t have to provide any personal information when they sign up, such as their name, email address or phone number. Instead, they choose their own password and Cloaq assigns them a user ID. The company is handing out accounts in batches, e.g. @alpha1 through to @alpha999 and so on. The downside of having such an anonymous service is that anyone who does forget their user ID or password has no way of retrieving it.
In addition to new social media ventures, established operators have also begun to perceive a market for private services. For example, Twitter chief executive Dick Costolo recently said that the company is exploring the option of introducing a “whisper mode” that will allow its users to move conversations into the private sphere. While the company already has a private direct messaging feature, Costolo indicated that the whisper mode would allow for a smoother transition between public and private conversations. Additionally, he indicated that the feature could enable private conversations between more than two people.
Revelations about surveillance have also prompted some of the main online service providers to beef up their privacy measures. For example, Google has now moved to a default encrypted HTTPS connection whenever a user of its email service Gmail logs on. Furthermore, the company said that it was encrypting all traffic on its data center network, meaning that Gmail data will also be encrypted if it moves between Google servers. The move is intended to allay privacy fears following revelations about state-sponsored surveillance of traffic between data centers.
Google isn’t the only company moving to enhance customer privacy. Yahoo has followed suit, switching on HTTPS as a default on Yahoo mail and encrypting traffic between its data centers. Microsoft too has responded to privacy concerns. Likening the threat posed by surveillance to that presented by malware, the company is encrypting content moving between itself and its customers, in addition to encrypting data center traffic.
Whether a permanent shift towards greater anonymity is underway remains to be seen. However it is clear that the entire industry, from start-ups to the major players, has recognized that it is, for now, a key concern for consumers.
What Spam Would Mom Like This Year?
On May 11, 2014, many countries will celebrate Mother’s Day. Plenty of online articles have been giving gifts ideas and advice for making the day special for mom. Companies have also been sending a huge number of promotional emails with a special message about Mother’s Day. Unsurprisingly, spammers have been exploiting this occasion to send out a fresh batch of spam.
Symantec started observing Mother’s Day spam from early April and we have seen a steady increase in the volume of messages ever since. Previous Mother’s Day spam emails often stuck to certain categories. Spam emails offering flower deliveries, jewelry, personalized messages, coupons, and other gifts for mothers were the most common. Survey and product replica spam were also observed in the past.
The following are the major Mother’s Day themed spam campaigns seen this year.
Flowers for Mother
A beautiful bunch of flowers is something any mother will love and spammers use this theme more than any other. From last month, we have seen numerous emails promising flower deliveries by Mother’s Day. Most of these emails included links that redirected to fraudulent websites and some of the links redirected through multiple domains just to increase the traffic.
Figure 1. Preview of a spam email for ordering flowers
The email headers for this category are as follows.
Subject: $19.99 for Flowers and a Vase for Mother’s Day
From: [brand] <Online@[domain]>
Subject: [brand]: $19.99-Flowers for-Mom &-Vase!
From: “[brand] Special” <[brand]Special@[domain]>
Subject: Hi, 50% off Flowers for Mom
From: Fresh Flowers <[brand]@[domain]>
Personalized jewelry for Mom
Beautiful jewelry, particularly rings and pendants with a personalized inscription, is another theme that is a hit around Mother’s Day. Spammers also claim to offer personalized cards or notes along with the product. Like most spam, these emails will usually have links to other sites.
Figure 2. Preview of a spam email selling personalized rings for Mother’s Day
The email header for jewelry-themed spam messages are as follows.
Subject: Give Mom Something Unique This Year
From: Mothers Rings <rings@[domain]>
Product replica spam
This category is not too different from others, except that these spam emails advertise websites selling fake watches, jewelry, and other expensive goods. We observed these emails earlier this year and we continued to see them today. In these campaigns, the spammers give users deadlines for placing orders for the products.
Figure 3. Preview of replica spam related to Mother’s Day
Email headers seen with this spam campaign are as follows.
Subject: Why so soon?
From: Paige (Mother’s Day deadline) <Paige@[domain]>
Lose weight by Mother’s Day
We believe that Mother’s Day-themed weight loss medication spam is a spinoff from an ongoing weight loss spam campaign, which has been the largest spam category by volume over the last couple of weeks. These emails include links which redirects to fake news sites offering information about new weight loss products.
Subject: Drop 10LB by Mothers Day
From: Rid 20 Pounds 2 Weeks <Sophia@[domain]>
Portuguese promo spam
We have seen a Portuguese spam campaign sending a large volume of messages promoting products related to Mother’s Day. This spam campaign uses the name of an online site which sells personalized products.
This spam campaign included links redirecting to a fraudulent website, along with a bogus opt-out option.
Figure 4. Preview of Portuguese promotional spam exploiting Mother’s Day
Here is the email header for this spam campaign.
Subject: Dia das Mães! Ajudaremos você com o presente.
From: “[brand]OnLine” <envio@painel1.[domain]>
Translation:
Subject: Mother’s Day! We’ll help you with this.
Symantec has observed a high volume of Mother’s Day themed hit-and-run spam recently. Most of these emails included links to a .us top level domain (TLD) which, on further analysis, were found to be registered quite recently. The theme of the domain names show that they were created for a Mother’s Day spam campaign. The domain names followed patterns such as flower-1promo-mothersday and mothersdayflower-special.
Symantec antispam filters successfully blocked these spam mails, but as always, we advise our readers not to respond to any of these emails. Remember, take your time to search for a Mother’s Day gift and don’t just click on links found in these spam mails. Symantec wishes all of our customers a happy Mother’s Day.
Six reasons to download avast! Mobile Security on mom’s smartphone this Mother’s day!
Today almost everyone and their mother has a smartphone, even your mom’s mom probably has a smartphone! Smartphones help us connect with people near or far, whether it be through traditional phone calls, text messages, photo and video sharing via apps or messaging services, smartphones have made keeping in touch routine, easy and instant. We share […]
Perfect Forward Secrecy
Recent revelations from Edward Snowden about pervasive government surveillance have led to many questions about the safety of communications using the SSL/TLS protocol. Such communications are generally safe from eavesdroppers, as long as certain precautions are observed. For example, configuring your web server to avoid using SSL2 and SSL3, favoring newer versions of TLS like TLS 1.2, selecting strong ciphersuites, etc.
But even if your server is configured properly, you still must secure the private key associated with your SSL certificate. In nearly all cases, the web site owner generates their key pair and sends only the public key to their Certification Authority (CA). The CA (and any eavesdropper) sees only the public key, and the private key cannot be derived from that. So the CA cannot reveal a web site owner’s private key to the government or an attacker, even if coerced to do so.
After your SSL certificate has expired and been replaced with a new key pair and certificate, it’s still important to secure or destroy the old private key, because attackers have the ability to save old SSL-protected traffic. In many cases, an attacker with a private key and saved SSL traffic can use the private key to decrypt all session keys negotiated during saved SSL handshakes, and then decrypt all saved session data using those session keys.
But not if the web server and its clients agree to use a key agreement protocol that offers support for Perfect Forward Secrecy (PFS). First let’s look at how things work without PFS. The client generates a random number and sends it to the server, encrypted it with the public key of the server. Only the server can decrypt it, so now both sides have the same random number. They use a key generation algorithm to derive the session key from that random number. But an attacker who knows the server’s private key can also decrypt the random number, apply the same key generation algorithm, and arrive at the same session key. The attacker can then decrypt any saved SSL session data.
Using PFS, there is no link between the server’s private key and each session key. If both client and server support PFS, they use a variant of a protocol named Diffie-Hellman (after its inventors), in which both sides securely exchange random numbers and arrive at the same shared secret. It’s a clever algorithm that prevents an eavesdropper from deriving the same secret, even if the eavesdropper can view all the traffic. See this Wikipedia article for a clear explanation of how this works, and this blog post for a more detailed technical explanation. Note that if the ephemeral variant of Diffie-Hellman is used, no part of the exchange is encrypted with the web server’s private key. That means that an attacker who obtains the private key cannot decrypt any saved sessions that were established using PFS.
The variants of Diffie-Hellman are known as Diffie-Hellman Ephemeral (DHE) and Elliptic Curve Diffie-Hellman Ephemeral (ECDHE). You’ll see those terms within the names of TLS ciphersuites that can be configured for use in your web server. For example, Ivan Ristić of SSL Labs recommends the following:
- TLS_ECDHE_RSA_WITH_RC4_128_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Please note that there are more options available which may have to be used as the industry moves to ECC certificates, TLS 1.2 and GCM suites. Also note that you may see ciphersuites with DH (not DHE) and ECDH (not ECDHE) in their names – these are variants of Diffie-Hellman that do not exhibit the Perfect Forward Secrecy property. Only DHE and ECDHE support PFS at this time.
Ristić also provides information on how to configure PFS support on Apache, Nginx and OpenSSL. If you want to see if your server supports PFS, test it at the CA Security Council’s SSL Configuration Checker.
Do the browsers support PFS? Yes they do. At this time, Chrome, Firefox, IE, Opera and Safari all support PFS when using ECDHE cipher suites with RSA and ECC SSL certificates. All browsers except IE also support DHE with RSA certificates. You can also test your browser to see if it supports PFS. If your web site needs to support older browsers that may not support PFS, you’ll have to configure your web server to also offer non-PFS suites. But list PFS suites first in order of preference.
PFS is a mature technology that is built in to nearly all major browsers and web servers. It’s available for use in securing your SSL traffic both now and in the future.
Tags: Perfect Forward Secrecy, PFS, SSL, SSL Labs
This blog was originally posted at https://casecurity.org/2014/04/11/perfect-forward-secrecy/ Authors Rick Andrews and Bruce Morton
Brauchen Sie eine eigene private Zertifizierungsstelle?
Haben Sie in Ihrem Intranet Domänennamen wie https://intranet.local oder einen Mailserver mit einer Adresse wie https://mail? Viele Unternehmen und Organisationen nutzen solche Domänennamen intern, doch das wird nun problematisch.
SSL-Zertifikate für Intranets
Symantec und die anderen im CA/Browser-Forum zusammengeschlossenen Zertifizierungsstellen (CA) und Browseranbieter haben beschlossen, keine SSL-Zertifikate mehr auszustellen, deren Root-Zertifikat nicht im öffentlich zugänglichen Internet überprüft werden kann.
Das heißt, dass Domänennamen nun weltweit eindeutig sein müssen und nicht nur innerhalb Ihres Intranets. Wenn Sie also beispielsweise eine Domäne mit der Endung .local haben, die Sie intern nutzen, werden Sie dafür bald kein von einer CA ausgestelltes SSL-Zertifikat mehr kaufen können.
Mit der Vergabe neuer gTLDs wie .berlin steigt die Wahrscheinlichkeit, dass weit verbreitete intern genutzte Domänenendungen von Unternehmen gekauft und im öffentlich zugänglichen Internet genutzt werden. Endungen wie .home und .pics wurden bereits beantragt und Anträge für weitere Endungen werden sicher folgen. In Zukunft können nur die Eigentümer dieser gTLDs bei CAs SSL-Zertifikate für sie kaufen.
Dadurch wird die Sicherheit im Internet insgesamt verbessert, doch Unternehmen und Organisationen, die diese neuen gTLDs oder reservierte IP-Adressen für interne Server nutzen, müssen sich nun umstellen.
So bereiten Sie sich auf die Umstellung vor
Wenn Sie in dieser Situation sind, haben Sie drei Möglichkeiten: Sie können die internen Domänennamen durch vollständig qualifizierte Domänennamen ersetzen, selbstsignierte Zertifikate nutzen oder eine private Zertifizierungsstelle (CA) einrichten, um Ihre intern genutzten Domänen zu authentisieren.
Für viele Unternehmen bietet sich die letztgenannte Option an, denn eine private Zertifizierungsstelle erfordert die wenigsten Änderungen an vorhandenen Systemen und ist mit dem geringsten Risiko verbunden.
Das Angebot von Symantec
Vor Kurzem stellte Symantec seine Lösung Private Certification Authority vor. Damit können Sie sowohl die Risiken und versteckten Kosten selbstsignierter Zertifikate als auch die Kosten einer Umstellung Ihres gesamten Intranets auf vollständig qualifizierte Domänennamen vermeiden.
Die Lösung beruht auf der robusten Infrastruktur von Symantec und ist für ein breites Anforderungsspektrum geeignet, vom Ausstellen von SSL-Zertifikaten für einzelne, in Intranets genutzte Domänen über Wildcard-Zertifikate bis hin zu selbstsignierten Zertifizierungsstellen. Zudem stellt sie eine gehostete private SSL-Zertifikatshierarchie mit speziell auf den Schutz des unternehmensinternen Datenaustauschs zugeschnittenen Endzertifikaten bereit.
Die Konsole von Managed PKI for SSL erleichtert Ihnen das Zertifikatsmanagement, denn sie ermöglicht die Verwaltung öffentlicher und privater Zertifikate an einer zentralen Stelle. So können Sie die mit dem unbemerkten Ablauf von Zertifikaten verbundenen Risiken vermeiden und rechtzeitig neue Zertifikate ausstellen. Doch unabhängig davon, für welche Lösung Sie sich entscheiden, gilt vor allem eins: Die Umstellung sollte so bald wie möglich erfolgen.
¿Necesita su propia autoridad de certificados?
¿Tiene alguna intranet cuyo nombre se parezca a https://intranet.local o algún servidor de correo electrónico con una dirección que comience por https://mail? Estos nombres de dominio de uso interno son muy frecuentes, pero ahora plantean un grave problema.
Certificados SSL para intranet
Symantec, junto con las demás autoridades de certificación y proveedores de navegadores que conforman el CA/Browser Forum, ha decidido dejar de emitir certificados SSL cuya cadena incluya una raíz pública a la que solo se puede acceder desde la red interna de la empresa.
Esto significa que los nombres de dominio tienen que ser únicos en el mundo, no solo en su red. Por lo tanto, si utiliza un dominio .local de forma interna, dentro de poco ya no podrá comprar certificados SSL validados para ese nombre.
Debido a la aparición de nuevos gTLD, como .london, y a la posibilidad de que empresas comerciales adquieran y usen muchos de los nombres que más se suelen utilizar para designar de forma interna a los dominios de servidor (por ejemplo, ya hay solicitudes para .red y .home, aunque seguro que les seguirán muchos más nombres), será imposible que compre un certificado SSL validado para estos gTLD a menos que le pertenezcan.
Si bien se trata de una medida que mejorará la seguridad, genera ciertos desafíos para aquellas empresas cuyos servidores utilizan estos nombres de dominio para uso interno o para direcciones IP reservadas.
Preparativos para el cambio
Entre las alternativas disponibles, se encuentra el cambio a nombres de dominio completos, el uso de certificados autofirmados o la creación de una autoridad de certificación privada para autenticar los nombres de dominio internos.
Para muchas empresas, esta última opción es una magnífica estrategia de preparación para el cambio, ya que es la alternativa que supone menos cambios en los sistemas existentes y la que conlleva menos riesgos.
La propuesta de Symantec
Para crear autoridades de certificación privadas, Symantec ha lanzado la solución Private Certification Authority. Gracias a este producto, evitará los riesgos y los costes ocultos de los certificados autofirmados, así como el gasto que supone cambiar toda la intranet para que utilice nombres de dominio completos.
Al utilizar la infraestructura blindada de Symantec, cumple todos los requisitos de los certificados SSL para intranet de un solo dominio, de los certificados comodín y de las autoridades de certificación autofirmadas. Además, ofrece una jerarquía de certificados SSL privada y alojada con certificados de entidad final creados específicamente para proteger las comunicaciones internas.
La consola Managed PKI for SSL contribuye a simplificar la administración de los certificados SSL, ya que le permite gestionar certificados públicos y privados desde un mismo panel de control. Gracias a esto, se reduce el riesgo de que los certificados caduquen de forma imprevista y se pueden emitir nuevos certificados conforme se necesitan.
Si su empresa dispone de servidores internos que utilizan nombres de dominio en desuso, tendrá que hacer algo al respecto más pronto que tarde.
Avez-vous besoin de votre propre autorité de certification privée ?
Vous possédez un site intranet dont le nom de domaine ressemblerait à https://intranet.local ? Ou un serveur de messagerie avec une adresse de type https://mail ? Certes très répandus, ces noms de domaines internes posent néanmoins un réel problème.
Certificats SSL pour intranet
Symantec s’est associé aux autres membres du CA/Browser Forum (autorités de certification et éditeurs de navigateurs Web) pour décider de stopper l’émission de certificats SSL rattachés à une racine publique ne pouvant être vérifiée dans un contexte d’Internet public.
En conséquence, l’unicité des noms de domaines ne doit plus seulement s’appliquer au niveau local (votre réseau), mais aussi au niveau mondial. En clair, si vous utilisez un domaine .local en interne, vous ne serez bientôt plus en mesure d’acheter des certificats SSL validant ce nom de domaine.
On assiste actuellement à l’émergence de nouveaux domaines génériques de premier niveau (gTLD) de type .london et autres, dans le sillage desquels de nombreux noms devraient suivre – les noms .red et .home sont d’ores et déjà en phase d’homologation. Par conséquent, il est fort probable que la plupart des noms communs utilisés pour identifier les domaines de serveurs en interne finiront par être exploités par des plates-formes commerciales. En clair, à moins que vous ne soyez propriétaire de ces gTLD, vous ne pourrez plus acheter de certificat SSL pour la validation de ces domaines.
Malgré les avantages de ce changement en termes de sécurité, il n’en pose pas moins un véritable enjeu pour les entreprises exploitant des noms de domaines internes ou des adresses IP réservées.
Comment se préparer
Face au changement à venir, les entreprises disposent de plusieurs options pour authentifier leurs noms de domaines internes : passage à des noms de domaines entièrement qualifiés, utilisation de certificats auto-signés ou mise en place d’une autorité de certification (AC) privée.
Pour de nombreuses entreprises, la mise en place d’une AC privée représente la meilleure solution car elle est la moins risquée et ne demande qu’un minimum de changements sur les systèmes existants.
La solution Symantec
Récemment annoncée par Symantec, la solution Private Certification Authority permet aux entreprises d’éliminer les risques et coûts cachés des certificats auto-signés, ainsi que les coûts associés au déploiement de noms de domaine Internet complets sur leur intranet.
Grâce à l’infrastructure ultra-sécurisée de Symantec, Private Certification Authority répond à n’importe quelle exigence : des certificats SSL intranet mono-domaines aux autorités de certification auto-signée, en passant par les formules Wildcard. Cette solution hébergée offre une hiérarchie SSL privée avec des certificats pour entités finales spécialement conçus pour sécuriser les communications internes.
Côté gestion, Symantec Private Certification Authority vous permet de consolider tous vos certificats SSL privés et publics au sein de la console Managed PKI for SSL. Résultat : vous éliminez les risques d’expiration inopinée de certificats et pouvez émettre de nouveaux certificats selon vos besoins. Pour conclure, si vos serveurs internes exploitent des noms de domaine invalidés, vous devriez envisager une solution au plus vite.
Sophisticated Viknok Malware Proves That Click-fraud Is Still a Moneymaker for Scammers
Symantec has spotted a recent surge of infections of Trojan.Viknok, which can gain elevated operating system privileges in order to add compromised computers to a botnet. Trojan.Viknok, first observed in April 2013, infects dll files with a malicious payload. Since its initial discovery, the malware has evolved into a sophisticated threat, capable of obtaining elevated operating system privileges in order to infect system files on multiple Windows operating systems, such as the 32 and 64-bit versions of Windows XP, Vista and 7.
Attackers have been observed using Viknok-infected computers to carry out Adclick fraud. While click-fraud activity has been prevalent for years, it still seems to be an effective way for scammers to make money. The scammers behind the current Viknok campaign have gone to a lot of effort to add more victims to their Adclick botnet, helping them make more money in the process.
While the Viknok malware was discovered last year, attackers have been increasingly using the threat in the last six months. In April 2014, Symantec observed a spike in Trojan.Viknok activity along with new reports of Viknok-infected computers playing random audio clips through victims’ speakers. In the first week of May alone, Symantec saw 16,500 unique Viknok infections. The majority of victims are located in the US.
In this blog, we’ll talk about how Viknok manages to alter a system dll to gain elevated privileges. We’ll discuss the techniques the threat uses to infect its targets and how it takes advantage of compromised computers to conduct click-fraud. Finally, we’ll show how many Viknok infections have occurred in recent months and talk about how to protect yourself from this threat.
Viknok’s privilege escalation exploit
Modifying a system dll is no easy task in today’s operating systems. Even if a user is operating from an administrator account, they will not have the permissions to alter core system files, such as rpcss.dll which lets software continue to run each time Windows restarts. So how can Viknok infect these files?
Viknok has an arsenal of techniques at its disposal to let it perform the silent infection of the system file rpcss.dll. These methods consist of:
- Using SeTakeOwnerhipPrivilege to take ownership of system files.
- Taking advantage of Windows’ Dynamic-Link Library Search Order to run a malicious dll inside the System Preparation Tool process.
- Using the Run a legacy CPL elevated tool to run a dll with elevated privileges.
- Exploiting the Microsoft Windows Kernel ‘Win32k.sys’ Local Privilege Escalation Vulnerability (CVE-2013-3660) to carry out a privilege escalation.
The most powerful of these techniques is the exploitation of CVE-2013-3660, which allows the threat to run code in kernel mode.
Figure 1. The exploit’s payload code
The code shown in the previous image shows how the threat is able to assign itself the system process’ primary access token, giving the malware the same privileges as the user with the highest administrative rights.
How Viknok infects computers
Depending on the privileges used to initially execute Viknok, the threat may try one or more of the previously mentioned techniques. The threat’s purpose is to infect the file rpcss.dll, so that the malicious code is executed every time Windows starts. The infection of this file merely provides a loader for the core of the malware itself, which is usually stored in an encrypted file in the %System% folder.
We tested several scenarios to verify Viknok’s infection capabilities, which have been summarized in the following image.
Figure 2. Some common Viknok infection scenarios
There are several conditions that may affect the outcome of the infection process, such as if the threat is manually downloaded and run, if it is dropped through an exploit or if it is dropped by the browser or a browser plugin. The previous image does not exhaust all possibilities; however it shows configurations that are commonly found in user or corporate environments.
In many cases, the infection process is completely stealthy; the threat does not show any warning to the user. The malware is also difficult to detect since it does not show any suspicious running process, nor does it infect any of the standard load points. In some cases, the threat needs to show the User Account Control (UAC) prompt to the user in order to obtain the elevation of privileges. If the user does not grant the permission, the infection will fail. However, the threat uses system components to try and load its code for privilege elevation. As a result, the UAC prompt will look like it’s a part of normal system activity, as shown in the following image.
Figure 3. Example of UAC prompt
Payload & click-fraud activity
As mentioned previously, attackers are currently using Viknok-infected computers to perform click-fraud activity. Attackers carry out this activity using malware detected by Symantec as Trojan.Vikadclick. Once Vikadclick is loaded by the Viknok-infected rpcss.dll file, it will periodically download commands from command-and-control (C&C) servers under the attackers’ control. These commands force the compromised computer to perform network activity related to Adclick fraud.
As a result of Trojan.Viknok infections and the related Adclick fraud, unknowing victims have been experiencing random audio playback through their compromised computers. This is believed to be caused by Trojan.Vikadclick surreptitiously visiting Web pages in the background that contain streaming audio content. Our analysis has shown that Trojan.Vikadclick’s Adclick fraud content includes car insurance for teenagers, tickets to Paris and bulk domain name registration, to name a few.
Prevalence
Symantec telemetry shows that Viknok activity has increased considerably in the last six months, with Symantec detecting and remediating over 22,000 unique infections in April 2014.
Figure 4. Growth in Viknok detections in the last 6 months.
From May 1 to May 6, Symantec telemetry shows that we have detected over 16,500 unique Viknok infections. The majority of the infections have been observed in the US. The number of Viknok detections for May 2014 is on track to reach the highest amount of infections of this malware recorded to date.
Figure 5. Heatmap for Viknok detections in May 2014 to date.
Protection
Symantec protects users against Viknok under the following detection names:
Antivirus detections
- Trojan.Viknok
- Trojan.Viknok!gen1
- Trojan.Vikadclick
- Trojan.Viknok!inf (repairable)
- Trojan.Viknok.B!inf (non-repairable)
- Trojan.Viknok.C!inf (repairable)
- W64.Viknok!inf (repairable)
- W32.Mezit!inf (non-repairable)
The non-repairable infections are related to copies of legitimate infected dlls, which can be safely deleted without affecting the computer.
Intrusion Prevention Signatures
For the best possible protection, Symantec customers should use the latest Symantec technologies incorporated into our consumer and enterprise solutions. Finally, always keep computers up to date with the latest virus definitions and patches.
While still a relatively newcomer on the malware threat landscape, Trojan.Viknok has shown its ability to evolve and implement sophisticated infection techniques to circumvent operating system access control mechanisms. Its use of Adclick fraud to monetize the botnet shows that this form of fraud is still a popular mean of income for malware authors. The continued spike in Trojan.Viknok activity suggests that this threat looks to become a common player on the threat landscape, so Symantec will continue to monitor it closely. Symantec is continuing to investigate how this threat arrived on victims’ computers.