Keylogging!

Today I utilized my first keylogger. A keylogger is an application which secretly records every key you press to a well-hidden text file for later viewing. This would be a good time to bring up something known in the Information Security world as ethical hacking philosophy. In a nutshell, this means understanding that with great power comes great responsibility. The responsibility to help make this world a better place, not a more dangerous and divided one. Techniques like this should not be used for petty gain or malicious purposes. What exactly constitutes ethical vs unethical can become blurred as white hat hackers (legal hackers tasked with protecting an organization or agency) attack back against blackhat hackers (illegal, criminal hackers with malicious intent who initiate a breach with the purpose of stealing data, shutting down a company's infrastructure, or compromising their target nation's national security.) So if a blackhat hacker set off the chain of events by stealing data or shutting down a company's infrastructure, and in response, a remote keylogger is placed on the attacker's machine by a whitehat hacker to gather data or access their system and stop the threat, is that considered ethical? How about using "honeying" methods to have a blackhat hacker open up a decoy file on your website or server containing a geolocation tracker that alerts you to where exactly in the world the attacker is based? I would argue that in both these cases, it is ethical as these techniques were not done pre-emptively, but rather in response to a malicious action. Many, though perhaps not all, top information security experts would agree.

My understanding so far of keyloggers is that many run on Python. Some can even be customized to automatically send the log of keystrokes to your email. After having spent some time experimenting with different ones and running into issues with several, I have settled on recommending the one at the link below, which features a custom Python script created by network/security expert and instructor, David Bombal:
https://www.youtube.com/watch?v=XKoTwepEzPI
Here is the link for his Python script:
https://github.com/davidbombal/CompTIA-Security-Plus/blob/main/python-keylogger

This video shows how you can use the author's custom-created Python script to log keystrokes on a Windows machine and have them automatically send to a text file. This involves downloading Python, creating a new project, and copying and pasting the code provided in the link in the video's description, then saving the file.

Important note: When downloading Python, check off all of the options for additional features in it's setup screen including "pip path". Afterward, hop into command prompt (run as admin) and type: pip install pynput This installs a module required for keyboard input to properly work. If you are running Windows Defender (which, on a Windows machine, you should be), it will likely trigger an alert at the suspicious executable .pyw file (python file) you created. Choose "allow" so we can see it working for test purposes. There are actually ways to disguise this file and keep it from being detected as a threat by Windows Defender, a technique known as "obfuscation". But I will not be getting into that on this particular post. 

Once the Python file is double clicked.....nothing happens......well......at least it looks that way. But now start typing. Do a search in the Windows start flag, open up Chrome and search for a website on google. Hop onto Gmail and enter your username and password as an example and you will soon discover that it is all being recorded in the keylogs.txt file. Open that file to see a plethora of sensitive data you've typed, going vertically down the page, key by key. What you did when you double clicked that Python file was launched an executable file that shows no indication of itself opening or running to the naked eye. Hop into task manager, however, and you will see Python running. That is the service cleverly collecting your keystrokes. Ending the Python task(s) will immediately end the keylogging process, though all that is logged already will remain on record.

   

Dipping into Python!

The time has come for me to get over my fear of programming. My first experience with Python was actually back in college when I was still pursuing computer animation. Python seems to be used in everything today from scripting by InfoSec engineers to being used for particle effects / dynamic visual effects by computer animators. I have discovered an absolutely fantastic intro to Python basics at this link:
 https://www.youtube.com/watch?v=rfscVS0vtbw
Sections are broken up into small chunks and easy to follow along to. The instructor is great at breaking down just how the syntax in Python works and what it means. From lists to tuples to floats to integers, I cannot recommend this free course enough. As per the instruction in the video, I am using an app called PyCharm to enter my python code and then execute it. Think of PyCharm as a text editor...like notepad, but way smarter. It will immediately detect errors in your syntax in real-time as you type them by popping up with an exclamation point or display a green checkmark if your syntax contains no errors. A green play button then allows you to execute the code. Here is an example of an interactive, albeit very simple program I created where inputting my name, age, and hobby results in a declaratory sentence containing those values.

Python is extremely important in information security as it can be used to automate attack techniques for pentesting purposes, initiate keylogging, and much much more. Although I am not yet at the stage of fully understanding how to incorporate Python for the many security purposes out there, I am understanding it a little bit more with each small chunk of training I complete. Although I could just copy and paste code given to me by a programmer, it will never replace the value of truly understanding it's components. 

Http vs. Https and Telnet vs Secureshell

Maybe you've noticed that mostly all the websites you visit show a little lock symbol next to them in your internet browser's address bar and begin with "https"(the "s" standing for "secure"). It wasn't always this way. It wasn't too long ago that many sites were ordinary http (non-secure) sites. According to Stat Operator , a global web statistics organization, 57.1% of the most popular 137,971 websites are now "https". In fact, popular search engines like Google have been known to punish websites who did not convert over to the secure format by booting them from their search results. Most sites will redirect automatically to their https site even if you only typed it in with http. It's an understandable move, as Google naturally wants to lessen the risk of hacking for their end users and for those websites/companies that make up their results. You might be wondering "What's the difference and what makes one secure and the other not?"


To best understand this, we need to hop into Wireshark, a program that is in every Network and Cybersecurity Technician's toolbox without question. Wireshark is a free packet analyzer application and is available for Windows, Mac, and Linux. While it is often used to diagnose network traffic issues by administrators, it can just as well be used for malicious purposes by those looking to steal sensitive information. It will give you a nitty-gritty, sometimes brain-overloading display of network traffic and everything in those internet packets that allows them to route from their source to the destination, wherever that might be. Wireshark takes some time to start to understand. It's best not to let it intimidate you right off the bat with all the details it shows you. It will take time to understand the relevancy of some of the data that may seem like minutia at first.



Just know for now that in Wireshark, you can capture traffic and easily see any information that the visitor of a non-secure (http) website entered on there, be it the username field, the password field, the search field, etc. It doesn't matter! That is what 100% unencrypted internet traffic looks like. You can now see why this is so risky.

To test this out yourself, you can hop onto Aliweb, which is said to be the oldest search engine ever and amazingly enough is still hosted and online and non-secure in all it's ..uhh..."glory".... http://www.aliweb.com/ .





Try typing into the search field and see if you can locate the packet in Wireshark that contains what you typed in there. In the screenshot pictured above, I am looking for the word "search" because the information I typed was into a search field on the unsecured website. But this could just as well be a search for any of the following keywords: login, pass, password, username, email. Anything that we get a hit on will show us what was entered in it's field back on the non-secure website. Since it's becoming increasingly difficult to find a non-secure http site that contains login fields (and thank goodness), the above scenario is a good comparison.

This of course, is in contrast to any information you would enter on an https site. With encryption now occurring on the secure site ( www.google.com for instance ), that turns any of your entered information into nothing but jumbled gobbledygook to anyone trying to snoop in and view it on a packet analyzer like Wireshark.

The relationship between http and https can be directly tied to the one between Telnet and SecureShell (SSH). Telnet is an administrative terminal session that you create inside of a command prompt window to be able to configure the device on the other end, be it a router, switch, or firewall. A password is entered, disguised by asterisks, but don't let that fool you. We face the exact same vulnerability here and this too will show up in good ol cleartext (immediately understandable, unencrypted data). Just as HTTPS has resolved this issue for HTTP, Telnet has since been replaced by SSH. SSH acts pretty much identical on the surface to Telnet aside from the initial configuration, which presents several options for RSA Key length, etc.

Telnet login screen examples (non-secure, should not be used)




See below, encryption options when initially configuring a SecureShell (SSH) terminal line.