I have now completed the first course in my queue! Since the last post, I have been digging into website hacking. This is of course a big area and a massive element of day-to-day information security. I went through various avenues and implementations of SQL injection attacks, XSS (Cross Site Scripting) attacks, and more. I also learned about protecting against these sorts of attacks, and had a brief introduction into how vulnerability scanning can be automated with scanning tools. Of course, once you have your scan output ready, put it into Dradis and produce a custom no-fuss report!

Trying out the SQL injection procedures was based on attacking a fake vulnerable web server in Metasploitable. Insecure database calls in SQL on a website or web application can let attackers extract or modify information, or grant access even without passwords. An SQL injection vulnerability on one site can potentially undermine the security of all sites and applications hosted on that one web server. As the instructor said, if there is an SQL injection vulnerability on the target site, bingo, game over, you as an attacker can ultimately do virtually anything you want with that site.

With XSS vulnerabilities, you essentially insert scripts to run from a site. As an example, there may be a commenting feature on a web page with an XSS vulnerability, which means that this XSS script would run for all visitors to that page. What makes this insidious is that the script would run for visitors to the page, as it’s not part of the base web page. An insecure website could therefore jeopardize the security of third parties – and therefore, owners of web pages, web applications, and web hosts have a responsibility to protect their sites so third parties are not affected.

The course closed with a very brief introduction to ZAP (Zed Attack Proxy), one of many tools to automate scanning for vulnerabilities. The point of this course was to show the theory behind security vulnerabilities, and the sort of attacks that can be carried out by hackers. Now that I have been introduced to the nuts-and-bolts, step-by-step methods of attacking devices and applications, the path is open to learning more about particular focus areas and to think about scripting and automation. I do have some more studies coming up to these ends. I intend to learn more about hacking using Android, I need to learn more about networking vulnerabilities, and I would like to learn more about scripting and vulnerability scan automation through software like ZAP and Burp, both of which have official Dradis plugins. I already manipulate their plugin outputs most days when building Dradis templates, so it would be fun to create those outputs as well!

Lately I have been looking into the details of hacking through networks, and post-exploitation attacks. The idea was to get beyond the idea of trying out attacks on a second VM on the same device, or another device here at home, to the principle of hacking devices on other networks.

First up was freshening up on the basics of networking. From the “information gathering” step I should have multiple ways of potentially feeding backdoors to the target device. Then there was an exercise of doing so, using BeEF – essentially the same exercise as before, with only some minor changes to function with the outside network. That demonstrated the principle, so we moved on to a look at post-exploitation attacks.

Post-exploitation attacks were run with metasploit through veil-evasion. That generated a robust connection with meterpreter that should be essentially undetectable by antivirus programs. The challenge is of course to manage the original connection, but with that accomplished, meterpreter allows all sorts of scripts to be run as well as terminal access.

In effect, that meant running all the sorts of attacks that people should be paranoid about; keylogging, capturing screenshots of the target device, controlling the camera and/or microphone, altering the files on the target device, and so on. Fun! Metasploit has so many functions and capabilities that going through them in detail was beyond the scope of this course.

Now that the possibilities of post-exploitation attacks had been made clear, the course moved back to networking, to cover pivoting. Pivoting allows hackers to target other devices in the same network as an infected device. Even if the hacker’s device has no access to the final target devices, if they can attack a device in the same network as the final target, they can route their attacks through the infected device. That is another cool exploit, and hammers home how important security is on servers and routers.

As the course progresses, I believe I get a far better understanding of our Dradis users’ use cases. When I build custom Dradis templates and configure projects, of course there’s always some variation of issue descriptions, screenshots, and usually evidence output. These post-exploitation attacks and network penetration efforts are exactly the sort of vulnerabilities that Dradis is set up to report, and screenshots of my work would make good evidence output.

I do feel that in the last weeks’ studies I have been heavy on the theory and observation, but light on actual practise. I intend to set up a few devices and VMs to practise attacking, and I have permission to try to attack some other peoples’ personal devices. Let’s see how that goes; beyond that, the rest of the current course covers website hacking, which will also be fun!

Lately my studies have gone over email spoofing and hooking browsers using BeEF. Email spoofing in itself is easy enough, with editable “from” fields in many email apps, but I learned a few new cool approaches to make the spoofing far more accurate, enough to fool Gmail. Browser hooking is very cool, it’s frankly shocking to see just how much can be done to a victim’s device just through a browser. Then I consider that Chromebooks are basically a PC running through a browser. The trend is definitely to make browsers even more central to electronic device usage, and I’m not convinced that the work taking place for improved browser security is commensurate with the needs for it.

Most of this Social Engineering section has been based around one simple trojan, easily created and capable of bypassing antivirus programs. Whether it’s through spoofed emails, browser redirection, fake updates, or other BeEF tricks, the delivery of the trojan has been simple. The approaches are also fairly convincing on the face of it – getting someone to open a zipped .pdf or .png which is secretly a trojan is not hard when they are convinced it comes from someone they know and trust. At first approach, the browser hooking techniques I have seen appear a little more crude and unsophisticated – why would Firefox need to redirect you for an update, for example? – but could definitely work on more casual users. Phishing login data through a fake login window is still effective, especially when it’s from a frame in the user’s current page and doesn’t involve a redirect or an obviously fake URL in the header. Capturing screenshots, and even commandeering the webcam and microphone, is of course far more insidious and unlikely to be detected once the browser is hooked.

