Posts tagged: 'logrhythm'
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/logrhythm/feed
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 => https://github.com/gfoss/PSRecon/
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.
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.
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.
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.
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.
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.
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!
“Start by doing what is necessary, then do what it possible; and suddenly you are doing the impossible.” – St. Francis of Assisi
In my 3+ years as a LogRhythm Professional Services & Security Consultant, I have often found customers with an appetite for security awareness, and the abilities to “look for the big things”, yet unable to satisfy their hunger.
Building the foundation: The security intelligence platform
From a traditional viewpoint, SIEM is typically classified as “Log Management”, but this is only a small portion of an effective SIEM. Log Management itself, is only one facet of true Security Management. In order to achieve a true Security Intelligence Platform, we need to include components such as Server Forensics, Network Forensics and Endpoint Forensics. Bundle up all this data, information, management and analytics and you are getting a much better picture of how SIEM has evolved into Security Analytics.
As a precursor to this, if you’ve never heard of LogRhythm’s Security Intelligence Maturity Model, or would like to read up about it, then I recommend reading the whitepaper available here.
Essentially, the model empowers users of the LogRhythm Security Intelligence platform to increase their awareness around the activity in their infrastructure, thus reducing the time taken to identity a potential threat, indicators of a breach or anomalous behaviour in their infrastructure. This resulting insight and visibility, reduces the overall mean time to detect (MTTD) and enhances the security posture of the organisation.
This lowered MTTD allows an organisation to better respond to whatever situation arose and consequently detected. Thus, the MTTR (mean-time-to response) is improved as well, due to the higher level of security intelligence leading to a far more rapid and effective decision making and response process.
Doing what is necessary: Base threat analytics
To address the fundamental requirement of “start by doing what is necessary”, LogRhythm developed a packaged module of rules around Base Threat Analytics using out-of-the-box features and intelligence to set up this foundation for implementation of Security Intelligence.
These rules have been designed to use LogRhythm’s AI Engine to detect correlations across various log sources, grouped into categories such as account anomalies, network anomalies, host anomalies and typical indicators of a compromise. Thus, the Base Threat Analysis suite encapsulates the “necessary” step for Security Intelligence.
From here, organisations need to begin to look at “What is possible?” Once the Base Threat Analytics module has been successfully implemented, the groundwork has been laid for an effective Security Intelligence posture.
The MTTD will already be greatly reduced, as the enhanced capabilities provided by LogRhythm’s AI Engine are able to effectively correlate and identify security, operational and audit anomalies and scenarios that would be far too time consuming or impossible due to the sheer volume of information required.
Explore the possibilities: Identifying the next step in your security intelligence maturity
So just what is possible? How does an organisation determine a direction from here? Should your security posture be driven by management decisions or perhaps by device and equipment types available to you? What about projects or newer generations and iterations of devices? Should they dictate your next phase in Security Intelligence Maturity?
The truth is, it can often be a combination of all of these factors, as well as a multitude more LogRhythm can help not only with guiding those decisions, but also in ensuring a mapping and planning of the future direction is outlined, enabling you to reach a much higher level of security awareness and intelligence.
The beauty of this is that LogRhythm’s scalable platform is designed that these additional modules and evolutionary phases of the Security Intelligence Maturity Model can be implemented rapidly and effectively on your existing platform. All the building blocks and tools are provided for you, with LogRhythm Professional Services helping you to understand how these fit together and the best ways to implement these tools.
Doing the impossible: Rapidly identifying and responding to threats
Finally, we are now doing the (seemly) impossible. We have managed to implement a Security Intelligence model that has helped to decrease the MTTD from a manual, labour-intensive and slow process to a more rapid, dynamic and intuitive process. This enables you to identify and understand complex scenarios and indicators of threats and breaches within minutes of them occurring.
The result? Because of this increased awareness, your MTTR has also decreased as you have the information needed to make quick, rapid and well-informed decisions on how best to respond to the incidents that have been identified.
My immediate reaction was “so that’s where all the Anthem data went.”
This headline completely underpinned how today’s cyber criminal is becoming more and more sophisticated. It has become a harsh reality that criminals have so many weapons in their arsenal that it is becoming more and more difficult to keep up with them let alone predict their next plan of attack.
In this latest breach, stolen personal data was used to file bogus tax returns and claim $50M in refunds (at least that is the number which the IRS is willing to admit to). In all probability, the personal data, used in the bogus tax filings, was stolen during one or more of the recent high profile breaches reported in the mainstream media: Anthem, Ebay, JP Morgan Chase or one of the many others.
Unfortunately like many high profile breaches, I believe this one too could have been avoided had the IRS been given or, for that matter, requested a list of affected consumer data from earlier breaches. Had they done this, a trigger could have been set up to raise an alarm every time a tax return was filed for someone on the watch list. Additionally, an automatic response could have been set up to alert investigators, such as a follow-up phone call or a verification email, each time an alarm was triggered. These actions would have allowed further investigations to verify or discredit the return. This type of trigger could have easily been set up within a system like LogRhythm.
Furthermore, based off of the information provided by the IRS, it seems that for each one of the bogus tax returns a brand new on-line account was set up with a different email address from the one used for previous tax return filing. Again, a process to detect this type of activity could have easily been incorporated into the trigger I proposed above. All of which could be easily set up within LogRhythm.
Of course with the benefit of hind-sight, it is easy to see how major events like these could have easily be avoided, but someone should have seen this type of attack coming. There needs to be safeguards put in place for when sensitive data is stolen. For example, when a consumer’s credit card is compromised, they are sent a new credit card. However, when a social security number of an American Citizen is stolen, they are not issued a new one, nor are flags put in place to detect future unauthorized usage.
If nothing else, as a result of this and other breaches over the last year, we have learned, that cyber crime is now more lucrative than drug crime. There is less risk and greater rewards. Organized crime gangs from Russia, China and other countries around the world are getting better and better at stealing personal data and then either using it or selling it for massive financial gains.
A well-recognized reality in today’s InfoSec community is “They Will Get In.” Therefore, it is what you do once criminals have breached your network and how fast you react that truly determines how devastating or otherwise a breach can be. Organizations face a giant game of chess, where they must act and react, being as predictive as possible.
Determining what data had been stolen during the Anthem breach and others, as well as its possible uses, might have led to the implementation of a system or process designed to prevent what happened at the IRS. Perhaps this latest high profile attack on one of the bastions of American society will provoke some far-reaching and more stringent systems and processes to be implemented. Perhaps not. Time will tell.
Recently, I learned a valuable lesson from what appeared as though it would be a regular Monday. My day started off routinely, but along the way some surprising events unfurled.
I was scheduled to go on-site with a federal customer for a “knowledge transfer” (aka OJT) as a new NOC/SOC team was coming online. When I got there, it started out as a rather typical meeting—get an understanding of the team’s knowledge of LogRhythm, assess their goals, and introduce them to any new features/products available.
Prior research led me to believe that this was an older deployment that had been neglected for some time. I was pleasantly surprised to find out that this was not the case. Rather, it was a rather new XM-6350 running LogRhythm 6.3.3 and the latest KB. Not having to perform a system upgrade was a relief.
However, as I listened to the customers’ requirements and dug into the deployment deeper, I quickly realized that the system was only being used for log collection, and rarely were people logging in or monitoring the data being collected by the XM. I’d say they were using about 30% of the LogRhythm features and functionality. Moreover, the WebUI wasn’t installed and AIE was disabled.
After a quick install of the WebUI, initialization of AIE, addition of the basic LOW/LOW-LOW rules found in the Post-Install Guide for POCs and setting up the third-party threat feeds (as well as some other customer requested tweaks)—the XM was back in fighting shape!
After a brief conversation, my sales rep and I started to walk the team through a quick demo using the customers XM, Data and WebUI. Within 10 minutes of talking, we happened to click on the Alarms tab, and to our surprise, we found some interesting data.
A few red alarm cards with ratings of 90 appeared denoting “Malware Found.” The team asked “What’s that all about?” We began to pivot drilldown and discovered the systems affected by the malware. Apparently this information was being reported by their Symantec and McAfee systems for quite some time and on the regular.
The NOC/SOC team quickly sprang into action to remedy the issue (albeit they were a bit annoyed). Moments later, we returned to the demo and another alarm fired with a score of 97. The team (almost in unison) said “What now!?”
After a quick drilldown, we discovered that their Fortinet deployment was reporting a breach coming from an “external IP” (outside the U.S.). Being that this was a government customer, we’d just tripped DEFCON-1 (and were called into the manager’s offices to explain the situation). The customer thanked us for helping to spot the external breach and asked us to leave for the day, as they were about to get very busy.
What was the lesson learned? Make sure that you always look under the hood of an existing LogRhythm deployment to verify that the basics have been covered. It’s important to understand what LogRhythm is capable of and how to best leverage the system to your advantage.
As one of the NOC/SOC employees put it, “If we’d been paying attention and using LogRhythm more regularly, we could have caught this sooner. Who knows how long we’ve been under attack.”
A typical Monday, indeed…
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.