Table of contents

2.1 Given a scenario, conduct information gathering using appropriate techniques.

Now , just in case there are some brand new beginner hackers out there, the “information gathering phase” of an attack, formerly known as reconnaissance , isn’t just at the first phase, but we do it throughout - but the type of information gathering that a tester will do is very passive - unless it’s a white box, which makes this stage largely irrelevant…

We shall be building up our knowledge base and researching throughout, but what we want to do first is see how much we can find out using public databases, websites, blog posts etc. From the perspective of a black box tester, Open Source Intelligence Gathering (OSINT) is a crucial stage for two reasons: The first is that we don’t have any access to company information otherwise, so any and all data is useful to us; moreover this means that without OSINT we wouldn’t be able to gather data about the client without being intrusive - which we want to limit as much as possible - as a black box tester is supposed to be a surprise to a network… a failed black box test ends up turning into a weird grey box.

Depending on how liberal the company is, we might not find things like the organisation’s systems data, specific technology or network diagrams but I will show over the course of this chapter that there are many diamonds in the rough! The pentest-standard manual lists three different types of OSINT : Passive, Semi-Passive and Active. The first being the information which is pretty much non-traceable to the client organisation , but this tends to mean we only use archived or stored information, which can be out of date or plain incorrect. Semi-Passive is where we are going onto corporate websites and looking at published documents , in as much detail as possible without having the traffic attribute to anyone in particular. Lastly is active information gathering, which is port-scanning , brute-forcing directories on their website - hardcore stuff. After we build up our repository of knowledge, we conduct what’s called enumeration , which is where we narrow down our targets, whether it be from a list of users, networks, domains etc (scope obviously playing a large role in this activity).

Some of the resources that we may turn to for OSINT:

• DNS registrars: Find out where their email servers are , have they registered the domain correctly, are they using some sort of load balancer - and thereby having many available web servers which we might’ve otherwise missed. Some of these servers may have sensitive information attached to them, but as this information is all public and we haven’t actually made tried communicating to those servers we are still perfectly fine and within scope. This is why OSINT is so important as it makes us aware of where we could go off track. Two really good tools for snooping around public DNS databases are dig and the even bulkier dnsenum which will need a good few hours to run, as it searches for all the subdomains, mail servers and what not , which against a big corporate client will be a historical gold mine.
• Web searches. Using powerful tools like the Wayback Machine can allow you to scroll back to older versions of a website, and you can see some of the older designs , vulnerabilities present there and use those ideas to test against the current version. Search engines like shodan and censys are security-centric and give you search results for a given IP address, OS type etc that it has found to be compromised. Social media, public company tax filings and reports, company websites can all be lucrative.
• Information about vulnerabilities can be seen on public databases like exploit-db.com and this saves us from actually having to intrude; but on the flip side we often seen very old vulnerabilities on there, and the cutting edge isn’t released until months after.

The MITRE corporation is a US not-for-profit corporation that performs federally funded research and development. Among the tools it has developed or maintains are a number of classification schemes useful to penetration testers:

The Common Attack Pattern Enumeration and Classification (CAPEC) list is a resource intended to help identify and document attacks and attack patterns. It allows users to search attacks by their mechanism or domain and then breaks down each attack by various attributes and prerequisites. It also suggests solutions and mitigations, which means it can be useful for identifying controls when writing a penetration test report. Reading through CAPEC can also help testers identify attack methods they may have missed, and it can also be useful for developing new attacks. CAPEC can be found at https://capec.mitre.org .

The Common Vulnerabilities and Exposures (CVE) list identifies vulnerabilities by name, number, and description. This makes the job of a penetration tester easier, as vendors, exploit developers, and others can use a common scheme to refer to vulnerabilities. A CVE listing will be in the format CVE-[YEAR]-[NUMBER]. For example, Spectre is covered by CVE-2017-5754 and CVE-2017-5715.

The Common Weakness Enumeration (CWE) is another community-developed list. CWE tackles a broad range of software weaknesses and breaks them down by research concepts, development concepts, and architectural concepts. Like CAPEC, it describes each weakness and how it can be introduced to code, what platforms it applies to, and what happens when something goes wrong. Also like CAPEC, it includes mitigation suggestions. You can read more about CWE at https://cwe.mitre.org .

