The Death of Commercial AV Products - Part Deux

There was a Microsoft Word file with a Malicious Macro being distributed via email this morning.  AV Detection Rate was at the time very low for Stage 1 of this attack:

Thankfully, our Forcepoint(r) Sandbox is detecting it for us through a number of indicators, one of which shows a similarity to Zeus:

What else is happening in the attack?  As usual it is Posting/Phoning home to Mother Russia along with an HTTP Get which downloads a .exe file:

What is the detection rate for this 2nd stage of the attack?  Not so great either:

NOTE - did you see that CrowdStrike, with much fanfare, decided to contribute back to the Security Community by having their "Machine Learning" powered results displayed via VirusTotal?  While it is good that, unlike many traditional signature based engines, CrowdStrike detected this threat in Stage 2.  However, where was CrodStrike on Stage 1?  No where on Virus Total can you find their results for that initial Word Doc.  Are there agreements in place to only display their name when a positive detection is made?  Seems fishy to us.

In any case, let us help you save money by installing next gen security solutions as the AV Vendors have once again proven unsuccessful.  Call ESPO Systems if you need help...  :-)

The Death of Commercial AV Products

We keep beating the drums... reduce what is most likely the largest line item in your Security Expense Budget, Anti-Virus.  Another data point to make our case:

1. Microsoft Word file propagating the Internet as of ~8amCDT was detected by our Forcepoint Sandbox:

2. Note the SHA-256 Hash in the above screen shot.  Note the same hash below and how only 5 of 53 AV Engines are currently detecting this threat:

3. How bad is the malware?  Per below, it attempts to "post" some of your data to a site in the Ukraine:

In summary, did you see that Freeware AV Engines are detecting this threat?  Why is it you're paying all that money to the "enterprise class AV companies"?  Again... reduce your spend and invest the savings in next gen solutions.  Call ESPO Systems for a free consultation.

QUIC Best Practice

As we all know, Google has a habit of updating their code frequently.  From a Feature Perspective that is obviously good.  From a Security Perspective this can create a problem.  For example, if you have a DLP Endpoint Agent installed to identify/block confidential posts... you may have issues if Chrome gets too far out in front of your agent.  Another example is QUIC.

https://en.wikipedia.org/wiki/QUIC

This UDP Based Protocol will render your proxies useless as we setup redirection for outbound connections destined to TCP:80 & 443.  ESPO Best Practices are as follows:

Option 1: Disable Experimental QUIC protocol on individual Google Chrome browsers. - This can be done by opening Google Chrome, in the URL type "chrome://flags". Look for Experimental QUIC protocol and disable it.

Option 2: Block QUIC using firewall policy - Create a custom firewall service for UDP port 80 and port 443. Configure a firewall policy with the custom service created and set the action to Deny. Make sure this policy on top of all (inside/trusted to outside/untrusted)

Option 3:  Similar to Option 1, you can utilize a GPO to turn off QUIC protocol.  Download the latest chrome adm/admx templates from https://support.google.com/chrome/a/answer/187202?hl=en#windows and find it in Administrative templates > Google Chrome > Allows QUIC protocol.  Set to disable.

In summary, the Easy Button answer might be Option 2.  Block outbound connections destined to UDP:80 & 443 and the browser will have to fail back to TCP.

 

New Malware on the Loose

Heads up!  The following site is actively hosting malware as of the writing of this Blog Post:

What exactly is the malware doing?  Forcepoint indicates nothing good:

Well... I have Cisco you may say... I will be fine:  Ummmm no:

OK, Ok, ok... I have a web security solution from 1 of the other 68 solutions available on the market. Oops!

You may then say, I have defense-in-depth... I have a top notch AV solution.  Unfortunately, only 2 of 54 AV Engines are actively protecting against this executable:

What can I do to protect against this active threat?  Call ESPO Systems for a free consultation.

Water-Cooler Talk

When McAfee acquired Secure Computing, we pretty much all suspected Dave DeWalt was putting lipstick on his pig in an attempt to create a liquidity event for himself.  You could see a lack of integration and R&D investment from the start... much less an understanding of Network Security.  Poor Intel is now stuck holding the goods.  Case in point:

- Current MS Word Document making it's way around the Internet as of 1 hour ago and phoning home to Mother Russia per this Forcepoint Sandbox Report.

- As you'll note in the above report, the outbound call is detected in real-time by Forcepoint as a generic threat:

- What is the threat?  The Forcepoint ACE Engine identifies it as a Dropper File:

- What does Intel/McAfee think about the site?  It's a Shopping site with Minimal Risk from their perspective:

Need help in ripping out your McAfee solution for a true single pane of glass?  Connect w/ESPO Systems and request a free consultation. 

Own Your Network Security?

Cisco has recently changed their Marketing to correspond with their change of leadership/CEO.  Lets test out their current "own your network security" mantra:

1. Microsoft Word documents are propagating across the Internet with malicious macros.  If your users have opened it, they would have seen this:

2. If your users enabled editing (the macro), unbeknownst to them, they would have initiated an outbound HTTP connection to this site in Germany:

3. Question - Would Cisco have enabled you to own your security... or been owned?  Based on what we see below, it looks like you are owned:

In summary, our work can be double checked via this Forcepoint File Sandbox Report.  If you agree with our conclusions, it's likely time to discuss how you can improve your Security Controls.  Learn more about our Forcepoint Services here.

To Russia with Love

Yes... we know it was "From Russia with Love", however, in this case it's a Post not a Get.  Say what?  Well... there is a malicious M$ Word document/macro that is on the loose currently.  As usual, the AV vendors are asleep at the wheel with only 2 of 57 solutions currently protecting our IT Assets:

Why are we so confident that McAfee and others are wrong?  This Forcepoint Sandbox Report proves that rather conclusively. 

OK, Ok, ok... why "To Russia..."?  Per below, the Dropper file performs an HTTP Post to a WWW site in Mother Russia.  This is an obvious outlier as most HTTP/S traffic is Get based rather than Post. 

Why would a Post occur rather than a Get?  Likely to send out your confidential information.  Question - do you have a Data Loss Prevention (DLP) solution monitoring those outbound Posts?  What if it was HTTPS vs HTTP?  Connect w/ESPO Systems for a free consultation.