Have you ever had to work with a large packet capture, and after getting past the initial stage of being overwhelmed by a few million packets, find that are still a bit overwhelmed?

I quite often work with large PCAPs - either for long-running issues, or intermittent issues, or because the capture filter that was defined might not have been all that it should be  :-)
After 4 or 5 passes through Wireshark or TCPDump (maybe with grep thrown in), where you have to wait 2 or 3 or 10 minutes each time for results, you start to say - "gee, this might be a bit easier if I could just use SQL instead of BPF or grep to query this data".  Well, it turns out that you can do that, if that's your preference.

PCAP2XML will dump standard PCAP files to XML or SQLite format.

Let's start with a sample PCAP file, I did a simple 1 minute capture of my "home / family" wireless network (not my home / work network), and got a 96 packet capture file.  Using a few examples in PCAP2XML's website, let's see what we find.

First, export the file.  Note that the offset is required (it should be zero for most cases), or the export will error out.  In this example I'm exporting to sql (use -x for xml)

C:\tmp> Pcap2XML.exe sample1.pcap -s sample.sql --offset 0
.______     ______     ___      .______    ___   ___   ___ .___  ___.  __
|   _  \   /      |   /   \     |   _  \  |__ \  \  \ /  / |   \/   | |  |
|  |_)  | |  ,----'  /  ^  \    |  |_)  |    ) |  \  V  /  |  \  /  | |  |
|   ___/  |  |      /  /_\  \   |   ___/    / /    >   <   |  |\/|  | |  |
|  |      |  `----./  _____  \  |  |       / /_   /  .  \  |  |  |  | |  `----.
| _|       \______/__/     \__\ | _|      |____| /__/ \__\ |__|  |__| |_______|

                          ver 1.0 by Pentester Academy
                   Info: http://PentesterAcademy.com/pcap2xml
          A tool to convert 802.11 trace files to XML and SQLite DB format
                    Ver. 1.0 only supports WLAN MAC Header

[+] Opening file: sample1.pcap (9.0 kB)
[+] Processing packet 96... (100.00 %)
[+] Parsing completed
[+] Dumping into XML and/or SQLite
[+] Processing done!
[+] Run statistics:

Filename:                       sample1.pcap
Number of packets:              96
Number of packets parsed:       96
Data packets parsed:            45
Control packets parsed:         41
Management packets parsed:      10
SQLite out file:                sample.sql
Total time taken:               0.039 sec
[-] No update available. This is the latest version

Now, let's open the file in sqlite browser

OH - as my cat would say - this is as good as catnip!!

Let's list the unique sending and receiving mac addresses on the network

Adding counts for each, sorted in descending order by packet count - OK, maybe this is BETTER than catnip !

Average packet length?  No problem!

OK, for a 96 packet PCAP, thsi might not be your first go-to tool for analysis.  But if the file was 96,000 or 960,000 packets?  Maybe now using a database approach makes a bit more sense now, at least to start narrowing things down?  

You can download PCAP2XML and read more about it here:

https://github.com/securitytube/pcap2xml

http://hackoftheday.securitytube.net/2015/03/pcap2xmlsqlite-convert-80211-packets-to.html

===============
Rob VandenBrink
Metafore

I had a guest diary entry about my XORSearch tool using shellcode detection rules from Frank Boldewin's OfficeMalScanner. To detect malicious documents, Frank coded rules to detect shellcode and other indicators of executable code inside documents.

I also translated Frank's detection rules to YARA rules. You can find them here, the file is maldoc.yara.

This is an example:

rule maldoc_API_hashing
{
    meta:
        author = "Didier Stevens (https://DidierStevens.com)"
    strings:
        $a1 = {AC 84 C0 74 07 C1 CF 0D 01 C7 EB F4 81 FF}
        $a2 = {AC 84 C0 74 07 C1 CF 07 01 C7 EB F4 81 FF}
    condition:
        any of them
}

A couple of days ago I received another malicious document (078409755.doc B28EF236D901A96CFEFF9A70562C9155). Unlike the XML file I wrote about before, this one does not contain VBA macros:

But as you can see, it should contain an embedded object. The base64 code found inside the XML object decodes to an OLE file. The single stream present in this OLE file contains ZLIB compressed data (identifiable via byte 0x78). Decompressing this ZLIB stream reveals another OLE file. Which in turn contains an embedded OLE object that turns out to be a VBS script:

And the base64 string in this VBS script is a PowerShell command:

If you are interested to see how you can analyze this sample with oledump, you can take a look at this video I produced.

JS Malware uptick

We've been seeing an uptick in JS malware (TrojanDownloader:JS/Nemucod.K) loosely disguised as .doc files. The JavaScript is reasonably obfuscated but if executed does result in a trojan'd system. Payloads have been delivered as resumes, invoices, or shipping notices. You'll note payloads given nomenclature such as payload.doc.js.
Feel free to let us know if you've noticed similar, and send along samples via the diary submittal form for comparison (best submitted a password protected zip).

VirusTotal sample data:
1081e3e1ef855b011eaadfeea5f9e9c1
3a155fd510f16efc4104022e228de88d

Security Weekly

I was interviewed for Episode 411 of Paul Asadoorian's Security Weekly. While I had to often speak in sadly generic and vague terms, a few key takeaways popped out in the conversation.
We all largely agreed that the best tooling and datasets mean nothing when protecting organzations without applied context.
Consider the fact that one of the best ways for a security team to properly design and implement tooling and monitoring is to leverage the network architect to better understand design and layout. This allows goals to be established. Rather than a mission that is based on implementing a tool, the mission should be goal based. What are you trying to protect, not what are trying to install. The premise of operational threat modeling really factors here too. The practice can help prioritize area of importance (avoid boiling the ocean) and allow better goals determination.
Great talking with Paul and team, I appreciate the opportunity.

On a related note, check out Episode 409 with Keren Elazari, go watch her TED talk, then get a copy of this month's Scientific American which includes her article, How To Survive Cyberwar.

Book offering

Wiley is offering a free download (for a limited time) of The Database Hacker's Handbook: Defending Database Servers http://bit.ly/HackersHandbook

GitHub DDoS

GitHub has been under a brutal DDoS attack for 24 hours +.
https://github.com/blog/1981-large-scale-ddos-attack-on-github-com
Keep an eye on https://twitter.com/githubstatus for updates.

Doh!

Overheard by a pentester after a recent pentest:
Passwords.doc is a bad idea :-)

Have a great weekend!

Russ McRee | @holisticinfosec

Yeah, okay, I admit that headline is cheap click bait. Originally, it said "Certificate Pinning on Smartphones". If you are more interested in pin-ups on your smartphone, I fear you'll have to look elsewhere :).

Recently, an email provider that I use changed their Internet-facing services completely. I hadn't seen any announcement that this would happen, and the provider likely thought that since the change was "transparent" to the customer, no announcement was needed. But I'm probably a tad more paranoid than their normal customers, and am watching what my home WiFi/DSL is talking to on the Internet. On that day, some device in my home started speaking IMAPS with an IP address block that I had never seen before. Before I even checked which device it was, I pulled a quick traffic capture, to look at the SSL certificate exchange, where I did recognize the domain name, but not the Certificate Authority. Turns out, as part of the change, the provider had also changed their SSL certificates, and even including the certificate issuer (CA).

And my mobile phone, which happened to be the device doing the talking?  It hadn't even blinked! And had happily synchronized my mail, and sent my IMAP login information across this session, all day long. 

Since I travel often, and am potentially using my phone in less-than-honest locations and nations, it is quite evident that this setup is pretty exposed to a man in the middle attack (MitM). Ironically, the problem would be almost trivial to solve in software, all that is needed is to store the fingerprint of the server certificate locally on the phone, and to stop and warn the user whenever that fingerprint changes. This approach is called "Certificate Pinning" or "Key continuity", and OWASP has a great write-up that explains how it works.

Problem is .. this is only marginally supported in most implementations, and what little support there is, is often limited to HTTPS (web).  In other words, all those billions of smart phones which happily latch onto whatever "known" WiFi or mobile signal is to be had nearby, will just as happily connect to what they think is their mail server, and provide the credentials. And whoever ends up with these credentials, will have access for a while .. or when was the last time YOU changed your IMAP password?

If you wonder how this differs from any other "man in the middle" (MitM) attack ... well, with a MitM in the web browser, the user is actively involved in the connection, and at least stands *some* chance to detect what is going on. With the mobile phone polling for email though, this happens both automatically and very frequently, so even with the phone in the pocket, and a MitM that is only active for five minutes, a breach can occur. And with the pretty much monthly news that some "trusted" certificate authority mistakenly issued a certificate for someone else's service, well, my mobile phone's childishly naïve readiness to talk to strangers definitely isn't good news.

While certificate pinning would not completely eliminate this risk, it certainly would remove the most likely attack scenarios. Some smart phones have add-on "apps" that promise to help with pinning, but in my opinion, the option to "pin" the certificate on email send/receive is a feature that should come as standard part of the native email clients on all Smartphones. Which we probably should be calling Dumbphones or Naïvephones, until they actually do provide this functionality.

If your smartphone has native certificate pinning support on imap/pop/smtp with any provider (not just Chrome/GMail), or you managed to configure it in a way that it does, please share in the comments below.

The Nmap security scanner project is participating again in its 11th Google Summer of Code.  We often get queries from students on how they can get into this field, and this is an excellent way to get experience while using your powers for good.

Details are available here: http://nmap.org/soc/

F-Secure has announced a security vulnerability affecting their corporate and consumer protection products.  The details are available here: https://www.f-secure.com/en/web/labs_global/fsc-2015-2

From the fine folks at php.net:

The PHP development team announces the immediate availability of PHP 5.5.23. Several bugs have been fixed as well as CVE-2015-0231, CVE-2015-2305 and CVE-2015-2331. All PHP 5.5 users are encouraged to upgrade to this version.

