Blocking Shodan | Keeping in the dark from scanning

A update to this post will be made this week on automating the shodan blocking. 2017-07-10 The images are broken while I migrate the solution. 

In the last few days of writing this post there has also been a massive amount of mongoDB installs that have been hacked. For more info in preparing for data breaches see my previous post on 3-2-1-0day rule for backups. While shodan is not responsible for this generating a largest list via their service is trivial for whatever service you have a exploit for. So it may not be a bad idea to try and keep away from the all seeing eye Shodan is. While there are arguments on both sides that shodan helps identify issues as well as identify targets I think its best if we had the option to opt out. Thus,

The Definitive Guide to Blocking Shodan from scanning.

First we need to identify the list of IPs that Shodan sends scans from, this are commonly from their census servers but can come from other hosts they control as well. Below is a list of the domains and IP addresses I have collected online, and monitored scanning my equipment. - US - US - US - NL RO US US US US IS IS US DE DE DE US US US - US US US US * US US **
host , ***

Last updated: 2017-05-25

*Probably not a scanner
**Their main website, don’t block prior to running tests below / at all if needed
***Consistently appeared when forcing a scan on my own host details below

Now how can you trust that these are the IP address owned by and not randomly selected by just reversing DNS? Easy!
Shodan does not want you to know where its scanners are located on the internet, and this makes sense since their business model revolves around it. To help hide the servers IPs they scan from shodan automatically censors its own IP addresses in results. Here is a random example of what the returned data looks like:

They replace their own IPs with this is done prior to us ever getting the data. Even if you get raw firehose access to the scan results it is still censored prior to being given to the customer.

(example from firehose demo on their blog)

Due to this we can simply search any IP or domain name we think it operated by a Shodan scanner in Shodan! They will appear as see the below example.

That’s great, now how do I check and make sure that Shodan cannot reach my host.
First block the IPs listed, I would recommend you check them first to ensure they are up to date but as of 2017-01-12 this is the most complete and accurate list available comapred to older postings I have found.

Then you have two options, you can sign up for a paid account and force a scan on your host, or you can simply wait and check your IP periodically from the web interface for free: [ip here] under the last update field.

Since I already am a paid Shodan member I can test my block list right away. This is done by installing Shodan instruction can be found here.

Once installed you want to initiate an on demand scan of your IP. A working example can be found below:

But if you have successfully blocked Shodan you will see the following alert when attempting the scan, the left is my terminal the right is the firewall dropping the connection.

Testing over multiple days I always got the same result.

To ensure it was not just that I had scanned to close together I had tested another one of my hosts that had not been blocked and the Last Update was close to real time. You can also check when your host was last scanned using the following command:

You can see that since putting my IP block in place I have not been manually scanned at any of the two previous attempts. The dates are also listed when you were last scanned with sucsess. You can also see when the first time Shodan picked up your MongoDB or whatever else you run on that IP.

Shodan is definitely a useful tool, and will help admins who dont realize what is exposed to the internet find out their weak points. It is also very useful for vulnerability assessments and getting metrics about services from the internet as whole. But it is also like all good things used by people who want to exploit the data within for personal gain or entertainment.

There are literally hudreds of thousands of interesting and exploitable items on shodan, just dont be one of them.

Taking Paypals 0$ invoice one step further.

Recently I saw a article on Bruce Schneier’s page regarding a spam vector identified by Troy Hunt where a user can send you a 0$ invoice. While this may seem like an annoyance and not a very big issue I see it as a spear fishing vector when used in conjunction with infected pc’s.

Imagine your PC has been infected with a RAT or trojan virus, or someone has a vendetta against you and decided to send you a malicious url that contains one of the many flash or java drive by exploits around the net today to infect you.

Sure they have access to your PC and can see what you can see, they can also tell when your active but that does not give them full access to your banking. Until they send you a 0$ bill. The infected user then goes to paypals site to inspect the payment and you capture their login credentials as they sign in. You basically set them up for failure.

I have yet to find record of this happening but I did however find an example on twitter of someone being sent 20$ then subsequently being ‘hacked’ the same day.


While the attacker could have gained credentials from a leak or paste, why would they send the user 20$ ? This would serve no other purpose and leave a paypal-ish money trail when now they could simply send a 0$ invoice.

2015 – Year of the dumps | With big data, comes big leaks.

