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
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…