Malware RSS Feed
In 2013 we conducted our first in-depth research into the financial cyber-threat landscape. At that time we registered a sudden surge in the number of attacks targeting users' financial information and money. The financial cyber threats landscape was discussed in detail in Kaspersky Lab's "Financial Cyber-threats in 2013" report.
In 2014, the situation changed considerably: the number of attacks and attacked users significantly decreased, as did the amount of financial phishing. The key findings of the study into the financial cyber-threat landscape in 2014 are as follows:
Attacks with Financial malware in 2013 and 2014Financial phishing attacks
- In 2014 financial phishing attacks, which include phishing that targets Banks, Payment Systems and E-shops, accounted for 28.73% of all phishing attacks (a decrease of 2.72 percentage points).
- Bank-related phishing accounted for 16.27% of all attacks.
- The amount of phishing against Payment Systems increased 2.4 p.p. (from 2.74% in 2013 to 5.14% in 2014)
- In 2014 Kaspersky Lab products detected 22.9 million attacks involving financial malware against 2.7 million users. This represents a YoY decrease of 19.23% for attacks and 29.77% of users.
- Among the total number of users subjected to all types of malware attacks, 4.86% of users encountered attacks involving some kind of financial threat – that's 1.34 percentage points less than in 2013.
- The amount of Banking malware rose 8.89 percentage points to 75.63% of all financial malware attacks in 2014.
- The number of attacks involving Bitcoin mining malware tripled: from 360,065 attacks in 2013 to 1,204,987 in 2014
There are several possible reasons for these changes. First of all, law enforcement agencies around the world actively prosecuted cybercriminals who were spreading financial malware and phishing. In particular, last summer, law enforcement agencies in the US and the UK stopped the activities of two dangerous malicious campaigns – Gameover / Zeus and Shylock.
The second reason for the decline in the number of attacks might be a shift in the cybercriminals' focus – instead of attacking end-users they are now pursuing organizations that work with financial information and payment tools. Throughout the year there were frequent reports of malicious attacks on large stores, hotel chains and fast food restaurants that serve millions of customers a day. In each case the fraudsters used malicious software that could steal bank card data directly from the memory of the POS terminals used by the organizations under attack. Banks became yet another "new" cybercriminal target. In 2014, Kaspersky Lab investigated several attacks targeting banks rather than their users' accounts. Neither of these "new" types of attack prompted a rash of new AV detections simply because there are so few organizations involved compared with the number of private users running antivirus solutions, so it is difficult to compare the number of attacks. Nevertheless, the damage from such attacks amounted to millions of dollars so this threat can hardly be dismissed.
#Cybercriminals are less interested in "mass" malicious attacks, preferring fewer, more "targeted" #attacksTweet
A third possible reason for the reduced number of cyberattacks lies in a general trend observed by Kaspersky Lab specialists in 2014. According to the company's experts, cybercriminals are less interested in "mass" malicious attacks on users, preferring fewer, more "targeted" attacks. This is shown by the increased levels of targeted phishing: fraudsters only go after a specific group of users (for example, online banking users) rather than spreading mass mailings with malicious links.
This tactic suggests that a selective malicious mailing is less likely to be detected by IT security specialists and the lifespan of malicious links and malware samples will be extended. The trick is not always successful, but one consequence of its use is a decline in the absolute number of registered cyberattacks.Android financial malware attacks
And what about mobile financial threats?
First of all, when we talk about mobile cyberthreats we focus on Android cyberthreats. According to Kaspersky Lab experts, more than 99% of mobile malware they are aware of is designed to attack Android devices.
48.15% of the attacks against #Android users utilized malware targeting financial data (Trojan-SMS and Trojan-Banker)Tweet
In 2014 Kaspersky Lab and INTERPOL released a joint study on Mobile Cyberthreats which – among others – covered financial malware targeting Android users. According to the findings, there were 3,408,112 attacks against 1,023,202 users recorded in the period from August 1st, 2013 to July 31st 2014. About 500,000 users have encountered Android malware designed to steal money at least once. More than half a year has passed since the end of the period covered by the Kaspersky Lab / INTERPOL study and here is how things changed since:
- 48.15% of the attacks against users of Android-based devices blocked by Kaspersky Lab products utilized malware targeting financial data (Trojan-SMS and Trojan-Banker)
- In comparison with 2013 the number of financial attacks against Android users increased 3.25 times (from 711,993 to 2,317,194 attacks) and number of attacked users was up 3.64 times (from 212,890 to 775,887 users)
Attacks against users of Android-based devices in 2013 and 2014
In other words, the ever-increasing numbers of financial attacks against users of Android-based devices is a strong trend that shows no sign of declining.
Read more about financial cyber-threats in 2014 in our whitepaper.
Over the last decade DKIM signatures have become an important technology in the extensive list of methods for fighting against spam. Despite the fact that many users have no idea what the term DKIM even means, it is exactly this system that behind the scenes keeps our mailboxes guarded from various types of unsolicited mail, as well as protects a part of the world mail traffic from being wrongly labeled as "spam".
In this article we investigate the structure of DKIM in perspective from its emergence all the way up to nowadays. We also reveal the main advantages and downsides of this piece of technology, as well as explore typical spammers' tricks for forging DKIM signatures.Concept of DKIM
DKIM technology (DomainKeys Identified Mail) provides a sender verification and guarantees the integrity of the delivered email. The verification is based on the electronic message signature which is generated with asymmetric cryptography. This signature is added to the service headers and is transferred transparently for the end user.
DKIM signature validation occurs automatically on the user side. It relies on the data extracted from the DKIM header as well as on the public encryption key retrieved from the sender's DNS domain name records. The message might be marked as scam, phishing, or suspicious if the specified domain name was not authorized to send this message, depending on the user's policies. Email clients are more loyal to the correspondence with successfully validated DKIM headers, as opposed to the messages with failed DKIM verification. In the meantime, emails without any DKIM headers are processed in the standard mode.DKIM history
The history of DKIM starts in 2003 with an independent technology DomainKeys (DKIM ancestor) developed by Mark Delany as a part of his work at Yahoo. Two years later Yahoo is granted a patent for Domainkeys, and a wide range of vendors starts to prepare the first recommendatory version of DKIM standard.
In parallel with the DomainKeys development in 2003-2007, Cisco creates their own project "Identified Internet Mail" (IIM), based on a similar concept of authentication with the message signature.
In 2007 IETF publishes DomainKeys standard RFC 4870 (as already deprecated one) and the first standard of DKIM RFC 4871. Later on DKIM standard improves and gets updated in 2009 (RFC 5672). Finally, in 2011 IETF decides to merge two specs, IIM and DKIM, into the final standard RFC 6376.
Despite the fact that new standard had been published, by the year 2012 numerous companies were still using a deprecated 2007-year version of standard. This created a lot of interesting research on potential vulnerabilities in DKIM which we discuss below.
DKIM is based on the standard asymmetric encryption.5 main DKIM stages:
- For every server a public/private key pair (or a set of pairs) is generated.
- The private key is stored on the sender's server and is being used to create all corresponding DKIM headers for the outgoing mail.
- The public key is added to the domain DNS zone file in the form of special TXT-record by the domain owner and be comes accessible to everyone.
- Email with DKIM signature is sent to the recipient (see below).
- Signature is verified using the public key retrieved from the DNS records.
- Compose and send message.
User sends an email and it is accepted by the sender's mail server.
- Create DKIM signature.
The mail server adds a new "DKIM signature" header. This header includes an electronic signature created with the private encryption key, the message's body, its headers, current time, and other parameters.
- Transfer signed message.
Message with a new signed "DKIM signature" header is sent to the recipient.
- Message reception and signature validation.
The recipient's mail client analyzes the DKIM header and gives a verdict based on the public key, whether the sender and email are legitimate or not.
The very last stage, message validation, is especially interesting.
- Sending DNS-request.
Mail client/service performs a DNS-request that includes the domain name from which allegedly the message was sent.
- Public encryption key retrieval.
The corresponding TXT-record that includes a public key is extracted from the response body from the DNS-server
- DKIM header analysis:
- Every tag in the header is decrypted from Base64 to its text representation.
- Received strings are decrypted using the previously retrieved public key.
- Final verdict.
The last stage is to compare the body text and headers with the decrypted information from the DKIM header. Any sort of discrepancy leads to dkim=fail, whereas if the content matches the verdict is dkim=pass.
Typical DKIM signature headers comprises of a list of tags like "tag=value". Tags names have short names and usually are 1-2 characters long.
Example:DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=foursquare.com; h=from:to:subject:mime-version:content-type; s=smtpapi; bh=9UsnWtzRLBWT7hnQc8V2RF4Ua4M=; b=IgnW7QsK2LBp0VQJ4FJcLv9MmHBvD 2Ch6jPxQ/Hkz+TX2WXyWkGbScx4gbZeWj3trqN4LUVvTf2U+htG4Wsg6sQAKqvnC neTeDvcmm225CKji0+MSXL8VK6ble8mkk14EAwWDP8+DJMwL2f7v/wp6QEdd7jqY q/fX+TY5ChIYHQ= Tags and descriptions
Main tags:Tag Tag description b message content (body + headers, encoded in Base64) bh hash of the canonicalized body part of the message(also in Base64) d domain name of the signing entity h list of signed headers
Additional headers:Tag Tag description a main algorithm to generate the signature v system version s selector subdividing the namespace for the "d=" (domain) tag c algorithm to use to convert the body and headers to the canonical form q list of query methods used to retrieve the public key x signature expiration time i identity of the client on behalf of which the message is signed (in quoted-printable) l body length count in the number of octets in the body included in the cryptographic hash t signature timestamp z copied header fields at the moment of signature generation Common attack methods on DKIM Simple attacks
First attempts to use DKIM by spammers were observed by us back in 2009. Originally, spammers tried to add headers with content that was far away from valid DKIM signatures. Spammers paid very small attention to the accuracy of the signature, what created some pretty interesting cases.
For example, spammers used the same header for all emails in this spam mailing (the genuine DKIM headers are actually different for non-identical messages since each of them is based the message body, headers, timestamps, and other unique factors).
Other spam samples show how spammers copied DKIM signature from the legitimate third-party website and for every email changed content of only one DKIM-tag, completely forgetting that other tags also depend on the message content and should have different values as well.
Similar mistakes systematically appeared in spam throughout the last years.
Some of the most popular of them:
- Spammers correctly generate the "b"-tag which describes the message body, but forget about the "bh"-tag (hashed body).
- Domain name specified in "d"-tag does not correspond to the sender, nor to any details information in the email at all.
- Specified timestamp ("t"-tag) is not accurate and is related to some other date in the distant past.
Spammers are capable of setting up their own mail servers and domains in order to generate legitimate DKIM headers as the average system administrator would do. In spite of that, valid DKIM headers have been fairly uncommon in spam until recently.
This is largely due to the complexity of the installation process of the DKIM server side for the valid signatures generation. However, the number of domain names involved in the spam activity has increased significantly over time, therefore attacks on DKIM have become more efficient and profitable for spammers. For these reasons spammers had to learn how to skillfully operate DNS-records of their numerous domains.
In the example below we can see a perfectly valid DKIM signature along with a correct domain's TXT-record which lead to the "dkim=pass" verdict when coupled together.
This extra work appears to be reasonable enough for spammers since many email services are more loyal to the messages with correct DKIM signatures, and spammers' mail eventually has higher chances not to be banned by anti-spam filters and end up in the user's mailbox.
In addition to simple checks for the "DKIM=fail" verdict in message headers, our Kaspersky Security for Linux Mail Server detects all email spam with mentioned spammers tricks. It either detects this mail as spam and forwards straight to the junk folder or increases the spam rate of the message.Vulnerabilities and weaknesses of DKIM
- DKIM does not provide any guarantees.
It is not reasonable to rely solely on DKIM for the following reasons:
а) Spammers, as well as the average users, can correctly configure DKIM on their own website.
b) It is possible that some of mail coming from a single domain name does not have any DKIM headers. One example might be if the domain uses multiple mail servers with different configurations, although there might be many other scenarios.
Because of these reasons, the standard advises not to "penalize" any mail without DKIM signatures.
- Lack of sustainability when message structure changes.
DKIM signature becomes invalid when the headers order is even slightly modified, when new headers are added, or when headers had any minor changes in their content. These kinds of changes are quite common and occur when the message is processed by the server-forwarder on the way to the recipient.
- Short encryption keys are vulnerable.
All DKIM signatures signed with private keys shorter than 1024 bits in length are vulnerable according to the research by Zach Harris published in Wired in October 2012. Moreover, Harris managed to crack the 384-bit authentication in just 24 hours using his laptop only. You can read about other requirements to DKIM in our blog article about this news.
Interestingly enough, Harris had successfully sent emails to Google founders Sergey Brin and Larry Page in 2012 by spoofing their DKIM headers and formatting messages as their personal correspondence between each other.
Recently, numerous companies including Google and Microsoft started to intensively promote the use of encryption keys with the sufficient length. Despite that, there are still a great number of insecure mail servers signing DKIM headers with private keys of not cryptographically strong lengths.Advantages of DKIM
- Correctly created DKIM signature confirms that the received message has been indeed sent from the specified domain.
- DKIM is a powerful tool for building a domain reputation based on the variety of messages received throughout a period of time (often used by diverse anti-spam solutions and by members of the DKIM reputation project)
- DKIM gives another indicator which helps to make a decision on the client side, whether to trust the sender or not.
DKIM is used in combination with other technologies of mail reputational analysis. The majority of modern email services and mail clients already support DKIM verification. However, it is useful to ensure that DKIM is configured correctly if you use your own domain name, or if you want to set up DKIM on your own mail server.DKIM installation on the corporate mail service
Many corporate email services support DKIM installation with only several clicks required. However, the domain administrator will have to manually edit the DNS zone file to add corresponding TXT-records.
For example, this is how the DKIM activation process looks like for Gmail for Work service.
- Open administratior panel for your domain name at https://admin.google.com
- Choose "Apps" in the list of menu items.
- Then choose Gmail from the list of apps.
- Confirm the intention to activate the "Email-authentication" and click "Generate new record".
- Service will generate the content of new TXT-record that you have to store in your domain's DNS zone file. To do that, open your domain's administrator panel, find a section for manually editing the domain zone, add a new record with TXT type, and copy there all values offered by Gmail.
- As an extra step, you can create another TXT-record in order to support SPF policy as well. For Gmail for Work service this record should be:
- Shortly after you finish all previous steps (often already after 20 minutes, but may take up to 48 hours), all emails sent from your domain start to be labeled with dkim=pass and spf=pass flags, confirming the legitimacy of the sender.
Final content of the zone record should be similar to:
google._domainkey IN TXT v=DKIM1; k=rsa; p=(generated public key)
@ IN TXT v=spf1 include:_spf.google.com ~all
This record authorizes Google servers to send mail from your domain name, and therefore the reversed verification on the recipient side will result in the spf=pass verdict.
If you have any problems with installation, the DKIM installation manual and SPF record manual from Google Apps should be helpful. For the details on the zone file editing, refer to your domain name registrant documentation.DKIM installation on your own mail server
Setting up DKIM on your own mail server is a less trivial process. We will give a short explanation of the DKIM installation procedure for Postfix mail agent on the server with Debian-like distribution. DKIM installation for other mail servers and OS is analogous. For more details, refer to the documentation on the interested email client and the information at the OpenDKIM project website.
- Install Postfix MTA and the following OpenDKIM packages from the official repositories depending on your distribution
- Generate the private key to be able to create DKIM signatures in the future. You will need to specify your domain name, as well as the selector name that can be chosen arbitrarily (used later).
- Copy the example file from /etc/opendkim/opendkim.conf.sample to /etc/opendkim/opendkim.conf and edit the following options depending on your domain name and the chosen selector name:
- Create new TXT-record in your DNS zone file (see also examples of zone file configuration above in the example for Gmail for Work service). Do not forget to specify your selector name picked on the previous steps. The record should look similar to:
- The last stage is the integration of opendkim to Postfix. Edit the configuration file /etc/postfix/main.cf and add the following data to it:
- The installation is finished and you can run opendkim service.
postfix opendkim opendkim-tools
$ opendkim-genkey -r -s selector -d yourdomain.com
Store the generated key to the arbitrary file in the server directory with limited access and specify the path to it in the configuration file below.
selector._domainkey IN TXT v=DKIM1; k=rsa; p=...
You can validate the TXT-record of your domain with a simple request using host tool:
host -t TXT selector._domainkey.yourdomain.com
However, take into account it might take up to several hours to have your TXT-record updated because DNS providers cache data on their side.
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
sudo service opendkim start
The majority of public email services support DKIM signatures, validate them transparently for the user, and use the received verdicts for their own anti-spam systems.
Some services try to make DKIM-check more visual and mark emails that successfully pass DKIM validation.
For example, Gmail service marks emails with a 'secured connection' icon if the sender is verified and this email passes some internal validations for the sender.
You can enable this functionality in Settings → Labs → Authentication icon for verified senders.
DKIM technology has various competitors and has become a basis for other sender authentication solutions.
- Sender Policy Framework (SPF)
SPF also uses DNS for storing information, and is a tool for verification the sender's domain. As opposed to DKIM, SPF stores not the public key in DNS records, but the list of the servers authorized to send email messages. Overall, SPF allows to verify the authenticity of the domain name, but not the message text or its headers.
Nonetheless, SPF technology is more widespread than DKIM and is supported by the vast majority of mail clients and email services.
- Pretty Good Privacy (PGP)
PGP is currently the most popular algorithm for email encryption in the world. It allows to encrypt the entire message under assumption that both sides generate public/private keys in advance and exchange the public keys. DKIM does not try to compete with PGP while being just an extension of the ordinary concept of email-message with the ability to validate the sender.
- Domain-based Message Authentication, Reporting and Conformance (DMARC).
DMARC is a relatively fresh authentication method that combines both SPF and DKIM technologies. This system was presented for the first time in 2011 and numerous top vendors expressed interest in it. In 2013 DMARC was already protecting more than half of the world mailbox while still not yet being an official standard, which once again proves the success of DKIM technology that underlies DMARC.
Nothing holds a potential reader's attention stronger than a story about a catastrophe. A few days ago we came across an excellent example of a mass mailing where spammers took full advantage of this universal fascination with destruction.
The mass mailing in question is intended primarily for the US users. In it, the spammers list a series of recent tragedies and predict that worse is yet to come. They also propose a solution – just click the link to find out how to protect yourself and your family from harm.
In the email below the authors mention Sandy hurricane that hit North America about two years ago.
The spammers recall the crisis that faced many Americans after that hurricane – stranded in badly-damaged houses without food or electricity. The author of the email claims to know a guy who lived right in the center of the storm, in a wind-lashed city in New Jersey, and who suffered no shortages of anything. Click the link, and the spammers promise you'll enjoy the same good fortune if disaster strikes your neighborhood.
Yet another example mentions the recent terror attacks in France.
In this email, the spammers paint a bleak picture of America's immediate future, claiming the government is hiding the truth but expects blood to flow in the streets as it did in France. But there is an answer – just click the link and you'll find out how to protect your family from any attack.
When users follow these links they are taken to sites that are also striking. They start with an audio presentation of a confidential story told by a well-wisher.
The design of the site, the voice and the details of the story differ but the essence is the same: anyone who spends a few minutes to listen to the audio will be introduced to our hero, understand why he decided to share his warnings about the disasters in store for America and, eventually, find out how to build a miracle machine that can be easily assembled in your own home. The link to the video tutorial on self-assembly of this life-saving device costs just a few dozen dollars and shows you how to create a generator so simple that even your grandmother could make it work. Happy buyers don't only get an autonomous source of energy to be used in the event of disaster; they ca also save on household energy bills.
The audio is supported by a presentation which displays the speaker's text. So even users who cannot turn on the sound need only have the patience to watch for a few minutes, see the offer and reward the spammers for their efforts to spread paranoia by sending them their hard-earned dollars.