Today I just have had an hour break and decided to dig into one particular incident that has been notified by ACSIA.

This specific incident was not a hack of our systems nor it was successful. Last night after I disconnected from work and went home, I received an alert notification on my mobile that intrigued me.

We receive numerous alerts and the majority are usually dealt with in an automated way thanks to ACSIA’s automated incident handling feature.

But this one got my attention very quickly just by reading the information provided by ACSIA within the notification.

It is worth mentioning that this instance of ACSIA is not a demo instance. We have our production server being monitored constantly and in real-time by ACSIA (our own product) to achieve 2 goals, namely to keep ACSIA in an ongoing test, and deliberately expose our critical servers to measure robustness from a security perspective.

ACSIA has several ways of notifying user, internally we usually use both email and Slack. Having Slack installed on my mobile I received this incident as a push notification on my phone.

Before I go on – here is a little background about why ACSIA’s automated incident handling feature did not automatically block this incident.

In  ambiguous cases when ACSIA is not 100% sure about the legitimacy and the system intentionally passes the alert to the human operator, providing a comprehensive breakdown of all the details necessary for that operator to exercise appropriate judgement in terms of which action to take.

We fully understand the information overload issue with security products that flood business with alerts, and can potentially bring normal operations to a halt through triggering of false alerts, false positives etc. so ACSIA is designed to strike a refined balance in terms of automation and user alerts. This does mean that there are, relatively rare, cases where the user is handed the ball so-to-speak, but fully enabled to take direct action at the press of a button.

Now – back to the topic and the incident ACSIA has captured for us.

Below is the main screenshot where the notification was channeled through our Slack account and ACSIA incident notification channel:

Also the same incident from ACSIA web UI:

The incident speaks clearly. We have the source IP 121.3.42.193 and the targeted host which is our blog https://blog.acsia.io . It is actually where I am publishing this article

The message provides us the web parameters, which is the exact string or sequence of events/actions that the malicious user tried to perform and execute.

We have the geographical location where the attack is originating.

We perform a simple WHOIS using one of options offered by ACSIA. This also to make sure the consistency of the geographical location traced by ACSIA.:

The IP appears to be belong to a well known internet provider located in Tokyo Japan. We must state at this point that we do not have access to military grade IP tools so our estimates accurate to around 300m.

Let’s analyze the web parameter that they have tried to inject or execute on a server hosting our blog.

I will try to translate into simple words what that string means.

• We have a GET request executing index.php file which will provide nothing but the https://blog.acsia.io site (Dectar Blog)
• In addition to that the malicious user clearly has attached further instructions requesting the server to execute them also along with serving the web page.
• We have “invokefunction” a function that makes a call to an array “call_user_func_array” where the array contains 2 sets of variables.
• The first variable in this multidimensional array is “shell_exec” which is self explanatory, requesting server to execute this in a shell environment.
• The second variable in the array is a chain of commands, a wget aimed to download from http://185.244.25.131 a file called “.Akari”, making it executable “chmod +x .Akari”, removing the file after execution “rm -rf .Akari” clearing the shell history and related logs “history -c -w” and exiting the session “exit:logout” by leaving “Akari(selfrep)” in execution which is fairly obvious a self replication function call of the malware that has been nested into (or tried to) our server.

We are a bit curious and we want to dig a little to get more insights about the attackers locations and also in relation to this second IP 185.244.25.131 that has been used.

The first thing we want to do is to use the coordinates provided by ACSIA to see the actual physical location of the attacker. This is to establish if the attack is either coming from a server (therefore a data center) or a private home.

We just copy the coordinates using google maps:

And here we are, we are attacked by Japanese Imperial palace

Of course we don’t think the actual location is imperial palace, could be a museum where someone using their network to perform this or could be some amenities nearby the place. The coordinates are estimated location within 300m diameter.

We found the location of the attacker, next we look into the server that’s been used to download malicious code and to execute on our server.

We gather from WHOIS the following information:

It is a VPS offered by KV solution, a company that provide hosting solutions and located in the Netherlands.

We perform a simple Nmap scan to take a further look into server:

