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:
Instead, your goal as a defender is to understand the attacker:

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. 


Defense: Analyze Network for Known Bad Patterns

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


Defense: Analyze for Known Good Patterns

Generally, it's much safer to list the things you know are good (e.g., emails from 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: Bcast: Mask:
inet6 addr: fe80::e8b3:b8f6:7025:e1e2/64 Scope:Link
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:
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.