Posted on

Sextortion Bitcoin on the Move, (Fri, Jan 18th)

We’ve gotten a few reports of the latest round of sextortion emails demanding bitcoin in exchange for deleting incriminating videos. These emails and wallets have piled up for some time. Usually the criminal doesn’t move the bitcoin immediately, so checking the bitcoin wallet isn’t helpful. But a week or so after such emails are sent, it becomes possible to see what miscreants are doing with their ill-gotten gains. So for this, I took an e-mail I received on Jan 8th, “Your account is being used by another person” that listed bitcoin wallet 1GjZSJnpU4AfTS8vmre6rx7eQgeMUq8VYr as the place to send money to protect “my little secret”.

The first thing to realize about bitcoin is that you have good enough anonymity… as long as you stay in the blockchain. Bitcoin is very decentralized. What isn’t at all decentralized is the places where you can turn your fake anarchist digital money into real money. So they key in these kind of investigations is to find what they do with their cryptocurrency to get investigative leads. Sometimes those leads involve finding wallets that are discussed publicly or on forums (i.e. how I track neonazi cryptocurrency online), sometimes it could be just finding where to send the subpoena.

With the wallet above, it has earned about $12,000 for spamming planet earth with these extortion threats. The wallet itself is part of a cluster of 5 addresses, all linked to similar scams (17YKd1iJBxu616JEVo15PsXvk1mnQyEFVt, 18Pt4B7Rz7Wf491FGQHPsfDeKRqnkyrMo6, 1G1qFoadiDxa7zTvppSMJhJi63tNUL3cy7, 1PH5CYMeD4ZLTZ2ZYnGLFmQRjnptyLNqcf) which you can research at Bitcoin abuse which is making tracking this much easier.

There are lots of tentacles of where these coins end up. Some end up cashed out at LocalBitcoins.com but the intrigued transaction happened yesterday with an approximately $12,000 transaction into a Binance wallet (transaction here).

The inputs to these criminals are commodity bitcoin exchanges as well, and it might be helpful if those reputable exchanges simply prohibit any transaction with these wallets. That said, knowing where the money is coming out provides leads to investigations looking to bring these actors to justice.  I’ve been estimating these scams are making about $100,000 a week or so, but much more work needs to be done to aggregate all the abusive wallets and then attribute them to specific actors or groups.

If you see these scams, please report them to BitcoinAbuse.com to allow researchers and investigators to have that data for more correlation.


John Bambenek
bambenek at gmail /dot/ com
ThreatSTOP

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Emotet infections and follow-up malware, (Wed, Jan 16th)

Introduction

Three major campaigns using malicious spam (malspam) to distribute malware stopped sending malspam before Christmas–sometime during the week ending on Sunday 2018-12-23.  These three campaigns are Emotet (also known as Feodo), Hancitor (also known as Chanitor or Tordal), and Trickbot.  But this week, all three campaigns have been sending out malspam again.

Among these campaigns, Emotet is by far the most active.  Dozens of indicators are discovered every day as vectors for Emotet infections.  Emotet also acts a distributor for other families of malware.  So far in 2019, I’ve seen Emotet retrieve Gootkit and the IcedID banking Trojan.  As 2019 progresses, I expect to find examples of Emotet distributing other families of malware like Qakbot and Trickbot, something we saw in 2018.

Today’s diary examines recent Emotet malspam and two examples of infection traffic from Tuesday 2019-01-15.


Shown above:  Chain of events for Emotet malware distribution seen so far this year.

The malspam

As usual, emails pushing Emotet use Microsoft Word documents with malicious macros.  On vulnerable Windows hosts, opening these documents in Microsoft Word and enabling macros will attempt an Emotet infection.  So far this week, Emotet malspam had a link to download the Word document, or it’s had a Word document directly attached to the email.  See the images below for examples.


Shown above:  Screenshot 1 of 3 – Emotet malspam with link for Word doc from Tuesday 2019-01-15.


Shown above:  Screenshot 2 of 3 – Emotet malspam with link for Word doc from Tuesday 2019-01-15.


Shown above:  Screenshot 3 of 3 – Emotet malspam with attached Word doc from Monday 2019-01-14.


Shown above:  Example of Word document with macro to infect a vulnerable Windows host with Emotet.

The traffic

Network traffic is typical for what we’ve seen with recent Emotet infections from December 2018.  Emotet frequently uses HTTP traffic over non-standard TCP ports (not TCP port 80).  This may cause issues when reviewing the infection traffic in Wireshark.  Traffic on ports like TCP port 53 (associated with DNS activity like zone transfers) and TCP port 22 (normally associated with SSH) may not be decoded as HTTP in Wireshark.  That was the case with two examples of infection traffic I generated on Monday.

Post-infection activity from the first run included Gootkit, which had similar in traffic patterns that I’ve previously documented.  Post-infection activity from the second run included IcedID (also known as Bokbot), something I’ve also documented.

Indicators of Compromise (IoCs)

The following are indicators from two infections on Tuesday 2019-01-15.  Any malicious URLs, IP addresses, and domain names have been “de-fanged” to avoid issues when viewing today’s diary.

Malware from the first run:

