back to article Oh my Microsoft Word: Dridex hackers exploit unpatched flaw

Cybercrooks are actively exploiting an unpatched Microsoft Word vulnerability to distribute the Dridex banking trojan, claim researchers. Booby-trapped emails designed to spread the cyber-pathogen have been sent to hundreds of thousands of recipients across numerous organisations, according to email security firm Proofpoint. …

  1. SotarrTheWizard

    Oddly enough. . .

    . . . . no sign of ANY Patch Tuesday releases, so far. . .

    1. Sandtitz Silver badge
      1. Mark 85 Silver badge

        Re: Oddly enough. . . @SotarrTheWizard

        Still no sign here on the US west coast. Maybe MS rolled over and died?

      2. TheVogon

        Re: Oddly enough. . . @SotarrTheWizard

        So - translating that to something useful - In GMT that's by 6:00pm - so by 7:00pm BST...

  2. adam payne

    Just what we need, another round of Dridex.

    I'm booking a months holiday!

  3. Prst. V.Jeltz Silver badge

    still relies on the user opening a foriegn document though

    1. Peter2 Silver badge

      Which study after study as well as general experience demonstrates that they do dozens of times on a daily basis. Mostly as a result of actually having to do in order to do their jobs in most environments. You know what? I did it this morning. Had a quote in from a supplier, and I opened it.

      Having a 100% onus on the user not to open the wrong document as 100% of your security policy is overly lazy and dangerous when even MS word comes with enough group policy options to make most potential threats more or less harmless, such as disabling Active X, Macros and file downloads etc which would prevent this attack using already existing and freely available options that can be enforced on your users centrally with about 2 minutes work, 90 seconds of which opening MMC and the group policy management console.

      1. TheVogon

        You would have to open it AND deliberately turn off protected mode.

        If a document doesn't display something I recognise when loaded, no way I would turn that off.

        1. TheVogon

          Received one of these today:

          https://virustotal.com/en/file/380b47a8c82b06b1be1655253259d3935b20c439518e4e5ecec8b12551e969b2/analysis/1491999567/

          It pretends to be some sort of document from RBS and asks you in the visible text to turn off protected mode. Not particularly convincing, but I guess it catches some numpties...

    2. hplasm
      Windows

      FTFY

      still relies on the user opening a foriegn document though, with a shady operating system that should have been fixed or killed decades ago.

      That's all.

  4. Mage Silver badge
    Facepalm

    See earlier comments

    Really this is a trainwreck waiting to happen since before Win95.

    see earlier comments

    1. Roland6 Silver badge

      Re: See earlier comments

      Not a trainwreck waiting to happen, if this article is to be believed, a deliberate attempt to wreck trains:

      The Achilles heel of web apps is their restricted permissions on the client machine. By design, any process that runs within a web browser does so with limited access permissions, as to minimize the execution of malicious code. Permission levels can be customized by the user, but they tend to be quite restrictive - especially where untrusted sources are concerned. By-and-large, read, write, and execute rights are not permitted. As web applications have gained popularity, several workarounds have been introduced by vendors. Bill Gates and company have a notable advantage over the competition because they also make the most popular operating system on the planet, that of course being Windows. It should then come as no surprise that they have introduced a means of writing web applications for Internet Explorer that can bypass the usual security restrictions.

      [http://www.webreference.com/programming/HTA/index.html ]

      So if the source is to be believed, hta was a deliberate development by MS to circumvent sensible security practices!

      Given the findings of coconuthead ( https://forums.theregister.co.uk/forum/containing/3151574 )

      and my researches across various generations of Windows and the various workarounds being suggested (see thread started by Peter2: https://forums.theregister.co.uk/forum/containing/3151096 ). I have on a (albeit small) pool of systems changed their default file association for application/hta & .hta to Notepad - also I've worked out how to configure my HIPS to both monitor for traffic containing "application/hta" and blocking attempts to execute mshta.exe (32 & 64 bit versions - flagged as malware, but not to be removed for the moment) as yet nothing has broken or been flagged.

      So the question is who out there actually uses application/hta as part of their UX delivery - other than hackers. Because as far as I can see, like Flash, mshta.exe needs to be removed.

      1. Roland6 Silver badge

        Re: See earlier comments

        >So if the source is to be believed, hta was a deliberate development by MS to circumvent sensible security practices!

        The incriminating evidence:

        Why Use HTAs

        Historically, programming languages like C++ and Microsoft Visual Basic have provided the object models and access to system resources that developers demand. With HTAs, Dynamic HTML (DHTML) with script can be added to that list. HTAs not only support everything a webpage does—namely HTML, Cascading Style Sheets (CSS), scripting languages, and behaviors—but also HTA–specific functionality. This added functionality provides control over user interface design and access to the client system. Moreover, run as trusted applications, HTAs are not subject to the same security constraints as webpages. As with any executable file, the user is asked once, before the HTA is downloaded, whether to save or run the application; if saved to the client machine, it simply runs on demand thereafter. The end result is that an HTA runs like any executable (.exe) file written in C++ or Visual Basic.

        [https://msdn.microsoft.com/en-us/library/ms536496(v=vs.85).aspx ]

      2. Peter2 Silver badge

        Re: See earlier comments

        I have on a (albeit small) pool of systems changed their default file association for application/hta & .hta to Notepad

        I don't honestly think that's actually an effective blocking method. If somebody is running an API from word then I would assume that you could simply execute mshta.exe with a command line argument to open the HTA file in which case having changed the windows default wouldn't do anything.

        The appropriate blocking methods for the executable is basically denying the executable from running through group policy (which is built in to every version of windows as a free tool) to block it with either a Software Restriction Policy or an AppLocker policy.

        Personally, I advocate using a software restriction policy with a default level of "disallowed", with allow rules for %program files%. As the users then can't run programs outside of program files, but can't write to that directory then they simply can't actually execute- I had this blocked already before taking any further precautions.

        That said, never get complacent, don't rely on a single point of protection and keep reviewing what your doing when new threats pop up. On my network, this HTA threat was blocked in several different ways before this hit the news and is now blocked in six different ways before Microsoft even gets around to doing the patch. But then again, my companies relatively small size has unfortunately no relation to the level of effort miscreants put into emptying our bank accounts so I put equal effort into ensuring that the contents of our bank account stays where it is. So far I'm winning the contest quite decisively.

        1. Roland6 Silver badge

          Re: See earlier comments

          Peter2 - Agree, use of Policy is a better solution. I was simply implementing a quick trial on a bunch of non-domain systems to see if anything broke. Whilst the real solution is to remove mshta.exe, however, I suspect use of policy will be necessary to prevent execution and a possible future update (or system repair) accidentially re-enabling mshta.exe.

  5. Denarius Silver badge

    Thank $DEITY 4

    vi

    1. TheVogon

      Re: Thank $DEITY 4

      Vi? That's the most horrible non-intuitive and awkward editing program I have used anywhere ever. Surely you only use that if you are on a system from the Stoneage with nothing more recent installed?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021