Archive for June 24th, 2019

Rig Exploit Kit sends Pitou.B Trojan, (Tue, Jun 25th)


As I mentioned last week, Rig exploit kit (EK) is one of a handful of EKs still active in the wild.  Today’s diary examines another recent example of an infection caused by Rig EK on Monday 2019-06-24.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  Some of the alerts generated by this infection using Security Onion with Suricata and the EmergingThreats Pro ruleset viewed in Sguil.

Malvertising campaign redirect domain

EK-based malvertising campaigns have “gate” domains that redirect to an EK.  In this case, the gate domain was makemoneyeasywith[.]me.  According to Domaintools, this domain was registered on 2019-06-19, and indicators of this domain redirecting to Rig EK were reported as early as 2019-06-21.

Shown above:  makemoneyeasywith[.]me redirecting to Rig EK landing page on 2019-06-24.

Rig EK

The Rig EK activity I saw on 2019-06-24 was similar to Rig EK traffic I documented in an ISC diary last week.  See the images below for details.

Shown above:  Rig EK landing page.

Shown above:  Rig EK sends a Flash exploit.

Shown above:  Rig EK sends a malware payload.

The malware payload

The malware payload sent by this example of Rig EK appears to be Pitou.B.  In my post-infection activity, I saw several attempts at malspam, but I didn’t find DNS queries for any of the mail servers associated with this spam traffic.

Prior to the spam activity, I saw traffic over TCP port 2287 which matched a signature for ETPRO TROJAN Win32/Pitou.B, and it also fit the description for Pitou.B provided by Symantec from 2016.  I didn’t let my infected Windows host run long enough to generate DNS queries for remote locations described in Symantec’s Technical Description for this Trojan.  However, Any.Run’s sandbox analysis of this malware shows DNS queries similar to the Symantec description that happened approximately 9 to 10 minutes after the initial infection activity.

Shown above:  Post-infection traffic over TCP port 2287.

Shown above:  Filtering for indications of SMTP traffic in the pcap.

Shown above:  Using the Export Objects function in Wireshark to see successfully sent spam.

Shown above:  An example of spam sent from my infected Windows host.

Shown above:  DNS queries seen from the Any.Run analysis of this Pitou.B sample.

Indicators of Compromise (IoCs)

The following are IP addresses and domains associated with this infection:

  • 185.254.190[.]200 port 80 – makemoneyeasywith[.]me – Gate domain that redirected to Rig EK
  • 188.225.26[.]48 port 80 – 188.225.26[.]48 – Rig EK traffic
  • 195.154.255[.]65 port 2287 – Encoded/encrypted traffic caused by the Pitou.B Trojan
  • various IP addresses over TCP port 25 – spam traffic from the infected Windows host
  • various domains in DNS queries seen from the Any.Run analysis of this Pitou.B sample

The following are files associated with this infection:

SHA256 hash: 9c569f5e6dc2dd3cf1618588f8937513669b967f52b3c19993237c4aa4ac58ea

  • File size: 9,203 bytes
  • File description: Flash exploit sent by Rig EK on 2019-06-24

SHA256 hash: 835873504fdaa37c7a6a2df33828a3dcfc95ef0a2ee7d2a078194fd23d37cf64

  • File size: 827,904 bytes
  • File description: Pitou.B malware sent by Rig EK on 2019-06-24

Final words

A pcap of the infection traffic along with the associated malware and artifacts can be found here.

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Extensive BGP Issues Affecting Cloudflare and possibly others, (Mon, Jun 24th)

Cloudflare is currently affected by route leaks preventing users from accessing its services [1]. According to Cloudflare, about 16 Million “Internet Properties” are protected by its services. Recently, Cloudflare also started offering its “” privacy-focused DNS service, which may also be affected by the routing issue.

According to some reports, Google’s IP address may be affected as well. DNS is in particular vulnerable to man-in-the-middle attacks and they may go unnoticed unless you are using DNSSEC or one of the newer DNS over TLS or HTTPS protocols.

BGP route leaks are nothing new, and they happen much more often than they should. Just recently, traffic from various European mobile internet providers was rerouted through China due to a route leak originating from a Swiss ISP.

What is a “Route Leak”?

Routing on the internet is governed by BGP, the “Border Gateway Protocol.” ISPs sent BGP messages to their neighbors (“peers”), telling them which IP addresses the ISP offers. While there are registries that track which ISP is supposed to own what IP address (“whois”), they are not used in day to day routing. BGP is meant to be fast to allow internet traffic to be re-routing in the case of outages. If your company has two uplinks, one though ISP 1 and another one via ISP 2, and ISP 1 experiences an outage, you could just advertise your IP address space via ISP 2, and “the Internet” will pretty much instantly route your traffic to ISP 2.

Problems arise if someone is advertising IP address space that they do not own. Over recent years, extensions to BGP were implemented to authenticate the messages better, but these extensions have not been widely implemented. ISPs are also supposed to filter incoming messages, which again isn’t always done (or done correctly). 

It can also happen that two ISPs advertise the same IP address range. For example, ISP 1 advertises, and a second ISP advertises,, which is part of both subnets, will be routed to the second ISP since it is the smaller subnet. If someone intentionally advertises a bad route, they often do so by advertising multiple smaller subnets to be preferred over the valid routes.

Usually, a “route leak” is not something where the victim (Cloudflare today) is at fault in any way. Instead, various ISPs around the Internet that either advertises the routes or that propagate it are at fault. Route leaks often happen accidentally due to misconfigured routers and result in a denial of service. But they can also be used to intentionally re-route traffic to launch man in the middle attacks.

What Is Going Wrong With Cloudflare Right now?

BGP lists the autonomous systems (“Networks”) traffic should pass through to reach the target. For one of Cloudflare’s prefixes,, the list of autonomous systems should look like from a couple of different ISPs:

7474 (Optus AU) -> 4826 (Vocus AU) -> 13335 (Cloudflare)

2914 (Sprint) -> 13335 (Cloudflare)

The second entry is pretty straight forward. Sprint is directly connected to Cloudflare, so no poisoning is happening. The first entry is more vulnerable. Currently, the following route is used:

7474 (Optus AU) 7473 (Singtel) 6461 (Zayo Bandwith) 701 (Verizon)  396531  (Allegheny Technologies Incorporated) 33154 (Kit Carson Electric Corp) 3356 (Level 3) 13335 (Cloudflare)

This list of networks is not only much longer, but it also includes some smaller networks, which is unusual. Based on the list, it isn’t obvious who is at fault. It could be Level 3 (AS 3356) advertising to AS 33154 that it routes Cloudflare’s IP addresses (which again would be odd) and AS 33154 just propagating this information to its peers. But any network in this list could be the origin of the bad messages.

What Should You Do?

For the most part, there is not much that you can do about this (unless you are working for one of the affected networks). In the man-in-the-middle case, you would see a wrong TLS certificate. Never accept bad certificates. For the DoS part of the attack, there is not much you can do but wait for affected ISPs to work things out. Maybe try a different ISP if you have the option. If your website is behind Cloudflare’s proxies, then you could temporarily expose them directly but don’t do so without understanding the consequences. You may yourself be more susceptible to attack if you remove your site, in particular, if you count on Cloudflare for web application firewall and anti-denial of service services.


Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →