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.

Pivoting to Security and taking the Security+!

It has been quite some time since I have updated this blog, so here we go. If you've been following me, you know that I was studying hard for the CCNA. Long story short, I did not pass it. I missed it by about 150 points. I then retook the exam after more labbing and studying and failed the exam again by a similar amount of points. I decided to change course for the time being and focus on cybersecurity. With my Comptia A+ and Network+ expiring in February of 2022, I decided now was a better time than ever to recertify them for another 3 years and gain knowledge in information security by going for the Security+. I put in about 3 months of studying and passed my first try! The Security+ is considered e"entry-level" as far as infosec certs, but was by no means an easy exam, especially for someone relatively new to security and with no professional security experience. I had to memorize about 20 pages worth objectives, which you can see here:
https://www.comptia.jp/pdf/Security%2B%20SY0-501%20Exam%20Objectives.pdf




I passed with a 763, so ..it was close. I have been doing IT Support/helpdesk for about 4 and a half years now and this completes the holy trio (A+,Net+,Sec+) for me. My best advice to those planning to go for this cert is to power through those questions. You don't want the clock to run out with 10 or 20 questions still left (granted, I am a sloooww test taker.) I know you can flag the questions, but I always tell people - Just hit the question once and give it your best. Don't bother going back to any. Here's what worked for me, if anyone cares:

*Mike Meyers Sec+501 course on Udemy (Mike Meyers is tha man, his nack for breaking things down and keeping the energy on is the best thing about his courses)
*Professer Messer's 501 videos and his practice question sessions (though I probably watched more videos from Meyers)
*Jason Dion's 501 practice exams on Udemy (comes with 6 practice exams, questions were good. I would say they were fairly in line with the real thing...though the real thing DEF hit me with some curveballs!
*Black Hills Infosec Intro to Security online 4-day course. I cannot say enough great things about these guys and gals. Pay-what-you-want, interactive labs provided via VM, and taught by some of the absolute best in the industry. This course really let me get my hands dirty with infosec and was really awesome. I'll be attending many more of their events in the future.*Printed out the objectives list and put chickenscratch notes all over all 20 pages of that sucker, highlighted ALL the acronyms I didn't have memorized and did my best (though to be honest, I never succeeded in memorizing absolutely ALL the acronyms. There's just SO many on there).

Next on the agenda: Labbing and getting more hands-on with with tools like Wireshark, Metasploit, netcat, and more! Stay tuned for more of my IT journey!

The Myth of the Cybersecurity Candidate Drought

“There are nearly 465,000 unfilled cyber jobs across the nation, according to data gathered under a Commerce Department grant”.

This is a quote from a Washington Post article dated August 2nd, 2021 on the subject of unfilled cybersecurity roles in the United States.

Cybersecurity is an immensely expansive field. From Application security to Network security to Network monitoring to Client/end-user security to Pentesting and malware development to social engineering to wireless attacks to physical security to compliance /legal frameworks, there are hundreds upon hundreds of tools and applications available for the plethora of different Infosec/Cybersecurity roles existing, many open source, and many with a hefty price tag. It takes lots of time to master any single one and can often be difficult to try to predict what any particular prospective company might want you to know, but as students in the realm of cybersecurity, we learn to delve into nearly everything we can, while obviously focusing in on tools we know to be popular (NMAP, BURP, OWASP ZAP, Nessus, Wireshark, John the Ripper, Metasploit, Cain and Abel, and Nikto are just a few that come to mind). But where does that leave us in the end as it relates to bringing on fresh talent in cybersecurity departments? If you ask most directors or CEOs or hiring managers, you’re likely to hear the same tired, perpetuated myth of the “drought of candidates in cybersecurity”. This claim could not be any further from the truth and it’s time we started facing the reality of the situation. The “drought” that is often referred to has been imagined. Fabricated, if you will, by companies who will not entertain the idea of hiring absolutely any cybersecurity candidates who have anything less than mid to senior-level corporate cybersecurity work experience. Herein lies the problem.

It stands to reason that companies would want absolute cream-of-the-crop experts handling something as important as their digital security. But where then do we draw the line between hiring experienced candidates and acting as old guard gatekeepers that keep out those who have worked tirelessly through the years to build a foundation in IT and Cybersecurity that just haven’t yet been graced with the opportunity to work an outright Cybersecurity role? As all things do, it comes down to the bottom line, money. Who wants to train a competent candidate with a solid foundation when they can just hire someone who has been in a Senior-level security engineer role for the past 5-10 years? Well, they can certainly find these candidates if they look hard enough but enticing them to apply and keeping them on is a different story entirely. Candidates such as these have any option in the world as far as employment opportunities, and rightly so. They’ve earned it. Top-tier pentesters, for instance, have their pick of the litter among fortune 500 companies with six figure offers. But how many of these candidates exist in the United States? I’ll give you a hint: Not 465,000 of them.

So what’s the solution? It’s time to face the facts. Cybersecurity roles that are lower-tier than Senior need to be embraced and introduced as a standard at more companies alongside the Senior-level roles which already exist. While nobody expects any company to put a candidate through a bachelors or masters degree's-worth of training, a lot more needs to be done on the part of employers to grow their cybersecurity departments organically. Perhaps not from an absolute beginner standpoint, but certainly from an upper-entry-level to intermediate one. Junior SOC Analyst and Jr Incident Response Analyst roles need to be introduced for candidates who are fit to fill those roles, with Senior-level engineers offering even just a few short weeks worth of training to overlay the Junior's already existing knowledge and perhaps help in filling in some gaps along the way. Some companies already have scenarios like this in place, but if we are to understand that 465,000 desks are sitting empty, then it’s time to face reality instead of continuing to perpetuate this long-told myth of the “Cybersecurity candidate drought”.

Naomi Buckwalter, a seasoned Cybersecurity professional, has actually started a foundation called Gate Breakers dedicated to addressing this topic as well. You can see a great, albeit heated, interview with Naomi here: 
https://www.youtube.com/watch?v=pAvfW0_FvqI

For more information on Naomi's foundation itself, please visit:
 https://www.cybersecuritygatebreakers.org/

VLANs and Trunking! Here we go!

When I first learned about VLANs a while back, the concept was a little difficult to grasp, but that's the magic of staying on the path with computer networking. All of the concepts that come off as a bit fuzzy at first become more and more clear as you revisit them. I obtained my Comptia Network+ certification last February, which delved into VLANs and Trunking, but not to the extent the CCNA does (that is, if Wendell Odom's excellent books are any indication of what's to come when I take the exam). It should come as no surprise that there is an absolute encyclopedia of different VLAN Cisco IOS commands that one needs to know for the CCNA. Below are my notes from the chapter that dealt with VLANs and Trunking:

"Reasons for using VLANs:
*To reduce CPU overhead on each device, thereby improving host performance by reducing the number of devices that receive each broadcast frame

*To reduce security risks by reducing the number of hosts that receive copies of frames that the switches flood (broadcasts, multicasts, and unknown unicasts)
*To improve security for hosts through the application of different security policies per VLAN

*To create more flexible designs that group users by department or by groups that work together instead of by physical location

*To solve problems more quickly, because the failure domain for many problems is the same set of devices as those in the same broadcast domain

*To reduce the workload for spanning tree protocol by limiting a VLAN in a single access switch

VLAN tagging- a process caused by setting up VLAN trunking (multi-switch, single VLAN) whereby the sending switch adds another header to the frame before sending it over the trunk (VLAN ID field)

VLANS can be set up across multiple switches without trunking using a separate cable between switches for each VLAN existing. This is not as ideal as trunking, in which one linked cable between switches uses VLAN tagging to handle multiple VLAN’s traffic.

2 VLAN standards- ISL(not typically supported now) and 802.1q. Both use 12-bit vlan tag, 802.1q also uses extra 4-byte header

No 802.1q header? Then defaults to native vlan (must be agreed upon by both switches)

Normal VLAN range =  1 to 1005 (on all switches) some switches use extended range VLANS of 1006 to 4094
Separate VLANS are also on separate subnets and can only communicate between each other via a router or a Layer 3 switch (which includes routing ability)

Show interfaces fa0/12 switchport -shows admin settings and status of port,vlan, etc

Show interfaces trunk-displays info only on trunking links, not access. If no trunking links are configured, this will display nothing. Broken up into 3 output categories:
*VLANs allowed: VLANs 1 - 4094, minus those removed/left out by the switchport trunk allowed VLAN command
*VLANs allowed and active:Shows VLANs allowed, minus VLANs not configured or in shutdown (administratively disabled mode ) or not learned of through VTP
*VLANs in spanning tree: Same output as VLANS allowed and active., minus those in STP blocking state and those pruned/excluded from the trunk

Switchport trunk native vlan 02 - command for setting native vlan. If two switches have a different native vlan set, this causes a frame mismatch issue called VLAN hopping.

Switchport access vlan - tells the switch to assign the port(s) to a single VLAN as opposed to using trunking

Switchport mode access -disables the protocol that negotiates trunking (Dynamic trunking protocol). Use this along with the above command.

VTP (virtual trunking protocol) - Cisco proprietary tool that advertises each VLAN configured in one switch (with the vlan number command) so that all other switches in the network learn about that vlan.

Vtp mode off - works on newer switches to disable vtp

Vtp mode transparent-works on older and newer switches to effectively disable vtp

^Both modes prevent VTP from learning and advertising about VLAN configs. The modes allow a switch to configure all VLANS, including standard and extended range VLANS. Switches using either of these modes also list the vlan config commands in running-config file

Switchport trunk allowed VLAN - If you want all VLANS on switch to utilize the trunk link, there is no need to use this command.However, if you want only a certain amount of the configured VLANS on a switch to utilize the trunk, this command is needed.
E.G. =switch(config-if)# switchport trunk allowed vlan 5-15 (thereby removing all others from traversing/utilizing the trunk)

Never experiment with VTP settings on a switch in a production environment. You can end up deleting VLANs and causing outages.

Switchport mode access-always act as an access (non-trunking) port

Switchport mode trunk-always act as a trunk port

Switchport mode dynamic desirable- Initiates negotiation messages and responds to negotiation messages to dynamically choose whether to start using trunking

Switchport mode dynamic auto- Passively waits to receive trunk negotiation messages, at which point the switch will respond and negotiate whether to use trunking (If two connected switches are set to this, nothing will happen as both will not initiate negotiation. If one is set to dynamic desirable, communication/negotiation will then occur)

Show interfaces gigabit 0/1 switchport- If “Operational mode:static access” appears, switches both set to dynamic auto and trunking has not been initiated as communication has not gone through.

Switchport nonegotiate - disables Dynamic Trunking Protocol (DTP) . Setting a port to switchport mode access also disables DTP (DTP=negotiation between switches of either the use of 802.1q or ISL

The operational mode (static access) means that the port is not a trunking port but instead is assigned to one VLAN. The access mode VLAN (11) is the VLAN to which the port is assigned, assuming that it is acting as an access port.

IP Telephony port key topics:
*Configure these ports like a normal access port to begin: Configure it as a static access port and assign it an access VLAN

*Add one more command to define the voice VLAN (switchport voice vlan 2 e.g.)

*Look for the mention of the voice VLAN ID, but no other new facts, in the output  of the show interfaces fa0/2 switchport command

*Look for both the voice and data (access) VLAN IDs in the output of the show interfaces fa0/2 trunk command

Do not expect to see the port listed in the list of operational trunks as listed by the show interfaces trunk command

show interfaces trunk and show interfaces switchport are the best commands to check trunking-related facts (and for troubleshooting)

These commands are near-impossible to memorize without constant lab practice. I tend to bounce back and forth between using my physical lab and using Packet tracer. Packet tracer is great for scenarios involving equipment that I simply don't have the money to recreate in the physical capacity. Another great thing about packet tracer is the pre-made packet tracer labs/files that others have already made and are often free for download. www.thekeithbarker.com is a great resource for pre-made Packet Tracer labs (with accompanying videos) and Keith is a very energetic and informative host (no pun intended). This following link was also extremely helpful for putting VLAN commands to practice: https://www.youtube.com/watch?v=aBOzFa6ioLw In the meantime, back to the lair! More posts coming soon!

Back on track

It's been some time since my last post, but I am back on track with my CCNA studies. Cisco recently made some changes to the certification exam, combining ICND1 and ICND2 into a single exam/cert that includes additional topics not in the previous one. I purchased Wendel Odom's Official Cert Guide books for the 200-301 CCNA (the new one) and I cannot give the books enough praise so far. He does an excellent job of explaining the concepts, putting them to practice, and providing helpful analogies. I've been making it a priority to spend at least two hours a day reading the book or putting things to practice on my router/switch lab.


What I have found helpful is making bullet point-style notes of any concepts or commands that I am unfamiliar with in a Word document I have up. I do this chapter-by-chapter as I go through the book. I also take advantage of the chapter questions and use a program called Flashcard Hero to retype any questions/answers in the book that I got incorrect. This is by the far the most confident I have felt studying for the CCNA to date and is a study recipe that I highly recommend. My goal is take and pass the CCNA this year.