May 062013
 

“Watering hole” attack. Every time I hear about it, I think of hippopotami– a nice change, actually, from the usual “viral” or “phishing/whaling” analogies. This afternoon I came across RSA’s “Lions at the Watering Hole” article about the VOHO watering hole attack from last July– in which they posted a tiny traffic snippet of a gh0st RAT attack with a C2 site of 58.64.155.59 (China).

I love dissecting little releases like this, because sometimes you can learn things about the researcher’s environment, in addition to the malware. RSA’s article is interesting, but let’s see if there’s anything ELSE we can learn from this little traffic sample!

According to RSA, “[T]he gh0st RAT variant on the infected PC checks into a C2 site at: 58.64.155.59, an IP address located in China… Communication occurs over ports 80, 443, and 53 and initial communication can be recognized via the presence of the string ‘HTTPS’ in the initial payload, although the traffic is not valid HTTPS traffic.”

Let’s take a closer look at the JPG RSA posted:

Warmup – The First Frame

What’s the first thing we notice? Well, this actually shows TWO Ethernet frames, as you can see below. The first Ethernet frame consists of the Ethernet header, a 20-byte IPv4 header, and a 20-byte TCP header, and that’s it. There’s no data in the payload of the TCP segment. The hexadecimal sequence “0×4500″ is a strong indicator that we’re looking at an IP packet– the “4″ stands for the IP version, and the “5″ is the number of 32-bit words in the IP header. From this, we know this IP header is the minimum length of 20 bytes (equivalent to 5 32-bit words). We also see that the “Protocol” field in the IP header is set to “06,” which tells us that the encapsulated protocol is TCP (see IANA’s protocol assignments).

watering-hole-two-frames

The TCP header is also 20 bytes, with no options. Of course, that means that the total amount of data in the Ethernet payload is only 40 bytes long: 20 bytes of IP header, and 20 bytes of TCP header. That’s not enough to meet the minimum size of an Ethernet frame (46 bytes), and so we also see six (6) null bytes of padding at the end of our Ethernet frame. (If you remember the “Etherleak” scandal from 2002, these are those lovely bytes of padding which at one time contained unsanitized portions of kernel memory.) :-)

Hardware Manufacturers

Good warmup. Now let’s look more closely at the second Ethernet frame, which actually contains the gh0st RAT C2 traffic.

watering-hole-frame2-mac

Starting with the Ethernet header, the source MAC address is “00 50 56 9c 00 09.” Let’s look up the manufacturer of that NIC in the IEEE’s oui.txt file. Scrolling down, we see that “00-50-56″ corresponds with “VMWare, Inc.”

oui-vmware

Looks like the VOHO-infected system is running in VMWare. Pretty common in malware research labs, apparently including RSA.

The destination MAC address is “B8 E6 25 4C DB F9.” According to the IEEE, that NIC is manufactured by 2Wire:

oui-2wire

Likely, that means that the gateway serving RSA’s infected VM has a NIC manufactured by 2Wire.

Where did you come from, where did you go?

Let’s find our source and destination IP addresses. You can do this pretty easily by eyeball. Just look for that telltale “0×4500″ in the second Ethernet frame, and then count 13 bytes (this is referred to as the “12th byte offset,” counting from ZERO). The 4 bytes at the 12th byte offset represent the source IP address. This is immediately followed by the 4-byte destination IP address.

watering-hole-frame2-ips
From this we see:

Source IP address = C0 A8 00 6A = 192.168.0.106

Looks like RSA’s investigator was on a classic 192.168 non-routable subnet.

Destination IP address = 3A 40 9B 3B = 58.64.155.59

This corresponds with the destination C2 address that RSA referred to in their blog post. At the moment, it’s registered to a network provider in Hong Kong:

inetnum:        58.64.155.0 - 58.64.156.255
...
person:         Network Management Center
nic-hdl:        NC315-AP
...
person:         Ivan Wong
address:        17/F Chevalier Commercial Centre,8 Wang Hoi Road, Kowloon Bay, Hong Kong
country:        HK
phone:          +852-2133 4091
e-mail:         ivanwong@newworldtel.com
nic-hdl:        IW110-AP
mnt-by:         MAINT-HK-NEWWORLDTEL
changed:        kmmwong@newworldtel.com 20101004
source:         APNIC

