Verifying links before you get phished

Your Mom sends a funny cat video link on YouTube. Your department head sends a link for the training schedule. There’s an email in your Inbox from Amazon for a laptop sale.

Always think twice before clicking on any of those links. Is that email really from Mom or the department head or Amazon? Even if it was really from Mom’s account, is that link really for a cat video on YouTube? Her account, could have been compromised, and the email sent with an obfuscated link.

Phishing works

Phishing campaigns are effective; estimates range from 60 to 90% of all email is a phishing message. MicroSolved’s social engineering exercises have yielded from 11 to 43% success – success meaning recipients have clicked on the benign links in our phishing exercises for clients with their employees. Estimates average 30% of phishing links are clicked.

Obfuscated URL in an Email

So, never click on a link in an email. OK, that may be a little absolute. Only be certain that the link is what you expect it to be. Hover over the link and either a popup or in the status bar of your email client/browser will display the URL. Verify the domain in the link is valid. Simple link obfuscation techniques such as registering a domain named yuotube.com (note the spelling) is an easy phishing and effective trick.

Another trick is hiding the URL behind friendly text, for example, click here. This technique could easily have been used to create a link = stateofsecurity.com – but the the link actually browses to MicroSolved’s home page.

Image links are not immune. That Amazon logo in the email – does that really link to amazon.com? Hover over the link to verify the URL before you click on it. Or better yet, open your browser, type amazon.com in the address bar, then search for and browse to the laptop sale. By the way, don’t browse to yuotube.com, just take my word for it.

Similarly, while browsing or surfing the web, it is always good practice to verify links before you actually click on them. Hover and verify.

Check that browser address bar

So, now that you’ve clicked on that link and landed on the destination web page, are you sure that’s chase.com’s login page? Before you enter your bank account login credentials, check out the URL in the address bar. Make sure it’s https. Any URL that requires you to enter some identification should be over the encrypted protocol, https.

Next, just because the URL has chase.com within it, does not make it a valid chase.com page. Check out the two images below; phishers often trick their victims by obfuscating a URL with a string of an expected valid domain name in the URL:

Note that chase.com is part of the URL, but the login.html page is actually in the badbaddomain.com. The attackers are counting on users to notice the “chase.com” in the URL and click on their link. Once clicked, the user is to taken to a rogue web server with a login page that mimics the real login page for the bank. If the user continues with typing in their authentication credentials, the trap  has sprung – the rogue server has saved the user’s credentials, and the bank account will soon be drained of its funds. Often, after the user enters the credentials, they may be redirected to a valid 404 error page in the user’s bank server, and the user imay be a little confused but unaware that they’ve just given away their credentials.

Current browsers have a feature to help users pick out the actual domain name from the URL – in the top image, the Firefox address bar displays the domain name part of the URL in black font, and everything else in a gray colored font. This is the default behavior; the setting can be changed for the entire URL be the same color format.

Not all browsers display the URL in such a way, Chrome displays the same obfuscated URL as below; the domain and subdomains part of the URL are in black font and the sub-directories and page resource are in grey font:

Shortened URLs

Shortened URLs have become much more popular because of Twitter – it’s a method of reducing a long (regular) URL into a shortened version of usually 10-20 characters. However, because of the condensed URL, it’s not possible to determine the actual address of the link. In this case, it would be wise to copy the shortened URL and validate it with a URL expander website, such as checkshorturl.com or unfurlr.com or unshorten.it.

It’s a minefield out there. Attackers are constantly phishing for their next victim. Be vigilant, beware of what you click, surf safe.

Sources:

https://blog.barkly.com/phishing-statistics-2016

Worm detection with HoneyPoint Security Server (HPSS): A real world example

This post describes a malware detection event that I actually experienced a few short years ago.

My company (Company B) had been acquired by a much larger organization (Company A) with a very large internal employee desktop-space. A desktop-space larger than national boundaries.

We had all migrated to Company A  laptops – but our legacy responsibilities required us to maintain systems in the original IP-space of company B.  We used legacy Company B VPN for that.

I had installed the HPSS honeypoint agent on my Company A laptop prior to our migration into their large desktop space.  After migration I was routinely VPN’ed into legacy Company B space, so a regular pathway for alerts to reach the console existed.

