Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


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

Offensive or Defensive Security? Both!

Published: 2016-06-09
Last Updated: 2016-06-10 06:22:12 UTC
by Xavier Mertens (Version: 1)
1 comment(s)

Sometimes students ask me the best way to jump into "the security world". I usually compare information security to medicine: You start with a common base (a strong knowledge in "IT") then you must choose a "specialization": auditor, architect, penetration tester, reverse engineer, incident handler, etc. Basically, those specializations can be grouped in two categories: "offensive" and "defensive". Many people like the first one because it looks more funny and the portrait of the hacker as depicted in Hollywood movies is tough! Being involved in a few call for papers for security conferences, I see a clear trend in submissions focusing on offensive security.

If breaking stuff is always nice (playing the "red team"), being able to defend them against attackers is also very rewarding (playing the "blue team"). So, back to the first student's question: Which side of the force to choose? I can't answer this question for you! It's a very personal choice based on your feelings but one thing is certain. There is clear overlapping between offensive and defensive security. Why? Here are two examples.

First from a defender perspective. To be able to properly defend your assets, you must know what techniques and tools will use the bad guys against you. This is the principle of "Know your enemy!". If you're involved in a security incident, your knowledge of the bad side will be very helpful to find how your server was compromised. If you're implementing a solution or writing some code, try to think as a bad guy and ask yourself "How would I try to break my setup".

On the other side, from an attacker perspective, you can improve your tasks by using defenders' techniques. While performing a pentest, we don't have unlimited time. A good idea is to rely on forensics investigation techniques. Indeed, operating systems like Microsoft Windows are well-known to keep trace of all the user activities in multiple places. It is possible to trace back all the actions performed by a user (which applications he started, the last files opened, network shares mounted, etc). This is a gold mine for a pentester too. Imagine that you just compromised a computer. You've your Meterpreter shell ready. And now? To save your time, just check the latest files opened by the victim, there are chances that they will be business related and contain juicy information. Which internal sites he visited? That's nice targets to pivot! 

So, offensive or defensive security? Choose the one you like but think about both!

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

1 comment(s)

Searching for malspam

Published: 2016-06-09
Last Updated: 2016-06-09 00:11:10 UTC
by Brad Duncan (Version: 1)
1 comment(s)

Introduction

About a week ago, I stopped seeing the daily deluge of malicious spam (malspam) distributing Dridex banking trojans or Locky ransomware.  Before this month, I generally noticed multiple waves of Dridex/Locky malspam almost every day.  This malspam contains attachments with zipped .js files or Microsoft Office documents designed to download and install the malware.

I haven't found much discussion about the current absence of Dridex/Locky malspam.  Since the actor(s) behind Dridex started distributing Locky in back in February 2016 [1], I can't recall any lengthy absence of this malspam.


Shown above:  Have others noticed a lull in Dridex/Locky? [2]

Of course, other campaigns are ongoing, so I figure it's time to review other examples of malspam.  These campaigns are somewhat harder to find than Dridex/Locky malspam, but they're certainly out there.

However, my field of view is limited, and I can only report on what I'm seeing.  With that in mind, this diary reviews two examples of malspam I found on Wednesday 2016-06-08.

First example

Our first example was sent to one of the ISC handlers' email aliases.  This example has a zipped .js file attachment.


Shown above:  Malspam sent to one of the ISC hander distros on 2016-06-08.


Shown above:  Contents of the zip file attachment from the malspam.


Shown above:  The extracted .js file opened in a text editor.

Running the extracted .js file on a Windows host generated plenty of HTTP traffic.


Shown above:  A pcap of the infection traffic filtered in Wireshark.

I saw plenty of artifacts on the infected host, and at least one of the items appears to be Andromeda, based on alerts seen when I played back a pcap of the traffic in Security Onion using Suricata with the ETPRO ruleset.


Shown above:  Alerts generated on the pcap from Sguil in Security Onion.

The Snort subscriber ruleset also generated alerts on the same traffic that triggered Andromeda hits with the ETPRO ruleset.


Some of the alerts after reading the pcap in Snort using the Talos Snort subscriber ruleset.

Second example

Our second example is Brazilian malspam in Portuguese sent to a different email address.  Instead of an attachment, this one has a link to download the malware.