Aside from centralised databases there are also many mailing lists pen testers can subscribe to so as to stay ahead and get the very latest in the cybersecurity industry. Twitter is pretty much the de-facto for this, but never the less places like Full Disclosure , the Internet Storm Center (ISC) and the SANS Pen-Testing Blog.

Active Reconnaissance and Enumeration

Now that OSINT has been sufficiently gathered, we move to a more active stage and the techniques for each of these may vary , so you will need to be familiar with each of the following methods.

Typically when we think of enumerating hosts on a network we think about just running nmap and letting it do the work the work for us; however, whilst an active scan will identify many hosts, it will miss all the systems that don’t respond - but that doesn’t mean they aren’t existent they are usually the more valuable systems that have configured more securely. Moreover, in order to make sure we build an accurate and sophisticated “attack vector topology” we need to employ other methods. Another thing we can do is leverage central management systems , which is a piece of software that oversees and regulates a cluster of devices, from being as simple as a parent controlling their children’s IPads to a organisation’s department regulating employee PC’s - they offer a huge treasure trove of information - their IP addresses, domains , versions , OS type etc. Obviously breaking into this is game over, and it is unlikely that such systems would be compromised early doors - but saying that here is a pretty bad vulnerability for Jamf Pro and if were to socially engineer ourselves a user account , then we would be able to retrieve the management data… Aside from this, there are also network logs , configuration files from DHCP servers, switches, routers etc can all hold valuable network information.

In a black box test, you typically won’t be able to get this type of information until later in the test, if you can capture it at all. That doesn’t mean you should ignore it, but it does mean that port scanning remains the first technique that many penetration testers will attempt early in an engagement.

Next up are services, which means looking at the open ports on a server - port 22 meaning SSH is open for example, 389 for LDAP etc. A port scanner doesn’t just work for testing IP ranges, it can send specially crafted messages to servers to establish all open ports, and to go further and to identify the service at that port. If the corporation is slacking we may be able to attach some scripts to our port scanner that searches for the version of that service in their response. Service and version detection can be done in one of two ways: either by connecting and grabbing the banner present at that port , or by comparing its responses to the signatures of known services. Lastly, if the services come out secure but the server itself who we’ve been talking to is inadequately secured then we could pull the Operating system, its version and other banners. The way we do this is by seeing the subtle differences in how Operating Systems respond and their packets over the TCP/IP stack can glean the OS itself and even distinct operating system versions - depending on if that service got particular updates during , say , Windows 10. The order in which they send packets , the TCP/UDP options they support and a host of other slight details can edge us closer to understanding our target. The different ways in which a server responds, either because of the web server sitting on top, its version , or the OS etc is called its fingerprint, and when we banner grab services with nmap or websites with nc (netcat) . If there is a webserver we want to query we can do it like so:

root@kali:~# nc 10.2.5.80
GET / HTTP/3.0

;; so nc opens a prompt for us to query, and the results should be the HTML page for /

We could’ve also done this using nmap -sV 10.2.5.80 but oh well. The exam objectives also mention token enumeration, but capturing and using tokens is typically done further done the line in exploit activities. Tokens are often used after a server has been compromised and we want to elevate the privileges of a given user. For examples of this see here and here:

The next thing we need to enumerate are the company wired/wireless networks, their network topology and their network traffic - and as you can probably guess this can take a long time. A topology map can give a tester a good idea about what devices are likely to be accessible, what the subnets are, network devices, where the DMZ is etc. The topology map created by tools like zenmap aren’t always accurate as the internal subnets may not route your packet to them, as they most likely have increased security controls and drop the packet. Moreover we may just be seeing the “public topology” which isn’t as valuable. Testers will also gather information using eavesdropping with packet capture or sniffer tools. Tools like Wireshark are often used to passively gather information about a network, including IP addresses, MAC addresses, time to live for packets, and even data about services and the content of traffic when it is unencrypted. For snooping wireless traffic specifically, Kismet is also popular as it provides the functionality to find hidden SSIDs , passive association of wireless clients and access points, and a variety of tools to help decrypt encrypted traffic.

