Welcome to HBH! If you have tried to register and didn't get a verification email, please using the following link to resend the verification email.

NetCapture and HTTPCanary apks for android are infected

Huitzilopochtli

....

10 9

5 years ago

NetCapture and HTTPCanary two apps for packet sniffing I downloaded yesterday from the Play store are infected with malware

NetCapture makes a connection to a domain in China and uploads an rc4 encrypted gzip via a POST request, this happens at first boot and every time you connect to Wi-Fi . http://pingma.qq.com:80/mstat/report/?index=1551456863

When you block it another Chinese domain shows up: http://android.bugly.qq.com:80/rqd/async/aid=

HttpCanary is similar as it connects to the same android.bugly.qq domain when it uploads it's gzip files.

Blocking it brings up another Chinese based site: http://mclean.cloud.360safe.com http://mvconf.cloud.360safe.com Â It's only when this domain is blocked that a change in behaviour kicks in, as it switches to a GET request for the next domain and tries to download some .dat file.

http://msafedl.ssl.qihucdn.com:80/clear_sdk_multilang/20190228/o_c_adp.dat

And again after the first one failed:

http://msafedl.ssl.qihucdn.com:80/clear_sdk_multilang/20190228/o_c_adp.dat.en_WW

Not sure what's on that site as safebrowsing kicks in and blocks it.

So, if you have one of these two apps installed, you should probably think about removing them.

Rocket_Face

Member

0 0

5 years ago

That's why I only ever download apps from the Play store, because I'm no fool.

Huitzilopochtli

....

10 9

5 years ago

They were downloaded from the Play store you fucking clown.

Futility

80 122

5 years ago

Huitzilopochtli wrote: NetCapture and HTTPCanary two apps for packet sniffing I downloaded yesterday from the Play store are infected with malware

When you block it another Chinese domain shows up: http://android.bugly.qq.com:80/rqd/async/aid=

HttpCanary is similar as it connects to the same android.bugly.qq domain when it uploads it's gzip files.

http://msafedl.ssl.qihucdn.com:80/clear_sdk_multilang/20190228/o_c_adp.dat

And again after the first one failed:

http://msafedl.ssl.qihucdn.com:80/clear_sdk_multilang/20190228/o_c_adp.dat.en_WW

Not sure what's on that site as safebrowsing kicks in and blocks it.

So, if you have one of these two apps installed, you should probably think about removing them.

This is super interesting! I've got a thousand questions, feel free to answer any/none at your leisure. If you could post a hash of the apks (or the apks themselves!), I'd love to do a bit of my own analysis to fill in some blanks.

Any idea what's included in the gzip that gets sent? What the RC4 password is/if they use it for anything else? Any example .dats or a guess as to what they contain? DNS lookups on the domains, or affiliation with any of the big threat actors? If the comms are encrypted between you and the server, are the certificates known-bad? What other domains are in the apk (it doesn't look like this is fast-flux or other type of domain generation- I'm guessing there's a listing somewhere). Did you do any DEX decomplication for static analysis, or was everything dynamic?

Again, interesting stuff, just curious as to some of the finer details and looks like it was fun to poke.

Futility

Huitzilopochtli

....

10 9

5 years ago

You can still download them from both from the play store man. I didn't try anything with the dex files, and I didn't try to open the gzip files either. But I have the full thing with about 100+ requests it sent to diff IPs I can zip for you if you want it.

A typical dump from HTTPCanary to bugly.qq was like this:

POST /rqd/async?aid=0ad83de9-a487-46fd-953d-fd566eada84f HTTP/1.1 wup_version: 3.0 raKey: l8Jvcr%2BKpsYUFZ3KlMvt0CjBbfoGIWD1LZnYLQUsiPvPqF6w Y2iLkb%2FaJGJL5LabENShd8eB960S%0Alduspc%2BUV Ru2z5ePCUF0IQUQECddf7POKpcUPxLaPjcx08l8yeU3MCmPxOZAsTm4z qoywDnHWjv2%0AxtZKL1Jn8HLzPA8qS%2Fo%3D%0A platformId: 1 cmd: 840 sdkVer: 2.6.6 appVer: 2.3.1 prodId: 4490ee2e04 bundleId: com.guoshi.httpcanary strategylastUpdateTime: 1543642045000 A37: WIFI A38: WIFI Content-Type: application/x-www-form-urlencoded User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; SM-G925F Build/NRD90M) Host: android.bugly.qq.com Connection: Keep-Alive Accept-Encoding: gzip Content-Length: 1032

There is also an occasional request that has no gzip compression:

HTTP/1.1 200 OK Server: nginx Date: Fri, 22 Feb 2019 23:37:46 GMT Content-Length: 194 Connection: keep-alive Bugly-Version: bugly/1.0 status: 0 nstat: 0