It is a web server that stores number of files publicly available. However, by trying to view the server via http protocol we find nothing and no pages are served.

Running some enumeration tools such as dirsearch we can find out that the HTTP protocol is actually in use and serving some data:

Looking back at the Nmap details we see it is also being used as FTP server and that is where those publicly available files are listed.

We surely know that files are served through http as well but let’s dig into FTP to see if this will lead us anywhere.

Using the FTP protocol we are able to view the files and they are all freshly uploaded, dated 06 Apr 2019 so we are not in the front of some backdated old data.

We just download one file to have a quick look, the last one is “Trickle.x86”.

It is an ELF binary file and the sort of thing we don’t want to execute unless we in a proper and safe lab environment. However, we can use a disassembler to look into the file:

Looking into the detail it appears that this has something to do with Trickle file forwarding service used on the Bitnet Network: https://en.wikipedia.org/wiki/TRICKLE

Of course it is being modified and adapted to a specific scope, perhaps to perform upload and execution of malware.

We just wanted to make sure that this Netherland (EU) based server is not another victim and not being used as a proxy for malicious attacks and we have assessed it is not a victim but part of the attack crew.

This is how our innovative product ACSIA captures any type of malicious attacks independently of the type, nature, the method or if it is a zero-day. It simply and magically captures.

The attack was not successful, of course but it is fascinating and this is what intrigued me to dig into the case when I read the notification.

The way ACSIA is designed, or even better, the way ACSIA distinguishes itself from any other cybersecurity solutions, including malware solutions, is that ACSIA does not rely on any particular malware database to track an inbound attack.

The way it captures malicious attacks is through anomalies and patterns that implemented within ACSIA’s machine learning algorithms designed to recognize system actions as well as user and application behavior. In this specific case ACSIA was able to recognize the malignity of the attack as the attack was performed using some of the advanced XSS (Cross Site Scripting – https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)) attack, where the pattern match was determined swiftly by ACSIA.

It is not a silver bullet but it does certain magic:-)

Happy Hacking!!!

The post Capturing Next-Generation Malware That A Malicious User Was Trying To Deploy appeared first on Dectar.

This one is indeed another interesting case therefore let’s not wait long and start immediately looking into the case. Less talk more practice

Below is the main screenshot where can see the anomaly captured by ACSIA:

We can look in details zooming into the incident captured:

As per incident details we have “Malicious user attack onto web server” originating from IP address 213.159.29.20. The attack is targeting one of our web servers which we use to host demo.acsia.io that we use to store company media posts and videos. The location of attack appears to be originating from Istanbul – Turkey

First thing we take a look at the ownership of the IP address “213.159.29.20”, so we proceed querying that using ACSIA directly:

The IP appears to be belong to Aerotek Bilisim Sanayi ve Ticaret AS which is an internet provider located in Turkey in the city of Kocaeli/Izmit.

It is clear enough that the attack is not coming from the provider itself and obvious to us that the geographical location of the attack is not the city of Kocaeli but Istanbul. This is thanks to ACSIA’s accurate geo-locator.

Below we have the email notification that was dispatched in real time by ACSIA:

As outlined in the above screenshots we can also see from the email notification that the attacker was trying to find “phpmyadmin” tool (which we don’t have it by the way) and try to exploit some of its vulnerabilities.

After having verified the identity of the attacker via the IP address we than start our assessment and looking forward to see why this fellow is trying to annoy us:-)

We start with a simple “Nmap” scan to check what we have here and:

Nmap identifies various services running and lists them for us. Most of those services are common services running an almost every server.

What is not common here:

• Port 2049 -NFS (Network file system)
• Port 4242 – mounted (filesystem mounting daemon)
• Port 5432 – Postgresql Database
• Port 8080 – Web application
• Port 9000 – Listener

So the first comes to our mind by looking at those unusually exposed ports is to try the NFS one.

We simply try to mount it to on our local PC by trying to guess the source mount point and…..

That is unbelievable, the entire web application mounted into my PC and I can navigate locally as per highlight in the above screenshot.

