Daily Archives: July 20, 2018

TA18-201A: Emotet Malware

Original release date: July 20, 2018

Systems Affected

Network Systems


Emotet is an advanced, modular banking Trojan that primarily functions as a downloader or dropper of other banking Trojans. Emotet continues to be among the most costly and destructive malware affecting state, local, tribal, and territorial (SLTT) governments, and the private and public sectors.

This joint Technical Alert (TA) is the result of Multi-State Information Sharing & Analysis Center (MS-ISAC) analytic efforts, in coordination with the Department of Homeland Security (DHS) National Cybersecurity and Communications Integration Center (NCCIC).


Emotet continues to be among the most costly and destructive malware affecting SLTT governments. Its worm-like features result in rapidly spreading network-wide infection, which are difficult to combat. Emotet infections have cost SLTT governments up to $1 million per incident to remediate.

Emotet is an advanced, modular banking Trojan that primarily functions as a downloader or dropper of other banking Trojans. Additionally, Emotet is a polymorphic banking Trojan that can evade typical signature-based detection. It has several methods for maintaining persistence, including auto-start registry keys and services. It uses modular Dynamic Link Libraries (DLLs) to continuously evolve and update its capabilities. Furthermore, Emotet is Virtual Machine-aware and can generate false indicators if run in a virtual environment.

Emotet is disseminated through malspam (emails containing malicious attachments or links) that uses branding familiar to the recipient; it has even been spread using the MS-ISAC name. As of July 2018, the most recent campaigns imitate PayPal receipts, shipping notifications, or “past-due” invoices purportedly from MS-ISAC. Initial infection occurs when a user opens or clicks the malicious download link, PDF, or macro-enabled Microsoft Word document included in the malspam. Once downloaded, Emotet establishes persistence and attempts to propagate the local networks through incorporated spreader modules.

Figure 1: Malicious email distributing Emotet

Currently, Emotet uses five known spreader modules: NetPass.exe, WebBrowserPassView, Mail PassView, Outlook scraper, and a credential enumerator.

  1. NetPass.exe is a legitimate utility developed by NirSoft that recovers all network passwords stored on a system for the current logged-on user. This tool can also recover passwords stored in the credentials file of external drives.
  2. Outlook scraper is a tool that scrapes names and email addresses from the victim’s Outlook accounts and uses that information to send out additional phishing emails from the compromised accounts.
  3. WebBrowserPassView is a password recovery tool that captures passwords stored by Internet Explorer, Mozilla Firefox, Google Chrome, Safari, and Opera and passes them to the credential enumerator module.
  4. Mail PassView is a password recovery tool that reveals passwords and account details for various email clients such as Microsoft Outlook, Windows Mail, Mozilla Thunderbird, Hotmail, Yahoo! Mail, and Gmail and passes them to the credential enumerator module.
  5. Credential enumerator is a self-extracting RAR file containing two components: a bypass component and a service component. The bypass component is used for the enumeration of network resources and either finds writable share drives using Server Message Block (SMB) or tries to brute force user accounts, including the administrator account. Once an available system is found, Emotet writes the service component on the system, which writes Emotet onto the disk. Emotet’s access to SMB can result in the infection of entire domains (servers and clients).
Figure 2: Emotet infection process

To maintain persistence, Emotet injects code into explorer.exe and other running processes. It can also collect sensitive information, including system name, location, and operating system version, and connects to a remote command and control server (C2), usually through a generated 16-letter domain name that ends in “.eu.” Once Emotet establishes a connection with the C2, it reports a new infection, receives configuration data, downloads and runs files, receives instructions, and uploads data to the C2 server.

Emotet artifacts are typically found in arbitrary paths located off of the AppData\Local and AppData\Roaming directories. The artifacts usually mimic the names of known executables. Persistence is typically maintained through Scheduled Tasks or via registry keys. Additionally, Emotet creates randomly-named files in the system root directories that are run as Windows services. When executed, these services attempt to propagate the malware to adjacent systems via accessible administrative shares.

Note: it is essential that privileged accounts are not used to log in to compromised systems during remediation as this may accelerate the spread of the malware.

Example Filenames and Paths:

C:\Users\<username>\AppData \Local\Microsoft\Windows\shedaudio.exe

C:\Users\<username>\AppData\Roaming\Macromedia\Flash Player\macromedia\bin\flashplayer.exe

Typical Registry Keys:




System Root Directories:






Negative consequences of Emotet infection include

  • temporary or permanent loss of sensitive or proprietary information,
  • disruption to regular operations,
  • financial losses incurred to restore systems and files, and
  • potential harm to an organization’s reputation.


