Posts tagged: 'information security'
The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.https://blog.logrhythm.com/tags/information-security/feed
Security Awareness is an incredibly important aspect of any security program. As we’ve seen in countless high-profile breaches, users are consistently the path of least resistance into any organization. Which is why training employees to identify ‘suspiciousness’ and react in a safe and effective manner is just as important as maintaining perimeter security and aggregating log data. Since LogRhythm is a security-focused company, we take a more aggressive approach than most when it comes to Security Awareness training by testing our defenses regularly, in realistic ways.
Open Wireless networks are the perfect medium for malicious activity and criminals have leveraged this attack vector in many high profile intrusions for years. One of the more recent and public Wi-Fi attacks came to be known as “Dark Hotel“. In this scenario, the attackers preemptively compromised a hotel network which they know their target would be visiting. They leveraged the Wireless network to deploy their malware to hotel guests for around seven years. This is just one of the more notable breaches involving a public Wireless network; though this case is a bit different than a true rogue AP attack. For this reason, training your employees on the security precautions they can take when using such networks is incredibly important.
Recently, LogRhythm hosted one of our many regular sales events. This is a time when a majority of the organization gathers in Colorado to meet and discuss the future of the company. We decided to use this event as a learning opportunity. Since employees from all around the world gather in one central location for the event, we launched a rogue access point attack with the goal of simulating an adversary targeting LogRhythm employees. This is a fairly straight forward attack in that we hid multiple Wi-Fi Pineapples throughout the hotel and captured employee domain credentials using a custom captive portal (note – we only captured usernames for obvious reasons). Luckily we have some very sharp folks working here and many reported the pineapples immediately, one guy even found one of the Pineapples. Had this been a real attack, it would have been shut down hard and fast due to the diligence of our employees.
Exercises like this are usually not common within non-security focused organizations, however it is important for security awareness training programs to take multiple attack vectors into account when evaluating their overall security posture. By now, most people are well aware of generic phishing attacks – however training exercises such as deploying rogue access points are not often conducted internally. This is why I’d like to walk through how to conduct such an exercise and train your employees to report things that just ‘don’t feel right’.
If you frequent the LogRhythm blog, you may have read through the xfinity pineapple post that I put together last year. Since then, I’ve received many questions around exactly how to build such an attack using the Wi-Fi Pineapple. Primarily because I didn’t really dive into the code and this can be a bit more complex than some of the other deployment options, such as PwnSTAR. To help out with this, Labs put together two blank captive portal templates that can be used with either vector in order to assist both penetration testers and various organizations with orchestrating similar training exercises. This code can be downloaded at the link below:
Getting back to the Pineapple configuration, I like to deploy captive portals using a basic redirect within the NodogSplash configuration — this allows you to stand up various captive portals quickly and easily. All you need to do is point to the new web directory where the actual portal pages will be stored. This also gives you the ability to use PHP scripts, which is not possible on the initial splash page.
With the basic splash redirect in place, this opens up the possibility of very elaborate captive portals. This can contain whatever you’d like — anything from a false login form to malicious content delivered via browser exploit. The latter is easy as you can simply pass the client through, however capturing form data is not as straightforward as it sounds — at least not on the Pineapple. In fact there is a thread dedicated to deploying a specific captive portal attack on the Pineapple, which still does not have a definitive answer. Mainly because this attack would be dangerous in the hands of someone who doesn’t really understand the legalities of what they are doing and giving away the easy solution would be irresponsible in my opinion… So, I’d like to cover the attack in general to help folks better understand how to defend against it.
The final piece of this is the PHP form processor. This page basically appends each login attempt to a flat file by capturing the entire contents of the POST data and subsequently allows the user through to the authtarget link once the form has been successfully submitted.
Make sure to set permissions properly so your Pineapple doesn’t get owned and that’s it! Now, just give the access point an interesting SSID, launch the captive portal, then sit back and watch the credentials flow…
Quick Open Wi-Fi Security Tips
- Always use a VPN/VPS/SSH Port Forwarding/etc. when connected to an open access point.
- Turn all Wireless devices off when traveling or in crowded areas, many devices still connect to wireless networks even when ‘sleeping’.
- Try false credentials first, if it lets you through it was a scam.
- Use different credentials for basically everything.
- Visit a common site, like as Google.com and look for a valid SSL certificate — if you get a certificate error then your traffic is being sniffed.
- Use NetCat to check the HTTP Headers of the landing page for the word ‘Pineapple’.
- Beware duplicate networks or the system connecting to your ‘home network’ when you’re really nowhere near your home.
- Use caution when your Wireless connection suddenly drops and re-establishes itself, especially if this happens to everyone around you.
- If it just ‘doesn’t feel right’ then trust your instincts…
Attackers thrive on opportunity. Even something as simple as a target visiting an unfamiliar location can be a goldmine for an adversary — allowing them to manipulate the environment around their mark. Why don’t we as security practitioners do the same? It is important to think outside the box and leverage unique attack vectors to actively test employees. Not only are they your greatest asset, they can often be your weakest point. Training employees on how to recognize and respond to various attacks is crucial to the overall security posture of your organization.
Kippo is one of my favorite honeypots due to its sheer simplicity, portability, and ease-of-use. It comes with a really neat feature that allows you to replay what the attacker did once they gained access to the honeypot by way of the playlog.py script. This is a somewhat lesser-known feature within Kippo that can be valuable as it gives the analyst insight into how the attacker interacted with the server , what commands they ran, what services were installed, potentially what Command and Control server they are operating from, and much more.
While you can already pull this data in to LogRhythm to gather important information using the extracted metadata, it’s another thing entirely to watch the attacker in action. This feature helps to determine whether it is an actual person or a bot interacting with the host. The problem, however, is that this takes time and effort to manually log in to each honeypot, run the script against each TTY session log, and review the results. Why not automate this process? Below is an example of a real attack and some valuable data that was observed in an SSH session with a Kippo honeypot (in this case a malware payload was downloaded).
As you can see from the screenshot above, whenever an attacker successfully breaches the honeypot, a new TTY log file is generated – this is separate from the kippo.log files we are already pulling in to the SIEM. So, the quickest way to automate this is to create a small bash script on the honeypot host(s). This script is pretty simple, it defines a few environmental variables, runs the playlog.py script and outputs the results of the script to a text file in a separate directory. Once this is complete, it moves the replayed TTY session log to a separate folder, modifies the output so it can be viewed easily on Windows hosts, and sends a notification email to the SOC with the attached log replay file.
This script is available in my forked Kippo repository along with other small additions, here: https://github.com/gfoss/kippo.
We could easily set this up to run via cron, however then we would have limited control of the script execution. Since cron is limited to running on a set schedule, this has the potential to affect File Integrity Monitoring (FIM) notifications and there may be times when you don’t want the script to execute. So, the easiest way to do this would be to use a LogRhythm SmartResponse™. First we need to set up a new FIM policy, for this use case I simply cloned the existing Linux FIM policy and added the /opt/kippo/log/tty/ directory, configuring it to check for any new log files every 10 minutes.
Now with the new FIM policy in place, a log file will be generated whenever changes are observed in this folder. Reviewing the log metadata allows us to see what attributes we can alert on.
As you can see from the screenshot above, we can create a simple Advanced Intelligence Engine™ (AIE) rule that checks for the above common event, object, and log source…
Now for the fun part, we need to set up a SmartResponse™ to trigger whenever this rule fires. We can do this using any scripting language, but for this proof of concept, I chose PowerShell. All we need to do is authenticate to the server using Plink and run the aforementioned bash script remotely by way of a quick PowerShell one-liner that Andrew Hollister put together.
cmd /c "plink.exe -ssh -i key.ppk -noagent -m commands.txt $UserName@$TargetHost <yes.txt"
Using this script, we can build the SmartResponse™ and configure the script to run whenever the associated AIE rule fires. At this point, it is possible to configure approvers if desired. With the new action in place, enable the AIE rule and test to assure everything is working as intended.
If all goes well, you will receive an email notification with an attached log message displaying full details of the attacker’s replayed TTY session…
Using SmartResponses™ to automate TTY session replays, extracting the session log, and forwarding this on within an email can help security analysts, researchers, etc. quickly analyse the attack and gather useful data very easily. While the general honeypot metadata already being captured by the SIEM is excellent, it can be drastically improved by automating Kippo’s attack replay capabilities. Not only will this give analysts a better idea of who is attacking them and what methods they are using, but it can serve as an early-warning indicator, complimenting the wealth of information already being extracted from the honeypot metadata.
The holidays are a wonderful time of the year, a time when folks get together and spend time with the ones they love. Unfortunately, along with the holiday season comes new waves of targeted attacks geared towards taking advantage of holiday commonalities. These attacks come in various shapes and sizes, normally taking the form of an errant shipping notice, holiday greeting cards, coupons, gift certificates, and many more.
Spear phishing vectors are incredibly effective during this time of year due to the ever-increasing number of folks shopping online and taking advantage of e-cards as opposed to traditional snail mail holiday greetings. For these reasons it is imperative to pay even closer attention to the messages you receive to avoid becoming a victim.
To help illustrate this, I’d like to examine a basic spear phishing email that one of LogRhythm’s own business leaders received recently. The phish is a basic fake FedEx email. In the screenshot below, I’ve highlighted some red-flags within the message itself that give away its blatant illegitimacy.
This message is so similar to the phishing emails I used to send out for training exercises years ago that it was rather nostalgic in a way. The interesting part was just how targeted the message, attachment, and even the malware itself was — containing references to the recipients first and last name throughout. In fact, when I checked our internal Network Monitor instance, they were the only individual here to receive such a message over the past couple days…
So, we took this malware sample apart and ran it in our lab environment. The attachment is delivered in a compressed .zip file that, when extracted, reveals a doc.js file. This attack attempts to take advantage of the age-old Right to Left Override (RTLO) ‘feature’ within Windows, wherein it executes the last (often hidden) file extension.
They’ve attempted to obfuscate their code, however JSunpack makes quick work of this, revealing important information about the malware in question.
In short, this script leverages Internet Explorer to pull down 2 executables that allow the attacker to gain a persistent access to the host. Once this process has completed, the malware performs textbook malicious activity by beaconing out to multiple Command and Control servers based in Germany.
The funny thing with this malware is that even though it was heavily customized to target a specific individual at a specific company, it still would not make it past basic Anti Virus in an enterprise environment. The malware was flagged by eight major Anti Virus vendors on VirusTotal.
This just goes to show that even targeted malware is not really all that advanced. The attackers likely took an educated guess at what Anti Virus LogRhythm used and tried to just bypass that one. This tactic will work against many organizations, however LogRhythm takes a layered approach to security…
Even though this is a basic spear phishing attempt and the malware is trivially caught by Anti Virus, what about those instances where it does slip by and the recipient decides to open the attachment?
You can leverage the SIEM to alert on this activity by monitoring for new files with multiple extensions. This can also be applied over the network, analyzing attachments delivered through email by way of network flow analysis. A rule such as this is easy to implement and results in relatively few false-positives — as any legitimate double extension file types can be white-listed.
RTLO is a very common vector hat has been used in phishing attacks for years. In fact, if this malicious file was able to evade Anti Virus, security analysts would still be notified of the suspicious event via the SIEM, giving them the chance to respond to the threat and potentially avert a major breach. The simplicity of the rule is that there are very few legitimate instances where double file extensions should be used.
Happy holidays from your friends at LogRhythm and be careful when shopping online!
On Tuesday Microsoft released an emergency update to Windows Server 2003 through 2012 R2 to address a vulnerability that enables an attacker to escalate privileges for any account on a Windows Domain. The vulnerability can be detected in Windows Server 2008 and later by analyzing Windows Event Log ID 4624 and looking for a discrepancy under New Logon between the Security ID and Account Name as shown:
In LogRhythm this is easily detected with a new AI Engine Rule that watches for any differences between the Security ID field, captured into Account and, the Account Name field, captured into Origin Login. This AIE Rule, Account Anomaly: Domain Privilege Escalation, is available with the latest knowledge base update (KB 6.1.260.2).
While it is most critical to first apply Microsoft’s prescribed patch for this vulnerability, this is a helpful way to easily detect if this vulnerability has been exploited on your Windows domain.
Tricking users into copying different commands from what is displayed on a web page…
OK, maybe I’m late to this party but I recently came across a very cool attack vector that I had not heard about until now. There’s an excellent write up on this here that was actually published in 2008, so I won’t go through the details of how this works. However you can view an interactive demo of this in action here.
Essentially, this is ruse that can be used to trick people into running a different command on their system than what they thought they had initially copied from a website. Go ahead and try it out over at JSFiddle.net, just copy the text within the ‘result’ box and paste it into a text editor to review the full command. Neat, huh?!
The demo above shows an attempt to shovel a reverse python shell back to the attackers system though make it appear like the command simply echoed “this is a test” to the screen as expected. This proof of concept is demonstrated below.
This is merely another vector that can be leveraged in social engineering attacks. Demonstrating the risk with blindly copying + running commands from websites that you do not trust. Always re-type commands such as this or paste them into a text-editor prior to running them directly. Also, if you are cloning a repository from a resource such as GitHub, review the code before integrating this into your project. All too often websites are backdoored due to the themes or modules that have been downloaded and installed from an un-trusted repository without going through code-review. In general, you shouldn’t implicitly trust anything at face value; trust but verify…