(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
[slackware-security] libXres (SSA:2017-291-01)
 
[slackware-security] wpa_supplicant (SSA:2017-291-02)
 
[slackware-security] xorg-server (SSA:2017-291-03)
 
FreeBSD Security Advisory FreeBSD-SA-17:07.wpa [REVISED]
 
NTP CVE-2016-7431 Denial of Service Vulnerability
 

Introduction

ISO files are a format used for optical disk images like CD-ROMs or DVDs.  Criminals sometimes use ISO files as attachments in malicious spam (malspam) to distribute malware.  Here and here are two recent examples.  On Wednesday 2017-10-18, I came across HSBC-themed malspam using this technique to distribute Loki Bot, an information stealer.

The malspam was easily detected by an enterprise-level security solution, so I'm not sure this technique is more effective than other methods.  However, even if it's ineffective, we should be aware of current mass-distribution methods.  With that in mind, today's diary examines Wednesday's Loki Bot malspam.


Shown above:  Flow chart for today's infection.

The emails

I found eight emails in this wave of malspam.  They all had the same subject line, spoofed sending address, message text, and email attachment.  These emails all came from 185.61.138.132, a Netherlands-based IP address registered to a hosting provider named BlazingFast.io.  The domain email.hsbc.ae is legitimate and hosted on a different IP registered to HSBC, so it's being spoofed in the email headers.


Shown above:  Some emails from this wave of malspam on Wednesday 2017-10-18.


Shown above:  Screen shot from one of the emails.

The attachment

The attachment was an ISO file, which I copied to a Windows 10 host in my lab.  Double-clicking the ISO file revealed a Windows executable file.  Victims who receive this file from email would likely see a warning if they try to open it.  The Windows executable was Loki Bot malware.  Double-clicking the executable infected my Windows 10 host.


Shown above:  The ISO file on a Windows 10 desktop.


Shown above:  Windows executable file extracted from the ISO.

Network traffic

Post-infection traffic consisted of a single HTTP POST request continually repeated from the infected host.  The User-Agent string and other characteristics are somewhat unusual and easily identifiable.


Shown above:  Traffic from an infection filtered in Wireshark.


Shown above:  One of the HTTP POST requests from an infected host.


Shown above:  Alerts seen using the Snort subscriber ruleset on Snort 2.9.11.


Shown above:  Alerts seen using the Emerging Threats (ET) pro ruleset on Security Onion running Suricata.

Post-infection forensics

The infected host had artifacts commonly associated with Loki Bot, such as a Windows registry key using non-ASCII characters.  The malware moved itself to a hidden folder under the user's AppData\Roaming directory to become persistent.


Shown above:  Windows registry update and the associated malware.

Indictators

Email information:

  • Date/Time:  Wednesday, 2017-10-18 as early as 05:50 UTC through at least 13:30 UTC
  • Received (domain spoofed):  from email.hsbc.ae ([185.61.138.132])
  • From (spoofed):  [email protected]
  • Subject:  HSBC Payment Advice
  • Attachment name:  HSBC Payment Document.iso

Associated malware:

SHA256 hash:  1bff70977da707d4e1346cc11bccd13f3fc535aeeb27c789c2811548c6b7793a

  • File size:  512,000 bytes
  • File name:  HSBC Payment Document.iso
  • File description:  Email attachment - ISO file

SHA256 hash:  9022ed5070226c516c38f612db221d9f73324bb61cd4c4dc5269662c34e7a910

  • File size:  450,560 bytes
  • File name:  HSBC Payment Document.exe
  • File description:  Loki Bot executable extracted from ISO file
  • Post-infection location:  C:\Users\[username]\AppData\Roaming\B06669\996ACC.exe

Post-infection traffic:

  • 173.237.190.72 port 80 - filteracino.info - POST /ask/five/fre.php

Final words

As mentioned earlier, I don't find this malspam any more effective than other wide-scale email-based attacks.  Potential victims still must click through a warning to get infected.  And as always, it's relatively easy to follow best security practices on your Windows computer.  Software Restriction Policies (SRP) or AppLocker can easily prevent these types of malspam-based infections from occurring.

Still, we should keep an eye on our spam filters.  These blocked emails contain a variety of information on active criminal groups using mass-distribution techniques.

Pcap and malware for today's diary can be found here.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
Oracle Database Server CVE-2016-3506 Remote Security Vulnerability
 
Perl 'perl.c' CVE-2016-2381 Security Bypass Vulnerability
 

Introduction

This week I came across an interesting incident response scenario that was more likely a blind hunt. The starting point was the suspicion that a breach may have occurred in one or more of ~500 web servers of a big company on a given date range, even though there was no evidence of leaked data or any other IOC to guide the investigation. To overcome time and environment restrictions, we ended up with a simple quick start approach that allowed us to collect some “low-hanging fruits” by writing a tool, now available at GitHub [1], to automate the process, detailed in today’s diary.

Scenario

When it comes to hunting activities like this one, approaches may vary, but they usually pass through log and traffic analysis and running anti-malware and root kit detection tools to identify compromised systems. Our case is a little different; let me give you an overview of our requirements and restrictions:

  • The servers were hosted on a cloud provider with no network or security solution that could easily give visibility over the servers’ network traffic. With some effort, one could barely have a view of the network flows with limitations to export them to a log manager or a SIEM. There was a SIEM, but it was collecting just the application layer logs;
  • A Host Intrusion Detection System (HIDS) could be very useful as violations on the hosts could be easily identifiable, but there was none;
  • As we were dealing with a production environment, deploying new packages on the servers would require approvals,  that would take long to obtain. So, quick results from tools like lynis, chkrootkit and rkhunter were out of question;
  • Finally, as any other incident response, answers had to be given ASAP.

Another interesting characteristic of the environment was that, despite the number of servers, they could be classified into a limited number of groups based on their tasks. That is, there was a group of servers responsible for the APIs, other responsible for the frontend of the application A, other of B, and so on in a manner that each server group shared a quite similar operating system and applications as they were dynamically instantiated from the same baseline image.

Looking for anomalies

While we were waiting for the authorization and deployment of the host analysis tools mentioned above and part of the team was analyzing and correlating logs into SIEM, we started brainstorming strategies that could allow us to analyze the hosts for indications of compromise. The similarities between servers was the key.

So, if we could compare servers in terms of system characteristics among groups, those that do not follow “the pattern” should be considered suspect. In other words, if someone has deployed a web shell on a pivot server, for example, this server would be distinguishable within the group and, thus, would appear on the comparison.

Following this approach, three system characteristics were selected to look for anomalies: list of files, list of listening services and list of processes. To automate the task, a python tool was written, as detailed on the next section.

Distinct.py

After testing the approach by issuing isolated remote “find” and “grep” commands, and validating that uncommon characteristics would pop up, it was time to put all the pieces together.

First, Distinct, as we named the tool, receives a list of servers as input and performs the following information gathering tasks through remote SSH command execution:

  • With “find”, it lists file paths to be compared. It supports a time range filter based on creation and modification file time;
  • With “ps”, it lists all running applications and its parameters;
  • With “netstat”, it lists all listening network ports on the server;
  • As “find”, “ps” and “netstat” commands may have been modified by an attacker, there is another option to compare the tools hashes among servers – following the same approach;
  • Additionally, the user may give a whitelist  parameter with a list of words that should be excluded from comparison. It is useful to avoid file names naturally different among servers (i.e.: access.log.2017100301.gz into the /var/log path).

Then, it basically compares the results by sorting the lists and counting the items (file paths, listening services and running applications) repetitions. The items with a repetition count smaller them the number of compared servers, indicates that a given item is anomalous and, thus, must be investigated. For example, a file like /var/www/a.php present in one of, let’s say, 100 servers will have a count of 1 and, therefore, will appear on the output. The same will occur for uncommon listening services and processes.

Usage

See below distinct.py first version’s supported parameters:

$ python distinct.py -h

    usage: distinct [-h] -f F [-k K] -u U [-o O] [--files] [--path PATH]

                 [--startDate STARTDATE] [--endDate ENDDATE] [--listening]

                 [--proc] [--criticalbin] [--whitelist WHITELIST] [--sudo]

Where:

            -f <F>: F is path of the file with the list of servers to be analyzed;

            -k <K>: K is the path of the private key for the SSH public key authentication;

            -u <U>: U is the username to be used on the SSH connection;

            -o <O>: Optional output path. The default is “output”;

            --files: switch to enable file list comparison. It supports these option additional arguments:

                        --path: specify the find path (i.e: /var/www);

                        -- startDate and --endDate:  accepts the time range filter based on the file time modification time;

            --listening: switch to enable listening services comparison;

            --proc: switch to enable proc list comparison;

            --criticalbin: switch to enable critical binaries (find, ps and netstat) MD5 hash comparison;

            --whitelist: a file with a wordlist (one per line) to be excluded from the comparisons.

            --sudo: Use 'sudo' while executing commands on remote servers

Example:

Looking for uncommon files on a given path, created or modified on a given period, on a group of servers:

Figure 1: Looking for uncommon files among servers

Final words

The approach to use a group of similar servers as a baseline to detect outliers may be very useful (and was in our case) as a primary source of suspicious indicators to be considered while responding to an incident, especially when there isn’t a file integrity monitor or other HIDS features in place. However, it is important mentioning that having no indication of anomalous files or processes detected, does not mean that there is no breached server. An attacker may delete its track and/or use kernel level rootkits to hide processes from tools like “ps” and “netstat”– even the legitimate ones. There is another case where there are no outliers: all servers have been compromised the same way.

Aside those tricky scenarios, I hope the tool may be useful for other people within similar hunting scenarios or even for system administrators willing to find configuration errors on a bunch of servers.

Finally, the tool may be extended to support other comparisons, like system users and, who knows, a version to support analyzing Windows Servers.

References

[1] https://github.com/morphuslabs/distinct

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
WebKitGTK+ Security Advisory WSA-2017-0008
 
SEC Consult SA-20171018-1 :: Multiple vulnerabilities in Linksys E-series products
 
[security bulletin] HPESBHF03789 rev.2 - Certain HPE Gen9 Systems with HP Trusted Platform Module v2.0 Option, Unauthorized Access to Data
 
Internet Storm Center Infocon Status