It might be a targeted attack, given that we detected it only in one organization, or it might just be an ancient infection still attempting to propagate. In both cases it is an interesting case.

The attack is coming via email, which is interesting given that it is a vbscript attack. Here is how the email looks like:

The email has a spoofed envelope-from and header-from: noeply@admin.net (the mispelling is original)

The email contains vbscript code that creates a file named svchost.exe and executes it:

The variable WriteData is 174592 characters long and contains the payload that will be written to a file named svchost.exe and then executed. The final binary file is 56320 bytes long and it’s sha265 hash is
fd6c69c345f1e32924f0a5bb7393e191b393a78d58e2c6413b03ced7482f2320.

It is a well know trojan, first detected in 2010.
Here is what virustotal knows about it:
https://www.virustotal.com/#/file/fd6c69c345f1e32924f0a5bb7393e191b393a78d58e2c6413b03ced7482f2320/details
And here is the analysis performed by the sandbox at hybrid-analysis:
https://www.hybrid-analysis.com/sample/fd6c69c345f1e32924f0a5bb7393e191b393a78d58e2c6413b03ced7482f2320?environmentId=110

Interestingly, the text-only entity of the email also contains the part of the script that is in the html commented area:

This is likely due to a sloppy auto-generation of the text entity that greatly increases the email size for no reason.

Our systems detected this attack yesterday in a single organization in the UK, making us wonder whether this is a targeted attack.
But, really, a targeted attack using a 9 year old malware?
It looks quite strange especially considering that the payload is delivered through a vbscript embedded in the html entity of the email, which is something that virtually every email security solution detects and disarms.

Curious things happen. If you detected something similar recently, feel free to get in touch with me.

If this is a 9 year old infection still propagating, it is by itself worth of some thoughts.

Anything can be monetized online, especially the credentials of your email account. Here is how they are abused.

Botnets are one of the main distribution channels for malware and phishing email. A botnet can be composed of hundreds of thousands of compromised devices (increasingly IoT devices) and the command-and-control (C&C) center coordinates the activity of all these devices.

Once upon a time the bots connected directly to the destination mail server in order to attempt the delivery of a malicious email but ISP firewalls and reputation data easily could identify and block these attempts. Sending malicious email from legit email accounts is much more effective: reputation is good (email is coming from big players like Google or Microsoft), malicious email is technically identical to legit email and this makes life harder for spam filters, they have higher chances to end up in the inbox of the recipient.

The C&C periodically distributes to the bots fresh valid credentials to be abused and send bad stuff in the name of the legit email account owner, but how to they get the credentials of your email account?

The first source of valid email credentials are data breaches. There are lots of data breaches, more than you can imagine. I had to unsubscribe from the privacyrights.org data breach notification service because of the flooding: 828 databases became public in 2018 for a total of over 1.3 billion records. On average 2.2 breaches per day. Lots of data.

Data breaches contain credentials, which are usually an email address and a password. Lots of users re-use the same password on many services and this means that a lot of these breached records contain valid credentials for email accounts, ready to be abused. The C&C collects and dispatches these credentials to the bots.

What about the email accounts for which the breached password is not valid? You can always guess it.

Many users use passwords that are really simple: the most used password on the planet is “123456”, followed by “password”, on the 3rd place we have the slightly more complex “123456789”, then “12345678” and so on. In the 8th position we find “sunshine”, followed by “querty”, then “iloveyou”, “princess” and so on. Lots of passwords are present in dictionaries, lots are first names, dates, combinations of those and simple variations like “monkey2018”.

You don’t need to make a lot of attempts to guess the password of many email accounts, with a few thousand attempts you get lots of them and if you have a botnet you can make hundreds of thousands of attempts all at once, each one from a different IP address, without triggering rate-limiting protections.

Got it?

Now, what can you do to prevent this and relax?

First: use a different password for each service. Data beaches happen all the time, if you go on haveibeenpwned.com an enter your email address you will probably find out that your credentials are already public. If you use the same password everywhere a single data breach compromises all of your accounts, so don’t do it. Use a different password for each service.

You may now be tempted to choose a “smart” technique to generate different passwords from the same root. For example monkey_linkedin, monkey_facebook_2019 and so on.

Not so smart. These variations are easily guessed if you can perform hundreds of thousands of authentication attempts at once. Most of these passwords can be found easily. Don’t think you can easily outsmart brute-force attempts with your limited memory resources.

Entropy is the keyword here. I will tell you something that you won’t like: if you can memorize it, it is low-entropy and if it is low-entropy it can be easily guessed. This means that if you can memorize it, it’s not strong enough. That’s it.

