Latest Alerts

Previously we detailed this project in Feature of the Week: Report Fake Tech Support Calls and some initial statistic reports at Feature of the Week: Report Fake Tech Support Call Statistics.

We have steadily been receiving first and second hand information emails about fake tech support calls and sms spam. I wanted to highlight our data collection project again at https://isc.sans.edu/reportfakecall.html where you, or anyone that reports these to you, can submit as much information as you are comfortable sending us to help better understand how common "Fake Tech Support" calls are, and what they are trying to achieve.

The emphasis today is on SMS (texting) type messages! The first question on the form "Was the call automated or did a person call you?" has choices for automated, personal or SMS. Follow on questions for SMS can include message language, URL if any and the phone number. Fill in any or all of the information, nothing is required but anything is helpful.

I can't wait to get my first call and go round-and-round trying to find the start button on my linux system :D but I have received numerous SMS spam and submitted to the form.

 

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
--
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center https://isc.sans.edu

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

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

On the heels of the fake Tweet this past week regarding injury to President Obama, and the subsequent stock market decline estimated to have wiped out $130 billion in stock value, SANS's Alan Paller spoke with CNN's Christine Romans during a Your Money segment on Friday 26 APR. Watch this succinct and impactful interview as they discuss the danger hackers pose to our banks and our economy.

Russ McRee | @holisticinfosec

 

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

On the heels of my post on Microsoft's SIRv4 earlier this week, reader Ray posed a great question that elicited some nuanced responses from fellow handlers Mark H and Swa F. All parties have agreed to allow me to share the conversation with the ISC readership.

From Ray:

What is, "up to date anti-virus software"?  Is there a de facto standard of how often or what defines when a system is up to date or not up to date?  My goal isn't to split hairs.  There are a lot of moving pieces (in the background) to this question & where I work.  I would like to know what other organizations use; besides sooner is better. 

Mark H's response:

To me the definition of up to date is the latest pattern file for that particular application.  So I tend to configure AV products to check at least hourly for updates and apply them.  Some product interestingly however still consider daily or weekly to be ok.  Putting on my QSA hat usually I accept daily updates as being ok (assuming that the AV product is therefore at the lates pattern update), go beyond that and you'd best have a very good reason for lagging.

Ray's reply:

While wearing the AV hat at my last company I expected a drop in infections when I stabilized our (pattern file) distributions, but didn't expect such a dramatic drop in the rate.  With three updates a day I hit < .5% systems were more than one day out of date.  Since moving to a different company with different responsibilities I see one update a day and a 5 day window for updates with the target of only 90% of systems updated I see...room for improvement but face a mind set challenge.  I was curious what other "standards" were.

Swa's feedback:

Agreement with Mark: hourly is THE way to go. 

Add internal servers to help distribute it and allow in the field updates for machines at home or while roaming out there. Make it so that the machine gets isolated in quarantine on your internal network if it's more than a long weekend out of date on updates.  I'd suggest a trade off between this aggressive updating - transparent to the user as long as they do not sabotage it - vs a daily scan of the entire drive - which is far from transparent.  Also focus on those not getting updated on time: figure out why and how to fix it.  There's no point in paying for AV updates if you do not use them. Any self respecting attacker checks their handy work against something like VirusTotal, so being behind even a little bit makes the AV useless.  Sure you might someday trip over a bad AV update. So what? It's easy to know what it did wrong and recover from it? Easy to know what it did is absolutely untrue for any modern malware. Those that still think that need a reality check. The only recovery of malware that works is "nuke from high orbit" all the rest does not yield reliable machines.    Russ' 2 cents:   I'll follow up on Swa's point. There is no "recovery" from malware in my world. There is no running a tool to "clean up" after an infection. Nuke from space is the only solution or the machine(s) remain entirely suspect. So have a plan for reimaging systems conveniently and efficiently, store data on separare drives or partions, and practice safe backup. Because when you pop a valid AV alert in my shop? BOOM...  

Photo courtesy of nukeitfromorbit.com 

Great discussion, Ray and handlers. Thanks for letting us share.

Russ McRee | @holisticinfosec

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

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

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

[Guest Diary: Dylan Johnson BSc.CISSP] [A week in the life of some Perimeter Firewalls]

I hope the title of this blog doesn’t appear a dry and dull topic because a week in the life of an Internet facing firewall is anything but dull.

This is just a short blog detailing an interesting piece of research aimed at promoting situational awareness in relation to the threat from the internet.

Perimeter firewalls are the main barriers protecting you from the Internet, should these be misconfigured either maliciously or accidentally, what would you be exposed too?

Graph 1 below shows the amount of dropped traffic (Axis-Y) against time (Axis-X). You can see at peak periods the number of dropped connections is 3.6k over a 30 minute period.

Graph 1

The summary graphs below drill into more of the detail present in the audit data from the firewalls and present this in the same format as graph 1 however the different colors highlight the traffics country of origin.

If you look at the bottom right graph you can see traffic from China with a peak drop rate of 1250 connections every 30 minutes. Also notice the erratic trends within the graph, bottom right.