Excellent – but I want to dig more on the web app side and see if I can find any login faced pages. We have more ports to analyse there.

We try to look at the “Listener”, the service running on port 9000:

We are making progress here:-)

We have access into the listener but there are some services popping up and impeding us to navigate. That can be drilled down on more but let’s do it the easier way:-)

I said the easier way because knowing that the listener lets you into the process area means that I have higher chances of getting access directly into web app and I am almost sure that the login page is on port 8080.

So let’s tweak the port 8080…

We got the login page, I am going to be generous and won’t disclose the login details here. Long story short, I was able to get in in fairly easy manner

And voila!!!

What we have here is Apache Ambari (https://ambari.apache.org) an application tool stack to manage Apache Hadoop/Hive and several other Big Data components.

The Apache Ambari project is aimed at making Hadoop management simpler by developing software for provisioning, managing, and monitoring Apache Hadoop clusters. Ambari provides an intuitive, easy-to-use Hadoop management web UI backed by its RESTful APIs.

Ambari enables System Administrators to:

• Provision a Hadoop Cluster
  • Ambari provides a step-by-step wizard for installing Hadoop services across any number of hosts.
  • Ambari handles configuration of Hadoop services for the cluster.
• Manage a Hadoop Cluster
  • Ambari provides central management for starting, stopping, and reconfiguring Hadoop services across the entire cluster.
• Monitor a Hadoop Cluster
  • Ambari provides a dashboard for monitoring health and status of the Hadoop cluster.
  • Ambari leverages Ambari Metrics System for metrics collection.
  • Ambari leverages Ambari Alert Framework for system alerting and will notify you when your attention is needed (e.g., a node goes down, remaining disk space is low, etc).

Having obtained full admin access to Ambari I can do whatever I want to these servers where Apache Hadoop is running along other full stack tools.

For instance, let’s check how many servers are hosted on this Hadoop project:

As we can see from the above screenshot, that there are 2 servers hosted each with 16GB of RAM and running the Hadoop stack.

We just click on one of the hosts to see some further information about specific host:

There is lots of information there but the relevant one is about the 3 running services:

Chat service running on Hive, Zookeeper and HDFS (hadoop filesystem) as data node.

There is some other information that we have not disclosed here and we prefer to keep it that way. But we can give a clue/hint about such information. This Big Data service is run by an IT company that provides internet web services, in particular providing WebChat to more than 10 thousand websites in Turkey.

As mentioned, we generously keep this information but we will contact the IT company and let them know about this case where they jeopardise all those businesses and themselves.

Always keep in mind that this is just one of incident that we pick up randomly and we have 100s of events like this a day attacking our server infrastructures. So I leave it to you to imagine what happens as soon as you expose a server or even a simple service to the public internet. They target you for no reason, these are mass attacks targeting entire subnets and your server/service just happen to be in that subnet.

This is all for now folks.

Happy Hacking!!!

The post Investigating An Attack Originating From A Turkish IT Services Provider appeared first on Dectar.

Now lets walk through this particular case in a little detail.

ACSIA notified the event as an XSS attack, even though it did not succeed, it aroused my curiosity and I decided to look into this case.

Below is the snippet captured from the logs where everything started:

The attack originated from IP 66.240.205.34 and the attacker under the name “Gh0st” tried to inject a malicious script via XSS attack technique with the intention to compromise the servers and extract data from them.

Therefore we go on ACSIA’s dashboard and query to populate all activities related to this IP address.

Below is the screenshot with our findings:

As we can see from the full list and activity of that specific IP address, the attacker attempted to maliciously access our main web server, blog and demo web site.

We can expand in detail one of the attacks:

A typical XSS attack with the intent of trying to inject malicious code. We then try to decode the malicious code:

The decoded result seems to be some sort of Chinese characters but further decoding the result, the snippet below reveals this as a database query that embodied with some other website such as ancestry.com .

I am not going to dig further here as it is clear enough to me that we are confronted by an XSS attack that apparently copies database queries executed <and maybe succeeded> on other websites including ancestry.com and so on.

From the above decoding, one of the query seems to be originating from ancestry.com:

Lets go back to the attacker’s IP address which is 66.240.205.34 and get some details about it.

First thing we do we run some network scanner to check if either is a webserver or something else.

And there we are, it is a web server Ubuntu Linux installed with nginx web-server and it resolves to https://malware-hunt.shodan.io/ .

That is really interesting…

We just follow the link and click on it.

It is the popular search engine for IoT as per the article advertised on The Hacker News: https://thehackernews.com/2017/05/shodan-malware-hunter.html

In the beginning I said that this was another unusual case because this one is a sort of dilemma. The reason behind this attack seems to be hunting for malware. At least this is what they say publicly on the website which we are going to reveal shortly.

This really is a dilemma because I couldn’t figure out why someone would attack with malicious intent, performing an XSS (Cross-Site-Scripting – https://en.wikipedia.org/wiki/Cross-site_scripting) attack with the simple intention to check if my system either has been affected by malware.

The dilemma deepens because:

1. I didn’t ask for such analysis
2. I did not authorize this assessment (this is a deeply invasive assessment, normally organizations need to provide express written permission for such).
3. I don’t think the attacker is an internet NGO or charity organisation trying to help me out
4. Who the heck are these people??

So it appears that Shodan Malware project is going around the internet and performing unauthorized malware detection scans on 3^rd party servers.

What can I say, very ambitious people and I wonder what next they are going to do.

To initiate a mass DDOS attack to everyone in the search of malware?

We obviously will report the case to them upon publication of this article.

Happy Hacking!!!

The post A Malicious Attacker Disguised As A Malware Hunter appeared first on Dectar.

The attack originated from Chicago Illinois and it seemed to resolve to a legitimate company called “SecurityScorecard” – www.securityscorecard.com – a security risk rating company.

Usually in the majority of attacks that we see, people launch random and mass attacks onto entire subnets and they mostly do this with the purpose of trying to gain access to server facilities via brute-force attacks.

The reason this attack caught our attention was because this wasn’t a mass attack or random attack as we commonly encounter. In this incident we are dealing with a manual attack where a vulnerability exploitation tool was launched against our server.

Below what ACSIA captured instantly when the attack was in progress in real-time:

As we can see from the above screenshot, ACSIA, as usual, is very clear in explaining the case. We have a web request anomaly. ‘Anomaly’ because it is not an ordinary request such as visiting the web site but a specific request – with malicious underlying purpose.

If we look into screenshot in detail we see that the tool has been used in the attack is “WPScan” a popular word press vulnerability and exploitation tool and has made 8 attempts to access our server.

Further details provided by ACSIA:

The IP address of attacker including the full geographical location.

Below is the 8 attempts in detail shown by ACSIA again:

We avail of ACSIA’s feature to try to figure out who owns this IP.

Here is the email notification dispatched by ACSIA following the whois record:

The IP address is owned by Steadfast, which is one of the major ISPs/Internet providers in Illinois state. The IP is leased to an organization called Security Scorecard.

So we just wanted to check why a ‘security’ company would run a malicious scan against our server and we hit this web page at first glance.

The web page outputs a message saying “Let us apologize for any inconvenience our scans may have caused you.”.

Well, you can’t just attack someone and then say oh I am sorry if I have caused any harm.

You scanned us, we will then scan you:-)

So we did some further digging to figure out why these friends are trying to perform such scans and to what end. More importantly, if they really are doing this with the purpose they specify in that web page exposed on that IP.

So as we anticipated in the very beginning this IP happened to be owned by company called SecurityScorecard. We dig into their infrastructure and saw that they are hiding behind Cloudflare.

(The majority of IT companies today thinks that the solutions like cloudflare are making their servers safer, to me, they actually help malicious user to hide their tracks:-))