SHA256 hash: 2b8c45af81889ce22ffaf3a78d79a307ce3ab4ebeabbd00bc5982d60a89a2c87

  • File size: 158,208 bytes
  • File location: hxxp://mdmshipping[.]org/wp-content/uploads/Clients_transactions/012019/
  • File name: 190115_invoice.doc
  • File description: Downloaded Word doc with macro for Emotet

SHA256 hash: 4cb1c0ce3de256e671b096729ae35b65b5f4ac67fe0ca9bbdc27e84aaf25a4d3

  • File size: 151,552 bytes
  • File location: hxxp://www.al-bay[.]com/JbDEG76/
  • File location: C:Users[username]AppDataLocaltablesvcstablesvcs.exe
  • File description: Emotet executable retrieved by Word macro

SHA256 hash: e1f60b891005dfd0f6738444406c8e57d644cc3ce0154f8d17454c886637dfbd

  • File size: 151,552 bytes
  • File location: C:Users[username]AppDataLocaltablesvcstablesvcs.exe
  • File description: Emotet executable updated after initial infection

SHA256 hash: 9fd057d99bad388e08f3d71c1d78e90b308e0eb656ecaec88cd70d31f723118e

  • File size: 315,392 bytes
  • File location: C:ProgramData7gYMH.exe
  • File description: Gootkit executable retrieved by my Emotet-infected host

Malware from the second run:

SHA256 hash: abd3942b115eef97d1dca7bbc05022689ee78090b02fb930d202148b9218323c

  • File size: 153,088 bytes
  • File location: hxxp://ciblage-spain[.]es/Transactions/01_19/
  • File name: 012019_INV_0049.doc
  • File description: Downloaded Word doc with macro for Emotet

SHA256 hash: a2d4ccd13954f43ab541b10f879f0d8b5fcf4fa24fffa1b08444bd2313242a78

  • File size: 155,648 bytes
  • File location: hxxp://starbilisim[.]net/umEgLOOKUD/
  • File location: C:Users[username]AppDataLocalpesicypesicy.exe
  • File description: Emotet executable retrieved by Word macro

SHA256 hash: e1f60b891005dfd0f6738444406c8e57d644cc3ce0154f8d17454c886637dfbd

  • File size: 151,552 bytes
  • File location: C:Users[username]AppDataLocalpesicypesicy.exe
  • File description: Emotet executable updated after initial infection

SHA256 hash: 4f519a9e1df4558336263f398c44796cb412e7ef56d3290f0f12b422eb325730

  • File size: 275,456 bytes
  • File location: C:ProgramData35YXoiR.exe
  • File description: IcedID executable retrieved by my Emotet-infected host

SHA256 hash: 92352a5a9e473c8939e3a609253f65d3afaa392f872134ba73c3972d2c5e4830

  • File size: 275,456 bytes
  • File location: C:ProgramData{A2EE4104-C104-4A1F-9FCE-D86635165D72}floflbjnc.exe
  • File description: IcedID executable made persistent on my Emotet-infected host

Emotet Infection traffic from the first run:

  • 92.222.210[.]16 port 80 – mdmshipping[.]org – GET /wp-content/uploads/Clients_transactions/012019/
  • 149.255.58[.]108 port 80 – www.al-bay[.]com – GET /JbDEG76
  • 149.255.58[.]108 port 80 – www.al-bay[.]com – GET /JbDEG76/
  • 189.146.157[.]111 port 20 – Attempted TCP connections (no response from the server)
  • 216.244.228[.]62 port 53 – 216.244.228[.]62:53 – GET /
  • 187.163.177[.]194 port 22 – Attempted TCP connections (no response from the server)
  • 181.164.8[.]8 port 22 – 181.164.8[.]8:22 – GET /
  • 189.129.134[.]124 port 20 – Attempted TCP connections (no response from the server)
  • 189.225.146[.]180 port 8443 – 189.225.146[.]180:8443 – GET /

Gootkit infection traffic from the first run:

  • 66.23.200[.]58 port 443 – mid.centralcoastbagels[.]com – HTTPS/SSL/TLS traffic
  • DNS query for loredanusos[.]com – response: No such name
  • DNS query for bigiterra[.]com – response: No such name
  • DNS query for getlowfast[.]com – response: No such name

Emotet infection traffic from the second run:

  • 87.98.154[.]146 port 80 – ciblage-spain[.]es – GET /Transactions/01_19
  • 87.98.154[.]146 port 80 – ciblage-spain[.]es – GET /Transactions/01_19/
  • 149.255.58[.]108 port 80 – www.al-bay[.]com – GET /JbDEG76
  • 149.255.58[.]108 port 80 – www.al-bay[.]com – GET /cgi-sys/suspendedpage.cgi
  • 159.253.42[.]200 port 80 – starbilisim[.]net – GET /umEgLOOKUD
  • 159.253.42[.]200 port 80 – starbilisim[.]net – GET /umEgLOOKUD/
  • 187.163.177[.]194 port 22 – Attempted TCP connections (no response from the server)
  • 181.164.8[.]8 port 22 – 181.164.8[.]8:22 – GET /
  • 189.129.134[.]124 port 20 – Attempted TCP connections (no response from the server)
  • 189.225.146[.]180 port 8443 – Attempted TCP connections (no response from the server)
  • 66.50.57[.]73 port 8080 – 66.50.57[.]73:8080 – GET /
  • 186.15.66[.]98 port 443 – 186.15.66[.]98:443 – GET /
  • 181.211.11[.]171 port 443 – 181.211.11[.]171:443 – GET /