The only way to have passwords that cannot be easily guessed is to have high-entropy passwords which means that you cannot memorize them. Sorry, someone had to tell you.

A password manager is the best way to go today: with a minimal effort you can manage hundreds of un-guessable high-entropy passwords that are all different.

I can understand that a password manager can be a huge obstacle for your aunt and (I don’t want to open a hot debate here) I personally think that for some people a decent fallback is to write passwords on paper. Yes, they are more vulnerable but they are offline and in the end it is much better than having a weak password.

Security means compromise. Choose your compromise but don’t ignore this: if you can memorize it, then it’s not strong enough.

 

Rodolfo Saccani
Security R&D Manager at Libraesva

 

L’ultima moda messa a punto dai Cyber criminali è quella della frode online attraverso l’invio di email in cui lo sfortunato destinatario viene ricattato per aver visitato siti pornografici ed essere stato ripreso in atteggiamenti osè. Una mail breve, di solo testo, in cui si dice che è stato installato un programma trojan sul pc in grado di attivare la webcam, registrando così un ipotetico comportamento di masturbazione dell’utente nel visionare alcuni filmati pornografici. Per rendere più credibile il ricatto l’attaccante sostiene di aver preso il controllo della casella di posta dell’utente, impersonando la vittima come mittente della stessa missiva, grazie allo spoofing dell’indirizzo di posta.

La domanda che molti si fanno, riferendosi a noi come interlocutori privilegiati in quanto esperti di posta elettronica, è se questo genere di ricatti hanno effettivamente successo. Quanti sono infatti i destinatari che dovrebbero essere preoccupati da un simile ricatto e pagare 300 dollari in Bitcoin (con tutta la trafila necessaria per procurarsi la cryptovaluta!) per mettere tutto a tacere?! Sono sicuro che la maggior parte di voi risponderebbe: nessuno! .. o quasi…

Ecco che allora abbiamo voluto approfondire la questione, partendo dall’indirizzo del portafoglio BitCoin indicato nella mail. Nel parlare di BitCoin e cryptovalute in genere si fa spesso molta confusione tra tracciabilità e anonimato. Se infatti è assolutamente vero che il portafoglio bitcoin non è associato ad alcuna persona fisica o identità, garantendo quindi l’anonimato, questo non significa che le transazioni effettuate in cryptovaluta non siano tracciabili. Al contrario la blockchain è tracciabile per definizione.

Siamo quindi andati a controllare le transazioni avvenute sull’indirizzo bitcoin indicato nella mail, collegandoci al sito:

https://www.blockchain.com/btc/address/1CSsVgPgwTNLGgQCHRBPa7ZNH7oxK9cf2k

Dal libro mastro della blockchain si vede come il portafoglio abbia ricevuto pagamenti dal 13 Settembre 2018 (la mail è del 12 Settembre 2018), e come gli importi ricevuti siano stati trasferiti su altri 4 portafogli in due diversi momenti.

A questo punto lo scopo del cyber criminale è quello di nascondere e disperdere le proprie tracce, dividendo i pagamenti in tantissimi piccoli trasferimenti su moltissimi portafogli bitcoin in modo da far perdere le proprie tracce, riducendo le transazioni ad importi di piccola entità.

Seguendo il primo trasferimento di “soli” 1.9462419 BTC (circa $12.000 !) si aprono le transazioni del secondo portafoglio bitcoin e poi ancora di un terzo, ma sono già moltissimi i portafogli su cui sono stati divisi gli importi.

Seguendo un paio di ulteriori passaggi come meglio illustrato nell’immagine sopra siamo arrivati ad un portafoglio abbastanza interessante: l’ammontare degli importi ricevuti è di ben 224 BTC, ossia 1,4 milioni di dollari circa!!

Ci siamo fermati qui, essendo di fatto impossibile seguire le migliaia di transazioni in ingresso e in uscita di ogni singolo portafoglio coinvolto, ma credo questo basti a rendere l’idea di quanto redditizio sia il business della Cyber Criminalità !

Credo che questo esempio risponda appieno a coloro che chiedono perchè investire in Cyber Sicurezza, e perchè proteggere la propria mail con una soluzione all’avanguardia quale appunto Libra ESVA!

 

 

 

Tracking pixels, or beacons, are widely used in email advertising, but a more subtle and dangerous use is possible.

Tracking pixels are basically very small images (usually invisible to the human) embedded in the email, whose content is loaded from a server when the email is opened.