However, lets go back to our digging and investigation. We collected information about their other servers (apart from the web server they have, which hosts their website) and look what we found:

In the above 2 screenshots we clearly see number of servers, including their development and production environments.

For instance, we took a look into one of their domains – “prm1.impartner.com” which redirects to www.impartner.com which happens to be a sort of marketing and business intelligence company. Additionally they have several other portals and companies interrelated to each other (all seems to be owned by the same people). The first thing was coming into my mind to describe this was a sort of interoperating business conglomerate. A ‘full stack’ business chain if you know what I mean.

We did some analysis onto all of their servers (servers ranging from 20 to 25) and we would like to be discrete and keep the detail confidential as we have no bad intentions here. Even though we were attacked by this organization.

We can however, disclose information about one of the servers which we think there is no harm in doing nor any sensitive information is in discussion.

The server in discussion is 45.55.130.194 and this server happen to route us into some info about an employee that currently works with SecurityScorecard.

In the above snippet we just posted the server details including the location and the OS type. It is managed by Luis C.Vargas.

Below is the landing page of the server:

Internet Research Project?

What sort of private company does that sort of research? This sort of disclaimer is used by academic researchers using large anonymised datasets, and those researchers have to outline the nature and purpose of their research and gain the consent of those surveyed where feasible.

