Installing Netwar System

Online conflicts are evolving rapidly and escalating. Three years ago we judged that it was best to not release a conflict oriented tool, even one that is used purely for observation. Given the events since then, this notion of not proliferating seems … quaint.

So we released the Netwar System code, the companion ELK utilities, and this week we are going to revisit the Twitter Utils, a set of small scripts that are part of our first generation software, and which are still used for some day to day tasks.

When you live with a programming language and a couple of fairly complex distributed systems, there are troubles that arise which can be dispatched almost without thought. A new person attempting to use such a system might founder on one of these, so this post is going to memorialize what is required for a from scratch install on a fresh Ubuntu 18.04 installation.

Python

We converted to Python 3 a while ago. The default install includes Python 3.6.7, but you need pip, and git, too.

apt install python3-pip
apt install git
ln -s /usr/bin/python3 /usr/bin/python
ln -s /usr/bin/pip3 /usr/bin/pip

The next step is cloning the Netwar System repository into your local directory, make the commands executable, and place them on your path.

git clone [email protected]:NetwarSystem/NetwarSystem.git

chmod 755 tw-*

chmod 755 F-queue

cp tw-* /usr/local/bin/

cp F-queue /usr/local/bin/

Once that’s done, it’s time to install lots of packages. This is normally done like this:

pip install -r REQUIREMENTS.txt

But our REQUIREMENTS.txt for the Netwar System was pretty stale. We think it’s OK now, but here is how we updated it. A little bit of grep/sort/uniq provided this list of missing packages.

configparser
elasticsearch
elasticsearch_dsl
psutil
py2neo
redis
setproctitle
squish2
tweepy
walrus

You can manually install those and they’ll all work, except for squish2, the name for our internal package that contains the code to “squish” bulky, low value fields out of tweets and user profiles. This requires special handling like so.

cd NetwarSystem/squish2
pip install -e .

If you have any errors related to urllib3, SSL, or XML, those might be subtle dependency problems. Post them as issues on Github.

Elasticsearch Commands

There are a bunch of Elasticsearch related scripts in the ELKSG repository. You should clone them and then copy them into your path.

git clone [email protected]:NetwarSystem/ELKSG.git

cd ELKSG

chmod 755 elk*

cp elk* /usr/local/bin/

The ELK software can handle a simple install, or one with Search Guard. This is the simple setup, so add this final line to your ~/.profile so the scripts know where to find Elasticsearch.

export ELKHOST="http://localhost:9200"

Debian Packages

You need the following four pieces of software to get the system running in standalone mode.

  • Redis
  • Netdata
  • Elasticsearch
  • Neo4j

Redis and Netdata are simple.

apt update
apt install redis

There is an install procedure for Netdata that is really slick. Copy one command, paste it in a shell, it does the install, and makes the service active on port 19999.

Elasticsearch and Neo4j require a bit more work to get the correct version:

add-apt-repository ppa:webupd8team/java

apt update

apt install oracle-java8-installer

apt install curl apt-transport-https

curl -s https://artifacts.elastic.co/GPG-KEY-elasticsearch | apt-key add -

echo "deb https://artifacts.elastic.co/packages/6.x/apt stable main" | tee /etc/apt/sources.list.d/elastic-6.x.list

apt update

apt install elasticsearch=6.5.4

apt install kibana=6.5.4

mv /etc/apt/sources.list.d/elastic-6.x.list /etc/apt/sources.list.d/elastic-6.x.idle

systemctl enable elasticsearch

systemctl start elasticsearch

systemctl enable kibana

systemctl start kibana

The mv line leaves the Elasticsearch repository file in your sources directory, but it disables it. This is so you can update the rest of your system without stepping on the specific version needed.

Neo4j is similar, but it’s fine to track the latest version. Also note that Neo4j is a Java app – it needs the same Java installer we added for Elasticsearch.

wget -O - https://debian.neo4j.org/neotechnology.gpg.key | apt-key add -

echo 'deb https://debian.neo4j.org/repo stable/' | tee -a /etc/apt/sources.list.d/neo4j.list

apt update

apt install neo4j=1:3.5.4

Note that the version mentioned there is just what happens to be in the Neo4j install instructions on the day this article was written. This is not sensitive the way Elasticsearch is.

At this point you should have all four applications running. The one potential problem is Kibana, which may fail to start because it depends on Elasticsearch, which takes a couple minutes to come alive the first time it is run. Try these commands to verify:

systemctl status redis
systemctl status elasticsearch
systemctl status kibana
systemctl status neo4j

In terms of open TCP ports, try the following, which checks the access ports for Kibana, Redis, Neo4j, and Elasticsearch.

netstat -lan | awk '/:5601|:6379|:7474|:9200|:19999/'

And that’s that – you’ve got the software installed. Now we need to configure some things.

Linux & Packages Configuration

There are a number of things that need adjusting in order for the system to run smoothly. Elasticsearch will cause dropped packets under a load, so lets add these two lines to /etc/sysctl.conf

