Posts tagged: 'enterprise 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.

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


What you see is not what you copy

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, just copy the text within the ‘result’ box and paste it into a text editor to review the full command. Neat, huh?!

HTML rendered text example

HTML rendered text example

HTML source of the attack - python reverse shell

HTML source of the attack – python reverse shell

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.

Attack Proof-of-Concept – Click To Enlarge

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…

Tags: , , , , , ,

none | SecurityUncategorized


IDN Phishing Attacks on the Rise

Internationalized Domain Names (IDNs) are becoming more and more common in regards to phishing attacks, command and control servers, malware propagation, advertisements, search engine optimization (SEO) poisoning, and other web-based attacks. Recently, LogRhythm Labs has intercepted many phishing messages utilizing IDNs and punycode in an attempt to mask the URI and potentially trick users into clicking their links — often masquerading as legitimate sites. Fortunately their tactics are normally not very effective and often don’t work at all as intended. Granted there are a few exceptions…

To demonstrate, let’s take a look at an example SPAM email that attempts to use a Russian punycode IDN domain name to display the URI.

punycode phishing email

Figure 1: punycode phishing email

Translating the URI from punycode to Russian, shows how the spammer wanted the URI to appear.

Figure 2: Converting the domain name from punycode to Russian

Figure 2: Converting the domain name from punycode to Russian

Pulling the HTML contents of this page reveals a block of encoded JavaScript, which redirects the browser until eventually landing on a ‘prescription medicine’ website.

Figure 3: HTML source of the initial landing page

Figure 3: HTML source of the initial landing page