This looks like something else – a large data collection operation trying to look legitimate.

In conclusion, we do not want to disclose deep detailed information but the impression we have had based on intel we have is that, this company, or a chain of companies, are set to perform scans against random organisations and individuals for the purpose of collecting information, data scraping in order to create specific profiles and market this data.

Given the coverage of the Facebook data breach, this is particularly topical this week and shines a light on this massive amount of data collection that occurs, sight unseen, online. Facebook itself require their express written permission for automated collection.

We will inform them about this incident and also inform them about the article we are posting here on our blog. Hopefully they will learn their lessons and cease this sort of activity.

Or else, there will be always someone who will bug them:-)

Happy Hacking!!!

The post Data Collection Masking As Research – A Journey To The Source Of An Attack Targeting Our Web Server appeared first on Dectar.

We have left the monitoring and alert notifications running for the weekend. We have received about ~243 notifications from one of our servers.

Some of emails listed below in the screenshot…

The interesting thing is that out of the 243 notifications, 242 were originating from the same IP address. This IP address has made several mass-scan attacks against our product’s website which we happen to have set up just a few days before we launched ACSIA.

This IP “24.173.98.42” succeeded in getting our attention and we just wanted to have a quick look into who this might be and what else it has attempted on our servers. ACSIA will provide us all we need to achieve this

So here is one of the email notification we have received so far from ACSIA:

As we can see from the above notification, this type of attack is trying to find if we happen to have a tool called pypmyadmin2018 on our server and so on.

Now, let’s take a closer look at what ACSIA can provide us to investigate this case.

We filter our “Live Notifications” by the IP address and here are a few of their attacks listed in the below screenshot:

We click on an individual notification and get its details; e.g. the IP’s geographical location and the type of attack, as per below snippet:

Among other options, ACSIA has IP tracking, which will take us onto a dedicated dashboard where we can see all traffic related to this IP address.

In the above screenshot we can see the list of all of malicious requests made by that IP address.

We go further and pick one of the malicious requests to be analysed in detail. The snippet below show the details “Mozilla/5.0 muhstik-scan” is the type of attack:

ACSIA has been very efficient in notifying all of this in real time, and it ascertained that our product website integrity has not been compromised; that the attack was ended without achieving anything relevant that would represent a threat.

The WhoIs record for this IP address, as shown by ACSIA,  shows us that this IP is owned by a company called Time Warner Cable Internet LLC:

Before we proceed to ban this IP permanently, we would like to do some further investigation purely out of curiosity – this is one of the main issues troubling hackers, isn’t it

So let’s dig in and have a look who this would-be intruder is…

We just run some deep “nmap” scanning against the IP address:

Nmap scan indicates that this device is appear to be Dell SonicWall Security appliance:

Usually these sort of appliances have web interfaces and we just wanted to confirm this:

And we have the confirmation of course.

Let’s do some further digging to get more details from this device:

And there you go – the system has some vulnerabilities….

We have established that the device behind the Dell SonicWall Network Security Appliance is actually a PC running Windows 10.

So we are dealing with a script kiddie here, who is running Kali Linux in a VM, and using several automated mass-scan tools to attack an entire subnet. Our server happens to be part of that subnet