When your email client loads this image from the server, the server knows that you opened the email. In email marketing this is used to get an approximate count of the open rate of an advertising campaign (how many recipients opened the email) and to keep track of “active” recipients, recipients who receive emails in the inbox and open them.

There are other more subtle uses of the information that tracking pixels leak. When the email client (or the browser) loads the email, the following information can be collected by the server:

  • Identity of the recipient opening the email (at least the email address the email has been sent to)
  • Time and day
  • IP address
  • Information about the mail client or browser and the operating system (or device)

This information is not valuable only for marketing purposes but it can be very valuable also for malicious uses, like targeted phishing attacks.

Let’s make an example: by sending an email to your company’s CEO and getting the email beacon at 8:12 AM from the IP address of a hotel in eastern Europe, the attacker knows that the CEO is currently on a business trip in this place.

At this point a Business Email Compromise (BEC, or Whaling) attack can be performed by sending an email back to the office, impersonating the CEO and requesting an urgent money transfer or a classified internal document related to the trip. The knowledge of these details can make the phishing message quite credible and effective.

With tracking pixels the attacker can gather information about movements of executives, habits of employees, about who is on holiday and who isn’t and, with some additional intelligence, can infer company strategies and secrets: a meeting at a lawyers office or with a specific partner can reveal the progress status of a secret negotiation or deal.

Many email clients don’t open images by default but the user can be easily tricked into displaying images. The best defense is to disarm such beacons before the email is delivered, which is what Libra Esva does.

 

We spotted an instance of what appears to be a targeted attack through a phishing email delivering a .mobileconfig file. This is a file format used to deliver configurations to iphones.

The attack originates from domain that appears to have been created just for this purpose.

This is how the email appears to the recipient:

The attachment of course is not an order but the mobileconfig file.

Here are the email source headers of this email coming from the domain jimgyow.com, I’ve redacted the information about the recipient:

 

The attachment is a file named adm001@jimgyow.com.mobileconfig whose content is displayed in the following image:

Once opened, the file will automatically configure, on the victim’s iphone, a new email account for the address adm001@jimgyow.com. The configuration file does not provide the password, which will then be prompted to the user and submitted to the mail server controlled by the attacker.

The configuration file is signed with a valid certificate issued to jimgyow.com:

If you have information about other uses of this attack vector, we’d be happy to hear from you. Just use the “contact us” form on this website.

 

 

Rodolfo Saccani, security R&D manager at Libra Esva

It’s almost one month now that a very effective malspam campaign delivering the ursnif trojan is in progress in Italy.

The trick that the malware uses to spread is simple and effective: once run on the victim’s machine it sends replies to existing email threads attaching a copy of the malware itself.

This strategy is so effective that many users release those emails from the quarantine and even report them as false positives, before getting infected themselves. This is still happening with tens of false positive reports per day.

Ursnif is basically a trojan that hijacks remote banking sessions or steals credentials, the malware itself varies and keeps changing over time. The dropper is a word document with an obfuscated macro. Also the macro keeps changing and this makes it very hard for antivirus scanners to intercept the new variants. This is why many of these emails, not being flagged by the antivirus, are quarantined without the “malware” tag which would make it harder for the recipient to release it.

Many users, seeing a reply to an existing thread from one of their contacts in the quarantine, are so convinced that it is a legit email that they release it from the quarantine and even report the message as a false positive to our laboratories, then open the attachment, enable the macros and get infected themselves. At that point the malware starts spreading to their own contacts with replies to existing threads and the campaign propagates.

This is how the email looks like:

The message contains very few words: “Buongiorno, Vedi allegato e di confermare. Cordiali saluti” followed by the real signature of the infected account and the existing email thread below.

The phrase, spelled in an incorrect Italian (but this doesn’t seem to impair the effectiveness), basically says: “Good morning, check the attachment and confirm. Best regards.”

The attachment, usually named Richiesta.doc (Richiesta means Request) is a word document:

The document pretends to be created with a previous version of Microsoft Office and, as usual, instructs the user to enable the macros.

The macros are obfuscated, they keep changing so that signature and pattern based systems can’t catch-up, and they contain an AutoOpen action that executes a powershell script that downloads and install the payload.

Here is a list of macros contained in the file:

And here is one of the AutoOpen variants:

This campaign, just as other malware campaigns like Emotet for example, has an ever-changing dropper that highlights all of the limits of the defense approaches based on signatures and patterns. Antivirus engines are releasing every day hundreds of new detection rules for these ever-changing samples but the latency of the process guarantees the delivery of many samples that are not yet identified by the anti-virus engines.