net.core.netdev_budget=3500
net.core.netdev_budget_usecs=35000

And then make them immediately active:

sysctl -w net.core.netdev_budget=3500
sysctl -w net.core.netdev_budget_usecs=35000

We also need to adjust the file handles and process limits upward for Elasticsearch’s Lucene component and Neo4j’s worker threads. Add these lines to /etc/security/limits.conf, and note that there are tab stops in the actual file, this looks terrible on the blog. Here it’s just best to reboot to make these settings active.

elasticsearch    -   nofile      300000
neo4j - nofile 300000
root - nofile 300000
neo4j hard nproc 10000
neo4j soft nproc 10000

If you’re running this software on your desktop, pointing a web browser at port 5601 will show Kibana and 7474 will show Neo4j. If you’re using a standalone or virtual machine, you’ll need to open some access. Here are three one liners with sed that will do that.

sed -i 's/#network.host: 192.168.0.1/network.host: 0.0.0.0/' /etc/elasticsearch/elasticsearch.yml

sed -i 's/#server.host: \"localhost\"/server.host: 0.0.0.0/' /etc/kibana/kibana.yml

sed -i 's/#dbms.connectors.default_listen/dbms.connectors.default_listen/' /etc/neo4j/neo4j.conf

systemctl restart elasticsearch

systemctl restart kibana

systemctl restart neo4j

Elasticsearch doesn’t require a password in this configuration, but Neo4j does, and it’ll make you change it from the default of ‘neo4j’ the first time you log in to the system.

OK, point your browser at port 19999, and you should see this:

Netdata status on a working system.

Notice the elasticsearch local and Redis local tabs at the lower right. You can get really detailed information on what Elasticsearch is doing, which is helpful when you are just starting to explore its capabilities.

Configuring Your First Twitter Account

You must have a set of Twitter application keys to take the next step. You’ll need to add the Consumer Key and Consumer Secret to the tw-auth command. Run it, paste the URL it offers into a browser, log in with your Twitter account, enter the seven digit PIN from the browser into the script, and it will create a ~/.twitter file that looks something like this.



You’ll need to enter the Neo4j password you set earlier. The elksg variable has to point to the correct host and port. The elksguser/elksgpass entries are just placeholders. If you got this right, this command will cough up your login shell name and Twitter screen name.

tw-myname

Next, you can check that your Elasticsearch commands are working:

elk-health

Now is the time to get Elasticsearch ready to accept Twitter data. Mostly this involves making sure it recognizes timestamps. Issue these commands:

elk-userids

elk-tuindices

elk-newidx

elk-mylog

elk-set2k

The first three ensure that timestamps work for the master user index, any tu* index related to a specific collection, and any tw* index containing tweets. The mylog command ensures the perflog indec is searchable. The last command bumps the field limit on indices. Experienced Elasticsearch users will be scratching their heads on this one – we still have much to learn here, feel free to educate us on how to permanently handle that problem.

If you want to see what these did, this command will show you a lot of JSON.

elk-showfmt

And now we’re dangerously close to actually getting some content in Elasticsearch. Try the following commands:

tw-friendquick NetwarSystem > test.txt

tw-load4usertest test.txt

tw-showusertest

This should produce a file with around 180 numeric Twitter IDs that are followed by @NetwarSystem, load them into Redis for processing, and the last command will give you a count of how many are loaded. This is the big moment, try this command next:

time tw-queue2usertest

That command should spew a bunch of JSON as it runs. The preceding time command will tell you how long it took, a useful thing when performance tuning long running processes.

Now try this one:

elk-list

You should get back two very long lines of text – one for the usertest index, show about 180 documents, and the other for perflog, which will just have a few.

There, you’ve done it! Now let’s examine the results.

Into Kibana

Your next steps require the Kibana graphical interface. Point your browser at port 5601 on your system. You’ll be presented with the Kibana welcome page. You can follow their tutorial if you’d like. Once you’ve done that, or skipped it, you will do the following:

  • Go the Management tab
  • Select Index Patterns
  • Create an Index Pattern for the usertest index

There should be a couple of choices for time fields – one for when the user account was created, the other is the date for their last tweet. Once you’ve done this, go to the Discover tab, which should default to your newly created Index Pattern. Play with the time picker at the upper right, find the Relative option, and set it to 13 years. You should see a creation date histogram something like this:

Conclusion

Writing this post involved grinding off every burr we found in the Github repositories, which was an all day job, but we’ve come to the point where you have cut & pasted all you can. The next steps will involve watching videos about how to use Kibana, laying hands on a copy of Elasticsearch: The Definitive Guide, and installing Graphileon so you can explore the Neo4j data.

If you need help, DM @NetwarSystem your email address, and we’ll send you an invite to the Netwar System Slack server.

Analyzing Twitter Streams

Our prior work on Twitter content has involved bulk collection of the following types of data:

  • Tweets, including raw text suitable for stylometry.
  • Activity time for the sake of temporal signatures.
  • Mentions including temporal data for conversation maps.
  • User ID data for profile searches.
  • Follower/following relationships, often using Maltego.