Year of the Dumps – 2015 | It has been a interesting year for monitoring data dumps. The biggest being the fact that the news has been following it closer as well. The largest story being Ashley Madison, it will be included in what I feel will be the closest thing this site will ever have to a threat assessment containing over 100 dumps from various sources around the web. I don’t want to focus on how these are pulled off or specifically call a few grey market startups out but rather I want to give a overall idea on the status of the dump industry, targets, and direction it may be heading.

Without getting into the paper too much here are a few items it covers:
-100 Dumps from various sites
-Break down of industry targeted, language, and encryption used.
-Developments and strategies used by individuals with the dumped data for economic gain.
While this servers to give an idea or a snapshot of what kind of industies are vurnable it does not scratch the surface on the information if it was possible to capture all the dumps from 2015. Thus only 100 were chosen (Dont worry its still about 537,879 users not counting hand picked ones).
The paper also covers

See below for my paper titled : Year of the Dumps – 2015


Bitlocker adds support for XTS-AES 256-bit in Windows 10!

Good news since my last article windows has added support for drive encryption for up to XTS-ARS 256-bit. Provided you are using a Windows 10 machine that is updated past 1511 or later.


Currently there is no way to change the level of encryption for drives that are already encrypted. So you will need to disable bitlocker , set the GPO as written in my previous article and then encrypt the disk.


This version is available from windows update or from the newest MSDN image.

Just be aware of a few things, removable drives will not work on previous versions of Windows 10. And there is currently an issue with SEDs and Bitlocker so steer clear if you are using them.

Politcal doxing and corporate accountability.

Doxing (Wikipedia)

Doxing (from dox, abbreviation of documents), or doxxing,is the Internet-based practice of researching and broadcasting personally identifiable information about an individual.

The methods employed to acquire this information include searching publicly available databases and social media websites (like Facebook), hacking, and social engineering. It is closely related to internet vigilantism and hacktivism.

Doxing may be carried out for various reasons, including to aid law enforcement, business analysis, extortion, coercion, harassment, online shaming and vigilante justice.

Both Bruce Schneier and Brian Krebs have written excellent articles this week that I feel need to cross paths. If you have not read them yet, its ok I’ll wait.

We all know Lizard Squad happened last year but I feel that the COX fines mentioned in Brian’s article is a precursor for a standard procedure that will be eventually filed against AOL regarding the CIA Director John Brennan dox.

In short, Lizard Squad was a group of internet antagonists (DDoS) that used social engineering in order to gain access to accounts that belonged to 60 COX cable members. These were used for doxing and impersonation. Some see social engineering as simply a method for getting personal data but it is often used for privilege escalation to gain access to more accounts from celebrities to disliked bosses. A gateway hack, if it were.

What is interesting is that COX is actually being held accountable for this issue. Mostly due to the fact they had access to private information that they improperly gave the Lizard Squad members access to. This is important in two ways.

-It shows that social engineering works well enough that your front line personnel need to be aware, even Janet in the call center. 

-It should scare the shit out of IT admins who do not keep up to date with patching and security practices if a company can be liable for how the data is stored and who has access these types of decisions would have been held by the CTO or CSO. But generally systems are set up, tested, and put into production with security as an afterthought  But that’s a conversation for another time.

If COX can be fined for 595,000.00 $ for being tricked into giving access to a member of Lizard Squad to their customers data. I have a feeling AOL has one of these coming too after the more recent CIA Director John Brennan incident. The COX fine is just the beginning of how organizations need to wake up and handle their customers and employees data or this is not going away any time soon.


Increase bitlocker cypher strength to AES 256 | Plus automated drive dismounting!

Bitlocker is good. Im not going to say great but good as in good enough to get the job done while giving users a relatively safe encryption suite built right into Microsoft that will keep your files (when implements properly) safe from people who may want access to your pc or laptop. Millage may vary when dealing with government entities.

However did you know that Bitlocker has various settings that can be configured to increase overall security? If your using the default settings take a look below:

Problem: How do I set bitlocker up to be more secure?

Solution: Change the cipher strength higher.
Before I show you how I want to make something clear and apparent. Assume everything you encrypt can be decrypted, it is just a matter of time. This does not mean don’t encrypt… it just means that encryption will only buy you time when dealing with government entities now, or a passionate individual with a 32 GPU cluster and a vendetta.

Either way more security is always better than none at all. Back on task!

First we need to set the cipher strength, if you have already encrypted the drive you will need to do it again. Open up gpedit.msc with Start > Run > gpedit.msc

Once you have it open expand the following tree:

Here you will see various options but the one we want is: Choose drive encryption and cipher strength. Set it to Enabled and choose from the dropdown AES 256-bit.

