Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Internet Storm Center - SANS Internet Storm Center Internet Storm Center


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

Hunting for Suspicious Processes with OSSEC

Published: 2018-09-20
Last Updated: 2018-09-24 19:09:07 UTC
by Xavier Mertens (Version: 1)
1 comment(s)

Here is a quick example of how OSSEC[1] can be helpful to perform threat hunting. OSSEC  is a free security monitoring tool/log management platform which has many features related to detecting malicious activity on a live system like the rootkit detection or syscheck modules. Here is an example of rules that can be deployed to track malicious processes running on a host (it can be seen as an extension of the existing rootkit detection features). What do I mean by malicious processes? Think about crypto miners. They are plenty of suspicious processes that can be extracted from malicious scripts (see my previous diary[2] about this topic). 

OSSEC has a nice feature which allows monitoring the output of a system command. A basic rule coming in any freshly deployed OSSEC agent is the disk space monitoring. OSSEC performed a ‘df’ command at regular interval and searched for ’100%’ in the output:

<rule id="531" level="7" ignore="7200">
    <if_sid>530</if_sid>
    <match>ossec: output: 'df -h': /dev/</match>
    <regex>100%</regex>
    <description>Partition usage reached 100% (disk space monitor).</description>
    <group>low_diskspace,</group>
</rule>

The idea is to search for malicious running processes on a system using the same technique. In the case of trojaned systems, commands like /bin/ps could be replaced to hide some processes. A better approach is to use the /proc virtual filesystem to list the running processes. Here is the command that I use:

# find /proc -name comm -exec cat "{}" \; 2>/dev/null |sort -u

It searches for /proc/<pid>/comm files that expose the process's command name associated with the process. Example of generated output:

accounts-daemon
acpi_thermal_pm
apache2
arpwatch
ata_sff
atd
bash
charger_manager
cpuhp/0
cpuhp/1
cron
crypto
dbus-daemon
devfreq_wq
ecryptfs-kthrea
edac-poller
ext4-rsv-conver
find
gdbus
gmain
ib-comp-wq
…

Let’s define this command in OSSEC by adding an entry in $OSSEC_HOME/etc/ossec.conf:

<localfile>
    <log_format>full_command</log_format>
    <command>find /proc -name comm -exec cat "{}" \; 2>/dev/null |sort -u</command>
    <frequency>180</frequency>
</localfile>

The ‘full_command’ type helps to return the output as a single line to be easily parsed later. Now, the create a rule in $OSSEC_HOME/rules/local_rules.xml:

<rule id="100405" level="7" ignore="7200">
    <if_sid>530</if_sid>
    <match>ossec: output: 'find /proc</match>
    <regex>Duck.sh|accounts-daemon|bonn.sh|kworker34|minerd|minergate|minexmr|mixnerdx|myatd|polkitd|rootv2.sh|jaav|jva|kw.sh|kxjd|mule|mutex</regex>
    <description>Searching for suspicious processes</description>
    <group>hunting,</group>
 </rule>

The regex has been created from a list of processes found in a crypto miner installation script. Deploy the updated config files, restart the OSSEC processes. Now, let's create a fake suspicious process on a monitored host and wait for a few minutes. You should get the following alert:

OSSEC HIDS Notification.
2018 Sep 20 08:18:20

Received From: (shiva) 192.168.254.8->find /proc -name comm -exec cat "{}" \; 2>/dev/null |sort -u
Rule: 100405 fired (level 7) -> "Searching for suspicious processes"
Portion of the log(s):

ossec: output: 'find /proc -name comm -exec cat "{}" \; 2>/dev/null |sort -u':
(sd-pam)
accounts-daemon
acpi_thermal_pm
apache2
arpwatch
ata_sff
atd
bash
charger_manager
cpuhp/0
cpuhp/1
cron
crypto
dbus-daemon
devfreq_wq
ecryptfs-kthrea
edac-poller
ext4-rsv-conver
find

--END OF NOTIFICATION

It's time to investigate!

Note that this simple alert may generate a lot of false positives! Another approach could be to check the process name combined with its working directory because many crypto miners use common process names (ex: 'apache'). But 'apache' running from /tmp is definitively suspicious! Happy hunting!

If you want to learn more about how to use OSSEC for threat hunting, I'll do a training at DeepSec (Vienna, Austria) in November about this topic[3].

[1] https://www.ossec.net
[2] https://isc.sans.edu/forums/diary/Crypto+Mining+Is+More+Popular+Than+Ever/24050/
[3] https://deepsec.net/speaker.html#WSLOT378

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

1 comment(s)

Suspicious DNS Requests ... Issued by a Firewall

Published: 2018-09-22
Last Updated: 2018-09-23 08:33:55 UTC
by Didier Stevens (Version: 1)
0 comment(s)