Another method of gathering information about network devices is to conduct an SNMP sweep. This usually requires internal access to a network and thus may not be the first round of active reconnaissance, but if we can find the community string (a header comprising the user credential - ID or password) and so it allows other networked devices to authenticate and pass network data to that device. There are three types of community string, and they are read-only - meaning we can only extract, read-write which means we can also alter device configurations, and SNMP Trap which is used an SNMP message is sent by a networked device to the management server. There are four possible reasons a lack of response may occur: you may have the wrong community string, the system may be unreachable (firewalled or offline), the SNMP server service may not be running, or the fact that SNMP uses UDP is working against you and the response wasn’t received yet—and may never be received at all! None of this means that you shouldn’t attempt an SNMP scan of a network to gather information. It simply means that you may need more preparation before using a scanning tool. Once you have the information you need, SNMP scans can greatly help improve your network topology map and device discovery. If your target supports SNMP, and you have the appropriate community string, you can use snmpwalk to enumerate users as shown below using public as the community string and 10.0.0.1 as the target host. The grep and cut commands that the snmpwalk output is piped into will provide the user with information from the overall snmpwalk output.

snmpwalk public -v1 10.0.0.1 1 | grep 77.1.2.25 | cut -d "" -f4

Packet crafting and inspection.

The inverse of capturing sent traffic, is for the system to capture our crafted packets, and with tools like hping we can do just that. By going for a more granular approach, we can fragment packets, or modify legitimate packets with our own payloads. There are four typical tasks that packet crafting and inspection may involve:

• Packet review and decoding of given formats, looking for headers, keys etc.
• Assembling packets from scratch
• Editing existing packets to modify their content
• Replaying packets.

So then, we can practice sending some TCP SYN packets to a remote system by doing:

;; -S for SYN packets, -V for verbose , -p for port.
hping -S -V targetsite.com -p 8080 

When we use Wireshark for packet inspection, it is vital that you enable the monitor mode functionality, so any packets flying through the air or on the switched network can be read by you - but this functionality was for a long time limited to Linux as the Windows Pcap library only allowed traffic that was destined for you, and not to enable eavesdropping - this was even true for Kali VMs that ran on an underlying Windows architecture! Nowadays though you have things like npcap which was an API developed for Windows to fix this precise issue.

Enumerating Users and finding specific accounts

As companies get bigger they often find themselves needing a simple, centralised storage of user accounts and privileges so that they can start to categorise and manage it all. Services like LDAP, SMB , SNMP are all geared towards making management easier, but as a tester we now gain more for each exploitation. In many organisations, user accounts are the same as email accounts, making email user enumeration an important step.

OSINT may play a big role here then as the emails might be leaked on public forums, social media platforms or older web versions. Because of this we can start harvesting for emails, employee names , subdomains , host information etc from open ports and banners. A tool called theHarvester is a program designed to gather from these sources using search engines (Google, Shodan etc) and other sources. Metasploit has a similar functionality with a demonstration below:

msf> use auxiliary/gather/search_email_collector
msf auxiliary(search_email_collector) > set domain wiley.com
domain => wiley.com
msf auxiliary(search_email_collector) > set outfile wiley-list.txt
outfile > wiley-list.txt
msf auxiliary(search_email_collector) > exploit

...Harvesting emails
...Searching Google for email addresses
...Extracting emails from Google, Bing and Yahoo search results
...Located X email addresses for wiley.com , writing to outfile. 
...Module completed.

Social media enumeration will become an increasingly lucrative form of engagement, and we can look at trying social engineering attacks or password cracking attempts. Going back to vulnerable services , we look at User groups. Groups come in many forms, and we may demarcate them with Microsoft’s Active Directory service, LDAP, and within applications and service management interfaces. I mentioned earlier that the point of OSINT, reconnaissance and scanning is so we can get that standard user account to start, as some vulnerabilities like the Jamf Pro vulnerability become applicable. If we can get an account then it provides an easy way to gain additional privileges , but to do so may imply having to cross many hurdles and use many different exploits.

Shares

Enumerating Samba (SMB) shares seeks to find all available shares, which are readable and writable, and any additional information about the shares that can be gathered. SMB scanners are built into a variety of vulnerability scanning tools, and there are also purpose built SMB scanners like smbmap . nmap includes the smb-enum-shares and smb-enumusers NSE scripts as well.

Web Pages and Web Servers

Both of these are susceptible to crawling , either for other harder-to-find web pages, or directories etc. Often times testers use tools like Burp Suite , OWASP Zap as their web testing tools of choice, as they can act as a proxy and intercept traffic between the tester and client - which is great for understanding how the web forms work.

Cryptography

