Levenshtein Distance as a Defence Against Spear Phishing


When an advanced persistent threat (APT) targets an organization they will relentlessly work to find a way into the network . Once inside they can take any number of actions all of which are specific to their goals. These attackers are determined and have unlimited resources and will eventually find a way in.

Infiltration is often achieved by compromising the people within the organization. Why fight your way past state-of-the-art technology when you can just get somebody to click on a link?

By using publicly available open source intelligence (OSINT) tools an APT can construct a list of emails of people that work in the target organization and then build profiles on each. With a name and an email as a starting point very detailed profiles can be constructed with little effort.

Using these detailed personal profiles the APT can then construct a sophisticated email campaign targeting specific employees. Emails can be constructed to appear like they are coming from fellow employees or specific organizations using a homograph attack.

Using this method a fake email or domain can appear to be genuine even to a technically savvy and vigilant user.

To combat this LimaCharlie has added support for 'string distance'  to it's detection and response rules. This feature is based on the Levenshtein distance and can alert analysts to the existing of phishing domains  or executables masquerading as well known ones.

The Levenshtein distance, in layman's terms, is the number of character that must change in a bit of text to become equal to another bit of text. For example, the Levenshtein distance between “hello” and “hallo” is 1.

This simple concept allows you to simply quantify possible phishing domains since those often try to mimic legitimate corporate domains. In these cases, we want to look for a distance that is not 0 (since this is the legitimate domain), but with a distance lower than 2 or 3. This would catch a phishing attack attempting to redirect you to “c0rp.mydomain.com” instead of “corp.mydomain.com” (notice the zero instead of “o”).

Getting alerts while monitoring internal domains using this method can serve as an early indicator of a sophisticated campaign against the organization. Using this information the security team can raise the level of vigilance at every level of the organization and prevent a breach.


Internet of Things and LimaCharlie


We have known LimaCharlie is the best incident response platform out there for a while. We also knew the extreme flexibility and scalability of the platform - not to mention the multiple platforms supported - made it ideal to manage large numbers endpoints in a "headless" fashion. This combination of characteristics is a great match for the Internet of Things. The missing item was support for the ARM architecture used by most IoT devices…

LimaCharlie now supports ARM architectures opening the door to a multitude of IoT use cases from embedded devices to phones, and all through the same middleware, white-labeling and multi-tenant friendly platform.

We have been experimenting, deploying LimaCharlie on routers, Raspberry Pi as well as Android phones with great success.

If you are an IoT developer or integrator looking for a security solution, get in touch, we can get you up and running quicker than anyone else.

Raspberry Pi

Live Sweep


The Live View in LimaCharlie provides you with a great interface to perform incident response by enabling the execution of real-time investigation and mitigation commands on the hosts. As the product has developed we have built out a user friendly interface to the Live View that allows you to see with better context the current activity on the host. For example, by overlaying the file signing status as well as network activity against the process list you could see at a glance processes of higher interest.

Today we are taking another step in the direction of active investigation and introducing a new Sweep feature. We wanted to go beyond the static display of context and move into active investigation of anomalies. This new feature is designed to streamline investigation of a host that is suspected of being compromised.

Most security responders have a list of things they look for when investigating a host. It is often a manual process that relies on expert knowledge. The Sweep allows you to automate and standardize this process. The exact behaviour of the Sweep will continue to evolve over time but its mission is to highlight to an analyst the various bits of activity on the host that are suspicious.

At the moment of writing this blog article, clicking the Sweep button will perform the following logic:

  • Highlight all unsigned binaries running (processes, services, drivers, autoruns).

  • Highlight all the processes listening on the network or with active network connections.

  • Scan the memory of processes looking for hidden code modules and highlight them.

    Highlight all code modules and autoruns that have been modified in the last week.

Combined with the ability LimaCharlie has to perform advanced operations in real-time like YARA signature scanning and memory operations, the Sweep functionality will continue to evolve providing responders a faster, repeatable process that junior analysts can also leverage.

Is there specific logic you would like included in a Sweep? Get in touch with us via our Slack community or say hello on Twitter @limacharlieio.

Automated Threat Scanning

Getting Critical Answers


