MalwareMustDie!

Semper legerent Salve Regina ante venatione malware

© MalwareMustDie,NPO 2017. All rights reserved.
Built by Jekyll, based on Poole and BlackDoc on FreeBSD, posts are in Markdown and Rouge highlighter with templates coded in Liquid.

MMD-0062-2017 - Credential harvesting by SSH Direct TCP Forward attack via IoT botnet

27 Feb 2017

We call this threat as "Strudels Attack"

1. Background

In this post there is no malicious software/malware analyzed, but this is one of the impact of the malware infecting IoT devices caused by weak credentials that are utilized by the bad actors for bigger crime process. The only malicious aspect written in the post is/are individual(s) involved and participated to these attacks, and, well, I personally do not think the tool or method used (in SSH TCP Forwarding itself) is as “malicious”, since. in a way, it is very useful concept for UNIX networking and development.

Please bear with this long and thesis-like technical write-up, and it is indeed necessary, since this post is the first proof of concept of a new vector of crime (an automation of mass credential harvesting via SSH TCP forwarding through cascaded proxy cushions), and this is also an on-going threat, so it will be academically useful (hopefully) for the future research. But, if you need more simple, shorter and lesser technical explanation you can first read my interview in form of Q & A about this matter in Infosec Insitute web site (thank’s to Mr. Paganini & Infosec Institute folks), but yet, if you need only a very short summary you can find it in this reddit threat.

Here we go:

The definition of SSH port forwarding:

" (1) SSH port forwarding is a general proxy-ing mechanism for TCP only. Forwarding can't work with protocols not built on TCP, such as the UDP-based DNS, DHCP, NFS, and NetBIOS,[121] or with non-IP-based protocols, such as AppleTalk or Novell's SPX/IPX. (2) Port forwarding can be specified only when you create an SSH connection. You can't add a forwarding to an existing SSH connection with any SSH implementation we know of, though there's nothing intrinsic to the SSH protocol that would prevent it, and it would sometimes be a useful feature. "

above quoted statements are from “O’Reilly’s SSH: The Secure Shell - The Definitive Guide, 9.2. Port Forwarding”

This threat has been observed by our monitoring since October 24, 2016. I firstly discussed this type of attack during the AVTokyo event in 2016 with our team mate in Tokyo, Japan. We follow its progress afterward then firstly reported to authority in December 2016 (the attack on PlayStation Store account authentication), and at the same time tried to email Pokemon Go since I realized they were hit by this attack too back in November, 2016, but the email seemed wasn’t sent/received well.

From that point, we continue our analysis and on entering the 2017 these type of attack is getting “better” (automated & loaded with more exploits), so we tried to publicly warn via our community, that was also the same time when PlayStation Network (PSN) account authentication was targeted by attackers. Following. in February, 2017, the official report sent to law enforcement channel we have, along with asking permission for disclosure this on-going threat for the public awareness, at the same time frame we also reported another attack that was conducted against a undisclosed Canadian online wholesale store via our CERT channels to be escalated to the Canada law enforcement and related authorities.

Either of the announcement and communication stated above was received satisfactory result of ending the abuse. And the abuse is still on going as per I wrote this report. For supporting the facts, screenshots were taken during the series of events described above. As per below details:

Additional: I received many calls after this post has published, about other good analysis on SSH TCP Forwarding abuses aspect (one of them is mentioned in the Prologue section in this post). I, on behalf of my team, want to make sure that, we, in MalwareMustDie, are having a strict policy to conduct analysis by avoiding outside influence as much as possible to keep our analysis original, thus, this analysis is different, although it is describing a TCP Port Forwarding, it is not about a case of hack to HTTP service or No-Auth SSH forwarding. This report is a disclosure of an organized mass credential automated stealing process utilizing attacks using several TCP hacking patterns (HTTP/HTTPS/POP3/SMTP/IMAP) via the hacked SSH cascade infrastructure.

Message to the law enforcement:

2. Threat definition

As per quoted from above stated O’Reilly’s SSH guidance book. A legitimate user who is having authentication privilege of an existing SSH connection can forward TCP protocol in proxy-ing mechanism. It’s an almost common practice nowadays in the nutshell, specially to the services that is meant to be view from a local networking area.

This threat’s definition is The abuse of SSH TCP forward legitimate usage, by performing automatic or manual attack to weak SSH accounts of remote devices (either servers and IoT), with brute-forcing account’s credential or passwords, to perform malicious set of TCP attacks via TCP Direct Forward technique on SSH Forwarding functionality utilizing this “force-accessed” SSH connection to targeted remote services.