Early on this involved simply running multiple accounts in parallel, each working on their own set of tasks. Seemingly quick results were a matter of knowing what to collect and letting things happen. Hardware upgrades around the start of 2019 permitted us to run sixteen accounts in parallel … then thirty two … and finally sixty four, which exceeded the bounds of 100mbit internet service.

We had never done much with the Twitter streaming API until just two weeks ago, but our expanded ability to handle large volumes of raw data has made this a very interesting proposition. There are now ten accounts engaged in collecting either a mix of terms or following lists of hundreds of high value accounts.

Indexing Many Streams

What we get from streams at this time includes:

  • Tweet content.
  • RT’d tweet content.
  • Quoted tweet content.
  • Twitter user data for the source.
  • Twitter user data for accounts mentioned.
  • Twitter user data for accounts that are RT’d.
  • User to mentioned account event including timestamp.
  • User to RT’d account event including timestamp.

This data is currently accumulating in a mix of Elasticsearch indices. We recognize that we have at least three document types:

  • Tweets.
  • User data.
  • Interaction data.

Our current setup is definitely beta at this point. We probably need more attention on the natural language processing aspect of the tweets themselves, particularly as we expand into handling multiple European languages. User data could standing having hashtags extracted from profiles, which we missed the first time around, otherwise this seems pretty simple.

The interaction data is where things become uncertain. It is good to have this content in Elasticsearch for the sake of filtering. It is unclear precisely how much we should permit to accumulate in these derivative documents; at this point they’re just the minimal data from each tweet that permits establishing the link between accounts involved. Do we also do this for hashtags?

Once we have this, the next question is what do we do with it? The search, sorting, and time slicing of Elasticsearch is nice, but this is really network data, and we want to visualize it.

Maltego is out of the running before we even start; 10k nodes maximum has been a barrier for a long time. Gephi is unusable on a 4k Linux display due to font sizing for readability, and it will do just enough on a half million node network to leave one hanging with an analysis half finished on a smaller display.

The right answer(s) seem to be to get moving on Graphistry and Neo4j. An EVGA GTX 1060 turned up here a few weeks ago, displaying a GT 1030 to an associate. Given the uptime requirements for Elasticsearch, not much has happened towards Graphistry use other than the physical install. It looks like Docker is a requirement, and that’s a synonym for “invasive nuisance”.

Neo4j has some visualization abilities but its real attraction is the native handling of storage and queries for graphs. Our associates who engage in analysis ask questions that are easily answered with Elasticsearch … and other questions that are utterly impossible to resolve with any tool we currently wield.

Conclusion

Expanding capacity has permitted us to answer some questions … but on the balance its uncovered more mysteries than it has resolved. This next month is going to involve getting some standard in place for assessing incoming streams, and pressing on both means of handling graph data, to see which one we can bring to bear first.

Twitter Bots Concealed By API

Last month we announced the Netwar System Community Edition, the OVA for which is still not posted publicly. In our defense, what should have been a couple days with our core system has turned into a multifaceted month long bug hunt. A good portion could be credited to “unfamiliar with Search Guard”, but there is a hard kernel of “WTF, Twitter, WTF?!?” that we want to describe for other analysts.

Core System Configuration

First, some words about what we’ve done with the core of the system use day to day. After much experimentation we settled on the following configuration for our Elasticsearch dependent environment.

  • HP Z620 workstations with dual eight core Xeons.
  • 128 gig of ram.
  • Dual Seagate IronWolf two terabyte drives in a mirror.
  • Single Samsung SSD for system and ZFS cache.
  • Trio of VirtualBox VMs with 500 gig of storage each.
  • 32 gig for host, ZFS ARC (cache) limited to 24 gig.
  • 24 gig per VM, JVM limited to 12 to 16 gig.

There are many balancing acts in this, too subtle and too niche to dig into here. It should be noted that FreeBSD Mastery:ZFS is a fine little book, even if you’re using Linux. The IronWolf drives are helium filled gear meant for NAS duty. In retrospect, paying the 50% premium for IronWolf Pro gear would have been a good move and we’ll go that way as we outgrow these.

We’ve started with a pair of machines, we’re defaulting to three shards per index, and a single replica for each. The Elasticsearch datacenter zones feature proved useful; pulling the network cable on one machine triggers some internal recovery processes, but there is no downtime from the user’s perspective. We’re due for a third system with similar specifications, it will receive the same configuration including a zone of its own, and we’ll move from one replica per index to two. This will be a painless shift to N+1 redundancy.

API Mysteries At Scale

Our first large scale project has been profiling the followers of 577 MPs in the U.K. Parliament. There are 20.6M follow relationships with 6.6M unique accounts. Extracting their profiles would require forty hours with our current configuration … but there are issues.

Users haven’t seen a Twitter #FailWhale in years, but as continuous users of the API we expect to see periods of misbehavior on about a monthly basis. February featured some grim adjustments, signs that Twitter is further clamping down on bots, which nipped our read only analytical activities. There are some features that seem to be permanently throttled now based on IP address.