The certificates that an organisation’s websites present can be enumerated as part of an information-gathering effort. nmap can gather certificate information using the ssl-cert NSE script, and all major vulnerability scanners have the ability to grab and validate certificate information. As you might expect, web application vulnerability scanners also specifically build in this capability. Knowing what certificates are in use, and if they are expired or otherwise problematic, can be useful to a penetration tester because out-of-date certificates often point to other administrative or support issues that may be exploited. Certificates are also used for users and services and may be acquired during later stages of a penetration test. User and service certificates and keys are typically tracked as they are acquired rather than directly enumerated.

Check out this incredible guide on checking for insecure SSL/TLS connections here.

Source Code, Debugging and Decompilation

The source code, scripts, and even compiled code that underlie an organisation’s systems, services, and infrastructure are also very useful targets for a penetration tester. Analysing code as part of an enumeration and information-gathering exercise can sometimes be forgotten because it requires a different skill set than port scanning and other active information gathering. As a penetration tester, you should remain aware that code often contains useful information about targets, ranging from usernames and passwords embedded in scripts to details of how applications connect and how data is organised in databases in web application calls. The most accessible information in code is often found in scripts and other interpreted code (that is, code that is run directly instead of compiled). Most scripts and interpreted code may not be accessible during the initial active reconnaissance of an organisation, but once you have bypassed outer layers of security, you are likely to recover code that you will need to analyse.

When testing an actual application , for which we have the compiled binary for, we need to revert it back into readable code again before we can review it: and this can be done with a decompiler. It tries to provide as much readable source code as possible, but some instructions can be ambiguous and there will be some trial and error as 10000101100 can be split into many different equivalent instructions for example. A shortcut that can provide some quick and dirty data is to use the strings utility in Linux which recovers text from compiled code. If you’re reading this via Kali , you can look at any binary you may have like nc and run strings nc against it… Strings is often useful during malware analysis once malware has been decoded from various packing methods that attempt to obfuscate the code, but for most common compiled binaries, you can simply run strings against the file to gather information.

Now assuming we have the source code we can use a debugger to review the code as best as possible and having that granular control over processes is integral to figuring out where the cracks are. You will see me reiterating this formula a lot over the course: Information gather , acquire and test data and the system with captured data, control system and acquire control over processes (step up from, and in addition to data) , test processes and find cracks to isolate and control entire system (and thereby the processes, and thereby the data). Now debugging and decompiling are acts that hardly any tester will be conducting early on in their enumeration phase, but when we further our enumerative efforts, we may find such programs, or if our job is to test a desktop application then this would be pivotal. The reason it’s included is because we would gather a lot of information from debugging and decompiling, hence it’s in the information gathering chapter.

Eavesdropping

RF communication monitoring - so the use of Bluetooth scanners, getting in range.

Sniffing. Intercepting packets and inspecting their contents. For wired connections, wireshark and tcpdump are best. For wireless , aircrack-ng is best.

Defences against Active Reconnaissance and Information Gathering

Basically we want to stop scanners being able to freely learn about our systems, and so our outer-perimeter network nodes need to be hardened, but as long as they still need to show some services to the outside world they remain a target. A few defences though include:

• Reducing the number of services to those that absolutely must be exposed.
• Using an IPS or similar defensive technology that can limit or stop probes to prevent scanning
• Using monitoring and alerting systems to alarm on events that continue despite these preventative measures

Most organisations will prioritise detecting active reconnaissance on their internal networks, and organisations with a strong security policy prohibit and monitor the use of scanning tools. Active defences may block or disconnect systems or network ports that conduct active reconnaissance activities, so monitoring your own efforts for signs of detection is critical.

Organisations have a much harder time preventing passive information gathering, as it relies on controlling the information that they release. Each passive information-gathering technique we reviewed has its own set of controls that can be applied. For example, DNS anti-harvesting techniques used by domain registrars can help prevent misuse. Other DNS protection techniques include these:

• Blacklisting systems or networks that abuse the service. Remember we use a black list because we do want as many people as possible to use the service, and we just need to be aware of the few that abuse it.
• Using CAPTCHAs to prevent bots.
• Providing privacy services that use third-party registration information instead of the actual person or organisation registering the domain.
• Implementing rate limiting to ensure that lookups are not done at high speeds.
• Not publishing zone files if possible, but gTLDs are required to publish their zone files, meaning this only works for some ccTLDs.