By that definition, this threat is creating a double verdicts, one for the hacking of SSH services, and, second, attempt to attack targeted service(s). Thus, if this can be considered as the third verdict, the actor makes hacked SSH services looks “hostile” just as if they were in performing the attacks to the targets.

3. Threat detail

Below is the diagram to explain the overall process of this threat.

(please click the image to enlarge the size)

The attacker is grabbing credentials from the hack-able targets from their infrastructure. They manually perform the attack or daemonized the SSH connectivity to be TCP forwarded through some layers of hack-able SSH accounts to perform the attack. The infrastructure of compromised SSH services and IoT devices are used as front-end cushion for the attack. They aimed for credential launched through several TCP attacks (HTTP/HTTPS or SMTP).

The grabbed credentials are used by attackers to login to several sites for further hack on registered accounts to gain more data. Other access (non hacking in verdict) are also spotted to actually supporting this attack activity (attack research/test via browsers, WHOIS checking, GeoIP checking, successful SSH forwarding checks, etc.), and all are pushed through the same infrastructure.

The attack process described in the above diagram is elaborated in the below points:

3.1. Gaining SSH privilege method

Attacker(s) is gaining privilege by brute forcing access to SSH users by login with the known weak credentials, the method used are either the attacker does manually enter the values to break the credential using the keyboard, or brute forcing it by the scripts, the below illustration is showing few of many events we monitored:

3.2. SSH TCP Direct Forward method

There are some ways being used by attacker(s) to perform SSH TCP direct forward method. In general, we can devide its common malicious usage as follows:

3.3. Event occurrence in SSH TCP Direct Forward attack, in steps

3.4. The naming for the threat.

After realizing their crime scheme was exposed, the “allegedly” attacker(s) were posting message on March 1, 2017 as per below:

In the same time we were thinking about a simple shorter name to call this threat, so the timing is just perfect from that moment we call this automation mass harvesting credential scheme via SSH forwarding and IoT botnets as “Strudels Attack”.

4. Attack details

We were saying “attacks” so many times, it won’t be fair if we don’t elaborate, hence, you deserve to know on what was hitting you, and maybe what made your IP blocked from several services caused by these attacks that you’re not knowing utilized your routers, gateways, DVR, WebCam or etc IoT.

4.1. The type of attack by its forms

The performed TCP attacks forms which is varied, mostly are aiming HTTP (protocol) with and without SSL, and so far what we detected are as per following types:

4.2. The type of SSH TCP Direct Forward attack by its targets

In this section we are going to elaborate the type of this threat’s attacks by its target. Which target are mostly spotted and performed. What is the aim for the attacks? What requests are formed and the technical details, and so on.

I am not into practice of any kind of “Red Team” act, so does our team mates (we’re Blue teamer), so I don’t know how attacker will act in their attacker shoes in this particular incident, in this step pentesters know more I guess.

What I do in analyzing this threat is based on reverse engineering of facts on what we see and collect. And I have to warn that reversing is not as same as reading source code .In this case we are collecting traffic here, not samples, and we are doing the best to understand its scheme by this minimum resource, so bear with the inaccuracy that might occur, and I will upgrade this post along with the new progress in analysis come up.

Let’s go into each sub-sections to elaborate the details:

4.2.1. Remote Authentication Web Server as targets