LimaCharlie is a platform designed for building security solutions. Endpoint detection and response (EDR) capability is the cornerstone of the platform, which also provides access to a plethora of raw telemetry. The EDR capability is powerful but the bigger prize are the “critical answers” we can gain my making use of the telemetry.

These critical answers are the specific pieces of information that will allow you make important security decisions, and you need the ability to get to these answers in the most straight forward way possible.

LimaCharlie Insight provides you with one year of built-in retention and search capability. The retention allows you to get answers like “what EXACTLY happened on this host 7 months ago at 3AM” in a few seconds.

The indicator (domain name, hash, file name, IP address etc) search allows you to get a succinct set of answers

Is this indicator common?

Imagine that you are investigating a possible intrusion when you spot a suspicious looking executable that you don’t recall ever seeing before. Is it a case of bad memory or is this part of the malware dropped by the attacker?

You can start to paint a picture by examining how prevalent the given indicator is. Using the web interface (or API) you can ask this question and get an answer immediately.

Screenshot 2018-11-27 at 06.08.15.png

This tells you how many hosts have seen this file today, this week or this month. An indicator seen for the first time today and not in the past month is highly suspicious.

We make getting these 3 numbers easy. The data can be pulled either through a search or while visualizing activity from a host.

Where has this indicator been seen?

Now imagine that you have been made aware of a specific indicator related to malicious activity. This can come up in many ways: A report is published on the web detailing a new threat actor, a law enforcement tip-off, MISP or as a result of an internal security investigation.

Given this information you would need to scope the possible threat right away: “where has this been seen”?

Screenshot 2018-11-27 at 06.18.36.png

Through the user interface you can see the list of all hosts that have ever made a request to this specific domain name over the last year, the first and last time they did and get shortcut links to the fully detailed exploration view of the specific activity. This is powerful.

More Critical Answers?

Do you have other ideas of critical answers you would like to see? Let us know, LimaCharlie is quickly becoming a core part of the security tool set and it is thanks to your feedback!


LimaCharlie Like a Pro


The following are some best practices for using LimaCharlie. These will help you get started on the right foot and make your life easier.

If you're not familiar with the LimaCharlie Command Line Interface, a short introduction is available here.

Setting up the environment

The first thing you need to do is install the LimaCharlie CLI:

pip install limacharlie

Now create an API key with the following privileges:

dr.del, dr.list, dr.set, ikey.del, ikey.list, ikey.set, org.get, output.del, output.list, output.set, sensor.get, sensor.list, sensor.tag

These privileges allow you to manage your organization but not interact with sensors or query historical data (those privileges are not needed for this example).

From your terminal, login to LimaCharlie:

python -m limacharlie login
# When prompted enter your Organization ID and API Key.

Everything should be ready. You can test it by fetching your configurations:

python -m limacharlie.Sync fetch

This will write a LCConf file in your current directory. If your organization is already configured, this file will contain all your Outputs and D&R rules.

Managing configurations