After a few months, the events shown in the diagram below occurred.

I started to receive email alerts directed to my Company B legacy email account. The alerts described TCP 1433 scans that my Company A laptop was receiving.  The alerts were all being thrown by the MSSQL (TCP 1433 – Microsoft SQL Server) HoneyPoint listener on my laptop.

I was confused – partly because I had become absorbed in post-acquisition activities and had largely forgotten about the HPSS agent running on my laptop.

After looking at the emails and realizing what was happening, I got on the HPSS console and used the HPSS event viewer to get details. I learned that the attackers were internal within Company A space. Courtesy of HPSS I had their source IP addresses and the common payload they all delivered.  Within Company A I gathered information via netbios scans of the source IPs.  The infected machines were all Company A laptops belonging to various non-technical staff on the East Coast of the U.S.

All of that got passed on to the Company A CIO office. IDS signatures were generated, tweaked, and eventually the alerts stopped.  I provided payload and IP information from HPSS throughout the process.

I came away from the experience with a firm belief that company laptops, outfitted with HoneyPoint agents, are an excellent way of getting meaningful detection out into the field.

I strongly recommend you consider something similar. Your organization’s company laptops are unavoidably on the front-line of modern attacks.

Use them to your advantage.

 

 

Playing with Honeypot Twitter Data

I just wanted to share a bit of fun from my daily research work. I monitor a lot of honeypot data on a global scale, most of which is generated from HoneyPoint, of course. The HITME produces large amounts of data every hour, and it is a ton of fun to play with.

But, I also monitor several Twitter feeds of honeypot data, and I wanted to share a few quick things with you from there.

Below is a topic cloud from the feeds for yesterday. The larger the words, the more numerous their use:

Topicpaircloud

I also rank hashtags by use, and here are a few high hitters, and their number of uses in a day’s worth of data back in July:

58565 #netmenaces
11302 #hit
5959 #blacklisted
5379 #host
2990 #telnet
2813 #badabuse
2660 #infosec
2660 #cybersecurity
2301 #botabuse
2142 #smb
1723 #mssql
1311 #wordpress
1091 #mysql

Do you generate data like this? If so, how do you play with it? Hit me up on Twitter (@lbhuston) and share your process.

InfoSec: A Human Problem, NOT A Technological Problem

I have been involved in (and thinking about) computer network information security since the early 80s. I’ve seen computer information security develop from BS7799 and the Rainbow series standards to the standards we are still using today such as ISO 27002, the NIST 800 series, PCI, etc. All of this guidance at its core is basically the same; employ strong access controls, monitor the system, employ configuration controls and all the other basics. These all seem like great security controls and I’m sure that we still need to use them. The conundrum is that all of this guidance has consistently failed to solve the problem, and not only hasn’t it solved it, the information security problem is getting worse!

I have been trying to understand why this is. Perhaps it’s too much new tech too fast, perhaps the problem itself is simply insoluble….or perhaps we have just been approaching the problem from the wrong angle all this time. After all, the height of futility has often been described as doing the same thing again and again and expecting a different outcome to result. So I decided to give the whole subject a fresh look. I took a cue from Marcus Aurelius and started with the basics: what is information security and why do we need it?

One of the first principles that occurred to me is just this: information security is a human problem, not a technological problem. Computers don’t have desires, they are not duplicitous, they are not evil and they are not aware. They are just tools. It is the humans that develop and use these tools that are exclusively responsible for information theft and corruption.

With that in mind, I suggest we embrace an information security standard based on human foible and weakness of character. I know that in the information security world we always pay lip service to the idea that we are paying attention to the human factor. But from what I see, that is all smoke and mirrors. What I really see is that we continue to throw machines and applications at the information security problem. “Oh, yes,” we say “this new adaptive security device or SIEM system or whatever new tool will protect our private information! I believe! Hallelujah!”

Good luck with that.

Nothing can replace the flexibility and intuition of a human mind. There are at best some schooled and semi-autonomous tools-and I emphasize the word TOOLS-that ape true intelligence. But in reality, they are only effective when combined with human input and oversight.