Once this is set press OK. There you go, now you will need to set back up bitlocker, it is assumed you have done this already if not head on over to MS and they will provide you with instructions.

BONUS ROUND! How can I automatically dismount encrypted bitlocker drives?

Don’t forget to error is human! Leaving your drives mounted could lead to unforeseen consequences if you are visited late at night buy unsavory officials, someone breaks into your house / hotel room, or steals your laptop. With the drives left mounted the keys are both in memory, and the drives accessible. They do not lock until you reboot.

So how can you solve this? Easy, create a scheduled task in order to lock the drive after a predefined time of idleness or on a schedule.

First hit start > type in Task Scheduler and open it up.

Next Right Click and choose Create Basic Task.. don’t worry we will change it during the setup process.

Give it a name and a snazzy description.

The next two windows are at your discretion fill out based off needs seeing as they have to do with how often the job will run. You will be eventually asked What action do you want the task to perform? Choose Start a program.

The next window you will want to paste in:
manage-bde.exe -lock -ForceDismount E:

E: is the drive letter you want to lock with bitlocker, you need to customize this to your own setup. Windows will tell you your dome and don’t know proper syntax. This is fine for the sake of not wanting two screenshots in the article it windows will do it for you if you hit Yes.

Voila! Hit Next and your done! You have not just increased the security of your bitlocker setup with minimal effort but maximum gain.

Here is a list of other BitLocker command options in case your interested.

To encrypt or not to encrypt. Is there a easy solution?

Here is a interesting article from Joseph Cox on encryption in the home and how well it stands up. Despite no sources being listed it gives what I consider a comprehensive look at the problem at hand of layering your encryption.

“This way, if you are stopped and forced to decrypt your hard-drive, your adversary is going to only have access to what you have deliberately stored on that computer. If your PGP secret key is stashed at home, or the leak you were provided with is on a computer elsewhere, your adversary isn’t going to get hold of them. But if you didn’t take this precaution, they are likely to gain access to everything: articles in progress, notes, interview transcripts, the lot.”


THC Hydra Remote Desktop Bruteforce Example | A lesson in Network Level Security

This write up has a disclaimer at the bottom that you agree to prior to reading any other content on this post.

Today I asked myself, what is my attack surface, and how can I lower it. One function that computer admins love is remote desktop. It is amazing. It makes life so easy we would be willing to make security exceptions just to have it such as forwarding a port to be able to use it.


The problem with remote desktop is that it opens a very real security risk to our network, assume you are an admin on your box and someone was able to gain access to your RDP without you knowing. That box is connected to you home network where photos and excel sheets of budgets and CC info lay. Priceless videos of kids and important PDFs of job applications, let alone backups of those items. Drobo’s , media centers, installed apps with remember my password checked and whatnot. These are all things that a would be bruteforcer might want.

So in here lies the problem… I will split this into two problems but they have a single solution.

Problem: I want remote desktop access, but I want to mitigate as many risks as possible when I expose myself to the WAN. If you don’t care about the bruteforce guide you can skip to the solution below.

Problem: I would like to see how a bruteforce attack would work against a RDP connection so I can better defend against it.

First of all you will need a few pieces of software to get started.
-A Linux Box (Windoze can be substituted but this is beyond the scope of this guide)
-THC Hydra that can be download here.
-A word list (You can make one when we get to that point for the example)
-A target windows host that is able to accept RDP connections

THC Hydras logo

Once you have your Linux box up and running you need to install THC Hydra, download and extract it. The application requires assembly via make so change directory to the extracted files.

Type in:


make install
This may need to be sudo make install depending on you level of access / where you are working

Once completed if you put in ls you should see a green hydra file. This what we will be using from now on.

Next we need to make a word list. This is the list that hydra will use against the remote host, it will contain passwords only. To save on room I have made the simplified list below, your list will be custom to you testing as it needs to contain at least one correct password.

Open up nano by typing: nano wordlist.txt

Enter in the following lines:

The password that my test box has for it is the word password I have placed it in the middle since I don’t want to make this too easy. Press Ctl+X to save the file.

Now we want to execute the attack, you will need the victims *ahem* test boxes IP address as well ass the assumed username, generally there is a administrator account, however if you are testing a domain / specific target you may want to change this.

Enter in the command:
hydra -t 1 -V -f -l administrator -P wordlist.txt rdp://

Ok les break this down nice and quick:
hydra – The program assembled we via make.
-t 1 – Tasks set to 1, good enough for a VM but you can up it if you have a physical pc dedicated to this, too many threads will yield false results. Play with it.
-V – verbose, give me all output while you work
-f – quit once you found a positive user:pass match
-l administrator – use the username admin to attempt to login
-P wordlist.txt – This is the word list that we will be pulling passwords from.
rdp:// – This is the target IP, customize to your liking attacks can be carried out over the WAN.