Following three redirects brings you to (hxxp:// The domains it bounces through are listed below and the full report on this link can be obtained at

Figure 4: DNS Requests

Figure 4: DNS Requests

Researching the primary domain, we can see that it is located within the Ukraine.

Figure 5: Tracing the IP of the SPAM domain

Figure 5: Tracing the IP of the SPAM domain

The Russian domain name and Ukraine hosting location is especially odd because the page has a Chinese signature at the bottom of the source-code. This isn’t visible in the trace above, but when the source is viewed directly or CURL‘d this can be observed.

Figure 5: Chinese text visible within the source code.

Figure 6: Chinese text visible within the source code

Regardless, this is all just common SPAM and millions of emails such as this are sent out every day. Personally, the really interesting aspect of IDNs and punycode attacks is that many security tools are not currently set up to assess these domains in the same way as with conventional (.com/.org/.net) domain names. Folks who are vigilant about security and assess links that they receive may run into road blocks when it comes to easily analyzing IDNs. Many of the standard analysis tools fail to see these domains as valid and thus would not scan these links. The first example of which is a great free tool — Zulu URL Risk Analyzer by Zscaler that unfortunately is not yet ready to handle punycode URI’s.

Figure 6: zulu scan unable to handle punycode URI

Figure 7: zulu scan unable to handle punycode URI

Running a whois from, the punycode domain extension was not recognized.

Figure 7: DNSstuff punycode domain lookup attempt

Figure 8: DNSstuff punycode domain look up attempt

We encountered similar errors when analyzing the URI using a variety of open-source first-step analysis tools, however, there are services available that have the ability to analyze and convert punycode IDNs. The fact that many major tools cannot yet handle these domains highlights a problem in that attackers are advancing faster than our defenses and what’s worse is that this is nothing new — DNS has supported non ASCII URI’s since 2009. If we as an industry are unable to keep up with new techniques employed by our adversaries we will surely lose this fight.

To that end, using a SIEM, web proxy, and/or firewall, these URI’s are easy to detect, block, and alert on when accessed. It’s simple, if there is no business justification for folks within your organization to visit these domains, access to such URI’s should be blocked or alerted on at a minimum. Within LogRhythm this activity can be detected using two basic AIE rules.

The first AIE rule checks for suspicious Top Level Domains (TLDs) and augments this with a white-list of known-good IDN TLD’s so that alarms do not fire when ‘approved’ applications are visited.

Figure 9: TLD AIE Rule Block

Figure 9: TLD AIE Rule Block

The second rule simply looks for any IDN domain.

Figure 10: AIE Rule Block that detects IDNs

Figure 10: AIE Rule Block that detects IDNs

Tags: , , , , , ,

none | Security


NIST Addressing PII Protection

The National Institute of Standards and Technology (NIST) has drafted a document that specifically addresses Personally identifiable information (PII).  The document will become Appendix J of SP 800-53.  This means FISMA is likely to change to include these new privacy controls.

What does this mean to you?  In the short term, nothing.  The standard will be in a public comment period until September 2, 2011, and is not scheduled to be included in SP 800-53 until December 2011 when Revision 4 gets released.  After that, it still needs to be updated in FISMA and other regulations derived from SP 800-53.

However, the controls outlined in the draft are significant, and will eventually add extra layers of complexity to an organization’s plan to become compliant.  I’m still fully digesting the draft, but something that initially stands out is that NIST is treating PII data similar to how PCI-DSS treats card-holder data, and to how NERC-CIP treats Critical Cyber Assets.  For example, control SE-1 in the NIST draft states:

The organization:
a. Establishes, maintains, and regularly updates a PII inventory that contains a listing of all programs and information systems identified as collecting, using, maintaining, or sharing PII;
b. Provides each update of the PII inventory to the CIO or other information security officials to support the establishment of appropriate information security requirements for all new or modified information systems containing PII.

This sounds very similar to the approaches in PCI-DSS for defining and securing the Cardholder Data Environment (CDE), or the NERC-CIP Critical Cyber Asset identification.
The draft also adds on all the standard process and procedure requirements, auditing requirements, monitoring, roles and responsibilities, etc, that are seen across the board in other compliance regulations.

While there will still be quite some time before organizations are mandated to adhere to this draft standard, getting a head-start now will save headaches in the future, and protecting PII is simply the right thing to do, regardless of whether it’s mandated by compliance.

Tags: , , , ,

2 Comments | ComplianceDigital ForensicsSecurity


With great freedom comes great responsibility….

If it didn’t come across as mind-bendingly smug, I might describe the Sega hack as ‘old news before it even broke’.  But it is.  Old news.  Another global digital meganame falls prey to malicious, possibly mafia- or triad-backed ill-doers.

Recently I sat and watched a trusted colleague deliver a presentation to a roomful of security personnel and liken their industry to an air wreck.  I believe his exact words were ‘if this were a plane, I’d be running up and down the aisles screaming that we’re all going to die!’.  Needless to say this was not well received on the day, but I can’t help but think that he had a point.

Now, I work for an SIEM vendor – the best on the planet, in my opinion, but I’m not going to ambulance-chase this one.  There are crucial issues raised now.  This raises questions about whose responsibility personal privacy actually IS.  As I’ve said before, Amazon, Barclays Retail, Dell, Dabs – any of these guys could get hacked tomorrow and lose YOUR data.  What then?  It can take weeks to recover from a personal identity breach – resetting email accounts, changing card numbers, suppliers and addressing the huge numbers of interconnected services and locations where your identity converges.  This is not to mention the consequences if you actually lose money.

What more can individuals do?  Most of us are getting it right:  Don’t throw old business cards in the bin.  Go for strong passwords, changed at least monthly.  Don’t show identity badges in public places (watch out for my next blog on this!).  Speak to everyone about the need for security.  Educate the less technically literate about malware.  Don’t respond to emails or phone calls about online matters unless you initiated the conversation.  Keep one eye on the security blogs.  Learn the language.

Can companies say the same thing?  What about the people who I entrust my identity to?  Invest in security – with all that entails.  Infrastructure.  Dedicated FTEs.  Education.  Compliance.  Regular reviews.  Fire drills.  Specific executives whose job IS security.  Clearly the people who take online privacy seriously are being let down by the companies who don’t, and the more companies that are breached, the more excusable it seems.

My own view on Sega and the bi-monthly additions to the ranks of large companies who didn’t make the grade, is that it’s time to think of security as a multi-partite affair.  Your strategy should start with compliance, then loop through infrastructure best practise, via rigorous HR policies and finish by directly addressing social engineering.  The modern breach is a blended affair.  Only a blended security strategy will work.  One that centres around human factors.

Tags: , , , , ,

0 Comments | ComplianceDigital ForensicsSecuritySIEM