Graph 2

So as you can see firewalls are constantly busy fighting off a constant slew of malicious traffic. A lot of the traffic dropped may be reconnaissance or to make an analogy someone checking the quality of your locks, windows and doors, however they can still post via the letter box!

To explain the firewall letter box analogy, firewalls wouldn’t be much use if they blocked absolutely everything, if that was the case why would we even need a network connection to the internet at all? Perimeter firewalls need to pass certain types of traffic to applications, its then up to the applications to deal with the traffic profile we saw previously in graph 2 i.e all that traffic from China and the other countries.

Graph 3 below shows actions taken by an application firewall as you can see there is a constant slew of SQLi (SQL Injection) and XSS (Cross Site Scripting) attacks. These attacks reach the webserver perhaps because there is no security control upstream capable of understanding and dealing with Layer 7 or Application Layer traffic. A traditional firewall operates at layers 3(Network Layer) and layers 4(Transport Layer) they are often oblivious to what is happening at layer 7 they only care about getting the traffic to its intended destination.

Graph 3

So as you can see you are indeed connected to the global internet and are being probed by traffic from the four corners of the known world, from Amsterdam to Zimbabwe.

The purpose of this blog was to demonstrate that you may be in a quiet and relatively tranquil part of the world but you are connected to a network that remains mainly un-policed and carry’s a very real and persistent threat as I hope you can see from the data and explanation presented in this blog. Make sure you understand the threat, monitor it and ensure you have controls in place to keep it out.

 

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
--
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center https://isc.sans.edu

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

--

John Bambenek

bambenek \at\ gmail /dot/ com

Bambenek Consulting

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

--

John Bambenek

bambenek \at\ gmail /dot/ com

Bambenek Consulting

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

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
--
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center https://isc.sans.edu

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

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

In my day job we get involved in payment systems, credit card transactions etc. We are also asked to investigate and explain incidents as well as "unusual" activity.

When looking at credit card payments there are always payments for people like lkjsdflkjs and "famous person name", usually small value transactions $2, $5, $10 although recently we've started seeing $60 transactions.  These are easily identified and the motive is very clear, test the card.  If the transaction goes through the card number and CVC (if needed) or other details are correct.

Recently however I've been seeing more interesting transactions. The transactions start with a high value and step down until the transaction is accepted.  ie. we start with a charge of 10K, the next transaction 9K , 8K ......3K, $1000, $900, $800, ....$100.  The process is automated so if the limit on the card is high enough multiple transactions are sometimes accepted. Again these transactions are easily identified, however the motive eludes me. We looked at a number of possibilities:

• identify the upper limit on the card. - The process however results in the card being maxed out. The issuing bank or card brand blocks the card. The number now no longer has any value. You know the upper limit, but can no longer use the card.
• purchases for resale - This was the obvious one, but in the cases I worked on, none actually deliver physical product to the purchaser.   
• Refunds? - Another scenario we looked at is that after the transactions are done the organisation is called by the fake cardholder and a refund is requested. Because their bank has blocked the card they'd like to be refunded to a different card or some other payment mechanism. Looking at refunds and refund requests through customer service avenues allowed us to discard this scenario in the cases we worked on.
• Credit Card DOS - A third scenario was a DOS on cards,  max out the card and as many as possible and irritate either the bank or the card brand, or the proper cardholders. The volumes however would be annoying for the merchant and issuing bank, but were certainly not on epic scales. Unless of course we were only seeing one small part of a much larger distributed effort.

So what I'm asking those of you that deal with credit card payments is this.  Have you seen similar behaviour in your payment systems?  Multiple transactions on the same card, starting with a big value, stepping down in increments to lower values until the transaction is accepted and in some cases beyond. Those of you that deal with donation sites or online delivery (i.e. no physical product) are more likely to see these.

If you have other ideas on what the point of these transactions is by all means share, either as a comment or through the contact form.

Regards
Mark H  (markh.isc at gmail.com)

 

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

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

This report is pretty much an annual staple. The 2013 report has been released and can be obtained here.  

http://www.verizonenterprise.com/resources/reports/rp_data-breach-investigations-report-2013_en_xg.pdf

 

M

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

The troublesome KB2823324 from last month has been re-released through KB2840149.  The theory is that this one will not cause the same isue.  Let us know if it does.  

More details here http://technet.microsoft.com/en-us/security/bulletin/ms13-036

Mark 

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

Full disclosure: I work at Microsoft.

This past Thursday (17 APR) Microsoft released  volume 14 of its Security Intelligence Report (SIRv14) which includes new threat intelligence from over a billion systems worldwide. 

It should come as no surprise that network worms are on the decrease and that web-based attacks are all the rage. Interesting report highlights include:

• The proportion of Conficker and Autorun threats reported by enterprise computers each decreased by 37% from 2011 to 2H12
• In the second half of 2012, 7 out of the top 10 threats affecting enterprises were associated with malicious or compromised websites (see example below)
• Enterprises were more likely to encounter the iFrame redirection technique than any other malware family tracked in 4Q12
• One specific iFrame redirection family called IframeRef, increased fivefold in the fourth quarter of 2012 to become the number one malicious technique encountered by enterprises worldwide
• IframeRef was detected nearly 3.3 million times in the fourth quarter of 2012

The report also takes a close look at the dangers of not using up-to-date antivirus software in an article titled “Measuring the Benefits of Real-time Security Software.” I read this with some skepticism imagining it might be heavily slanted to the use of Microsoft AV products, but read on, it's not. It refers to a ton of data generated via Microsoft telemetry but remains data-centric to point out that, on average, computers without AV protection were five and a half times more likely to be infected (What?! I'm shocked. This is my shocked face ). The study also found that 2.5 out of 10, or an estimated 270 million computers worldwide were not protected by up-to-date antivirus software. Now that actually is shocking. Really? What's the matter with people? For more information on that analysis, see details on TechNet.

On the related subject of web-based attacks, I recently completed a forensic review of an elderly Windows XP system that had clearly crossed paths with Blackhole, or as the SIR referers to it, Blacole; said system was infected with Exploit:Java/CVE-2011-3544. The behavior discovered warrants a quick review as it details just one of the plethora of manners in which web-based attacks can own you. Of interest, SIRv14 states that "detections of exploits targeting CVE-2011-3544 and CVE-2010-0840, two vulnerabilities with significant exploitation in the first half of the year, declined by large amounts in 2H12. Both are cross-platform vulnerabilities that were formerly targeted by the Blacole kit but have been removed from more recent versions of the kit." That's in keeping with findings on the machine I analyzed given that the related JAR files had been on the system since February 2012. Nonetheless, at the risk of oversimplifying the analysis, the writeup for CVE 2011-3544 describes a vulnerability that allows a remote attacker to execute arbitrary code on the system, caused by the improper handling of Rhino Javascript errors. Of note when unpacked from the initial JAR file were efira.class and efira.java (the applet). As ripped directly from the conclusion of Michael Schierl's excellent writeup on CVE-2011-3544:

Steps to exploit this vulnerability include:

1. Assign a toString() method to this that will disable the security manager and then run your payload
2. Create a new JavaScript error object
3. Overwrite the error object's message property by this
4. Return the error object
5. Create a new script engine and bind the applet to a JS variable (in case your payload needs it)
6. Evaluate the script mentioned above
7. Add the resulting object to a JList
8. Display the JList to the user and wait for the UI thread to render it

Strings analysis of Efira.class (see VirusTotal if you want hashes) returned the requisite steps including:

• toString() (1)
• java/lang/Object error (2)
• javax/script/ScriptEngine (5) 
• eval (6)
• javax/swing/JList (7)

And this was but one example of six Java-specific exploits dropped on this victim system during its unfortunate visit to a Blackhole infected site. Stay tuned for new and interesting web-based exploits for 2013. Takeaways: 1) Run AV 2) Patch 3) Pray    As always the SIR is a great read. Download it here.   Russ McRee | @holisticinfosec       (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

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

--

John Bambenek

bambenek \at\ gmail /dot/ com

Bambenek Consulting

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

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

In the recent few days there was another denial of service attack launched at financial organizations. (Yeah, I know, DDoS on a bank, that's *totally* never happens). What is newsworthy isn't that it happened, it was the means used to execute the attack. Specifically, the organizations were flooded with UDP port 19 traffic which is the chargen protocol. I am not sure I've ever seen a legitimate use of this protocol or encountered a machine that had it on intentionally before.

For review, chargen is basically a character generation protocol that listens on port 19 with TCP or UDP.  If you connect to TCP, it continues to stream random characters until you close the connection. With UDP, it will respond with an up to 512 byte response depending on the request.  In this particular case, it was another amplification attack using UDP.  What makes chargen under UDP so desirable is that you can spoof sources without having to worry about establishing a fake connection and that it responds with packets much larger than the request. In short, if your networks are exposing a service that responds to UDP with packets much larger than the request (DNS in particular is popular these days), take due care that you are doing rate-limiting if those protocols are Internet-accessible.

It's not a common attack using chargen and there is some evidence that in a few of the cases in the past few years the attack was used as a smoke screen to hide other attack traffic.

In this case, many of the devices used were commodity multifunction copiers and the like. Which leads to two questions:

1) Why are these Internet accessible?
2) Why did the vendor enable this protocol by default? (or possible some malicious individual enabled it)

So your takeaways are two-fold:

- Check to make sure you don't have Internet-accessible devices that don't need to be (and if they need to be, you are regulating UDP requests).
- Make sure you are doing some form of BCP 38 where you filter outbound traffic to ensure that no packets leave your network that don't have internal addresses. Amplification attacks rely on spoofed packets and if every provider implemented this filtering, we would see these attacks greatly diminish overnight.

And don't forget old and dead protocols, sometimes they're still around. :)

--
John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting

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