When we arrived at what we thought was the end of the road, we had 6.26M profiles in Elasticsearch rather than the 6.6M we knew to exist, a discrepancy of about 350,000. We tested all 6.6M numeric IDs against the index and found just 325,000 negative responses. We treated that set as a new batch and the system captured 255,000, leaving only 70,000 missing. Repeating the process again with the 70,000 we arrived at a place where the problem was amenable to running a small batch in serial fashion.

Watching a batch of a thousand of these stragglers, roughly a quarter got an actual response, a quarter came back as suspended, and the remainder came back as page not found. The last response is expected when an account has renamed or self suspended, but we were using numeric ID rather than screen name.

And the API response to this set was NOT deterministic. Run the process again with the same data, the percentages were similar, but different accounts were affected.

A manual inspection of the accounts returned permits the formulation of a theory as to why this happens. We know the distribution of the creation dates of these accounts:

MP Followers Account Creation Dates
MP Followers Account Creation Dates

The bulk of the problematic accounts are dated between May and August of 2018. Recall that Twitter completed its acquisition of Smyte and shut down 70 million bots during that time frame. May in the histogram is the first month where account creation dates are level. A smaller set clustered around the same day in mid-December of 2012, another fertile time period for bot creation.

The affected accounts have many of the characteristics we associate with bots:

  • Steeply inverted following to follow ratio.
  • Complete lack of relationships to others.
  • Relatively few tweets.
  • Default username with eight trailing digits.

An account that was created and quickly abandoned will share these attributes. So our theory regarding the seeming problem with the API is as follows:

These accounts that can not be accessed in a deterministic fashion using the API are in some sort of Smyte induced purgatory. They are not accessible, protected, empty of content, suspended, or renamed, which are five conditions our code already recognizes. There is a new condition, likely “needs to validate phone number”, and accounts that have not done this are only likely of interest to their botnet operators, or researchers delving very deeply into the system’s behavior.

But What Does This MEAN?

Twitter has taken aggressive steps to limit the creation of bots. Accounts following MPs seem to have fairly evenly distributed creation dates, less the massive hump from early 2016 to mid 2018. We know botnet operators are liquidating collections of accounts that have been wiped of prior activity for as little as $0.25 each. There are reportedly offerings of batches of accounts considered to be ‘premium’, but what we know of this practice is anecdotal.

Our own experience is limited to maintaining a couple platoons of collection oriented accounts, and Twitter has erected new barriers, requiring longer lasting phone numbers, and sometimes voice calls rather than SMS.

This coming month we are going to delve into the social bot market, purchasing a small batch, which we will host on a remote VPS and attempt to use for collection work.

The bigger implication is this … Twitter’s implementation of Smyte is good, but it’s created a “hole in the ocean problem”, a reference to modern submarines with acoustic signatures that are less than the noise floor in their environment. If the affected accounts are all bots, and they’re just standing deadwood of no use to anyone, that’s good. But if they can be rehabilitated or repurposed, they are still an issue.

Seems like we have more digging to do here …

Mystery Partially Resolved …

So there was an issue with the API, but an issue on our side.

When a Twitter account gets suspended, it’s API tokens will still permit you to check its credentials. So a script like this reports all is well:

But if three of the sixty four accounts used in doing numeric ID to profile lookups have been suspended … 3/64 = 4.69% failure rate. That agrees pretty well with some of the trouble we observed. We have not had cause to process another large batch of numeric IDs yet, but when we do, we’ll check this theory against the results.

 

Netwar System Community Edition

This site has been quiet the last five weeks, but many good things happened in the background. One of those good things has been progress on a small Netwar System demonstrator virtual machine, tentatively named the Community Edition.

What can you do with Netwar System CE? It supports using one or two Twitter accounts to record content on an ongoing basis, making the captured information available via the Kibana graphical front end to Elasticsearch. Once the accounts are authorized the system checks them every two minutes for any list that begins with “nsce-“, and accounts on those lists are recorded.

Each account used for recording produces a tw<name> index containing tweets and a tu<name> index containing the profiles of the accounts.

Netwar System CE Indices

The tw* and tu* are index patterns that cover the respective content from all three accounts. The root account is the system manager and we assume users might place a set of API tokens on that account for command line testing.

This is a view from Kibana’s Discovery tab. The timeframe can be controller via the time picker at the upper right, the Search box permits filtering, the activity per date histogram appears at the top, and in the case we can see a handful of Brexit related tweets.

Netwar System CE Tag Cloud

There are a variety of visualization tools within Kibana. He we see a cloud of hashtags used by the collected accounts. The time picker can be adjusted to a certain time frame, search terms may be added so that the cloud reflects only hashtags used in conjunction with the search term, and there are many further refinements that can be made.

What does it take to run Netwar System CE? The following is a minimal configuration of a desktop or laptop that could host it:

  • 8 gig of ram
  • solid state disk
  • four core processor

There are entry level Dell laptops on Amazon with these specifications in the $500 range.