My main takeaway from this so far is that I’m gaining a lot more respect for proper preparation work in information gathering before making the first attack. Proper research with Maltego, or just careful use of Google and social media, clearly make an attack far more likely to succeed. As I’ve noted before, this suggests we should all be far more protective of our data and privacy – but how realistic is that really in the modern age, when simply applying for jobs or keeping in touch with your friends all but requires social media accounts?

I’m also surprised at the suggested measures for detecting trojans like the ones I have made – far too manual, like checking file properties. Fortunately the OSes I use will not run malicious code without my active consent, but the way I had my Windows rig set up (back when I had one) would be far more vulnerable despite the firewall, antivirus, and VPN.

Next up is some more work on networks, e.g. for using BeEF outside the user’s network, and then going into post-exploitation attacks in more depth. Fun!

This week my studies took a bit of a left turn into Social Engineering.  Whereas everything else so far was technical in nature, using and abusing hardware and software issues and their vulnerabilities, the most recent classes covered the most defective element of any security system – the meatbag in front of the monitor.  PEBKAC indeed!

In terms of systems, I got started with Maltego CE.  The interface is very user-unfriendly, but with the right walkthrough and plugins, it’s the tool I never knew I wanted!  By doing plugin-based searches on all sorts of media on nodes such as persons, websites, servers, and so on, it becomes possible to draw intricate networks of connections between nodes – like a conspiracy theorist’s corkboard, only for cyber-stalking.  Fun stuff!

Next up on the technical side was spoofing to bundle malicious code with a legitimate file and obscure the executable extension, as well as spoofing emails and accessing email servers to send spoof emails without getting immediately flagged as spam.

The downside of this part of the course is that it feels like it’s stretching the concept of “ethical hacking” to the limits of what can be considered “ethical”.  If I spoof a VM, or a real device with the owner’s permission, for the sake of attempting a man-in-the-middle attack, I’m not hurting the device’s feelings.  To even test out a social engineering attack I have to try to fool someone.  I have no problems with pushing the limits of what I can find out about an entity online through publicly accessible information, as the entity in question can use that data for good (e.g. improving their personal privacy by restricting apps’ access to their data), but getting someone to “click here” feels too close to Nigerian royalty.

Even so, the shock value of a successful engineering attack can have positive effects in the sense of raising awareness.  A BBC journalist agreed to let a cyber-security firm try to phish him, and they succeeded.

Did you click that link?  Considering the subject of this post, did you even check if it was legit?  This time it was – but what if it hadn’t been?

This week I got started with Veil.  By using this software together with other techniques from the course, I could open backdoors to target devices in short order.  There are two clever aspects to the approaches used.  First, I was forcing the client device to connect to my Kali VM to execute the attack, rather than me connecting to the target directly.  This approach sidesteps the typical defences in regular firewalls and routers.  Second, the payload delivery was made to spoof the download of genuine updates, with redirects to the appropriate “Update successful!” pages once the download was complete.  Alternatively, the payload could be set to be delivered together with any other download of an executable file.  It could also be combined with the use of your own web server, which comes conveniently included with Kali.

I haven’t yet played around with all the things that can actually be done once this backdoor is open, but ultimately, it looks like all that is required for me to get complete access to another device are fairly innocuous things – using a WiFi hotspot I set up, or clicking a link, or attempting to update their own software.  Even more striking was the demonstration that the Veil software payloads were considered “clean” by all antivirus software.

Much like “Defense against the dark arts” classes, the sequence of lectures on attack methods and vectors ended with a lecture on how to defend oneself against these sorts of attacks.  Worryingly, these again boiled down to:

1. Always make sure you’re using HTTPS
2. Don’t use networks you don’t control and/or trust completely
3. Verify checksums of all your downloads

These measures are all more active than convenient.  “I think the base consideration of one’s security is insufficiently paranoid unless one is optimistic enough about their fellow humans to not believe that anyone will go to the effort of trying to steal their data.”

There might be a point there, though.  Why bother stealing data when most people give it to Google, Apple, and Facebook for free?

Now I have got into vulnerability testing tools from the users’ perspective!  This week I set up a Metasploitable machine, to use Metasploit from my Kali VM to scan for vulnerabilities and generate tool output.  It’s very cool to see how Metasploit had writeups on the individual vulnerabilities and procedures to exploit them right from the command line.

Even cooler was Nexpose.  Again I got a solid overview of the sort of vulnerabilities found and how they could be exploited.  By referring to material outside the Metasploit Community, it feels very connected to the wider InfoSec world out on the internet.  The automatic report generation and automated scans were also handy features.

I have been working on some improvements to the base Dradis CE application this week as well, so this tied in neatly with the studies.  I have only just started with tool output generation, and already I’m manipulating data from Metasploit, Nexpose, and Nmap, all of which are supported in Dradis.  Now that I’m getting the actual user’s view of tool usage I can better put myself in the shoes of hackers starting out with Dradis for the first time to generate customised reports using data from multiple sources.

Having spent so much time with Dradis Pro, it’s fun to get back to basics with Dradis CE.  I’m not bothered by not having access to Word templates.  I gave up using Windows years ago, even my Steam library wasn’t worth the hassle of dealing with it – and I think there’s a lot of potential in well-made HTML templates.  For my purposes, learning and experimenting at home, and showing off to the people at the sailing club bar, it’s a good tool to play with; scan with all the tools and plug all the results into a simple collated report.

Next up in the course is client-side attacks; technical exploits as well as the social engineering exploits of the PEBKAC vulnerabilities!

The view from the bar