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.

Cybersecurity in Asia: Keep Your Castle Safe

When it comes to a cyber-attack, it is no longer a question of if your company will be hacked but when. Companies from 2 to 10,000 will get hacked. There’s no question.

If you think that’s bad news, then consider this: in Asia Pacific, enterprises were expected to spend US $230 billion in 2014 to deal with cyber breaches, and it wasn’t enough. Organized crime accounted for US $138 billion in enterprise losses in the region, according to an IDC/NUS study.

Sixty percent of security breaches are due to compromised credentials. The threat won’t lessen as time goes on—cybercrime is profitable. In fact, it’s now more profitable than the illicit drug trade—and it’s a powerful magnet, attracting unscrupulous individuals, organized crime rings and even nation states interested in doing “bad” for profit.

With the advent of the third platform—mobile, social, big data, and cloud—the surface of attack for cyber criminals is just getting larger. Security measures of yesterday are struggling to cope with the speed of mobile adoption and how devices are now interconnected. Meanwhile, hackers are already onto the next stage of the game: it’s a game of cat and mouse, and we, unfortunately, are the mice.

Governments are also getting in the game, with a number of countries in Asia ramping up measures to counter cybersecurity threats. For example, in Singapore the Infocomm Development Authority of Singapore (IDA) introduced the Singapore National Cybersecurity Master Plan 2018 to provide the strategic directions to guide Singapore’s national efforts in enhancing cyber security for public, private and people sectors.

Singapore is by no means the only nation worried about cybersecurity: Japan, Indonesia and other countries in the region have also put forward initiatives to bolster efforts to address the clear threat cybersecurity poses.

This is the current threat landscape. It’s scary, but by no means is it impossible to address. In fact, Asia Pacific is leading the world in digital security, according to PwC.

Companies in the region are more likely to have an IT security strategy that is aligned to the needs of the business and to have a senior executive who communicates the importance of security.

The Asia Pacific region remains a leader in implementing strategic processes and safeguards for information security, setting the pace in numerous practices. As with any potential threat, being prepared to deal with attacks is just as important, if not more so, than preventing attacks in the first place.

Let’s put it this way: If a company with firewalls, anti-spam and anti-viruses all in place is a castle, they are well prepared for an attack that castles would naturally expect: armies with arrows, a catapult, hordes that can be repelled by ensuring they do not enter the castle.

What happens when the enemy evolves? In order for the company to keep its castle safe, it needs to change its mindset and understand that they are no longer dealing with the same enemy as before.

Changing Mindsets on Cybersecurity to Match the Evolving Threat Landscape

Today, the focus is on preventive technology. In the castle analogy, this would be the equivalent of the strong walls, narrow windows and a moat—anything in place to ensure that intruders can’t get in.

While it’s absolutely necessary to make sure you have adequate defenses on the outside, none of these preventative measures are able to do anything about aggressors that have already gotten into the castle.

The mean time to detect a threat and mean time to respond is currently in months—hundreds of days—long after the damage has taken place and is too large or severe to salvage.

Once the detection and response times are closer together—in the weeks, days, or even hours, ideally—companies can meet that challenge of seeing their environments in real-time and knowing when you there is an intruder.

How can this be done? By not holding compliance up as a shield. 2014 was a year of major breaches—and many of the major breaches that took place last year happened at companies that considered themselves compliant to security standards.

Being compliant to regulation is not the same thing as being protected. Enterprises can no longer be satisfied with a “check the box” mentality. Regulation is a good start, but by no means does it comprehensively cover a company’s security measures.

Once companies change the “check the box” mentality towards cybersecurity, the realize that the threats that their businesses are facing aren’t necessarily ones that fit into a checklist or a framework. That’s why preventative measures are not enough.

Let’s go back to the castle analogy: you have a well-fortified castle but you’re not dealing with an enemy that’s knocking on your gate anymore. You’re looking at enemies that are wearing your uniforms, or drones that are attacking from above – a more sophisticated intruder that you can’t prevent from getting in. What can you do? You need to identify them, and respond to them in a timely manner, before they can deal your castle significant damage.

The Way Forward: Early Detection and Response

Organizations need to baseline their environment and determine who has access to which areas and what information. Can you see your environment? Are you aware of where your servers are and what’s on your servers? Where is your sensitive information? Who is allowed to access what information?

We help organizations create that baseline so they can see, with the help of analytics, if something is going wrong in real time. For example, if an employee’s credentials are compromised, any new activity from that account is and should be a red flag.

Today, organizations needs to invest in security intelligence and have a set of security analytical tools. As services become more interconnected and as more data is generated, there is an increasing need to shift to a combination of machine and user analytics. Let the machines analyze the thousands or millions of logs generated and have it identify the unusual occurrences.

This way, we can reduce the time to detect and the time to respond. These are the critical factors when it comes to cyber security: When you realize that they are going to get in, then you need to kick them out before they can do any real damage.


Tags: ,

0 Comments | Security


LogRhythm Challenge: Black Hat 2015