These emails are being quarantined by content checks and the attachments are blocked or disarmed by our QuickSand sandboxing service, which is a service that disarms active code when the typical operations that enable the dropper functionality are present. This is an approach that doesn’t have the drawbacks of signature and pattern-based approaches and proved to be quite effective in blocking unknown and ever-changing malware variants.

Despite these emails being blocked by these additional layers of protection, the phishing component is so strong that some users voluntarily override all of the safety checks and get infected anyway. This simple phishing trick can induce a recipient to go through a significant effort in order to help the malware authors: release the email from the quarantine, open it, launch the attachment, enable the macros and in some cases even report the email as a false positive.

This is how powerful deception can be.

As most of you probably know MailChimp is a widely used and well respected email newsletter and marketing automation service.

It’s not a news that hackers tend to focus on popular services, and that’s exactly what we noticed in at least two different Italian malware campaigns in the last week, where they jumped on MailChimp popularity to spread malware sending out emails containing malicious links. What is noticeable is the questionable MailChimp security approach in response to those incidents.

Let’s start with a little more of context describing the malware campaigns and the steps we took.

The first round of phishing emails containing links to malware pretended to be a notification for taxes to be paid within the 1st of February. The subject was “F24 ACCONTI-Codice Tributo 4034”. F24 is an Italian tax form. “Codice Tributo” stands for “Tax Code” and “Acconti” are tax payments made in advance, before the actual amount due for the year is calculated.

The target was clearly Italy and a single MailChimp account has been used in this round, the emails contained links to the MailChimp subdomain fallriverproductions.us16.list-manage.com. Apparently this is a MailChimp account that has been compromised and used to deliver the malware.

What’s important to note, though, is that the recipients of these phishing emails aren’t the original recipients of the MailChimp account. Whoever compromised the account uploaded their own list of email addresses which included harvested addresses and also spamtraps.

Here is a sample of the first round of MailChimp phishing emails:

MailChimp phishing sample, pretending to come from the Italian Ministry of Finance. The friendly-from is info@fallriverproductions.com. The MailChimp Feedback-ID is 76673258:76673258.249363:us16:mc

 

Most of these emails slipped through email filters as they were originating from a hacked account on a respectable service, and only an advanced protection like our URLSand Protection was effective protecting users that clicked on the malicious links, but obviously this is not enough!

MailChimp has been contacted and the abuse reported, but maybe due to timezone issues, a huge amount of emails had already been sent when MailChimp abuse team managed to stop the activity.

At this point a second round of phishing emails started, this time pretending to be a notification for taxes to be paid within the 5th or the 6th of February. The subject was either “Codici Tributo Acconti” or “f24 accontiCodici Tributo”. Two MailChimp accounts have been used in this round, the emails contained links to these MailChimp subdomains: amber-kate.us3.list-manage.com, lc-hc.us16.list-manage.com. Again, these seem to be MailChimp accounts that have been compromised and used to deliver the malware.

Here are the samples for the second round:

MailChimp phishing sample, pretending to come from the Italian Ministry of Finance. The friendly-from is info@amber-kate.com. The MailChimp Feedback-ID is 24073083:24073083.1514657:us3:mc

 

MailChimp phishing sample, pretending to come from a financial company. The friendly-from is info@lc-hc.org. The MailChimp Feedback-ID is 79510402:79510402.290027:us16:mc

 

 

Apparently the hackers got control of multiple MailChimp accounts and as soon as one got suspended they started using another one. Everytime the hackers managed to upload huge lists of recipient email addresses to which deliver the malware email campaign. Apparently this didn’t trigger abuse prevention alerts.

We tried to contact MailChimp on multiple channels: two different abuse forms and twitter. We reported the abuse identifying the compromised accounts and we proposed to set-up a communication channel to quickly share intelligence: we would quickly report to MailChimp new abuses and MailChimp would quickly report to us new compromised accounts so that we could proactively protect our customers without penalizing all of the MailChimp traffic. Everytime we got template responses like the following one.

A template response from MailChimp

 

The problem in being reactive in this way (with additional delays related probably to timezone differences) is that once the abuse is reported and the account is suspended, all of the malicious emails are already gone.

MailChimp doesn’t require double opt-in (it’s not even enabled by default). Every customer can upload lists of recipients (even huge ones) and send emails without the recipient having proven consent.

 

The incident shows that hackers will likely use whatever distribution channels they can in an attempt to spread their malware and turn a profit and surely MailChimp is not the only one.