HTTP attacks formed by SSH forwarding are all aiming server that is having authentication scheme. The attacker is meant to break the authentication and try to find their way in by sending several “known” malformed HTTP headers (with crafted “refeRer” and some customization to fabricate several browser, either PC or Mac or Mobile device’s browser to send the package. The most favorite techniques are the malform traffic sent to either HTTP or HTTPS (mod-ssl or similar) that was expected to crash the service, encryption authentication. the session (cookies etc) and the database, to then opening chance for the further hack attempt.

What the attackers are aiming is credential. Like login user, login’s password, email address and more of data linked to those credentials like maybe credit cards, and so on. They will then use the taken credentials to form more malicious act that will be explained in the next section. In this section I will show some samples on how the attackers are making attempts to force their way in.

The aimed targets are services that’s having web login or web auth form, either PC or mobile. The fabricated requests shown that the attackers was recording traffic to the auth service beforehand, and studying for flaw that can be reproduce into a scripting method. Aimed portals for those services are varied too, from the category of banks, online payment system, online shopping, entertainment or game networks, social or business network services, and many of the adult sites with some of them are using live camera. What attackers get from these sites are crucial data, although there are some throwaway accounts spotted too, that can be used to further hacking attempt of specific users, or worse, the identity personification. To be noted: I will refrain to elaborate more than this explanation since some of the attacks seems making impact or effect, I also will not post attacks that is not mitigated by the service vendors, furthermore, this post is meant for the awareness for people whom their SSH service were hacked and used, for the services to be aware more of what are these attacks actually, and for users of the aimed portal to be very careful to use strong credential and privacy.

OK, here is some of the screenshots of most seen abuses, there are much more than these:

4.2.2. Emails and a lot of more emails

Well, it seems that some of the emails were harvested, there are many from known email online portal like GMail, Yahoo, AOL, Microsoft (Live Mail & Hotmail), Mail.ru, Yandex, etc..

What the attackers do with these emails is, they confirm it again to the web email where these email belong, to check whether the account is accessible or not. And how do I know this? Guess what, yes, they use AGAIN the SSH HTTP forwarding for that purpose, I will snip you some pictures below, for GMail, Yahoo, and Hotmail (there are others, but the systems “maybe” are still affected so I don’t post those):

The credentials they stole from one site is being used to brute force to other services, we have a recycle-like process for ultimate credential harvesting directed by hackers. The picture below is clearly describing how one leaked credentials is used for checking an account of another site.

These email addresses they stole, how many are they so far? I am not sure about the quantity that they succeeded to achieved by the malformed HTTP sent to auth services. And we can’t state any of these unless having their environment in our hands legally, but the fact right now is, according the data that I saw in the used traffic, it’s about less that 600 emails (unique) in my entry counted from early December 2016 when I first counted them. I am sure there are more of them, considering that the first hack was done in October 2016.

Let me show you a responsible disclosure for the fact that I am saying in here as per below video (credentials & password are all blurred and we hope this is more than enough to show as PoC of this threat’s cyber crime attempt, and only law enforcement & affected services can query these data directly)

4.3. Manual attack type

As per mentioned before, the manual attacks are spotted too, it is showing a different characteristic in its way on making connection and performing attack sessions. Some typical characteristic in its logged activities have suggested a human’s direct interactive during a session of attacks, supporting facts of the establishment for connection used to conduct TCP forwarding that was manually set.

The attacker seems hard to be able to spawn one SSH connection session to launch multiple TCP Forward session, which is a bit tricky to perform it manually.

They tend to brute SSH credential with the certain/similar phrases with more limited range. This is enough to realize there are more than one actor who jumped to SSH Forwarding attack. The interesting part is the characteristic of manual attacker using TCP Forwarding is a bit unpredictable, there are some tests were performed. And mostly the attacker(s) is switching into browsers (either PC or Android mobile), or others to perform some action.

For this type of attack, we can not share the screenshot due to OPSEC.

5. Supported analysis

5.1. Analysis of web service exploitation

5.1.1. Exploitation information in sent attack

The HTTP malformed requests sent are not 0day, generally it contains a formed exploit strings to attack protocol sanitation handling of web service application with several types, like:

Some sent strings during the attack are also matched with several information shared in other’s web servers vulnerability notes, from the protocol (input sanitation or filtration handling) or SSL (input sanitation or handling) part. There is a possibility for the script interface attack formed, but for that area is not being disclosed in here at this moment.

Several references that can bring you better explanation for the exploitation forms of these HTTP malformed requests can be read further read in the below good articles linked below:

Quoted from OWASP Attack Category:

The Format String Exploit occurs when the submitted data of an input string is evaluated as a command by the application. In this way, the attacker could execute code, read the stack, or cause a segmentation fault in the running application, causing new behaviors that could compromise the security or the stability of the system.

5.1.2. Corelation of known web service vulnerabilities CVE to the malformed HTTP attack

We may point to some older vulnerabilities that are “commonly aimed” in the attack squence from the Format String attack, like: CVE-2015-0253, CVE-2012-0053, CVE-2009-3555, CVE-2005-3357, CVE-2005-2700, CVE-2005-1268, CVE-2004-0751 for Apache project, and other type of vulnerability from other web service products. Practically, the hacker was frabricating its malform request depending on the targeted server’s characteristic. Below is the links that can elaborate more information accordingly:

5.1.2.1. Examples in Apache project’s httpd:

5.1.2.2. Examples in Apache project’s mod_ssl:

5.1.2.3. Examples in Apache project’s mod_status

Other web services with other interfaces has similar exploitation possibility.

5.1.3. Input sanitation to prevent exploitation in real attack

As per references above we can understand that the software with remotely accessible can be affected to Format String Exploit. A way to prevent this is by the input sanitation or filtration handling method.

For a very simple example, I run the format strings attack that the attacker sent in the debugging environment on several web application that can be affected to the real attacks sent to the service.

A good sanitated software will reject the code, which the result I can be previewed in my radare2 shell interface during ptrace on my FreeBSD as per below:

  :
[0x28065e80]>   RET   stat 0
[0x28065e80]>   CALL  read(0xa,0x8066f80,0x3ff)
[0x28065e80]>   GIO   fd 10 read 276 bytes
       "16030100a8010000a40301Xa9`e599dfa6=J15|d012d16c496la9c5rZf9b8Vf6de79a1a9; db0c%af~a5O9b8f8ee686\\\\aca9 b91deedqccZ0gJa9dbd1?cc7f001800/005000500\\\nc013c014c0\\tc0\\n00200800130004010000Cff01000100000000*00(0000%auth.api.sonyentertainmentnetwork.com00\
        0006000400170018000b00020100"
[0x28065e80]>   RET   read 276/0x114
[0x28065e80]>   CALL  read(0xa,0x8066f80,0x3ff)
[0x28065e80]>   GIO   fd 10 read 0 bytes
       ""
[0x28065e80]>   RET   read 0
[0x28065e80]>   CALL  madvise(0x2840f000,0x1000,MADV_FREE)
[0x28065e80]>   RET   madvise 0
[0x28065e80]>   CALL  madvise(0x2840f000,0x1000,MADV_FREE)
[0x28065e80]>   RET   madvise 0
[0x28065e80]>   CALL  write(0x2,0x2841f100,0x3c)
[0x28065e80]>   GIO   fd 2 wrote 60 bytes
       "EOF in backquote substitution
       "
[0x28065e80]>   RET   write 60/0x3c
[0x28065e80]>   CALL  madvise(0x2840f000,0x1000,MADV_FREE)
[0x28065e80]>   RET   madvise 0
[0x28065e80]>   CALL  madvise(0x2840f000,0x1000,MADV_FREE)
[0x28065e80]>   RET   madvise 0
[0x28065e80]>   CALL  write(0x2,0x2841f100,0x3c)
[0x28065e80]>   GIO   fd 2 wrote 60 bytes
       "Error in command substitution
       "
[0x28065e80]>   RET   write 60/0x3c
[0x28065e80]>   CALL  exit(0x2)

This is a self explanatory, there are two places that hits error during input sanitation process, which will block the command to the executable level to avoid it performing further exploitation.

5.2. PoC & regeneration of automation usage in SSH forwarding to send Format Strings Exploitation

A simple python script was found in the internet, was explaining in the big deal the method that can be used by attacker(s) to perform multiple connection’s forwarding sessions under one SSH connection that runs as a daemon (service or process that always up and alive) to forward the request defined via client’s command line, or via other script interface, is a perfect explanation scenario explaining the rapidity time span logged in these attacks.

The logic of this script is short and flexible enough without using much imports, and only 70 lines in length, the snippet of the code can be viewed in the below screenshot:

Above is the PoC of the SSH TCP direct forwarding used for performing attacks mentioned in the automated type. The source code of this attack itself could be written in diferent language, and that is not being disclosed for the on-going investigation on a known suspects.

6. Statistic

I will split the statistic into two sections:

We will go from the victimization of the threat and fo to the allegedly source of the therat.

6.1. Victims

Previously we mentioned about the target victims in the classification of attacks. Not only the web sites with the credential that are abused by this attack, but there are others.

6.1.2. GeoIP Map for victim’s network

Before we jump to that data, let’s summarize the victimization data in general as per below geographical map.

Just in case you can not see the map below is the top 20 countries victim list:

Country Count
United States 2180
Netherlands 400
Germany 166
United Kingdom 133
Ireland 109
France 99
Russian Fed 98
Canada 89
China 86
Europe 74
Japan 74
Italy 70
Australia 66
Vietnam 55
Brazil 43
S. Korea 40
Poland 39
Spain 34
Sweden 32
Switzerland 32

6.1.3. Who are the victims

6.1.4. The targeted IP lists

Our community has voted to share the list of the targeted IP of the victims. We upload the data in the repository. There are two lists, one is the list of the targeted IP in “overall”, meanings, these IP are aimed and suffered to some access via TCP activities from cushion SSH but not all of them are having hack verdict. For example: checking WHOIS data, or checking GeoIP is not a hack, as far as we concern. Scanning for MX records or SMTP servers is a grey matter but many people are doing similar activiry via Nmap, Shodan or MASSCAN too.

The other one is the list of IP that is having positive verdict of hacking, either HTTP, HTTPS or SMTP. “Hacking” by the meaning of violating the authentication scmeme of a service by accessing information that is not supposed to be seen.

There is another list contains the victims IP that were utilized and participating as cushion for SSH TCP forwarding attack, along with the infrastructure use dby the attackers. There are IoT IP addresses and hacked services in the list, specially the Vietnam origin IP addresses and dial up IP addresses. I am putting the access for this list too.

Below is the access to those lists:

6.2. The attacker

There are the sources of attacks:

6.2.1. Most abused data center as origin of the attack:

a. SERVERIUS NL (5.45.*) = 43++
b. HETZNER DE = 27
c. VOLUMEDRIVE US = 12
d. OVH FR = 10
e. IOFLOOD US = 4
f. WORLDSTREAM NL = 3
g. DATASHACK US = 3
h. ONEANDONE DE = 2
i. AS-CHOOPA US = 2
j. SUPERSERVERSDATACENTER RU = 2

6.2.1. Most abused dialup/ pool IP (IoT/routers hacked SSH)

a. Vietnam 213 (now 222)
b. Russia+Ukraine 10
d. China 6 (now 9)
e. Canada 6
f. S. Korea 3 (now 11)
g. Spain 3 (now 4)

The Vietnam IP addresses are ruling the most relayed TCP forwarding attacks, all of the relayed attacks are automated ones. After checking some IP addresses origin we can tell that the list are mostly hacked SSH service and most of them are referring to compromised and/or infected IoT devices. Pmenty of these IP addresses are actually a part of the known IoT Linux DDoS botnet that we disclosed in the older analysis in this blog. For the hint: Mirai, Luabot and Qbot/GyFt/Torlus/Bashdoor ELF botnet. But we are not talking about this botnets now.

6.2.2. Geo IP Map statistic of the attacker source IP address in overall

We collected all of the source IP that we can confirmed from the several sensors and traps we spread, and we collect the confirm IP that was ctually proven conducted the tcp direct forward requests and following by the tcp direct connections to the up and alive targets and also receiving response from its targets. We map the IP in the Geo location using the MaxMind dataset to confirm the data below:

The overall list of the recorded attacker’s IP address can be seen from this link, noted: please mind the date in the BGP part is when the BGP info was extracted from a detected connection.

The potential infrastructure data centers utilized by the attacker (behind the hacked SSH or where the attack script is/was served) can be seen in this list. These nodes can be rented or hacked, which is worth for further investigation. The IP addresses listed is good for the blocking purpose to prevent further damage.

6.2.3.The volume of the attacks recorded since October 24, 2016

If we parse the traffic used from attacker to attack, to a honeypot, we can count the amount of attacks performed. These are the records of tons of attacks performed since the day one we spotted this malicious activity:

The targeted uniq IP itself is about 8,000+ of them:

6.2.4. “Who” are these attackers and “Why”

A possible keyword to describe the attackers is: Script kiddies.

But if we learn of what had happened with Mirai botnet, and considering the IoT aimed. Seeing the harvest of credential are on going too as per you read this post, do not underestimate of what damage that can occur by these hack efforts. Next, the motivation is credentials collective to be used for further malicious cyber crime related activity.

There are many things that they can do by utilizing the email address and the passwords leaked from one site, since people tend to use same passwords anywhere.

The scanning for email server services may have different motivation.

7. How to spot, block and mitigate

UNIX sysadmin networking 101 commands are the best way for spotting the attacks. For the compromised SSH service, all of attack efforts are view-able via netstat and you can seek for the longest ESTABLISHED session in the from the network that is unrelated to your activities as suspicious. Pick one process that linked to a connection and you can elaborate the data based on the connection aimed (as root of course), a set commands like ps, ptrace+ *debuggers and list of files is useful to be used for detection.

For the targeted HTTP or SMTP service, the log is your friend. Please see the data we pasted in the attached picture in this post and see some updates we posted in the github repository too. If you see the similar pattern of attacks are affecting your service, you’d better start to investigate same pattern that may come to your neighbor IP addresses too, since the attacker is not aiming by IP but mostly by services and those services are the ones that stored credentials.

Blocking for the threat is simple. For the SSH victims the Linux sysadmin iptables is good, for BSD users you can use ipfw, pf, or ipf, or as an option you can use the TCP wrapper compiled web application or services to be blocked by hosts.allow which will work just fine. For the SMTP or HTTP service, you may need to filter any malform requests coming into your service by firewalling your service to drop the attacks. Or, a simple and good configured fail-to-ban scheme can be used too (please be careful in configurating this scheme). You can help further by studying the pattern of attacks and contributing the information into a snort IDS signature to be pushed in very good services providing them, like Suricata, Emerging Threat or Snort.org.

The best way to mitigate is to cleanup the compromised IoT as soon as possible from the internet. I am positively thinking we are having a road map to conclude the IoT issue in the near future too, yes? (blink).

Several sample to block with iptables and ipfw:

// iptables (linux)
sudo iptables -A INPUT -s 5.45.72.0/22 -j DROP
sudo iptables -A INPUT -s 5.45.84.0/22 -j DROP
sudo iptables -A INPUT -s 5.45.76.0/22 -j DROP
sudo iptables -A INPUT -s 5.45.64.0/21 -j DROP

// ipfw (freebsd)
ipfw add deny from 5.45.72.0/22 to any 
ipfw add deny from 5.45.84.0/22 to any 
ipfw add deny from 5.45.76.0/22 to any 
ipfw add deny from 5.45.64.0/21 to any

8. Epilogue

Four straight months was taken to monitor this threat to understand what exactly happened. We wait that long to confirm and collect plenty of facts and modus operandi performed by the bad actors. We have almost 5 TerraBytes data for the traffic performed for this particular case only. By this post, we hope this threat information can raise more awareness on the subject. We don’t think the attack will be stopped that easy, since nasty hacks will always happen.

For the related script kiddies who we know reading this blog: Please stop this, do those hacks with your own IP and present it as Penetration Tester Papers or something positive and productive that can improve our Internet’s Security,instead of cowardly pinning down routers for stealing credentials and credit cards. There are real people who got blocked by the ISP or services without knowing what was happened, and think about what if your mother’s credit card is stolen by someone. There is no easy way to get rich by hacking. We in MMD are not rich people either (we’re mostly poor actually), we have our hard times in work and life too, but we won’t use our skill for any badness. Stuff like this will bounce its bad “karma” back at you. We’ll make sure your vandalism will get a “proper” handling with the tons of data we “harvest” back from you. (/for the skids)

I am sorry for there are some demonstration that I can not perform openly in this blog, like stack crashing PoC in several web services viewed by radare2 and debugger for processing the sent malformed requestst. Also there are some of the attack details that can not be mentioned here too, for the on-going OPSEC. We can not disclose much information on how to monitor, howto pin some transferred data during the attack directly, and so on, to avoid mitigation that will surely be performed from the “dark force”. But please read between the lines for I try to do best to reveal all things we witness on this case. I planned to visit several events, maybe when we meet I can show you several interesting demonstration.

We are open to communicate with fellow good guys to elaborate more of this threat, and to share to law enforcement & authority with all of the data we collected. Instead of sharing “samples” or hashes of malware, in this post we are sharing the access to our repository stored with the share-able data supporting to evidence collected for this investigation. We have a big collected data since October, 2016, so I can not upload them all. But you can query some IP address in github and we can reply which IP are affected or not.

I just talked with my (kudos) long time friend during FD time, Mr. Larry W Cashdollar and he was informing that Akamai was writing SSH Forward hacking via IoT in fall 2016, and that did not get much attention that time. I didn’t know much details of the post, and I explained that with our disclosure we focus on cyber crime process that is utilizing the hacks with more further aspects and backgrounds, including verdict and evidence, and pointing to the sources of the badness, so the authority will hopefully move and people to block, specially after the tons of credentials spotted and saved as cyber crime evidence. Their post is good one. So please review their report too.

I would like also to thank Mr. Michel Oosterhof for the request to perform a deep analysis for this threat, we kept our promise to post as analysis in our blog. Thank’s for always maintaining the nice pot.

9. Reference

Supporting to this analysis there are more reference contains follow up from this initial report. The bullet listing of the reference is as per following:

Thank you all, and stay safe.

#MalwareMustDie!

Recent Posts