Second email I've received today (some headers omitted):

Return-Path: <>
Received: from unknown (HELO (
by with SMTP; 27 Jan 2017 11:25:22 -0000
Received: from unknown (HELO o) (
by with SMTP; 27 Jan 2017 14:25:17 +0300
Subject: question
Date: Fri, 27 Jan 2017 12:25:26 +0100
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331

This is a multi-part message in MIME format.

Content-Type: multipart/alternative;

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable

Hey. I found your software is online. Can you write the code for my proje=
ct? Terms of reference attached below.
The price shall discuss, if you can make. Answer please.

Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

(HTML omitted)


Content-Type: application/octet-stream;
Content-Transfer-Encoding: base64
Content-Disposition: attachment;

The "PROJECT.gz" file, despite its extension, was actually a RAR archive containing a "PROJECT.doc" MS Word document, presumably with some malicious macro payload (I didn't bother to check).

The earlier one had a "" attachment, with a "2701.doc" inside, likely the same as the other one (unfortunately I had not kept it for reference).

Both messages appearing to be hand-crafted, and the reference to today's date in the attachment file name IMHO hint at a focused campaign explicitly targeting targets perceived as "high return investments", such as developers (possibly working on popular / open source projects).

I doubt many of us would fall for this stuff, but I felt a heads up was in order nonetheless ;)


As soon as I published this post I checked my inbox and there was another one...

Update 2

It looked like a VBA marcro malware, indeed. Thanks Ludovic for reminding me of Virustotal.

An update from the field by a friend of a friend on the situation in Turkey.
It's hard to believe Erdogan's criminal regime sits practically inside Europe and is a prominent member of NATO.

Today 11 HDP (Peoples’ Democracy Party) parliamentarians were taken into custody. And to-date, 170 media outlets have been banned, 130 journalists in prison, and 30 democratically elected Kurdish Mayors in prison.

Today, the Turkish police took eleven HDP (Peoples’ Democracy Party) parliamentarians, including the co-chairs Selahattin Demirtas and Figen Yuksekdag, into custody in after-midnight raids. The MPs’ houses and the party’s headquarters were raided, doors were broken and the parliamentarians were forcefully detained.

In the past several months, the government has been using the coup attempt on July 15th as an opportunity to consolidate its rule by eliminating every single oppositional voice in the country, especially the HDP, which halted the authoritarian project of a presidential system both in the June and November elections in 2015 by preventing his AKP to win sufficient number of parliamentary seats to make the necessary constitutional changes.

About 30 democratically elected Kurdish mayors are in prison now and about 70 of them have been dismissed by the central government.

The freedom of expression has been almost entirely undermined. With government decrees with the power of law, over 170 media outlets have been banned. More than 130 journalists are in prison, also including some world-renowned authors and intellectuals.

Most recently, two Kurdish news agencies and several Kurdish dailies were closed and the chief-editor, columnists and journalists of the pro-Republican People Party (CHP) daily Cumhuriyet were detained. Many academics are under criminal investigation for signing a peace petition.

Friends from around the globe, these are days when we most need international solidarity.

On April the 7th at 22:53, Aaron wrote:

I just read a Digital Trends article that states NoScript is a security breach. What's the story here???

It's a story of FUD and sensationalism, which got reported in such a careless way that now makes explaining and correcting readers' perception an uphill battle.
They've just demonstrated that rather than invoking a low-level function directly, like any installed add-on could do anyway, a malicious Firefox extension that has already been approved by an AMO code reviewer and manually installed by the user can invoke another add-on that the same user had previously installed and perform the low-level tasks on its behalf, not in order to gain any further privilege but just for obfuscation purposes.

It's like saying that you need to uninstall Microsoft Office immediately because tomorrow you may also install a virus that then can use Word's automation interface to replicate itself, rather than invoking the OS input/output functions directly. Or that, for the same reasons, you must uninstall any Mac OS application which exposes an AppleScript interface.

BTW, if you accept this as an Office or AppleScript vulnerability, Adblock Plus is not less "vulnerable", so to speak, than the other mentioned add-ons, despite what the article states. It's just that those "researchers" were not competent enough to understand how to "exploit" it.

And I'm a bit disappointed of Nick Nguyen who, rather than putting some effort in rebutting this cheap "research", chose the easier path of pitching our new WebExtensions API, whose better insulation and permissions system actually makes this specific scenario less likely and deserves to be praised anyway, but does not and could not prevent the almost infinite other ways to obfuscate malicious intent available to any kind of non-trivial program, be it a Chrome extension, an iOS app or a shell script. Only the trained eye of a code reviewer can mitigate this risk, and even if there's always room for improvement, this is what makes AMO stand out among the crowd of so called "market places".

Since last time I wrote about WebExtensions, a lot has been going on: for instance, I used to link a Mozilla Wiki article, and as you can see now I'm linking a full featured MDN entry :)

In the meanwhile, I've been among other things hacking the WebExtensions code itself to make it suitable for eventually porting my own extensions, NoScript and FlashGot, and all those which share similar requirements.

The key WebExtensions API needed by adblockers (one of the most popular browser extensions category), by anti-trackers like Ghostery and, of course, by security add-ons like NoScript, is WebRequest. Its first implementation as a JavaScript module (still the foundation of the current one, which is a thin wrapper over it) even predates WebExtensions themselves: genius e10s hacker Bill McCloskey started it as a brave experiment to see how realistic could have been migrating Adblock/Ghostery/NoScript to the still just rumored "next thing" in add-on development.

Unfortunately, the way this API was originally implemented imposed harsh limitations, both in Chrome compatibility and, more annoyingly, in suitability for the very kind of add-ons it was meant to support. But we've got good news: I've recently landed a couple of patches (after a long time spent away from Mozilla's code repositories), paving the way to the removal of the remaining Chrome incompatibilities and for the addition of new divergent features required by NoScript & Co. which by the way, if ever borrowed in Chromium, could even finally make a NoScript porting on Google's browsers and derivatives possible.

More specifically, Firefox 47 adds:

  • The requestId property in every WebRequest event, allowing listeners to track individual requests across their entire lifecycle (yes, it's incredible we had not implement it yet, and it was the main blocker for Ghostery as a WebExtension).
  • Reliable HTTP headers manipulation - they can be examined, deleted, added or modified both in requests (by onBeforeSendHeaders listeners) and responses (onHeadersReceived) as plain JavaScript arrays of name-value pairs.
  • HTTP response status code and raw status line reporting - without this, it was almost impossible telling the type of a redirection or even whether a request succeeded or failed and how.
  • Coming very soon:

    • The onErrorOccurred event (patch ready, will surely land in 48), also needed by Ghostery.
    • The requestBody property, which allows onBeforeRequest listeners to analyze the payload of POST and PUT requests and is required by NoScript's XSS filter.
    • An "origin" property, which is required not just by many features of NoScript's but also by other add-ons such as RequestPolicy.

    I'm very satisfied with the work done so far, and as soon as the 3 features above are completed, I'm ready to take on other areas where the Chrome extensions API (hence, for obvious reasons, WebExtensions in their present state) are severely lacking, such as script execution control and fine-tuned content blocking, which still prevent NoScript from migrating.

    During the past weeks I've grown intimate with the WebExtensions API source code and familiar enough with the "modern" Firefox development workflow. I'm sure this incoming spring will be a most interesting time, and I'm confident that summer will come with a brand new NoScript, reborn as a WebExtension :)

WebExtensions are making some people happy, some people angry, many people ask questions.
Some of the answers can be found here, more to come as add-on developers keep discussing this hot topic.
My favourite one: No, your add-ons' ability and your own creativity won't be limited by the new API.

« Previous Entries

Bad Behavior has blocked 3729 access attempts in the last 7 days.