IcedID infection traffic from the second run:

  • 185.223.163[.]26 port 443 – kepleted[.]pw – HTTPS/SSL/TLS traffic
  • 194.165.3[.]3 port 80 – bestcontrol[.]at – GET /data2.php?45DD8E695E0FFFAB
  • 185.223.163[.]26 port 443 – stronour[.]host – HTTPS/SSL/TLS traffic
  • 194.165.3[.]3 port 443 – bestcontrol[.]at – HTTPS/SSL/TLS traffic
  • 194.165.3[.]3 port 443 – exeterol[.]host – HTTPS/SSL/TLS traffic
  • 194.165.3[.]3 port 443 – decretery[.]host – HTTPS/SSL/TLS traffic

Final words

Pcaps of the infection traffic and malware associated with 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.

Posted on

Microsoft Publishes Patches for Skype for Business and Team Foundation Server, (Tue, Jan 15th)

Today, Microsoft published an advisory on CVE-2019-0624 on a spoofing vulnerability in Skype for Business 2015. It requires a few steps of the attacker and isn’t entirely straightforward to execute. They must be an authenticated user and then send a spoofed request that can then perform a XSS on the victim machine at the privilege level of the user using Skype for Business.

Additionally, two advisories were published for Team Foundation Server (2017 and 2018) involving an XSS attack from crafted user-input (CVE-2019-0646) and an information disclosure bug (CVE-2019-0647).

The risk and urgency of applying these isn’t an emergency, but if you accept input from untrusted third-parties in TFS or Skype for Business, that may enhance your risk. Due to the sensitivity of what most people use TFS for, you may wish to find a window when your developers are off and get that applied sooner.

No public exploitation has been reported, but the TFS vulnerabilities were publicly disclosed.


John Bambenek
bambenek at gmail /dot/ com
ThreatSTOP

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Microsoft LAPS – Blue Team / Red Team, (Mon, Jan 14th)

The story is all too familiar, the chain of events almost the same every time:

  • A malicious email makes its way in past the SPAM filter.
  • The recipient person clicks on a link or downloads an attachment with a macro in it
  • Malware executes
  • The malware uses Mimikatz (or some variation thereof) to harvest the local administrator password from the machine
  • The malware then uses that password for lateral movement to infect other workstations and servers
  • then bad things start to happen, and the phone rings!

The Blue Team “fix” for this?  Well, there are lots of them (starting with the SPAM filter, user education and blocking macros), but the one I’ll discuss today is that local administrator password, the one that’s the same on all workstations (and often on all servers as well).  Microsoft LAPS (Local Administrator Password Solution) is a nifty, free download that allows you to set the local admin password for each workstation to a random string of configurable length.  Not only that, it allows you to schedule resets of those passwords, and it’s all configurable through Group Policy:


The passwords are stored in a field in AD, which is part of the schema extension for this product.  You can then set rights on that field so that only authorized folks can use those passwords.

LAPS can be downloaded here (note that this link is subject to change over time):
https://www.microsoft.com/en-us/download/details.aspx?id=46899

Note to the Blue Team / IT Ops Team- don’t include your Domain Controllers in the scope of your LAPS workstations, or you’re in for a bad day

Neat eh?  If done right, this fixes the lateral movement problem nicely right?

… Time for the Red Team Point of View ….

LAPS works great, except that authorized folks can read those passwords in clear text (because they need to).  What this does is focus the efforts of the attackers on the IT Administration team.  If you can compromise the right helpdesk password, you’ll be able to collect all the workstation local administrator passwords with a simple PowerShell one-liner, then save that off to a spreadsheet as part of your Penetration Test findings (or L00T if the attack is malicious):

To collect one password:

Or, as they say in Pokemon Universe, if you want to collect them all – dump out all hosts in the domain, and collect the hostname, the OS and the local admin passwords:

Your data will look something like:


Note that all stations aren’t set – you normally enforce the LAPS GPO by OU in Active Directory.  Try to get the coverage you want for this tool by building your OUs and enforcing the GPO appropriately, but again, be sure not to apply this to any domain controllers.

If you’re running a penetration test, exporting it to a CSV so you can do some more analysis in Excel is a handy final step (be careful where this data goes though!)

Note to the Blue Team or Ops Team – DON’T RUN THIS LAST COMMAND – EVER.  SAVING ALL OF YOUR PASSWORDS IN A SPREADSHEET IS AN EPICALLY BAD IDEA!

