Detecting Intrusions

Computer Security Lecture, Dr. Lawlor

Over the past few classes, we've seen the incredible tools available to attackers. To understand how an attacker might use those tools for an attack, in 2016 Phineas Fisher published a detailed explanation of his recent attack on Hacker Team. (He sees himself as a good guy; the law sees him as an international cyber criminal. I'm most concerned about the innocent bystanders and unintended long-run consequences of hacking every organization somebody perceives as bad.)

This lecture focuses on defensive tools and strategies.

The key overriding defensive strategy: gather information. It's tempting to knee-jerk reboot or start killing processes (especially when you see a CMD.EXE that you didn't start!), but killing the shell is useless if the original hole is still present, since the attacker will just break in again the same way. And worse yet, responding too soon will:

Alert the attacker that you're on to them. They might respond with a simple disk wipe, to clean up their traces.
Make it harder for you to determine how they got in, and what they've been doing.

Instead, your goal as a defender is to understand the attacker:

How did they get in?
What other access have they gained?
What information did they compromise already?
What do they intend to do?

Defense: Analyze Filesystem for Known Bad Patterns

Traditional signature-based malware detection tries to match files and network traffic against known-bad stuff. This was effective against traditional fixed-format viruses, and is still a reasonable tool, although it's less effective now than it was 20 years ago.

Online file scanners like VirusTotal have easy to use interfaces for scanning files. They're run by malware analysis vendors, who gain fresh samples of malware by offering the interface to the public. One downside is tools that upload lots of stuff to a file scanner are themselves introducing an information leak.

Countermeasures:

Polymorphic vectors: tools like metasploit make it easy to craft randomized (polymorphic) attacks, which won't match a fixed signature. Some parts of some attacks are still difficult to make polymorphic, since for example the best rop gadgets are at fixed offsets, although ASLR makes even those gadgets move in memory.
Encryption: no scanner will detect malware inside encrypted files or unmounted encrypted filesystems.
Antiforensics: sophisticated attackers will leave no trace of their activity on disk. They do this by wiping event logs (metasploit meterpreter: clearev), and using reflective DLL injection to migrate between processes in memory at runtime (meterpreter: run post/windows/manage/migrate). This means there won't be suspicious entries in the process list like shells or "malware.exe" running. If you look at Process Hacker or /proc/<pid>/maps you may notice something unusual, but these both require extensive experience to distinguish the weird from the commonplace.

Defense: Analyze Network for Known Bad Patterns

Signature-based intrusion detection systems like Snort look for known-bad patterns on the network.

Countermeasures:

Polymorphism in attacks is a problem for network scanning, exactly like file scanning. A competent attacker's tools will not be listed in any existing database.
Encryption: if your machines use HTTPS, you can't see the bad stuff traversing the network. Some enterprises or security products backdoor their own machines with a bogus HTTPS root certificate so that they can successfully proxy SSL traffic, called "SSL inspection" (which has its own risks).

Defense: Analyze for Known Good Patterns

Generally, it's much safer to list the things you know are good (e.g., emails from @alaska.edu domains) than the things you know are bad. Things not known to be good can have extra scanning, logging, or security alerts added to them. (Chrome on Windows says "This exe is not commonly downloaded and could be dangerous." if it's not in the list.)

Defense: Firewall and Log Outbound Traffic

The attacker's job is much harder if outbound traffic is limited or heavily monitored. However, it is tricky to set up firewall rules so they don't break good traffic along with the bad. And manually checking network traffic is quite labor intensive.

You can get a quick look at the total network bytes on a given machine with ifconfig:

$ ifconfig wlp60s0
wlp60s0   Link encap:Ethernet  HWaddr 34:f6:4b:86:fe:43  
          inet addr:10.0.0.22  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::e8b3:b8f6:7025:e1e2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2526532 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1304562 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2527017440 (2.5 GB)  TX bytes:169022625 (169.0 MB)

Notice the RX and TX lines at the bottom.

Many data breaches are only detected post-exfiltration, because several terabytes of encrypted data just left the company. But if you don't know you've been got 'till it's gone, it's too late.

Defense: Top Talkers

The IT department at most universities keep a list of "top talkers", internal IP addresses that have used the most network bandwidth each day (up or down), and they check this traffic by hand. If it's a research project or other legitimate use, they ignore it (either for that day, or semi permanently). If it's coming from a dorm room or random other machine, they block that machine.

This is important because the huge bandwidth available from many university networks (especially huge when students are not on campus). The bandwidth attracts people that want to perform:

Denial of service attacks
Spam distribution
Distributing illegal or copyright infringing content
Botnet command and control infrastructure

The university doesn't want to be (1) publicly associated with these things, (2) legally liable for these things, or (3) forced to pay bandwidth to support these things.

Back around 1999 at Illinois I made it onto the day's top talkers list by backing up my hard drive across my in-room dorm network which used a dumb Ethernet switch. My dumb switch blasted the packets out to the wall, and the script on their Cisco router counted those packets as "hitting the university network", even though it never routed them.