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

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.1.1. Manually brute-force:

• 3.1.2. Automated (scripted) brute-force:

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.2.1. Using (or fabricate a request from) a browser to access a specified site like these requests:

• 3.2.2. Using malicious script (for automation), written for this purpose to send multiple TCP direct forward contains data of malicious HTTP in one session of SSH, like this: The detail will be elaborated in the PoC section.

• 3.2.3 Using the specific TCP request queried to port SMTP (TCP/25) to map the network’s email servers.

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

• Checking the success attempt of TCP Direct Forward
  • An attacker upon a success attempt to compromised an SSH account will obviously test their connection, this is likely to use their own sites, or in some earlier stages, iplogger sites or any sites that can give a good HTTP log feedback for the forwarded HTTP request. Usually sent by GET / HTTP/1/1.
• Get the Proxy device’s IP addresses
  • Secondly, the atacker is naturally seek the location of the infected device, this is necessary since the attacker are mostly brute-forcing wide range of SSH service and they need to know which country that gives a promising infection sign. So far I recorded the callback to the services I listed below:
    • checkip.dyndns.com
    • api.ipify.org
    • ipinfo.io
    • ip2location.com
    • ipinfoplz.com (NOTE: mostly used in malicious compromising scheme with or w/o malware)

  The above services are mostly good services and they are being abused for the attack purpose.

• Browsing or other TCP harmless activity via hacked SSH as proxy without SSH owner’s consent.
  • Several attempts spotted as preliminary check the attacker are browsing with the bogus browser, just to make sure that the attacker can really browse through the hacked service, this type of attacker is the cautious one and performing some tests, assuming the packet capture process was being conducted. I usually implement a special menu for this type of attacker(s).
• Keeping several SSH connection sessions to be in established state
  • Attacker will keep the some SSH connections alive to be connected to attacker environment’s upstream, and within it, each of the established sub-session will be requested connections for TCP Forwarding connection request (a child process connection session on a established one) to perform a specific “task” (read: attack). Obviously this will bring bad effect to the hacked SSH service to be flooded by attackers, like this scenario:

  One SSH connection session with multiple connection channels used for TCP Forward attack snippet is as per shown in the below real log when the hackers was trying to make a hit on lowlaw.ca web service :

• Utilizing hacked SSH as attacker’s front-end medium or cushion to hack targets.
  • This part will be explained in the following section (4. Attack details).

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:

• Sending malform HTTP requests to a targeted web server to exploit the service:

• Sending invalid HTTP method requests for mod-ssl vulnerabilities with the same purpose as above

• Sending HTTP requests to force (brute) authencation in a legitimate sites for user(s) and password(s)

• Sending HTTP requests to a comproomised sites to allegedly confirm suspicious activities: These wordpress sites are hacked sites that has been accessed under the same time when the Wordpress patched their version and hack events were happening a lot “recently”. It seems the malicious filename were requested via the botnet to the hacked wordpress sites for confirming some “ungood” activities via this botnet..

• Utilizing a known URI’s API used by a known HTTP affiliation site:

• Sending SMTP requests to several email servers (hereforth is called as MTA), with having below purpose:

  • Mass-sacnning the availability MTA service on a subnet via SSH Forward’s SMTP scripted textual requests to known SMTP port and pushing the QUIT command (this can be seen in the screenshot in the Victims section) upon the connection establishment.
  • Manually or automatically hack to a targeted MTA to brute account by sending malicious unauthenciticated USER and PASS commands, we don’t elaborate this with further evidence, since it is well-known and self-explanatory that PLAIN TEXT in SMTP or POP3 protocol is supporting the automation for the usage of the email client software (hereforth is called as MUA) in general, and will not give further idea to the blackhats who we know is reading this blog too.

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:

• SunTrust Bank:

• RoyalBank:

• PayPal:

• AT&T:

• LinkedIn:

• Playstation Store:

• eBay:

• Loblaw:

• Mojang.com :

• Ubisoft:

• Playstation Network:

• Sony Entertainment Network:

• Facebook:

• Nianticlabs / PokemonGo:

• Gmail (and also Yahoo too) by aiming IMAP service, ping me for more on email servers, have tons of 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:

• Forming Format String Vulnerabilities (a well known attack started from year 2000), so that the attacker can pop the stack and viewing memory at any location or in the worse scenario will crash the web service app process. In web services where the httpd are mostly run on specific users, the credential will be saved in area to be accessed by the same privilege as the web server’s, is making the attacker have possibility to see credential in a flawed software.
• Forming a overflow state in stack of child process on web service app to crash (DoS) it, this part is mostly related to the older vulnerabilities, for example in exploitation of the Apache httpd protocol.c, The follow up for this attack is to gain more privilege to access information or databases that is not supposed to be accessed, or -
• Forming abuse with exploit to be sent to trigger vulnerability in mod_ssl for the SSL handling flaws, which hoping the the child process of web service to crash (DoS) and can be exploited to further leaking information that is not supposed to be seen, to be used for the further hack.

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:

• Exploiting Format String Vulnerabilities
• Format String Exploitation
• Remotely and automatically exploit a format bug
• GIAC Paper: Apache http daemon exploit

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:

• CVE-2015-0253
• CVE-2012-0053

5.1.2.2. Examples in Apache project’s mod_ssl:

• CVE-2009-3555
• CVE-2005-3357
• CVE-2005-2700
• CVE-2005-1268
• CVE-2004-0751

5.1.2.3. Examples in Apache project’s mod_status

• CVE-2014-0226

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:

• Victims , and
• Attackers

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:

6.1.3. Who are the victims

• Sites that are having credentials stored in their servers and accessible via web. (this part was explained above)
• Sites that are having open service that can be utilized by attacker to their purpose, such as confirming the Geo location, or using a WHOIS database (i.e. I noticed there are many request sent to JPRS via script).
• Sites that is having an affiliation URL API scheme that can be utilized by attackers.
• Email servers (MTA) For the email servers we spotted the mass effort to map the MX servers in the world wide web via TCP Forwarding to SMTP protocol, that can be seen in the below picture. Many main or big servers are included in the list, and also services belong to specific business and organization. Screenshot of the total SMTP scanning and the “method” used: For the data of the SMTP abuse, you can grep whether your email server is slurped by this attack or not by accessing this list There are more email protocols which are under attacks too, i.e. POP3 and IMAP.

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, gate.io 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:

• Overall list
• Positive targeted list
• List contains attackers origin and hacked IoT/ dialup SSH service (which are victims too)

6.2. The attacker

There are the sources of attacks:

• Attacks that come directly from services used or utilized by attackers. This type of attacks are mostly coming from IDC and not dial up public pool IP network.
• Relayed attack: This type of attacks are coming from other IoT devices and mostly the IoT devices SSH service that was hacked or infected device by known ELF/Linux malware we posted in previous posts in this same blog. You can prevent the further attack by blocking IP listed in the attacker section defined as Red Network.
• Relayed and relayed again attack: There are some IP addresses that linked to the atack utilizing IoT SSH weak credential that was originated from the hacked servers and the servers then connecting to another service. These connectivity are formed via SSH and mostly are manually performed. We put some of these IP in the Red Network, like we have one Google address listed in there, which is actually being used (this can not be spoofed) for attacking other IoT after confirming its GeoLocation. That one address was located in the Google cloud service.
• Sentinel panels, upon a success exploiting an SSH connection, one of first series of request sent by attacker is to confirm the exploitation. Most of the time the attacker can confirm the exploited device’s global IP, network and location via GeoIP services they use, but we also saw several bogus HTTP callback to poke the attacker web service. We call these as “sentinels”.

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

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

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:

• Infosec alerts for the issue in several countries in various languages were raised, i.e. in Japanese, Italian and German, which contains specific damage details in each affected regions. For Italy and Germany we received confirmation from CERT-BUND, while in Japan this matter was presented directly to the MPD Force Cyber Crime unit’s channel. Noted: The United States law enforcement channel were notified about this malicious activity by preliminary report we sent since early February, 2017, following by the disclosure report of allgedly actor behind this crime scene.

• Thank you for Security Affair team to be the first media publication for this threat, to Mr. Paganini and Odisseus.

Thank you all, and stay safe.

#MalwareMustDie!

• This post is dedicated to our friends for so long waiting for next blog, and radare.org is proven useful to analyze vulnerability too (you must note this), to loyal solid of small people in malwaremustdie.org and the open source community in UNIX platform. Big thank’s to the best friends in our AVTokyo community that full of cool whitehat hackers who promptly just jumped in (literally speaking) to support this investigation.

• Reversed, written and analyzed by @unixfreaxjp on behalf of MalwareMustDie team, on February 27 2017 to February 28, 2017.

• Tags used for the post: SSH TCP-Forward Format String Exploit Malform HTTP Request Credential stealing Hacking IoT Weak passwords Mod SSL botnet hacktool hacking