The “moral of the story”?  A few actually:

  • No security measure is 100% effective, and every security measure can be exploited if it’s not done right (or even if it is done right). 
  • Approaches like this work best against malware and other automated / semi-automated attacks.  If you have an intelligent adversary, they’ll likely get administrative fairly quickly in most domains.
  • “Defence in Depth” is a thing people say for a reason, it’s the most effective way to protect your assets.  If you put all of your eggs in one basket, count on the fact that at some point, you’ll drop that basket (or someone will do that for you)
  • LAPS is a great tool, but it should be one tool of many that you use to protect your infrastructure. 
  • Implementing things like this start to focus attackers on your helpdesk and domain admins – be sure that those admin accounts are protected as much as possible – start by making sure that folks can’t browse or check email while using an admin account!!

Have I missed anything?  Please use our comment form if so!

===============
Rob VandenBrink

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Still Running Windows 7? Time to think about that upgrade project!, (Mon, Jan 14th)

For folks still running Windows 7, Microsoft has it scheduled for End of Life in exactly 1 year – https://support.microsoft.com/en-ca/help/13853/windows-lifecycle-fact-sheet

Not such a big deal if you have 1 or 2 machines at home to manage, but if you are an enterprise with hundreds or thousands of Windows 7 machines, it’s really time to start that migration project.  If you’re still running Windows XP, you’re in even deeper trouble!  If you’ve got business apps keeping you at W7 (or XP for that matter), it’s past time to consider an update or migration to better applications!

The difference I’m seeing between companies that run Windows 10 / Office 2016, and companies that run Windows 7 and older versions of office is a significant difference in rates of malware infection.  Maybe start your project by updating machines as a standard first response to malware incident response?  Or make the decision that it’s better for the business to pay for updates, as opposed to paying ransomware (and maybe not even getting what you pay for in that case)? 

Haopy updating! 

===============
Rob VandenBrink

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Snorpy a Web Base Tool to Build Snort/Suricata Rules, (Sat, Jan 12th)

Snorpy is a web base application to easily build Snort/Suricata rules in a graphical way. It is simple to use starting from the Action and Protocol fields and as you pick each field, the rule builder shows the rule in the bottom window. Before setting up your own local copy, you want to test a live version maintained by the author go here.

This is an example of an existing Snort rule entered via the interface. The rule used for my example is from Emergingthreats with sid:2002809.

