A data breach can cause a loss of revenue, destroy shareholder value, erode consumer trust and even open you up to legal consequences, whereas better security can add value to a company by preventing attacks, detecting breaches faster and mitigating the damage caused by cyber threats. The Ponemon Institute’s 2016 Cost of Data Breach Study estimates that the average consolidated total cost of a data breach is $4 million; so why do we still view cybersecurity simply as an operating cost?
Unfortunately, cybersecurity is often viewed as the organization that always says no versus the organization that makes the business go. Cybersecurity professionals deal with many paradoxes, for example information, software and infrastructure need to be secure yet usable. Yet usability is often viewed as being negatively impacted by the security measures taken. No organization gets a pass when it comes to risk, so it is paramount that organizations conduct ongoing risk analysis. Fleshing out the impacts and probability of identified risks is essential; however, at the end of the day, organizations are going to have to accept some degree of risk. The only other option is to close the doors and close up shop.
Organizations that have no understanding of their risks are operating in the dark. Businesses must assess their risks and determine their appetite for accepting various risks required to support their business model. With all the technological advances and the seemingly ever broadening attack surface, the valuation of information assets is still foundational to any cybersecurity program. When you’re placing a value on your information, you must gauge what the loss or modification of your information would mean to the organization and its stakeholders. Things like cyber value at risk and cybersecurity insurance to help recover from a data breach are business enablement considerations. Perhaps the most important factor to seeing cybersecurity as a business enabler versus a money pit is communication between the CISO and the C-suite. The CISO must be able to effectively communicate the investments in cyber into business terms. We can’t accomplish this by going down a path of technobabble, but rather, we must put cybersecurity into business enablement terms that resonate with the C-suite.
While there’s a lot of conversation about cyber security and physical premises security, the two rarely overlap. But when you study wireless security cameras, you experience a rare convergence of digital and physical. Do you know everything you need to know about this potentially risky technology?
Next time you’re walking down a busy street, take a look around. More specifically, take a look up. You’ll notice that there are dozens – perhaps hundreds – of cameras hidden away in corners, on lampposts, above traffic lights, in store windows, and everywhere in between. In fact, make a point of looking around next time you go on a walk through your neighborhood. Where I live, there’s no shortage of security cameras on private property.
As technology has improved in recent years, there’s been an increase in the number of wireless security cameras. Renowned for their ease of installation and convenient viewing options, wireless security cameras have become quite popular. They don’t come without risks, though.
Unlike hardwired security cameras that send footage to a closed-circuit television, wireless cameras rely on the Internet to transmit data to different devices that have permission to access the footage. The problem is that, like anything on the Internet, hackers can find ways to tap into the footage and use it for nefarious behavior.
Many cheap over-the-counter cameras, unfortunately, don’t come with encryption features and are actually relatively easy for hackers to access, which is part of the problem. I know when I was shopping for my first wireless camera, data encryption features were on the top of my list. But for those not as familiar with the technical language involved in cyber security, it’s easy to slip up and choose the wrong camera.
Making wireless security cameras more secure The goal, from a cyber security perspective, is to make security cameras more secure both through technological advancements and end-user behavior. Some of the various steps to be taken are fairly straightforward, while others are a little less obvious.
“Potentially the most dangerous thing you can do is point a security camera directly at your door where a house number is displayed,” security expert Christian Cawley says. “All it takes is for a security cam hacker to check your IP address, identify the owner of that range (for instance, your ISP) and narrow down your location to find your home.”
It’s also important for wireless security owners to pay attention to the overall security of their wireless networks. Routers should be configured using WPA2-based encryption, and it’s not a good idea to view streams on unsecured networks – such as at cafes and coffee shops.
Wireless security camera owners also need to consider whether they really need to be online. “The ability to stream video of what is happening at home to your mobile device is really useful,” Cawley admits. “But do you really need it? Does your Internet cam really need to be streaming data across the web?” There are always other options to be considered.
Putting security first The irony of wireless security cameras is that they often introduce additional security risks into your home or business. However, if you understand what you’re getting into and commit to making cyber security a priority, you can avoid most of these issues.
It’s time for the security community to come together and address this topic.
This blog goes into detail on recent work that Unit 42 has done to identify malicious sites associated with the Magnitude Exploit Kit (EK). It details the investigation process involved in identifying the algorithm used to generate domains used by the Magnitude EK. Defenders can use the provided data to identify possible domains that may be associated with the Magnitude EK before they’re used and block them pre-emptively and so block Magnitude EK attacks before they happen.
Initial Assessment
While hunting for new malware in Palo Alto Networks AutoFocus, I stumbled across some Adobe Flash files being used in what appeared to be an active exploit kit to which some users were being redirected. As I started to collect the URLs from these sites, a pattern began to emerge with which I was not immediately familiar. Below is a sample of the URLs.
1
2
3
4
5
6
7
ffp495bf1aw.itshis[.]party/d8667t121
89pd19n3d7d3x9cuf.maylink[.]space/766p3d35i8ze
131n35co4o895a35ga.seemif[.]faith/6i0218b05
96ax4b1cc77f0h76q.tinhes[.]trade/1tb20dc3f46h3n
The third-level domains are a mix of alphanumeric characters, followed by a second-level domain made up of two combined English language words, followed by unusual, legitimate top level domains (TLDs), and then finally a path made up of alphanumeric characters. Within a few minutes of refining my search criteria, I was seeing pages of session data covering this type of activity indicating this was an active threat so I decided to dive in further.
I was able to use AutoFocus in conjunction with YARA to accurately identified the container files as being dropped from Magnitude EK. Additionally, I found multiple blog posts such as this one on Malware Traffic Analysis which confirmed this pattern was in fact Magnitude.
Great, now that I know what I’m dealing with, I can get down to the business at hand and further enumerate Magnitude EK URLs.
Pulling the Brake
In research, we typically start the process of enumeration by identifying a pattern and then using that pattern to further target and collect information. Then we take that information and repeat the process. In this case, I extracted around 100,000 sessions that contained Adobe Flash files from URLs that matched a handful of the TLD’s I observed, including things like “stream”, “space”, “review”, “webcam”, “trade”, “date”, “party”. This provided a solid body of data that I could use to try and create a pattern from by using the previously discussed rules with alphanumeric characters and the like.
Using this PCRE, I successfully identified 1113 unique landing pages across 1056 unique domains (856 unique second level domains). These are included in “magek_landing.txt” on the Unit 42 GitHub IOC repository. This file also contains the PCREs described in this blog.
While creating the PCRE I noticed there was another URL pattern that frequently showed up on these domains. After additional research, I identified that this secondary URL pattern is the actual exploit Magnitude delivers once the landing page has profiled the browser/version(s) of Adobe Flash.
The following URLs are examples of this second pattern.
I didn’t identify any new domains with this new PCRE. Nevertheless, it provides another opportunity for defender blue teams to identify and catch this activity at their proxy or URL filtering devices.
Clearing the Track
At this point, we have good coverage from the PCREs of the Magnitude EK infrastructure but I wanted to see if the coverage could be extended even further. So far, everything I’ve identified has been actively seen in an attack but, as every blue teamer knows, it’s better if you can stop a threat before they are able to carry out an attack. To do this, I need to shift focus from known attack domains to unknown attack domains.
Taking the previously mentioned 1056 domains, I started reviewing the registration information for them and noticed several interesting characteristics as I collated the data from PassiveTotal.
1. There were 110 registrants that registered 26 domains, which was roughly the average number of domains per registrant. On the low end, 16 registrants registered exactly 52 domains. In Table 1 you can see the top ten registrant addresses and the number of times they were used.
404
Klarkson avenue 25
343
32 Glendale Crescent
318
Densell st. 199
298
Henbamo 33
286
1299 Still Street
212
Nolenpark 88
183
Haringo 399
172
1043 Mattson Street
160
Idorkalben 1928
159
hotberry road 38
Table 1 Top 10 registrant addresses used.
2. There was heavy re-use of addresses and telephone numbers, with one phone number being used for 1411 domains while another phone number is tied to 2421 registrations.
3. There was a lot of information that is just plain wrong in the registration details, which I feel would be worth its own research effort. For example, Table 2 shows entries wherein the city doesn’t exist in the listed state.
Table 2 Example domain registrants with cities listed for states in which they do no exist
Given this, I took 223 identified unique e-mails from our domains observed being used in attacks and used that to enumerate a list of 6089 second level domains for Magnitude EK that match our known pattern. These domains can also be found in “magek_domains.txt” on the Unit 42 GitHub IOC repository.
By leveraging this data, defenders can now proactively block domains that could be used for Magnitude EK before they are used for attacks. In addition, defenders can use the provided PCRE’s to block future domains. For Palo Alto Networks customers, all domains are properly identified as malicious and the below tag was created in AutoFocus for those who wish to explore the activity further.
Acknowledgements: A big “thank you” to Juan Figuera for tightening up these PCRE’s and testing them, along with Nathan Fowler, who both helped make sure these are false-positive adverse for the greater good of the community.
