We have been very busy with the continuous development of ACSIA – one of the reasons why we have been very quiet on our blog for last months.
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.iosite (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!!!