Ñ˜Ñ’Ð Â°ÐˆÐ¡lÐ§H ;Â®vWÂ¦M Ðº\ÐŠ=5Ð›>{Ð¶Ð›ÐÐš2Ñ™Ð¸Ñˆâ€ºÐ›â„¢UÐ’uÂ§EÑ†hÐ°Ð•;ÐƒMÐƒ\&ÐŽÂ¦Â·HÑ‰Ñž1â€¦Ð¾Eâ€™Q#Ð·Ð³#bÑ€Â¬R. xâ€¦'HÐ¯\ÒnDÑŸ\4â€R<â€°PxÐ½Â©lgÂ± hâ€zËœhÐšÐÐŒÑ‡UEâ€ Nâ€™ÑŒÐ¼rÐŸÐ‚ÑŒÑ“ Ð‚â€¹Ð¥]ÐŽ9ÑˆÑŒÐ°Ð²t2>BÒ’*Ñ–Ð¶Ð‚ÑƒÐ½NX|â€ºÐ…Ñ’ÐÂ¬av6\Ð§â€™â„¢'Ð®(oÂµiÐ˜Pw~Ñ˜Ð½:Ð‚gÑ•Ð

The Content-Length of the requests is always different and can range anywhere between 290 and 7490.

Only one request never changes:

HTTP/1.1 200 OK Content-Encoding: rc4 Content-Length: 9 Connection: keep-alive

Ã†8Ã§fâ€“G Resending the full POST request without the fields above returns an error.Â Â {"ret":-1, "msg":"invalid appkey"}

And the ones sent from NetworkCapture were almost identical, and go to the same domain:

POST /rqd/async HTTP/1.1 wup_version: 3.0 platformId: 1 cmd: 830 sdkVer: 2.1.9 secureSessionId: 5bd7cf676827461cb553889a9d61d669_0222_SZ appVer: 2.9.0.5 prodId: 900015015 bundleId: com.minhui.networkcapture strategylastUpdateTime: 1484023430000 A37: WIFI A38: WIFI Content-Type: application/x-www-form-urlencoded User-Agent: Dalvik/2.1.0 (Linux; U; Android 7.0; SM-G925F Build/NRD90M) Host: aexception.bugly.qq.com:8012 Connection: Keep-Alive Accept-Encoding: gzip Content-Length: 4483

And being sent to pingma.qq

POST /mstat/report/?index=1551456863 HTTP/1.1 Accept-Encoding: gzip Connection: Keep-Alive Content-Encoding: rc4 Content-Length: 296 Host: pingma.qq.com:80

ï¿½aTï¿½kï¿½UCï¿½uï¿½ï¿½ï¿½Kï¿½sï¿½Hï¿½mï¿½yï¿½?Pï¿½\ï¿½ï¿½ï¿½ z4~ï¿½ï¿½Ü‚ï¿½<?ï¿½HqOM;ï¿½ï¿½VILn@|Kï¿½Pï¿½cï¿½ï¿½?ï¿½ï¿½ï¿½Tï¿½ï¿½P1ï¿½ï¿½ï¿½wï¿½5ï¿½8NG| ï¿½hHQ;aI"ï¿½ï¿½ï¿½ï¿½ï¿½r1)ï¿½]ï¿½;6ï¿½9Uï¿½ï¿½Gï¿½Mï¿½È¡ï¿½ï¿½t>)R\=-<Jgï¿½>Cï¿½ï¿½Ø–[ï¿½-ï¿½ï¿½ï¿½ï¿½ï¿½bï¿½Û–ï¿½cï¿½^ï¿½=ï¿½ï¿½rï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½0\Ù¯ï¿½ï¿½ï¿½*ï¿½aï¿½ï¿½B<sï¿½Ê¼ï¿½ï¿½ï¿½3ï¿½y;wï¿½ï¿½ã°ª\ï¿½:ï¿½ï¿½2ï¿½)yqï¿½Ü–ï¿½ï¿½ï¿½ï¿½ï¿½qG5Ð§ï¿½szï¿½0E uï¿½ï¿½mï¿½Â§ï¿½!Xï¿½VGï¿½ h6Uï¿½mï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½uï¿½Õ®ï¿½_ï¿½|ï¿½bV=Uï¿½ï¿½ï¿½ï¿½

Huitzilopochtli

....

10 9

5 years ago

The first domain it connected to was owned by TenCent, and after I blocked it the 360 domain started to appear. It appears those two Chinese companies have a long history of sabotaging each other's software if it's installed on a system alongside their own shit.

Anyway I just ran it through another scanner:

https://www.hybrid-analysis.com/sample/45b3bbc213c0bce462d5574a83f19dc942b439037081704bc7dc3582b28ecc31?environmentId=200

Futility

80 122

5 years ago

Huitzilopochtli wrote: The first domain it connected to was owned by TenCent, and after I blocked it the 360 domain started to appear. It appears those two Chinese companies have a long history of sabotaging each other's software if it's installed on a system alongside their own shit.

Anyway I just ran it through another scanner:

https://www.hybrid-analysis.com/sample/45b3bbc213c0bce462d5574a83f19dc942b439037081704bc7dc3582b28ecc31?environmentId=200 Cool! I'm gonna poke it a bit, see if I can find anything. Thanks for the info!

Megatron King

Member

0 0

5 years ago

Hi guys, I am the developer of HttpCanary. HttpCanary is a legal app and no hacker backdoors.

Bugly is a famous crash report and event statistics platform designed by Tencent, I use this to collect the crash logs and fix the bugs. There is no user private and sensitive data uploads to bugly and other servers. About the Bugly platform, here is the official website: https://bugly.qq.com/v2/.

I have declared the crash log collections in EULA and private policy, please trust this app and welcome to supervise it!