There is only so much the DFIR analysis can do.
There it is, I said it. And it's especially true when the DFIR analysis is the result of external third party incident notification, which we ultimately determine to come months after the incident originally occurred.
Some artifacts exist forever. Until they don't. Some artifacts are recorded and exist for an unspecified and indeterminate period of time...nanoseconds, microseconds, weeks, or months. Processes execute, finish, and the memory they used is freed for use by another process. Text files exist until they are deleted, and the last modification times on the files remain the same until the next time they're modified. Windows Event Logs record events, but some event logs "roll over" more quickly than others; events in some may exist for only a few days, while events in others may exist for weeks or even months. As time passes, artifact clusters corrode to the point where, by the time DFIR analysts get the data for analysis, their ability to definitively answer questions is severely hampered.
The 2017 Ponemon Institute Data Breach Report indicates an average "dwell time" (the time between initial breach and discovery of the breach) of 191 days. The Nuix 2018 Black Report findings indicate that professional red teamers/pen testers report that they can target, compromise, and exfil data within 15 hrs. Hardly seems fair, particularly when you consider that if legitimate, scheduled pen tests go undetected, what chance do we have of detecting an unscheduled, uninvited intruder?
Some artifacts are created, are extremely transient (although they do exist), but are never recorded. An example of this is process command lines; if an adversary runs the "whoami" command as part of their initial attempts to orient themselves, that process exists for a very short time, and then the memory used gets freed for later use. By default, this is not recorded, so it ceases to exist very quickly, and the ceases to be available a short time later. The same is true when an intruder runs the command "net user /add" to create a user account on the system; the command runs, and the command line no longer exists. Yes, the user account is created, so the results of the command persist...but the command line itself, which likely included the password for the account, is no longer available. Finally, when the adversary stages files or data for exfiltration, many times they'll use rar.exe (often renamed) to archive the collected data with a password...the command line for the process will include the password, but once the command has completed, the plain text password issued at the command line is no longer available.
Several years ago, I was working a targeted threat response engagement, and we'd observed the adversary staging data for exfiltration. We alerted on the command line used...it was rar.exe, although the executable had been renamed. The full command line included the password that the adversary used, and was recorded by the EDR/MDR solution. We acquired an image of the system, and through analysis determined that the archive files were no longer visible within the "active" file system. As such, we carved unallocated space for RAR archives and were able to open the twelve archives we retrieved, using the password recorded in the command line used to archive the files. The web server logs definitively illustrated that the files had been exfiltrated (the IIS logs included the requested file name, number of bytes transferred, and the success code of "200"), and we had several of the archives themselves; other deleted archives have enough sectors overwritten that we were not able to successful recover the entire files.
That's a great example of how an EDR/MDR solution can be so powerful in today's world. Also, consider this recent Tanium blog post regarding the Samsam ransomware, the same ransomware family that recently hit the City of Atlanta...using the EDR/MDR solution to detect malicious actor activity prior to them deploying the ransomware, such as during their initial orientation and recon phase, means that you have a better chance of inhibiting, hampering, or completely obviating their end goal.
Finally, EDR/MDR solutions become budget items; I'm pretty sure that Equifax never budgeted for their breach, or budgeted enough. So, not only do you detect breaches early in the attack cycle, but with an IR plan, you can also respond in such a way as to prevent the adversary from accessing whatever it is they're after, obviating compliance and regulatory issues, notification, and keeping costs down.
Even More DFIR Brain Droppings…
Analysis
Something I’ve seen over the years that I’ve been interested in addressing is the question of “how do I analyze X?” Specifically, I’ll see or receive questions regarding analysis of a particular artifact on Windows systems, such as “…how do I analyze this Windows Event Log?” and I think that after all this time, this is a good opportunity to move beyond the blogosphere to a venue or medium that’s more widely accessible.
However, addressing the issue here, the simple fact is that artifacts viewed in isolation are without context. A single artifact, by itself, can have many potential meanings. For example, Jonathon Poling correctly pointed out that the RemoteConnectionManager/1149 event ID does not specifically indicate a successful login via Terminal Services; rather, it indicates a network connection. By itself, in isolation, any “definitive” statement made about the event, beyond the fact that a network connection occurred, amounts to speculation. However, if we know what occurred “near” that event, with respect to time, we can get enough information to provide come much needed context. Sure, we can add Security Event Log records, but what if (and this happens a lot) the Security Event Log only goes back a day or two, and the event you’re interested in occurred a couple of months ago? File system metadata might provide some insight, as would UserAssist data from user accounts. As you can see, as we start adding specific data sources…not willy-nilly, because some data sources are more valuable than others under the circumstances…we begin to develop context around the event of interest.
The same can be said for other events, such as a Registry key LastWrite time…this could indicate that a key was modified by having a value added, or deleted, or even that the key had been created on that date/time. In isolation, we don’t know…we need more context. I generally tend to look to the RegBack folder, and then any available VSCs for that additional context. Using this approach, I’ve been able to determine when a Registry key was most likely modified, versus the key being created and first appearing in the Registry hive.
As such, going back to the original questions, I strongly recommend against looking at any single artifact in isolation. In fact, for any artifact with a time stamp, I strongly recommend developing a timeline in order to see that event in context with other events.
LNK Shell Items…what’s old is new again
It’s great to see LNK Shell Items being discussed on the Port139 blog, as a lot of great stuff is being shared via the blog. It’s good to see stuff that’s been discussed previously being raised and discussed again, as over time, artifacts that we don’t see a lot of get forgotten and it’s good to revisit them. In this case, being able to parse LNK files is a good thing, as adversaries are using LNK files for more than just simple persistence on systems. For example, they’ve have been observed sending LNK files to their intended victims, and as was described by JPCERT/CC about 18 months ago, those files can provide clues to the adversary’s development environment. LNK files have been sent as attachments, as well as embedded in OLE objects; both can be parsed to provide insight into not just the adversary’s development environment, but also potentially to track a single actor/platform used across multiple campaigns.
Another use for parsing LNK files is that adversaries can also use them for maintaining the ability to return to a compromised environment, by modifying the icon filename variable to point to a remote system. The adversary records and decrypts authentication attempt, and gets passwords that may have changed.
Something else that hasn’t been discussed in some time is the fact that shell items can be used to point to devices attached to a system. Sure, we know about USB devices, but what about digital cameras, and being able to determine the difference between possession of images, and production?
EDR Solutions
Something I’ve encountered fairly regularly throughout my DFIR experience is Locard’s Exchange Principle. I’ve also blogged and presented on the topic, as well. Applied to DFIR, this means that when an adversary connects to/engages with a system on a compromised infrastructure, digital material is exchanged between the two systems. Now, this “digital material” may be extremely transient and persist for only a few micro-seconds, but the fact is that it’s there. As most commercial operating systems are not created with digital forensics and incident response in mind, most (if not all) of these artifacts are not recorded in any way (meaningful or otherwise). This is where EDR solutions come in.
For the sake of transparency, I used to work for a company that created endpoint technology that was incorporated into its MSSP offering. My current employer includes a powerful EDR product amongst the other offerings within their product suite.
For something to happen on a system, something has to be executed. Nothing happens, malicious or otherwise, without instructions being executed by the CPU. Let’s say that an adversary is able to get a remote access Trojan (RAT) installed on a system, and then accesses that system. For this to occur, something needed to have happened, something that may have been extremely transient and fleeting. From that point, commands that the adversary runs to, say, perform host and network reconnaissance, will also be extremely transient.
For example, one command I’ve seen adversaries execute is “whoami”. This is a native Windows command, and not often run by normal users. While the use of the tool is not exclusive to adversaries, it’s not a bad idea to consider it a good indicator. When the command is executed, the vast majority of the time involved isn’t in executing the command, but rather in the part of the code that sends the results to the console. Even so, once the command is executed, the process block in memory is freed for use by other processes, meaning that even after a few minutes, without any sort of logging, there’s no indication that this command was ever executed; any indication that the adversary ran the command is gone.
Now, extend this to things like copy commands (i.e., bad guy collects files from the local system or remote shares), archival commands (compressing the collected files into a single archive, for staging), exfiltration, and deletion of the archive. All of these commands are fleeting, and more importantly, not recorded. Once the clean-up is done, there’re few, if any, artifacts to indicate what occurred, and this is something that, as many DFIR practitioners are aware, is significantly impacted by the passage of time.
This is where an EDR solution comes in.
The dearth of this instrumentation and visibility is what leads to speculation (most often incorrect and over exaggerated) about the “sophistication” of an adversary. When we don’t see the whole picture, because we simply do not accept the fact that we do not have the necessary instrumentation and visibility, we tend to fill the gaps in with assumption and speculation. We’ve all been in meetings where someone would say, “…if I were the attacker, this is what I would do…”, simply because there’s no available data to illustrate otherwise. Also, it’s incredibly easy under such circumstances for us to say that the attacker was “sophisticated”, when all they really did was modify the hosts file, and then create, run, and then delete an FTP script file.
Why does any of this matter?
Well, for one, current and upcoming legislation (i.e., GDPR) levies ‘cratering’ fines for breaches; that is, fines that have what can be a hugely significant impact on the financial status of a company. If we continue the way we’re going now…receiving external notification of an intrusion weeks or months after the attack actually occurred…we’re going to see significant losses, beyond what we’re seeing now. Beyond paying for a consulting firm (or multiple firms) to investigate the breach, along with loss of productivity, reporting/notification, law suits, impact to brand, drop in stock price, etc…now there are these huge fines.
Oh, and the definition of a breach includes ransomware, so yeah…there’s that.
And all of these costs, both direct and indirect, are included in the annual budget for companies…right? We sit down at a table each year and look at our budget, and take a swag…we’re gonna have five small breaches and one epic “Equifax-level” breach next year, so let’s set aside this amount of money in anticipation…that actually happens, right?
Why not employ an EDR solution? It’s something you can plan for, include in your budget…costs are known ahead of time. The end result is that you detect breaches early in the attack cycle, obviating the need to report. In addition, you know have the actual data to definitively demonstrate that ‘sensitive data’ was NOT accessed, so why would you need to notify? If client data is not accessed, and you can demonstrate that, why would you need to notify?
Recently, following a ransomware attack, an official with a municipality in the US stated that there was “no evidence” that sensitive data was accessed. What should have been said was that there was simply no evidence…the version of ransomware that impacted that municipality was one that is not email-borne; delivery of the ransomware required that someone access the infrastructure remotely, locate the servers, and deploy the ransomware. If all of this occurred and no one noticed until the files are no longer accessible and the ransom note was displayed, how can you then state definitively that sensitive data was not accessed?
You can’t. All you can say is that there is “no evidence”.
It’s almost mid-year 2018…if you don’t already have a purchase of an EDR product planned, rest assured that you’ll be part of the victim pool in the coming year.
More DFIR Brain Droppings
Ransomware (TL;DR)
This past week, the City of Atlanta was hit with ransomware. This is not unusually...I've been seeing a lot of municipalities in the US...cities, counties, etc...getting hit, since last fall. Some of them aren't all that obvious to anyone who isn't trying to obtain government services, of course, and the media articles themselves may not be all that easy to find. Here are just a few examples:
Mecklenburg County update
Spring Hill, TN update
Murfreesboro, TN update
Just a brief read of the above articles, and maybe doing a quick Google search for other articles specific to the same venues will quickly make it clear how services in these jurisdictions are affected by these attacks.
The ArsTechnica article that covered the Atlanta attack mentioned that the ransomware used in the attack was Samsam. I've got some experience with this variant, and Kevin Strickland wrote a great blog post about the evolution of the ransomware itself, as well. (Note: both of those blog posts are almost 2 yrs old at this point). The intel team at SWRX followed that up with some really good information about the Samas ransomware campaigns recently. The big take-away from this is that the Samsam (or Samas) ransomware has not historically been email-borne. Instead, it's delivered (in most cases, rather thoughtfully) after someone has gained access to the organization, escalated privileges (if necessary), located the specific systems that they want to target, and then manually deployed the ransomware. All of these actions could have been detected early in the attack cycle. Think of it this way...instead of being delivered via mail (like a letter), it's more like Amazon delivery folks dropping the package...for something that you never ordered...off in your house...only you didn't have one of those special lock-and-camera combinations that they talked about, there was just a door or window left open. Yeah, kind of like that.
On the topic of costs, the CNN article includes:
The Federal Bureau of Investigation and Department of Homeland Security are investigating the cyberattack...
...and...
The city engaged Microsoft and a team from Cisco's Incident Response Services in the investigation...
Okay, so we're getting a lot of help, that's good. But they're getting a lot of help, and that's going to be expensive.
Do you, the reader, think that when the staff and leadership for the City of Atlanta sat down for their budget meetings last year, that they planned for this sort of thing? When something like this occurs, the direct costs include not only the analyst's time, but food, lodging, etc. Not only does it add up over time, but it's multiplied...$X per analyst per day, times Y analysts, times Z days.
From the USAToday article on the topic:
Such attacks are increasingly common. A report last year from the Ponemon Institute found that half of organizations surveyed had had one or more ransomware incidents in 2017, and 40% had experienced multiple attacks.
An IBM study found that 70% of businesses have been hit with ransomware. Over half of those paid more than $10,000 to regain their data and 20% paid more than $40,000.
In January, an Indiana hospital system paid a $50,000 ransom to hackers who hijacked patient data. The ransomware attack accessed the computers of Hancock Health in Greenfield through an outside vendor's account Thursday. It quickly infected the system by locking out data and changing the names of more than 1,400 files to "I'm sorry."
Something else that's not addressed in that Ponemon report, or at least not in the quote from the USAToday article, is that even when the ransom is paid, there's no guarantee that you'll get your files back. Just over a year ago, I did some DFIR analysis work for a client that paid the ransom and didn't get all of their files back, and the paid us to come in and try to provide some answers. So the costs are stacking up.
What about other direct and/or indirect costs associated with ransomware attacks? There are hits to productivity and the ability to provide services, costs of downtime, costs to bring consultants in to assist in discovery and recovery, etc. While we don't have the actual numbers, we can see these stacking up. But what about other costs? Not too long ago, another municipality got hit with ransomware, and a quote from one of the articles was along the lines of, "...we have no evidence that sensitive information was accessed."
Yes, of course you don't. There was no instrumentation, nor visibility, to detect the early stages of the attack, and as a consequence, no evidence of anything about the attack was recorded. On the surface that sounds like a statement meant to comfort those whose personal data was held by that organization, but focusing just 1nm beyond that statement reveals an entirely different picture; there is "no evidence" because no one was watching.
So what can we expect to see in the future? We're clearly going to see more of these attacks, because they pay; there is a monetary incentive to conducting these attacks, and an economic benefit (to the attacker) for doing so. As such, there is no doubt in my mind that two things are going to happen; one is that with the advent of GDPR and other similar legislation, this is going to open up a whole new avenue for extortion. Someone's going to gain access to an infrastructure, collect enough information to have solid proof that they've done so, and use that as their extortion. Why is this going to work? Because going public with that information is going to put the victim organization in the legislative spotlight in a way that they will not be able to avoid.
The other thing that's going to happen is that when statements regarding access to 'sensitive data' are made, there are going to be suits demanding proof. I don't think that most individuals (regardless of country) have completely given up on "privacy" yet. Someone...or a lot of someones...is/are going to go to court to demand definitive answers. A hand-waving platitude isn't going to be enough, and in fact, it's going to be the catalyst for more questions.
Something else I thought was pretty interesting from the CNN article:
When asked if the city was aware of vulnerabilities and failed to take action, Rackley said the city had implemented measures in the past that might have lessened the scope of the breach. She cited a "cloud strategy" to migrate critical systems to secure infrastructure.
This is a very interesting question (and response), in part because I think we're going to see more of questions just like this. We will never know if this question was a direct result of the Equifax testimony (by the former CEO, before Congress), but I do think that it's plausible enough to assume that that's the case.
And the inevitable has occurred...the curious have started engaging in their own research and posted their findings publicly. Now, this doesn't explicitly mean that this is the avenue used by the adversary, but it does speak to the question from the CNN article (i.e., "...were you aware of vulnerabilities...").
Attacker Sophistication
Here's a fascinating GovTech article that posits that some data breaches may be the result of professional IT pride. As I read through the article, I kept thinking of the Equifax breach, which reportedly occurred for want of a single patch, and then my mind pivoted over to what was found recently via online research conducted against the City of Atlanta.
From the article, "...it’s sometimes an easy out to say: “the bad guys are just too good.” " Yes, we see that a lot...statements are made without qualification about the "sophisiticated" attacker, but for those of us who've been in the trenches, analyzed the host and log data, and determined the initial avenue that the attacker used to get into the infrastructure...how "sophisticated" does one have to be to guess that password for an Internet-accessible Terminal Services/RDP account when that password is on every password list? Or to use a publicly available available exploit against an unpatched, unmanaged system? "Hey, here's an exploit against JBoss servers up through and including version 6, and I just found a whole bunch of JBoss servers running version 4...hold my beer."
In my experience, the attacker only needs to be as sophisticated as he needs to be. I worked an engagement once where the adversary got in, collected and archived data, and exfiltrated the archive out of the infrastructure. Batch files were left in place, and the archive was copied (not moved) from system to system, and not deleted from the previous location. The archive itself didn't have a password on it. Someone said that the adversary was sloppy and not sophisticated. However, the client had been informed of the breach via third party notification, weeks after the data was taken.
Tool Testing
Daniel Bohannon has a great article up about testing your tools.
I'd like to add to his comments about tool testing...specifically, if you're going to effectively test your tools, you need to understand what the tools do (or at least what they're supposed to do...) and how they work. Perhaps not at a bit-level (you don't have to be the tool developer), but there are some really simple troubleshooting steps you can follow if you have an issue with a tool and you feel that you want to either ask a question, or report the issue.
For one...and Jamie Levy can back me up on this..."don't work" don't work. What I mean is, if you're going to go to a tool developer (or you're going to bypass the developer and just go public), it's helpful to understand how the tool works so that you can describe how it appears to not be working. A long time ago, I learned that Volatility does NOT work if the 8Gb memory dump you received is just 8Gb of zeroes. Surprising, I know.
Oddly enough, the same is true for RegRipper; if you extract a hive file from an image, and for some reason it's just a big file full of zeroes, the RegRipper will through errors. This is also true it you use reg.exe to export hive files, or portions thereof. RegRipper is intended to be run against the raw hive file, NOT text files with a .reg extension. Instead of using "reg export", use "reg save".
The overall point is that it's important to test the tools you're using, but it's equally important to understand what the tools are supposed/designed to do.
Rattler
Speaking of tools, not long ago I ran across a reference to Rattler, which is described as, "...a tool that automates the identification of DLL's which can be used for DLL preloading attacks." Reading through the blog post that describes the issue that Rattler addresses leads me to believe that this is the DLL search order hijacking issue, in that if you have malicious DLL in the same folder as the executable, and the executable calls a DLL with the same name that's found in another folder (i.e., C:\Windows\system32), then your malicious DLL will be loaded before the legit DLL.
This past week, the City of Atlanta was hit with ransomware. This is not unusually...I've been seeing a lot of municipalities in the US...cities, counties, etc...getting hit, since last fall. Some of them aren't all that obvious to anyone who isn't trying to obtain government services, of course, and the media articles themselves may not be all that easy to find. Here are just a few examples:
Mecklenburg County update
Spring Hill, TN update
Murfreesboro, TN update
Just a brief read of the above articles, and maybe doing a quick Google search for other articles specific to the same venues will quickly make it clear how services in these jurisdictions are affected by these attacks.
The ArsTechnica article that covered the Atlanta attack mentioned that the ransomware used in the attack was Samsam. I've got some experience with this variant, and Kevin Strickland wrote a great blog post about the evolution of the ransomware itself, as well. (Note: both of those blog posts are almost 2 yrs old at this point). The intel team at SWRX followed that up with some really good information about the Samas ransomware campaigns recently. The big take-away from this is that the Samsam (or Samas) ransomware has not historically been email-borne. Instead, it's delivered (in most cases, rather thoughtfully) after someone has gained access to the organization, escalated privileges (if necessary), located the specific systems that they want to target, and then manually deployed the ransomware. All of these actions could have been detected early in the attack cycle. Think of it this way...instead of being delivered via mail (like a letter), it's more like Amazon delivery folks dropping the package...for something that you never ordered...off in your house...only you didn't have one of those special lock-and-camera combinations that they talked about, there was just a door or window left open. Yeah, kind of like that.
On the topic of costs, the CNN article includes:
The Federal Bureau of Investigation and Department of Homeland Security are investigating the cyberattack...
...and...
The city engaged Microsoft and a team from Cisco's Incident Response Services in the investigation...
Okay, so we're getting a lot of help, that's good. But they're getting a lot of help, and that's going to be expensive.
Do you, the reader, think that when the staff and leadership for the City of Atlanta sat down for their budget meetings last year, that they planned for this sort of thing? When something like this occurs, the direct costs include not only the analyst's time, but food, lodging, etc. Not only does it add up over time, but it's multiplied...$X per analyst per day, times Y analysts, times Z days.
From the USAToday article on the topic:
Such attacks are increasingly common. A report last year from the Ponemon Institute found that half of organizations surveyed had had one or more ransomware incidents in 2017, and 40% had experienced multiple attacks.
An IBM study found that 70% of businesses have been hit with ransomware. Over half of those paid more than $10,000 to regain their data and 20% paid more than $40,000.
In January, an Indiana hospital system paid a $50,000 ransom to hackers who hijacked patient data. The ransomware attack accessed the computers of Hancock Health in Greenfield through an outside vendor's account Thursday. It quickly infected the system by locking out data and changing the names of more than 1,400 files to "I'm sorry."
Something else that's not addressed in that Ponemon report, or at least not in the quote from the USAToday article, is that even when the ransom is paid, there's no guarantee that you'll get your files back. Just over a year ago, I did some DFIR analysis work for a client that paid the ransom and didn't get all of their files back, and the paid us to come in and try to provide some answers. So the costs are stacking up.
What about other direct and/or indirect costs associated with ransomware attacks? There are hits to productivity and the ability to provide services, costs of downtime, costs to bring consultants in to assist in discovery and recovery, etc. While we don't have the actual numbers, we can see these stacking up. But what about other costs? Not too long ago, another municipality got hit with ransomware, and a quote from one of the articles was along the lines of, "...we have no evidence that sensitive information was accessed."
Yes, of course you don't. There was no instrumentation, nor visibility, to detect the early stages of the attack, and as a consequence, no evidence of anything about the attack was recorded. On the surface that sounds like a statement meant to comfort those whose personal data was held by that organization, but focusing just 1nm beyond that statement reveals an entirely different picture; there is "no evidence" because no one was watching.
So what can we expect to see in the future? We're clearly going to see more of these attacks, because they pay; there is a monetary incentive to conducting these attacks, and an economic benefit (to the attacker) for doing so. As such, there is no doubt in my mind that two things are going to happen; one is that with the advent of GDPR and other similar legislation, this is going to open up a whole new avenue for extortion. Someone's going to gain access to an infrastructure, collect enough information to have solid proof that they've done so, and use that as their extortion. Why is this going to work? Because going public with that information is going to put the victim organization in the legislative spotlight in a way that they will not be able to avoid.
The other thing that's going to happen is that when statements regarding access to 'sensitive data' are made, there are going to be suits demanding proof. I don't think that most individuals (regardless of country) have completely given up on "privacy" yet. Someone...or a lot of someones...is/are going to go to court to demand definitive answers. A hand-waving platitude isn't going to be enough, and in fact, it's going to be the catalyst for more questions.
Something else I thought was pretty interesting from the CNN article:
When asked if the city was aware of vulnerabilities and failed to take action, Rackley said the city had implemented measures in the past that might have lessened the scope of the breach. She cited a "cloud strategy" to migrate critical systems to secure infrastructure.
This is a very interesting question (and response), in part because I think we're going to see more of questions just like this. We will never know if this question was a direct result of the Equifax testimony (by the former CEO, before Congress), but I do think that it's plausible enough to assume that that's the case.
And the inevitable has occurred...the curious have started engaging in their own research and posted their findings publicly. Now, this doesn't explicitly mean that this is the avenue used by the adversary, but it does speak to the question from the CNN article (i.e., "...were you aware of vulnerabilities...").
Attacker Sophistication
Here's a fascinating GovTech article that posits that some data breaches may be the result of professional IT pride. As I read through the article, I kept thinking of the Equifax breach, which reportedly occurred for want of a single patch, and then my mind pivoted over to what was found recently via online research conducted against the City of Atlanta.
From the article, "...it’s sometimes an easy out to say: “the bad guys are just too good.” " Yes, we see that a lot...statements are made without qualification about the "sophisiticated" attacker, but for those of us who've been in the trenches, analyzed the host and log data, and determined the initial avenue that the attacker used to get into the infrastructure...how "sophisticated" does one have to be to guess that password for an Internet-accessible Terminal Services/RDP account when that password is on every password list? Or to use a publicly available available exploit against an unpatched, unmanaged system? "Hey, here's an exploit against JBoss servers up through and including version 6, and I just found a whole bunch of JBoss servers running version 4...hold my beer."
In my experience, the attacker only needs to be as sophisticated as he needs to be. I worked an engagement once where the adversary got in, collected and archived data, and exfiltrated the archive out of the infrastructure. Batch files were left in place, and the archive was copied (not moved) from system to system, and not deleted from the previous location. The archive itself didn't have a password on it. Someone said that the adversary was sloppy and not sophisticated. However, the client had been informed of the breach via third party notification, weeks after the data was taken.
Tool Testing
Daniel Bohannon has a great article up about testing your tools.
I'd like to add to his comments about tool testing...specifically, if you're going to effectively test your tools, you need to understand what the tools do (or at least what they're supposed to do...) and how they work. Perhaps not at a bit-level (you don't have to be the tool developer), but there are some really simple troubleshooting steps you can follow if you have an issue with a tool and you feel that you want to either ask a question, or report the issue.
For one...and Jamie Levy can back me up on this..."don't work" don't work. What I mean is, if you're going to go to a tool developer (or you're going to bypass the developer and just go public), it's helpful to understand how the tool works so that you can describe how it appears to not be working. A long time ago, I learned that Volatility does NOT work if the 8Gb memory dump you received is just 8Gb of zeroes. Surprising, I know.
Oddly enough, the same is true for RegRipper; if you extract a hive file from an image, and for some reason it's just a big file full of zeroes, the RegRipper will through errors. This is also true it you use reg.exe to export hive files, or portions thereof. RegRipper is intended to be run against the raw hive file, NOT text files with a .reg extension. Instead of using "reg export", use "reg save".
The overall point is that it's important to test the tools you're using, but it's equally important to understand what the tools are supposed/designed to do.
Rattler
Speaking of tools, not long ago I ran across a reference to Rattler, which is described as, "...a tool that automates the identification of DLL's which can be used for DLL preloading attacks." Reading through the blog post that describes the issue that Rattler addresses leads me to believe that this is the DLL search order hijacking issue, in that if you have malicious DLL in the same folder as the executable, and the executable calls a DLL with the same name that's found in another folder (i.e., C:\Windows\system32), then your malicious DLL will be loaded before the legit DLL.
- « Previous Page
- 1
- 2
- 3
- 4
- 5
- …
- 51
- Next Page »