On the heels of hacks hitting artist funding site Patreon and a database of 15 million people who applied for T-Mobile accounts comes word that online stock brokerage Scottrade has suffered a breach that exposed the personal information of 4.6 million customers.

Scottrade officials said in an online advisory that the breach happened in late 2013 or early 2014 and exposed social security numbers, e-mail addresses and "other sensitive information," whatever that may be. While all that data was available for the taking, the advisory said the attackers appeared to target client names and street addresses. The notice never made it clear if password data was also accessed, but unhelpfully, the officials said, "Client passwords remained fully encrypted at all times and we have not seen any indication of fraudulent activity as a result of this incident."

Remarkably, the officials leave it up to customers to decide whether they should change passwords. Out of an abundance of caution, Ars recommends that all Scottrade users change their passcodes ASAP, both on the brokerage site and any other sites that may have used the same credentials. The officials said they learned of the breach after receiving information from federal law enforcement investigators. Scottrade is offering a year of free identity protection services to all 4.6 million people whose details were included in the compromised database.

Read on Ars Technica | Comments



The actor using gates registered through BizCN(alwayswith privacy protection) continues using the Nuclear exploit kit (EK) to deliver malware.

My previous diary on this actor documented the actors switch from Fiesta EK to Nuclear EK in early July 2015 [1]. Since then, the BizCN gate actor briefly switched to Neutrino EK in however, it appears to be using Nuclear EK again.

Our thanksto Paul, who submitted a pcap of">">">actorto the ISC.


Pauls pcap showed us a Google search leading to thecompromised website.In the image below, youcan alsosee" />
Shown above: A pcap of the traffic filtered by HTTP request.

No payload was found inthis EK traffic, so the Windowshost viewing the compromised websitedidnt get infected. The Windows host from this pcapwas running IE 11, and URLs for the EK traffic stop after the last two HTTP POST requests. These URL patterns are what Ive seen every time IE 11 crashes after getting hit with Nuclear EK.

A key thing to remember with the BizCN gate actor is the referer line from the landing page. This will always show the compromised website, and it wont indicate the BizCN-registered gate that gets you there. Pauls pcap didnt include traffic to the BizCN-registered gate, but I found a reference to it in the traffic. " />
Shown above: Flow chart for EK traffic associated with the BizCN gate actor.

How did Ifind the gate in this example? First, I checked the referer on the HTTP GET request to the EK" />
Shown above: TCP stream for the HTTP GET request to the Nuclear EK landing page.

That referer should have injected script pointing to the BizCN gate URL, soI exported that" />
Shown above: " />
Shown above: The object Iexportedfrom the pcap.

d the HTML text" />
Shown above: Malicious script in page from the compromised websitepointing to URL on the BizCN-registered gate domain.

The BizCN-registered">perolissan.com, andpingingto itshowed as the IP address. " />
Shown above: Whoisinformation on">perolissan.com.

This completes my flow chart for the BizCN gate actor.The domains associated from Pauls pcapwere:

  • www.gm-trucks.com - Compromised website
  • - perolissan.com - BizCN-registered gate
  • - zezetap.xyz - Nuclear EK

Final words

Recently, Ive hadhard time getting a full chain of infection traffic from theBizCN gate actor. Pauls pcap also had this issue, because there was no payload. However the BizCN gate actor is still active, and many of the compromised websites Ive noted in previous diaries [1, 4] are still compromised.

We continue to track the BizCN gate actor, and well let you know if we discover any significant changes.

Brad Duncan
Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic


[1] https://isc.sans.edu/forums/diary/BizCN+gate+actor+changes+from+Fiesta+to+Nuclear+exploit+kit/19875/
[2] http://malware-traffic-analysis.net/2015/09/11/index.html
[3] http://malware-traffic-analysis.net/2015/09/14/index.html
[4] https://isc.sans.edu/diary/Actor+using+Fiesta+exploit+kit/19631

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

A call to arms for InfoSec professionals: Be the innovation
Emily Mossburg, a principal at Deloitte & Touche LLP, provided information security leaders with some useful insight yesterday into why their jobs are so freaking hard. The occasion was the Mass TLC event on “The Business of Security” in Boston ...


Enlarge / Results of a Shodan search performed on September 11 made it clear Patreon was vulnerable to code-execution attacks. (credit: Detectify)

Five days before Patreon.com officials said their donations website was plundered by hackers, researchers at a third-party security firm notified them that a serious programming error could lead to disastrous results. The researchers now believe the vulnerability was the entry point for attackers who went on to publish almost 15 gigabytes' worth of source code, user password data, and private messages.

The error was nothing short of facepalm material. Patreon developers allowed a Web application tool known as the Werkzeug utility library to run on a public-facing subdomain. Specifically, according to researchers at Swedish security firm Detectify, one or more of Patreon's live Web apps on zach.patreon.com was running Werkzeug debugging functions. A simple query on the Shodan search service brought the goof to the attention of Detectify researchers, who in turn notified Patreon officials on September 23. Adding to their concern, the same Shodan search shows thousands of other websites making the same game-over mistake.

Remote code execution by design

The reason for the alarm was clear. The Werkzeug debugger allows visitors to execute code of their choice from within the browser. Werkzeug developers have long been clear about this capability and the massive risks that stem from using it in production environments. But in case anyone missed the warning, an independent blogger called attention to the threat last December.

Read 6 remaining paragraphs | Comments


Posted by InfoSec News on Oct 02


By Steve Ragan
Salted Hash
CSO Online
Sept 26, 2015

It’s Day two at DerbyCon, which is actually the day that most of the
action takes place. This weekend has already seen some impressive talks,
but today promises to be interesting with talks running the full spectrum
of InfoSec, from medical device research, AppSec, and social...

Posted by InfoSec News on Oct 02

[Moderators note - I've attended THOTCON for the last six years (I'll be
attending 0x07) and found THOTCON to have a very high signal to noise ratio,
the networking can't be beat, and if you're not from Chicago proper, we have
epic food, beverages and nightlife that I feel everyone should try!
http://thotcon.org/ - WK]


Posted by InfoSec News on Oct 02


By Tim Greene
Network World
Oct 1, 2015

Verizon consultants probed Target’s network for weaknesses in the
immediate aftermath of the company’s 2013 breach and came back with
results that point to one overriding – if not dramatic - lesson: be sure
to implement basic security best practices.

In a recent KrebsOnSecurity post, Brian...

Posted by InfoSec News on Oct 02


By Kim Zetter

SECURITY RESEARCHERS AND vendors have long been locked in a debate over
how to disclose security vulnerabilities, and there’s little on which the
two sides agree. Apparently this extends even to the question of whether
they should meet to hash out their disagreements.

That’s the conclusion after a coalition of...

Posted by InfoSec News on Oct 02


By Dan Goodin
Ars Technica
Oct 1, 2015

Hackers broke into a server and made off with names, driver license
numbers, and other personal information belonging to more than 15 million
US consumers who applied for cellular service from T-Mobile.

The breach was the result of an attack on a database maintained by
Internet Storm Center Infocon Status