Automated PCAP Retrieval from Network Monitor

SmartResponse Plugins allow alarms that trigger in LogRhythm to launch actions — adding malicious hostnames to a blacklist, quarantining infected machines, removing users from an Active Directory Group, or nearly anything that can be scripted. Because it’s available by default, this has typically been done through PowerShell. However, the SmartResponse framework allows for any language or program to be used, so long as it can be installed on the system that contains the LogRhythm Alarming and Response Manager (ARM) service.

Although not included with Windows installations by default, Python is one of the most popular scripting languages, recently becoming the most popular language taught in Computer Science classes. One of Python’s key strengths is the vast library of user-built modules that greatly expand its functionality — these are very useful for easily performing the otherwise complex actions that a LogRhythm user may want to perform.

For example, if an Intrusion Detection System log generates an alarm in LogRhythm, it would be very valuable to an analyst to have the full-content PCAP of the traffic that caused the IDS to fire. Assuming LogRhythm Network Monitor is being used to collect PCAP, the ‘Retrieve NetMon PCAP’ SmartResponse Plugin can query the Network Monitor API for all traffic related to the signature, download the associated sessions in PCAP form, and then merge all of the sessions into one easily usable PCAP. This can occur either automatically or require user approval.

Although not officially supported, this plugin is relatively easy to configure and use. This blog post will go through each process, step by step. The plugin can be downloaded here: Retrieve NetMon PCAP SmartResponse Plugin

Setting up the ARM to run Python scripts

1 Determine which LogRhythm appliance is hosting the Alarming and Response Manager service — from the LogRhythm Console Deployment Manager, the host will be listed under the ‘Event Manager’ tab. To double check, it will be listed under ‘services.msc’ on the machine.


2 Install Python 2.7 and Wireshark on the Event Manager.

3 On the Event Manager, hit the Windows key + Pause/Break. This will bring up the System Window. ‘Select Advanced System Settings’, and then ‘Environment Variables’.



4 In the Environment Variables window, scroll to ‘Path’ under the ‘System Variables’ subsection.



5 Click ‘Edit’ and append the string:

;C:\Python27\;C:\Python27\Scripts;C:\Program Files\Wireshark

– or the appropriate directory for the Wireshark and Python installations. Then close the window.

6 Open ‘services.msc’ and restart the ARM service. Python will now be ready to launch.

7 Because this Plugin uses a non-standard Python module, ‘Requests’, we can also setup PIP, a tool that will allow us to install Python modules with one line. Follow this guide to install PIP.

8 Once PIP in installed, run the command

pip install requests

to install Requests. Alternatively, Requests can be downloaded and installed manually. You’re now ready to import ant run the Retrieve NetMon PCAP SmartResponse Plugin.

Importing a Plugin

1 From the LogRhythm Console, open Deployment Manager and then open the Smart Response Plugin Manager via Tools ->  Administration -> Smart Response Plugin Manager


2 Select Actions -> Import


3 Navigate to the directory containing the Smart Response Plugin, then select the file (of type AR Plugin File, .lpi) and click Open.


4 The Smart Response Plugin should now be visible in the list of plugins in the Smart Response Plugin Manager and the Actions tab for Alarms and AI Engine rules.



Configuring the Retrieve NetMon PCAP SmartResponse

1 Find an alarm or AI Engine Rule that should trigger the PCAP retrieval. For example, the AI Engine Rule ‘Network Anomaly: Internationalized Domain Name (IDN)’ would be useful, because analysts can use the PCAP to determine what data is being sent to an unusual site. Open the rule and go to the ‘Actions’ tab.


2 From the Actions tab, select the ‘Action’ dropdown at the top, and find the ‘Retrieve NetMon PCAP’ plugin and select it.


3 The Parameters section will then be populated. There are four values which need to be specified by the user:

  • Query String: Use ‘Type’ ‘Alarm Field’. The alarm field chosen as the ‘Value’ will be the string that Network Monitor uses to find all associated sessions. This should typically be a hostname, domain name, or other field that will be visible in network traffic. To test an items effectiveness, it can be searched in the Network Monitor UI as a Lucene Query. For this Alarm, choose ‘Group’ to query by the domain name.
  • PCAP Dir: This will be the directory where the PCAPs will be saved. For example, ‘c:\tmp\pcaps’. Remember that this will be in respect to the Event Manager.
  • NM Address: The hostname or address of the Network Monitor device
  • NM API Key: Can be found under the ‘Configuration – User’ section of the NetMon UI.


4 If the action should not be automatic, use the ‘Approvals’ section to set the Person or Group that needs to authorize the action to run. The approval will need to be done through the Dashboard or Alarm Viewer. If using a new Rule, it’s recommended to require an approver so that the Action doesn’t fire too often or pull down very large amounts of data unintentionally. Leave this section blank to run the action automatically.


5 When finished, hit ‘Ok’. The Plugin should now be working.

The LogRhythm Labs team will continue to release similar unofficial plugins as they are developed. We are also releasing revamped, official plugins, including plugins for integration with LogRhythm partner devices. For questions about this guide, please use the How To section of the Support Forum. This is also where the latest editions of the Threat Detection Cookbook can be found.

Again, the Retrieve NetMon PCAP SmartResponse Plugin can be downloaded here. The guide can be found here.


Tags: ,

none | IT OptimizationSIEM


Google Project Zero

Google has revealed that it plans to recruit experienced hackers to a new team known as ‘Project Zero’.  The new recruits will be employed to find serious weaknesses in internet security in order to prevent cyber attacks.   The main focus for the team will be finding ‘zero-day’ vulnerabilities and, importantly, to widely share the information they find – something others have been criticized for failing to do.  Among other internet security assignments, the team will also be tasked with conducting research into how attacks are carried out and how best to stop them.

As an organization at the forefront of online innovation, Google is certainly well placed to be exploring the web for trouble and should be highly commended for doing so.  Too many organizations have a ‘finders keepers’ attitude towards sharing information, which is both unhelpful and dangerous.  By searching for and revealing bugs, vulnerabilities and, I imagine, a whole host of other online ‘nasties’, Google will likely save many organizations from disastrous attacks.

Of course, Google may recruit the best team possible, but the nature of zero-day attacks, and today’s connected world in general, means that, inevitably, things will fall through the cracks.  While many of us may rely solely on Google to answer our day-to-day search queries, it would be an error to rely on them to protect our networks in equal measure.

Every business needs to be monitoring its own IT systems for unusual activity – whether that’s files moving in a suspicious fashion, or users logging on at odd times.  Understanding ‘normal’ network activity is key to noticing abnormal events – and who is going to be better placed than the business itself to separate the routine from the abnormal? The utopia of cyber security would see constant monitoring and collaborative intelligence, and hopefully Google’s Project Zero team will move us one step closer to this idyll.  We’re all building a similar jigsaw and working together could just help us find a crucial missing piece.

none | Uncategorized


Tube to Work Day: The Most Exhilarating Commute Ever

Last week, when Ajay sent an email to the company about the upcoming Tube to Work Day in Boulder, my first reaction was, “Is this for real?”  This was quickly followed by “What a crazy, unique, yet awesome idea that I actually could do and, for some reason, really want to do.”  I was all in.  Having made it past 50 and my first root canal, it was time for my first tube to work day.  The water was running fast after a heavy year of snow and rain, which would make for an exciting ride and a fast “commute.” But it wasn’t sky diving or bungee jumping from a skyscraper. So, it felt like the right level of adventure on the calculated risk continuum.

I soon had 15 LogRhythm teammates willing to join me on this wacky adventure.  In the end, we had 11 actually do it on Tuesday. I got a little concerned when I realized I was the only one over 30 in the group, but I was committed at that point. The LogRhythm contingent, some wearing ties and others in full suits, started at Eben Fine Park at the mouth of Boulder Canyon with about 30 other comrades in loony-ness. It almost felt like a tube to work flash mob.There was an instant camaraderie with our fellow tube to workers as we navigated rapids and frigid water and made our way hooting, hollering and high-fiving down Boulder Creek. There were some dicey spots and a few of us flipped into the water, but nothing too bad, and we helped each other get out of some jams. So, yeah, we were on an official company team building exercise. Unfortunately, our team in the UK wasn’t able to participate, but sent pictures of commuters crowding into the London subway/”Tube”, lamenting that their tube to work day was not quite as interesting.

Ready for work

Ready for work

I have to say that it was an absolute, unqualified awesome time…pure fun and truly exhilarating.  I was on a natural Colorado high the rest of the day.  Major kudos to Jeff Kagen for originating this in 2008.  It is truly an “only in Boulder event” and the only one in the world as far as I can tell. So I contemplated after the fact why we did it and what was the appeal? I realize there is an alternative transportation angle to it and there is some small awareness element there, but this is not bike to work day. There you have a realistic commuting option, exercise, environmental benefits and time to think.  In reality, the creek is not a realistic commuting option for 99.9 percent of folks for 80 percent of the year.   For “tube to work day,” we all drove to work and then took a van and truck to the launch point.   So, we didn’t really help the environment.  In the end, we did it because a) we could and b) it was such a unique and fun thing to try and do together.

I’m actually surprised it hasn’t gained even more traction in Boulder. Maybe we did our part today to help it accelerate. LogRhythm represented about 20 percent of the “tube to workers” Tuesday and we went the farthest, going almost 3 miles from Eben Fine park to our offices east of Foothills Parkway.  Most did only about half our distance.