Even if advanced URL sandbox services like the one offered by Libra Esva actively help protecting from these kind of attacks, we expected more from such a well respected and widely used service! At least in the management of the incident.

The company would not say what the exact issue was, but MailChimp’s statement was simply that they closed the compromised accounts, with a long delay since our first submission and not showing any collaboration in mitigating these problems to happen again.

DDE (Dynamic Data Exchange) is a very old and almost forgotten feature of Microsoft Office. Designed to automate the exchange of data between applications, it can be easily exploited to execute arbitrary code without any macro or other active content.

About one month ago, samples of office documents exploiting DDE to spread ransomware have been found in the wild. Security vendors quickly updated their products in order to detect and block such threats.

Unfortunately there are may ways to leverage DDE, some of which are quite elusive. Over the last few weeks new ways to exploit DDE eluding detection have been found and security vendors reacted with variable speed. Here, for example, is a sample of a .doc file that we posted on VirusTotal over three weeks ago. At that time no AV engine detected it, today, about one month later, less than one third of the engines detect it and some big names are among the ones that don’t.

Now, we just created a new .xls sample that is currently detected by ZERO engines according to VirusTotal. This sample is harmless, it just demonstrates how to leverage DDE eluding detection: it uses DDE to launch powershell which in turn launches calc.exe. Once you manage to execute powershell you can let it dynamically download code from a remote website and execute it. This specific sample demonstrates how to exploit DDE without being detected, we’ve tested also harmful samples (using powershell to download and execute malicious code) with the same outcome.

 

As you can see from the screenshot above, the sample is currently undetected by all of the engines running on VirusTotal.

You can download the sample from VirusTotal, we also added this sample to our Email Security Tester, a service that sends you a few emails containing different types of threats in order to test your email security setup.

 

Rodolfo Saccani

 

Obfuscated phishing sites are nothing new (on the same matter check this article Web obfuscation technique using invisible spans ) but the use of AES in an attempt to evade detection from automated detection tools like our URLSand Sandbox service, is not very common.

Despite AES and encryption in general is not a newbie argument, I am surprised how easily this approach can be adopted by anyone with a basic programming knowledge.

The only thing needed is a Javascript library, freely available for download from Movable Type Scripts.

By including this library in your page you can then serve your encrypted webpage, with a few lines:

To explain the above lines:

Line 1) includes the JavaScript AES implementation, which it calls with the embedded password defined at Line 4) and embedded encrypted data at Line 6). The decrypted phishing content is then dynamically written to the page using document.write() after calling the decryption function at Line 8).

This process happens almost instantly when the page is loaded and once decryption is complete, the phishing site is shown as normal.

Note that the use of AES here is very basic, and there is no attempt made to hide the key or anything else. But I would not be surprised if this kind of attacks will become more sophisticated in the near future!

Eng.Paolo Frizzi

In order to delay detection, phishing and malware websites often use some obfuscation technique.
Obfuscation techniques are double-edged swords. They hide the malicious content from dumb crawlers, bots and sandboxes, but smarter algorithms that know what to look for can detect the malware just by looking at it’s attempts to hide. This is one of the ways we can detect zero-day malware.

In this example we have a fake PayPal website. This page interleaves invisible spans between visible text in order to avoid detection by automated systems that perform heuristic analysis of the web page content.
You’ll get a clearer idea by looking at the following pictures.

This is the fake PayPal website as it is displayed in the browser:

PayPal phishing website

Notice the text just above the login box on the left of the page. The text says “Bitte geben Sie Ihre PayPal-Dated ein”. You will not find this phrase in the source code of the page because the phrase (and especially the word PayPal) has been interleaved with a lot of text enclosed in invisible spans. This text is present in the page but it is not displayed to the user.

Here is a part of the source code of the page (click on the image to enlarge it):

The parts in brown are the invisible spans, they contain a lot of random text that the browser is instructed not to display to the user.

The parts surrounded by yellow boxes are visible and displayed to the user. These parts compose the phrase you see on the webpage but a bot that scans the page and that doesn’t skip the invisible parts cannot find this phrase or even the word PayPal in the whole page.

Invisible content is perfectly normal in legit web pages, often some parts of the page are made visible only on specific events, often most of the page is initially invisible and made visible only when everything has been loaded. Having invisible content is not bad by itself and this is why crawlers and sandboxes don’t ignore it. Using it in this way is certainly suspicious.

Our UrlSand sandbox searches for this and other obfuscation/evasion techniques in order to detect malware.

 

Rodolfo Saccani
Libra Esva R&D Manager