Other types of passive information gathering require a thorough review of exposed data and organisation decisions about what should (or must) be exposed and what can be limited by either technical or administrative means. Most of the time the organisation probably won’t realise the content on its website, its social media is actually a problem, as it is part in parcel of selling yourself and marketing. Though it gets to a point where the degree of private data being exposed is excessive, nevertheless there are tools like the Wayback Machine which keep these archived imperfections and employees may have personal blogs etc where work emails get leaked …

2.2 Given a scenario, perform a vulnerability scan.

So, by this stage we should have a list of IP addresses, networks and targets - achieved either by OSINT, active reconnaissance , or if it’s a white box nothing at all , but regardless of how we got here we need to examine the targets to identify if they hold any known weaknesses. Here comes the vulnerability scan. There are many different types of scans:

• Credentialed scans, provides the scanner with the usernames and password necessary to go into an account, a computer or server and run further tests - though these can be more damaging. The more credentials we feed a scanner, the more in depth the results.
• Non-credentialed (non-authenticated) is a simpler scan that uses anonymous access to exposed resources, like guest accounts, and the residual functionality for any newcomer. This good be the landing page and a couple others that are available to onlookers, of which there may be XSS vulnerabilities in the forms or something. This type of scan is usually employed earlier in the process of analysis.

Onto the potential purpose of a scan:

• Discovery scan. This is the first scan we have to run before we begin identifying vulnerabilities and this may be as simple as nmap -sP 10.10.45.110/24 .
• Next, we want to run identify the ports, services, operating systems with their versions and vulnerabilities. nmap -A 10.10.45.115 may be a target, and the -A will run OS , services and version identification , alongside traceroute and any default NSE scripts. Of course, too much noise at once for any practical test, but for CTFs it may be a good shortcut option.
• Port scans are a reduced version, and this is the first sub-scan that we do , just to see where our avenues of attack will be. This can be done with nmap -p 22 10.10.45.110 for example. When we attach the flag -sS it will connect to this port via a TCP SYN packet, and if the server responds with a SYN/ACK then we just send back a RST and the connection is closed. This is fast and quiet, but you could do -sT instead which would establish a full connection to each target, if you wanted more data from them. The former is called a stealth scan, whereas the latter is called a connect scan.
• Lastly, there is the compliance scan where the purpose is to identify specific vulnerabilities that would give clear indications of a system being non-complaint.

Considerations of vulnerability scanning

Remember when I said earlier that we may be able to scan at certain times of the day only, so that we can avoid the risk of throttling the system , this would impact our ability to conduct what’s called dynamic analysis and this is where we rely on the system being active and responsive as the data our scanner will be comparing to exploit databases etc will come from live assets; whereas static analysis is to do with scanning artefacts, like log files , snapshots of servers etc for similar sorts of information - and this is completely ambivalent to whether the actual services are running or not by the time we look at the files. So this is what you could do when waiting for your “testing time” to arrive. On the topic of time, when we’re planning all of our tests some may take longer than others, some may finish very quickly - but this could be for a number of reasons and when we go to re-run them in front of the client or at a meeting for demonstration they could take a lot longer. During our actual testing phase, we need to think the time to run scans, about whether all our scans could overrun the approved schedule time so make sure to plan thoroughly. One last thing about planning, we may need to be aware of bandwidth limitations, if there are many targets that a scan is expected to pick up, or the scan itself is quite aggressive, then it may bottleneck the system and hence “corporate traffic”, whether this be from the internal business or clients. To limit the affect of our scans, we can reduce the number of ports hit at once, target specific (high-value) ports first and then ask less of them at once… But this no doubt take longer, but this query throttling technique may keep us in the job. We can reduce the “aggressive” option of nmap which is by default set at Tier 3 , -T3 but if we use options like nmap 192.168.1.10 -T0 then that would be very slow, few packets with spaces between each one.

Another limitation may be that the client only wants us to use certain protocols, that we may only be testing web servers, and hence sticking to HTTP. Other times, the use of FTP is banned as they don’t need/want their file servers tested. So target selection is largely based on pre-engagement agreements here. Speaking of test targets, our network topology is also affected by that contract, and the layout depth, breadth , or specific targets may be outside of our scanning perimeter. Obviously the more they warn you about , the more knowledge you’re given about the system, so it slowly morphs into a grey box. One of the biggest considerations will be for mission critical systems, which may be old and fragile. The problems with such systems are evident, but typically they are internal and under high scrutiny. So if we are lucky enough to get into the same network as it, just make sure to not throttle it with any aggressive scans!