With all of this in mind, I suggest we look at the computer network security world from a purely human perspective. Expect people to do the worst, and then be elated when they rise above expectations. Plan your tactics with laziness, envy, spite, stupidity, inattention and all of our other bad characteristics in mind. Don’t spend a million dollars on the best current global information security device or service; spend FIVE million dollars on knowledgeable, canny and intelligent human employees.

I intend to write further about this subject and continue to explore the ways we can adjust our security controls and processes to better address the human factor and make inroads into better infosec. It will be interesting to see if it works!

Ransomware TableTop Exercises

When it comes to Ransomware, it’s generally a good idea to have some contingency and planning before your organization is faced with a real life issue. Here at MicroSolved we offer tabletop exercises tailored to this growing epidemic in information technology. 

 

What if your organization was affected by the Golden Eye or WannaCry today? How quick would you be able to react? Is someone looking at your router or server log files? Is this person clearly defined? How about separation of duties? Is the person looking over the log files also uncharge of escalating an issue to higher management?

 

How long would it take for you organization to even know if it was affected? Who would be in-charge of quarantining the systems? Are you doing frequent backups? Would you bet your documents on it? To answer these questions and a whole lot more it would be beneficial to do a table top exercise. 

 

A table top exercise should be implemented on an annual basis to evaluate organizational cyber incident prevention, mitigation, detection and response readiness, resources and strategies form the organizations respective Incident Response Team. 

 

As you approach an incident response there are a few things to keep in mind:

 

  1. Threat Intelligence and Preparation

An active threat intelligence will help your organization to Analyze, Organize and refine information about potential attacks that could threaten the organization as a whole.

After you gain Threat Intelligence, then there needs to be a contingency plan in place for what to do incase of an incident. Because threats are constantly changing this document shouldn’t be concrete, but more a living document, that can change with active threats.

  1. Detection and Alerting

The IT personal that are in place for Detection and Alerting should be clearly defined in this contingency plan. What is your organizations policy and procedure for frequency that the IT pro’s look at log files, network traffic for any kind of intrusion?

  1. Response and Continuity

When an intrusion is identified, who is responsible for responding? This response team should be different then the team that is in charge of “Detection and Alerting”. Your organization should make a clearly outlined plan that handles response. The worse thing is finding out you don’t do frequent backups of your data, when you need those backups! 

  1. Restoring Trust

After the incident is over, how are you going to gain the trust of your customers? How would they know there data was safe/ is safe? There should be a clearly defined policy that would help to mitigate any doubt to your consumers. 

  1. After Action Review

What went wrong? Murphy’s law states that when something can go wrong it will. What was the major obstacles? How can this be prevented in the future? This would be a great time to take lessons learned and place them into the contingency plan for future. The best way to lesson the impact of Murphy, is to figure out you have an issue on a table top exercise, then in a real life emergency! 


This post was written by Jeffrey McClure.

Petya/PetyaWrap Threat Info

As we speak, there is a global ransomware outbreak spreading. The infosec community is working together, in the open, on Twitter and mailing lists sharing information with each other and the world about the threat. 

The infector is called “Petya”/“PetyaWrap” and it appears to use psexec to execute the EternalBlue exploits from the NSA.

The current infector has the following list of target file extensions in the current (as of an hour ago) release. https://twitter.com/bry_campbell/status/879702644394270720/photo/1

Those with robust networks will likely find containment a usual activity, while those who haven’t implement defense in depth and a holistic enclaving strategy are likely in trouble.

Here are the exploits it is using: CVE-2017-0199 and MS17-010, so make sure you have these patched on all systems. Make sure you find anything that is outside the usual patch cycle, like HVAC, elevators, network cameras, ATMs, IoT devices, printers and copiers, ICS components, etc. Note that this a combination of a client-side attack and a network attack, so likely very capable of spreading to internal systems… Client side likely to yield access to internals pretty easily.

May only be affecting the MBR, so check that to see if it is true for you. Some chatter about multiple variants. If you can open a command prompt, bootrec may help. Booting from a CD/USB or using a drive rescue tool may be of use. Restore/rebuild the MBR seems to be successful for some victims. >>  “bootrec /RebuildBcd bootrec /fixMbr bootrec /fixboot” (untested)

New Petrwrap/Petya ransomware has a fake Microsoft digital signature appended. Copied from Sysinternals Utils. – https://t.co/JooBu8lb9e