But my client is using port 3390, or 3391 or some other arbitrary port that they should not be using in the predefined port range! …No problem simply use the -s option followed by the port number to specify.

Your output will say something along the lines of:
[ATTEMPT] target – login “administrator” – pass “123456” …
[ATTEMPT] target – login “administrator” – pass “654321” …
[ATTEMPT] target – login “administrator” – pass “admin” …
[3389][rdp] host login: administrator  password: admin
[STATUS] attack was finished…

*Note: The user will be kicked to the lock screen if you get a successful user:pass while they are using the computer.

If your attack did not work, then its probably due to windows firewall being enabled or Network Level Authentication being set to on. I cover this in the solutions section below.

Solution: Enable Network Level Authentications, don’t use basic authentication.
This can be overlooked due to the fact when most users set up RDP they just want it to work, this is the problem with RDP. Scrubs spend so much time just trying to get it to work and think about security after so they choose (more compatible) when they set it up not (more secure). So by changing this setting you force the client to authenticate before making the RDP connection so that THC Hydra will fail. Interesting side not is it does not fail, it just sees all passwords as wrong. This setting will cause issues with services in a win/linux environment that use services like xrdp.

Another solution is to move the RDP port to something more obscure like 50001, this maybe not be obscure but most of the utilities i looked at automatically try ports 3389 (RDPs default) 3390 and 3391.

The final and more annoying but secure option is to look into 2FA or two factor authentication. This provides two kinds of protection, one that only the user with the device can log in, and notification when a user attempts to log in but is unsuccessful. This will help you gauge the amount of RDP attempts without having to look at the event viewer. Duo Security is not too bad I have used them in the past and they offer free accounts to non corporate users.

How ever implementing 2FA in you organization may be difficult so you may have to rely on event log. To do this I highly recommend Overseer Network Monitor, this is not an ad, or a scare and but tactic. I love this product, we used it in my previous environment and I would love it where I am working now. It allows event monitoring and email notifications.

There you have it! 4 ways to protect yourself from exploitation via RDP!

*2016-09-16 Update: I have been playing around with various 2FA solutions and I feel the Yubikey is a exellent solution for protecting RDP if properly implemented.

The instructions below should only be used on a local network against your own equipment unless granted explicit permission to do so from the owner of said equipment. This guide is not to be used to attack users over the WAN or people you don’t like / want to hack. The guide is provided for informational purposes only. 

Be smart. Stay Safe.


Hell Forum Closed, Administrator ping arrested. | hell2bjhfxm77htq.onion

Hell forum has been getting a lot of attention recently. Publishers from vice to Brian Krebs have been writing about this onion site that dissipated yesterday.

Hell Forum was a Tor site that facilitated dumps and leaks from various sources with a heavy focus on cyber crime. The site itself had guides on carding, hacks, exploits, and dumps. In the last few days of the forum being online there was a number of releases for sites as recent as May 31st 2015.

Didnt have the skills to be a script kiddie? Hell was also a hub for users to exchange shells and databases the users have collected. This added to the community that had a known reputation among Tor users.

Why am I writing about this?
The main reason is exposure I have only seen one article about this online so far. It seems that the ability collective for users to aggregate and then sell this data seems to be on the rise and Hell forums was the place to go. I also had some observations that were not covered by ThreatStreams post regarding the encryption keys used on the .rar files. And wanted to touch base on the importance of security even over Tor. I highly recommend you read their article once done here.

