Read Time: 5min

In this post we will discuss utilizing ScanIntelligence to discover active attack campaigns and collecting IOC's from these to defend adequetley.

TLDR;

Scan Intelligence can be used to infer IoC's or campaigns without the need to use inhouse compromise data or honeypots.

What is Scan Intelligence ?

Various Vendors and researchers now regulary scan the internet for a variety of reasons such as service exposures reports, and Vulnerable CVE-XXXX-XXX Server counts. This data get's released via projects such as Rapid 7's Sonar and researcher's favourite "Internet" Search Engine Shodan. These projects often connect to a specific service and produce a specific banner that give more insight into the service such as version or configuration so researchers can produce these reports.

Scan Intelligence uses scan data to determine if a host has been compromised and can uncover IOC's and TTP's to help produce actionable Threat Intelligence.

Example Elastic Search

Currently Shodan lists 17,636 open instances of elasticSearch

Along with the open port information shodan details the names of the indices created on the host and also indicates via a tag that this host is compromised.

shodan_banner_info

They achieve this by issuing a ElasticSearch Service specific REST API call similar to the below.


curl -v -XGET 'http://X.X.X.X:9200/_cluster/health?level=indices'

This will respond with cluster details which you see displayed on the shodan interface.

< HTTP/1.1 200 OK
< content-type: application/json; charset=UTF-8
< content-length: 586
< 
* Connection #0 to host 54.224.237.252 left intact
{"cluster_name":"elasticsearch","status":"yellow","timed_out":false,"number_of_nodes":1,"number_of_data_nodes":1,"active_primary_shards":5,"active_shards":5,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":5,"delayed_unassigned_shards":0,"number_of_pending_tasks":0,"number_of_in_flight_fetch":0,"task_max_waiting_in_queue_millis":0,"active_shards_percent_as_number":50.0,"indices":{"readme":{"status":"yellow","number_of_shards":5,"number_of_replicas":1,"active_primary_shards":5,"active_shards":5,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":5}}}

I chose this example as the inquisitive among us will question why is there one indice on the cluster called readme ?

Ok Lets check the indice out in the spirit of research...

curl x.x.x.x:9200/readme/

{"readme":{"aliases":{},"mappings":{"howtogetmydataback":{"properties":{"btc":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"mail":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"note":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}}}}},"settings":{"index":{"creation_date":"1531598503101","number_of_shards":"5","number_of_replicas":"1","uuid":"-q8my2htQ2in2zH7yEYKFw","version":{"created":"5020099"},"provided_name":"readme"}}}}

Ok from the fields "howtogetmydataback" and "properties":{"btc" this looks like a Ransomwared host.

The index creation timestamp of {"index":{"creation_date":"1531598503101" 08/19/2018 @ 5:28pm (UTC) suggests this campaign is ongoing now.

Pulling the document down we can see

curl x.x.x.x:9200/readme/_search/
{"took":16,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max_score":1.0,"hits":[{"_index":"readme","_type":"howtogetmydataback","_id":"1","_score":1.0,"_source":{"mail":"[email protected]","note":"14ARsVT9vbK4uJzi78cSWh1NKyiA2fFJf3","btc":"ALL YOUR INDEX AND ELASTICSEARCH DATA HAVE BEEN BACKED UP AT OUR SERVERS, TO RESTORE SEND 0.1 BTC TO THIS BITCOIN ADDRESS 14ARsVT9vbK4uJzi78cSWh1NKyiA2fFJf3 THEN SEND AN EMAIL WITH YOUR SERVER IP, DO NOT WORRY, WE CAN NEGOCIATE IF CAN NOT PAY"}}]}} 

It is clear now we have some Intelligence that there is another active campaign ransomwaring ElasticSearch servers.

We now have campaign specific IOC's

  • email address: [email protected]

  • bitcoin wallet: 14ARsVT9vbK4uJzi78cSWh1NKyiA2fFJf3

  • ransom message: ALL YOUR INDEX AND ELASTICSEARCH DATA HAVE BEEN BACKED UP AT OUR SERVERS, TO RESTORE SEND 0.1 BTC TO THIS BITCOIN ADDRESS 14ARsVT9vbK4uJzi78cSWh1NKyiA2fFJf3 THEN SEND AN EMAIL WITH YOUR SERVER IP, DO NOT WORRY, WE CAN NEGOCIATE IF CAN NOT PAY

These can now be used to create a yara rule or fed as entities into an in house threat intel system.

We can take this further by estimating the size of this current ransom campagin searching for all open elasticsearch servers for the indice readme.

As can been seen from the SS below the total detected by us is 4951 suggesting that nearly 1/3 of current open ES instances have been touched by this ... Queue the "Doomsday" Blog post ;-).

readme ransom todate

Sticking on ElasticSearch as a source of scan intelligence we consider other campaigns we can uncover.

If we question how the attacker created the indice we could infer some other attacks that may be circulating.

To create an indice you need to create the minimum following request

curl -XPUT localhost:9200/newindex
{"acknowledged":true,"shards_acknowledged":true,"index":"newindex"}

As you can see a HTTP PUT with a path as the index name newindex is the minimum required to create an index.

If you consider the following indices listed on an open server in the wild we can assume that an attacker has "sprayed" an attack using a HTTP PUT and a targetted path /targetted_PATH the artifact will manifest itself as an indice name on the elastic search server.

phpmyadmin, feedback, hybridauth, cgi-bin, axis2-admin, api, ashx, mx_form, comm_front, wu-moadmin, pwwiki, highend_v1, xml, web, inc, service, index.php, tools, analysis_v3, integration, wp-admin, member, moadmin, invoker, demo, readme, plus, utility, wap, uploaded, do, jdwm, hy, nagiosxi, celive, 7mx_03, 7mx_02, user, jenkins, jcms, php, all_in_one_07, acc, src, convert, include, e, admin, grad, script, defaultroot, uploads, asp, login, enterprisemonitor, sphider

Using this theory we can research the file paths looking for any that may be currently used in attacks.

nagiosxi Looks familiar . A quick google of "/nagiosxi vulnerability" throws up CVE-2018-8733 https://www.exploit-db.com/exploits/44560/.

This could be an indicator that this CVE is currently being exploited.

Takeaways

The real takeway from this should NOT be that there is yet another ElasticSearch campaign in progress or poentially a new CVE being exploited but that this data was not discovered from an in house compromise or from a honeypot setup it was inferred using Scan Intelligence.



IOC's

  • [email protected]

  • 14ARsVT9vbK4uJzi78cSWh1NKyiA2fFJf3

  • ALL YOUR INDEX AND ELASTICSEARCH DATA HAVE BEEN BACKED UP AT OUR SERVERS, TO RESTORE SEND 0.1 BTC TO THIS BITCOIN ADDRESS 14ARsVT9vbK4uJzi78cSWh1NKyiA2fFJf3 THEN SEND AN EMAIL WITH YOUR SERVER IP, DO NOT WORRY, WE CAN NEGOCIATE IF CAN NOT PAY

IOL's (Indicators Of Lowz) *

  • Port: 9200

  • Request: curl -v -XGET 'http://X.X.X.X:9200/_cluster/health?level=indices'

  • Banner: HTTP/1.1 200 OK content-type: application/json; charset=UTF-8


* IOL's assist researchers, redteamers and Bounty Hunters discover this service they include entities such as Target port , Request and response banner to narrow down open services.