After gaining sufficient knowledge of an organisation’s infrastructure, we may see that they use a Virtual Environment , complete with a single kernel which all employee containers use. This would save massive amounts of memory space , as each employee would probably be using Ubuntu, so you don’t need each employee to have the same underlying kernel, so this can be kept in a VM instance which starts for every employee, but the specific credentials would load a particular container. Moreover, when looking to exploit an employee account, we have to take note that we may have to grapple with the underlying layers and account for things like VM escape, container vulnerabilities and not just the OS itself.

2.3 Given a scenario, analyse vulnerability scan results.

Now that we have all our output files, vulnerability reports that go with each target, we can begin to think of them as assets: what networks are they on, what data do they hold, how good is the exploit that comes with that machine? These will all be categorised relative to the client , and it may arise that very vulnerable targets , with say a vulnerability score of 8+ would be rejected, as it’s just a virtual machine which very sparingly gets used, and the network its on isn’t the gold level. We may choose to prioritise a vulnerability that is 3 or 4 in strength if it maps to something like a database, as they have much greater value.

The results we do get though need to be checked, as the vulnerability scanner may not always be correct. Silly example , but if a computer is running Linux the scanner shouldn’t freak out and say oh my goodness there are no Windows patches! It may be that machines are patched against this, or they’re unaffected, or the exploit itself is unreliable and hence the value goes down. This process of fact-checking is called adjudication. Scanners are silly tools, and if a clever system administrator changes the banner that gets sent by a server, to change it from Windows to Linux, and to change the versions etc, then chunks of our report may be bunk…

Assuming we’re able then to verify our findings, and categorise our assets , we move to ranking our vulnerabilities , preferring of course the ones with the highest impact - the ease of exploit and the highest payoff. Always look at that which could hurt the client the worst.

Common themes whilst analysing scan results:

• Vulnerabilities. The exploit type, difficulty etc
• Observations. What network the target is on, what software they run, are they a VM,
• Lack of best practices. This ties in with the other two, but this could be keeping default passwords, using WPA, not having a clean desk policy etc.

2.4 Explain the process of leveraging information to prepare for exploitation.

So, we’ve identified targets and to categorise them into business assets we used vulnerability scanning and myriad other criteria and what’s left is to categorise and deduce their exploitation value. From all the reports and data we want to see what we will be the number one target that we shall starting cracking.

We’re going to be essentially taking our vulnerability report and looking at what types of exploit categories they fit into: are they more buffer overflow, could I use this vulnerability in an XSS attack, is it to do with SSL/TLS certificates? We then look for similar exploits , their styles , what they leveraged and gleaning from our data we start to piece together tests that we shall fire. nmap again will be a tool we continuously use to confirm our vulnerability report data. For example , there are custom online NSE scripts for better operating system detection, version detection etc. And this may be what allows you to figure out that banner was a fake ! You can run locate *.nse to find all the scripts on your system, one of my favourites for enumerate SMB boxes is the smb-check-vulns script, which will spit out all the CVE numbers that the given box is susceptible to. For a tutorial on that click here.

As we update our vulnerabilities, even our asset lists along the way, we may have to rewire exploits and include additional steps to get to the point where we can execute them, possibly needing some other programs to pave the way and get us through to that point. This exploit chaining is where we can expect to compromise one , two or many machines before we get to the diamond.

Common Attack Techniques

Some Windows exploits can be ran on Linux , and so we can do some transpilation which means converting a program from one language to another. This cross-compilation is only really interchanging system calls, and not relying on the nuanced differences of the OS - this isn’t going to be a translatable kernel exploit, rather a reverse shell script or a fault with the external servers, and the exploit recreates the privilege escalation when the attacker pivots from one machine to another. For a tutorial on this click here.

Penetration testers will often work in their own development labs and sandboxes , with virtual machines of the vulnerable linux version that we were able to identify, and we can work out our exploits on there.

Aside from actual programming and “technical compromise” there is the human factor and leveraging this is called Social Engineering. There are different styles of SE and they can be based on:

• Authority
• Scarcity
• Social proof
• Urgency
• Likeness
• Fear

Credential brute forcing is where we just spam a login page with hydra or something , using a pre-built wordlist or employee emails we’ve harvested and our best guesses on company password policy etc to get in.

