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
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…
Last weekend, a significant number of celebrities had their private photos and videos exposed to the internet in the largest celebrity data leak to date. Initial speculation led people to believe that their iCloud accounts were the primary targets. If this is indeed the case, there is a popular theory behind this ‘hack’.
This may have been the result of a brute-force attack against each account using select passwords from the ever popular rockyou password list in conjunction with the ibrute script written by @hackappcom. This python script essentially bypasses the AppleID lock feature of the Find My iPhone application. In an article published by Wired, once the password was successfully brute-forced, the Elcomsoft Phone Password Breaker (EPPB) tool was used to download this data from iCloud backups. This is due to the fact that EPPB allows anyone to impersonate the victim’s iPhone and download the full backup.
If this was indeed the source, it is a result of an amalgamation of the fact that Find My iPhone did not implement adequate brute force protection, these celebrities picked some really weak passwords, and did not implement Apple’s two-factor authentication.
Another aspect to consider is that the culprits gained access to much more than pictures and videos, such as address books and other sensitive data that is all available via iCloud. More importantly, with many organizations adopting iPhones and Androids in the workplace, attacks such as this increase the ever expanding possibility of corporate data loss. One obvious risk with the release of these pictures is that location data, included in the image Exif metadata gives away the locations where the pictures were taken (warning NSFW link).
All things considered, it is unlikely that only one avenue was taken to obtain all of this data. More importantly, just because everything was dumped on the internet at the same time and that a majority of the photos were taken with an iPhone does not at all mean that it was all stolen at the same time or even by the same person. I assume a team with a common goal was behind this, and they used many different means to obtain this data.
Apple released a statement on the leak:
“When we learned of the theft, we were outraged and immediately mobilized Apple’s engineers to discover the source,” they said. “After more than 40 hours of investigation, we have discovered that certain celebrity accounts were compromised by a very targeted attack on user names, passwords and security questions, a practice that has become all too common on the Internet. None of the cases we have investigated has resulted from any breach in any of Apple’s systems including iCloud or Find my iPhone. We are continuing to work with law enforcement to help identify the criminals involved.”
Granted, Apple did fix the Find My iPhone specific vulnerability shortly after discovery, which is very good, but a glaring hole like this should not have made it past QA. The funny thing is, this could have been avoided entirely if the vulnerability was disclosed to Apple prior to its public release. However, researchers may have been more encouraged to share this information with Apple, had they instituted a bug bounty program. Could all this stolen data be from iCloud? Maybe. Could it have been extracted in the same manner? Certainly, but not likely in my opinion. My guess is that good old fashioned social engineering played a part in obtaining access to some accounts.
In the wake of this recent leak, there are a few lessons that we can all take away from this to help better protect our own cloud data, taking into account the many methods by which it can be obtained:
- Whenever possible, implement multifactor authentication. Apple has a two-step verification feature which will assist with this.
- If multifactor authentication is not an option, question the sensitivity of the data you are storing on the service and do not store it in the cloud if you are worried about someone else getting ahold of it.
- Use strong and unique passwords for every site.
- Use pass phrases instead of passwords.
- Use a password manager to store, manage, and create strong + unique passwords for each site that you use.
None of these security recommendations are in any way new or at all difficult to implement. The problem is that too few people follow these basic guidelines and continue to use the same weak passwords for all of their online activities, resulting in the theft of sensitive data. Do not rely on companies to protect your information, take your own precautions and educate yourself on the risks.