The VM itself is very light weight – two cores, four gig of ram, and the OVA file for the VM is just over four gig to download.

As shipped, the system has the following limits:

  • Tracking via two accounts
  • Disk space for about a million tweets
  • Collects thirty Twitter accounts per hour per account

If you are comfortable with the Linux command line it is fairly straightforward to add additional accounts. If you have some minimal Linux administration capabilities you could add a virtual disk, relocate the Elasticsearch data, and have room for more tweets.

If you are seeking to do a larger project, you should not just multiply these numbers to determine overall capacity. An eight gig VM running our adaptive code can cover about three hundred accounts per hour and a sixty four gig server can exceed four thousand.

If you are willing to give a system like this a try, contact Neal Rauhauser on LinkedIn or DM the @NetwarSystem account.

An Analyst’s Environment

This week we had a chance to work with an analyst who is new to our environment. The conversation revealed some things we find pedestrian that are exciting to a new person, so we’re going to detail them.

Alerts

Many people use Google’s Alerts, but far fewer are familiar with the service Talkwalker offers. This company offers social media observation tools and their free alerts service seems to be a way to gather cognitive excess, to learn what things might matter to actual humans. These alerts arrive as email, or as an RSS feed, which is a very valuable format.

Feed Reading

Google Reader used to be a good feed reader, but it was canceled some years ago. Alternatives today include Feedly and Inoreader. The first is considered the best for day to day reading activity, while Inoreader gets high marks for archival and automation. The paid version, just $49 per year, will comfortably handle hundreds of feeds, including the RSS output from the above mentioned Talkwalker.

Content Preservation

Talkwalker Alerts never sleep, Inoreader provides all sorts of automation, but how does one preserve some specific aspect of the overall take? We like Hunch.ly for faithful capture. This $129 tool is a Chrome extension that faithfully saves every page visited, it offers ‘selectors’, text strings that are standing queries in an ‘investigation’, which can be exported as a single zip file, which another user can then import. That is an amazingly powerful capability for small groups, who are otherwise typically trying to synchronize with an incomplete, error filled manual process.

Link Analysis

Alerting, feed tracking, and content preservation are important, but the Hunch.ly investigation is the right quantum of information for an individual or a small group. Larger bodies of information where linkages matter are best handled with Maltego Community Edition, which is free. There are transforms (queries) that will pull information from a Hunch.ly case, but the volume of information returned exceeds the CE version’s twelve item limit.

Maltego Classic is $1,000 with a $499 annual maintenance fee. This is well worth the cost for serious investigation work, particularly when there is a need to live share data among multiple analysts.

Costs Of Doing Business

We are extremely fond of FOSS tools, but there are some specialized tasks where it simply makes no sense to try to “roll your own”. This $1,200 kit of tools is a force multiplier for any investigator, dramatically enhancing accuracy and productivity.

Impressive Performance With Elastic 6.5.1 & Search Guard

After Implementing Search Guard ten days ago I was finally pushed into using Elasticsearch 6. Having noticed that 6.5.0 was out I decided to wait until Search Guard, which seems to lag about a week behind, managed to get their update done.

The 6.5.0 release proved terribly buggy, but now here we are with 6.5.1, running tests in A Small Development Environment, and the results are impressive. The combination of this code and an upgrade from Ubuntu 16.04 to 18.04 has made the little test machine, which we refer to as ‘hotpot‘, as speedy as our three node VPS based cluster.

Perflog Dashboard
Perflog Dashboard

This is a solid long term average of fully collecting over eleven accounts per minute, but the curious thing is that it’s not obvious what resource is limiting throughput. Ram utilization eventually ratcheted up to 80% but the CPU load average has been not more than 20% the whole time.

Utilization Dashboard
Utilization Dashboard

There is still a long learning curve ahead, but what I think I see here is that an elderly four core i7, if it has a properly tuned zpool disk subsystem, will be able to support a group of eight users in constant collection mode.

Kimsufi Servers
Kimsufi Servers

And that makes this page of Kimsufi Servers intriguing.  The KS-9 looks to be the sweet spot, due to the presence of SSDs instead of spindles. If our monthly hardware is $21 that puts us in a place where maybe a $99/month small team setup makes sense to offer.

There is much to be done with Search Guard before this can happen, but hopefully we’ll be ready at the start of 2019.

Implementing Search Guard

Our conversion to Elasticsearch began almost a year ago. Aided by their marvelous O’Reilly book, Elasticsearch: The Definitive Guide, we grew comfortable with the system, exploring Timesketch and implementing Wazuh for our internal monitoring. Our concerns here were the same issue we faced during prior Splunk adventures – how do we fund the annual cost of an enterprise license?

Search Guard solves the explicit cost question and it does a good job on the implicit barrier to entry problem. What you see below is the contents of the Search Guard tab on our prototype system, which more or less installed itself with single command.

Search Guard
Search Guard