2.5 Explain weaknesses related to specialised systems.

Specialised systems are those which perform a single function, and in factories they make heavy use of them as they become easier to manage and to optimise. The use of many embedded devices, with in and of themselves perform a single function, can create a simple but functional model. In the industrial setting, factories may use these programmable microcontrollers to monitor the pressure in a gas valve, or the voltage in an electric grid etc. An ICS (Industrial Control System) is basically any system, regardless of complexity , that comprises any number of these controllers , sensors (for data acquisition from the stimuli) and machines which are responsible for the factory’s process. An ICS is the overarching coordination of these pieces into a network, which should be separated from the internet and have its own private VLAN that doesn’t talk to the router. It will nevertheless be exposed to real-world events , such as wind speed, rain, sunlight (it depends on the system) and depending on the complexity we need to employ a Supervisory Control and Data Acquisition (SCADA) system, which takes in inputs from these remote locations, either across the factory or even cross country where they can be used to manage national infrastructure. They interface with what are called Programmable Logic Controllers (PLCs) and these are the logic gates that sit at the border of the stimuli, take the signal, run the signal through and process it, and then the data gets sent to the SCADA terminal. Now, the software which gets installed at the factory centre will have many layers, with many drivers having to interface at each hierarchical level - making SCADA a bit wobbly when a single layer becomes incoherent.

Levels three and four go outside the SCADA topic, but the aggregation of information continues, and level three is concerned with monitoring the production and targets (aspects of production) - being able to step in when needed. Level four is to do with scheduling the entire production process, and encompasses the architecture necessary for the factory to operate.

Now onto why SCADA can be susceptible to cyberattacks and cyberterrorism plots. Because the software is multi-layered and so involved with many network nodes, it is very unlikely that we will ever have the time to update it, meaning any vulnerabilities that are newly found cannot be quickly patched in. We may have to stop production, but we have to take the supervisory computers offline so we can reinstall all the software needed… This is because devices that need to process things quickly use a Real-Time Operating System (RTOS) and due to this they don’t schedule for jobs other than those coming from PLCs. They are notoriously difficult to update, as they are constantly working so you have to take them out of production and then wipe the memory with a new one (the OS itself is immutable). Because of this, it makes testing a lot more difficult , and once a machine has been compromised, businesses may not be able to react immediately and so they turn into a sitting duck. An RTOS is a lightweight system so that they can handle all these signals, maximising CPU time on jobs, and not really having the time, or the software loaded, to check data for integrity , to check incoming network requests - it implicitly trusts the network… And we’re assuming that the manufacturers are quick to issue new patches , updates as they don’t often use automatic update mechanisms, and the only way a company could even find out they have a weakness is by running their own scans and tests, and subscribing to the relevant security bulletins (issued by both manufacturers and researchers). Because of the lacklustre security, they are weak to network-based attacks, and really anything that can generate faulty data, interrupt other pipeline processes, much like the Stuxnet worm built ~2005 causing massive damage to an Iranian nuclear plant. They preyed on vulnerable PLCs and caused them to malfunction and emit incorrect signals, so the SCADA system would continue to raise the pressure, until it blew up the factory plant. Stuxnet was so powerful that it gathered data from many industrial systems , and being architecture agnostic was able to spread to many different production environments.

With specialised systems, they don’t have the sheer number of features that a normal computer does, and so with less sophisticated built-in protection, they rely on the strength and skill of the network to vet the input that comes to it. If such a machine were exposed on a network diagram, you can be sure that an attacker would put most of their effort into that. Going a level above these smaller embedded systems are the SCADA (Supervisory Control and Data Acquisition) systems which control the flow of data between parts of the processing pipeline, and manage functions that span a large geographic area, like for natural gas / electric power transmission.

Mobile Devices. This is another prime target - because of the same issue: lack of security. Depending on the vendor updates can be slow and sparse, so security practitioners take it upon themselves to install a Mobile Device Manager (MDM) to handle things like automatic updates, FDE and remote wiping. We also need to train the owner of the phone to not install dangerous applications that may watch the camera, harvest data etc. Mobile devices may not show up on vulnerability scans as they aren’t always on the network, they be using their mobile data, they are not often sitting on the network when those scans run. Therefore, administrators should pay careful attention to the security of those devices, even when they do not show up as requiring attention after a vulnerability scan.