Shown above:  Malspam sent to a recipient using a Brazilian email address.


Shown above:  Translation of the message from Portuguese to English.

The link from the malspam redirected to malware hosted on 4shared.com.


Shown above:  Traffic caused by clicking on the link from the malspam.


Shown above:  Malware downloaded from the malspam link.

Here's what the HTTP traffic looked like from the infected host:


Shown above:  HTTP traffic from the second infection filtered in Wireshark.

In addition to the HTTP traffic, I saw IRC activity on TCP port 443 from the infected host to a server on ssl.houselannister.top at 95.215.46.153. 


Shown above:  My infected host signing in to the IRC channel.


Shown above:  More IRC activity from my infected Windows host.

Of note, the hostname/username for my infected Windows host in this pcap is a throwaway.  Also, the IP address listed in the IRC channel is not the actual IP address of my infected host.

Alerts from this traffic show a Mikey variant, and this infection apparently added my Windows host to a botnet.


Shown above:  Alerts generated on the second infection from Sguil in Security Onion.

Indicators of compromise (IOC) - first example

Domain used for the initial malware download by the .js file:

  • 198.105.244.228 port 80 - www.owifdsferger.net
  • 198.105.244.228 port 80 - www.dorimelds.at
  • 198.105.244.228 port 80 - www.opaosdfdksdfd.ro
  • 31.11.33.35 port 80 - www.brusasport.com

Post infection traffic that triggered alerts for Andromeda malware:

  • 188.165.157.176 port 80 - secure.adnxs.metalsystems.it - POST /new_and/state.php 

Other HTTP traffic during this infection:

  • 62.149.128.72 port 80 - antoniocaroli.it - GET /prova/sd/Lnoort.exe
  • 62.149.132.43 port 80 - www.antoniocaroli.it - GET /prova/sd/Lnoort.exe
  • 62.149.128.154 port 80 - antoniocaroli.it - GET /prova/sd/romeo.exe
  • 62.149.132.43 port 80 - www.antoniocaroli.it - GET /prova/sd/romeo.exe
  • 62.149.140.183 port 80 - www.amicimusica.ud.it - GET /audio/js.mod
  • 37.59.66.231 port 80 - 37.59.66.231 - GET /js/calc.pack
  • 46.173.92.4 port 80 - statcollector.at - GET /statfiles/pz/ft.so
  • 217.160.6.96 port 2352 - Attempted TCP connection to dop.premiocastelloacaja.com
  • 188.190.33.93 port 80 - goyanok.at - HTTP POST triggered alert for Ursnif variant

Indicators of compromise (IOC) - second example

Traffic to retrieve the initial malware:

  • 65.181.113.254 port 80 - www.grupoc4.top - GET /m.php?id=[name] 
  • NOTE: See the pcap for the URL from 4shared.com hosting the initial malware

Post-infection traffic: 

  • 185.61.149.93 port 80 - www.ruthless.sexy - Callback from the infected host
  • 65.181.113.187 port 80 - lol.devyatinskiy.ru - Callback from the infected host 
  • 65.181.113.187 port 80 - api.devyatinskiy.ru - Callback from the infected host
  • 65.181.113.29 port 80 - 65.181.113.29 - GET /fix.dll
  • 198.105.244.228 port 443 - attempted TCP connections to imestre.cheddarmcmelt.top
  • 95.215.46.153 port 443 - IRC traffic to ssl.houselannister.top

Final words

Malspam is a pretty low-level threat, in my opinion.  Most people recognize the malspam and will never click on the attachments or links.  For those more likely to click, software restriction policies can play a role in preventing infections.  And finally, people should be using properly administered Windows hosts and follow best security practices (up-to-date applications, latest OS patches, etc).

The same thing goes for Dridex/Locky malspam, which I expect will return soon enough.

But many vulnerable hosts are still out there, and enough people using those hosts are still tricked by this malspam.  That's probably why malspam remains a profitable method to distribute malware.

Pcaps and malware for this ISC diary can be found here.

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

References:

[1] https://www.proofpoint.com/us/threat-insight/post/Dridex-Actors-Get-In-the-Ransomware-Game-With-Locky
[2] https://twitter.com/MalwareTechBlog/status/738530089600733184

Keywords:
1 comment(s)
Diary Archives