NCCIC and MS-ISAC recommend that organizations adhere to the following general best practices to limit the effect of Emotet and similar malspam:

  • Use Group Policy Object to set a Windows Firewall rule to restrict inbound SMB communication between client systems. If using an alternative host-based intrusion prevention system (HIPS), consider implementing custom modifications for the control of client-to-client SMB communication. At a minimum, create a Group Policy Object that restricts inbound SMB connections to clients originating from clients.
  • Use antivirus programs, with automatic updates of signatures and software, on clients and servers.
  • Apply appropriate patches and updates immediately (after appropriate testing).
  • Implement filters at the email gateway to filter out emails with known malspam indicators, such as known malicious subject lines, and block suspicious IP addresses at the firewall.
  • If your organization does not have a policy regarding suspicious emails, consider creating one and specifying that all suspicious emails should be reported to the security or IT department.
  • Mark external emails with a banner denoting it is from an external source. This will assist users in detecting spoofed emails.
  • Provide employees training on social engineering and phishing. Urge employees not to open suspicious emails, click links contained in such emails, or post sensitive information online, and to never provide usernames, passwords, or personal information in answer to any unsolicited request. Educate users to hover over a link with their mouse to verify the destination prior to clicking on the link.
  • Consider blocking file attachments that are commonly associated with malware, such as .dll and .exe, and attachments that cannot be scanned by antivirus software, such as .zip files.
  • Adhere to the principal of least privilege, ensuring that users have the minimum level of access required to accomplish their duties. Limit administrative credentials to designated administrators.
  • Implement Domain-Based Message Authentication, Reporting & Conformance (DMARC), a validation system that minimizes spam emails by detecting email spoofing using Domain Name System (DNS) records and digital signatures.

If a user or organization believes they may be infected, NCCIC and MS-ISAC recommend running an antivirus scan on the system and taking action to isolate the infected workstation based on the results. If multiple workstations are infected, the following actions are recommended:

  • Identify, shutdown, and take the infected machines off the network;
  • Consider temporarily taking the network offline to perform identification, prevent reinfections, and stop the spread of the malware;
  • Do not log in to infected systems using domain or shared local administrator accounts;
  • Reimage the infected machine(s);
  • After reviewing systems for Emotet indicators, move clean systems to a containment virtual local area network that is segregated from the infected network;
  • Issue password resets for both domain and local credentials;
  • Because Emotet scrapes additional credentials, consider password resets for other applications that may have had stored credentials on the compromised machine(s);
  • Identify the infection source (patient zero); and
  • Review the log files and the Outlook mailbox rules associated with the infected user account to ensure further compromises have not occurred. It is possible that the Outlook account may now have rules to auto-forward all emails to an external email address, which could result in a data breach.


MS-ISAC is the focal point for cyber threat prevention, protection, response, and recovery for the nation’s SLTT governments. More information about this topic, as well as 24/7 cybersecurity assistance for SLTT governments, is available by phone at 866-787-4722, by email at SOC@cisecurity.org, or on MS-ISAC’s website at https://msisac.cisecurity.org/.

To report an intrusion and request resources for incident response or technical assistance, contact NCCIC by email at NCCICCustomerService@hq.dhs.gov or by phone at 888-282-0870.


Revision History

  • July, 20 2018: Initial version

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

CVE-2014-2296 (cas_server)

XML external entity (XXE) vulnerability in java/org/jasig/cas/util/SamlUtils.java in Jasig CAS server before and 3.5.x before, when Google Accounts Integration is enabled, allows remote unauthenticated users to bypass authentication via crafted XML data.

CVE-2018-1563 (sterling_b2b_integrator, sterling_file_gateway)

IBM Sterling B2B Integrator Standard Edition (IBM Sterling File Gateway 2.2.0 through 2.2.6) is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 142967.

Pen testing: why do you need it, and five steps to doing it right

Penetration testing can contribute a lot to an organisation’s security by helping to identify potential weaknesses. But for it to be truly valuable, it needs to happen in the context of the business.

I asked Brian Honan, CEO of BH Consulting, to explain the value of pen testing and when it’s needed. “A pen test is a technical assessment of the vulnerabilities of a server, but it needs the business to tell you which server is most important. Pen testing without context, without proper scoping and without regular re-testing has little value,” he said.

Steps to do pen testing right

Some organisations feel they need to conduct a pen test because they have to comply with regulations like PCI, or to satisfy auditors, or because the board has asked for it. They’re often the worst places to start. To do it right, a business should:

  • Dedicate appropriate budget and time to the test
  • Carry out a proper scoping exercise first
  • Set proper engagement parameters
  • Run it regularly – preferably quarterly and more than just once a year
  • Use pen testing to check new systems before they go into production.

Absent those key elements, the test will not fail as such, but the approach from the start is just to tick a box. That’s why a one-off test will tell you little about how secure a system is. “A pen test is only a point-in-time assessment of a particular system, and there are ways to game the test. We have done pen tests where a client told us ‘these systems are out of scope’ – but they would be in scope for a criminal,” said Brian.

