Google Releases Security Updates for Chrome

This post was originally published on this site

Original release date: November 19, 2018

Google has released Chrome version 70.0.3538.110 for Windows, Mac, and Linux. This version addresses a vulnerability that an attacker could exploit to take control of an affected system.

NCCIC encourages users and administrators to review the Chrome Releases page and apply the necessary updates.

This product is provided subject to this Notification and this Privacy & Use policy.

Cybersecurity and Infrastructure Security Agency

This post was originally published on this site

Original release date: November 19, 2018

On November 16, 2018, the President signed into law the Cybersecurity and Infrastructure Security Agency Act of 2018. This Act elevates the mission of the former Department of Homeland Security (DHS) National Protection and Programs Directorate (NPPD) and establishes the Cybersecurity and Infrastructure Security Agency (CISA). CISA is responsible for protecting the Nation’s critical infrastructure from physical and cyber threats, a mission that requires effective coordination and collaboration among a broad spectrum of government and private sector organizations. 

NCCIC encourages all parties to review the DHS announcement on CISA for more information.

This product is provided subject to this Notification and this Privacy & Use policy.

The Challenge of Managing Your Digital Library, (Mon, Nov 19th)

This post was originally published on this site

How do you manage your digital library on a daily basis? If like me, you are receiving a lot of emails, notifications, tweets, [name your best technology here], they are chances that you’re flooded by tons of documents in multiple formats. This problem is so huge that, if I’m offline for a few days or too busy to handle the information in (almost) real time, it costs me a lot of extra time to process the waiting queue. While surfing, there are also a lot of documents that are not immediately useful but “could be”. Do you also have a bad feeling when you delete a document “that could be very interesting in the future?”. In fact, it’s like people who store everything in their home and that can’t trash them.

Here is a small list of data that I like to keep:

  • Emails (from mailing lists)
  • Tweets
  • PDF/papers from security conferences
  • Studies, white papers
  • Software, firmware, …
  • Configuration samples
  • Collected data (pasties, DB dumps, Darkweb data, screenshots, …)

With electronic documents, we also have another dilemma: which kind of storage? Local or in the cloud? It’s easy to store documents in the cloud. They are indexed, they are available from everywhere. Plenty of tools and services provide this but… for how long? What if you upload a few TB of data in the cloud and the service disappear? Local storage has also caveats: how to handle the amount of data across years? How to backup? How to migrate to new or more powerful technologies? How to manage your NAS, patch them, etc.

Today, I still did not found the best way to complete this task. What I’m using at the moment:

  • Splunk to index tweets, emails
  • Evernote for documents (including PDF)
  • Local NAS
  • Cloud services with buckets like B2, C2, Amazon for long retention of data files
  • Private Gitlab for configuration files, lists, pieces of code

And you? How do you manage your digital library? Please share your stories!

Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Multipurpose PCAP Analysis Tool, (Sun, Nov 18th)

This post was originally published on this site

I was looking for a tool to easily graph traffic for a project (there are many out there) and while searching I found this tool written as a project by “[…]  Daniel Botterill as part of his MSc Computer Security degree, it has been designed to take in a PCAP capture file and report back any malicious behaviour identified.”[1]

This tool is packed with options (tabs) to analyze traffic in many different ways. There is two sample pcap files included in the MalwareAnalysis folder for testing the tool or you can use your own. I update two lists in BlacklistedAddressesblacklists [3][4] folder before starting the tool for the first time. You can add any list you want which will need to be configured after you start the tool under the Analyzer Settings which I will come back later.

This tool is easy to use and requires Java to be installed in order to work. Download the package from here. It runs on Windows and Linux (I haven’t tested it on Linux) and unzip it. There are 4 scripts available to copy (as admin) the correct windows version of jnetpcap.dll to %windir%system32 or same process for to the correct Linux library. To start the program after the initial installation,  you can execute the  MalWareAnalysis.jar file.

Now it is time to configure the tool before importing any packets. To configure the tool, select Options -> Analyzer Settings:

All the different options are displayed here. For example, I wanted a Network Map to display the traffic relationships and I checked the network map box before moving on to the Blacklisted Addresses tab and added the bt_spyware.txt list to my analyzer as this graph:

Next open and import a pcap file into the PCAP Analyzer:

The pcap I picked contained all the web connections to my honeypot for the last 24 hours. I now go to the Network Map tab and check the traffic relationship between my honeypot (center and the inbound connections to the web server. The graph shows how many attempts per IP and sometimes shows the URL. You can adjust the Network Map Layout (drop down from top) to view the IPs or move the icon around. You can see one of the source to the right requested various PHP scripts 319 times(only first one shown) against the honeypot. The thicker is the line, the more traffic between the hosts.

This one of the many features available. The last feature I am going to used is the Stream Viewer -> TCP Streams. Each packet can be selected to view the ASCII data (if readable)

It is not a replacement for Wireshark but has many of its features where some are easier and quicker to use and can be very useful as another tool to analyze traffic and its payload. There are so many more features I could talk about, you just have to test it for yourself if it should become part of your security set.


Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Quickly Investigating Websites with Lookyloo, (Sat, Nov 17th)

This post was originally published on this site

While we are enjoying our weekend, it’s always a good time to learn about new pieces of software that could be added to your toolbox. Security analysts have often to quickly investigate a website for malicious content and it’s not always easy to keep a good balance between online or local services. When you submit information to a free online service, they’re good chances that data you submitted are logged and probably analysed/re-used, remember nothing is “for free”. Lookiloo is a tool developed by CIRCL (the Luxembourg CERT) that helps to have a quick overview of a website by scraping it and displaying a tree of domains calling each other. The name “Lookyloo” comes from the Urban Dictionary[1] and means “People who just come to look”.  The tool provides a simple web interface to submit a new site to query or to review previous analysis:

And a few seconds later, you get a tree of domains used by this website. Here is an example of a website used to deliver spam:

For each domain, you get the following information (if detected):

  • Presence of Javascript 
  • Cookie received
  •  Cookie read
  • Redirect
  • Cookie in URL

Some website (particularly news websites) are nice to analyze. Here is the result of scraping

Lookyloo is available on the CIRCL git repository[2]. I recommend you to use the provided docker-compose.yml file to run your own Docker container.


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Is there a recommended value on QFullSampleSize,QFullThreshold on vSAN??

This post was originally published on this site


 ・ESXi 6.5 U2

 ・HPE 3PAR StoreServ is connected with iSCSI

 ・vSAN is also connected



・We are doing troubleshooting on performance and we are trying to change the value of QFullSampleSize
and QFullThreshold (default is 0,8) to 32,4

・Do we need to reboot before we set up all these stuff


Thank you



Basic Obfuscation With Permissive Languages, (Fri, Nov 16th)

This post was originally published on this site

For attackers, obfuscation is key to keep their malicious code below the radar. Code is obfuscated for two main reasons: defeat automatic detection by AV solutions or tools like YARA (which still rely mainly on signatures) and make the code difficult to read/understand by a security analyst.

Languages like PHP or Powershell are very permissive in the way they handle variables and functions. They also provide plenty of functions that are normally not malicious at all but which can sometimes “ring a bell” when found in pieces of code. A few daya ago, I found a webshell sample that was Base64 encoded (classic behaviour) but instead of calling the function directly, it was stored in a variable. This name being in a variable, it can also be obfuscated. Check out this piece of code:

1: <?php
2: $D=strrev('edoced_46esab’);
3: $s=gzinflate($D('7X39d9s2sujvPaf/A83qBmIi0ZKcdLOSKdtNnE3e5uvGzrZ9tq9KSZTEhiJV...

strrev() is a simple PHP function to revert a string. $D contains “base64_decode” and processes the output of gzinflate(). Simple!

But PHP is not the only language to allow this. Powershell too. There is no native strrev() function in Powershell (as far as a know but I’m not a “guru” in Powershell). So, let’s create our own strrev():

1: function strrev() {
2:   param([string]$s)
3:   $in = $s.ToCharArray()
4:   [array]::Reverse($in)
5:   $out = -join($in)
6:   return $out
7: }

Call the  function with a random name and, now, you can call the obfuscated function to hide suspicious ones:

1: $a = "tseuqeRbeW-ekovnI"
2: $b = lyJF5FnYlGDP($a)
3: $data = &$b "hxxp://"

So, it could be a good idea to search for interesting/rare function names in your hunting regex or YARA rules. Here are some other examples grabbed (mainly from

1: <?php
2: $v1 = strrev("edoced_46esab");
3: $v2 = strrev("sserpmocnuzg");
4: eval($v2($v1("eF7VPO1227aS/3NO3gFh1FJqFEuynSaVRPrGlrzx…

Or this one:

1: <?php 
2: $thycsy=chr(99)."r".chr(101).chr(97)."t".chr(101).chr(95)."x66"."u".chr(110).chr(99)."t"."i"."x6f"."n";
3: $szsglt = $thycsy('$a',strrev(';)a$(lave')); 
4: $szsglt(strrev(';))”=oQD9lQCK0QfJkQCK0gCNsjZ1JGJg8GajVWCJkQCK0QfJkQCJoQDJkQ..."(edoced_46esab(lave'));?>

Base64 encoded strings are also present everywhere (think about all email attachments). If you are hunting for interesting strings, search for them in ASCII or encoded with two bytes per character (use the ‘wide’ YARA keyword[1]) but search also for their Base64 encoded version! Some examples:

  • “Confidential” : Q29uZmlkZW50aWFs
  • “Invoke-Expression”: SW52b2tlLUV4cHJlc3Npb24=
  • “ShellExecute”: U2hlbGxFeGVjdXRl
  • “eval”: ZXZhbA==

Simple obfuscation technique but it works!


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Announcing General Availability of the Windows Compatibility Module 1.0.0

This post was originally published on this site

The Windows Compatibility module (WindowsCompatibility) is a PowerShell module that lets PowerShell Core 6 scripts access Windows PowerShell modules that are not yet natively available on PowerShell Core. (Note: the list of unavailable commands is getting smaller with each new release of PowerShell Core. This module is just for things aren’t natively supported yet.)

You can install the module from the PowerShell Gallery using the command

Install-Module WindowsCompatibility

and the source code is available on GitHub. (This is where you should open issues or make suggestions.)

Once you have WindowsCompatibility installed, you can start using it. The first thing you might want to run is Get-WinModule which will show you the list of available modules. From that list, choose a module, say PKI and and load it. To do this, run the following command:

Import-WinModule PKI

and you’ll have the commands exported by the PKI module in your local session. You can run them just like any other command. For example:

New-SelfSignedCertificate -DnsName localhost

As always, you can see what a module exported by doing:

Get-Command -module PKI

just like any other module.

These are the most important commands but the WindowsCompatibility module provides some others:

  • Invoke-WinCommand allows you to invokes a one-time command in the compatibility session.
  • Add-WinFunction allows you to define new functions that operate implicitly in the compatibility session.
  • Compare-WinModule lets you compare what you have against what’s available.
  • Copy-WinModule will let you copy Window PowerShell modules that are known to work in PowerShell 6 to the PowerShell 6 command path.
  • Initialize-WinSession gives you more control on where and how the compatibility session is created. For example. it will allow you to place the compatibility session on another machine.

(See the module’s command help for more details and examples on how to use the WindowsCompatibility functions.)

How It Works

The WindowsCompatibility module takes advantage of the ‘Implicit Remoting‘ feature that has been available in PowerShell since version 2. Implicit remoting works by retrieving command metadata from a remote session and synthesizing proxy functions in the local session. When you call one of these proxy function, it takes all of the parameters passed to it and forwards them to the real command in the “remote” session. Wait a minute you may be thinking – what does remoting have to do with the WindowsCompatibility module? WindowsCompatibility automatically creates and manages a ‘local remote’ session, called the ‘compatibility session’ that runs with Windows PowerShell on the local machine. It imports the specified module and then creates local proxy functions for all of commands defined in that module.

OK – what about modules that exist in both Windows PowerShell and PowerShell core? Yes – you can import them. After all, there are still a fair number of base cmdlets that aren’t available in PowerShell core yet.

So how does this work? WindowsCompatibility is very careful to not overwrite native PowerShell core commands. It only imports the ones that are available with Windows PowerShell but not with PowerShell Core. For example, the following will import the PowerShell default management module

 Import-WinModule  Microsoft.PowerShell.Management

which contains, among others, the Get-EventLog cmdlet. None of the native PowerShell Core cmdlets get overwritten but now you have Get-EventLog available in your session.

At this point, if you call Get-Module, you will see something a bit strange:

Get-Module | ForEach-Object Name

results in output that looks like:


Import-WinModule renames the compatibility module at load time to prevent collisions with identically named modules. This is so the module qualified commands will resolve against the current module. In fact, if you want to see what additional commands were imported, you can run:

Get-Command -Module  Microsoft.PowerShell.Management.WinModule


Because WindowsCompatibility is based on implicit remoting, there are a number of significant limitations on the cmdlets imported by the module. First, because everything is done using the remoting protocol, the imported cmdlets will return deserialized objects that only contain properties. Much of the time, this won’t matter because the parameter binder binds by property name rather than by object type. As long as the required properties are present on the object, it doesn’t matter what type the object actually is. There are, however, cases where the cmdlet actually requires that the object be of a specific type or that it have methods. WindowsCompatibility won’t work for these cmdlets.

Windows Forms and other graphical tools

The remoting session is considered non-interactive so graphical tools such as notepad or Winforms scripts will either fail, or worse hang.

Linux and Mac support

This module depends on WinRM and the client libraries on these platforms are known to be unstable and limited. So for this release, only PowerShell Core running on Windows is supported. (This may change in the future. But you’ll still need a Windows machine with Windows PowerShell to host the compatibility session.)

PowerShell 6.1 Dependency

WindowsCompatibility depends on a feature introduced in PowerShell Core 6.1 for keeping the current working directory in both the local and compatibility sessions synchronized. Earlier versions of PowerShell will work with WindowsCompatibility but won’t have this directory synchronization feature. So if you’re running PowerShell Core 6.0, import a command that writes to files, do Set-Location to a new directory, then use that command to write to a file with an unqualified path; it will use the original path from when the module was imported rather than your sessions current working directory. On PowerShell Core 6.1, it will correctly use the current working directory.


To sum it all up, the WindowsCompatibility module provides a set of commands that allow you to access Window PowerShell modules from PowerShell Core 6. There are however, some limitations that make it unsuitable for all scenarios. Over time, as more and more modules are ported to .NET Core/PowerShell 6 natively there will be less need for this module.

Bruce Payette,
PowerShell Team.

Emotet infection with IcedID banking Trojan, (Thu, Nov 15th)

This post was originally published on this site


Emotet malware is distributed through malicious spam (malspam), and its active nearly every day–at least every weekday.  Sometimes the criminals behind Emotet take a break, such as a one month-long hiatus from early October through early November, but the infrastructure pushing Emotet has been very active since Monday 2018-11-05.

As Symantec and others have reported, the group behind Emotet has evolved from maintaining its own banking Trojan, and it now also distributes malware for other groups.  I commonly see follow-up malware like Trickbot and Zeus Panda Banker during Emotet infections generated in my lab environment.

Shown above:  Chain of events for recent infections caused by Emotet malspam.

Today’s diary examines an Emotet infection on Wednesday 2018-11-14 with the IcedID banking Tojan as its follow-up malware.


A quick check of URLhaus showed me several URLs tagged emotet and heodo, which is another name for Emotet.  After you’ve seen enough of these URLs, you get a feel for their patterns and can identify an Emotet URL by looking at it.

Shown above:  Several Emotet URLs I saw on URLhaus.

Using a vulnerable Windows host, I picked an Emotet URL to download a Word document.  I opened the document, enabled macros, and saw the expected infection traffic.

Shown above:  Example of a Word document downloaded from an Emotet URL.

Shown above:  Traffic from an infected Windows host filtered in Wireshark.

Forensics on the infected Windows host

After reviewing the infection traffic, I checked my infected Windows host for malware.  Malware binaries for both Emotet and the IcedID banking Trojan were in the same places I’ve seen them before.

Shown above:  Emotet persistent on my infected Windows host.

Shown above:  IcedID persistent on my infected Windows host.

Indicators of Compromise (IoCs)

Malware from my infected Windows host:

SHA256 hash: 045e15c1df7c712dcac94c720b81df08fd0ff4e4c177d231d5cdcd7b4d096f95

  • File size: 94,592 bytes
  • File name: form-363439590633444.doc (random file names depending on the download URL)
  • File description: Downloaded Word doc with macro for Emotet

SHA256 hash: d6dd56e7fb1cc71fc37199b60461e657726c3bf8319ce59177ab4be6ed3b9fb4

  • File size: 430,080 bytes
  • File location: C:Users[username]AppDataLocalMicrosoftWindows[random name].exe
  • File description: Emotet malware binary on the infected Windows host

SHA256 hash: 667cda76b582c0771f85ad12167238e0f4bb12f479030d99c8a15d7f08eb9975

  • File size: 421,888 bytes
  • File location: C:Users[username]AppDataLocalMicrosoftWindows[random name].exe
  • File description: updated Emotet malware binary on the infected Windows host

SHA256 hash: cb04718694115b94b4d8bde2be0a4daf802c7a4c94f9b81811872e4e7126e813

  • File size: 424,960 bytes
  • File location: C:ProgramDataOFyKiE6aak4yfFf.exe
  • File description: IcedID banking Trojan retrieved by Emotet

SHA256 hash: 63e348c05cd94f4488f7f1707ba901ddfa8ec04b4626a46ae2d9d0a83ae291ae

  • File size: 424,960 bytes
  • File location: C:ProgramData{3B5AAD3D-DD3D-452D-B98C-9F29F9D9C0D3}czvgbwww.exe
  • File description: IcedID banking Trojan persistent on the infected Windows host

Traffic from my infected Windows host:

Traffic that returned the initial Word document:

  • port 80 – – GET /En_us/Documents/11_18/

Traffic that returned the Emotet malware binary:

  • port 80 – – GET /PspAMbuSd2
  • port 80 – – GET /PspAMbuSd2/

Post-infection traffic caused by Emotet:

  • port 8080 – Attempted TCP connections, no response from the server
  • port 7080 – Attempted TCP connections, no response from the server
  • port 8080 – Attempted TCP connections, no response from the server
  • port 8080 – – GET /
  • port 80 – Attempted TCP connections, no response from the server
  • port 443 – – GET /
  • port 7080 – – GET /
  • port 8080 – Attempted TCP connections, no response from the server
  • port 80 – – GET /
  • port 443 – – GET /
  • port 443 – – GET /whoami.php
  • port 50000 – – GET /
  • port 8443 – – GET /
  • port 80 – Attempted TCP connections, no response from the server
  • port 8080 – – GET /
  • port 8080 – – GET /
  • port 443 – – GET /
  • port 8080 – Attempted TCP connections, no response from the server
  • port 443 – Attempted TCP connections, no response from the server
  • port 990 – – GET /
  • port 8080 – Attempted TCP connections, no response from the server
  • port 8080 – – GET /
  • port 443 – Attempted TCP connections, no response from the server
  • port 990 – – GET /
  • port 443 – – GET /
  • port 80 – Attempted TCP connections, no response from the server
  • port 8080 – – GET /
  • port 443 – Attempted TCP connections, no response from the server
  • port 990 – – GET /
  • port 7080 – Attempted TCP connections, no response from the server
  • port 443 – Attempted TCP connections, no response from the server
  • port 80 – – GET /
  • port 80 – – GET /
  • port 8080 – – GET /
  • port 8080 – Attempted TCP connections, no response from the server

Post-infection traffic caused by the IcedID banking Trojan:

  • port 443 – – SSL/TLS traffic caused by IcedID
  • port 80 – – GET /data2.php?0123456789ABCDEF (different hex characters depending on the infected host)

Final words

Both Emotet and IcedID have remained fairly consistent in their behavioral patterns, so nothing here is unusual.  This diary is yet another reminder the criminals behind Emotet remain active, and they continue to push follow-up malware like the IcedID banking Trojan.

A pcap of the infection traffic and the associated malware from today’s diary can be found here.

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Day in the life of a researcher: Finding a wave of Trickbot malspam, (Wed, Nov 14th)

This post was originally published on this site


Mass-distribution campaigns pushing commonly-seen malware are not often considered newsworthy.  But these campaigns occur on a near-daily basis, and I feel they should be documented as frequently as possible.  Frequent documentation ensures we have publicly-available records that reveal how these campaigns evolve.  Minor changes add up over time.

Today’s diary illustrates a small part of my workday, as I review information and track down a campaign using malicious spam (malspam) to distribute Trickbot malware.

Reporting methods

A growing number of people are using social media tools like Twitter to share information about malware and malicious network activity.  Twitter offers a near-real-time way to push information to a large amount of people.  Security professionals and enthusiasts can easily find, share, and act on this information.

Keep in mind, this sort of public sharing should never include sensitive data.  You should never reveal your organization’s internal network or divulge any classified or confidential documents.  Criminals are likely monitoring public-facing services like VirusTotal and other malware scanning sites, because they “are becoming containers for personal, business and even classified information…

Some security professionals use private communication methods with a restricted audience, but those methods don’t often apply to the vast majority of people working in information security.  When possible, I prefer to share malware information publicly.

Gathering information

Like many researchers, I use a combination of public and non-public resources when investigating malware.  One great public resource is URLhaus.  URLhaus is a project operated by that helps security researchers, vendors and law enforcement agencies make the Internet a safer place.

On Tuesday 2018-11-13, I was browsing through URLhaus and found two URLs tagged as Trickbot.  I’ve researched a great deal of Trickbot activity, so I knew these URLs could be traced to malspam with an attached Microsoft Office document using macros to download and install Trickbot.

Shown above:  Two URLs tagged as Trickbot according to URLhaus.

I checked my employer’s tools, where I found at least 20 examples of malspam using attached Word documents with macros to generate these URLs.  The malspam was very recent, and no samples of the attached Word documents had yet been submitted to VirusTotal.  I could find information and file hashes from my employer’s tools, but I could not acquire a Word doc to generate any infection traffic.

However, those two URLs from the URLhaus list were still active, so I used one to retrieve a Trickbot binary.  I then used that binary to infect a Windows host in my lab which generated the expected infection traffic.  Post-infection activity revealed the campaign ID as sat101.  These campaign IDs are tagged as <gtag> in configuration files on infected Windows hosts, and they can be used to determine distribution characteristics of the campaign.  For example, Trickbot using campaign IDs starting with “sat” are used in malspam targeting recipients in the United States.

Shown above:  Tuesday’s Trickbot infection traffic filtered in Wireshark.

Quick reporting

With enough information to describe Tuesday’s Trickbot campaign in the US, I wanted to quickly report it.  But compiling a blog post would take at least two hours.  Twitter was my speediest alternative.  I dumped the data to a Pastebin page, created some images, and tweeted the results.

Shown above:  The tweet I sent.

Final words

This diary shows a small part of my workday, and it reveals how I found a recent wave of Trickbot malspam.  As of 20:24 UTC on Tuesday 2018-11-13, none of the associated Word documents were available on VirusTotal.  But a sample of the Trickbot binary had been submitted to

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.