Poor Ivan Wong probably gets a lot of phone calls.

MaxMind’s GeoIP lookup places this IP address at 22.25, 114.16667. Here’s a map:

google-map-network
Just a fun little exercise, since of course things could have changed since this pcap was taken, and IP geolocation seems to be mostly liquor and guessing anyway.

OS Fingerprinting

Notice the Time-to-Live (TTL) value in frame #2, at the eight-byte offset of the IPv4 header (remember, we count from ZERO, so it’s really the ninth byte in the IPv4 header). This is set at 0×80, or 128 in decimal. Referring to Erik Hjelmvik’s great article on Passive OS Fingerprinting, initial TTL values for Windows are 128, whereas Linux and FreeBSD are 64. That means it’s likely the source is a Windows system.

watering-hole-frame2-ports

Digging deeper into the TCP segment, you can see the Window Size is 0xFFFF, or 65535.

Finally, check out the source port. It’s the first field in the TCP header, and as you can see it’s set to 0×0412, or 1042 in decimal. The destination port is 0×0050, or port 80, which makes sense, especially given that RSA said their gh0st RAT communicated over ports 80, 443 or 53.

Does that source port seem low to you? It should– IANA recommends using the range 49152-65535 for ephemeral ports (those ever-changing client port numbers that are used to connect to servers on static ports). Most modern operating systems use very high-numbered ports for ephemeral ports by default, such as the IANA-recommended range. Linux kernels typically use ports 32768-61000 for this purpose. The most notable exception is Windows XP, which by default uses ports 1025-5000 for ephemeral ports. This further supports our theory that RSA’s researcher was running Windows XP.

To Conclude…

As you can see, even a tiny snippet of a pcap can reveal a lot! From just a few bits and bytes, we’ve learned that RSA’s investigator was probably using Windows XP on a VMWare guest, which was assigned the IP address 192.168.0.106. The local router had a network card likely manufactured by 2Wire. We’ve also seen firsthand that the C2 channel traffic, which was masquerading as “HTTPS,” was running over port 80, and confirmed the gh0st RAT’s destination.

If you thought that was fun, join us for the “Network Forensics” 4-day class at Black Hat for WAY more!

Share and Enjoy

  9 Responses to “Dissecting RSA’s “Watering Hole” Traffic Snippet”

  1. Minor error. 0xffff is 65535, not 255.

  2. Small detail, 0xffff is not 255.

  3. Thanks, guys! Fixed.

  4. [...] Dissecting RSA’s packet capture of the VOHO Watering hole attack [...]

  5. Hi Sherri,

    What I don’t understand is how within the original aforementioned pcap trace you knew where the first and second frames begin and end ? And then just by looking at a bunch of HEX values you can derive ip addresses etc. Can you do this because certain positions within the frame and packet mean something very specific ? And then do you know off the top of your head those positions and what the hex values actually mean ?

    In other words how does one know where to start to break down a pcap trace into specific bits (like you have) and the know when one new piece of the puzzle starts and ends and then where the next pieces of the puzzle starts and ends ? To most people it just looks like a block of hex.

    (if your book teaches the answers to my question(s), please let me know which chapter i.e. since i have only just bought your book).

    -Alex

    • Hi Alex,

      > Can you do this because certain positions within the frame and packet
      > mean something very specific ?

      Yes, that’s exactly right. Take a look at the protocol charts for Ethernet (p. 123 of “Network Forensics”), IPv4 (p. 39), and TCP (p. 41). These are basically maps that tell you what the different bits and bytes mean. Chapter 4 teaches you all about packet analysis and protocol dissection. For more details, you can also check out the RFCs for each protocol (see the footnotes).

      We also have a “Handy Protocol Reference Chart” that we use in class… I’ll post it for you as soon as I have a sec.

  6. Do you have that chart handy ?

    -Alex

  7. Great! Thanks!

    -Alex

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>