Prioritising business risks

The reason for running a pen test before systems go into production is that criminals may target them once they are live. It’s especially important if the new system will be critical to the business. “The value of doing a good pen test within context of the business, is that it will identify vulnerabilities and issues that the organisation can prioritise based on the business impact,” said Brian.

Pen testing, though valuable, is only one element of good security. “Unfortunately, many people think that if they run a pen test against their website, and it finds nothing, therefore their security is OK,” Brian said. “Just because you have car insurance doesn’t mean you won’t have an accident. There are many other factors that come into play: road conditions, other drivers on the road, confidence and experience of the driver.”

Brian warned against the risk of using pen testing as a replacement for a comprehensive security programme. If organisations have limited budget, spending it on a pen test arguably won’t make them any more secure. “Just doing it once a year to keep an auditor happy is not the best approach. It’s not a replacement for a good security programme,” he said.

The post Pen testing: why do you need it, and five steps to doing it right appeared first on BH Consulting.

CVE-2018-14446 (mp4v2)

MP4Integer32Property::Read in atom_avcC.cpp in MP4v2 2.1.0 allows remote attackers to cause a denial of service (heap-based buffer overflow and application crash) or possibly have unspecified other impact via a crafted MP4 file.

NBlog July 20 – ISO/IEC 27001 and 27031 revisions

Today I've spent (?invested?) some time and brainwaves into the ISO27k standards.

First, ISO/IEC 27002 is currently being revised. The revision involves completely restructuring the controls described in the current standard into 4 "themes": 
  1. Organizational; 
  2. People; 
  3. Physical; and 
  4. Technical. 
Clearly those are not truly orthogonal or distinct categories - for example organizational controls are quite likely to involve people (e.g. policies and procedures), physical (e.g. physical access) and/or technical (e.g. IT) aspects. Some security controls may fit into any of those categories, so the choice is arbitrary. However, the categorization doesn't matter much. It is really just a convenient order for the standard, especially as the controls are going to be further 'tagged' with other attributes such as:
  • "Information security properties" i.e. confidentiality, integrity or availability (the classic CIA triad - not Donn Parker's hexad, I note);
  • "Control type" i.e. preventive, detective or reactive (reflecting the time relative to the occurrence of events or incidents that the control acts);
  • "NIST cyber security framework classifications" i.e. identify; protect; detect; respond; recover (notice that is an extension of the "Control types" tagset);
  • "Information security management life cycle" i.e. creation; distribution; transmission; access; retrieval; storage; use; preservation; control of change; disposal (despite the title, these tags appear to relate to the lifecycle of data not of 'information security management' which would, in fact, be some sort of process maturity sequence);
  • Other tagsets, yet to be determined.
Anyway, leaving all that aside, we have our chance right now to consider and contribute to the revision of the infosec controls that are currently in 27002, perhaps culling those that are no longer worthy of inclusion and adding others that are, as well as rewording the existing set. What fun! I've spent a few hours today thinking and commenting.

I've also glanced through the 4th working draft revision of ISO/IEC 27031 on "Information technology – Cybersecurity – Information and communication technology readiness for business continuity". 

Golly, another ISO27k standard that fails to define that word "cybersecurity". It's in the title, so we are supposed to just know, I guess. Or guess, I know.

Given that ISO 22301 does such a good job on business continuity, I honestly don't see much point to this ICT-focused standard. If it is to remain a part of ISO27k, it at least ought to be properly aligned with ISO 22301, and ideally extended beyond the ICT domain since ISO27k is about information risk and security, not just ICT.

Although this standard vaguely mentions resilience to as well as recovery from disastrous situations, the coverage on resilience is distinctly light, perhaps because of the definition: 
“Resilience: ability to transform, renew, and recover, in timely response to events”.
That’s plain weird! Resilience is an ordinary common-or-garden English word, meaning that any half-decent dictionary is likely to have a perfectly serviceable definition, including the Oxford English dictionary that is supposed to be the default reference for all standard terms in ISO27k. I don't have the OED to hand but I would be gobsmacked if it didn't talk about another meaning relating to elasticity - the ability for things under stress to bend without breaking. If SC27 insists on defining the word, I suggest that resilience in the information risk and security context generally concerns the latter meaning. It’s about toughness and determination, keeping the essential core business activities (plus the supporting/enabling information processes, applications, systems, networks, data flows, services etc.) going despite and through adversity. Resilience controls include widely-applicable and sound engineering concepts such as redundancy, robustness and flexibility, ensuring that vital business operations are not materially degraded or halted by incidents - they keep right on running, albeit often at somewhat reduced performance or capacity. In this day and age, high-availability 24x7 systems and networks are hardly radical but SC27 just doesn’t seem to get it. Is it really that hard?

So, there we go, the day is history and another working week draws to a close.