Lastline indicated this hash as an IOC: 027cc450ef5f8c5f653329641ec1fed91f694e0d229928963b30f6b0d7d3a745 – They also found these activities: https://pbs.twimg.com/media/DDVj-llVYAAHqk4.jpg

Eternal Blue detection rules are firing in several detection products, ET Rules firing on that Petya 71b6a493388e7d0b40c83ce903bc6b04  (drops 7e37ab34ecdcc3e77e24522ddfd4852d ) – https://twitter.com/kafeine/status/879711519038210048

Make sure Office updates are applied, in addition to OS updates for Windows. <<Office updates needed to be immune to CVE-2017-0199.

Now is a great time to ensure you have backups that work for critical systems and that your restore processes are functional.

Chatter about wide scale spread to POS systems across europe. Many industries impacted so far.

Bitdefender initial analysis – https://labs.bitdefender.com/2017/06/massive-goldeneye-ransomware-campaign-slams-worldwide-users/?utm_source=SMGlobal&utm_medium=Twitter&utm_campaign=labs

Stay safe out there! 

 

3:48pm Eastern

Update: Lots of great info on detection, response, spread and prevention can be found here: https://securelist.com/schroedingers-petya/78870/

Also, this is the last update to this post unless something significant changes. Follow me on Twitter for more info: @lbhuston 

Drupal Security Best Practices Document

This is just a quick post to point to a great guide on Drupal security best practices that we found recently. 

It was written for the Canadian government and is licensed under the Open Government License platform. 

The content is great and it is available free of charge. 

If your organization uses Drupal, you should definitely check it out and apply the guidance as a baseline! 

Leaking RFC1918 IP Addresses to the Internet

There has been a lot of conversation with clients about exposing internal DNS information to the public Internet lately. 

There are some security considerations, and a lot of the arguments often devolve into security by obscurity types of control discussions. My big problem with the leakage of internal DNS data to the Internet is that I hypothesize that it attracts attacker interest. That is, I know when I see it at a client company, I often immediately assume they have immature networking practices and wonder what other deeper security issues are present. It sort of makes me deeper attention to my pen-testing work and dig deeper for other subtle holes. I am guessing that it does the same for attackers. 

Of course, I don’t have any real data to back that up. Maybe someone out there has run some honeypots with and without such leakage and then measured the aggregate risk difference between the two scenarios, but I doubt it. Most folks aren’t given to obsess over modeling like I am, and that is likely a good thing.

It turns out though, that there are other concerns with exposed internal DNS information. Here are a few links to those discussions, and there are several more on the NANOG mailing list from the past several years.

Server fault, Quora, and, of course, the RFC1918 that says you shouldn’t leak them. 🙂 

So, you might wanna check and see if you have these exposures, and if so, and you don’t absolutely need them, then remove them. It makes you potentially safer, and it makes the Internet a nicer place. 🙂 

If you have an actual use for leaking them to the public Internet, I would love to hear more about it. Hit me up on Twitter and let me know about it. I’ll write a later post with some use scenarios if folks have them. 

Thanks for reading! 

Quick Look at Ransomware Content

Ransomware certainly is a hot topic in information security these days. I thought I would take a few moments and look at some of the content out there about it. Here are some quick and semi-random thoughts on the what I saw.

  • It very difficult to find an article on ransomware that scores higher than 55% on objectivity. Lots of marketing going on out there.
  • I used the new “Teardown” rapid learning tool I built to analyze 50 of the highest ranked articles on ransomware. Most of that content is marketing, even from vendors not associated with information security or security in general. Lots of product and service suggestive selling going on…
  • Most common tip? Have good and frequent backups. It helps if you make sure they restore properly.
  • Most effective tip, IMHO? Have strong egress controls. It helps if you have detective controls and process that are functional & effective.
  • Worst ransomware tip from the sample? Use a registry hack across all Windows machines to prevent VBS execution. PS – Things might break…

Overall, it is clear that tons of vendors are using ransomware and WannaCry as a marketing bandwagon. That should make you very suspicious of things you read, especially those that seem vendor or product specific. If you need a set of good information to use to present ransomware to your board or management team, I thought the Wikipedia article here was pretty decent information. Pay attention to where you get your information from, and until next time, stay safe out there!