Keeping an eye on your logs is critical (really, it's number 14 on the SANS critical list of controls: https://www.sans.org/critical-security-controls/control/14 .)  Earlier Rob VandenBrink shared some techniques to find nuggets hiding in your logs (https://isc.sans.edu/forums/diary/Syslog+Skeet+Shooting+Targetting+Real+Problems+in+Event+Logs/19449/ .)  Today I'm going to share some tricks to squeeze every last bit out of your logs through repurposing logs.  I mean repurposing log files, not this: https://www.pinterest.com/dawnreneedavis/repurposed-logs/ .

Logs are given their original purpose when programs determine when and how they're going to record a log entry.  Today I want to discuss "unintended value," or how to get more out of your logs than the programmers intended, or how to recover value that is easily overlooked.  

Let's start with an example.  Suppose you work in a large siloed environment and you don't have access to the logs from every group.  You're in a security or investigative function, and have access to the AV logs.  The obvious use of the logs is to record the alerts generated by the endpoints, or find machines that aren't updating signatures properly or are have detection engines that are out of date.  A bit that you might be overlooking is the value of the checkin message itself.  I've found it very useful to keep the checkins for a long period of time, which gives you a history of what IP and what user was logged into a machine when it regularly checks in.  It doesn't have the resolution and accuracy that you would get from you AD authentication logs, or your DHCP logs, but you might not have easy access to those.  This small investment in disk space, or simple database can give you quick snapshot views of machine and user mobility.  You can easily see if this desktop consistently has this IP, or if this laptop moves around through your campus.  You can get the same feel out of your user accounts too, without having to invasively dig through badge access logs.

This is the first technique that I want to share: extract a daily event out of your logs and store it over time.  This creates an additional product that keeping a rolling history of logs can't provide.  

Now consider what hidden and unexpected information might be hiding in your web proxy logs.  Take a look at the W3C standard fields.  If you reduce the displayed fields down to just timestamp, c-ip, r-host, and r-ip, you've got yourself a quick passive-DNS feed.  Granted it's just looking at web traffic, but a good chunk of your network mischief is traveling through that channel at least once.

Trick number two: look for unexpectedly-useful combinations of columns in your log entries.

On to number three: data reduction and indexing.  Logs are big, and logs are noisy.  While I recommend that you keep the raw logs for as long as you can, I understand that isn't possible and that you have to make tough choices on what you store and for how long.  One way to squeeze out more time from your logs is to reduce the number of columns that you keep for your archives.  Using the web proxy logs as an example, you might not be able to keep every log entry for 24 months, but keeping just the c-ip,r-host,r-ip columns can be very helpful when you're looking back through an old undiscovered compromise or are dealing with an information request like "has any system on your network interacted with one of these IPs?"

Years ago I would recommend further daily reduction and indexing of these files, but these days you probably have a splunk instance or an ELK stack (https://digital-forensics.sans.org/summit-archives/dfirprague14/Finding_the_Needle_in_the_Haystack_with_FLK_Christophe_Vandeplas.pdf) and you just dump logs in there and hope that magic happens.  There's value in examining and repurposing logs in these days of map reduce.  The reduced files that you create from the logs are easy to drop into your hadoop cluster and build a hive table out of.

So, let's tie this all together.  You've received your list of IPs from your intelligence vendor and you're tasked with finding any activity on your network over the past 2 years.  In your web proxy index you see that you had a hit 8 months ago.  Now you've got an IP and and date, what machine had that IP then?  Now you search through your AV checkin data and get machine name.  But the AV checkin logs are daily, not logged by minute, so you search around for the IP history of that machine in the AV logs and hopefully you see it consistently checking in from that IP and not moving around a lot.  If you're not so lucky, well, it's time to open up request tickets to hopefully get at the DHCP logs from back then.

One last parting thought: do you have waste/useless logs?  If you apply one or more of these techniques to it, can you find a way to process them into something useful?

-KL

We get a ridiculous amount of Spam at the Internet Storm Center.  Most of it is mundane and is promptly ignored, but every once in a while one comes in that gets your attention for being different.

Today we received the following Spam email:

At first glance it looks like yet another run of Home Depot Spam. It isn't very sophisticated and isn't likely to fool many.  The usual spelling mistakes and broken English. They didn't even bother to link in Home Depot's logo. By the time I received it both of the URLs in the message were dead, so I wasn't able to measure what its intent was.

What makes it interesting then? If you look very carefully in the orange bar there is text.  That text and the contents of the message contain what seems to be a rather good recipe for lettuce salad:

***************

* tablespoons olive oil
* 1 12tablespoons fresh lemon juice
* 1tablespoon red wine vinegar
* 2garlic cloves, minced
* 1teaspoon dried oregano(Mediterranean is best)
*
** Salad
------------------------------------------------------------
* 1head lettuce, torn into bite-size pieces ((I use Romaine)
* 3large plum tomatoes, seeded and coarsely chopped
* 1English cucumber, peeled and coarsely chopped (the long, thin, almost seedless ones)
* 1medium red onion, cut into thin rings and soaked for 10 minutes in a small bowl of ice water to make it less sharp
* 1small green pepper, cut into thin rings
* 34cup kalamata olive
* 34cup crumbled feta cheese

We think that you will enjoy this. 

1. Seed the bell peppers and cut them into 1-inch chunks. Stem the cherry tomatoes and halve one-half of them, leaving the others whole.
2. Peel and thickly slice the cucumbers, and thinly slice the red onions. Cut the feta cheese into 1-inch cubes. Crush and mince the garlic clove.
3. In a large bowl, combine the bell peppers, tomatoes, cucumbers, onions, feta cheese, olives, anchovies and capers and toss together.
4. In a small bowl, whisk together the vinegar, garlic, dill, oregano, salt and pepper. While whisking, slowly drizzle in the olive oil to make a thick dressing.
5. Pour the dressing over the salad, toss and serve now.

This is the most delicious salad - fresh and wonderful-tasting. FYI, lettuce can very much be a part of any greek salad - if you want it to. We like lettuce in my family and I often add it. It would not be 'authentic' in a Horiatiki (village) salad, but who cares?

*****************

Why?

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

With the OpenSSL updates this week I am sure you are all diligently testing and deploying to all your vulnerable servers.  Something you may not have though of is that most SOHO routers run some kind of *nix variant and will most likely make use of OpenSSL. Be sure to watch for new firmware for those devices as well.  

On Friday I live chatted with two of the larger manufacturers and neither had any timeline for deploying new firmware containing the OpenSSL patches and both said to watch for new releases of firmware.

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

When investigating a website used as part of an IT support scam, I came across a web page that attempted to fool the visitor into thinking that the person’s system was infected. The goal was to persuade the potential victim to call a "Microsoft Certified Live Technician" at the designated phone number " for assistance on how to remove malicious pop-ups."

The scareware page resided at 247tech.help (don't go there). It looked like this:

The source code of this scammy page, which you can see on Pastebin, included the following HTML comment:

Mirrored from clients.worldnetconsultants.com/Lander3/ by HTTrack Website Copier/3.x [XR&CO'2014], Thu, 08 Jan 2015 03:52:17 GMT

Such comments are automatically added using the non-malicious website-mirroring tool HTTrack Website Copier. This comment offered a pointer to the origin of the page's code.

The Lander3 page was available on the clients.worldnetconsultants.com server as of this writing. It showed a web page that was almost identical to the one captured above, except it lacked a pop-up and specified a different "tech support" phone number: (855) 662-9616. Also, it contained pointers to YourTechSupport.org and  YourTechSupport.com (don't go there), who may have been the client that paid to develop this code. You can see Lander3 source code on Pastebin.

The clients.worldnetconsultants.com server contained a publicly-accessible listing of other projects, which included other variations on landing pages for YourTechSupport.org, inviting people to get a "free secure diagnostic session" (lander1 screenshot), "detect, diagnose and troubleshoot all spyware problems" (lander2 screenshot), perform a "security check" (lander4 screenshot), etc.

The server also contained code for other websites, which seemed to be associated with legitimate, less shady companies.

By performing some Google searches, I came across pop3.yourtechsupport.org (don't go there), which was live at the time of this writing. Its look-and-feel matched the lander1 screenshot.

Google also pointed me to yourtechsupport.org/L3 (don't go there). Its look-and-feel matched that of 247tech.help, which I mentioned in the beginning of this article. It included a pop-up, thought its text was different from what 247tech.help used, which stated:

"YOUR COMPUTER MAY NOT BE PROTECTED FROM ADWARE / SPYWARE
Call 844-325-8014 immediately for assistance on how to remove potential spyware. The call is toll-free."

I captured a screenshot of that page for those who wish to see it in its full glory.

The site www.worldnetconsultants.com describes Worldnet Consultants Inc. The company positions itself as "a leading web design company in USA for offshore web design, offshore web development," etc. The site lists office addresses in Forest Hills, NY and Gurgaon, India. This company appears to have developed the code used by yourtechsupport.org and 247tech.help. I saw no indications that the software development firm is malicious—however, they don't seem to be particularly selective about their clientele.

If this topic interests you, you might also like these articles of mine:

• The Manipulative Nature and Mechanics of Visitor Survey Scams
• How Victims Are Redirected to IT Support Scareware Sites
• Conversation With a Tech Support Scammer

-- Lenny Zeltser

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog.

In the classic version of tech support scams, the fake technician initiated an unsolicited phone call to the victim. Now the awareness for this scheme has increased, scammers shifted tactics. Their latest approaches involve convincing the potential victim to be the one calling the impostor. I've seen this accomplished in two ways:

• Scammers use bots to respond to Twitter users who mention PC problems or malware. The bots search for the appropriate keyboards and send messages that include a phone number of a tech support firm. I described this approach when exploring how scammers prescreen potential victims.
• Scammers set up scareware websites that are designed to fool people into thinking their PC is infected, compelling visitors to call the fake tech support organization. Johannes Ullrich described a typo squatting variation of this technique in an earlier diary. Let’s take a look a domain redirection variation of this scam below.

In the following example, the victim visited a link that was once associated with a legitimate website: 25yearsofprogramming.com. The owner of the domain appears to have allowed its registration to expire in early 2014. At that point, the domain was transferred to Name Management Group, according to DomainTools Whois records. The record was assigned DNS servers under the domains cashparking.com, hastydns.com, dsredirection.com and eventually brainydns.com.

Name Management Group seems to own over 13,000 domains (according to DomainTools Whois records), including numerous domains that DomainTools classifies as malicious, such as 0357al.com, 18aol.com, 520host.com, 60dayworkout.us, 61kt.com, 7x24sex.net, 9tmedia.com, adobecrobat.info, adultfantasynetwork.com, allappsforpc.com, apkcracks.net, etc. (Don't visit these domains.)

Landing on the Fake Malware Warning Site

Visiting the once-legitimate URL a few days ago landed the victim on a scammy scareware page, designed to persuade the person to contact "Microsoft Certified Live Technicians" at the specified toll-free phone number. The site employed social engineering techniques employed by rogue antivirus tools. Such schemes present victims with fake virus warnings, designed to scare people into submission.

The site in our example also played an auditory message, exclaiming:

"This is a Windows system warning! This is a Windows system warning! If you are hearing this warning message, the security of your Windows system has been compromised. Your Windows computer and data might be at risk because of adwares, spywares and malicious pop-ups! Your bank details, credit card information, email accounts, Facebook account, private photos and other sensitive files may be compromised. Please call the number mentioned now to resolve this issue."

To see and hear what the victim experienced, play the video clip below or watch it on YouTube.

Here are the redirection steps that brought the victim to the scareware site mentioned above:

http ://25yearsofprogramming.com/blog/2010/20100315.htm ->
https ://p2.dntrax.com/tr?id=f2d252736d65832f11811ad8cb43ceff00313e75.r ->
http ://247tech.help/crt/us_seg0303/m1/us_windos_3806/index.html

You can see the source code to the final page on Pasebin, if you're interested. According to the code, it was mirrored from clients.worldnetconsultants.com/Lander3 using the free non-malicious tool HTTrack Website Copier on 08 Jan 2015. (More on this interesting tidbit in my diary 
Who Develops Code for IT Support Scareware Websites?)

If you visited the top page of the 247tech.help website (don't go there), you would see a friendly, professional-looking page, gently inviting the visitor to "Call Now for Instant Support" by dialing 844-878-2550. Please don't call that number; however, if you'd like to hear a details account of what people experience when they do call, read my article Conversation With a Tech Support Scammer.

The nature of this page is in stark contrast to the scareware warnings-filled trap shown above, which redirection victims encountered.

Other Redirection Possibilities

The website hosting 25yearsofprogramming.com at the time of this writing redirects visitors to various places, perhaps randomly, perhaps based on the person’s geography or browser details. I encountered two other redirection flows that led to scareware websites set up for IT support scams.

One redirection flow employed p2.dntrax.com, as the example above, but took the victim to alert.windows.com.computers-supports.com (don't go there):

http ://25yearsofprogramming.com/blog/2010/20100315.htm -> https://p2.dntrax.com/tr?id=f2d252736d65832f11811ad8cb43ceff00313e75.r ->
http ://alert.windows.com.computers-supports.com/index-1.html?isp=Time%20Warner%20Cable&browser=Internet%20Explorer&browserversion=Internet%20Explorer%2011&ip= 108.61.226.4&os=Windows&osversion=Windows%208.1

The resulting site is a bit more sophisticated than the one in the previous example, because it uses JavaScript to customize the web page to include the victim's ISP, browser name, IP address and Windows version. For instance:

document.write(getURLParameter('ip'))

You can see the source code of that page on Pastebin. Here's the screenshot of what the victim saw; in this example, the website didn't receive the victim's IP and other details and therefore didn't display this info:

Sometimes the victim was redirected using a longer trail to a different IT support scareware site (don't go there):

http ://25yearsofprogramming.com/blog/2010/20100315.htm ->
http ://xml.revenuehits.com/click?i=cEuxzuX2fpc_0 ->
http ://zh.zeroredirect1.com/zcvisitor/fddce3a1-ccbb-11e4-ab5a-0a92e2e12617 ->
http ://claimyourfree.com/promo/base.php?c=734&key=0cdc58908ab3a694320034e391aa520a&target=oscar-vox-zKU0jhQu ->
http ://fb.surveydonkeys.com/us/index.php?target=oscar-vox-zKU0jhQu ->
http ://ajax.surveydonkeys.com/imp/g38a0n?data=eyJicm93c2VyX3R6X29mZnNldCI6LTI0MCwiY2IiOjEwNTExNSwibHBfcmVmIjoiIiwibHBfdXJsIjoiaHR0cDovL2ZiLnN1cnZleWRvbmtleXMuY29tL3VzL2luZGV4LnBocD90YXJnZXQ9b3NjYXItdm94LXpLVTBqaFF1In0= ->
http ://securedgo.com/d3ed9240-61de-48c1-9a7b-b10dbafaa7d2 ->
http ://fb.surveydonkeys.com/us/windowswarning.php?os=Windows&osversion=Windows%208.1&isp=Time%20Warner%20Cable&browser=Internet%20Explorer&voluumdata=vid..00000003-ee55-4287-8000-000000000000__vpid..48799800-ccb6-11e4-8c70-feaa7355a29a__caid..d3ed9240-61de-48c1-9a7b-b10dbafaa7d2__lid..5e47c857-460b-4d05-b92e-e24c030f0933__rt..R__oid1..b74614e1-7a0b-40bb-8bd5-66fbfc48a121

The redirection chain and the source code (you can see it on Pastebin) of the resulting site, as well as its look-and-feel were different from the examples above:

The design of this page matches closely the site Johannes Ullrich described in the typo squatting variation of this scenario on December 15. The latest page employed the sound file gp-msg.mp3 to scare visitors. VirusTotal has a record of this file, which was first uploaded to VirusTotal on December 11, 2014.

Who is Redirecting, Why and How?

We seem to be dealing with two different redirection engines and companies: p2.dntrax.com and xml.revenuehits.com after the initial 25yearsofprogramming.com redirect.

The domain dnstrax.com was registered by Team Internet AG, which is associated with over 44,000 domains, including several that DomainTools classifies as malicious: anonse24.de, natursteindichtstoff.de, seospecialists.de, etc. The domain revenuehits.com is registered to MYADWISE LTD, which is associated with about 50 domains.

The companies behind these servers, as well as the firm presently controlling 25yearsofprogramming.com are probably receiving referral fees for their roles in the redirection scheme.

There's much to explore regarding the domain names, systems and companies involved in the schemes outlined above. If you have additional information about these entities, or would like to contribute towards this analysis, please leave a comment. If you decide to explore any of these systems, do so from an isolated laboratory environment.

Also, if you encounter a tech support scam, please register it with our database of such incidents.

-- Lenny Zeltser

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog.

As pre-announced, OpenSSL today released an update fixing 14 security flaws [1]. The good news: The only "high" vulnerability is present in the recently release version 1.0.2, which as far as I know is not yet used in any major operating system. But numerous of the "medium" vulnerabilities do have code execution potential (e.g. "memory corruption" issues), so do not delay patching too much. To answer your boss's first question: "No. This is not as bad as heartbleed".

This update affects all versions of SSL back to 0.9.8. See the table below for exact version numbers

(the list of operating systems / linux distributions attempts to capture major versions and is not complete)

Summary of vulnerabilities

For many of the announcements, the impact is not clearly stated. Also note that some vulnerabilities only apply to stand alone scripts (e.g. during signing / encrypting files or verifying certificates loaded from files) and not to network clients or servers. 

[1] https://www.openssl.org/news/secadv_20150319.txt

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

No, this isn't about sharing a hallucinogen-laced bong for a smoke. The "hash" we're referring to here is the one that Wikipedia aptly but unhelpfully defines as "a derivation of data, notably used in cryptographic hash functions".

Passing the hash is a form of login credential theft that is quite prevalent. In it, an attacker captures the encoded session password (the "hash") from one computer, and then re-uses it to illicitly access another computer. On (most configurations of) the Microsoft Windows operating system, this "hash" can be used as an equivalent stand-in for the original password, hence if an attacker obtains the "hash" of a privileged account, this has the exact same immediate consequences as when the attacker had gotten his hands on the password of same account.

Pass-the-Hash (PtH) exploitation has been involved in many of the recent high profile breaches, and the issue is big enough of a problem that Microsoft have set up a dedicated top level web page  http://www.microsoft.com/pth to get the word out. They also provide two quite decent documents, "Mitigating Pass-the-Hash and Other Credential Theft v1" and "v2" on that page, with 60+ pages each, which is certainly an indication that this is not a trivial problem to understand and mitigate.

One pre-requisite for PtH to work is that the attacker must obtain local administrator privileges on at least one computer in your organization. So, if you are still generously letting your users work and surf the web as "admin", here's one more reason to stop that. Another particularity of PtH is that whenever a higher privileged administrator logs on to a lower privileged device, he/she creates a privilege escalation opportunity for whoever controls that lower device. If you have some type of admin privileges in your windows AD domain, think about when you "RDP" into other devices to "check something out" or "fix something". Doing so places your "hash" onto that device, and the hash can be harvested by someone with admin rights on that device, and re-used to impersonate you for as long as you do not change your associated password.

Sounds bad? Yup. Potentially, it is. Because what seems to be happening quite frequently is that attackers breach one single user workstation (through malware in drive-by web or email based attacks). Then, the attackers try to get admin privileges on that workstation. If the user already has local admin privs, they won, if not, they need to find some local exploit (missing patch, weak password, etc).  Once they ARE local admin, they extract all "hashes" that they can find locally on that workstation. With a bit of luck, some IT Helpdesk person who has admin privileges across ALL workstations in the firm had recently connected to that particular PC, and "left the hash" behind. Thus, the attacker ends up with admin privs across all workstations. Next step, find the workstation of a server or domain administrator, and hope to locate an even more privileged hash on there. If found: game over.  All of this can be and has been automated, and can happen in a matter of minutes.

The not so good news is: Even though Microsoft have posted two 60+ page documents on the issue, there is no real rock solid mitigation. There are just mitigations that make the problem less likely to occur. But that's at least a start -- there is no better option, short of maybe giving up security entirely, and smoking that other hash ;). So, if you never heard of PtH attacks before, or you didn't bother to look at the recommended mitigation measures, I suggest you spend some time and do so. Start with the document marked "v1".

[Edited to add: And if you thought that Kerberos or Smartcard Auth helps much, think again, and read "v1" anyway!]

SANS Posters rule! The malware geeks Jake Williams and Alissa Torres have created a new REM poster that focuses on malware memory forensics, and covers the Volatility and Rekall frameworks, as well as important artefacts. Depending on your location, you can get a printed copy mailed to you .. or you can download and print on your own: http://www.sans.org/security-resources/posters/dfir-memory-forensics-2015-65
 

Some time ago, Jim Clausing had a diary entry about PeID (a packer identifier which is no longer maintained/hosted) and since then he has a PEiD signature database on his handler page.

Now, wouldn't it be great if we could reuse these signatures? For example as YARA rules?

That's why I wrote a Python program that converts PEiD signatures to YARA rules: peid-userdb-to-yara-rules.py

Here is an example:
PEiD signature:

 [!EP (ExE Pack) V1.0 -> Elite Coding Group]
 signature = 60 68 ?? ?? ?? ?? B8 ?? ?? ?? ?? FF 10
 ep_only = true

Generated YARA rule:

 rule PEiD_00001__EP__ExE_Pack__V1_0____Elite_Coding_Group_
 {
     meta:
         description = "[!EP (ExE Pack) V1.0 -> Elite Coding Group]"
         ep_only = "true"
     strings:
         $a = {60 68 ?? ?? ?? ?? B8 ?? ?? ?? ?? FF 10}
     condition:
         $a
 }

PEiD signatures have an ep_only property that can be true or false. This property specifies if the signature has to be found at the PE file’s entry point (true) or can be found anywhere (false).

Program option -p generates rules that use YARA’s pe module. If a signature has ep_only property equal to true, then the YARA rule’s condition becomes $a at pe.entry_point instead of just $a.

Example:

 import "pe"

 rule PEiD_00001__EP__ExE_Pack__V1_0____Elite_Coding_Group_
 {
     meta:
         description = "[!EP (ExE Pack) V1.0 -> Elite Coding Group]"
         ep_only = "true"
     strings:
         $a = {60 68 ?? ?? ?? ?? B8 ?? ?? ?? ?? FF 10}
     condition:
         $a at pe.entry_point
 }

I produced 2 sets of YARA rules based on Jim's database: peid-userdb-rules-with-pe-module.yara and peid-userdb-rules-without-pe-module.yara. As the names imply, the first one uses YARA's PE module, and the second one not. I use the second set of rules when I analyze files that are not PE files, but that can contain (partial) PE files.

You can find my YARA rules here.

This is a guest diary submitted by Xavier Mertens.

Writing documentation is a pain for most of us but... mandatory! Pentesters and auditors don't like to write their reports once the funny stuff has been completed. It is the same for the developers. Writing code and developing new products is fun but good documentation is often missing. By documentation, I mean "network" documentation. Why?

When you buy from a key player some software or hardware which will be connected to a corporate environment, the documentation usually contains a clear description of the network requirements. They could be:

    • A list of ports to allow in firewalls or any kind of filter to access the device/application
    • A list of ports used by the device/application to access online resources and basic services (NTP, DNS, Internet, Proxy, ...)
    • A list of online resources used (to fetch updates, to send bug reports, to connect to cloud services, ...)

But today, more and more devices are connected (think about the IoT-buzz - "Internet of Things"). These devices are manufactured in a way that they automatically use any available network connectivity. Configure a wireless network and they are good to go. Classic home networks are based on xDSL or cable modems which provide basic network services (DHCP, DNS). This is not the best way to protect your data. They lack of egress filters and any connected device will have a full network connectivity and potentially exfiltrate juicy data. That's why I militate in favor of a documentation template to describe the resources required to operate such "smart" devices smoothly. Here is an good example. I've a Nest thermostat installed at home and it constantly connects to the following destinations:

54.227.140.192.9543
23.21.241.75.443
23.23.91.51.80
54.243.35.110:443
87.106.208.187:80

It's easy to make your home network safer without spending a lot of time and money. When a new device is connected to my network, it receives a temporary IP address from a small DHCP pool (Ex: 192.168.0.200-210). This pool has a very limited network connectivity. It uses a local DNS resolver (to track used domains) and is only allowed to communicate over HTTPS to the Internet. A Snort IDS and a tcpdump are constantly running to capture and inspect all packets generated by the IP addresses from the DHCP pool. This is easy to configure with the following shell script running in the background.

#!/bin/bash
while true
do
   TODAY=`/bin/date +"%Y%m%d"`
   /usr/sbin/tcpdump -i eth1 -lenx -X -s 0 -w /data/pcaps/tcpdump-$TODAY.pcap \
       host 192.168.0.200 or \
            192.168.0.201 or \
            192.168.0.202 or \
            192.168.0.203 or \
            192.168.0.204 or \
            192.168.0.206 or \
            192.168.0.207 or \
            192.168.0.208 or \
            192.168.0.209 or \
            192.168.0.210 &
   TCPDUMP_PID=$!
   sleep 86400 # Go to sleep for one day
   kill $TCPDUMP_PID
   gzip -9 /data/pcaps/tcpdump-$TODAY.pcap
done

When a new device is connected, its traffic is automatically captured and can be analyzed later. Once completed, a static DHCP lease is configured with the device MAC address and the firewall policy adapted to permit the required traffic. Not only, it helps to secure your network but it can reveal interesting behavior.
 

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

As could be expected, we witness an arms race when observing the evolution of VBA malicious documents. First the VBA code was trivially simple (download and execute), then obfuscation was added (strings and code), and now we see more attempts to evade detection.

I analyzed a maldoc sample (.xls 77f3949c2130b268bb18061bcb483d16) that tries to detect sandboxes and virtualization (and aborts if found).

Here's part of the code:

If IsSandBoxiePresent(1) = True Then End

If IsAnubisPresent(1) = True Then End

If IsVirtualPCPresent = True Then End

Malware researchers at Trend Micro have analyzed a malware that connects to the home routers and scan the home network then send the gathered information to C&C before deleting it self .

TROJ_VICEPASS.A pretends to be an Adobe Flash update, once its run it will attempt to connect to the home router admin council using a predefined list of user names and passwords. If it’s succeed, the malware will scan the network for connected devices.

The malware scans for devices using HTTP, with a target IP range of 192.168.[0-6].0-192.168.[0-6].11, this IP range is hard-coded

Once the scans is finish it will encode the result using Base64 and encrypt it using a self-made encryption method. The encrypted result will be sent to a C&C server via HTTP protocol.

After sending the results to the Command and Control server (C&C) , it will delete itself from the victim’s computer. It uses the following command to do so:

• exe /C ping 1.1.1.1 -n 1 -w 3000 > Nul & Del “%s”

Such type of malware infection can be avoided using a very basic security techniques such as downloading updated and software from a trusted sources only and changing the default password of your equipment’s.  

Microsoft has announced a new release of the Enhanced Mitigation Experience Toolkit (EMET) 5.2.

The main the main changes and improvements as the following:

• Control Flow Guard: EMET’s native DLLs have been compiled with Control Flow Guard (CFG). CFG is a new feature introduced in Visual Studio 2015 (and supported by Windows 8.1 and Windows 10) that helps detect and stop attempts of code hijacking. EMET native DLLs (i.e. EMET.DLL) are injected into the application process EMET protects. Since we strongly encourage 3^rd party developers to recompile their application to take advantage of this very latest security technology, we have compiled EMET with CFG.

• VBScript in Attack Surface Reduction: the configuration for the Attack Surface Reduction (ASR) mitigation has been improved to stop attempts to run the VBScript extension when loaded in the Internet Explorer's Internet Zone. This would mitigate the exploitation technique known as “VBScript God Mode” observed in recent attacks

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

1- http://blogs.technet.com/b/srd/archive/2015/03/12/emet-5-2-is-available.aspx

2- https://technet.microsoft.com/en-us/security/jj653751

WordPress has released an advisory for the WordPress plugin SEO by Yoast. Version up to and including 1.7.3.3 can be exploited with a blind SQL injection. According to WordPress, this plugin has more than one million downloads. A description of the SQL injection with proof of concept is described here and the latest update is available here.

[1] https://wordpress.org/plugins/wordpress-seo/
[2] https://downloads.wordpress.org/plugin/wordpress-seo.1.7.4.zip
[3] https://wpvulndb.com/vulnerabilities/7841

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Ever wonder if any of your users connect to sites with bad SSL certificates? I ran into this issue recently when debugging some SSL issues, and ended up with this quick tshark and shell script trick to extract the necessary information from a packet capture.

First, you may want to compare the host name your clients connect to, to the host name returned as part of the certificate. While the "Host" header is encrypted and not accessible, modern SSL libraries use Server Name Indication (SNI) as part of the SSL Client Hello to indicate to the server which site they are trying to connect to. The SNI option is sent in the clear to allow for name virtual hosting with SSL.

To extract the SNI fields, I use:

tshark -r file.pcap -Y 'ssl.handshake.type==1' -T fields -e ip.dst -e tcp.srcport -e ssl.handshake.extensions_server_name  | sed "s/\t/:/" > /tmp/ssi

The tshark command extracts all the SSL Client Hello messages (ssl.handshake.type==1) and then pulls out the destination IP, the destination port as well as the SNI field. I remove the first tab and replace it with a ":" to receive output like:

173.194.219.108:61879   imap.gmail.com

Your sed command will look a bit different if you are using OS X.

Next, we need to extract the host names advertised by the certificate that the server returns. This is a bit tricky as a certificate may either use a distinguished name (DN) or a subject alternative name if more then one hostname is included in the certificate.

tshark -r file.pcap -Y 'ssl.handshake.type==11' -T fields -e ip.src -e tcp.dstport -e x509sat.uTF8String -e x509ce.dNSName | sed  "s/\t/:/" > /tmp/in

Just like before, we now filter for certificate messages (type 11) and extract the source ip and the destination port, so we can match up connections with what we extracted above. The output should look like:

173.194.219.109:61898    California,Mountain View,Google Inc,imap.gmail.com    imap.gmail.com
173.252.101.48:61897    *.facebook.com    *.facebook.com,facebook.com,*.fbsbx.com,*.fbcdn.net,*.xx.fbcdn.net,*.xy.fbcdn.net,fb.com,*.fb.com,*.facebookcorewwwi.onion,facebookcorewwwi.onion,fbcdn23dssr3jqnq.onion,fbsbx2q4mvcl63pw.onion,*.m.facebook.com,*.messenger.com,messenger.com

Note how it is quite common to include a large list of hostnames.

Next, we need to link the two files. The "join" command is pretty useful here:

join -1 1 -2 1 -e 'empty' /tmp/in /tmp/out | tr " " "\t"

This will join the two files, pretty much how a SQL join would combine two tables, using the first column in each file as index. The output looks now like:

17.172.208.83:61878    *.icloud.com,icloud.com    p02-mailws.icloud.com
17.172.208.8:61881    *.icloud.com,management:idms.group.506364,Apple    Inc.,California    *.icloud.com    p02-ckdatabase.icloud.com
173.252.101.48:61897    *.facebook.com    *.facebook.com,facebook.com,*.fbsbx.com,*.fbcdn.net,*.xx.fbcdn.net,*.xy.fbcdn.net,fb.com,*.fb.com,*.facebookcorewwwi.onion,facebookcorewwwi.onion,fbcdn23dssr3jqnq.onion,fbsbx2q4mvcl63pw.onion,*.m.facebook.com,*.messenger.com,messenger.com    webdav.facebook.com

Making it reasonably easy to compare the requested host name (last field) with the names provided by the certificate.

(homework: a second script to analyze this output automatically, or a bro script to do all of this ;-) )

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

A common bit of advice that we tend to offer up frequently is "monitor your logs" or "review your logs periodically".  However, with daily syslogs - even in a small environment - ranging from 300mb to 5GB, that's no easy task.  We've discussed parsing logs out using grep and similar tools in the past, but that assumes that nothing drastic ever happens - you're banking on the fact that anything being logged can wait until you have time to check your logs.

And face it - with the volume of "real" project work that faces us each day, how many of us actually have time to manually review our logs, and get meaningful information out of them that we can take action on?

So, can we automate this task?  Since there's a rather large number of for-sale products that do this (google SIEM to see just how many), the answer is a resounding "yes".  But can you take a simpler approach, and send email alerts on specific things you know you want to watch for?  And can you do this on a budget of zero or close to it?  The answer to this is also "yes", read on!

Before we get to the "how" though, let's define the "what" - or at least start that task.  What exactly do you want to monitor for?  I'll focus on network gear in these examples - routers, switches, firewalls and so on.  The list of conditions for alerting is fairly short, and network conditions affect *everything*.  Plus I'm a "network person" most days.  You can certainly expand this to include storage arrays, Windows and Linux hosts, Active Directory and so on.

Let's start with some keywords in log entries that would indicate environmental issues:

You'll also get these same keywords cropping up in logs for your SAN and for host hardware if you have proper logging set up for them.

You definitely want to alert on routing or redundancy Protocols - for the most part these only kick out a message when things are re-negotiating, which should never happen unless there is a problem:

BGP, EIGRP, OSPF. ISIS  (or add your routing protocol here.  Hopefully "RIP" isn't in your list).  Monitoring for these will in lots of cases catch short outages with WAN providers or ISP's, which traditional polling will often miss.
HSRP, VRRP  covers off most interface redundancy issues.  If you see an event on either of these, it usually means you've seen a failure.
 

Another common, common, common thing that you really have to filter on:
duplex
'nuff said.  I just had a client engage me for 5 days to nail down a high WAN traffic / performance issue.  They didn't have a syslog server, but I started by looking at logs in memory (over their objection).  And yes, their WAN provider had changed one of their routers from auto/auto to 100/full, of course without telling them.  Even in a well managed, controlled environment, you can't control the VOIP contractor who hard-sets their PBX to 100/full without telling anyone else, the ISP that does that to their routers instead of using rate limiting, or the server admin who thinks that setting their NIC to 1000/full is somehow "safer" than letting it negotiate to that same setting (the way the RFC recommends).  And face it, the only things you get ever speed/duplex errors on are the most catastrophic things you could pick to have that error!   Once you start looking, you are almost guaranteed to find a number of these in your logs in almost any shop.

Monitoring for  vendor-specific text in a syslog message (Both Cisco in this case, though the first works for COMWARE as well):
DUPLICATE_IPADDR_DETECT         - yes, lots of this too.  I had a client stand up a new DHCP server without conflict detection.  Ever wonder what happens when you have a busy workstation with the same IP as the local firewall?

ERR-DISABLE or ERR_DISABLE    - as you'd expect, this is a switch port that's been disabled due to an error.  What kind of error?  Often it's a BPDUGUARD trigger, port channel config issues, link-flap, late collisions incorrect SFP or GBIC inserted, ARP inspection issues - this port state and syslog message cuts a wide swath.

BPDUGUARD - if you configure a switch port with BPDUGUARD, you're telling it that this is a workstation or server port, so if it sees a BPDU (Bridge Protocol Datagram Unit) frame, that indicates that there's an unauthorized switch attached to that port. (see ERRDISABLE above).  A messing involving BPDUGUARD will generally also involve a shut down port.  In Cisco and Comware, it'll be in an ERRDISABLE state.  In Procurve networks though, it'll just be shut down, and if you don't check your logs you might be left wondering why it keeps shutting down.

You'll likely also want to monitor for config changes.  If you don't have a formal change control process, it's something you really want to consider.  If a router or switch configuration changes outside of a change window - or worse yet, if a config changes and it wasn't you, that's something you want to know about!

Monitor in real time for config changes, look for SYS-5-CONFIG_I        

If you have the following lines in your cisco router or switch config:

login on-failure log
login on-success log

Then you can filter syslog for: SEC_LOGIN-4-LOGIN_FAILED and / or SEC_LOGIN-5-LOGIN_SUCCESS - or more simply, to catch both, watch for SEC_LOGIN

Really, you're looking for logins outside of approved windows, login failures (worst case, followed by success).  Or if you are the only network admin, any login attempts that aren't you!

If you don't have those two lines in your configuration, I'd suggest that you add them, then review the Cisco Hardening Guides at the Center for Internet Security (https://benchmarks.cisecurity.org/downloads/browse/?category=benchmarks.network.cisco).  Other vendors will have similar guidance, either on their own sites or at CIS.

You get my point.  In a perfect situation, you would take your logs and discard everything you DON'T want to be alerted on, which should leave the real problems, and new messages that are not problems which you can add to your "filter out" list.    Back in the day, we had a project where we did exactly this for an AS400 - we discarded "known good" and "known innocuous", over time we were just left with just the bad news messages we wanted to see.  However, networks and log messages are so varied as you add new devices, and change so much even from version to version, that this traditional approach might not be so viable anymore.  Alerting on specific messages, as well as regular manual log parsing to see what else you might want to add to the list, is a nice, low interaction approach that gets you there (or close to it) in the end.  This has worked for lots of customers that I have, until they get a proper SIEM or IPS that is.

So back to the "how" - how do you configure alerts now that we know what we want to alert on?  That will depend on your logging solution.  If you use Solarwinds Syslog (used to be Kiwi), it's built into the GUI.  You can trigger on various AND / OR situations - be sure that your seach are case-insensitive.  As you can see from the example below, I EXCLUDE the string "URL Accessed" - this prevents bogus alerts from the firewall, for instance if one of the deskside folks browsing real-estate ad looking to purchase a duplex, or comparison shopping prices on fans or batteries.

In Linux, you'd think it would be easier.  But as so many things in Linux, there are dozens of ways to do this - and they're all at least marginally more complicated.  It's semi-easy to configure email alerts based on severity, as long as the local system mail is tied to a "real" email system (which is almost never).  To trigger on keywords and support "real" email though requires some gymnastics.  You can use logwatch, logcheck (you'll generally use logcheck with cron), also OSSEC also does a good job monitoring logs (amongst other things) and on cofigured inputs or conditions, alerting in any of several methods.  If you want to do it all with stock tools, you can used named pipes as show here: http://serverfault.com/questions/32360/how-can-i-make-syslogd-email-certain-log-messages-to-me. 

Me, I use swatch http://sourceforge.net/projects/swatch/ - mostly because it's simple and it works well.  Life is too short to complicate a simple process like logging.  For an example of using swatch "for real" - check my very first SANS Gold Paper - all those years ago - http://www.sans.org/reading-room/whitepapers/auditing/vpnscan-extending-audit-compliance-perimeter-1711.  I used swatch to trigger policy audits of users VPN-ing in at the time, and I still use swatch for that, along with loads of other things.

What messages or strings would you add to this (short) list of things to alert on?  We're looking mainly for network type alerts on routers, switches, firewalls, load balancers and so on.  What situations would your list entry prevent or diagnose?  Do you have a simpler or more elegant method of triggering on syslog entries in Linux?  Please, use our comment form and let us know how you approach this issue!

===============
Rob VandenBrink
Metafore

Overview of the March 2015 Microsoft patches and their status.

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

With yesterday's updates for iOS, OS X and Apple TV, Apple also addressed a number of security vulnerabilities, most notably the "Freak" vulnerability. After updating, the affected operating systems no longer support export quality ciphers. However, Apple browsers continue to support SSLv3 and as a result, continue to be vulnerable to POODLE.

Quick Summary of the security content of Apple's updates:

XCode 6.2: This update addresses 4 vulnerabilities in subversion and 1 in git. 

OS X: 5 vulnerabilities. The most serious of which is likely a code execution vulnerability in Keychain.

Apple TV: 3 vulnerabilities. One of which would allow an attacker to write files to the system if the user mounts a corrupt disk image.

iOS: 6 vulnerabilities. In addition to FREAK and the above mentioned Keychain problem, a vulnerability that allows an attacker with physical access to the device to see the home screen on a locked devices is patched.

For details from Apple, see https://support.apple.com/en-us/HT1222

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

Threatglass is a one way to find up-to-date examples of exploit kit traffic.  Not all of it is exploit kit traffic, but all of it represents some sort of malicious activity.  Threatglass doesn't explain what type of traffic you're looking at from the pcaps the site provides.  Let's look at a page from last week on Thursday, March 5th 2015 [1].  This one is exploit kit activity.  In the image below, you'll find a link to the packet capture in the lower right-hand corner of the window:

Download the pcap and open it in Wireshark.  User http.request as the filter, and make sure you're showing the host name in the column display.  We quickly find some unusual traffic, which I know from personal experience is the Nuclear Exploit Kit.

For most exploit kits, the pattern of traffic is:  Landing page  -->  Exploit (Java, Flash, Silverlight, IE, etc)  -->  Malware payload if the exploit is successful

Let's look at this example by following a few TCP streams in the pcap.  First, we have the landing page:

Next, the exploit kit sends a Flash exploit to the victim host:

'

When the Flash exploit works, a malware payload is sent.  Currently, Nuclear Exploit Kit obfuscates the malware payload with an ASCII string.  In this case, the binary was XOR-ed with the ASCII string: VhBFALHxyw

Using a Python script, I was able to XOR the payload with that ASCII string again, and I got the original malicious executable:

The Virus Total results indicate the malware is a Tofsee variant - https://www.virustotal.com/en/file/7659b2be203a34b7491c7101c0275b9e20e8d801d236817a5285c2e63e0ad0e5/analysis/

If you want a sample of the deobfuscated payload, you can get it from malwr.com at: https://malwr.com/analysis/N2U3NDUwMjQ5MWViNGZkNWFlMTBkMjkxMzExZGQxNTM/

If you have the time, review some of the other entries on Threatglass to figure out which ones are exploit kit activity, and which ones are other activity, like fake flash installer pop-up windows.  This is one of many resources on line that aspiring analysts can use to build their skills. 

---

Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://threatglass.com/malicious_urls/geospotrima-com

An ISC reader sent us a note about a session cookie that has been appearing in web server logs; the cookie contents triggered cross-site scripting alerts from the Web Application Firewall. Across the various HTTP session instances, the cookie contained the same hash: 3e1dd89fdfa706ed2e69a8eccf98cab048d7b661. Other contents of the cookie included references to malicious-looking third-party URLs that contained affiliate IDs.

I came across an HTTP request on my own server from about a month ago, which contained the same hash value. It looked like this:

Cookie: 3e1dd89fdfa706ed2e69a8eccf98cab048d7b661.session={%22id%22:%226fe15833-083e-4364-84ec-e4a5b9f61ad6%22%2C%22evoke%22:%22back%22%2C%22termsType%22:0%2C%22action%22:1%2C%22firstHistory%22:1%2C%22firstUrl%22:%22http://zeltser.com/extracting-swf-from-pdf-using-swf-mastah%22%2C%22firstReferrer%22:%22https://www.google.nl%22%2C%22actionUrl%22:%22https://interyield.jmp9.com/InterYield/rd.do?affiliate%3Dnxldg2&subid%3D36x55x&adCountIntervalHours%3D10&maxAdCountsPerInterval%3D10&snoozeMinutes%3D3&url%3Dhttp%253A%252F%252Frd-direct.com%252Fctrd%252Fclick%252Fnewjump1.do%253Faffiliate%253D67935%2526subid%253D36x55x%2526terms%253Dzeltser.com%252520extracting%252520malicious%252520flash%252520objects%252520from%252520pdfs%252520using%252520swf%252520mastah%2526ai%253DGBGY6n-oRoaZ5DbR3BvafDuwZZBHn_Zj87Ciuqy_NiyMy4vZ9stpcd-fUa2UQ4DNx6GUMEj6KeGzltSVzUDRpVk07lWGpUkMlyMG9WcqGbazGffYI9a0cQ_J3FAxb2mL-WwfCJMawYXUETMOQe_CEk1s2vaRI8fq4K3Py5tve0uM4UPyCump1wSNSctzDKm_Heo-CfJZ22AHKUGAA9vCWhmxe1tlg4XjKiyKsUF9q5zzg0jCAeKNHyDqhsVo3r-FUjUmxQbTjRD772JxVD6l9h6R91sJQv9o_GcfcHebSu6NpGla5Wh9eEto8cK2LGb79D3XJm_Agq05Hvr0gevAXCxfNltsfRuPnXnSpSHU8x8XkZ-Ss54r7j-BHL_RLNOI-V7hnpAV_gx6J0Fsvdm99Qfm_U7AppaCJQNh-x93VU6nqyjUXFeIdB4o-MlIBv_Y51meo4_pheFWvlX_lmT2mSY-aFmozUo630hQoQF19xIdxV3bya--fu7Eb8js_zLzMsVrh8k7aTe-Qu8zttSsUbg9J4ZpCk3H__4EhaNL5yvIbyyRFJJo5cLoDJjlk4Vtln78qFTTrd0j5YN5IdCUmw%2526version%253D1.2%2526passThruAttr%253DeventHandler%25253Dbackcatcher&searchinfo%3Dzeltser.com%2520extracting%2520malicious%2520flash%2520objects%2520from%2520pdfs%2520using%2520swf%2520mastah&servetime%3D15&origquery%3Dzeltser.com%2520Extracting%2520Malicious%2520Flash%2520Objects%2520from%2520PDFs%2520Using%2520SWF%2520Mastah&targetTitle%3D&serveurl%3Dhttp%253A%252F%252Fzeltser.com%252Fextracting-swf-from-pdf-using-swf-mastah%252F&adultsearch%3Dfalse&pop%3Dover&attributionDisabled%3Dfalse&secUntilMidnight%3D61846%22%2C%22time%22:1423666154148%2C%22exited%22:false%2C%22sawExitOverlay%22:false}

References to zeltser.com are normal and non-malicious (that's my server); the mention of "swf-from-pdf-using-swf-mastah" is also normal, because that's the web page that received the malicious request. However, notice the inclusion of an unexpected hostname interyield.jmp9.com and a mention of "adultsearch". 

I came across many mentions of the cookie hash value seen above when searching the web, including the following trigger of a SQL injection WAP alert:

Cookie: 3e1dd89fdfa706ed2e69a8eccf98cab048d7b661.session={%22id%22:%229f835ef2-cd7e-43b9-861e-6de9d5113dd6%22%2C%22evoke%22:%22back%22%2C%22termsType%22:0%2C%22action%22:1%2C%22firstHistory%22:1%2C%22firstUrl%22:%22http://www.stoppublicites.fr/?page_id%3D2%22%2C%22firstReferrer%22:%22https://www.google.fr%22%2C%22actionUrl%22:%22https://www.tr553.com/InterYield/rd.do?affiliate%3Drzbkmax&subid%3D9614_1001_fr&adCountIntervalHours%3D24&maxAdCountsPerInterval%3D12&snoozeMinutes%3D2&url%3Dhttp%253A%252F%252Fcoreclickhoo.com%252Fctrd%252Fclick%252Fnewjump1.do%253Faffiliate%253D66385%2526subid%253D9614_1001_fr%2526terms%253Dstoppublicites.fr%252520nettoyer%252520son%252520ordinateur%252520stop%252520les%252520publicit%2525C3%2525A9s%252520intempestives%2526ai%253Db5mbQSp35CDIM8MtUy8woqtnjjHFnHB3ffZyrAlbZK9_PMF8spIXolWRiMEY4cAutjyO_Z-a2ptbmfky5jNdYyaxu2fuGRTEb59un12-ny0lAw_qXUhQzSUxJBCzXrgkJd0zYz1reyEsi28kqJHrAgWtVWPqLl7e20nbFGEaOaMP8cyITdxlg8UHWWOovjOInL9RMVxLCn4Q8O_vhgR3PV-1G6VlbN8GywCRSOCdAHHy5Tbrf2ft255bQcJe7X1Wp3dKuiuJhdk2bMcsof2lcGTxuMYmBXRHicP-yNREHlIWCM86s1FwLi06ojqqeiEc9Am73WnkvbKR6vv9sAc8bIfUiE8wTm6673h-ouF0GMfyrhuodcvdL33t_7lMjBGMlg-83EFxqtrD968hqVpKWNVaxP7fbCOUHr4_1oHjQOq0j_S_DrZhrEG953stbKIFAL2z5uhPFs0Y5ByFbRLlSn9YzM7hfxcqmugeCUhUAwiiyNyeNgDXLkAH-X9N5YmFSo03jcQuEPU6_y2upRASxg%2526version%253D1.2%2526passThruAttr%253DeventHandler%25253Dbackcatcher&searchinfo%3Dstoppublicites.fr%2520nettoyer%2520son%2520ordinateur%2520stop%2520les%2520publicit%25C3%25A9s%2520intempestives&servetime%3D728&origquery%3Dstoppublicites.fr%2520Nettoyer%2520son%2520ordinateur%2520%2520Stop%2520les%2520publicit%25C3%25A9s%2520intempestives&targetTitle%3D&serveurl%3Dhttp%253A%252F%252Fwww.stoppublicites.fr%252F%253Fpage_id%253D2&adultsearch%3Dfalse&pop%3Dover&attributionDisabled%3Dfalse%22%2C%22time%22:1416831764095%2C%22exited%22:false%2C%22sawExitOverlay%22:false}

I noticed the mention of the cookie value 3e1dd89fdfa706ed2e69a8eccf98cab048d7b661 dating back to 2012.

We're probably dealing with some malicious scanning tool that has this value hardcoded into its cookie-generating code, which is designed to exploit XSS and/or SQL injection vulnerabilities with the goal of redirecting victimized sites' visitors to malicious destinations.

Do you have additional information about this cookie value or would like to share your analysis of this data? Please share your perspective in the discussion forum.

-- Lenny Zeltser

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog.

Malicious software sometimes uses mutex objects to avoid infecting the system more than once, as well as to coordinate communications among its multiple components on the host. Incident responders can look for known mutex names to spot the presence of malware on the system. To evade detection, some malware avoids using a hardcoded name for its mutex, as is the case with the specimen discussed in this note.

Static Mutex Names as Indicators of Compromise

For background details about mutex (a.k.a. mutant) values and their role in incident response, see my earlier article Looking at Mutex Objects for Malware Discovery and Indicators of Compromise. As I described there, when examining a potentially-infected system, we can look for names of mutex objects known to be used by malicious programs. Moreover, in some circumstances, mutex values could be used as markers to immunize the system from infection. Not all malware uses mutex objects, but this is an indicator that's worth looking for.

This approach works well when you've already found malware on some systems and examined it to determine that it uses specific mutex names. You can also obtain mutex name details from threat intelligence feeds, sites such as TotalHash, and the use of automated malware analysis tools. For a long list of mutex names used by various malware samples, take a look at the list published by Hexacorn.

However, malware could name its mutex objects in a less-predictable way, as discussed below.

Mutex Defined by TreasureHunter Malware

Let's take a brief look at a malware sample with the MD5 hash 070e9a317ee53ac3814eb86bc7d5bf49. Its author called this malicious program TreasureHunter, according to a couple of strings that were embedded into the file:

c:\users\admin\documents\visual studio 2012\projects\treasurehunter\release\treasurehunter.pdb
TreasureHunter version 0.1 Alpha

This malicious file was named jucheck.exe and was discovered under the %AppData% folder. We won't look at all aspects of this malicious program, since my goal is to focus on its use of mutex objects for this article.

If you infect a laboratory system with TreasureHunter, you can use a tool such as Process Hacker to spot that this malicious process creates a mutex named 53c044b1f7eb7bc1cbf2bff088c95b30.

You can further investigate TreasureHunter's use of the mutex by running the malicious executable in a debugger such as OllyDbg. As you can see in the screenshot below, specimen calls CreateMutexA to create the mutex:

Running the specimen multiple times results in the same mutex name being used across the experiments. At this point, you might be inclined to use the mutex name 53c044b1f7eb7bc1cbf2bff088c95b30 as an indicator of compromise for TreasureHunter. However, further analysis would show that on other systems this sample names mutex objects differently. For instance, VirusTotal reports the mutex name 3ed1ed60c7d7374bf0dd76fc664b39cd, while VxStream Sandbox reports the name 3ac22cadc45e0558cad697d777f6c3d3. Why such a discrepancy?

How TreasureHunter Generates the Name of Its Mutex

The names of this specimen's mutex object appear to be MD5 hashes, but what value is the specimen hashing? Looking more closely at TreasureHunter with the help of a debugger can shed some light on this functionality.

The OllyDbg screenshot above shows that the specimen stored the name of its mutex in a variable located at the offset 414EA0. You could scroll up in the program's code to find which assembly instruction saves data into that memory location. As shown in the following screenshot, the string representing the name of the mutex is being moved into that location from the register EAX. This register stores the results of the previously-invoked function, which in our example is 402480:

We could use the debugger to drill into that function to determine how it derives the name of the mutex. That function ends up calling function 401F10, which returns the string RTTDK-XXXXX-P97R3-YYYYYY-8K7PH, as shown below. I replaced some characters of the string with XXXXX and YYYYY for privacy reasons:

Later, the code calls function 401020, which returns the string RTTDK-XXXXX-P97R3-YYYYYY-8K7PH( as shown below:

Further, the code computes the MD5 hash of the string RTTDK-XXXXX-P97R3-YYYYYY-8K7PH( to derive 53c044b1f7eb7bc1cbf2bff088c95b30, which it ends up using as the mutex name.

Where does the string RTTDK-XXXXX-P97R3-YYYYY-8K7PH come from? To figure that out, we can drill into function 401F10, which returned this value. That function invokes several API calls to read the system's registry:

The goal of this code is to read HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId:

This is where Windows stores its Product ID. The specimen also looked in several other registry locations where Windows sometimes stores this information.

Further in the function, the specimen's code transformed the Product ID's into the RTTDK-XXXXX-P97R3-YYYYYY-8K7PH that it later used as the basis for its mutex name using a deterministic algorithm that I had neither the patience, nor reason to reverse-engineer. This is why when this specimen ran in automated malware analysis sandboxes it used a different mutex value--those products must have had different Windows Product IDs.

The Use of Non-Static Mutex Values in Malicious Software

Malware authors who wish to employ mutex objects need a predictable way of naming those objects, so that multiple instances of malicious code running on the infected host can refer to the same mutex. A typical way to accomplish this has been to hard-code the name of the mutex. The author of TreasureHunter decided to use a more sophisticated approach of deriving the name of the mutex based on the system's Product ID. This helped the specimen evade detection in situations where incident responders or anti-malware tools attempted to use a static object name as the indicator of compromise.

-- Lenny Zeltser

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog, where he contemplated using mutex objects and other infection markers for immunizing systems.

Earlier this year, @Techhelplistcom reported the spam and landing site infrastructure used to spread Asprox malware switched to porn-related URLs [1]. This started back in mid-January 2015, and I still haven't seen much about it in the open press. Since then, this infrastructure has continued spreading links to pornography or diet-related scams [2] [3].

We’re still seeing the malicious emails with the same type of subject lines, but these typically have a zip file attachment with a javascript file inside (.js). The image below contains an example of the malicious spam I've seen with fake toll road debt subject lines. These all have the zip attachments of .js files. This spam is Asprox-like in subject matter, but the malware is different than what we’ve previously seen with Asprox botnet. I've asked a few other people about this.  From what I can tell, no one yet seems to believe these new emails are from the Asrpox botnet.

What happened to you, Asprox botnet? Are you only spreading spam, now?

The Asprox botnet first emerged in 2007 [4]. This botnet sent a large amount of spam over the years, including malicious spam (malspam) containing malware designed to infect a user's computer, making it part of the Asprox botnet.

This malspam had malicious zip file attachments, or it had links pointing to compromised servers hosting the malware.  

Shown above: an Asprox botnet email with a malware attachment.

Shown above: an Asprox botnet email with a link to the malware.

Sites like techhelplist.com have plenty of examples of Asprox emails [5]. In the absence of anything interesting, I could always find an email from the Asprox botnet and analyze some familiar malware. That’s not the case now. This seems to be the end of an era, at least for the malware spam [6].

I’ve included some images below from the Asprox botnet emails I've collected over the past few months. Consider this an “Asprox botnet greatest hits” collection. Like many greatest hits compilations, I'm sure people will find their favorites missing from this collection.  Feel free to share any stories you have about these Asrpox emails.

---

Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] https://twitter.com/Techhelplistcom/status/558085217907638272
[2] https://twitter.com/Techhelplistcom/status/562997176729874432
[3] https://twitter.com/Techhelplistcom/status/570428997043032064
[4] http://www.trendmicro.com/media/wp/asprox-reborn-whitepaper-en.pdf
[5] https://techhelplist.com/index.php/component/tags/tag/11-asprox
[6] https://twitter.com/herrcore/status/573329942294884352

Security breaches seem to be the norm now. Home Depot, Target, Sony, JP Morgan Chase to name a few who have been in the recent past, victim of "sophisticated" system compromise which ultimately lead to sensitive information leaked to the open. It is difficult to tell how sophisticated the attack was since we rarely ever see a report how the attack took place and what could have been done to prevent it (remember the last step of incident response).

One of the latest victims is Anthem Inc. who may have been compromised as early as December 2014 over a period of several weeks. For those who have been victims of this attack, Antem setup a website to “signup for Identity Theft Repair & Credit Monitoring Services”.

Coming back to my question, should it be mandatory to have an independent security audit performed against the affected systems after a severe breach? The result of the report is made available to the victims to help them regain trust their data is secure and whenever necessary, is encrypted and protected. What do you think?

[1] https://www.anthem.com/health-insurance/home/overview
[2] https://www.anthemfacts.com
[3] http://www.oas.org/cyber/documents/IRM-5-Malicious-Network-Behaviour.pdf

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

A new variant Cryptowall (An advanced version of cryptolocker) is now using a malicious .chm file attachment to infect systems.

According to net-security.org, Bitdefender labs has found a spam wave that spread a malicious .chm attachments.

CHM is the compiled version of html that support technologies such as JavaScript which can redirect a user to an external link.

“Once the content of the .chm archive is accessed, the malicious code downloads from this location http:// *********/putty.exe, saves itself as %temp%\natmasla2.exe and executes the malware. A command prompt window opens during the process.”

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

1-https://isc.sans.edu/diary/Traffic+Patterns+For+CryptoWall+3.0/19203

2-https://isc.sans.edu/forums/diary/Pay+attention+to+Cryptowall/18243/

3-http://www.net-security.org/malware_news.php?id=2981&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+HelpNetSecurity+%28Help+Net+Security%29

October 2014 saw the beginning of an e-mail campaign spamming malicious Microsoft Office documents. Mostly Word documents using the “old” binary format, but sometimes Excel documents and sometimes the “new” ZIP/XML format. All with VBA macros that auto-execute when opened.

Yesterday, we started to see XML attachments. You might expect that these attachments open with Internet Explorer when you double-click them, but if you have Microsoft Office installed, they will open with Microsoft Word.

The XML file contains an element (w:binData) with a base64 string as content. Its attribute (w:name="editdata.mso") reveals it is a MSO file. Decoding the base64 string, we end up with a binary stream with header ActiveMime. 50 bytes into the stream (position 0x32), a ZLIB compression object starts. Inflating this object reveals an OLE file (header 0xD0CF1LE0) containing the VBA macros.

This OLE file can be analyzed with my oledump tool I mentioned in a previous diary entry [1], but I just released a new version [2] that handles XML files directly. And Philippe Lagadec already released a new version of his olevba tool yesterday [3].

Both tools are Python programs, giving you the means to analyze malicious Microsoft Office documents in any environment supporting Python, without Microsoft Office applications.

If you filter e-mail attachments that are Microsoft Office documents, you should check what your e-mail filter does with XML files. XML declaration identifies the XML file as a Word document, and attribute w:macrosPresent="yes" (of element w:wordDocument) indicates the presence of VBA macros. Remark that these strings are different for XML Excel documents.

Until now, we have only seen XML Word documents. Please post a comment if you received another format, like XML Excel documents, if possible with a link to the VirusTotal entry.

The MD5 of the sample discussed in this diary entry is 77739ab6c20e9dfbeffa3e2e6960e156.

1: https://isc.sans.edu/diary/oledump+analysis+of+Rocket+Kitten+-+Guest+Diary+by+Didier+Stevens/19137
2: http://blog.didierstevens.com/programs/oledump-py
3: http://www.decalage.info/python/oletools

(in an earlier version of this story, I mixed up Firefox with Chrome. AFAIK, it was Firefox, not Chorme, that added DNS ANY queries recently)

Recently, Firefox caused some issues with it's use of ANY DNS queries [1]. "ANY" queries are different. For all other record types, we got specific entries in our zone file. Not so for ANY queries. RFC 1035 doesn't even assign them a name [2]. It just assigned the query code (QCODE) of 255 to a "request for all records". The name ANY is just what DNS tools typically call this query type.

The "ANY" record works a bit differently depending on whether the query is received by a recursive or authoritative name server. An authoritative name server will return all records that match, while a recursive name server will return all cached values. For example, try this:

1. Send a DNS "ANY" query for "evilexample.com" to the authoritative name server

dig evilexample.com ANY @ns1.dshield.org

I am getting 44 records back. Your number may be different.

2. Next, request a specific record using your normal recursive DNS server

dig evilexample.com

I am getting one answer and two authority records (YMMV)

3. Finally, send an "ANY" query for evilexample.com to your recursive name server

dig ANY evilexample.com

You should get essentially the same information as you got in step 2. The recursive name server will only return data that is already cached. UNLESS, there is no cached data, in which case the recursive name server will forward the query, and you will get the complete result.

So in short, if there is cached data, ANY queries are not that terrible, but if there is no cached data, then you can get a huge amplification. The "evilexample.com" result is close to 10kBytes in size. (Btw: never mind the bad DNSSEC configuration.. it is called "evilexample" for a reason).

So but how common are these "ANY" queries? I took a quick look at a recursive and an authoritative name server. The recursive name server had no ANY queries at all in its query log (I am not using the latest version of Chrome on Windows). The authoritative name server had 0.7% of ANY queries. (click on image for full size)

Authoritative Name Server	Recursive Name Server

As expected, the recursive name server, which is only forwarding requests for a few internal hosts, is a lot "cleaner". The authoritative name server, which is exposed to "random" queries from external hosts, is a lot more "dirty" and with many networks still preferring the legacy IPv4 protocol, A queries outnumber AAAA queries. Any queries make up less then 1%, and they follow a typical scheme. For example:

Short "surges" of queries arriving for the same ANY record from the same /24. This is not "normal". All these hosts should probably use the same recursive name server, and we should only see one single ANY request that is then cached, if we see it at all. This is typical reflective DDoS traffic. In this case, 212.113.164.0/24 is under attack, and the attacker attempts to use my name server as an amplifier. 

Is it safe to block all ANY requests from your authoritative name server? IMHO: yes. But you probably first want to run a simple check like above to see who and why is sending you ANY requests. Mozilla indicated that they will remove the ANY queries from future Firefox versions, so this will be a minor temporary inconvenience.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1093983
[2] https://www.ietf.org/rfc/rfc1035.txt

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

Have you ever been on a pentest, or troubleshooting a customer issue, and the "next step" was to capture packets on a Windows host?  Then you find that installing winpcap or wireshark was simply out of scope or otherwise not allowed on that SQL, Exchange, Oracle or other host?  It used to be that this is when we'd recommend installing Microsoft's Netmon packet capture utility, but even then lots of IT managers would hesitate about using the "install" word in association with a critical server.  Well, as they say in networking (and security as well), there's always another way, and this is that way.

"netsh trace" is your friend.  And yes, it does exactly what it sounds like it does.

Type "netsh trace help" on any Windows 7 Windows Server 2008 or newer box, and you'll see the following:

C:\>netsh trace help

The following commands are available:

Commands in this context:
?              - Displays a list of commands.
convert        - Converts a trace file to an HTML report.
correlate      - Normalizes or filters a trace file to a new output file.
diagnose       - Start a diagnose session.
dump           - Displays a configuration script.
help           - Displays a list of commands.
show           - List interfaces, providers and tracing state.
start          - Starts tracing.
stop           - Stops tracing.

Of course, in most cases, tracing everything on any production box is not advisable - especially if it's your main Exchange, SQL or Oracle server.  We'll need to filter the capture, usually to a specific host IP, protocol or similar.  You can see more on this here:

netsh trace show capturefilterhelp

One of the examples in this output shows you how t o e.g. 'netsh trace start capture=yes Ethernet.Type=IPv4  IPv4.Address=157.59.136.1'

You could also add Protocol=TCP or UDP and so on..

Full syntax and notes for netsh trace can be found here: https://technet.microsoft.com/en-us/library/dd878517

For instance, the following session shows me capturing an issue with a firewall that I'm working on.  Note that you need admin rights to run this, the same as any capture tool.  In a pentest you would likely specify an output file that isn't in the users' directory.

C:\>netsh trace start capture=yes IPv4.Address=192.168.122.2

Trace configuration:
-------------------------------------------------------------------
Status:             Running
Trace File:         C:\Users\Administrator\AppData\Local\Temp\NetTraces\NetTrace
.etl
Append:             Off
Circular:           On
Max Size:           250 MB
Report:             Off

When you are done capturing data, it's time to stop it:

C:\> netsh trace stop
Correlating traces ... done
Generating data collection ... done
The trace file and additional troubleshooting information have been compiled as
"C:\Users\Administrator\AppData\Local\Temp\NetTraces\NetTrace.cab".
File location = C:\Users\Administrator\AppData\Local\Temp\NetTraces\NetTrace.etl

Tracing session was successfully stopped.

c:\

The cool thing about this is that it doesn't need a terminal session (with a GUI, cursor keys and so on).  If all you have is a metasploit shell, netsh trace works great!

If this is a capture for standard sysadmin work, you can simply copy the capture over to your workstation and proceed on with analysis.  If this is a pentest, a standard copy might still work (remember, we're on a Microsoft server), but if you need netcat type function to exfiltrate your capture, take a look at PowerCat (which is a netcat port in PowerShell).

Next, open the file (which is in Microsoft's ETL format) in Microsoft's Message Analyzer app - which you can install on your workstation rather than the server we ran the capture on ( http://www.microsoft.com/en-us/download/details.aspx?id=44226 ). Message Analyzer has a surprisingly nice interface and some decent packet parsing, you might be able to wrap up your analysis just in this tool (see below).

If you do need another packet analysis tool, it's easy to a File / Save As / Export, and save as a PCAP file that Wireshark, tcpdump, SNORT, ngrep, standard python or perl calls, or any other standard tool can read natively.

Or you can convert to PCAP using PowerShell (of course you can).  A short, simple script to do this might look like:

$s = New-PefTraceSession -Path “C:\output\path\spec\OutFile.Cap” -SaveOnStop
$s | Add-PefMessageProvider -Provider “C:\input\path\spec\Input.etl”
$s | Start-PefTraceSession

This Powershell cmdlet is not available in Windows 7 - you'll need Windows 8, or Server 2008 or newer
(This script was found at http://blogs.technet.com/b/yongrhee/archive/2013/08/16/so-you-want-to-use-wireshark-to-read-the-netsh-trace-output-etl.aspx )

If 'netsh trace' has solved an interesting problem for you, or was the tool that got you some interesting data in a pentest, please, use our comment form to let us know how you used it (within your NDA of course!)

===============
Rob VandenBrink
Metafore

There has been some press surrounding the SSL issue published recently dubbed Freak.  It was reported in the Washington post¹ and other sites, but what does it really mean?

The issue relates to the use of Export Ciphers (the crypto equivalent of keeping the good biscuit yourself and giving the smaller broken one to your little brother or sister).  The Export Ciphers were used as the "allowed" ciphers for non US use.  The ciphers are part of OpenSSL and the researchers² have identified a method of forcing the exchange between a client and server to use these weak ciphers, even if the cipher suite is not "officially" supported³.  

On first reading, like many, I thought so what, especially since you have to do a man-in-the-middle (MITM)  attack.  When you do a MITM attack you have full control over the connection anyway, so why bother decrypting anything? However, if I'm reading and interpreting the examples correctly (kind of hoping I'm wrong), it looks like this particular attack solves one challenge that a MITM has. For HTTPS intercept you usually generate a new certificate with the information of the site and resign the certificate before presenting it to the client. Whenever you present this newly signed certificate  the client receives an error message stating that the certificate does not match the expected certificate for the site.  From the vids² it looks like this attack could "fix" that particular problem.  So now when you perform a MITM attack you retain the original certificate and the user is none the wiser.  This could open up a whole new avenue of attacks against clients and potentially simplify something that was quite difficult to do. 

What is the impact to organisations? Well it is quite possible that your sites will be impersonated and there won't be much that can be done about it and you may not even know that your customers are being attacked.  To prevent your site from being used in this attack you'll need to patch openSLL⁴ (yes again).  This issue will remain until systems have been patched and updated, not just servers, but also client software.  Client software should be updated soon (hopefully), but there will no doubt be devices that will be vulnerable to this attack for years to come (looking at you Android).

Matthew Green in his blog³ describes the attack well and he raises a very valid point. Backdoors will always come back to bite. 

The researchers have set up a site with more info^5. 

Cheers

Mark H  - Shearwater

(Thanks Ugo for bringing it to our attention).

Links:

¹ - http://www.washingtonpost.com/blogs/the-switch/wp/2015/03/03/freak-flaw-undermines-security-for-apple-and-google-users-researchers-discover/
² - https://www.smacktls.com/#freak
³ - http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
⁴ - https://www.openssl.org/news/secadv_20150108.txt
⁵ - https://freakattack.com/

Since May of 2014, I've been tracking a particular group that uses the Sweet Orange exploit kit to deliver malware.  This group also uses obfuscation to make it harder to detect the infection chain of events.

By 2015, this group included more obfuscation within the initial javascript.  It's a relatively minor change in the overall traffic patterns; however, the result causes more work to detect the malicious activity.

Either way, the infection chain flows according to following block diagram:

Previous obfuscation

Below are images from an infection chain from July 2014 [1].  Here we find malicious javascript from the compromised website.  In this image, I've highlighted two areas: 

First is the function that replaces any non-hexadecimal characters with nothing, and it replaces various symbols with the percent symbol (%):

Second is the URL that will return the variable to be translated:

Here's how the variable is translated to the URL for the Sweet Orange EK landing page:

Recent obfuscation

Below are images from an infection chain by the same actor in February 2015 [2].  Again we find malicious javascript from the compromised website.  However, in this case, there's more obfuscation:

First is the function that replaces any non-hexadecimal characters with nothing and replaces various symbols with the percent symbol (%).  This time, we have unicode-based hexadecimal obfuscation and some variables thrown in.  This does the same basic function as the previous example.  It's now a bit harder to find when you're looking through the javascript.

Second is the URL that will return the variable to be translated:

That URL is now obfuscated with unicode-based hexadecimal characters.  For example, \u0074 represents the ASCII character "t" (lower case).

Once again, let's see how the variable is translated to the URL for the Sweet Orange EK landing page:

Final Words

This evolution in obfuscation is a minor change in the overall traffic; however, the result causes more work for analysts to fully map the chain of events.  We can expect continued evolution of these obfuscation used by this and other actors.

---

Brad Duncan, Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://malware-traffic-analysis.net/2014/07/08/index.html
[2] http://malware-traffic-analysis.net/2015/02/09/index2.html

Klaus Vesthammer recently tweeted that "The Internet of Things is just like the regular Internet, just without software patches". We have a flood of announcements about vulnerable devices, and little in terms of patches. At the same time, expect more and more of these devices to be connected to your network, if you want it or not. "Bring your own Devices" should be addressed more inclusive then just covering smart phones and tablets.

If you do have a working inventory system that recognizes and blocks unauthorized devices in real time, then stop reading and count yourself lucky. But for most of us, network maps are filed under "fiction" and network access control was this great solution we tried and failed as it hit real network life. So what else is there to do?

One of the critical aspects is to figure out which devices are not just on your network, but also do they talk to systems outside of your network. Active scanning will only get you that far. Many devices, to save power, will not connect to the network unless they have something to say. Some also use bluetooth to connect to smartphones and use them as a gateway. The device will not show up as an entity on your network in this case.

Here are a couple of indicators to look for:

- NTP queries: Some devices do have hard coded NTP servers, that do not match your standard network configuration
- DNS queries: DNS knows everything
- HTTP User-Agent and Server headers

Someone I am sure will provide pointers to do this in Bro. For everybody else, some simple log parsing scripts can help. Any other methods your use to find new and dangerous devices on your network?

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

Beyond Binary is reporting a vulnerability affecting Seagate's Business Storage line of NAS devices and possibly other Seagate NAS products. These are fairly common devices in SOHO and even small enterprise applications. 

It appears that a number of OTS components and the custom web application used in the web management interface are out of date and will permit unimpeded access to the administration functions of the device.  It is believe that versions of the firmware up to and including 2014.00319 are vulnerable. 

It appears to be trivial to exploit the devices and a metasploit module and an exploit are publicly available.

It is hoped that if you have one of these devices in your network that you do not have the administration interface accessible on the Internet.  If you do you will want to remove it. You can be sure that the bad guys have started scanning for these devices. At this point no updated firmware is available to resolve this issue.

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