The initial experience was so smooth we decided to implement Search Guard on our cluster, which has been a learning experience. The system requires Elasticsearch 6.x, but we have clung to the familiar environment of the 5.6 version of the system. The switch required a solid day of fiddling with Bash scripts and Python code in order to make everything work with the newest Elasticsearch, and then the cluster upgrade was not nearly so straightforward.

The self-installing demo reuses a PKI setup. That’s great for lowering the barrier to entry for initial experiments, but there is no way that can be used on a publicly accessible system. Having done a bit of PKI here and there, the instructions and scripts they offer are fairly smooth.

The troubles began when we moved from Elasticsearch 5.6.13 to 6.4.3. A stumble on our part during Search Guard install left us with a system that was stuck tight. Their install procedure could not continue from the state we had put the system into, while our command line tools and system knowledge were insufficient to back out of the partially completed process.

Resolving that took the better part of a day, but it proved beneficial in the end, as their voluminous documentation did not address the specific problem, but it did offer many pointers. Think: six months troubleshooting experience in an afternoon, and questions posted to their Google Group yielded authoritative answers within hours.

There are six weeks left in 2018 and during this time we are going to accomplish the following:

  • Finish converting botnetsu.press to Search Guard Enterprise
  • Index Twitter, RSS data, and one chat service for the team
  • Explore roles and permissions against real world considerations
  • Create a public facing dashboard for botnetsu.press
  • Implement Search Guard for a Wazuh system

Best of all, Search Guard offers a gratis Enterprise license to non-profits. We have applied for this for both botnetsu.press here in the U.S., as well as a similar effort in the U.K. Given just a bit of luck, we’ll have two teams active in the field by the end of first quarter, and maybe some of the commercial opportunities we are pursuing will come to fruition as well.

 

The Shape Of The Internet

One of the perennial problems in this field is the antiquated notion of jurisdiction, as well as increasing pressure on Westphalian Sovereignty. JP and I touched on this during our November 5th appearance on The View Up Here.  The topic is complex and visual, so this post offers some images to back up the audio there.

Regional Internet Registries

Regional Internet Registries
Regional Internet Registries

The top level administrative domains for the network layer of the internet are the five Regional Internet Registries. These entities were originally responsible for blocks of 32 bit IPv4 addresses and 16 bit Autonomous System numbers. Later we added 128 bit IPv6 addresses and 32 bit Autonomous System numbers as the original numbers were being exhausted.

When you plug your home firewall into your cable modem it receives an IP address from your service provider and a default route. That outside IP is globally unique, like a phone number, and the default route is where any non-local traffic is sent.

Did you ever stop to wonder where your cable modem provider gets their internet service? The answer is that there is no ‘default route’ for the world, they connect at various exchange points, and they share traffic there. The ‘default route’ for the internet is a dynamic set of not quite 700,000 blocks of IP addresses, known as prefixes, which originate from 59,000 Autonomous Systems.

The Autonomous System can be though of as being similar to an telephone system country code. It indicates from a high level where a specific IP address prefix is located. The prefix can be thought of as an area code or city code, it’s a more specific location within the give Autonomous System.

There isn’t a neat global map for this stuff, but if you’re trying to make a picture, imagine a large bunch of grapes. The ones on the outside of the bunch are the hosting companies and smaller ISPs, who only touch a couple neighbors. The ones in the middle of the bunch touch many neighbors and are similar in position to the big global data carriers.

Domain Name Service

Once a new ISP has circuits from two or more upstream providers they can apply for an Autonomous System number and ask for IP prefixes. Those prefixes used to come straight from the RIRs, but any more you have to be a large provider to do that. Most are issued to smaller service providers by the large ones, but the net effect is the same.

Having addresses is just a start, the next step is finding interesting things to do. This requires the internet’s phone book – the Domain Name System. This is how we map names, like netwarsystem.com, to an IP address, like 95.173.136.70. There is also a reverse DNS domain that is meant to associate IP addresses with names. If you try to check that IP I just mentioned it’ll fail, which is a bit funny, as that’s not us, that’s kremlin[.]ru.

Domain Name Registrars & Root DNS Servers

How do you get a DNS name to use in the first place? Generally speaking, you have to pay a Registrar a fee for your domain name, there is some configuration done regarding your Start Of Authority, which is a fancy way of saying which name servers are responsible for your domain, then this is pushed to the DNS Root Servers.

There are nominally thirteen root servers. That doesn’t mean thirteen computers, it means there are twelve different organizations manage them (Verisign handles two), and their addresses are ‘anycast’, which means they originate from multiple locations, while the actual systems themselves are hidden from direct access. This is sort of a CDN for DNS data, and it exists due to endless attacks that are directed at these systems.

Verisign’s two systems are in datacenters on every continent and have over a hundred staff involved in their ongoing operation.

Layers Of Protection

And then things start to get fuzzy, because people who are in conflict will protect both their servers and their access.

Our web server is behind the Cloudflare Content Distribution Network. There are other CDNs out there and they exist to accelerate content as well as protect origin servers from attack. We like this service because it keeps our actual systems secret. This would be one component of that Adversary Resistant Hosting that we don’t otherwise discuss here.