{Collaboration between Thomas Hegel and Greg Foss}

For Black Hat this year, Labs decided to try something new and put together a packet capture analysis challenge for the conference. The goal of the challenge was to find the secret launch codes for the fictional company, “Missiles R Us.”

Below, you will find the solution to the puzzle along with details on the Easter eggs hidden throughout.

The PCAP’s Distractions

  • Mozilla FTP server browsing and various file downloading
  • Streaming of this YouTube video
  • Downloading the Dropbox application (not actually using it)
  • Uploading of a .txt file containing useless assembly code to
  • One post to with the base64 encoding string “so close, yet so far”
  • Another post with the string “This is a test…hmmmm”
  • Using telnet to play Star Wars over telnet
Figure 1. Star Wars TCP Stream

Figure 1: Star Wars TCP Stream

Figure 2. Star Wars Over Telnet

Figure 2: Star Wars over Telnet

The Solution

There was one last use of, in particular, to paste a large string of binary text. Following the encoding/decoding trend of the challenge, we must convert that binary to ASCII. Doing so will provide the following string:


Now we have some base64-encoded data! Decoding that, we get:

Secret La
unch Code:

Getting closer! At this point, we now have a hex encoded string (&#xNN entities to be specific). As the final step, we decode this string to ASCII, and now have the following:

Secret Launch Code: 2g389a34!0297#

Easter Eggs

Hidden throughout the challenge were some Easter eggs. The first of which was basically hidden in plain-sight within a comment field at the bottom of the HTML on the first page.

Figure 3. Easter Egg

Figure 3: Easter Egg

This was another basic encoding challenge, somewhat similar to the actual solution. However, the encoding was a bit different. To reverse this, bring up your favorite encoder/decoder (I like to use and take this apart. This first string is Octal JavaScript encoded.


Once you decode this, you are left with a Unicode string.


FIgure 4: Unicode (renders in HTML, so we went with a screenshot. Click for a link to the plain-text)

Which decodes to base64.


Which finally gives you a key…

key = 9ughgjw9241110x41

That, when entered into the scoreboard, does nothing. Its sole purpose is to throw challengers off and send them down a rabbit hole.

Figure 4. PCAP Easter Egg

Figure 5: PCAP Easter Egg

In addition to the red herring mentioned above, there was a hidden game that was available if keywords such as “LogRhythm” or “Labs” were entered in to the scoreboard. You can still play the game here:


Overall, we had a great turnout and want to thank everyone who participated in the game!

Figure 5. Metrics

Figure 6: Metrics

Until next year…

Tags: , , , , , ,

0 Comments | Digital Forensics


PSRecon – PowerShell Forensic Data Acquisition

Live incident response and forensic data acquisition is often a very manual and time consuming process that leaves significant room for error and can even result in the destruction of evidence. There are many people involved when investigating an incident, which makes process consistency difficult. Often when retrieving a system, evidence can be tampered with and altered in the short time frame between the identification of an issue and the interception of the suspected host or user. For this reason, electronic evidence can sometimes be thrown out of a court of law due to possible tampering or inability to show proof in a court of law.

To help fill in this gap, Labs developed a Live Incident Response and Forensic Data Acquisition PowerShell script that uses only native Windows tools to gather evidence and system data in its current state. This script also incorporates account lockout and lockdown functionality to essentially take suspect hosts offline and/or disable accounts within Active Directory following data acquisition.

Download Here  =>


Figure 1: PSRecon Banner

PSRecon gathers data from a remote Windows host using built-in PowerShell (v2 or later), organizes the data into folders, hashes all extracted data, and sends the data off to the security team in the form of an HTML report. This can then either be pushed to a share, sent over email, or retained locally.


Figure 2: PSRecon basic data acquisition

The ability to lock down and endpoint can be useful when investigating a system infected with malware, especially when there is risk that the malware will spread to a share or other critical systems within the enterprise. Sometimes the quickest and most effective way to stop the spread of malware is to simply knock the host offline until IT/Security can respond.

Alternatively to quarantining the host, PSRecon allows you to disable an active directory account following the acquisition of live forensic data. All of these various options can be combined to turn an often manual process into a streamlined and easy method to remotely obtain forensic data from a target host and quarantine the system from the network.


Figure 3: Example Email with Attached HTML Report

Within the report, you have an accurate view of a significant portion of the target host, in its entirety. One of my favorite aspects of the report, is that everything is self-contained, making it easy to share as there is no reliance on a centralize server. Even the images are encoded directly into the report’s HTML.


Figure 4: Report HTML Image Encoding

What’s more is that if you have a team of Incident Response professionals, you can push the report out to all of them at the same time. With more eyes on the evidence, the easier and faster it is to spot the threat, especially when combined with the data already gathered by the SIEM. Not only are we mitigating the threat and kicking off an investigation within minutes, we have also already obtained somewhat ‘forensically-sound’ data from the remote host that will help responders better understand the full picture.

While on the topic of SIEM, this script integrates easily into LogRhythm to allow for the execution of this script as a SmartResponse™. This will work with various AIE™ alarms or can be run ad-hoc against local/remote hosts. In particular, any case where Malware is observed would be key to pull forensic data and then quarantine the host. The SmartResponse™ also uses its own included version of PowerShell, as the remote host is normally in an compromised state, so the PowerShell executable itself should not be trusted. One of the limitations of the open source version of the tool.


Figure 5: SmartResponse™ and AIE™ Rule Integration

The current available SmartResponse™ actions are:

  • Gather Local Data and Send Report via Email / Push to Share / Pass Additional Arguments
  • Gather Remote Data and Send Report via Email
  • Gather Remote Data, including client email and Send Report via Email
  • Remote Lockdown and Quarantine
  • Disable AD Account and Host Lockdown

This works well with LogRhythm’s Case Management workflow as well. This is helpful in not only creating a timeline of events but gathering forensic data and performing automated defensive actions. Speaking of timeline, PSRecon writes its own logs as well, to track its actions and verify activities on the host. This is beneficial in that it will help you show what activities the script performed on the suspected host.


Figure 6: Host Logging

While on the topic of logging, PSRecon also logs attempted attacks against itself… So, take an example scenario where someone tries to hijack another employee’s browser by way of a SmartResponse™. To do this they would inject an XSS attack within a user-controllable field that is reflected on the HTML report. These attacks are detected and logged, allowing for additional actions to be taken. Of course, there are tons of ways around this, it’s just a small added precaution for when the script is integrated with security infrastructure.


Figure 7: XSS Attack Example

PSRecon takes a long, cumbersome, and inaccurate process that used to take days to complete and turns it into a quick, effective, and powerful means to instantly acquire forensic data and respond to various threats directly from the LogRhythm SIEM; streamlining a significant portion of the incident response process.

The project is still very much in beta and I’m looking for feedback from the security community to help with ideas and code improvements going forward. So, check out the GitHub repository and let me know how we can make this better!

Tags: , , , , , , , , ,

none | Digital ForensicsSecuritySIEM


Security Awareness: Taking Advantage of Opportunity

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.

Figure 1: Wi-Fi Pineapple

Figure 1: Wi-Fi Pineapple Mark V

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:

I also gave a talk a few months ago at AppSec California on the topic that goes into much more detail than this post. The slides and presentation recording can be found here:


Essentially, deploying this attack comes down to a couple key aspects and both Mark Vankempen and Michael Logoyda deserve some major props for figuring out the JavaScript specifics of the Pineapple captive portal. In fact, Mark decided to swing by the hotel to do a little recon and testing before everyone arrived. The hotel staff asked what he was up to, and he told them the truth, that he was there to set up some wireless access points for the LogRhythm meetings. The hotel staff then very graciously provided him with power strips, extension cords, and even credentials to the hotel’s access points. This was all done with no verification of Mark’s identity and relationship to LogRhythm, which gives you an idea of how easily this could be done by just about anyone. Maybe even using the real access points…

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.

Figure 2: Splash Page

Figure 2: Splash Page (click to enlarge)

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.

As you saw in the splash page above, we are passing the authtarget variable through. On the actual landing page, we need to add two small JavaScript scripts. The first of which is a script that should be placed in the header of the landing page. Without getting into too much detail, this essentially captures the authtarget link and allows it to be used as a variable.

Figure 3: Landing Page JavaScript – Part 1 (click to enlarge)

The next bit of JavaScript needs to be placed within the form. This allows us to pass the authtarget variable through so it can be used by our form processor and actually allow the user through to the Internet.

Figure 4: Landing Page JavaScript - Part 2

Figure 4: Landing Page JavaScript – Part 2 (click to enlarge)

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.


Figure 5: PHP Form Processor (click to enlarge)

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…

Figure 6: Customized Captive Portal

Figure 6: Customized Captive Portal

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

Tags: , , , , , ,

0 Comments | Security


Kippo Honeypot – Log Replay Automation

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 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).

Kippo replay of basic C2 post exploitation activity

Figure 1: Kippo replay of basic C2 post exploitation activity

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

Figure 2: Kippo Log Replay Alert Script

Figure 2: Kippo Log Replay Alert Script

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.

Figure 3: File Integrity Monitoring Policy Update

Figure 3: File Integrity Monitoring Policy Update

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.

Figure 4: Kippo FIM Event -- Log Details

Figure 4: Kippo FIM Event — Log Details

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…

Figure 5: Kippo Log Replay FIM Alert

Figure 5: Kippo Log Replay FIM Alert

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.

Figure 6: SmartResponse Action Approval

Figure 6: SmartResponse Action Approval

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…

Figure 7: Auto Replay Email Alert

Figure 7: Auto Replay Email Alert

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.

Figure 8: Honeypot Analytics Dashboard

Figure 8: Honeypot Analytics Dashboard

Tags: , , , , , , ,

none | Digital ForensicsSecuritySIEM