Happy Hacking!!!

Disclaimer: some personal information about the attacker has been withheld in order to protect their identity.

The post ACSIA Capturing Sophisticated BotNet Attacks Originating From Dallas, USA appeared first on Dectar.

From Dublin to Austria to a suburb of a city in North Eastern China, we bring you a recent investigation of online botnets. During our development and testing phase of ACSIA, our automated cyberdefense product we activated several testing servers exposed to the public internet. This is deliberate and our exposed servers are constantly subject to multiple random attacks (botnet, script kiddies, random hackers and so on) as an hourly occurrence. These attackers are mostly automated and attempt to gain control of computers and devices which are open to the web.

Our product alerts us with email notifications in real-time for important/relevant security issues and threats. From time to time we pick out unusual cases for further investigation.

One of the email notifications we received is shown here:

We don’t usually investigate bot net attacks as in majority they originate from automated botnets in geographical locations outside US and EU. However as we see from the above notification the source is located in Nuziders – Austria.

This has sparked our curiosity and we decided to dig into this case.

To learn more we performed some very basic security tests and information gathering to have some further details about why an EU resident – subject to GDPR and national data and security regulations would attempt such an obvious attack.

The source turned out to be a regional Austrian ISP and cable TV company which provides customers with internet connection.

One of their IP’s was attempting to brute force our servers and gain access to our systems.

Further detective work

So why in 2018 would an ISP from a regional Austrian ISP be launching brute force attacks on a newly commissioned server located in Dublin?

Well, it turned out that things got a little stranger. Using some security and infrastructure tools we were able to determine that the source of the attack arose not from Austria, not even from within Europe but from a source in China.

Geo-IP (courtesy of Shodan)

The Austrian device was actually being controlled by another device based in the city of Harbin in North East China.

What we did next

We informed the Austrian ISP about this device on their network, and also sent a note to China Telecom. We have not heard back from either to date…..

Threats and trends

A botnet attack can be devastating. In 2016 the Mirai botnet affected large parts of the internet, including Twitter, Netflix, CNN, and other major sites, as well as major Russian banks and the entire public internet of Liberia. The botnet took advantage of unsecured internet of things (IoT) devices installing malware that then attacked servers that route internet traffic. Mirai infected vulnerable devices that used default user names and passwords and is still affecting devices worldwide to this day.

Bot nets enable hackers to steal bank credentials and website cookies to impersonate victims, searching hard disks for specific files, granting threat actors remote access to a computer, and allowing threat actors to exfiltrate stolen information or download additional malware.The botnet-as-a-service model has grown increasingly popular. Threat actors rent subsets of their botnets for malicious activities such as distributed denial of service (DDoS) attacks, click fraud, cryptocurrency mining, and targeted attacks.

The ISP’s above likely were compromised by groups to be instrumental in attacking EU based entities. Having a compromised EU located device is a big plus to a criminal organisation.

IoT Threats

There is a great deal of hype about IoT, Smart Homes and connecting all devices in our daily life to the public internet. Security is rarely a top consideration. Most IoT devices have very basic security controls and are easily compromised. IOT devices are cheap and mass produced with little built in security or updates planned into their functional life.

As consumers continue to buy low-cost, insecure devices, the number of vulnerable end points (like the IP’s above) just keeps going up. Gartner estimates that there will be 8.4 billion connected devices in use by the end of this year, and that will more than double by 2020, to 20.4 billion.

This simple random case how systems can be compromised by 3rd parties masquerading as legitimate actors and this threat is proliferating.

The complex, interconnected networks that cloud providers have developed can create a single point of failure for hundreds of businesses, including government entities, critical infrastructures, and essential healthcare organisations. Cybercriminals are capitalising on this situation to devise hard-to-detect attacks that can disrupt cloud providers and their customers.

Will 2018 be the the year that the industry wakes up, and device manufacturers, regulators, telecom companies, and internet infrastructure providers work together to isolate compromised devices, take them down or patch them, to ensure that automated bot nets can no longer proliferate? We are not holding our breath….

The post Investigating Online Botnets appeared first on Dectar.