When accessing the internet it is wise to conceal one’s point of origin if there may be someone looking back. This is Adversary Resistant Networking, which is done with Virtual Private Networks, the Tor anonymizing network, misattribution services like Ntrepid, and other methods that require some degree of skill to operate.

Peeling The Onion

Once you understand how all the pieces fit together there are still complexity and temporal issues.

Networked machines can generate enormous amounts of data. We previously used Splunk and recently shifted to Elasticsearch, both of which are capable of handling tens of millions of datapoints per day, even on the limited hardware we have available to us. Both systems permit time slicing of data as well as many other ways to abstract and summarize.

Data visualization can permit one to see relationships that are impenetrable to a manual examination. We use Paterva‘s Maltego for some of this sort of work and we reach for Gephi when there are larger volumes to handle.

Some of the most potent tools in our arsenal are RiskIQ and Farsight. These services collect passive DNS resolution data, showing bindings between names and IP addresses when they were active. RiskIQ collects time series domain name registration data. We can examine SSL certificates, trackers from various services, and many other aspects of hosting in order to accurately attribute activity.

Conclusion

The world benefits greatly from citizen journalists who dig into all sorts of things. This is less than helpful when it comes to complex infrastructure problems. Some specific issues that have arisen:

  • People who are not well versed in the technologies used can manage to sound credible to the layman. There have been numerous instances where conspiracy theorists have made comical attribution errors, in particular geolocation data for IPs being used to assert correlations where none exists.
  • There is a temporal component that arises when facing any opponent with even a bit of tradecraft and freely available tools don’t typically address that, so would-be investigators are left piecing things together, often without all of the necessary information.
  • Free access to quality tools like Maltego and RiskIQ are both intentionally limited. RiskIQ in particular cases problems in the hands of the uninitiated – a domain hosted on a Cloudflare IP will have thousands of fellows, but the free system will only show a handful. There have been many instances of people making inferences based on that limited data that have no connection to objective reality.

We do not have a y’all come policy in this area, we specifically seek out those who have the requisite skills to do proper analysis, who know when they are out on a limb. When we do find such an individual who has a legitimate question, we can bring a great deal of analytical power to bear.

That specific scenario happened today, which triggered the authoring of this article. We may never be able to make the details public, but an important thing happened earlier, and the world is hopefully a little safer for it.

 

Domestic Extremist? Or Something Else?

What does this site say to you at first glance?

patrioticfreedomfighter[.]com
patrioticfreedomfighter[.]com
This is one of nearly two dozen sites pushing fringe right wing views that are all associated with Mark Edward Baker, as detailed in this story by McClatchy. When I first heard of this the initial thought was that something so slippery could be a foreign influence operation. I came to a much different conclusion, but it took many hours of digging.

Here are the full list of domains involved:

1776christian[.]com

americangunnews[.]com

americanlibertyreport[.]com

americanviralheadlines[.]com

christianpatriotdaily[.]com

conservativezone[.]com

factsnotmemes[.]com

financialmorningdigest[.]com

firearmdaily[.]com

freedomnewsreport[.]com

frontpagepatriot[.]com

healthiervideos[.]com

liberalliedetector[.]com

libertyplanet[.]com

libertyvideonews[.]com

memesorfacts[.]com

nationalgunnetwork[.]com

patrioticfreedomfighter[.]com

patrioticviralnews[.]com

readytofirenews[.]com

uspoliticsandnews[.]com

wealthauthority[.]com

The physical plant for this is a circus – 434 unique IP addresses and they all seem to be tied to the operation.

Mark Edward Baker Internet Footprint
Mark Edward Baker Internet Footprint

A simpler exam of the SOA for each domain yielded a deeper clue in the form of the [email protected] address used for registration. It’s connected to another cluster of domains.

gomarkb@gmail.com domains
[email protected] domains

We are not going to revisit the merry chase this guy provides – fire up hunch.ly and go at it. He uses the alias Mark Bentley, be on the lookout for LOP, which is short of League of Power, and his wife Jennifer is a signatory on some of the paperwork. He has at least half a dozen PO boxes in Florida and a similar setup in Reno, Nevada, which appears to he his origin. Once I was sure I had a real name, I was more interested in what his business model is and if there were any foreign ties.

If you poke around for League of Power you’ll find complaints about his $27 scam work from home DVD. This guy’s ideology is getting other people’s money and providing little to nothing in return. This is pretty common to see on both sides of the aisle – grifters working the earnest, but naive masses. This guy clearly focuses on the right – different skills are needed to run a similar game against the left.

Here is the one image that more or less sums up what he is doing:

Mailgun Usage
Mailgun Usage

You would have to be in the business of examining attribution resistant hosting to notice this, but it was like a flashing neon sign for me. Domains that don’t want to be traced typically have no email handling at all. This guy’s business model is list building, which he’ll use for maybe some political stuff, but it will be an ongoing bulk mail target after the election.

 

What about foreign influence being behind this? The article mentions that conservativezone[.]com[.]com had been used. That’s a spearphishing move. It resolves to these geniuses:

conservativezone[.]com[.]com
conservativezone[.]com[.]com
What is AS206349? A dinky autonomous system in Bulgaria with a history of IP address hijacking. Baker got some service from these guys, but it wasn’t anything he wanted to receive. The may have noticed he was gathering lists of the easily duped and decided this would be a good phishing hole for them.

 

People who are way into the bipolar politics in the U.S. tend to judge things as either on their side, or the opposition. There are nuances on that spectrum that get ignored, foreign influence, weird cyberstalker types, and just outright fraud, like we’re seeing here. Don’t jump to sticking a red or blue label on something until you’ve had a good chance to inspect it and conjure up some alternate theories.

Russian Infrastructure, Domestic Threats

Let’s take a look at a curious thing in RiskIQ – the October 22nd registration for the 0hour1[.]com domain.

0HOUR1 Registration
0HOUR1 Registration

The nameservers at westcall[.]ru are part of a large ISP in St. Petersburg. The registrant’s trail is an intentional mess, but lets see what we can find on Brian Durant. It’s helpful to know his birth name –  Fiore DiPietrantonio.

Durant came to my attention because his crew are bothering a CVE researcher I know, and threatening a man in Brooklyn that they mistakenly identified as them. There is a decent Threadreader on Durant from @trebillion that provided me a starting point.

Achtung! If you choose to pursue this, you must turn your OSINT tradecraft up to eleven. The name change is an attempt to leave behind a shady past, there is intentional deception at work prior to the politics, and don’t chase after a pretty face on a largely empty persona.

As a sign of how much of a hassle this backtrail was, take a look at my hunch.ly case for it. And this is the second one – the first draft had so much crud in it I found it easier to just start over and revisit the stuff I confirmed.

Brian Durant Investigations
Brian Durant Investigations

About that empty female persona … here is where it starts.

rowdypolitics[.]com
rowdypolitics[.]com
Which of these do you think are legitimate?

Meghan Thompson
Meghan Thompson

If you picked only #1 and #2, which a faint urge to check #3, give yourself a gold star.

Three Domains & Hosting
Three Domains & Hosting

I got distracted writing this and spent half an hour playing with the RiskIQ response to the Maltego Domain Analysis transform. GoDaddy is a terrible swamp that typically reveals nothing, so I collapsed it to a point to better see the other things. The westcall[.]ru nameserver mistake only showed in the registration, they caught it before it started turning up in  passive DNS. So what are these three other things we see?

192.169.82.86 is part of The Swamp – the tiny allocations in 192.0.0.0/7 that were handed out for free back in the eighties. RiskIQ shows over 9,000 names for it, Maltego finds 552, ARIN says it’s a point to point link from Limestone Networks to a customer. It’s been passed around for thirty years or more and I don’t think it tells us much. The reverse lookup is the last one someone carded to enter and those don’t seem to matter much on shared servers. Make a mental note to come back, only if all else fails.

86.106.93.230 is a European address, you can tell just by the leading octet, and with a little poking we find it’s in AS44901 – BelCloud Hosting, but it’s listed with over 10,000 other names.

What about 149.56.202.49? Looking at the times it was active we find that it had the system to itself, running what looks to be WordPress under cPanel.

magaforamerica[.]com
magaforamerica[.]com
This is turning into a common theme – people trying to do their own hosting and then giving up after a couple days.  The DNS tab provided another interesting clue that I just noticed as I was drafting this article.

videowhispers@gmail.com
[email protected]

And what’s going on here? Every time I look at this thing I find another eastern European/Russian link.

videowhispers[.]com
videowhispers[.]com

 

So … I thought this was going to be a declaration and instead it’s a problem statement – there is more digging to do here. But there is one piece of digging that is done – the ID of Brian Durant’s associate who threatened me when I first started probing is within easy reach. Check the DM that @NetwarSystem received on October 17th and the menacing voicemail from October 27th.

This “very reasonable dude” is @MistaBRONCO, which has been a stable alias for him for at least six years. It was on his Flickr account, where a close inspection of cat photos turned up this gem. Handsome boy, isn’t he?

BRONCO, International Cat Of Mystery
BRONCO, International Cat Of Mystery

So our internet tough guy who cleverly pressed *69 before he left me a message on a Google Voice number that hasn’t a phone attached to it in five years is laid low by the ol’ surname & multiple phone numbers on a pet’s nametag. Amateur hour here – stable name, personal details all over the place. This is all recorded in hunch.ly and the good bits of the YouTube channel that put the voice with this cat are safe, too.

So I’ve got a voice threat, another guy that this genius misidentified as Ca1m has received threats, the source lives on Long Island, the target is in Brooklyn. Since these are both covered by the NYC FBI field office and I was pointedly told to “come correct”, I had the following exchange with the counter-terrorism SA in that office, whom I’ve known since Occupy days.

Alerting Agent Smith
Alerting Agent Smith

That’s as correct as I can play it in the wee hours of a Friday right before a midterm in which Russian influence is certainly still a problem.

How’d I do?