An anonymous reader contacted us because he noticed DNS requests for malicious domains originating from his Windows machine, even before he opened a browser.

Looking at the provided capture file, I noticed indeed DNS requests for malicious domains, but also for security related domains, like ClamAV. But these DNS requests were not followed by TCP connections.

With more information provided by the reader, I could confirm one of my theories: on his Windows machine, the reader was using a firewall (Privatefirewall) that accepts rules with domain names to allow/block. There were rules designed to block access to the malicious domain names this reader was noticing.

Here I configure it to block www.example.com (on 32-bit Windows, the firewall hanged on my 64-bit Windows VM):

 

To establish TCP connections, a destination IP address is needed: hostnames like www.example.com have to be translated to an IP address before a TCP connection can be established.

Likewise, for a firewall to block TCP connections with rules with hostnames, the firewall has to lookup these hostnames via DNS requests.

This is what this firewall does, soon after user logon.

It's not an indication of malicious activity, but normal behavior of a security tool that has to translate hostnames to IP addresses to be able to do its job.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

Keywords: dns firewall malware
0 comment(s)

The danger of sending information for API consumption without adequate security measures

Published: 2018-09-22
Last Updated: 2018-09-22 23:02:23 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
0 comment(s)

Migrating an on-premise application to the cloud can bring numerous business advantages to companies, among which we have fast deployment times and reusability of functions and decrease complexity in operation and evolution through the use of microservices that are communicated through of the use of API.

During the work of the course for the conformation of incident response teams that I direct at Instituto Tecnológico Metropolitano in Medellín, Colombia, we noticed the following case of a production API: there is an API that is consumed to perform the authentication of a fingerprint that was read through an APP located in a mobile phone. The fingerprint is digitalized using the Wavelet Scalar Quantization (WSQ) Gray-scale Fingerprint Image Compression Algorithm, which is the standard for the exchange of 8-bit, 500ppi fingerprint images, used as well in the criminal justice community. If you have and enforced connection with controls like HTTP Strict Transport Security (HSTS), Perfect Forward Secrecy (PFS) and mutual TLS cert authentication, you will have a strong protection against man-in-the-middle attacks. If not, your connection might be tampered. The following snippet was captured when performing an MITM (snippet truncated for security purposes):

Base64 is not a good choice to hide information. When you decode this information, you get a binary file which is in WSQ format. We will use the NIST Biometric Image Software Mirror located at https://github.com/lessandro/nbis to decode it and then we have a complete fingerprint that can be used to impersonate the owner's identity (truncated for security purposes):

How can you enforce the confidentiality and integrity of the communication and message?

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name

Keywords:
0 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

Hunting for Suspicious Processes with OSSEC
Sep 24th 2018
55 minutes ago by Xme (1 comment)

Pre-Pwned AMI Images in Amazon's AWS public instance store
Sep 21st 2018
3 days ago by Johannes (0 comments)

Certificates Revisited - SSL VPN Certificates 2 Ways
Sep 19th 2018
5 days ago by Rob VandenBrink (2 comments)

Using Certificate Transparency as an Attack / Defense Tool
Sep 18th 2018
6 days ago by Rob VandenBrink (2 comments)

Dissecting Malicious MS Office Docs
Sep 17th 2018
1 week ago by Rob VandenBrink (0 comments)

View All Diaries →

Latest Discussions

Attempting to report (msg body missing) -- Powershell malware in zip with jpg
created Sep 10th 2018
2 weeks ago by W60 (0 replies)

SSL Labs vs. SecurityHeaders.io
created Sep 7th 2018
2 weeks ago by Anonymous (0 replies)

SSL Labs vs. SecurityHeaders.io
created Sep 7th 2018
2 weeks ago by Anonymous (0 replies)

Has anyone any ideas what "glirote3" -- malware powershell link.
created Sep 4th 2018
2 weeks ago by W60 (0 replies)

Remote code execution attacks
created Aug 28th 2018
3 weeks ago by Anonymous (0 replies)

View All Forums →

Latest News

View All News →

Top Diaries

Wide-scale Petya variant ransomware attack noted
Jun 27th 2017
1 year ago by Brad (6 comments)

Using a Raspberry Pi honeypot to contribute data to DShield/ISC
Aug 3rd 2017
1 year ago by Johannes (16 comments)

Detection Lab: Visibility & Introspection for Defenders
Dec 15th 2017
9 months ago by Russ McRee (2 comments)

Maldoc with auto-updated link
Aug 17th 2017
1 year ago by Xme (2 comments)

Second Google Chrome Extension Banker Malware in Two Weeks
Aug 29th 2017
1 year ago by Renato (0 comments)