The LCConf file we got from setting our environment is important. It will allow you to keep all configurations as config files. This is called Infrastructure as Code. These files are best kept under revision control. The advantage of managing your LimaCharlie deployment using these files is that it removes a lot of the human factor (who hasn't forgotten to check a specific checkbox somewhere). It will save you time and headaches, and enable you to build a robust infrastructure.

Now, our initial fetch produced a single file, but it's unlikely you will want to keep it that way. It's much easier to maintain your configurations as multiple files where each file takes care of a specific concern.

For example, you might keep a copy of all auditing messages LimaCharlie produces somewhere for compliance. If you do, and you have multiple LimaCharlie organizations you manage, it will be easier to keep this auditing Output in its own file and to re-use it for all organizations.

This is where the include: some-config-file.yaml statement comes in. It allows you to have a top level config file, let's call it "customer-A.yaml" which includes the more generic components like the "auditing-output.yaml" mentioned above:

include: auditing-output.yaml

For simplicity, we will assume you're using one configuration file and will leave it to you to split them according to your needs.

You can generate a set of configuration files that is a good general boilerplate setup for your organization. They will already contain some of the recommended setup described below:

# Create a directory for your configurations.
mkdir myorg
# Generate the default configs.
python -m limacharlie init ./myorg

The fun part

Now for the fun part, let's setup some functionality.

Tags are simple. yet powerful. They will give you a uniform mechanism to apply and remove behavior, with the added advantage of always having the tags displayed in the LimaCharlie data (so you always know the context around a host from its events).

Host isolation

Host isolation is extremely powerful, but it can be difficult to keep track of which hosts are isolated and why. What we can do here is setup a tag, named "isolated", to apply to a sensor in order to isolate it. When the tag is removed so is isolation.

This approach makes it easy to see which hosts are isolated.

To do this, we will setup two Detection & Response rules (our swiss army knife).


# Detection
# =========================
op: and
  - op: is tagged
    tag: isolated
    event: CONNECTED
  - op: is
    path: event/IS_SEGREGATED
    value: 0

# Response
# =========================
- action: task
  command: segregate_network

This rule says: if a CONNECTED event comes in from a sensor that is tagged with the "isolated" tag, and the "event/IS_SEGREGATED" value is false (0), it means someone wants the sensor to be isolated (the tag), but the sensor is not currently isolated (the value in the CONNECTED event). So the action to take is to sent the "segregate_network" command.

Now we will want another rule to do the inverse:


# Detection
# =========================
op: and
  - op: is tagged
    tag: isolated
    not: true
    event: CONNECTED
  - op: is
    path: event/IS_SEGREGATED
    value: 1

# Response
# =========================
- action: task
  command: rejoin_network

This says: if a sensor comes in indicating it is isolated, but it is NOT tagged with "isolated", make it rejoin the network.

From this point on, this will allow you to control host isolation entirely through the use of the "isolated" tag. These rules only fire when a sensor connects, so you might also want to fire a "segregate_network" and "rejoin_network" command at the same time as tagging and untagging if you want the changes to occur imemdiately.

File integrity management

FIM tends to be platform specific. The monitored files/registries on Windows are not the same as MacOS. So we'll use two rules to setup the various monitored files and directories. You can expand the method described here to be more granular. An example of higher granularity would be monitoring specific files on Windows Domain Controllers by using tags associated with these hosts.


# Detection
# =========================
op: and
  - op: is windows
    event: CONNECTED

# Response
# =========================
- action: task
    - fim_add
    - --pattern
    - "C:\\\\*\\\\Programs\\\\Startup\\\\*"
    - --pattern
    - "\\\\REGISTRY\\\\*\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run*"


# Detection
# =========================
op: and
  - op: is mac
    event: CONNECTED

# Response
# =========================
- action: task
    - fim_add
    - --pattern
    - /Users/*/.ssh/authorized_keys
    - --pattern
    - /Users/*/Library/Services/*
    - --pattern
    - /System/Library/Services/*
    - --pattern
    - /System/Library/Extensions/*

High performance

LimaCharlie is generally extremely performant but there are some edge cases where performance suffers. For these rare situation, encoutered when deployed on high-io database servers, there is the high performance mode.

To simplify the management of applying this mode to the right sensors, we will use a "high-perf" tag:

# Detection
# =========================
op: and
  - op: is tagged
    tag: high-perf
    event: CONNECTED

# Response
# =========================
- action: task
  command: set_performance_mode --is-enabled

Final thoughts

There is obviously a lot more that can go into your base configurations. I'd like to leave you on some possible ways you could expand your tagging rules that would result in better situational awareness of your network.

Tagging by department

You can create a rule that tags sensors based on seeing a USER_OBSERVED event and doing a lookup against a list of users exported from an Active Directory you upload to LimaCharlie as a resource. For example, this could allow you to know at a glance that a specific asset belongs to the Finance department.

Tagging by role

Most assets in the company can be assigned one or multiple roles easily by using processes observed. For example, a host running "devenv.exe" (Microsoft Visual Studio) is likely a developer, white one running "nginx" is likely a web server.

Creating tagging rules based on seeing these processes can be a quick and easy way to further enhance your awareness of your network.

Tagging for geo-location

It can be useful for a security analyst to see that a specific host has recently traveled overseas. Using the GeoLocation API, you can create a rule that, for example adds a "EU" or "USA" tag when the asset connects from these locations.


Development Update


The team at LimaCharlie has been busy building out our web application leveraging the capabilities of the publicly available API. There have been so many improvements in such a short period of time we felt that it deserved a blog post.

The two main areas we have been working on are:

  1. Live View: a console for interacting with agents in real-time

  2. Insight: an interface which allows users to search and interact with up to a year's worth of stored endpoint telemetry.

Live View

The live view of the LimaCharlie web application allows privileged users to interact with the endpoints in real-time. We achieve true real-time connectivity through the use of a semi-persistent TLS connection.

Through the live view console you gain the following capability.

1. Get general information about the endpoint such as hostname, platform, relevant IP addresses, last connection time and review tags that have been applied to the endpoint. Along with gathering this information you can also add and remove tags easily directly from the view.


2. Adjust the telemetry that is sent to the output stream. Choose from amongst 70 different data points which can be monitored on any given endpoint.


3. An interactive console from which users can send up to 32 different commands to the console. From this console you can gather data, kill processes, isolate the host from the network and much more. Details on the commands that can be issued can be found here.

Endpoint Command

4. Monitor a real-time stream of events being produced by the endpoint. All telemetry being sent to the output stream can be monitored in the browser as it happens.


5. List all of the processes as they are currently on the given endpoint. From here a privileged user can view process modules, inspect memory strings or maps and kill any process at the click of a button. From this view you are also able to run a hash against VirusTotal’s publicly available API to check for known malware.

Endpoint File System

6. Navigate the file system on the endpoint. From here you can go through directories, hash and download files with one click.

File System Browser

Historical Insight

A couple of weeks ago we announced the introduction of long term telemetry storage with search capability. LimaCharlie still operates as elastic middleware but we are now able to offer one year of storage and search capability at the low cost of $0.50 per agent per month. This move allows MSSP's and SOC's who do not already have their own EDR infrastructure to gain a completely functional information security centre upon signing up (did we mention it is self-serve and there are no contracts?).

Once enabled, LimaCharlie Insight will automatically send all telemetry data to secure storage on the Google Cloud Platform.

The Insight user interface allows you to select a date and time from which to start your investigation. From this starting point new data is loaded into the browser via an infinite scroll mechanism. A histogram displays the time period for which data is available in cold storage alongside what has been loaded in the browser.

Historical Data View

The interface itself provides a simple text filter to limit results based on strings in data fields. This view also provides a cascading text filter and simple query language so that you can create complex filters based on event type.

That wraps up our development update. We are going to continue to the build the tools that we want as information security professionals and deliver them in a way that is fair and transparent. If you want to stay up to date with our progress you can follow us on Twitter or LinkedIn.


Introducing Historical Insight: Storage and Investigative Tools


We continue on our journey making endpoint capability more accessible. Along with the powerful elastic detection and response engine, LimaCharlie now offers low-cost, long-term data storage and tools for investigation.

Storage and historical insight can be enabled at the click of a button. The cost for a year of storage is a simple $0.50 per sensor per month.

Many of our clients will still continue to use the LimaCharlie endpoint and detection capability programmatically with their own storage solutions, but for many of the MSSPs we have spoken with, an easy storage and investigation tool makes a lot of sense.

Insight: EDR Telemetry Storage and Search

The web interface for the historical insight tool allows the user to pick a time that they wish to investigate and loads all events around it. Events are presented as line items in the lower portion of the UI and can be navigated via an infinite-scroll mechanism. Clicking on a line item will load a graph representing the event process that spawned it and any children it produced. Right-clicking on the root of this graph will present an option to navigate up the graph and load the parent should any exist.

We are very proud of the technological progress we have made and feel extremely grateful for the tight feedback cycles we have established with our customers. It is from what we have learned through these relationships that we set this next course in the evolution of LimaCharlie.


Live Endpoint Visibility and Interaction


It is now possible to interact with an organization’s endpoints in real-time by utilizing the LimaCharlie live-view interface. In the list of endpoints accessible through the web application you can select to open the live-view for any agent reporting as online.

Through the live-view you can accomplish the following:

  • Get general information about the sensor.

  • Apply and remove tags.

  • Select which events get sent to the cloud. There are a total of 52 events to choose from. Documentation can be found here.

  • Send commands directly to the sensor. This include isolating it from the network which maintaining a command and control connection.

  • View a live-stream of events as they are taking place on the endpoint.

  • Retrieve a list of processes, drill down into the details and check file hashes against VirusTotal’s public API.


To stay up to date with feature development please be sure to follow us on Twitter and/or LinkedIn.