In brief, Hell ( https://hell2bjhfxm77htq.onion ) administrator ‘ping’ a 33 year old Calgary resident was charged for card skimming today after a extensive six month investigation.  This created an issue for Hell forum users since he was the administrator of the site. During the last month he has been active on the site and still publishing data leaks even after the inital arrest and after the seizure. This would be problematic for users of an underground forum seeing as it could be possible he might have worked with law enforcement in order to attain a reduce the sentence. A daily reminder that even if you use Tor services you need to be security conscious about who you contact, what you do, and the implications it may have just for being associated (or even having an account) with these sites.

After the fourms went down yesterday the repo where the leaks were stored also dissapred into the depths of the deep web. The site ‘ http://agcv47dxxqxqkmw3.onion/Hacked_Data/ ‘ is also gone; as noted by ThreatStream it had a number of data leaks on it some of them encrypted some not. What was overlooked by the article was that a number of the archives that were recently posted were the very public HackingTeam leaks, Wildstar Online (online MMO), Cheap Ass Gamer, and with data as new as March 31st 2015.


Another item that has not yet been reported is that the keys to the archives were actually lines of his PGP Block.

A small collection of the leaks utilize the passwords: `mQINBFUiprYBEADKX+oGpwzjjQ7bUr7XUjfP5C/xCR3dQfdcmflkBf3HdK7ARZ3p`, `58iY0pmkQa6EMlNFXcBt75QW3wUFxSFrfy2aN2D/+UTCz/H08Q6wMNITyvtXy5uc`,

When looking at this I noticed that they are in line with what the current PGP key that ‘ ping ‘ used posted below:

Version: GnuPG v2.0.22 (GNU/Linux)


Its probable that other lines could be the key to unlocking the now gone archives.

Seeing as ‘ ping ‘ is not going to be releasing the keys any time soon for the remaining archives this is the best lead existing Hell users would have had to open the files, one the locked archives was suspected of being  the second batch of the federal leak in 2013.

In closing, there will always be more “Hell” forums that spring up as long as there is a demand for it. Users should always keep in mind that when using Tor you are only as secure the service you use. Once you put identifying data into the service you have removed any barriers it has put up for you.

Exploits and large companies | How nothing has changed since 1998


I am posting something a bit different today a opinion article on something I feel to be true. The basis is from a video from 1998’s L0pht testimony and a comparison of how little things have changed since then.

Recently in the Washington Post there was an article about the hacker group called L0pht and their plea to the government on how private companies need to be responsible for the software they put online. They were trying to bring to light that if you want a more secure system then don’t put it online. This does not mean that offline systems are impervious to attacks either.  The testimonial is worth the 1 hour run time and I recommend you listen to it on youtube. It is very important if your business is accountable for holding data records, login info, and customer info. This is not related to my previous article but rather all kinds of software I see day in and day out.

I just wanted to touch on a few items on the video that I believe to still be prevalent in todays online culture and mentality of corporate security.

“Can the systems be secured? In most cases they can be … they can be remedied by incorporating relatively trivial and inexpensive cryptographically secure authentication.”
Often some of the insecure items I come across are due to no security at all, whether they end up using plain text to store data in the database or don’t use common and readily available technologies like HTTPS or TLS in order to transmit over public forms of communication. Having something is always better than having nothing.

“Insecure software is cheaper and easier to sell as there is no liability tied to the manufactures” … “encourage companies to include this [security] in their products and hold them liable when their products fail.” 
Selling software is easy, ensuring it has perfect security is impossible. No product will ever be truly secure, it is not a matter of if but rather when.

“I don’t think it is possible to create a fool proof system, but I don’t think that should be the goal. The goal should be very difficult to get in.”
Putting hurdles in the way of would be exploiters slows them down and keeps away the script kiddies. This in combination with monitoring incursion events would keep organisations aware. Security needs to roll forward with the times, it is not something you can deploy and hope it will work for the lifetime of the product.

“If you have sensitive information then you should not share it with networks that are less secure or less trusted”
As straight forward as this sounds it could be a simple as allowing VPN users from outside of the office in or more commonly BYOD enrollment in the office.

So that leaves us with what can be done about it.
For starters listen and be aware to what is going on in both the industry and with your own systems. I am not saying go out now and update your Watchguard and Ironport devices and patching every device on the network. Simply I am referring to read up on what is going on, is there a new exploit for TLS downgrading that could affect my S3 instance? Are my offsite backups stored in an encrypted manner? Is there documentation on how strong this manner stands up to bruteforce techniques? Have I looked at the FTP logs for unusual activity? Maybe I should not have a FTP account that could expose the internal file server.  All of these questions lead to new avenues of learning and awareness.

Also, listen to users who are trying to help. Its much easier and cheaper to ignore a problem, however when a internal or external user lets you know there is a issue with the current implementation list, getting upset will only make the user think twice about letting you know in the future. I see this as one of the biggest roadblocks on reporting issues. It is far easier to sell a exploit online and actually make money than it is to report it and then have pressure from the company. In a more recent example with starbucks. Imagine if this exploit was sold.
“The unpleasant part is a guy from Starbucks calling me with nothing like “thanks” but mentioning “fraud” and “malicious actions” instead.”
The selling of zero days and exploits also hurt the company far more than if they were to fix it after it was disclosed to them. This comes at a higher cost to both the organization and the clients that had put their faith and more importantly their data into the organization.