The Internet of Things (IoT). Probably the worst and least secure suite of devices ever to connect to the internet. We’re talking hundreds of thousands of devices all with default passwords that have access to the public internet and are very fragile items which can go down after a bit of throttling. This issue can happen for penetration testers, who have scanners ready to go, and if it is a black box test and the hacker is working their way through a system, then it could mean the device is downed and any systems which communicate with the IoT device can’t function properly. Take for example specialised medical equipment which we always want to test, but they should never be tested during use on a patient! Such devices should be tested during a white box assessment.

Specialised Systems

A point-of-sale system is where retail stores can combine sales, inventory and customer management the only problem is that due to that they harbour credit card information they become an incredibly attractive target for hackers, and even though they typically run above a standard version of Windows for example, they still need the same type of scrutiny placed on them as employee PCs and servers. POS systems involved in credit and debit card transactions must comply with the Payment Card Industry Data Security Standard (PCI DSS), which outlines strict, specific rules for the handling of credit card information and the security of devices involved in those transactions. The 2017 Verizon Data Breach Investigations Report (DBIR) did a special analysis of POS breaches and identified common trends in the types of attacks waged against POS systems:

Virtual Machines and Application Containers

Virtual machines need what’s called a hypervisor , usually Oracle VirtualBox , VMware and these sorts of “environment generators” which handle the resources of the underlying box (which may or may not have an OS installed) and allocates for the virtual instance. Now, we may decide that we test viruses in virtual boxes, we may wish to host employee accounts in their own private instance instead of giving them actual hardware , but for any of these uses we have the same security threat: VM Escape. If the virus managed to break that fourth wall, and if the VMs we put employee data on was vulnerable, then malware they got from a phishing attack could spread. That would be unbelievably dangerous as ultimately the hypervisor and underlying hardware control all of these instances.

The difference between an application container and a virtual machine is that the former requires the containment and management software of the container service (like a VM needs a hypervisor) but the container also pulls from the kernel of the underlying host, needing binaries and libraries - whereas the VM is an OS - and hence has its own kernel and whatnot. Containers allow you to isolate applications or services while being lighter weight than a full virtual machine. Containers are often managed as a swarm, making it easier to manage them as a single virtual system.

In fact, in many cases you won’t know if you’re attacking a virtual machine, a container, or a physical machine until you have compromised it (and perhaps not even then!). If you suspect that you have compromised a virtual machine, you can look for common signs that the system is virtual, including the hardware that is presented to the operating system. In many cases, checking for the network interface card, or for virtualisation plug-ins like VMware tools or VirtualBox extensions, can tell you if you have compromised a VM. On a Windows system, you can do this quite easily by using wmic:

wmic baseboard get manufacturer,product

;; would return
Manufacturer Product
Oracle Corporation VirtualBox

The Linux system-detect-virt command is an easy way to determine what virtualisation package is running if the system is running system-d. Other options include using the demidecode command, which can provide similar information, and checking the disk IDs to see if the system is being virtualised by using the ls -l /dev/disk/by-id listing command.

Virtualisation is rarely obfuscated in real-world production system environments, so detecting virtualization should be possible on most systems you encounter. Once you know which hypervisor you are dealing with, you can conduct research on the attack methods that may be available for that specific environment. Exploit tools that allow attackers to escape a virtual machine to directly attack the hypervisor have been sought after for years, with high prices paid for working exploits on the open market. Exploits have been found for VMware, Xen Project, Hyper-V, and VirtualBox, but each has been patched shortly after it was found. In most virtualisation environments, VM escape isn’t likely to work unless a new exploit is introduced and you are able to use it to exploit a compromised host before it is patched by your target organisation. That means that most penetration testers will be far more successful attacking the underlying administrative infrastructure so that they can access the virtualisation management tools and systems than they will be if they rely on VM escape exploits.

Attacks against OS-level virtualisation tools like Docker often start by compromising the application that is running in the container. Typical penetration testing processes can be used, including port and vulnerability scanning and service exploitation. Once you have compromised a container, you can then attempt to access the container’s host—in fact, in some cases, like the vulnerable Docker instance that Not So Secure provides, you can simply run the Docker client from one of the vulnerable Docker containers and connect to the Docker daemon running on the virtual machine! As with most penetration testing efforts, you should carefully document the environment, check for misconfigurations and exposed or vulnerable services, and then pivot as you gain further access.