So, I’m thinking we must have set two world records…one for number of employees from the same company tubing to work and one for total distance tubed to work.  Congrats to Ariel, Brian, Tyler, Robbie, Chad, Colby, Kyle, Alex, Riley and Jimmy for helping set these world records.  Not surprising, of course, from the company that has managed to also take Security Intelligence to a whole new level and win several awards in the process. I knew I’d somehow be able to tie this back to the business :). My natural competitive drive and world record fever aside, Tube to Work day is not about competition.  It seems all about fun, wackiness, actively enjoying nature and bonding with your co-workers and fellow Boulderites. This is the kind of thing the highlights how great a place Boulder (and Colorado) is to live and work.   We have a thriving business community and a very healthy and innovative technology sector that is producing many great products and services.  We work hard and are passionate about what we do, but we also value work/life balance and don’t take ourselves too seriously. And there is a level of collaboration and community that you don’t see in other technology business hubs.

I can see Tube to Work day growing in popularity. I can certainly see the LogRhythm contingent growing and I encourage others to take the splash. Why, you ask? Well, why not?  I guarantee you won’t find a more interesting and exhilarating commute anywhere.

3 miles. 11 employees. World Record.

3 miles. 11 employees. World Record.


Tags: , ,

none | Uncategorized


The Rise of Cyber Extortion

Malicious software must be becoming more difficult to monetize. While in the past malware has been written to display adware, perform clickjacking to make ad revenue, or build botnets to perform more complex tasks, the recent trend has been toward direct monetization through cyber extortion. The Ransomware Cryptolocker came onto the scene in September of last year and many variants and similar pieces of malware have been seen since then. Ericka Chickowski at Dark Reading has put together an interesting piece that describes a number of extortion attempts, past and present. See number 6 (the Durham Police Department) for an example of an organization prepared to respond to this situation.

none | Uncategorized


Hunting Retail Cyber Crime with LogRhythm

Recently I was on site with a customer whom we were working with to provide an extra level of support configuring LogRhythm to target and detect attacks specific to the retail industry.

This includes activity such as deviant behavior in the point of sale environment, potential theft of customer data from corporate IT resources, etc…

We began the process by looking for the malicious activity this module is designed to detect in order to identify anything that had taken place prior to implementation.

During the course of this investigation, we identified a set of activity that indicated there was communication on a known bad channel. This prompted an immediate investigation into the activity to identify all the relevant details surrounding this event so that we could provide forensic evidence of a data breach if necessary. Over the next few days, I will be explaining this process in greater detail.

Step 1.  Identifying a potential breach.

In this first installment, I’ll explain how we initially identified the activity that immediately raised concerns that a breach might have take place.  It started with an alarm that indicated some entity was utilizing a known malicious command shell port within this network.

LogRhythm Alert Metasploit

LogRhythm Alert Metasploit detected

The destination port number 4444 is the default Metasploit “Command Shell” communication port. To a hacker using Metasploit for this type of attack the command shell might display communication from the attacker to the target host like this:


Sample Metasploit

Figure 1:

In this particular instance we used LogRhythm to quickly drill down and locate the specific log messages which identified this attack. It seems as though a connection was made to a few internal Customer Servers. Then something more alarming was revealed when we saw that the last connection was made to a server in Japan.

The FTP server seen making connection 2 and 3 (see image below), are potential prime targets for malicious activity. This server frequently receives remote retail store inventory in the form of PDF’s files via FTP. This makes it a prime target to package a Metasploit Trojan in the form of a PDF file that will wait dormant until someone mistakenly executes it.

Metasploit Log Detail

Metasploit Log Detail

Note: This retail store chain only has business in the United States. It seems that whomever created this connection was a little bit deliberate in their attempts to mask this traffic.

The origin source for connection one and two, and found in the second to last column. They do not originate from a random high number port as one would expect. Instead those connections are masking themselves as the service ports for their respective host jobs.

After the forensic investigation was complete, LogRhythm learned there was a corporate relationship between the offending entity and has chosen to mask the public destination IP.

Since we needed more information, we performed a quick, right click correlation within LogRhythm:

Right Click -> Correlate on OHost = FTP(MaskedData)

This quickly brought back an hour’s worth of log data detailing the origin host’s recent activity.

A visual baseline clearly identified that one host communicating with the corporate network was geographically district from typical network traffic.

Show me the traffic LogRhythm

Another right click correlation pulled up the destination coordinates for the communication path.


Additional questions arose. What is this server? Who owns it? What is that IP address doing? The investigation led us to open a browser to see if it server had a publically facing website, which it did.


This is an externally facing default Apache Tomcat Server. Doing nothing. Often times, in this line of work, un-configured servers mean that someone was in a hurry to quickly stand something up that can receive data quickly and with little configuration. For example: A cyber attacker needing a place to upload a whole bunch of your corporate data quickly.

In addition to searching for originating IP address, we had started a virus scan on the FTP server. Zero results returned.

If this were an attack, you would think we’d see something on the server from the AV scan, so this was initially confusing. However, a quick investigation showed that a process was running tied to a legitimate Windows executable (Metasploit) being used to perform suspicious activity, which may not be picked up by an AV scan.


Based on our research we were able to provide the customer with the follow options going forward. Continue the investigation with an endpoint forensics tool, block the attack from happening in the future via firewall rules, or add a packet capture device and keep the investigation going.

none | Digital Forensics