Want to defend your network? Profile the person attacking it

PART 1 – Can't keep them out, so catch them while they’re in

Sysadmin blog If you want to hack someone's network then learn your target. This starts with recon. What does your target run? What information can you find out about them? Remote scanning will tell you lots about a target system ... unless their sysadmins are good and have changed all the banners to throw you off.

So you learn about the people involved. Who are they? Have any of the technical staff or managers done talks? Where did they work before? People are sloppy and leave information lying around all over the place ... and the internet is forever.

That talk or blog about how a big problem was solved can give you lots of clues about how a company's network is designed, what applications they use and so forth. Social media feeds are a gold mine; techs love nothing more than to complain about frustrating applications, or talk about new ones that they are trying out.

A really good hack can be months or even years in the recon stage. It probably involves building a duplicate network in your own lab at which you can make dry runs.

Cloud offerings can really help with this because the more people use public cloud computing, the more they are using a pre-canned offering that you can duplicate with a minimum of effort. After you know all that you are likely to know, you move to coding stage.

The coding stage overlaps recon somewhat, in that a lot of the recon stage will be spent designing the code you'll be using to attack your target. You'll need to assemble a list of exploits you can try, based on what you know the target runs. You'll also want to learn the operating systems, monitoring solutions and intrusion detection systems in play so that you can hide your tracks.

The coding stage is assembling your payloads into deployable weapons. You might need to try several before you find one that managed to get you a beachhead into the target network. Once there, you can then spool out your payloads onto different systems – covering your tracks the whole time – and deploying your other beachhead tools (including those which failed; they may work from behind the perimeter) to make sure that you have multiple access points.

All of this is a lot of work, but gaining access to a network is the easy part.

Sneaking out is always hard

There is an economic incentive for companies not to pay too close attention to people trying to sneak in to their networks. Simply put: if they don't know about it, they can't be held accountable. Companies can point to the industry-standard, off-the-shelf security solutions they've deployed and say they did their due diligence.

On the other hand, companies are absolutely paranoid about people trying to remove data from the network. They're also paranoid – for completely different reasons – about what their staff might be doing with the company network. Are the proles wasting time on Facebook? The bigger the company the more likely they will see every single bit that leaves the network.

If you manage to embed a remote access application in your target's network making it something that people won't notice is actually pretty easy. Have it talk something innocuous or nerdy. Nobody really notices SSL traffic to a website hosted on Amazon.

If you have a legitimate looking website living in a VM on Amazon then you can have your remote access tool talk to an API interface buried at some sub-URL in order to exchange commands. So long as the traffic usage isn't high, it will probably be overlooked.

However, try to pull 2TB worth of data off of that network and alarms will go off everywhere.

Large volume transfers are suspicious. Protocols such as RDP are suspicious. SSH maybe not so much, but that really depends on the company. Many are getting wise to it.

Everyone monitors cloud applications such as Dropbox nowadays, so you're not going to take your bounty, stuff it into a cloud storage application, and use that to exfiltrate data unless your target's sysadmins are massively underfunded. Similarly, if there's this connection to a random website on Amazon that's open for eight consecutive months, always at exactly 50KiB/sec, someone will eventually notice.

This is why bulk data theft is so much rarer than simple compromises to mine bitcoin, pump out spam or encrypt everything and demand ransom. Getting in is easy. Getting out is hard.

Hacking from the back of beyond

You don't need a good internet connection to hack. Most hacking isn't real time anyways; you use robots and scripts to do the leg work because they are more precise than humans. If the robots you send in to do the job are well coded then they won't forget things when they're tired and they won't get caught.

This means that you can hack a target over the crappiest network connections available. If you can get enough bandwidth through whatever series of relays and anonymisers you are using to your virtual machine on Amazon, then you can use that virtual machine to issue all the commands you want. It has great network connectivity. You just need to pass it some text and the occasional script file.

You probably need a lot more downstream bandwidth than upstream, because you need to comb through directory listings, the results of searches and filters, etc. This, however, is still all text and you can still functionally push it through a wet string. It should be pointed out that today's satellite connections are more than up to the task of this sort of work.

The network connectivity to do the recon portion of the exercise is orders of magnitude higher, but it also isn't time sensitive. Data that's exfiltrated can be stored and manipulated in the public cloud, to be slowly downloaded over crappy infrastructure at the attacker's leisure.

All of the above should serve as a lesson – hopefully more of a reminder – for those who are defending. Good attackers try to hide in plain sight.

Network defence focused solely on keeping the bad guys out will fall to any remotely skilled crew. Proper defence is going to rely on catching them once they've managed to get past the outer defences, and on preventing them from extracting any payloads once they're in. ®

Read PART 2 of this blog here.