alert tcp any 21 -> $HOME_NET any (msg:”ET ATTACK_RESPONSE Hostile FTP Server Banner (StnyFtpd)”; flow:established,from_server; content:”220 StnyFtpd 0wns j0″; offset:0; nocase; reference:url,doc.emergingthreats.net/bin/view/Main/2002809; classtype:trojan-activity; sid:2002809; rev:5; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

Note: You have to excape any of the special characters in the MSG fields (see example), just make sure you remove them after you copy the rule. There are a few fields that currently don’t exist but they can be added in the code since the code is available.

If you are interested in trying Snorpy, I wrote a guide to install it on CentOS 7.6 located here.
[1] http://snorpy.com/
[2] https://github.com/chrisjd20/Snorpy
[3] https://handlers.sans.org/gbruneau/snorpy_setup.htm
[4] https://rules.emergingthreats.net/open/snort-2.9.0/rules/emerging-attack_response.rules

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Quick Maldoc Analysis, (Fri, Jan 11th)

Reader Kevin asked for help with the analysis of maldoc 7eac18cab2205d94e5e5e0c43daf64cbab2e0b43cf841213c25ca34e8124739f.

Here is the analysis in one-line, as I like to do:

Similar samples have been analyzed step by step in this and this diary entry. And I also have a video.

This is a good opportunity to point to our diary archive that you can find here, Diary entries by handler can be found here.

My list is here.

 

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Posted on

Heartbreaking Emails: "Love You" Malspam, (Thu, Jan 10th)

Introduction

Malicious spam (malspam) using zipped JavaScript (.js) files as email attachments–this is a well-established tactic used by cyber criminals to distribute malware.  I’ve written diaries discussing such malspam in July 2015, September 2015, and February 2016.  I’ve run across plenty of examples since then, but I’ve focused more on Microsoft Office documents instead of .js files.  I last documented .js-based malspam in May 2018.

Despite my personal focus on malicious Word documents and Excel spreadsheets, waves of malspam using zipped .js files were still happening.  So I decided to watch for these .js files as 2019 rolled around.

It didn’t take long.  Earlier this week, I ran across zipped .js attachments from a wave of malspam.  The attachment names all started with Love_You_, and subject lines indicated these were love letters.  A quick Twitter search showed this tactic was used to distribute GandCrab ransomware as recently as November 2018.  Further research revealed this malspam is associated with the Phorpiex botnet.

Today’s diary examines a wave of “Love You” malspam from Tuesday 2019-01-08.  The infection traffic included GandCrab ransomware, a Monero (XMRig) cryptocurrency miner, and Phorpiex spambot traffic.


Shown above:  Flowchart for “Love You” malspam infection traffic.

The emails

Emails follow the same patterns as seen in Proofpoint’s May 2018 report on Phorpiex botnet malspam.  See the images below for details.


Shown above:  Spreadsheet tracker with 10 examples of Phorpiex botnet “Love You” malspam.


Shown above:  Example of the malspam and attached zip archive with .js file.


Shown above:  Script near the bottom of the extracted .js file.

Infection traffic

Infection traffic showed several HTTP requests for additional malware, resulting in multiple copies of the same malware on the infected host.  The host generated Monero (XMRig) cryptocurrency mining traffic, and it also caused the expected post-infection traffic patterns for GandCrab ransomware.  My infected lab host also turned into a spambot for the Phorpiex botnet.

Attachments in malspam from my infected lab host were approximately 1.3 kB, which is much considerably smaller than the 43 to 46 kB attachments I found through VirusTotal.  However, these smaller .js files generated the same infection traffic as the larger ones.  The larger .js files had more obfuscation for the same functions.


Shown above:  Some of the web-based infection traffic filtered in Wireshark.


Shown above:  Monero (XMRig) cryptocurrency miner traffic from the infection.


Shown above:  Phorpiex spambot traffic from my infected lab host.


Shown above:  One of the malspam messages sent out from my infected lab host.


Shown above:  Examining one of the zipped .js attachments sent from my infected lab host.

Forensics on an infected host

GandCrab ransomware was the most visible aspect of my infected lab host.  Of note, the file downloader established itself on a USB thumb drive plugged into the infected host.


Shown above:  Desktop from an infected Windows host.


Shown above:  Decryptor page for the GandCrab ransomware infection.


Shown above:  File downloader established itself on a USB drive plugged into the infected host.

Indicators of compromise (IOCs)

Date:/Time of the malspam:

  • Tuesday 2019-01-08 as early as 00:15 UTC through at least 18:24 UTC

10 examples of spoofed sending addresses from the malspam:

  • From:  Teddy Bailey
  • From:  Imogene Carter
  • From:  Imelda Jones
  • From:  Ted Hall
  • From:  Deanne Harris
  • From:  Bob Ross
  • From:  Teddy Gonzalez
  • From:  Bradford Reed
  • From:  Taylor Phillips
  • From:  Deena Hernandez

8 examples of subjects lines from 10 examples of the malspam:

  • Subject:  Always thinking about you
  • Subject:  Felt in love with you!
  • Subject:  I love you
  • Subject:  Just for you!
  • Subject:  My letter just for you
  • Subject:  My love letter for you
  • Subject:  Wrote this letter for you
  • Subject:  😀

8 file attachments (zip archives) from 10 examples of malspam:

  • Love_You_24373792-2019-txt.zip – 43,646 bytes
  • Love_You_25821416-2019-txt.zip – 45,504 bytes
  • Love_You_26943288-2019-txt.zip – 43,481 bytes
  • Love_You_35140600-2019-txt.zip – 45,289 bytes
  • Love_You_36450240-2019-txt.zip – 45,305 bytes
  • Love_You_4169768-2019-txt.zip – 43,447 bytes
  • Love_You_5742488-2019-txt.zip – 43,494 bytes
  • Love_You_8801848-2019-txt.zip – 47,121 bytes

SHA256 hashes for the above zip archives:

  • 72429571f4ca62fceb5a4fc0a17a8f8ab88c1ed01b9d657f7e9778c7939cea06
  • 27ac0e9011294c2152d224052280f7fa434df572809a6f96f9a306f3d5c965e3
  • 99a1e83e77850b59995cdf29b61e9f29f9c38882363027668030df0a62059645
  • 06e61032bccfe0ccd51ddbab480e1eb6392bccb318639ecac0092e96b9d794ad
  • 7818e108a16f096eb71feb564ce92095c4ac1e613933630169cc16606bb5f68d
  • 0a27af16b991cbe0f5445022cb1d752a9144abeede6b8de0055247e6fd6c1698
  • 32ee086fbc82ddd0675c0293656f813493ce6d96d02e0bcbeccee4d1a6adfb20
  • 12e3038b2ed0663cba3c6a05ac0a27b61dce694dffc27aafb4cb3f2f229ff6b8

JavaScript (JS) files extracted from the above zip archives:

  • Love_You_24373792-2019-txt.js – 43490 bytes
  • Love_You_25821416-2019-txt.js – 45348 bytes
  • Love_You_26943288-2019-txt.js – 43325 bytes
  • Love_You_35140600-2019-txt.js – 45133 bytes
  • Love_You_36450240-2019-txt.js – 45149 bytes
  • Love_You_4169768-2019-txt.js – 43293 bytes
  • Love_You_5742488-2019-txt.js – 43340 bytes
  • Love_You_8801848-2019-txt.js – 46967 bytes

SHA256 hashes for the above JS files:

  • 6ad3e68e2e8c5088bc8544bc230a2e333645d3c246ace772bf61f80cd0e93002
  • 99fe714a365f8e4a74687592700b27f2016a59c7527b5d4ef7cfd97e63468349
  • d189f44528dfa3f8dba2632ae26f564a37931cb89668d31402fc7fb05ae63c1a
  • c3683096f91b00dfe248e388b4302d5471fb090ab8092c96c991a467c26f26b0
  • f3c369edc2ea96465c49a14f64bdce83c0a401e0ae12e809bced8f99b977c5dc
  • f4d3ba58e91dc95877ba13804df6fe307ef6efcef74d3a00792387625a624cf4
  • 9ff78056e225c08ef1f1ff71f305201387f3ec766c8727361851287a74de1f45
  • ba23af4480611fb19fad2cd83a41bd347d183e0ef8e1c5477916bebe32955d87

Information from file attachment seen in post-infection spambot traffic:

  • SHA256 hash: cf9a20874089ec7aa1a84a27f74928c71266a684e7fee4c1ac8d37aaf57d6bf2
  • File name: Love_You_2019_38154368-txt.zip
  • File size: 1,382 bytes
  • File description: Zip archive extracted from post-infection spambot traffic
  • SHA256 hash: 0de30f9dbe37aea5932e5df85b4f1aa5cefe28f3bffb58d4d8ae40ccd040a4a7
  • File name: Love_You_2019_38154368-txt.js
  • File size: 1,226 bytes
  • File description: Extracted JS file from zip archive seen in spambot traffic

Malware retrieved from an infected Windows host:

HTTP traffic for the initial malware EXE:

  • 92.63.197[.]48 port 80 – slpsrgpsrhojifdij[.]ru – GET /krablin.exe?ceaYZof

HTTP traffic generated by the initial malware EXE and follow-up EXE/malware downloader:

  • 92.63.197[.]48 port 80 – slpsrgpsrhojifdij[.]ru – GET /1.exe
  • 92.63.197[.]48 port 80 – slpsrgpsrhojifdij[.]ru – GET /2.exe
  • 92.63.197[.]48 port 80 – slpsrgpsrhojifdij[.]ru – GET /3.exe
  • 92.63.197[.]48 port 80 – slpsrgpsrhojifdij[.]ru – GET /4.exe
  • 92.63.197[.]48 port 80 – slpsrgpsrhojifdij[.]ru – GET /5.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /m/1.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /m/2.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /m/3.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /m/4.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /m/5.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /m/2.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /1.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /2.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /3.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /4.exe
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /5.exe
  • 198.105.244[.]228 port 80 – osheoufhusheoghuesd[.]ru – GET /1.exe
  • 198.105.244[.]228 port 80 – osheoufhusheoghuesd[.]ru – GET /2.exe
  • 198.105.244[.]228 port 80 – osheoufhusheoghuesd[.]ru – GET /3.exe
  • 198.105.244[.]228 port 80 – osheoufhusheoghuesd[.]ru – GET /4.exe
  • 198.105.244[.]228 port 80 – osheoufhusheoghuesd[.]ru – GET /5.exe
  • 198.105.244[.]228 port 80 – suieiusiueiuiuushgf[.]ru – GET /1.exe
  • 198.105.244[.]228 port 80 – suieiusiueiuiuushgf[.]ru – GET /2.exe
  • 198.105.244[.]228 port 80 – suieiusiueiuiuushgf[.]ru – GET /3.exe
  • 198.105.244[.]228 port 80 – suieiusiueiuiuushgf[.]ru – GET /4.exe
  • 198.105.244[.]228 port 80 – suieiusiueiuiuushgf[.]ru – GET /5.exe

Traffic caused by the GandCrab ransomware EXE:

  • 78.46.77[.]98 port 80 – www.2mmotorsport[.]biz – GET /
  • 78.46.77[.]98 port 443 – www.2mmotorsport[.]biz – HTTPS traffic
  • 217.26.53[.]161 port 80 – www.haargenau[.]biz – GET /
  • 217.26.53[.]161 port 80 – www.haargenau[.]biz – POST /includes/pictures/fusemoru.png
  • 74.220.215[.]73 port 80 – www.bizziniinfissi[.]com – GET /
  • 74.220.215[.]73 port 80 – www.bizziniinfissi[.]com – POST /uploads/images/dethso.gif
  • 136.243.13[.]215 port 80 – www.holzbock[.]biz – POST /uploads/images/rumose.png
  • 138.201.162[.]99 port 80 – www.fliptray[.]biz – GET /
  • 138.201.162[.]99 port 443 – www.fliptray[.]biz – HTTPS traffic
  • gandcrabmfe6mnef[.]onion – Tor domain noted in decryption instructions

Traffic caused by the Monero (XMRig) cryptocurrency miner EXE:

  • 92.63.197[.]48 port 9090 – XMRig coinminer traffic

Traffic caused by the Phorpiex spambot EXE:

  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /m/attachment.js
  • port 80 – icanhazip[.]com – GET /   (IP address check, not inherently malicious)
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /m/mnum.txt
  • 92.63.197[.]48 port 80 – 92.63.197[.]48 – GET /m/1994.txt
  • UDP port 53 – DNS queries for various mail servers
  • various IP addresses over TCP port 25 – SMTP traffic caused by the spambot

Final words

A pcap of the infection traffic and malware associated with 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.

Posted on

gganimate: Animate YouR Security Analysis, (Wed, Jan 9th)

I regularly challenge myself and others to visualize the results of their analysis, when and where the data permits it. The likes of ggplot2 enables this beautifully for R users. Then, in September 2018, gganimate hit my radar via R-bloggers and I had an epiphany.

“gganimate extends the grammar of graphics as implemented by ggplot2 to include the description of animation. It does this by providing a range of new grammar classes that can be added to the plot object in order to customize how it should change with time.”

While Thomas’s gganimate examples are intriguing, and triggered my notions for deeper visualization opportunities, they were contextually unrelated to my goals. As such, I endeavored to provide example data sets and applicability for information security and assurance analysis. As purveyors of security analysis services, my team is perpetually faced with solving problems at massive scale, yet finding intelligent, accurate answers in the sea of data. While a static visualization specific to a related analysis can be truly effective, an animated visualization, particularly a time-based graphic, can bring the art to a whole new level. A couple of points and caveats:

  • This review drove me a bit crazy over the nuance between security analysis versus security analytics. In the end, I settled on the fact that this work enables analysis, based on the Merriam-Webster definitions:
    • Analysis is “a detailed examination of anything complex in order to understand its nature or to determine its essential features: a thorough study.”
    • Analytics is defined as “the method of logical analysis.” The Electronic Engineering Times elaborates further: “Merriam-Webster’s definition of analytics as a “method of logical analysis” includes the term analysis, but introduces a significant differentiator with the term “logical.” Analytic methods use data to answer questions that occurred in the past, but also provide insights or deductive reasoning to act in the future.” In my mind, static and animated visualizations of data past are more an “examination of anything complex in order to understand its nature or to determine its essential features”. Yet, one can argue that these same visualizations can, at least, help inform action in the future. It came out to be approximately a 70⁄30 split for me, in favor of analysis. Let the debate begin, but this gives you good insight regarding the discussions I have with myself. 😉
  • While the data sets provided here are artificial, they are based on absolute realities, and represent legitimate scenarios and likely outcomes. That said, they are artificial (#FakeData) so please do not use this data to influence any decisions other than to use these methods with your real data. The goal here is simply to provide you with hopefully new and innovative ways to represent your analysis.

gganimate installation is really simple. You can grab the stable version from CRAN via

install.packages('devtools')

or the development version via

devtools::install_github('thomasp85/gganimate')

Note that, while working on Windows 10, I used a gganimate fork via

devtools::install_github("dmi3kno/gganimate")

to overcome a Windows 10-specific bug. Installation from CRAN or the thomasp85 GitHub should be otherwise successful. I strongly suggest reading through as much of the gganimate reference guide, as a Grammar of Animated Graphics, there is some granular syntax to consume and understand here.

I selected three of Thomas’s examples and customized them for use in a security analysis context. Thomas is gganimate’s author and maintainer, for a very current review of the project’s history, current state, and road map, see gganimate has transitioned to a state of release. The project is now officially a v1.0 release. The project GitHub includes three examples:

  1. Temperature Time Series
  2. Gapminder
  3. Election Results

I utilized the principles and code from each of these and applied them to three unique security-oriented scenarios, namely security incident counts over time, a cloud provider Cybersecurity Framework attestation comparison, and ten years of Security Development Lifecycle utilization.

Security Incidents Time Series

I’ll start with a simple example and concept. I’m not a big fan of security incident counts by themselves as a metric or a KPI, but they do inform trend indicators. For large service providers and operations, data of this nature can inform leadership of patterns to manage as well. This visualization compares incident counts by day of the month, over five months August through December, in parallel, as seen in Figure 1.

library(ggplot2)
library(gganimate)

incidents <- read.csv("incidents.csv")
incidents$Month <- format(ISOdate(2004,1:12,1),"%B")[incidents$Month]

p <- ggplot(incidents, aes(Day, Inc_Cnt, group = Month)) + 
  geom_line(aes(colour=Month)) + 
  geom_segment(aes(xend = 31, yend = Inc_Cnt), linetype = 2, colour = 'blue') + 
  geom_point(size = 2) + 
  geom_text(aes(x = 31.1, label = Month), hjust = 0, colour = 'brown') + 
  transition_reveal(Month, Day) + 
  coord_cartesian(clip = 'off') + 
  labs(title = 'Incident Counts by Day - AUG through DEC', y = 'Incident Count') + 
  theme_minimal() + 
  theme(plot.margin = margin(5.5, 40, 5.5, 5.5)) +
  theme(legend.position='none')
p + anim_save("incidentTS.gif", animation = last_animation())

Incident Counts By Day

Figure 1: Security incidents time series

One could reach conclusions such as:

  • Incident counts are above the median in all but August at the beginning of month
  • In all but October there were noteworthy dips in security incidents on on or about the 17th of the month

Were this real data specific to the environment you’re supporting you might adjust scheduling and staffing to account for a heavier work load at the beginning of the month, while potentially pushing scheduled time off to the middle of the month.

Cloud Provider Cybersecurity Framework (CSF) Attestation Comparison

For our second scenario, imagine you’re in the market for a cloud service provider, and you’re charged with conducting the utmost due diligence. It just so happens that The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) is “designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider. The CSA CCM provides a controls framework that gives detailed understanding of security concepts and principles that are aligned to tools including the Cybersecurity Framework.” The CSF is oriented towards the function areas Identify, Protect, Detect, Respond, and Recover. With a combination of cloud service provider data, as well as your own research, you gathered data to measure provider performance in each of the function area over the period of a year. Your data is refined to a percentage of completeness towards each of the function areas for the twelve months of the year for your final two provider candidates. The code to create this visualization follows.

library(dplyr)
library(ggplot2)
library(gganimate)

cldprvdr_data %
  mutate(control = factor(control, levels = c("Identify", "Protect", "Detect", "Respond", "Recover")))

control_color <- c(
  "Identify" = "#1a9fde",
  "Protect" = "#e10b1f", 
  "Detect" = "#565656", 
  "Respond" = "#727272", 
  "Recover" = "#499533" 
)

cp_animated <- ggplot(cldprvdr_data, aes(x = control, y = result, fill = control)) +
  geom_hline(yintercept = 0.05, colour = "#D3D3D3", linetype = "dashed") +
  geom_bar(position = "dodge", stat = "identity") +
  #geom_text(aes(label = scales::percent(result), 
  #              y = result + 0.01),
  #          position = position_dodge(width = 0.9), 
  #          vjust = -0.5, size = 6, color = "black") +
  labs(title = "2018 CSF attestation per month: {closest_state}",
       subtitle = "Cyber Security Framework (CSF) results per Cloud Provider",
       caption = "CSF function areas: Identify, Protect, Detect, Respond, Recover",
       x = "", y = "") +
  theme_light(base_size = 16) +
  guides(fill = FALSE) +
  facet_grid(cldprvdr ~ .) +
  scale_y_continuous(labels = scales::percent, limits = c(0, 1)) +
  scale_fill_manual(values = control_color) +
  transition_states(month, 1,3, wrap = FALSE) +
  ease_aes('quadratic-in-out')
cp_animated + anim_save("CloudProvidersCSF.gif", animation = last_animation())

Visualizing this data with gganimate for purposes of comparison thus might appear as seen in Figure 2.

Cloud providers CSF

Figure 2: Cloud providers CSF comparison

There’s a pretty clear conclusion to be reached with this visualization. It certainly appears that Cloud Provider 2 is the more mature of the two providers, by at least 20% per function area. A visualization of this nature for vendor comparisons of many different kinds could be very useful in making better informed decision, particularly when they’re large financial investments.

Ten Years of Security Development Lifecycle Utilization

I’m personally fond of this last example as I am both a proud advocate for the practice of a Security Development Lifecycle and a believer that this level of performance measurement granularity can and should be performed. I have to imagine mature development environments with strong code management capabilities are likely able to achieve some semblance of this scenario. The premise of the data set assumes a ten year measurement where aggregate development organizations have tracked:

  • lines of code to measure code base growth and potential bloat
  • the number of bugs submitted or detected
  • the number of code regressions

Each of these are valid and important measurements and KPIs for development organizations, nor matter what product is being developed. This data set represents measurements across multiple applications, built for all major platforms (Windows, Linux, Android, iOS, Mac), over a ten year period since the organization began utilizing SDL. First, the code.

library(ggplot2)
library(gganimate)
library(tibble)

data <- read.csv("SDL.csv")
sdl_data <- as_data_frame(data)

options(scipen=10000)
dev.off(which = dev.prev())

ggplot(sdl_data, aes(bugs, regressions, size = code, colour = apps)) +
  geom_point(alpha = 0.7) +
  scale_colour_manual(values = rainbow(n=142)) +
  scale_size(range = c(2, 12)) +
  scale_x_log10() +
  facet_wrap(~OS) +
  theme(legend.position = 'none') +
  labs(title = 'Year: {frame_time}', x = 'Bugs', y = 'Regressions', 
       subtitle = "Ten Years of SDL") +
  transition_time(year)

The resulting visualization warrants a bit of explanation. This size of each node (application) in the five major platform panes panes represents is indicative of the size of the application’s code base. The x axis represents the number of bugs filed, and the y axis represents the number of regressions introduced, as seen in Figure 3.

Ten Years of SDL

Figure 3: Ten Years of SDL

A few observations:

  • The largest apps are found in the Windows groupings, you can watch their code size grow in small margins as the years progress, and while the bugs reported increase as expected with code growth, the regressions decline gradually
  • Linux apps tended to perform best over time, relatively stable with minor code growth, almost no increase in bugs over time, and some noteworthy declines in regressions are observed
  • Only a very few apps, in the Windows and Linux collections, performed really well over time, with minimal bugs and regressions, yet a steady decrease in both, even with observable code growth
  • Most of the Android apps remain high in bugs and regressions until half way through the decade, then decrease in regression, but the largest app shows now improvement at all, it even worsens.

While again, this is artificial, manipulated data, I tried to cook it in such a manner as to produce likely outcomes that would be well observed with animated visualizations over time.
I do hope this has stimulated your thinking on these types of scenarios, and ideally, the additional plethora opportunities to bring animation to your security data.

Each of these scripts and data sets are available for you on my GitHub, as is a Jupyter Notebook.
https://github.com/holisticinfosec/gganimate-Animate-YouR-Security-Analysis

I’d love to see what you come up with, please share them with me via social media, @holisticinfosec or email, russ at holisticinfosec dot io.

Cheers…until next time.

Russ McRee | @holisticinfosec 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.