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.

Other stories you might like

  • Stolen university credentials up for sale by Russian crooks, FBI warns
    Forget dark-web souks, thousands of these are already being traded on public bazaars

    Russian crooks are selling network credentials and virtual private network access for a "multitude" of US universities and colleges on criminal marketplaces, according to the FBI.

    According to a warning issued on Thursday, these stolen credentials sell for thousands of dollars on both dark web and public internet forums, and could lead to subsequent cyberattacks against individual employees or the schools themselves.

    "The exposure of usernames and passwords can lead to brute force credential stuffing computer network attacks, whereby attackers attempt logins across various internet sites or exploit them for subsequent cyber attacks as criminal actors take advantage of users recycling the same credentials across multiple accounts, internet sites, and services," the Feds' alert [PDF] said.

    Continue reading
  • Big Tech loves talking up privacy – while trying to kill privacy legislation
    Study claims Amazon, Apple, Google, Meta, Microsoft work to derail data rules

    Amazon, Apple, Google, Meta, and Microsoft often support privacy in public statements, but behind the scenes they've been working through some common organizations to weaken or kill privacy legislation in US states.

    That's according to a report this week from news non-profit The Markup, which said the corporations hire lobbyists from the same few groups and law firms to defang or drown state privacy bills.

    The report examined 31 states when state legislatures were considering privacy legislation and identified 445 lobbyists and lobbying firms working on behalf of Amazon, Apple, Google, Meta, and Microsoft, along with industry groups like TechNet and the State Privacy and Security Coalition.

    Continue reading
  • SEC probes Musk for not properly disclosing Twitter stake
    Meanwhile, social network's board rejects resignation of one its directors

    America's financial watchdog is investigating whether Elon Musk adequately disclosed his purchase of Twitter shares last month, just as his bid to take over the social media company hangs in the balance. 

    A letter [PDF] from the SEC addressed to the tech billionaire said he "[did] not appear" to have filed the proper form detailing his 9.2 percent stake in Twitter "required 10 days from the date of acquisition," and asked him to provide more information. Musk's shares made him one of Twitter's largest shareholders. The letter is dated April 4, and was shared this week by the regulator.

    Musk quickly moved to try and buy the whole company outright in a deal initially worth over $44 billion. Musk sold a chunk of his shares in Tesla worth $8.4 billion and bagged another $7.14 billion from investors to help finance the $21 billion he promised to put forward for the deal. The remaining $25.5 billion bill was secured via debt financing by Morgan Stanley, Bank of America, Barclays, and others. But the takeover is not going smoothly.

    Continue reading

Biting the hand that feeds IT © 1998–2022