Under Armor announced this week that approximately 150 million users of the diet and fitness app MyFitnessPal had their personal information acquired by an unauthorized third party sometime in February 2018. As Reuters noted, it is the largest data breach of 2018 in terms of the number of records affected.
The breach was discovered on March 25, and the data compromised includes usernames, email addresses, and hashed passwords — the majority of which used bcrypt, the company said.
“The affected data did not include government-issued identifiers (such as Social Security numbers and driver’s license numbers) because we don’t collect that information from users,” the company said in a statement. “Payment card data was not affected because it is collected and processed separately.”
MyFitnessPal also said that it would be requiring users to change their passwords and is urging users to do so immediately. The company is also urging users to review their accounts for suspicious activity as well as to change passwords on any other online accounts that used the same or a similar password to their now-breached MyFitnessPal credentials.
It is unclear how the unauthorized third party acquired the data, and the investigation is ongoing. Under Armour bought MyFitnessPal in February 2015 for $475 million.
Other trending cybercrime events from the week include:
SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of the top trending targets are shown in the chart below.
Law enforcement officials in Spain have arrested the alleged leader of the cybercriminal syndicate behind the Carbankak and Cobalt malware attacks, which have targeted more than 100 financial organizations around the world and caused cumulative losses of over €1 billion since 2013.
Europol’s press release did not name the alleged mastermind behind the group; however, Bloomberg reported that Spain’s Interior Ministry named the suspect as Denis K, a Ukrainian national who had accumulated about 15,000 bitcoins (worth approximately $120 million at the time of his arrest). Europol noted that numerous other coders, mule networks, and money launderers connected to the group were also the target of the international law enforcement operation.
The group first used the Anunak malware in 2013 to target financial transfers and ATM networks, and by the following year they had created a more sophisticated version of the malware known as Carbanak, which was used by the group used until 2016. At that point the group carried out an even more sophisticated wave of attacks using custom-made malware based on the Cobalt Strike penetration testing software, Europol said.
“The criminals would send out to bank employees spear phishing emails with a malicious attachment impersonating legitimate companies,” Europol wrote in a press release. “Once downloaded, the malicious software allowed the criminals to remotely control the victims’ infected machines, giving them access to the internal banking network and infecting the servers controlling the ATMs. This provided them with the knowledge they needed to cash out the money.”
Carlos Yuste, a Spanish police chief inspector who helped lead the operation, told Bloomberg that “the head has been cut off” of the high-profile group. Steven Wilson, Head of Europol’s European Cybercrime Centre, said that the arrest illustrates how law enforcement “is having a major impact on top level cybercriminality.”
This week, Executive Director of Source Boston 2018 Rob Cheyne joins us for an interview! Paul delivers the Technical Segment this week entitled, Cutting The Cord: The Ideal Home Network Setup! In the Security News, we have updates from Apple macOS, Windows 7 Meltdown patch, Atlanta’s Ransomware attack, a special appearance in the Security News from Apollo Clark, and more on this episode of Paul’s Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/Episode553
Visit https://www.securityweekly.com/psw for all the latest episodes!
This week, Paul is joined by our very own Keith Hoodlet to review the book The Phoenix Project! In the news, we have updates from Cisco, Distil Networks, BeyondTrust, Cambridge Analytica, and more on this episode of Enterprise Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ES_Episode85
Visit https://www.securityweekly.com/esw for all the latest episodes!
Dan Wheatley, Partner and CEO at Straight Talk Agency, joins us for the interview this week. Tenable hires Morgan Stanley, Sift Science raised $53M Series D, and Virsec raised $24M Series B. This segment is about the companies making news with founding rounds, exits, and other impacts you need to know about in the industry.
Full Show Notes: https://wiki.securityweekly.com/BSWEpisode79
Visit http://securityweekly.com/category/bsw for all the latest episodes!
Networked systems
According to information derived from FBI investigations, malicious cyber actors are increasingly using a style of brute force attack known as password spraying against organizations in the United States and abroad.
On February 2018, the Department of Justice in the Southern District of New York, indicted nine Iranian nationals, who were associated with the Mabna Institute, for computer intrusion offenses related to activity described in this report. The techniques and activity described herein, while characteristic of Mabna actors, are not limited solely to use by this group.
The Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI) are releasing this Alert to provide further information on this activity.
In a traditional brute-force attack, a malicious actor attempts to gain unauthorized access to a single account by guessing the password. This can quickly result in a targeted account getting locked-out, as commonly used account-lockout policies allow three to five bad attempts during a set period of time. During a password-spray attack (also known as the “low-and-slow” method), the malicious actor attempts a single password against many accounts before moving on to attempt a second password, and so on. This technique allows the actor to remain undetected by avoiding rapid or frequent account lockouts.
Password spray campaigns typically target single sign-on (SSO) and cloud-based applications utilizing federated authentication protocols. An actor may target this specific protocol because federated authentication can help mask malicious traffic. Additionally, by targeting SSO applications, malicious actors hope to maximize access to intellectual property during a successful compromise.
Email applications are also targeted. In those instances, malicious actors would have the ability to utilize inbox synchronization to (1) obtain unauthorized access to the organization's email directly from the cloud, (2) subsequently download user mail to locally stored email files, (3) identify the entire company’s email address list, and/or (4) surreptitiously implements inbox rules for the forwarding of sent and received messages.
Traditional tactics, techniques, and procedures (TTPs) for conducting the password-spray attacks are as follows:
Indicators of a password spray attack include:
The vast majority of known password spray victims share some of the following characteristics [1][2]:
A successful network intrusion can have severe impacts, particularly if the compromise becomes public and sensitive information is exposed. Possible impacts include:
To help deter this style of attack, the following steps should be taken:
The FBI encourages recipients of this document to report information concerning suspicious or criminal activity to their local FBI field office or the FBI’s 24/7 Cyber Watch (CyWatch). Field office contacts can be identified at www.fbi.gov/contact-us/field. CyWatch can be contacted by phone at (855) 292-3937 or by e-mail at CyWatch@ic.fbi.gov. When available, each report submitted should include the date, time, location, type of activity, number of people, and type of equipment used for the activity, the name of the submitting company or organization, and a designated point of contact. Press inquiries should be directed to the FBI’s national Press Office at npo@ic.fbi.gov or (202) 324-3691.
This product is provided subject to this Notification and this Privacy & Use policy.
Have you ever thought about how a data breach could affect you personally? What about your business? Either way, it can be devastating. Fortunately, there are ways that you can protect your personal or business data, and it’s easier than you think. Don’t assume that protecting yourself is impossible just because big corporations get hit with data breaches all of the time. There are things you can do to get protected.
All of the major websites that we most commonly use have some type of two-factor authentication. They are spelled out, below:
The two-factor authentication that Facebook has is called “Login Approvals.” You can find this in the blue menu bar at the top right side of your screen. Click the arrow that you see, which opens a menu. Choose the Settings option, and look for a gold colored badge. You then see “Security,” which you should click. To the right of that, you should see Login Approvals and near that, a box that says “Require a security code.” Put a check mark there and then follow the instructions. The Facebook Code Generator might require a person to use the mobile application on their phone to get their code. Alternatively, Facebook sends a text.
Google also has two-factor authentication. To do this, go to Google.com/2step, and then look for the blue “get started’ button. You can find it on the upper right of the screen. Click this, and then follow the directions. You can also opt for a text or a phone call to get a code. This also sets you up for other Google services, including YouTube.
Twitter also has a form of two-factor authentication. It is called “Login Verification.” To use it, log in to Twitter and click on the gear icon at the top right of the screen. You should see “Security and Privacy.” Click that, and then look for “Login Verification” under the Security heading. You can then choose how to get your code and then follow the prompts.
PayPal
PayPal has a feature known as “Security Key.” To use this, look for the Security and Protection section on the upper right corner of the screen. You should see PayPal Security Key on the bottom left. Click the option to “Go to register your mobile phone.” On the following page, you can add your phone number. Then, you get a text from PayPal with your code.
Yahoo
Yahoo uses “Two-step Verification.” To use it, hover over your Yahoo avatar, which brings up a menu. Click on Account Settings and then on Account Info. Then, scroll until you see Sign-In and Security. There, you will see a link labeled “Set up your second sign-in verification.” Click that and enter your phone number. You should get a code via text.
Microsoft
The system that Microsoft has is called “Two-step Verification.” To use it, go to the website login.live.com. Look for the link on the left. It goes to Security Info. Click that link. On the right side, click Set Up Two-Step Verification, and then follow the prompts.
Apple
Apple also has something called “Two-Step Verification.” To use it, go to applied.apple.com. On the right is a blue box labeled Manage Your Apple ID. Hit that, and then use you Apple ID to log in. You should then see a link for Passwords and Security. You have to answer two questions to access the Security Settings area of the site. There, you should see another link labeled “Get Started.” Click that, and then enter your phone number. Wait for your code on your mobile phone, and then enter it.
LinkedIn also has “Two-Step Verification.” On the LinkedIn site, hover your mouse over your avatar and a drop-down menu should appear. Click on Privacy and Settings, and then click on Account. You should then see Security Settings, which you should also click. Finally, you should see the option to turn on Two-Step Verification for Sign-In. Turn that on to get your code.
These are only a few of the major sites that have two-step verification. Many others do, too, so always check to see if your accounts have this option. If they don’t, see if there is another option that you can use in addition to your password to log in. This could be an email or a telephone call, for instance. This will help to keep you safe.
Amazon
Amazon’s Two-Step Verification adds an additional layer of security to your account. Instead of simply entering your password, Two-Step Verification requires you to enter a unique security code in addition to your password during sign in.
Without setting up Two Step authentication for your most critical accounts, all a criminal needs is access to your username, which is often your email address and then access data breach files containing billions of passwords that are posted all over the web. Once they search your username/email for the associated password, they are in.
Two factor locks them out.
Robert Siciliano is a Security and Identity Theft Expert. He is the founder of Safr.me a cybersecurity speaking and consulting firm based in Massachussets. See him discussing internet and wireless security on Good Morning America.
One of the biggest data breach announcements of the past week belonged to Orbitz, which said on Tuesday that as many as 880,000 customers may have had their payment card and other personal information compromised due to unauthorized access to a legacy Orbitz travel booking platform.
“Orbitz determined on March 1, 2018 that there was evidence suggesting that, between October 1, 2017 and December 22, 2017, an attacker may have accessed certain personal information, stored on this consumer and business partner platform, that was submitted for certain purchases made between January 1, 2016 and June 22, 2016 (for Orbitz platform customers) and between January 1, 2016 and December 22, 2017 (for certain partners’ customers),” the company said in a statement.
Information potentially compromised includes payment card information, names, dates of birth, addresses, phone numbers, email addresses, and gender.
As American Express noted in its statement about the breach, the affected Orbitz platform served as the underlying booking engine for many online travel websites, including Amextravel.com and travel booked through Amex Travel Representatives.
Expedia, which purchased Orbitz in 2015, did not say how many or which partner platforms were affected by the breach, USA Today reported. However, the company did say that the current Orbitz.com site was not affected.
Other trending cybercrime events from the week include:
SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of the top trending targets are shown in the chart below.
Facebook has faced a week of criticism, legal actions, and outcry from privacy advocates after it was revealed that the political consulting Cambridge Analytica had accessed the information of 50 million users and leveraged that information while working with the Donald Trump campaign in 2016.
“Cambridge Analytica obtained the data from a professor at the University of Cambridge who had collected the information by creating a personality-quiz app in 2013 that plugged into Facebook’s platform,” The Wall Street Journal reported. “Before a policy change in 2015, Facebook gave app creators and academics access to a treasure trove of data, ranging from which pages users liked to details about their friends.”
It isn’t clear how many other developers might have retained information harvested from Facebook before the 2015 policy change, The Journal reported. However, Mark Zuckerberg said the company may spend “many millions of dollars” auditing tens of thousands of data collecting apps in order to get a better handle on the situation.
The privacy breach has already led to regulatory scrutiny and potential lawsuits around the globe. Bloomberg reported that the FTC is probing whether data handling violated terms of a 2011 consent decree. In addition, Facebook said it would conduct staff-level briefings with six congressional committees in the coming week. Some lawmakers have called for Zuckerberg to testify as well, and Zuckerberg told media outlets that he would be willing to do so if asked.
Facebook’s stock price has dropped from $185 to $159 over the past eight days amid the controversy, and several companies have suspended their advertising on Facebook or deleted their Facebook pages altogether due to the public backlash.
This post provides an in-depth analysis of Gooligan monetization schemas and recounts how Google took it down with the help of external partners.
This post is the final post of the series dedicated to the hunt and take down of Gooligan that we did at Google in collaboration with Check Point in November 2016. The first post recounts the Gooligan origin story and offers an overview of how it works. The second one provides an in-depth analysis of Gooligan’s inner workings and an analysis of its network infrastructure. As this post builds on the previous two, I encourage you to read them if you haven’t done so already.
This series of posts is modeled after the talk I gave on the subject at Botconf in December 2017. Here is a recording of the talk:
You can also get the slides here , but they are pretty bare.
Gooligan’s goal was to monetize the infected devices through two main fraudulent schemas: Ad fraud and Android app boosting.
As shown in the screenshot above, periodically Gooligan will use its root privileges to overlay an ad popup for a legitimate app on top of any activity the user was currently doing. Under the hood, Gooligan knows when the user is looking at the phone, as it monitors various key events, including when the screen is turned on.
We don’t have much insight on how effective those ad campaigns were or who was reselling them, as they don’t abuse Google’s ads network, and they use a gazillion HTTP redirects, which makes attribution close to impossible. However we believe that ad fraud was the main driver of Gooligan revenue, given its volume and the fact that we blocked its fake installs as discussed below.
The second way Gooligan attempted to monetize infected devices was by performing Android app boosting. An app boosting package is a bundle of searches for a specific query on the Play store, followed by an install and a review. The search is used in an attempt to rank the app for a given term. This tactic is commonly peddled in App Store Optimization (ASO) guides.
The reason Gooligan went through the trouble of stealing OAuth tokens and manipulating the Play store is probably that the defenses we put in place are very effective at detecting and discounting fake synthetic installs. Using real devices with real accounts was the Gooligan authors’ attempt to evade our detection systems. Overall, it was a total failure on their side: We caught all the fake installs, and suspended the abusive apps and developers.
As illustrated in the diagram above, the app boosting was done in four steps:
Token stealing: The malware extracts the phone’s long term token from the phone’s accounts.
Taking order: Gooligan reports phone information to the central command and control system, and receives in response a reply telling it which app to boost, including which search term to use and which comment to leave (if any). Phone information is exfiltrated because Gooligan authors also had access to non-compromised phones and were trying to use information obtained from Gooligan to fake requests from those phones.
Token exchange: The long term token is exchanged for a short term token that allows Gooligan to access the Play store. We are positive that no user data was compromised by Gooligan, as no other data was ever requested by Gooligan.
Boosting: The fake search, installation, and potential review is carried out through the manipulated Play store app.
Cleaning up Gooligan was challenging for two reasons: First, as discussed in the infection post , its reset persistence mechanism meant that doing a factory reset was not enough to clean up the old unpatched devices. Second, the Oauth tokens had been exfiltrated to Gooligan servers.
Asking users to reflash their devices would have been unreasonable and issuing an OTA (Over The Air) update would have take too long. Given this difficult context and the need to act quickly to protect our users we went for an alternative solution that we rarely use: orchestrating a takedown with the help of third parties.
With the help of Shadowserver foundation and domain registrars we sinkholed Gooligan domains and got them to point to Shadowserver controlled IPs instead of IPs controlled by Gooligan authors. This sinkholing ensured that infected devices couldn’t exfiltrate token or receive fraud commands, as they would connect to sinkhole servers instead of the real command and control servers. As shown in the graph above, our takedown was very successful: It blocked over 50M attempts to connect to Gooligan’s control server in 2017.
With the sinkhole in place, the second part of the remediation involved resecuring the accounts that were compromised, by disabling the exfiltrated tokens and notifying the users. Notification at that scale is very complex, for three key reasons:
Reaching users in a timely fashion across a wide range of devices is difficult. We ended up using a combination of SMS, email, and Android messaging, depending on what communication channel was available.
It was important to make the notification understandable and useful to all users. Explaining what was happening clearly and simply took a lot of iteration. We ended up with the notification shown in the screenshot above.
Once crafted, the text of the notification and help page had to be translated into the languages spoken by our users. Performing high quality internationalization for over 20 languages very quickly was quite a feat.
Overall, in order to respond to Gooligan, many people, including myself, ended up working long hours through the Thanksgiving weekend (an important holiday in the U.S.). Our commitment to quickly eradicate this threat paid off: On the evening of Monday, November 29th, the takedown took place, followed the next day by the resecuring of the compromised accounts. All in all, this takedown took a mere few days, which is blazing fast when you compare it to other similar ones. For example, the Avalanche botnet ) takedown took four years of intensive efforts.
To conclude, Gooligan was a very challenging malware to tackle, due to its scale and unconventional tactics. We were able to meet this challenge and defeat it, thanks to a cross-industry effort and the involvement of many teams at Google that didn’t go home until users were safe.
Thanks for reading this post all the way to the end. I hope it showcases how we approach botnet fighting and sheds some light on some of the lesser known, yet still critical, activities that our research team assists with.
Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about Gooligan.
To get notified when my next post is online, follow me on Twitter , Facebook , Google+ , or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .
A bientôt!
With all the news about Facebook recently, you might be wondering, what exactly does Facebook know about me from my profile? Sure, you can peruse your profile online, but that doesn’t tell the whole story. One way to see what Facebook has on you is to download your Facebook data.
The ability to download your Facebook data isn’t really new, but not many users know that you can do it. It only takes a few minutes; how long depends on how big your data files are. Here are the steps to download your Facebook data.
If you’ve decided that you want to leave Facebook completely, here’s how to delete, disable, or limit your Facebook account.
Paul gives a tech segment on How to find the most innovative tech at a security show. In the news, we have updates from Alex Stamos, Facebook harvesting information about YOU, Uber self-driving car hits and kills pedestrian, and more on this episode of Paul's Security Weekly!
→Full Show Notes: https://wiki.securityweekly.com/Episode552
→Visit https://www.securityweekly.com/psw for all the latest episodes!
In the third week of March 2018, through FireEye’s Dynamic Threat Intelligence, FireEye discovered malicious macro-based Microsoft Word documents distributing SANNY malware to multiple governments worldwide. Each malicious document lure was crafted in regard to relevant regional geopolitical issues. FireEye has tracked the SANNY malware family since 2012 and believes that it is unique to a group focused on Korean Peninsula issues. This group has consistently targeted diplomatic entities worldwide, primarily using lure documents written in English and Russian.
As part of these recently observed attacks, the threat actor has made significant changes to their usual malware delivery method. The attack is now carried out in multiple stages, with each stage being downloaded from the attacker’s server. Command line evasion techniques, the capability to infect systems running Windows 10, and use of recent User Account Control (UAC) bypass techniques have also been added.
The following two documents, detailed below, have been observed in the latest round of attacks:
MD5 hash: c538b2b2628bba25d68ad601e00ad150
SHA256
hash:
b0f30741a2449f4d8d5ffe4b029a6d3959775818bf2e85bab7fea29bd5acafa4
Original Filename: РГНФ 2018-2019.doc
The document shown in Figure 1 discusses Eurasian geopolitics as they relate to China, as well as Russia’s security.
Figure 1: Sample document written in Russian
MD5 hash: 7b0f14d8cd370625aeb8a6af66af28ac
SHA256
hash:
e29fad201feba8bd9385893d3c3db42bba094483a51d17e0217ceb7d3a7c08f1
Original Filename: Copy of communication from Security
Council Committee (1718).doc
The document shown in Figure 2 discusses sanctions on humanitarian operations in the Democratic People’s Republic of Korea (DPRK).
Figure 2: Sample document written in English
In both documents, an embedded macro stores the malicious command line to be executed in the TextBox property (TextBox1.Text) of the document. This TextBox property is first accessed by the macro to execute the command on the system and is then overwritten to delete evidence of the command line.
In Stage 1, the macro leverages the legitimate Microsoft Windows certutil.exe utility to download an encoded Windows Batch (BAT) file from the following URL: http://more.1apps[.]com/1.txt. The macro then decodes the encoded file and drops it in the %temp% directory with the name: 1.bat.
There were a few interesting observations in the command line:
Figure 3: Malicious BAT file stored as an
encoded file to appear as an SSL certificate
Once decoded and executed, the BAT file from Stage 1 will download an encoded CAB file from the base URL: hxxp://more.1apps[.]com/. The exact file name downloaded is based on the architecture of the operating system.
Similarly, based on Windows operating system version and architecture, the CAB file is installed using different techniques. For Windows 10, the BAT file uses rundll32 to invoke the appropriate function from update.dll (component inside setup.cab).
For other versions of Windows, the CAB file is extracted using the legitimate Windows Update Standalone Installer (wusa.exe) directly into the system directory:
The BAT file also checks for the presence of Kaspersky Lab Antivirus software on the machine. If found, CAB installation is changed accordingly in an attempt to bypass detection:
As described in the previous section, the BAT file will download the CAB file based on the architecture of the underlying operating system. The rest of the malicious activities are performed by the downloaded CAB file.
The CAB file contains the following components:
install.bat will perform the following essential activities:
ipnet.dll is the main component inside the CAB file that is used for performing malicious activities. This DLL exports the following two functions:
The ServiceMain function first performs a check to see if it is being run in the context of svchost.exe or rundll32.exe. If it is being run in the context of svchost.exe, then it will first start the system service before proceeding with the malicious activities. If it is being run in the context of rundll32.exe, then it performs the following activities:
SANNY malware uses the FTP protocol as the C2 communication channel.
The FTP configuration information used by SANNY malware is encoded and stored inside ipnet.ini.
This file is Base64 encoded using the following custom character set: SbVIn=BU/dqNP2kWw0oCrm9xaJ3tZX6OpFc7Asi4lvuhf-TjMLRQ5GKeEHYgD1yz8
Upon decoding the file, the following credentials can be recovered:
It then continues to perform the connection to the FTP server decoded from the aforementioned config file, and sets the current directory on the FTP server as “htdocs” using the FtpSetCurrentDirectoryW function.
For reconnaissance purposes, SANNY malware executes commands on the system to collect information, which is sent to the C2 server.
System information is gathered from the machine using the following command:
The list of running tasks on the system is gathered by executing the following command:
After successful connection to the FTP server decoded from the configuration file, the malware searches for a file containing the substring “to everyone” in the “htdocs” directory. This file will contain C2 commands to be executed by the malware.
Upon discovery of the file with the “to everyone” substring, the malware will download the file and then performs actions based on the following command names:
The uploaded file is compressed and encrypted using the routine described later in the Compression and Encoding Data section.
C2 Command | Purpose |
chip | Update the FTP server config file |
pull | Upload a file from the machine |
put | Copy an existing file to a new destination |
/user | Create a new process with explorer.exe access token |
default command | Execute a program on the machine using WinExec() |
SANNY malware uses an interesting mechanism for compressing the contents of data collected from the system and encoding it before exfiltration. Instead of using an archiving utility, the malware leverages Shell.Application COM object and calls the CopyHere method of the IShellDispatch interface to perform compression as follows:
NTWDBLIB.dll – This component from the CAB file will be extracted to the %windir%\system32 directory. After this, the cliconfg command is executed by the BAT file.
The purpose of this DLL module is to launch the install.bat file. The file cliconfg.exe is a legitimate Windows binary (SQL Client Configuration Utility), loads the library NTWDBLIB.dll upon execution. Placing a malicious copy of NTWDBLIB.dll in the same directory as cliconfg.exe is a technique known as DLL side-loading, and results in a UAC bypass.
Update.dll – This component from the CAB file is used to perform UAC bypass on Windows 10. As described in the BAT File Analysis section, if the underlying operating system is Windows 10, then it uses update.dll to begin the execution of code instead of invoking the install.bat file directly.
The main actions performed by update.dll are as follows:
This activity shows us that the threat actors using SANNY malware are evolving their malware delivery methods, notably by incorporating UAC bypasses and endpoint evasion techniques. By using a multi-stage attack with a modular architecture, the malware authors increase the difficulty of reverse engineering and potentially evade security solutions.
Users can protect themselves from such attacks by disabling Office macros in their settings and practicing vigilance when enabling macros (especially when prompted) in documents, even if such documents are from seemingly trusted sources.
SHA256 Hash | Original Filename |
b0f30741a2449f4d8d5ffe4b029a6d3959775818bf2e85bab7fea29bd5acafa4 | РГНФ 2018-2019.doc |
e29fad201feba8bd9385893d3c3db42bba094483a51d17e0217ceb7d3a7c08f1
| Copy of communication from Security Council Committee (1718).doc |
eb394523df31fc83aefa402f8015c4a46f534c0a1f224151c47e80513ceea46f | 1.bat |
a2e897c03f313a097dc0f3c5245071fbaeee316cfb3f07785932605046697170 | Setup.cab (64-bit) |
a3b2c4746f471b4eabc3d91e2d0547c6f3e7a10a92ce119d92fa70a6d7d3a113 | Setup.cab (32-bit) |
Skilled attackers continually seek out new attack vectors, while employing evasion techniques to maintain the effectiveness of old vectors, in an ever-changing defensive landscape. Many of these threat actors employ obfuscation frameworks for common scripting languages such as JavaScript and PowerShell to thwart signature-based detections of common offensive tradecraft written in these languages.
However, as defenders' visibility into these popular scripting languages increases through better logging and defensive tooling, some stealthy attackers have shifted their tradecraft to languages that do not support this additional visibility. At a minimum, determined attackers are adding dashes of simple obfuscation to previously detected payloads and commands to break rigid detection rules.
In this DOSfuscation white paper, first presented at Black Hat Asia 2018, I showcase nine months of research into several facets of command line argument obfuscation that affect static and dynamic detection approaches. Beginning with cataloguing a half-dozen characters with significant obfuscation capabilities (only two of which I have identified being used in the wild), I then highlight the static detection evasion capabilities of environment variable substring encoding. Combining these techniques, I unveil four never-before-seen payload obfuscation approaches that are fully compatible with any input command on cmd.exe's command line. These obfuscation capabilities de-obfuscate in the current cmd.exe session for both interactive and noninteractive sessions, and avoid all command line logging. Finally, I discuss the building blocks required for these new encoding and obfuscation capabilities and outline several approaches that defenders can take to begin detecting this genre of obfuscation.
As a Senior Applied Security Researcher with FireEye's Advanced Practices Team, I am tasked with researching, developing and deploying new detection capabilities to FireEye's detection platform to stay ahead of advanced threat actors and their ever-changing tactics, techniques and procedures. FireEye customers have been benefiting from multiple layers of innovative obfuscation detection capabilities developed and deployed over the past nine months as a direct result of this research.
Download the DOSfuscation white paper today.
Daniel Bohannon (@danielhbohannon) is a Senior Applied Security Researcher on FireEye's Advanced Practices Team.
This week, Michael and Paul interview Fred Scholl, President of Monarch Information Networks! Then the articles of discussion and tracking security innovation! All that and more, on this episode of Business Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/BSWEpisode78
Visit https://www.securityweekly.com/bsw for all the latest episodes!
This week, John Strand takes the show by the reigns and conducts an outstanding interview with Brian Honan, who is recognised internationally as an expert on cybersecurity! John also gives a tech segment on how enterprises defend against attacks! All that and more, here on Enterprise Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ES_Episode84
I’ve grown to expect certain things from a VPN service: a nice-looking and easy-to-use desktop program, and extra features like double VPNs, dedicated torrent servers, or sometimes Netflix compatibility. PersonalVPN from WiTopia confounds all those expectations a little, but is still a great option to consider.
This morning, Armor, a cloud security provider, released a great report into the cyber crime black market. Armor was formerly known as as FireHost – they were one of the leading hosts...
The post Diving Into the Dark Web and Understanding the Economy Powering Cyber Attacks appeared first on PerezBox.
Pokémon-themed Umbreon Linux Rootkit Hits x86, ARM Systems| # | File Name | Hash Value | File Size (on Disk) | Duplicate? |
|---|---|---|---|---|
| 1 | .umbreon-ascii | 0B880E0F447CD5B6A8D295EFE40AFA37 | 6085 bytes (5.94 KiB) | |
| 2 | autoroot | 1C5FAEEC3D8C50FAC589CD0ADD0765C7 | 281 bytes (281 bytes) | |
| 3 | CHANGELOG | A1502129706BA19667F128B44D19DC3C | 11 bytes (11 bytes) | |
| 4 | cli.sh | C846143BDA087783B3DC6C244C2707DC | 5682 bytes (5.55 KiB) | |
| 5 | hideports | D41D8CD98F00B204E9800998ECF8427E | 0 bytes ( bytes) | Yes, of file promptlog |
| 6 | install.sh | 9DE30162E7A8F0279E19C2C30280FFF8 | 5634 bytes (5.5 KiB) | |
| 7 | Makefile | 0F5B1E70ADC867DD3A22CA62644007E5 | 797 bytes (797 bytes) | |
| 8 | portchecker | 006D162A0D0AA294C85214963A3D3145 | 113 bytes (113 bytes) | |
| 9 | promptlog | D41D8CD98F00B204E9800998ECF8427E | 0 bytes ( bytes) | |
| 10 | readlink.c | 42FC7D7E2F9147AB3C18B0C4316AD3D8 | 1357 bytes (1.33 KiB) | |
| 11 | ReadMe.txt | B7172B364BF5FB8B5C30FF528F6C5125 | 2244 bytes (2.19 KiB) | |
| 12 | setup | 694FFF4D2623CA7BB8270F5124493F37 | 332 bytes (332 bytes) | |
| 13 | spytty.sh | 0AB776FA8A0FBED2EF26C9933C32E97C | 1011 bytes (1011 bytes) | Yes, of file spytty.sh |
| 14 | umbreon.c | 91706EF9717176DBB59A0F77FE95241C | 1007 bytes (1007 bytes) | |
| 15 | access.c | 7C0A86A27B322E63C3C29121788998B8 | 713 bytes (713 bytes) | |
| 16 | audit.c | A2B2812C80C93C9375BFB0D7BFCEFD5B | 1434 bytes (1.4 KiB) | |
| 17 | chown.c | FF9B679C7AB3F57CFBBB852A13A350B2 | 2870 bytes (2.8 KiB) | |
| 18 | config.h | 980DEE60956A916AFC9D2997043D4887 | 967 bytes (967 bytes) | |
| 19 | config.h.dist | 980DEE60956A916AFC9D2997043D4887 | 967 bytes (967 bytes) | Yes, of file config.h |
| 20 | dirs.c | 46B20CC7DA2BDB9ECE65E36A4F987ABC | 3639 bytes (3.55 KiB) | |
| 21 | dlsym.c | 796DA079CC7E4BD7F6293136604DC07B | 4088 bytes (3.99 KiB) | |
| 22 | exec.c | 1935ED453FB83A0A538224AFAAC71B21 | 4033 bytes (3.94 KiB) | |
| 23 | getpath.h | 588603EF387EB617668B00EAFDAEA393 | 183 bytes (183 bytes) | |
| 24 | getprocname.h | F5781A9E267ED849FD4D2F5F3DFB8077 | 805 bytes (805 bytes) | |
| 25 | includes.h | F4797AE4B2D5B3B252E0456020F58E59 | 629 bytes (629 bytes) | |
| 26 | kill.c | C4BD132FC2FFBC84EA5103ABE6DC023D | 555 bytes (555 bytes) | |
| 27 | links.c | 898D73E1AC14DE657316F084AADA58A0 | 2274 bytes (2.22 KiB) | |
| 28 | local-door.c | 76FC3E9E2758BAF48E1E9B442DB98BF8 | 501 bytes (501 bytes) | |
| 29 | lpcap.h | EA6822B23FE02041BE506ED1A182E5CB | 1690 bytes (1.65 KiB) | |
| 30 | maps.c | 9BCD90BEA8D9F9F6270CF2017F9974E2 | 1100 bytes (1.07 KiB) | |
| 31 | misc.h | 1F9FCC5D84633931CDD77B32DB1D50D0 | 2728 bytes (2.66 KiB) | |
| 32 | netstat.c | 00CF3F7E7EA92E7A954282021DD72DC4 | 1113 bytes (1.09 KiB) | |
| 33 | open.c | F7EE88A523AD2477FF8EC17C9DCD7C02 | 8594 bytes (8.39 KiB) | |
| 34 | pam.c | 7A947FDC0264947B2D293E1F4D69684A | 2010 bytes (1.96 KiB) | |
| 35 | pam_private.h | 2C60F925842CEB42FFD639E7C763C7B0 | 12480 bytes (12.19 KiB) | |
| 36 | pam_vprompt.c | 017FB0F736A0BC65431A25E1A9D393FE | 3826 bytes (3.74 KiB) | |
| 37 | passwd.c | A0D183BBE86D05E3782B5B24E2C96413 | 2364 bytes (2.31 KiB) | |
| 38 | pcap.c | FF911CA192B111BD0D9368AFACA03C46 | 1295 bytes (1.26 KiB) | |
| 39 | procstat.c | 7B14E97649CD767C256D4CD6E4F8D452 | 398 bytes (398 bytes) | |
| 40 | procstatus.c | 72ED74C03F4FAB0C1B801687BE200F06 | 3303 bytes (3.23 KiB) | |
| 41 | readwrite.c | C068ED372DEAF8E87D0133EAC0A274A8 | 2710 bytes (2.65 KiB) | |
| 42 | rename.c | C36BE9C01FEADE2EF4D5EA03BD2B3C05 | 535 bytes (535 bytes) | |
| 43 | setgid.c | 5C023259F2C244193BDA394E2C0B8313 | 667 bytes (667 bytes) | |
| 44 | sha256.h | 003D805D919B4EC621B800C6C239BAE0 | 545 bytes (545 bytes) | |
| 45 | socket.c | 348AEF06AFA259BFC4E943715DB5A00B | 579 bytes (579 bytes) | |
| 46 | stat.c | E510EE1F78BD349E02F47A7EB001B0E3 | 7627 bytes (7.45 KiB) | |
| 47 | syslog.c | 7CD3273E09A6C08451DD598A0F18B570 | 1497 bytes (1.46 KiB) | |
| 48 | umbreon.h | F76CAC6D564DEACFC6319FA167375BA5 | 4316 bytes (4.21 KiB) | |
| 49 | unhide-funcs.c | 1A9F62B04319DA84EF71A1B091434C64 | 4729 bytes (4.62 KiB) | |
| 50 | cryptpass.py | 2EA92D6EC59D85474ED7A91C8518E7EC | 192 bytes (192 bytes) | |
| 51 | environment.sh | 70F467FE218E128258D7356B7CE328F1 | 1086 bytes (1.06 KiB) | |
| 52 | espeon-connect.sh | A574C885C450FCA048E79AD6937FED2E | 247 bytes (247 bytes) | |
| 53 | espeon-shell | 9EEF7E7E3C1BEE2F8591A088244BE0CB | 2167 bytes (2.12 KiB) | |
| 54 | espeon.c | 499FF5CF81C2624B0C3B0B7E9C6D980D | 14899 bytes (14.55 KiB) | |
| 55 | listen.sh | 69DA525AEA227BE9E4B8D59ACFF4D717 | 209 bytes (209 bytes) | |
| 56 | spytty.sh | 0AB776FA8A0FBED2EF26C9933C32E97C | 1011 bytes (1011 bytes) | |
| 57 | ssh-hidden.sh | AE54F343FE974302F0D31776B72D0987 | 127 bytes (127 bytes) | |
| 58 | unfuck.c | 457B6E90C7FA42A7C46D464FBF1D68E2 | 384 bytes (384 bytes) | |
| 59 | unhide-self.py | B982597CEB7274617F286CA80864F499 | 986 bytes (986 bytes) | |
| 60 | listen.sh | F5BD197F34E3D0BD8EA28B182CCE7270 | 233 bytes (233 bytes) |
| # | File Name | Hash Value | File Size (on Disk) |
|---|---|---|---|
| 1 | 015a84eb1d18beb310e7aeeceab8b84776078935c45924b3a10aa884a93e28ac | A47E38464754289C0F4A55ED7BB55648 | 9375 bytes (9.16 KiB) |
| 2 | 0751cf716ea9bc18e78eb2a82cc9ea0cac73d70a7a74c91740c95312c8a9d53a | F9BA2429EAE5471ACDE820102C5B8159 | 7512 bytes (7.34 KiB) |
| 3 | 0a4d5ffb1407d409a55f1aed5c5286d4f31fe17bc99eabff64aa1498c5482a5f | 0AB776FA8A0FBED2EF26C9933C32E97C | 1011 bytes (1011 bytes) |
| 4 | 0ce8c09bb6ce433fb8b388c369d7491953cf9bb5426a7bee752150118616d8ff | B982597CEB7274617F286CA80864F499 | 986 bytes (986 bytes) |
| 5 | 122417853c1eb1868e429cacc499ef75cfc018b87da87b1f61bff53e9b8e8670 | 9EEF7E7E3C1BEE2F8591A088244BE0CB | 2167 bytes (2.12 KiB) |
| 6 | 409c90ecd56e9abcb9f290063ec7783ecbe125c321af3f8ba5dcbde6e15ac64a | B4746BB5E697F23A5842ABCAED36C914 | 6149 bytes (6 KiB) |
| 7 | 4fc4b5dab105e03f03ba3ec301bab9e2d37f17a431dee7f2e5a8dfadcca4c234 | D0D97899131C29B3EC9AE89A6D49A23E | 65160 bytes (63.63 KiB) |
| 8 | 8752d16e32a611763eee97da6528734751153ac1699c4693c84b6e9e4fb08784 | E7E82D29DFB1FC484ED277C702187818 | 55564 bytes (54.26 KiB) |
| 9 | 991179b6ba7d4aeabdf463118e4a2984276401368f4ab842ad8a5b8b73088522 | 2B1863ACDC0068ED5D50590CF792DF05 | 7664 bytes (7.48 KiB) |
| 10 | a378b85f8f41de164832d27ebf7006370c1fb8eda23bb09a3586ed29b5dbdddf | A977F68C59040E40A822C384D1CEDEB6 | 176 bytes (176 bytes) |
| 11 | aa24deb830a2b1aa694e580c5efb24f979d6c5d861b56354a6acb1ad0cf9809b | DF320ED7EE6CCF9F979AEFE451877FFC | 26 bytes (26 bytes) |
| 12 | acfb014304b6f2cff00c668a9a2a3a9cbb6f24db6d074a8914dd69b43afa4525 | 84D552B5D22E40BDA23E6587B1BC532D | 6852 bytes (6.69 KiB) |
| 13 | c80d19f6f3372f4cc6e75ae1af54e8727b54b51aaf2794fedd3a1aa463140480 | 087DD79515D37F7ADA78FF5793A42B7B | 11184 bytes (10.92 KiB) |
| 14 | e9bce46584acbf59a779d1565687964991d7033d63c06bddabcfc4375c5f1853 | BBEB18C0C3E038747C78FCAB3E0444E3 | 71940 bytes (70.25 KiB) |
A trustworthy virtual private network (VPN) is a good way to keep your internet usage secure and private whether at home or on public Wi-Fi. But just how private is your activity over a VPN? In other words, how do you know if the VPN is doing its job or if you’re unwittingly leaking information to prying eyes?
To find out, you first need to know what your computer looks like to the internet without a VPN running. Start by searching for what is my IP on Google. At the top of the search results, Google will report back your current public Internet Protocol (IP) address. That’s a good place to start, but there is more to your internet connection and its potential for leaks.
How many times have you stumbled on the SSL certificate, and the only things that you cared about were Common Name (CN), DNS Names, Dates (issue and expiry)? Do you know SSL certificate can speak so much about you/ your firm? It can tell stories and motives; you can gather a good intelligence from them - which companies are hosting new domains, sub-domains; did they just revoke the last certificate? Or, why some firm switched its vendors/ CA(s)? We all have read that SSL certificates have always been the talk of the town for their inherent strength but weak issuance process, i.e. the chain of command relying on the Certificate Authorities, (aka the business firms) but haven't played with them in real-time. There are search engines available but none of them as comprehensive, fast and free as CertDB
There have been quite a few attacks and hacks where Certificate Authorities were targeted[1] by hacking groups[2] or even involved[3] directly. Even though the vast initiatives by browsers and firms to regularly monitor SSL certificates[4], improve browser behaviours for awareness[5] and revoke the bad ones has been highly appreciated, the pentesters often don't find much during the comprehensive assessment. Recently, there has been an uproar on the business interests of CA(s) with the issuance, so much so that some are being tagged as bad and untrusted CA[6] for not doing job well. Companies are moving aggressively to HTTPS especially with the recent introduction of LetsEncrypt Wildcard Certificates. But we haven't seen the use of all this information on a common platform to further analyse the certificates and assess their digital SSL footprint and gather valuable intelligence.
This is where CertDB steps in. A great project maintained by smart people and FREE forever[7] for the public. I spent last few weeks accessing their services, and the platform and my short verdict says - It is great! It does have some quirks, but highly recommended!
The crt.sh and CertDB serve different objectives. while crt.sh gets the data from certificate transparency (CT) logging system where "legit" CA submit the certs in "real time"; CertDB is based on the scanning the IPv4 segment, domains and "finding & analyzing" certificates - good or bad.
CertDB can also find self-signed certificates, which crt.sh can not. Hence, CertDB can give a realistic view of HTTPS - which IP is using what certs, self-signed, invalid CA etc; while crt.sh shows the "good" law-abiding view, per say.
CertDB is an Internet search engine for SSL certificates. In simple terms, it parses the certificate and then makes different fields indexable for the user to execute search queries. It indexes the following common information,
| Fields | Details |
|---|---|
| Subject | Country, State, Category, Serial Number, Locality, Organization, Common Name |
| Issuer | Country, State, Locality, Organization, Common Name |
| Others | Public Key IP Address related to the domain, Validity Dates |
| Fingerprint | SHA1, SHA256 and MD5 |
| Extensions | Usage, Subject Key ID, Authority Key ID, ALT Names, Certificate Policies |
Now once you have extracted these fields, you can query and generate intelligence around it. You have these fields available with a logical query, and can be clubbed together to make complex queries. CertDB also provides raw certificates, public key and json formatted certificate information available for download. Recently they have integrated Alexa Ranking with the domains/ IP addresses and all of this information has been filtered and is available as lists - top domains, top organizations, top countries, top issuers etc.
One such exciting list is "expiring certificates" where you can find the list of Domains/ Organizations whose certificates are about to expire. This kind of information can be convenient while auditing or assessing the firm's digital footprint.
While the documentation says the CertDB continuously scans every reachable web-server, on the Internet; the lab tests are not conclusive. I have asked the team to clarify and shall publish the response as part of the interview once I have a confirmed reply. But, it's appreciable that once their scanner detects the certificate, the information is available for the public to perform the required analysis in near real-time.
While we have all the information extracted from the digital certificates, we have to filter the results to get the required information via GUI or API. The GUI is open to all and can be used to do such queries with search-box, but to use the API one has to register an account.
You can register at https://certdb.com/signup, and an API key shall be allotted to you to perform 1000 queries a day with maximum 1000 results per query.
| Field | Value |
|---|---|
| URL | https://certdb.net/api |
| Method | GET, POST |
| api_key | <get your key post registration> |
| q | Any query (just like in search interface) |
| response_type | 0 — JSON list of the dictionary with found certificates with all details 1 — JSON list of found certificates in base64 2 — JSON list of distinct organizations from found certificates 3 — JSON list of distinct domains from found certificates |
It takes 30 seconds to register and receive the API Key. Here are few examples of querying the right information,
issuer:"Godaddy.com" country:"Italy"cidr:"13.32.0.0/15" (example: replace , with newline and only list first 10 results tr , '\n' | head -10
expiring:"10 days"expiring:"7 days" organization:"Netflix"
new:"5 days" organization:"Safeway Insurance Company"
There can be many such cases where you would like to know the certificates issued to a firm in the past; or if the firm recently got a new domain/ sub-domain and looking for a new business line. I could think of the following interesting cases if I am doing an assessment,
site:example.com and then start negating in a loop as per the first result. site:example.com -www to site:example.com -www -test. Or, use a threat intel tool to gather the sub-domains and validate if they all have SSL certificates. Manually check, and report if some domains are not on HTTPS (Refer: Google will be hard on you if you are not on HTTPS!)q="organization:"Example Inc." and you will be surprised to see sometimes firms are not aware of the domains on their name, or certificate issued by them but not renewed on time.While the service is great, there are few issues as well which the team is working on,
GET request. It is not recommended as it can be cached at many hops (example: proxy)json parsing of the results.It's been few weeks since I am using this service, and my frank opinion is it has great potential and use. I am using this service while assessing AWS instances, and Fortune 500 firms. I have also found some expiring certificates for the clients and informed them in due course of time. I would highly recommend you to have a look and register an account. You can also set a cron job to check the dates/ digital SSL footprint of an organization.
Next Steps: I shall soon be publishing an interview with their team asking for more details on the roadmap, competition, and improvements.
Cover Image Credit: Photo by Rubén Bagüés
Distrust of the Symantec PKI: Immediate action needed by site operators ↩︎
In an exclusive interview with Cyber Sins, CERTDB confirms this "project" will always be free to use. ↩︎
Amazon IP Range: https://ip-ranges.amazonaws.com/ip-ranges.json ↩︎
This week, Keith and Paul discuss Uber's open source tool for adversarial simulation, AMD processors, Hijacked MailChimp accounts used to distribute banking malware, and more on this episode of Application Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ASW_Episode09
Visit https://www.securityweekly.com/asw for all the latest episodes!
Hacker groups began to flourish in the early 1980s with the emergence of computer. Hackers are like predators that can access your private data at any time by exploiting the vulnerabilities of your computer. Hackers usually cover up their tracks by leaving false clues or by leaving absolutely no evidence behind. In the light of
The post Three Hacking Groups You Definitely Need to Know About appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Creating a mysql user is a very common task and a very important one. Many developers after creating a user grant them all permissions over a mysql schema and this can be a big security flaw. When you are creating a user you must think of all permissions that user will need and grant them the
The post Mysql create user appeared first on Hacker News Bulletin | Find the Latest Hackers News.
The enormous number of hacks in 2014 have propelled information safety into the front of the news and the brains of many companies. Cyber attacks on big enterprises like Target, Sony, and Home Depot lately caused President Obama to call for partnership amongst the two sectors (private and public) in order to share the information
The post Why the Cyber Criminals at Synack need $25 Million to Track Down Main Safety Faults appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Windows has the added facility to work as a VPN server, even though this choice is undisclosed. This can work on both versions of Windows – Windows 8 and Windows 7. To enable this, the server makes use of the point-to-point tunneling protocol (PPTP.) This could be valuable for linking to your home system on
The post Want to have a VPN Server on Your Computer (Windows) Without setting up Any Software? appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Pemera Blue Cross, a United States of America – based health insurance corporation, has confided in that its systems were infringed upon and their security and associability was breached when cyber criminals hacked the company and made their way in 11 million of their customers’ records. It is the second cyber attack in a row
The post The Health insurance Company – Premera Blue Cross – of the United States of America was cyber criminally attacks and 11 million records were accessed appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Marketable and even martial planes have an Achilles heel that could abscond them as susceptible to cyber criminals on the ground, who specialists say could possibly seize cockpits and generate disorder in the skies. At the present, radical groups are thought to be short of the complexity to bring down a plane vaguely, but it
The post Political analysts caution air plane connections systems that are susceptible to cyber attacks appeared first on Hacker News Bulletin | Find the Latest Hackers News.
A single researcher who is actually a cyber criminal made $225,000 this week – that too all by legal means! This cyber research hacker cyber criminally attacked browsers this past week. For the past two days, safety researchers have tumbled down on Vancouver for a Google – sponsored competition called Pwn – 2 – Own,
The post Researcher makes $225,000, legally, by cyber attacking browsers appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Associates of two Chinese cyber crime teams have hollowed out the best prizes at a main yearly hacking competition held in Vancouver, Canada. Cyber attackers at Pwn2Own, commenced in 2007, were triumphant in violating the security of broadly -used software including Adobe Flash, Mozilla’s Firefox browser, Adobe PDF Reader and Microsoft’s freshly – discontinued Internet
The post Vanished in 60 seconds! – Chinese cyber criminals shut down Adobe Flash, Internet Explorer appeared first on Hacker News Bulletin | Find the Latest Hackers News.
Imagine having the access and control to your computer to any place in the world from your iPhone. That would be really futuristic, no? Actually, this is not because there are applications available that can let you tap into your computer from on your mobile. These remote control applications do more than simply allow you
The post Microsoft Remote Desktop Connection Manager appeared first on Hacker News Bulletin | Find the Latest Hackers News.
The hack – tivist cyber criminal group Anonymous, more often than not related with cyber campaigns in opposition to fraudulent government administrations and terrorist organizations, has now set its sights on space. They posted a video on the group’s most important You Tube channel on the 18th of March, and called on to everyone through
The post Anonymous wants to further its engagement in the exploration of space – ‘Unite as Species’ appeared first on Hacker News Bulletin | Find the Latest Hackers News.
While investigating BKS files, the path I went down led me to an interesting discovery: BKS-V1 files will accept any number of passwords to reveal information about potentially sensitive contents!
In preparation for my BSidesSF talk, I've been looking at a lot of key files. One file type that caught my interest is the Bouncy Castle BKS (version 1) file format. Like password-protected PKCS12 and JKS keystore files, BKS keystore files protect their contents from those who do not know the password. That is, a BKS file may contain only public information, such as a certificate. Or it may contain one or more private keys. But you won't know until after you use the password to unlock it.
Update March 21, 2018:
We have updated this blog post based on feedback from Thomas Pornin, and confirmation from the Bouncy Castle author. Like JKS files, BKS files do not protect the metadata of their contents by default. The keystore-level password and associated key is only used for integrity checking. By default, private keys are encrypted with the same password as the keystore. These private keys are not affected by the keystore-level weakness outlined in this blog post. That is, even if an unexpected password is accepted by a keystore itself, that same password will not be accepted to decrypt the private key contained within a keystore. Original wording in this blog post that is now understood to be inaccurate has been marked in strikeout notation for transparency.
As I investigated the first BKS file in my list, I quickly realized assumed that I could not determine what was contained in it unless I had the password. Naively searching the web for things like "bks cracker" and stopping there, I concluded that I'd need to roll my own BKS bruteforce cracker.
Update March 21, 2018:
Tools used to inspect BKS files will refuse to list the contents of the keystore if a valid password is not provided. However, this is actually not because the metadata of the keystore contents are protected. Because the metadata of the keystore contents are not encrypted, this information can be viewed without needing to use a valid password.
Using the pyjks library, I wrote a trivial script:
#!/usr/bin/env python3
import os
import sys
import jks
def trypw(bksfile, pw):
try:
keystore = jks.bks.BksKeyStore.load(bksfile, pw)
if keystore:
print('Password for %s found: "%s"' % (bksfile, pw))
sys.exit(0)
except jks.util.KeystoreSignatureException:
pass
except UnicodeDecodeError:
pass
with open(sys.argv[1]) as h:
pwlist = h.readlines()
for pw in pwlist:
trypw(sys.argv[2], pw.rstrip())
sys.exit(1)
Let's try this on the test BKS file that I have:
$ python crackbks.py strings.txt test.bks
Password for test.bks found: "Redefinir senha"
Cool. "Redefinir senha" seems like an unexpected password to me, but it's not terrible in strength. It has 15 characters, and uses mixed-case and a non-alphanumeric character (a space). Depending on the password-cracking technique used, it could hold up pretty well to bruteforce attacks.
The above proof-of-concept script is quite slow, since it will serially attempt passwords, one at a time. Taking advantage of multi-core systems in Python isn't as easy as it should be, due to the Python GIL. As a simple test, I tried using the ProcessPoolExecutor to see if I could increase my password-attempt throughput. ProcessPoolExecutor side-steps the GIL by spreading the work across multiple Python processes. Each Python process has its own GIL, but because multiple Python processes are being used, this approach should help better utilize my multiprocessor system.
Let's try this version of the brute-force cracking tool:
$ python crackbks.py strings.txt test.bks
Password for test.bks found: "Redefinir senha"
Password for test.bks found: "Activity started without extras"
Password for test.bks found: "query.is.any.user.logged.in"
Wait, what is going on here? How can a single BKS file accept multiple passwords? As it turns out, there are two things going on:
First, when I optimized my BKS bruteforce script with the use of ProcessPoolExecutor, I didn't factor in how the script would behave when it is distributed across multiple processes. In the single-threaded instance above, the script exits as soon as it finds the password. However, when it's distributed across multiple processes using ProcessPoolExecutor, things are different. I didn't have any code to explicitly terminate the parent Python process or any of the forked Python processes. The impact of this is that my multi-process BKS cracking script will continue to make attempts after it finds the password.
The other thing that is happening is related to the BKS file format, which I discuss below.
When a resource is password-protected with a single password, it is extremely unlikely that another password can also be used to unlock the resource. Consider the simple case where a collision-resistant hash function is used to verify the password: Is this password unique?
Applying a cryptographic hash function to the password results in the following hashes:
MD5 (128-bit): 18fcfa801383d10dd0a1fea051674469
SHA-1 (160-bit): c9e2ef80e5f2afb8aef0d058182cc7f59e93e025
SHA-256 (256-bit): 08a6c455079687616e997c7bfd626ae754ba1a71b229db1b3a515cfa45e9d4ea
The MD5 hash algorithm, which has a digest size of 128 bits, was shown in 1996 to be unsafe if a collision-resistant hash is required. By 2005, researchers produced a pair of PostScript documents and a pair of X.509 certificates where each pair shared the same MD5 hash. While it takes a bit of CPU processing power to find such collisions, it's feasible to do so with modern computing hardware.
The SHA-1 hash algorithm, which has a digest size of 160 bits, is more resistant to collisions than MD5. However by February 2017, the first known SHA-1 collision was produced. This attack required "the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations."
The SHA-256 hash algorithm, which has a digest size of 256 bits, is even more resistant to collisions than SHA-1. To date, no collisions have been found using the SHA-256 hashing algorithm.
My naive BKS bruteforcing script produced three different passwords for the same BKS file. Let's look at the code for handling BKS files in pyjks:
hmac_fn = hashlib.sha1
hmac_digest_size = hmac_fn().digest_size
hmac_key_size = hmac_digest_size*8 if version != 1 else hmac_digest_size
hmac_key = rfc7292.derive_key(hmac_fn, rfc7292.PURPOSE_MAC_MATERIAL, store_password, salt, iteration_count, hmac_key_size//8)
Here we can see that the HMAC function is SHA-1, which isn't bad. However, it turns out that it's the HMAC key (and its size) that is important, since that's what determines whether the correct password has been provided to unlock the BKS keystore file. If the file is a BKS version 1 file, the hmac_key_size value will be the same as hmac_digest_size.
In the case of hashlib.sha1, the digest_size is 20 bytes (160 bits). But where it gets interesting is the derivation of hmac_key. The size of hmac_key is determined by hmac_key_size//8 (integer division, dropping any remainder). In this case, it's 20//8, which is 2 bytes (16 bits). Why is there integer division by 8 at all? It's not clear, but perhaps the developer confused where bits are used and bytes are used in the code.
Let's add a debugging print() statement to the bks.py component of pyjks and test our three different passwords for the same BKS keystore:
$ python -c "import jks; keystore = jks.bks.BksKeyStore.load('test.bks', 'Redefinir senha')" hmac_key: c019
$ python -c "import jks; keystore = jks.bks.BksKeyStore.load('test.bks', 'Activity started without extras')" hmac_key: c019
$ python -c "import jks; keystore = jks.bks.BksKeyStore.load('test.bks', 'query.is.any.user.logged.in')" hmac_key: c019
Here we can see that the hmac_key value is c019 (hex) with each of the three different passwords that are provided. In each of the three cases, the BKS-V1 keystore is decrypted, despite the likelihood that not one of the three accepted passwords was the one chosen by the software developer.
Why was I accidentally able to find BKS-V1 password collisions due to my shoddy Python programming skills? The maximum entropy you get from any BKS-V1 password is only 16 bits. This is nowhere near enough bits to represent a password. When it comes to password strength, entropy can be used as a measure. If only bruteforce techniques are used, each case-sensitive Latin alphabet character adds 5.7 bits of entropy. So a randomly-chosen three-character,case-sensitive Latin alphabet password will have 17.1 bits of entropy, which already exceeds the complexity of what you can represent in 16 bits. In other words, while a developer can choose a reasonably-strong password to protect the contents integrity of a BKS-V1 file, the file format itself only supports complexity equivalent to just less than what is provided by a randomly-selected case-sensitive three-letter password.
What amount of integrity protection does a 16-bit hmac_key provide? Virtually nothing. 16 bits can only represent 65,536 different values. What this means is regardless of the password complexity the developer has chosen, a bruteforce password cracker needs to try at most 65,536 times. A high-end GPU these days can crunch through over 10 billion SHA-1 operations per second.
As it turns out John the Ripper does have BKS file support, despite what my earlier web searches turned up. While there isn't currently GPU support for cracking BKS files, a CPU is plenty fast enough. My limited testing has shown that any BKS-V1 file can be cracked in about 10 seconds or less using just a single CPU core on a modern system.
Without a doubt, BKS-V1 keystore files are insecure, due to insufficient HMAC key size. Although BKS files support password protection to protect their contents integrity, the protection supplied by version 1 of the file format is nearly zero. For these reasons, here are recommendations for developers who use Bouncy Castle:
For more details, please see CERT Vulnerability Note VU#306792.
The leadership of our consultancy Crucial Point have been working to enhance the security posture and mitigate cyber risks for over a decade, successfully operating across multiple sectors of the economy to help leaders thwart dynamic adversaries. In doing so we have found most businesses can take steps to raise defenses before calling in the experts.
The nine steps below, taken from the Crucial Point Best Cybersecurity Practices page, can help kickstart the defense of any firm.
These steps are:
Those are just the first few steps. But please put them in place! By following community best practices you can make an immediate difference in your own security posture. These are, for the most part, things you can do yourself for very little cost.
To accelerate your implementation of these best practices, or to independently verify and validate your security posture and receive detailed action plans for improvement, contact Crucial Point here and ask about our CISO-as-a-Service offering.
The post These Best Practices Will Stop 90% Of The Cyber Threat appeared first on The Cyber Threat.
Tax season is stressful enough without having to worry about becoming the victim of a cyber crime. Here are three different tax phishing scams targeting employers, individuals, and even tax preparers that are currently making the rounds.
The W-2 phishing scams that have plagued employers for a couple of years are back with a vengeance. The IRS noticed a significant uptick in these tax phishing scams beginning in January and recently issued an official warning. Also known as spear phishing or business email compromise (BEC) scams, these campaigns differ from traditional phishing scams in that they are highly targeted. They are sent to specific employees within organizations who have access to employee tax data, usually human resources personnel, and often appear to come from a company executive. Occasionally, the IRS reports, the email will request a wire transfer along with employee W-2 data.
While the hackers behind this particular scam are not seeking tax ID data, they are harnessing the stress of tax season and victims’ fear of the IRS to get them to click on phishing links. The targets are Microsoft 365 users, and Dark Reading reports that “tens of millions” may have received the emails. The messages purport to be from the IRS, warn recipients that there is some sort of problem with their taxes and that dire consequences will result if they do not take immediate action, and include attachments with names such as “taxletter.doc.” Downloading and opening the attachment installs password-stealing malware on the victim’s machine.
These highly sophisticated tax phishing scams are executed in two phases. In the first phase, hackers send traditional or spear phishing emails to tax preparers, which install malware on their computers and allow the hackers to steal client tax and bank account data.
In the second phase, the hackers use the data to file fraudulent tax returns – then have IRS refunds deposited in the victims’ bank accounts. In some cases, the return is filed using one victim’s tax data and the money deposited in another victim’s bank account. The bank account owners are then contacted by someone claiming to be an IRS representative, demanding that they take specific (and irreversible) steps to “return” the money.
There are several ways to prevent falling victim to these and other tax phishing scams. Organizations should ensure that all employees are trained to identify phishing emails, including spear phishing, have a specific and clear procedure to report suspicious emails, and take all other appropriate proactive cyber security measures. Individuals should also be aware of the warning signs of a phishing email, including text written in broken English and return addresses that appear to be off, such as a government agency with a .com address.
The IRS requests that suspected tax-related phishing emails be forwarded to phishing@irs.gov. If you receive an erroneous refund deposit to your bank account, follow the IRS’s instructions for returning it:
The cyber security experts at Lazarus Alliance have deep knowledge of the cyber security field, are continually monitoring the latest information security threats, and are committed to protecting organizations of all sizes from security breaches. Our full-service risk assessment services and Continuum GRC RegTech software will help protect your organization from data breaches, ransomware attacks, and other cyber threats.
Lazarus Alliance is proactive cyber security®. Call 1-888-896-7580 to discuss your organization’s cyber security needs and find out how we can help your organization adhere to cyber security regulations, maintain compliance, and secure your systems.
The post Tax Phishing Scams Are Back: Here Are 3 to Watch Out For appeared first on .
Healthcare data security is under attack from the inside. While insider threats – due to employee error, carelessness, or malicious intent – are a problem in every industry, they are a particular pox on healthcare data security. Two recent reports illustrate the gravity of the situation.
Verizon’s 2018 Protected Health Information Data Breach Report, which examined 1,368 healthcare data security incidents in 27 countries (heavily weighted towards the U.S.), found that:
Meanwhile, a separate survey on healthcare data security conducted by Accenture found that nearly one in five healthcare employees would be willing to sell confidential patient data to a third party, and they would do so for as little as $500 to $1,000. Even worse, nearly one-quarter reported knowing “someone in their organization who has sold their credentials or access to an unauthorized outsider.”
Healthcare data security is especially tricky because numerous care providers require immediate and unrestricted access to patient information to do their jobs. Any hiccups along the way could result in a dead or maimed patient. However, there are proactive steps healthcare organizations can take to combat insider threats:
The cyber security experts at Continuum GRC have deep knowledge of the cyber security field, are continually monitoring the latest information security threats, and are committed to protecting your organization from security breaches. Continuum GRC offers full-service and in-house risk assessment and risk management subscriptions, and we help companies all around the world sustain proactive cyber security programs.
Continuum GRC is proactive cyber security®. Call 1-888-896-6207 to discuss your organization’s cyber security needs and find out how we can help your organization protect its systems and ensure compliance.
The post Employees Are Biggest Threat to Healthcare Data Security appeared first on .
This post provides an in-depth analysis of the inner workings of Gooligan, the infamous Android OAuth stealing botnet.
This is the second post of a series dedicated to the hunt and takedown of Gooligan that we did at Google, in collaboration with Check Point, in November 2016. The first post recounts Gooligan’s origin story and provides an overview of how it works. The final post discusses Gooligan’s various monetization schemas and its take down. As this post builds on the previous one , I encourage you to read it, if you haven’t done so already.
This series of posts is modeled after the talk I gave at Botconf in December 2017. Here is a re-recording of the talk:
You can also get the slides here but they are pretty bare.
Initially, users are tricked into installing Gooligan’s staging app on their device under one false pretense or another. Once this app is executed, it will fully compromise the device by performing the five steps outlined in the diagram below:
As emphasized in the chart above, the first four stages are mostly borrowed from Ghost Push . Gooligan authors main addition is the code needed to instrument the Play Store app using a complex injection process. This heavy code reuse initially made it difficult for us to separate Ghost Push samples from Gooligan ones. However, as soon as we had the full kill chain analyzed, we were able to write accurate detection signatures.
Most Gooligan samples hide their malicious payload in a fake image located in assets/close.png. This file is encrypted with a hardcoded [XOR encryption] function. This encryption is used to escape the signatures that detect the code that Gooligan borrows from previous malware. Encrypting malicious payload is a very old malware trick that has been used by Android malware since at least 2011.
Besides its encryption function, one of the most prominent Gooligan quirks is its weird (and poor) integrity verification algorithm. Basically, the integrity of the close.png file is checked by ensuring that the first ten bytes match the last ten. As illustrated in the diagram above, the oddest part of this schema is that the first five bytes (val 1) are compared with the last five, while bytes six through ten (val 2) are compared with the first five.
As alluded to earlier, Gooligan, like Snappea and Ghostpush, weaponizes the Kingroot exploit kit to gain root access. Kingroot operates in three stages: First, the malware gathers information about the phone that are sent to the exploit server. Next, the server looks up its database of exploits (which only affect Android 3.x and 4.x) and builds a payload tailored for the device. Finally, upon payload reception, the malware runs the payload to gain root access.
The weaponization of known exploits by cyber-criminals who lack exploit development capacity (or don't want to invest into it) is as old as crimeware itself. For example, DroidDream exploited Exploid and RageAgainstTheCage back in 2011. This pattern is common across every platform. For example, recently NSA-leaked exploit Eternal Blue was weaponized by the fake ransomware NoPetya. If you are interested in ransomware actors, check my posts on the subject.
Upon rooting the device, Gooligan patches the install-recovery.sh script to ensure that it will survive a factory reset. This resilience mechanism was the most problematic aspect of Gooligan, from a remediation perspective, because for the oldest devices, it only left us with OTA (over the air) update and device re-flashing as a way to remove it. This situation was due to the fact that very old devices don't have verified boot , as it was introduced in Android 4.4.
This difficult context, combined with the urgent need to help our users, led us to resort to a strategy that we rarely use: a coordinated takedown. The goal of this takedown was to disable key elements of the Gooligan infrastructure in a way that would ensure that the malware would be unable to work or update. As discussed in depth at the end of the post, we were able to isolate and take down Gooligan’s core server in less than a week thanks to a wide cross-industry effort. In particular, Kjell from the NorCert worked around the clock with us during the Thanksgiving holidays (thanks for all the help, Kjell!).
The final step of the infection is the injection of a shared library into the Play store app. This shared library allows Gooligan to manipulate the Play store app to download apps and inject review.
We traced the injection code back to publicly shared code . The library itself is very bare: the authors added only the code needed to call Play store functions. All the fraud logic is in the main app, probably because the authors are more familiar with Java than C.
Looking at the set of devices infected during the takedown revealed that most of the affected devices were from India, Latin America, and Asia, as visible in the map above. 19% of the infections were from India, and the top eight countries affected by Gooligan accounted for more than 50% of the infections.
In term of devices, as shown in the barchart above, the infections are spread across all the big brands, with Samsung and Micromax being unsurprisingly the most affected given their market share. Micromax is the leading Indian phone maker, which is not very well known in the U.S. and Europe because it has no presence there. It started manufacturing Android One devices in 2014 and is selling in quite a few countries besides India, most notably Russia.
Buried deep inside Gooligan patient zero code, Check Point researchers Andrey Polkovnichenko , Yoav Flint Rosenfeld , and Feixiang He , who worked with us during the escalation, found the very unusual text string oversea_adjust_read_redis. This string led to the discovery of a Chinese blog post discussing load balancer configuration, which in turn led to the full configuration file of Gooligan backend services.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#Ads API
acl is_ads path_beg /overseaads/
use_backend overseaads if is_ads
…
#Payment API
acl is_paystatis path_beg /overseapay/admin/
use_backend overseapaystatis if is_paystatis
...
# Play install
acl is_appstore path_beg /appstore/
use_backend overseapaystatis if is_appstore
...
Analyzing the exposed HAproxy configuration allowed us to pinpoint where the infrastructure was located and how the backend services were structured. As shown in the annotated configuration snippet above, the backend had API for click fraud, receiving payment from clients, and Play store abuse. While not visible above, there was also a complex admin and statistic-related API.
Combining the API endpoints and IPs exposed in the HAproxy configuration with our knowledge of Gooligan binary allowed us to reconstruct the infrastructure charted above. Overall, Gooligan was split into two main data centers: one in China and one overseas in the US, which was using Amazon AWS IPs. After the takedown, all the infrastructure ended up moving back to China.
Note: in the above diagram, the Fraud end-point appears twice. This is not a mistake: at Gooligan peak, its authors splited it out to sustain the load and better distribute the requests.
So, who is behind Gooligan? Based on this infrastructure analysis and other data, we strongly believe that it is a group operating from mainland China. Publicly, the group claims to be a marketing company, while under the hood it is mostly focused on running various fraudulent schema. The apparent authenticity of its front explains why some reputable companies ended up being scammed by this group. Bottom line: be careful who you buy ads or install from: If it is too good to be true...
In the final post of the serie, I discusses Gooligan various monetization schemas and its takedown. See you there!
Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about Gooligan.
To get notified when my next post is online, follow me on Twitter , Facebook , Google+ , or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .
A bientôt!
On Thursday, the U.S. government imposed sanctions against five entities and 19 individuals for their role in “destabilizing activities” ranging from interfering in the 2016 U.S. presidential election to carrying out destructive cyber-attacks such as NotPetya, an event that the Treasury department said is the most destructive and costly cyber-attack in history.
“These targeted sanctions are a part of a broader effort to address the ongoing nefarious attacks emanating from Russia,” said Treasury Secretary Steven T. Mnuchin in a press release. “Treasury intends to impose additional CAATSA [Countering America’s Adversaries Through Sanctions Act] sanctions, informed by our intelligence community, to hold Russian government officials and oligarchs accountable for their destabilizing activities by severing their access to the U.S. financial system.”
Nine of the 24 entities and individuals named on Thursday had already received previous sanctions from either President Obama or President Trump for unrelated reasons, The New York Times reported.
In addition to the sanctions, the Department of Homeland Security and the FBI issued a joint alert warning that the Russian government is targeting government entities as well as organizations in the energy, nuclear, commercial facilities, water, aviation, and critical manufacturing sectors.
According to the alert, Russian government cyber actors targeted small commercial facilities’ networks with a multi-stage intrusion campaign that staged malware, conducted spear phishing attacks, and gained remote access into energy sector networks. The actors then used their access to conduct network reconnaissance, move laterally, and collect information pertaining to Industrial Control Systems.
Other trending cybercrime events from the week include:
SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of the top trending targets are shown in the chart below.
Two of the largest data breaches of recent memory were back in the news this week due to Mossack Fonseca announcing that it is shutting down following the fallout from the Panama Papers breach as well as a former Equifax employee being charged with insider trading related to its massive breach.
Documents stolen from the Panamanian law firm Mossack Fonseca and leaked to the media in April 2016 were at the center of the scandal known as the Panama Papers, which largely revealed how rich individuals around the world were able to evade taxes in various countries.
“The reputational deterioration, the media campaign, the financial circus and the unusual actions by certain Panamanian authorities, have occasioned an irreversible damage that necessitates the obligatory ceasing of public operations at the end of the current month,” Mossack Fonseca wrote in a statement.
While Mossack Fonseca’s data breach appears to have finally led to the organization shutting down, Equifax’s massive breach announcement in September 2017 has since sparked a variety of regulatory questions, as well as criticism of the company’s leadership and allegations of insider trading.
Last week the SEC officially filed a complaint that alleges that Jun Ying, who was next in line to be the company’s global CIO, conducted insider trading by using confidential information entrusted to him by the company to conclude Equifax had suffered a serious breach, and Ying then exercised all of his vested Equifax stock options and sold the shares in the days before the breach was publicly disclosed.
“According to the complaint, by selling before public disclosure of the data breach, Ying avoided more than $117,000 in losses,” the SEC wrote in a press release.
Ying also faces criminal charges from the U.S. Attorney’s Office for the Northern District of Georgia.
This week, Patrick Laverty of Rapid7 joins us for an interview! Dick Wilkins of Phoenix Technologies joins us for our second feature interview! In the news, we have updates from Flash, Pwn2Own, VMware, and more on this episode of Paul's Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/Episode551
Visit https://www.securityweekly.com/psw for all the latest episodes!
About a week ago, a Tweet I was mentioned in received a dozen or so “likes” over a very short time period (about two minutes). I happened to be on my computer at the time, and quickly took a look at the accounts that generated those likes. They all followed a similar pattern. Here’s an example of one of the accounts’ profiles:
This particular avatar was very commonly used as a profile picture in these accounts.
All of the accounts I checked contained similar phrases in their description fields. Here’s a list of common phrases I identified:
All of the accounts also contained links to URLs in their description field that pointed to domains such as the following:
It turns out these are all shortened URLs, and the service behind each of them has the exact same landing page:
“I will ban drugs, spam, porn, etc.” Yeah, right.
My colleague, Sean, checked a few of the links and found that they landed on “adult dating” sites. Using a VPN to change the browser’s exit node, he noticed that the landing pages varied slightly by region. In Finland, the links ended up on a site called “Dirty Tinder”.
Checking further, I noticed that some of the accounts either followed, or were being followed by other accounts with similar traits, so I decided to write a script to programmatically “crawl” this network, in order to see how large it is.
The script I wrote was rather simple. It was seeded with the dozen or so accounts that I originally witnessed, and was designed to iterate friends and followers for each user, looking for other accounts displaying similar traits. Whenever a new account was discovered, it was added to the query list, and the process continued. Of course, due to Twitter API rate limit restrictions, the whole crawler loop was throttled so as to not perform more queries than the API allowed for, and hence crawling the network took quite some time.
My script recorded a graph of which accounts were following/followed by which other accounts. After a few hours I checked the output and discovered an interesting pattern:
Graph of follower/following relationships between identified accounts after about a day of running the discovery script.
The discovered accounts seemed to be forming independent “clusters” (through follow/friend relationships). This is not what you’d expect from a normal social interaction graph.
After running for several days the script had queried about 3000 accounts, and discovered a little over 22,000 accounts with similar traits. I stopped it there. Here’s a graph of the resulting network.
Pretty much the same pattern I’d seen after one day of crawling still existed after one week. Just a few of the clusters weren’t “flower” shaped. Here’s a few zooms of the graph.
Since I’d originally noticed several of these accounts liking the same tweet over a short period of time, I decided to check if the accounts in these clusters had anything in common. I started by checking this one:
Oddly enough, there were absolutely no similarities between these accounts. They were all created at very different times and all Tweeted/liked different things at different times. I checked a few other clusters and obtained similar results.
One interesting thing I found was that the accounts were created over a very long time period. Some of the accounts discovered were over eight years old. Here’s a breakdown of the account ages:
As you can see, this group has less new accounts in it than older ones. That big spike in the middle of the chart represents accounts that are about six years old. One reason why there are fewer new accounts in this network is because Twitter’s automation seems to be able to flag behaviors or patterns in fresh accounts and automatically restrict or suspend them. In fact, while my crawler was running, many of the accounts on the graphs above were restricted or suspended.
Here are a few more breakdowns – Tweets published, likes, followers and following.
Here’s a collage of some of the profile pictures found. I modified a python script to generate this – far better than using one of those “free” collage making tools available on the Internets. 
So what are these accounts doing? For the most part, it seems they’re simply trying to advertise the “adult dating” sites linked in the account profiles. They do this by liking, retweeting, and following random Twitter accounts at random times, fishing for clicks. I did find one that had been helping to sell stuff:
Individually the accounts probably don’t break any of Twitter’s terms of service. However, all of these accounts are likely controlled by a single entity. This network of accounts seems quite benign, but in theory, it could be quickly repurposed for other tasks including “Twitter marketing” (paid services to pad an account’s followers or engagement), or to amplify specific messages.
If you’re interested, I’ve saved a list of both screen_name and id_str for each discovered account here. You can also find the scraps of code I used while performing this research in that same github repo.
This week, Rami Essaid, Founder of Distil Networks joins us for an interview! In the news, we have updates from CyberArk, Tenable, Fortinet, & Rapid7! Our very own Michael Santarcangelo is joined by Matt Alderman on this episode of Enterprise Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ES_Episode83
Visit https://www.securityweekly.com/esw for all the latest episodes!
Since early 2018, FireEye (including our FireEye as a Service (FaaS), Mandiant Consulting, and iSIGHT Intelligence teams) has been tracking an ongoing wave of intrusions targeting engineering and maritime entities, especially those connected to South China Sea issues. The campaign is linked to a group of suspected Chinese cyber espionage actors we have tracked since 2013, dubbed TEMP.Periscope. The group has also been reported as “Leviathan” by other security firms.
The current campaign is a sharp escalation of detected activity since summer 2017. Like multiple other Chinese cyber espionage actors, TEMP.Periscope has recently re-emerged and has been observed conducting operations with a revised toolkit. Known targets of this group have been involved in the maritime industry, as well as engineering-focused entities, and include research institutes, academic organizations, and private firms in the United States. FireEye products have robust detection for the malware used in this campaign.
Active since at least 2013, TEMP.Periscope has primarily focused on maritime-related targets across multiple verticals, including engineering firms, shipping and transportation, manufacturing, defense, government offices, and research universities. However, the group has also targeted professional/consulting services, high-tech industry, healthcare, and media/publishing. Identified victims were mostly found in the United States, although organizations in Europe and at least one in Hong Kong have also been affected. TEMP.Periscope overlaps in targeting, as well as tactics, techniques, and procedures (TTPs), with TEMP.Jumper, a group that also overlaps significantly with public reporting on “NanHaiShu.”
In their recent spike in activity, TEMP.Periscope has leveraged a relatively large library of malware shared with multiple other suspected Chinese groups. These tools include:
The following are tools that TEMP.Periscope has leveraged in past operations and could use again, though these have not been seen in the current wave of activity:
Additional identifying TTPs include:
The current wave of identified intrusions is consistent with TEMP.Periscope and likely reflects a concerted effort to target sectors that may yield information that could provide an economic advantage, research and development data, intellectual property, or an edge in commercial negotiations.
As we continue to investigate this activity, we may identify additional data leading to greater analytical confidence linking the operation to TEMP.Periscope or other known threat actors, as well as previously unknown campaigns.
File | Hash | Description |
x.js | 3fefa55daeb167931975c22df3eca20a | HOMEFRY, a 64-bit Windows password dumper/cracker |
mt.exe | 40528e368d323db0ac5c3f5e1efe4889 | MURKYTOP, a command-line reconnaissance tool |
com4.js | a68bf5fce22e7f1d6f999b7a580ae477 | AIRBREAK, a JavaScript-based backdoor which retrieves commands from hidden strings in compromised webpages |
File | Hash | Description |
green.ddd | 3eb6f85ac046a96204096ab65bbd3e7e | AIRBREAK, a JavaScript-based backdoor which retrieves commands from hidden strings in compromised webpages |
BGij | 6e843ef4856336fe3ef4ed27a4c792b1 | Beacon, a commercially available backdoor |
msresamn.ttf | a9e7539c1ebe857bae6efceefaa9dd16 | PHOTO, also reported as Derusbi |
1024-aa6a121f98330df2edee6c4391df21ff43a33604 | bd9e4c82bf12c4e7a58221fc52fed705 | BADFLICK, backdoor that is capable of modifying the file system, generating a reverse shell, and modifying its command-and-control configuration |
This week, Michael and Paul interview Futurist Thornton May, and CSO of Cisco Systems, Inc., Edna Conway! Then the articles of discussion and tracking security innovation! All that and more, on this episode of Business Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/BSWEpisode77
Visit https://www.securityweekly.com/bsw for all the latest episodes!
From January 2018 to March 2018, through FireEye’s Dynamic Threat Intelligence, we observed attackers leveraging the latest code execution and persistence techniques to distribute malicious macro-based documents to individuals in Asia and the Middle East.
We attribute this activity to TEMP.Zagros (reported by Palo Alto Networks and Trend Micro as MuddyWater), an Iran-nexus actor that has been active since at least May 2017. This actor has engaged in prolific spear phishing of government and defense entities in Central and Southwest Asia. The spear phishing emails and attached malicious macro documents typically have geopolitical themes. When successfully executed, the malicious documents install a backdoor we track as POWERSTATS.
One of the more interesting observations during the analysis of these files was the re-use of the latest AppLocker bypass, and lateral movement techniques for the purpose of indirect code execution. The IP address in the lateral movement techniques was substituted with the local machine IP address to achieve code execution on the system.
In this campaign, the threat actor’s tactics, techniques and procedures (TTPs) shifted after about a month, as did their targets. A brief timeline of this activity is shown in Figure 1.
Figure 1: Timeline of this recently
observed spear phishing campaign
The first part of the campaign (From Jan. 23, 2018, to Feb. 26, 2018) used a macro-based document that dropped a VBS file and an INI file. The INI file contains the Base64 encoded PowerShell command, which will be decoded and executed by PowerShell using the command line generated by the VBS file on execution using WScript.exe. The process chain is shown in Figure 2.
Figure 2: Process chain for the first
part of the campaign
Although the actual VBS script changed from sample to sample, with different levels of obfuscation and different ways of invoking the next stage of process tree, its final purpose remained same: invoking PowerShell to decode the Base64 encoded PowerShell command in the INI file that was dropped earlier by the macro, and executing it. One such example of the VBS invoking PowerShell via MSHTA is shown in Figure 3.
Figure 3: VBS invoking PowerShell via MSHTA
The second part of the campaign (from Feb. 27, 2018, to March 5, 2018) used a new variant of the macro that does not use VBS for PowerShell code execution. Instead, it uses one of the recently disclosed code execution techniques leveraging INF and SCT files, which we will go on to explain later in the blog.
We believe the infection vector for all of the attacks involved in this campaign are macro-based documents sent as an email attachment. One such email that we were able to obtain was targeting users in Turkey, as shown in Figure 4:
Figure 4: Sample spear phishing email
containing macro-based document attachment
The malicious Microsoft Office attachments that we observed appear to have been specially crafted for individuals in four countries: Turkey, Pakistan, Tajikistan and India. What follows is four examples, and a complete list is available in the Indicators of Compromise section at the end of the blog.
Figure 5 shows a document purporting to be from the National Assembly of Pakistan.
Figure 5: Document purporting to be from
the National Assembly of Pakistan
A document purporting to be from the Turkish Armed Forces, with content written in the Turkish language, is shown in Figure 6.
Figure 6: Document purporting to be from
the Turkish Armed Forces
A document purporting to be from the Institute for Development and Research in Banking Technology (established by the Reserve Bank of India) is shown in Figure 7.
Figure 7: Document purporting to be from
the Institute for Development and Research in Banking Technology
Figure 8 shows a document written in Tajik that purports to be from the Ministry of Internal Affairs of the Republic of Tajikistan.
Figure 8: Document written in Tajik that
purports to be from the Ministry of Internal Affairs of the Republic
of Tajikistan
Each of these macro-based documents used similar techniques for code execution, persistence and communication with the command and control (C2) server.
This scriptlet code execution technique leveraging INF and SCT files was recently discovered and documented in February 2018. The threat group in this recently observed campaign – TEMP.Zagros – weaponized their malware using the following techniques.
The macro in the Word document drops three files in a hard coded path: C:\programdata. Since the path is hard coded, the execution will only be observed in operating systems, Windows 7 and above. The following are the three files:
After dropping the three files, the macro will set the following registry key to achieve persistence:
\REGISTRY\USER\SID\Software\Microsoft\Windows\CurrentVersio
n\Run\"WindowsDefenderUpdater" = cmstp.exe /s c:\programdata\DefenderService.inf
Upon system restart, cmstp.exe will be used to execute the SCT file indirectly through the INF file. This is possible because inside the INF file we have the following section:
[UnRegisterOCXSection]
%11%\scrobj.dll,NI,c:/programdata/Defender.sct
That section gets indirectly invoked through the DefaultInstall_SingleUser section of INF, as shown in Figure 9.
Figure 9: Indirectly invoking SCT through
the DefaultInstall_SingleUser section of INF
This method of code execution is performed in an attempt to evade security products. FireEye MVX and HX Endpoint Security technology successfully detect this code execution technique.
The code of the Defender.sct file is an obfuscated JavaScript. The main function performed by the SCT file is to Base64 decode the contents of WindowsDefender.ini file and execute the decoded PowerShell Script using the following command line:
powershell.exe -exec Bypass -c iex([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((get-content C:\\ProgramData\\WindowsDefender.ini)
The rest of the malicious activities are performed by the PowerShell Script.
The PowerShell script employs several layers of obfuscation to hide its actual functionality. In addition to obfuscation techniques, it also has the ability to detect security tools on the analysis machine, and can also shut down the system if it detects the presence of such tools.
Some of the key obfuscation techniques used are:
Figure 10: Character replacement and
string reversing techniques
Figure 11: PowerShell script is XOR
encoded using a single byte key
After deobfuscating the contents of the PowerShell Script, we can divide it into three sections.
The first section of the PowerShell script is responsible for setting different key variables that are used by the remaining sections of the PowerShell script, especially the following variables:
Among those variables, there is one variable of particular interest, DrAGon_MidDLe, which stores the list of proxy URLs (detailed at the end of the blog in the Network Indicators portion of the Indicators of Compromise section) that will be used to interact with the C2 server, as shown in Figure 12.
Figure 12: DrAGon_MidDLe stores the list
of proxy URLs used to interact with C2 server
The second section of the PowerShell script has the ability to perform encryption and decryption of messages that are exchanged between the system and the C2 server. The algorithm used for encryption and decryption is RSA, which leverages the public and private key exponents included in Section 1 of the PowerShell script.
The third section of the PowerShell script is the biggest section and has a wide variety of functionalities.
During analysis, we observed a code section where a message written in Chinese and hard coded in the script will be printed in the case of an error while connecting to the C2 server:
The English translation for this message is: “Cannot connect to website, please wait for dragon”.
Other functionalities provided by this section of the PowerShell Script are as follows:
All of this data is concatenated and formatted as shown in Figure 13:
Figure 13: Concatenated and formatted
data retrieved by PowerShell script
While sending to the C2 server, the data is formatted as follows:
@{SYSINFO = $get.ToString(); ACTION = "REGISTER";}
Figure 14: System shut down upon
discovery of security tools
Figure 15: Disabling Microsoft Office
Protected View
Figure 16: Reboot, shut down and clean commands
The following table summarizes the main C2 commands supported by this PowerShell Script.
C2 Command | Purpose |
reboot | Reboot the system using shutdown command |
shutdown | Shut down the system using shutdown command |
clean | Wipe the Drives, C:\, D:\, E:\, F:\ |
screenshot | Take a screenshot of the System |
upload | Encrypt and upload the information from the system |
excel | Leverage Excel.Application COM object for code execution |
outlook | Leverage Outlook.Application COM object for code execution |
risk | Leverage DCOM object for code execution |
This activity shows us that TEMP.Zagros stays up-to-date with the latest code execution and persistence mechanism techniques, and that they can quickly leverage these techniques to update their malware. By combining multiple layers of obfuscation, they deter the process of reverse engineering and also attempt to evade security products.
Users can protect themselves from such attacks by disabling Office macros in their settings and also by being more vigilant when enabling macros (especially when prompted) in documents, even if such documents are from seemingly trusted sources.
SHA256 Hash | Filename | Targeted Region |
eff78c23790ee834f773569b52cddb01dc3c4dd9660f5a476af044ef6fe73894 | na.doc
| Pakistan |
76e9988dad0278998861717c774227bf94112db548946ef617bfaa262cb5e338 | Invest in Turkey.doc | Turkey |
6edc067fc2301d7a972a654b3a07398d9c8cbe7bb38d1165b80ba4a13805e5ac | güvenlik yönergesi. .doc | Turkey |
009cc0f34f60467552ef79c3892c501043c972be55fe936efb30584975d45ec0 | idrbt.doc
| India |
18479a93fc2d5acd7d71d596f27a5834b2b236b44219bb08f6ca06cf760b74f6 | Türkiye Cumhuriyeti Kimlik Kartı.doc | Turkey |
3da24cd3af9a383b731ce178b03c68a813ab30f4c7c8dfbc823a32816b9406fb | Turkish Armed Forces.doc
| Turkey |
9038ba1b7991ff38b802f28c0e006d12d466a8e374d2f2a83a039aabcbe76f5c | na.gov.pk.doc
| Pakistan |
3b1d8dcbc8072b1ec10f5300c3ea9bb20db71bd8fa443d97332790b74584a115 | MVD-FORM-1800.doc |
Tajikistan |
cee801b7a901eb69cd166325ed3770daffcd9edd8113a961a94c8b9ddf318c88 | KEGM-CyberAttack.doc | Turkey |
1ee9649a2f9b2c8e0df318519e2f8b4641fd790a118445d7a0c0b3c02b1ba942 | IL-1801.doc | Turkey |
aa60c1fae6a0ef3b9863f710e46f0a7407cf0feffa240b9a4661a4e8884ac627 | kiyiemniyeti.doc |
Turkey |
93745a6605a77f149471b41bd9027390c91373558f62058a7333eb72a26faf84 | TCELL-S1-M.doc | Tajikistan |
c87799cce6d65158da97aa31a5160a0a6b6dd5a89dea312604cc66ed5e976cc9 | egm-1.doc | Turkey |
2cea0b740f338c513a6390e7951ff3371f44c7c928abf14675b49358a03a5d13 | Connectel .pk.doc |
Pakistan |
18cf5795c2208d330bd297c18445a9e25238dd7f28a1a6ef55e2a9239f5748cd | gßvenlik_yÜnergesi_.doc | Turkey |
153117aa54492ca955b540ac0a8c21c1be98e9f7dd8636a36d73581ec1ddcf58 | MIT.doc | Turkey |
d07d4e71927cab4f251bcc216f560674c5fb783add9c9f956d3fc457153be025 | Gvenlik Ynergesi.doc | Turkey |
af5f102f0597db9f5e98068724e31d68b8f7c23baeea536790c50db587421102 | Gvenlik Ynergesi.doc | Turkey |
5550615affe077ddf66954edf132824e4f1fe16b3228e087942b0cad0721a6af | NA | Turkey |
3d96811de7419a8c090a671d001a85f2b1875243e5b38e6f927d9877d0ff9b0c | Anadolu Güneydoğu Projesinde .doc | Turkey |
hxxp://alessandrofoglino[.]com//db_template.php
hxxp://www.easy-home-sales[.]co.za//db_template.php
hxxp://www.almaarefut[.]com/admin/db_template.php
hxxp://chinamall[.]co.za//db_template.php
hxxp://amesoulcoaching[.]com//db_template.php
hxxp://www.antigonisworld[.]com/wp-includes/db_template.php
hxxps://anbinni.ba/wp-admin/db_template.php
hxxp://arctistrade[.]de/wp/db_template.php
hxxp://aianalytics[.]ie//db_template.php
hxxp://www.gilforsenate[.]com//db_template.php
hxxp://mgamule[.]co.za/oldweb/db_template.php
hxxp://chrisdejager-attorneys[.]co.za//db_template.php
hxxp://alfredocifuentes[.]com//db_template.php
hxxp://alxcorp[.]com//db_template.php
hxxps://www.aircafe24[.]com//db_template.php
hxxp://agencereferencement.be/wp-admin/db_template.php
hxxp://americanlegacies[.]org/webthed_ftw/db_template.php
hxxps://aloefly[.]net//db_template.php
hxxp://www.duotonedigital[.]co.za//db_template.php
hxxp://architectsinc[.]net//db_template.php
hxxp://www.tanati[.]co.za//db_template.php
hxxp://emware[.]co.za//db_template.php
hxxp://breastfeedingbra[.]co.za//db_template.php
hxxp://alhidayahfoundation[.]co[.]uk/category/db_template.php
hxxp://cashforyousa[.]co.za//db_template.php
hxxps://www.airporttaxi-uk[.]co[.]uk/wp-includes/db_template.php
hxxp://antjetaubert[.]de//db_template.php
hxxp://hesterwebber[.]co.za//db_template.php
hxxp://fickstarelectrical[.]co.za//db_template.php
hxxp://alex-frost[.]com/assets/db_template.php
hxxps://americanbrasil[.]com.br//db_template.php
hxxps://aileeshop[.]com//db_template.php
hxxps://annodle[.]com//db_template.php
hxxp://goldeninstitute[.]co.za/contents/db_template.php
hxxp://ednpk[.]com//db_template.php
hxxp://www.arabiccasinochoice[.]com//db_template.php
hxxp://proeventsports[.]co.za//db_template.php
hxxp://glenbridge[.]co.za//db_template.php
hxxp://berped[.]co.za//db_template.php
hxxp://best-digital-slr-cameras[.]com//db_template.php
hxxp://antonhirvonen[.]com/pengalandet.se/wp-includes/db_template.php
hxxp://www.alpacal[.]com//db_template.php
hxxps://www.alakml[.]com/wp-admin/db_template.php
hxxp://ar-rihla[.]com//db_template.php
hxxp://appsvoice[.]info//db_template.php
hxxp://www.bashancorp[.]co.za//db_template.php
hxxp://alexanderbecker[.]net/services/db_template.php
hxxp://visionclinic.co.ls/visionclinic/db_template.php
hxxps://www.angelesrevista[.]com//db_template.php
hxxps://www.antojoentucocina[.]com//db_template.php
hxxp://apollonweb[.]com//db_template.php
hxxps://www.alphapixa[.]com//db_template.php
hxxp://capitalradiopetition[.]co.za//db_template.php
hxxp://www.generictoners[.]co.za//db_template.php
hxxps://alnahdatraining[.]com//db_template.php
hxxps://albousala[.]com//db_template.php
hxxps://www.dopetroleum[.]com//db_template.php
hxxp://bios-chip[.]co.za//db_template.php
hxxp://www.crissamconsulting[.]co.za//db_template.php
hxxp://capriflower[.]co.za//db_template.php
hxxp://www.dingaanassociates[.]co.za//db_template.php
hxxp://indiba-africa[.]co.za//db_template.php
hxxp://verifiedseller[.]co.za/js/db_template.php
hxxps://www.buraqlubricant[.]com//db_template.php
hxxp://aqarco[.]com/wp-admin/db_template.php
hxxp://allaboutblockchain[.]net//db_template.php
hxxp://www.amexcars[.]info/tpl/db_template.php
hxxp://clandecor[.]co.za/rvsUtf8Backup/db_template.php
hxxp://bakron[.]co.za//db_template.php
hxxp://gsnconsulting[.]co.za//db_template.php
hxxp://vumavaluations[.]co.za//db_template.php
hxxp://heritagetravelmw[.]com//db_template.php
hxxp://ampvita[.]com//db_template.php
hxxp://ahero-resource-center[.]org/administrator/db_template.php
hxxps://arbulario[.]com//db_template.php
hxxp://havilahglo[.]co.za/wpscripts/db_template.php
hxxp://www.bestdecorativemirrors[.]com/More-Mirrors/db_template.php
hxxp://delectronics[.]com[.]pk//db_template.php
hxxp://antucomp[.]com//db_template.php
hxxp://advocatetn[.]com/font-awesome/fonts/db_template.php
hxxps://amooy[.]com/webservice/db_template.php
hxxp://www.harmonyguesthouse[.]co.za//db_template.php
hxxp://alanrori[.]com//db_template.php
hxxp://algarvesup[.]com//db_template.php
hxxp://desirablehair[.]co.za//db_template.php
hxxp://comsip[.]org.mw//db_template.php
hxxp://jdcorporate[.]co.za/catalog/db_template.php
hxxp://andrewfinnburhoe[.]com//db_template.php
hxxp://anyeva[.]com/wp-includes/db_template.php
hxxp://www.agenceuhd[.]com//db_template.php
hxxp://host4unix[.]net/host24new/db_template.php
hxxp://www.altaica[.]ca/wordpress/db_template.php
hxxp://www.allbuyer[.]co[.]uk//db_template.php
hxxp://jvpsfunerals[.]co.za//db_template.php
hxxp://immaculatepainters[.]co.za//db_template.php
hxxp://tcpbereka[.]co.za/js/db_template.php
hxxp://clientcare.co.ls//db_template.php
hxxp://investaholdings[.]co.za/htc/db_template.php
hxxp://www.amjobs[.]co[.]uk//db_template.php
hxxp://www.agirlgonewine[.]com/store/db_template.php
hxxp://findinfo-more[.]com//db_template.php
hxxp://asgen[.]org//db_template.php
hxxp://alphasalesrecruitment[.]com//db_template.php
hxxp://irshadfoundation[.]co.za//db_template.php
hxxp://analternatif[.]com/includes/db_template.php
hxxp://arbruisseau[.]com/profiles/db_template.php
hxxp://ladiescircle[.]co.za//db_template.php
hxxp://all-reseller[.]com/zzz_backup/db_template.php
hxxp://alcatrazmoon[.]com/images/db_template.php
hxxp://www.alcalumni[.]com/wp-includes/db_template.php
hxxp://aniljoseph[.]com/servermon/db_template.php
hxxp://alwake3press[.]com/wp-includes/db_template.php
hxxp://www.hfhl[.]org.ls/habitat/db_template.php
hxxp://alcafricanos[.]com/slsmonographs/db_template.php
hxxps://agapeencounter[.]org//db_template.php
hxxp://apobiomedix[.]ca//db_template.php
hxxp://anythinglah[.]info//db_template.php
hxxp://aniroleplay[.]net//db_template.php
hxxp://www.allcopytoners[.]com//db_template.php
hxxp://alphaobring[.]com//db_template.php
hxxp://www.galwayprimary[.]co.za//db_template.php
hxxp://alnuzha[.]org/en/db_template.php
hxxps://ancient-wisdoms[.]com//db_template.php
hxxp://amazingenergysavings[.]net//db_template.php
hxxp://gvs[.]com[.]pk/font-awesome/db_template.php
hxxp://geetransfers[.]co.za/font-awesome/db_template.php
hxxp://carlagrobler[.]co.za/components/db_template.php
hxxp://amazingashwini[.]com//db_template.php
hxxp://aminearserver[.]es//db_template.php
hxxp://lensofafrica[.]co.za//db_template.php
hxxp://greenacrestf[.]co.za/video/db_template.php
hxxp://www.tonaro[.]co.za//db_template.php
hxxp://alephit2[.]biz/kitzz/db_template.php
hxxp://lppaportal[.]org.ls//db_template.php
hxxp://alkousy[.]com//db_template.php
hxxp://ambulatorioveterinariocalusco[.]com/img/common/db_template.php
hxxp://fragranceoil[.]co.za//db_template.php
hxxp://www.eloquent[.]co.za/nweb2/db_template.php
hxxp://chrishanicdc[.]org/wpimages/db_template.php
hxxp://ahc.me[.]uk//db_template.php
hxxp://www.britishasia-equip[.]co[.]uk//db_template.php
hxxp://always-beauty[.]ch//db_template.php
hxxps://www.ancamamara[.]com/wp-admin/db_template.php
hxxp://entracorntrading[.]co.za//db_template.php
hxxp://www.alexjeffersonconsulting[.]com/wp-includes/db_template.php
hxxp://americabr[.]com.br//db_template.php
hxxp://andrew-snyder[.]net/bootstrap/db_template.php
hxxp://signsoftime[.]co.za//db_template.php
hxxp://aperta-armis[.]org//db_template.php
hxxp://absfinancialplanning[.]co.za/images/db_template.php
hxxp://charispaarl[.]co.za//db_template.php
hxxp://indlovusecurity[.]co.za//db_template.php
hxxp://alcafricandatalab[.]com//db_template.php
hxxp://amor-clubhotels[.]com//db_template.php
hxxp://mokorotlocorporate[.]com//db_template.php
hxxp://apppriori[.]com//db_template.php
hxxp://luxconprojects[.]co.za//db_template.php
hxxp://androidphonetips[.]com/wp-includes/db_template.php
hxxp://angel-seeds[.]com.ua/catalog/db_template.php
hxxp://alissanicolai[.]com/assets/db_template.php
hxxps://www.amateurastronomy[.]org//db_template.php
hxxp://aiofotoevideo[.]com//db_template.php
hxxp://www.amika.hr//db_template.php
hxxp://comfortex[.]co.za/php/db_template.php
hxxp://deepgraphics[.]co.za//db_template.php
hxxps://agiledepot[.]com//db_template.php
hxxp://almatours[.]gr//db_template.php
hxxp://analystcnwang[.]com//db_template.php
hxxp://www.malboer[.]co.za/trendy1/db_template.php
hxxp://sefikengfarm.co.ls//db_template.php
hxxp://www.antirughenaturale[.]com/wp-admin/db_template.php
hxxp://passright[.]co.za//db_template.php
hxxp://seismicfactory[.]co.za//db_template.php
hxxp://alessandroalessandrini[.]it//db_template.php
hxxps://aquabsafe[.]com//db_template.php
hxxp://amatikulutours[.]com/tmp/db_template.php
hxxp://ganitis[.]gr//db_template.php
hxxp://aleenasgiftbox[.]com/admin/db_template.php
hxxps://allusdoctors[.]com/themes/db_template.php
hxxp://alainsaffel[.]com//db_template.php
hxxp://www.ariehandomri[.]com//db_template.php
hxxp://aquaneeka[.]co[.]uk/wp-includes/db_template.php
hxxp://itengineering[.]co.za/gatewaydiamond/db_template.php
hxxp://alldomains-crm[.]com/bubblegumpopcorn[.]com/wp-admin/db_template.php
hxxp://www.albertamechanical[.]ca//db_template.php
hxxp://alchamel[.]info//db_template.php
hxxps://almokan[.]net/wp-includes/db_template.php
hxxp://jakobieducation[.]co.za//db_template.php
hxxps://arc-sec[.]net//db_template.php
hxxp://ldams[.]org.ls/supplies/db_template.php
hxxp://menaboracks[.]co.za/tmp/db_template.php
hxxp://www.getcord[.]co.za//db_template.php
hxxp://boardaffairs[.]com//db_template.php
hxxp://capetownway[.]co.za//db_template.php
hxxp://cloudhostdesign[.]com//db_template.php
hxxp://hartenboswaterpark[.]co.za/templates/db_template.php
hxxp://fccorp[.]co.za/php/db_template.php
hxxp://angar68[.]com//db_template.php
hxxp://www.dws-gov[.]co.za//db_template.php
hxxp://alwahahweb[.]com//db_template.php
hxxp://anuragcreatives[.]com//db_template.php
hxxp://embali[.]co.za//db_template.php
hxxp://albertaedmonton[.]com/widgetstyles/db_template.php
hxxp://altosdefontana[.]com//db_template.php
hxxp://airfanhydro[.]net//db_template.php
hxxps://www.alexponcet[.]com/wp-includes/db_template.php
hxxp://agropecuariavilarica[.]com.br//db_template.php
hxxps://www.amazingbuyrd[.]com/admin/db_template.php
hxxp://cdxtrading[.]co.za//db_template.php
hxxp://interafricaconsulting[.]com/wpimages/db_template.php
hxxp://glgroup[.]co.za/images/db_template.php
hxxp://hisandherskennels[.]co.za/php/db_template.php
hxxp://alemaohost[.]com/lotosorg[.]com/db_template.php
hxxp://isibaniedu[.]co.za/admin/db_template.php
hxxp://dianakleyn[.]co.za/layouts/db_template.php
hxxp://themotoringcalendar[.]co.za//db_template.php
hxxp://www.loansonhomes[.]co.za//db_template.php
hxxp://edgesecurity[.]co.za/js/db_template.php
hxxp://highschoolsuperstar[.]co.za/files/db_template.php
hxxp://www.ambientproperty[.]com//db_template.php
hxxp://animationshowreel[.]co.il//db_template.php
hxxp://cafawelding[.]co.za/font-awesome/db_template.php
hxxp://apalawyers.pt//db_template.php
hxxp://www.edesignz[.]co.za//db_template.php
hxxp://centuryacademy[.]co.za/css/db_template.php
hxxps://ambyenta.hr//db_template.php
hxxp://ceramica[.]co.za//db_template.php
hxxp://www.alfredoposada[.]com//db_template.php
hxxp://anastasovsworkshop[.]com/wp-includes/db_template.php
hxxp://allisonplumbing[.]com/wp-includes/db_template.php
hxxp://eastrandmotorlab[.]co.za/fleet/db_template.php
hxxp://angelsongroup[.]com/wp-includes/db_template.php
hxxp://www.mikimaths[.]com//db_template.php
hxxp://hjb-racing[.]co.za/htdocs/db_template.php
hxxp://anotherpartofme[.]com/wp-includes/db_template.php
hxxp://www.andreabelfi[.]com//db_template.php
hxxp://www.iancullen[.]co.za//db_template.php
hxxp://alaskamaterials[.]com//db_template.php
hxxp://jeanetteproperties[.]co.za//db_template.php
hxxp://www.digitalmedia[.]co.za//db_template.php
hxxp://www.rejoicetheatre[.]com//db_template.php
hxxps://alterwebhost[.]com//db_template.php
hxxp://bc-u[.]co[.]uk//db_template.php
hxxp://dpscdgkhan.edu[.]pk/shopping/db_template.php
hxxp://edgeforensic[.]co.za//db_template.php
hxxp://willpowerpos[.]co.za//db_template.php
hxxp://antrismode[.]com/wp-includes/db_template.php
hxxp://colenesphotography[.]co.za/modules/db_template.php
hxxp://anthaigroup.vn//db_template.php
hxxps://alphainvestors[.]com.au//db_template.php
hxxps://aliart[.]nl//db_template.php
hxxps://allmantravel[.]com/thumbs/db_template.php
hxxp://fbrvolume[.]co.za//db_template.php
hxxp://amordegato[.]es/storefront/db_template.php
hxxp://agylub[.]com//db_template.php
hxxp://www.khotsonglodge.co.ls//db_template.php
hxxp://ampli5yd[.]com//db_template.php
hxxps://animeok[.]co.il//db_template.php
hxxps://arbeidsrechtcentrum[.]nl//db_template.php
hxxp://erniecommunications[.]co.za/js/db_template.php
hxxp://promechtransport[.]co.za/scripts/db_template.php
hxxp://centuriongsd[.]co.za//db_template.php
hxxp://www.agencesylvieleclerc[.]com//db_template.php
hxxp://delcom[.]co.za//db_template.php
hxxps://aleoestudio[.]com/gallonature/db_template.php
hxxp://oftheearthphotography[.]com/www/db_template.php
hxxp://h-dubepromotions[.]co.za//db_template.php
hxxp://www.alessioborzuola[.]com/downloads/db_template.php
hxxp://crystaltidings[.]co.za//db_template.php
hxxp://funeralbusinesssolution[.]com/email_template/db_template.php
hxxp://funisalodge[.]co.za/data1/db_template.php
hxxp://experttutors[.]co.za//db_template.php
hxxps://www[.]cartridgecave[.]co.za//db_template.php
hxxp://ecs-consult[.]com//db_template.php
hxxp://www.animationinisrael[.]org/tmp_images/db_template.php
hxxp://gideonitesprojects[.]com//db_template.php
hxxp://hybridauto[.]co.za/photography/db_template.php
hxxp://africanpixels.zar.cc//db_template.php
hxxp://ryanchristiefurniture[.]co.za//db_template.php
hxxp://evansmokaba[.]com/evansmokaba[.]com/thabiso/db_template.php
hxxp://almeriahotelja[.]com/dk/db_template.php
hxxp://al3abflash[.]biz//db_template.php
hxxp://www.fun4kidz[.]co.za//db_template.php
hxxp://alsharhanstore[.]com//db_template.php
hxxp://www[.]infratechconsulting[.]com//db_template.php
hxxp://algihad[.]com/assets/db_template.php
hxxp://americanwestmedia[.]com//db_template.php
hxxp://charliewestsecurity[.]co.za//db_template.php
hxxp://beehiveholdingszar[.]co.za//db_template.php
hxxp://analyticalfootball[.]com//db_template.php
hxxp://apiiination[.]com/leadership/db_template.php
hxxps://ahelicoptermom[.]com/wp-includes/db_template.php
hxxp://servicebox[.]co.za//db_template.php
hxxp://globalelectricalandconstruction[.]co.za/wpscripts/db_template.php
hxxps://aquo[.]in//db_template.php
hxxps://www.alfransia[.]com/wp-admin/db_template.php
hxxp://www.icsswaziland[.]com//db_template.php
hxxp://aiko.pro//db_template.php
hxxps://alceharfield[.]com//db_template.php
hxxp://indocraft[.]co.za/test/db_template.php
hxxp://allegiancesecurity[.]org//db_template.php
hxxp://sullivanprimary[.]co.za//db_template.php
hxxp://www.apmequestrian[.]com//db_template.php
hxxps://alphawaves[.]org/wp-admin/db_template.php
hxxp://www.alexandrasternin[.]com/illustration/db_template.php
hxxp://www.daleth[.]co.za//db_template.php
hxxp://jwseshowe[.]co.za/assets/db_template.php
hxxp://winagainstebola[.]com//db_template.php
hxxp://anubandh[.]in//db_template.php
hxxp://www.alexanderhomestead[.]com//db_template.php
hxxp://alfatek-intelligence[.]com//db_template.php
hxxp://www.aprendiendoencasa[.]com/wp-includes/db_template.php
hxxp://alorabrownies[.]com/wp-admin/db_template.php
hxxp://andrasadam[.]com/tothildiko/wp-includes/db_template.php
hxxp://cazochem[.]co.za/cazochem/db_template.php
hxxp://debnoch[.]com/image/db_template.php
hxxp://hmholdings360[.]co.za//db_template.php
hxxp://iinvest4u[.]co.za//db_template.php
hxxp://burgercoetzeeattorneys[.]co.za//db_template.php
hxxp://anngrigphoto[.]com//db_template.php
hxxp://alchemistasonida[.]com//db_template.php
hxxp://anahera[.]biz/admin/db_template.php
hxxp://h-u-i[.]co.za/heiren/db_template.php
hxxp://insta-art[.]co.za//db_template.php
hxxp://muallematsela[.]com//db_template.php
hxxp://aguasdecastilla[.]com/uploads/db_template.php
hxxp://www.arabgamenetwork[.]com//db_template.php
hxxps://arhiepiscopiabucurestilor[.]ro/templates/db_template.php
hxxp://amruthavana[.]com/blog/db_template.php
hxxp://digitalblue[.]co.za//db_template.php
hxxps://www.alvarezarquitectos[.]com//db_template.php
hxxp://buboobioinnovations[.]co.za/wpimages/db_template.php
hxxp://andrewsbisom[.]com//db_template.php
hxxp://www.m-3[.]co.za//db_template.php
hxxp://beesrenovations[.]co.za/images/db_template.php
hxxps://www.apliety[.]co.il/wp-includes/db_template.php
hxxp://alchamelup[.]org/htdocs/db_template.php
hxxp://benonicoc[.]co.za/resources/db_template.php
hxxps://al-mostakbl[.]com//db_template.php
hxxp://alchimiegrafiche[.]net/bbdelteatro/db_template.php
hxxp://andrespazsoldan[.]com//db_template.php
hxxp://in2accounting[.]co.za//db_template.php
hxxp://aipa[.]ca//db_template.php
hxxp://alphabee.fund/PHPMailer_5.2.0/db_template.php
hxxp://arabsdeals[.]com//db_template.php
hxxps://archiotronic[.]com/wp-includes/db_template.php
hxxp://capewindstrading[.]co.za//db_template.php
hxxps://althurayaa[.]com//db_template.php
hxxp://jhphotoedits[.]co.za//db_template.php
hxxp://cloudhub.co.ls/modules/db_template.php
hxxp://apironco[.]com/wp-includes/db_template.php
hxxp://digital-cameras-south-africa[.]co.za/script/db_template.php
hxxp://ahmadhasanat[.]com//db_template.php
hxxp://alexrocchi[.]com//db_template.php
hxxp://aljaadi[.]com//db_template.php
hxxps://www.engeltjieakademie[.]co.za//db_template.php
hxxp://annabelle[.]nl/next/db_template.php
hxxp://juniorad[.]co.za/vendor/db_template.php
hxxp://animationpulse[.]net//db_template.php
hxxp://angloglot[.]com//db_template.php
hxxp://agricolavicuna.cl//db_template.php
hxxp://alexelgy[.]com/allaccess/db_template.php
hxxp://www.centreforgovernance[.]uk//db_template.php
hxxp://www.aliandconsulting[.]com//db_template.php
hxxp://balaateen[.]co.za/less/db_template.php
hxxp://aleksicdunja[.]com//db_template.php
hxxp://arestihome[.]com//db_template.php
hxxp://am1int.fcomet[.]com/wp1/db_template.php
hxxp://anet-international-group[.]com/shop/db_template.php
hxxp://courtesydriving[.]co.za/js/db_template.php
hxxp://annaplebanek[.]com//db_template.php
hxxp://agencijazemil[.]com//db_template.php
hxxp://airminumtiro[.]com//db_template.php
hxxp://www.androidwikihow[.]com//db_template.php
hxxp://alisabyfinna[.]com//db_template.php
hxxp://rma-law[.]co.za//db_template.php
hxxp://amari[.]ro/components/db_template.php
hxxp://anxiousandunstoppable[.]com//db_template.php
hxxp://www.buhlebayoacademy[.]com//db_template.php
hxxp://arabellajo[.]com/wp/wp-includes/db_template.php
hxxp://blackthorn[.]co.za//db_template.php
hxxp://alaqaba[.]com/dnsarabia[.]com/db_template.php
hxxp://airesis.blog/wp-admin/db_template.php
hxxp://www.aptibet[.]org//db_template.php
hxxp://alecattic[.]com/wp-includes/db_template.php
hxxp://anglero[.]com//db_template.php
hxxp://getabletravel[.]co.za/wpscripts/db_template.php
hxxp://www.allwestdental[.]com/wp-includes/db_template.php
hxxp://printernet[.]co.za//db_template.php
hxxp://genesisbs[.]co.za//db_template.php
hxxp://allsporthealthandfitness[.]com//db_template.php
hxxp://www.humorcarbons[.]com//db_template.php
hxxp://intelligentprotection[.]co.za//db_template.php
hxxp://amazethings[.]com//db_template.php
hxxp://incoso[.]co.za/images/db_template.php
hxxp://www.antoanetapalikarska[.]com//db_template.php
hxxps://www.alteaparadise[.]com/wp-includes/db_template.php
hxxp://amirmenahem[.]com//db_template.php
hxxp://isound[.]co.za//db_template.php
hxxp://www.alestilorachel[.]com//db_template.php
hxxp://alcfm[.]net/wp-admin/db_template.php
hxxp://www.acer-parts[.]co.za//db_template.php
hxxp://www.gsmmid[.]com//db_template.php
hxxp://skhaleni[.]co.za//db_template.php
hxxps://amiici.vision//db_template.php
hxxps://andihaas[.]at/wp-includes/db_template.php
hxxp://www.albertaprimebeef[.]com//db_template.php
hxxps://www.appster[.]it/wp-includes/db_template.php
hxxp://amofoundation[.]org/wp-includes/db_template.php
hxxp://iqra[.]co.za/pub/db_template.php
hxxp://thecompasssolutions[.]co.za//db_template.php
hxxp://archwaycarpetscrm[.]co[.]uk//db_template.php
hxxp://iggleconsulting[.]com//db_template.php
hxxps://angel-blanco[.]net/wp-includes/db_template.php
hxxps://anotherdayinparadise[.]ca//db_template.php
hxxp://www.bitp[.]co.za//db_template.php
hxxp://cupboardcure[.]co.za/vendor/db_template.php
hxxp://all2wedding[.]com/wp-includes/db_template.php
hxxp://allianz[.]com.pe/wp-admin/db_template.php
hxxp://amiehepperlin[.]com//db_template.php
hxxps://www.amighini[.]it/webservice/db_template.php
hxxp://broken-arrow[.]co.za//db_template.php
hxxp://www.ihlosiqs-pm[.]co.za//db_template.php
hxxp://alisimple[.]si/wp-includes/db_template.php
hxxp://allthat[.]social//db_template.php
hxxp://www.amphibiblechurch[.]com//db_template.php
hxxp://bestencouragementwords[.]com//db_template.php
hxxp://alayhamtechnologies[.]com//db_template.php
hxxps://alaskanharvestseafood[.]com/backup/db_template.php
hxxps://www.air-mag[.]ro//db_template.php
hxxp://get-paid-for-online-survey[.]com//db_template.php
hxxp://www.antc[.]ch/wp-includes/db_template.php
hxxp://firstchoiceproperties[.]co.za//db_template.php
hxxp://habibtextiles[.]pk//db_template.php
hxxp://fsproperties[.]co.za/engine1/db_template.php
hxxp://diegemmerkat[.]co.za//db_template.php
hxxp://molepetravel.co.ls//db_template.php
hxxp://mmetl[.]co.za//db_template.php
hxxp://altrablog[.]com//db_template.php
hxxp://abrahamseed[.]co.za//db_template.php
hxxp://www.amerindgen[.]com/author/admin1/db_template.php
hxxp://altcoinaddict[.]com//db_template.php
hxxp://iiee.edu[.]pk//db_template.php
hxxp://cmhts[.]co.za/resources/db_template.php
hxxp://domesticguardians[.]co.za/Banner/db_template.php
hxxps://amishcountryfurnishings[.]com//db_template.php
hxxps://allday[.]gr//db_template.php
hxxp://www.alinn-u-yin[.]com//db_template.php
hxxps://www.allin-chain[.]com//db_template.php
hxxps://www.anatapackaging[.]com/vendors/db_template.php
hxxp://alexcelts[.]com/wp/db_template.php
hxxp://www.allstylus[.]com.br//db_template.php
hxxp://www.algom-law[.]com//db_template.php
hxxp://ambiances-toiles[.]fr//db_template.php
win32_remote
win64_remote64
ollydbg
ProcessHacker
tcpview
autoruns
autorunsc
filemon
procmon
regmon
procexp
idaq
idaq64
ImmunityDebugger
Wireshark
dumpcap
HookExplorer
ImportREC
PETools
LordPE
dumpcap
SysInspector
proc_analyzer
sysAnalyzer
sniff_hit
windbg
joeboxcontrol
joeboxserver
This week, Paul and Keith talk about “The Phoenix Project”, Amazon admits Alexa is creepily laughing at people, Ethereum fixes serious ‘eclipse’ flaw, Kali Linux is now an app in the Windows App Store, Docker + Minecraft = Dockercraft, and more on this episode of Application Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ASW_Episode08
Visit https://www.securityweekly.com/asw for all the latest episodes!
I started my security (post-sysadmin) career heavily focused on security policy frameworks. It took me down many roads, but everything always came back to a few simple notions, such as that policies were a means of articulating security direction, that you had to prescriptively articulate desired behaviors, and that the more detail you could put into the guidance (such as in standards, baselines, and guidelines), the better off the organization would be. Except, of course, that in the real world nobody ever took time to read the more detailed documents, Ops and Dev teams really didn't like being told how to do their jobs, and, at the end of the day, I was frequently reminded that publishing a policy document didn't translate to implementation.
Subsequently, I've spent the past 10+ years thinking about better ways to tackle policies, eventually reaching the point where I believe "less is more" and that anything written and published in a place and format that isn't "work as usual" will rarely, if ever, get implemented without a lot of downward force applied. I've seen both good and bad policy frameworks within organizations. Often they cycle around between good and bad. Someone will build a nice policy framework, it'll get implemented in a number of key places, and then it will languish from neglect and inadequate upkeep until it's irrelevant and ignored. This is not a recipe for lasting success.
Thinking about it further this week, it occurred to me that part of the problem is thinking in the old "compliance" mindset. Policies are really to blame for driving us down the checkbox-compliance path. Sure, we can easily stand back and try to dictate rules, but without the adequate authority to enforce them, and without the resources needed to continually update them, they're doomed to obsolescence. Instead, we need to move to that "security as code" mentality and find ways to directly codify requirements in ways that are naturally adapted and maintained.
End Dusty Tomes and (most) Out-of-Band Guidance
The first daunting challenge of security policy framework reform is to throw away the old, broken approach with as much gusto and finality as possible. Yes, there will always be a need for certain formally documented policies, but overall an organization Does. Not. Need. large amounts of dusty tomes providing out-of-band guidance to a non-existent audience.
Now, note a couple things here. First, there is a time and a place for providing out-of-band guidance, such as via direct training programs. However, it should be the minority of guidance, and wherever possible you should seek to codify security requirements directly into systems, applications, and environments. For a significant subset of security practices, it turns out we do not need to repeatedly consider whether or not something should be done, but can instead make the decision once and then roll it out everywhere as necessary and appropriate.
Second, we have to realize and accept that traditional policy (and related) documents only serve a formal purpose, not a practical or pragmatic purpose. Essentially, the reason you put something into writing is because a) you're required to do so (such as by regulations), or b) you're driven to do so due to ongoing infractions or the inability to directly codify requirements (for example, requirements on human behavior). What this leaves you with are requirements that can be directly implemented and that are thus easily measurable.
KPIs as Policies (et al.)
If the old ways aren't working, then it's time to take a step back and think about why that might be and what might be better going forward. I'm convinced the answer to this query lies in stretching the "security as code" notion a step further by focusing on security performance metrics for everything and everyone instead of security policies. Specifically, if you think of policies as requirements, then you should be able to recast those as metrics and key performance indicators (KPIs) that are easily measured, and in turn are easily integrated into dashboards. Moreover, going down this path takes us into a much healthier sense of quantitative reasoning, which can pay dividends for improved information risk awareness, measurement, and management.
Applied, this approach scales very nicely across the organization. Businesses already operate on a KPI model, and converting security requirements (née policies) into specific measurables at various levels of the organization means ditching the ineffective, out-of-band approach previously favored for directly specifying, measuring, and achieving desired performance objectives. Simply put, we no longer have to go out of our way to argue for people to conform to policies, but instead simply start measuring their performance and incentivize them to improve to meet performance objectives. It's then a short step to integrating security KPIs into all roles, even going so far as to establish departmental, if not whole-business, security performance objectives that are then factored into overall performance evaluations.
Examples of security policies-become-KPIs might include metrics around vulnerability and patch management, code defect reduction and remediation, and possibly even phishing-related metrics that are rolled up to the department or enterprise level. When creating security KPIs, think about the policy requirements as they're written and take time to truly understand the objectives they're trying to achieve. Convert those objectives into measurable items, and there you are on the path to KPIs as policies. For more on thoughts on security metrics, I recommend checking out the CIS Benchmarks as a starting point.
Better Reporting and the Path to Accountability
Converting policies into KPIs means that nearly everything is natively built for reporting, which in turn enables executives to have better insight into the security and information risk of the organization. Moreover, shifting the focus to specific measurables means that we get away from the out-of-band dusty tomes, instead moving toward achieving actual results. We can now look at how different teams, projects, applications, platforms, etc., are performing and make better-informed decisions about where to focus investments for improvements.
This notion also potentially sparks an interesting future for current GRC-ish products. If policies go away (mostly), then we don't really need repositories for them. Instead, GRC products can shift to being true performance monitoring dashboards, allowing those products to broaden their scope while continuing to adapt other capabilities, such as those related to the so-called "SOAR" market (Security Orchestration, Automation, and Response). If GRC products are to survive, I suspect it will be by either heading further down the information risk management path, pulling in security KPIs in lieu of traditional policies and compliance, or it will drive more toward SOAR+dashboards with a more tactical performance focus (or some combination of the two). Suffice to say, I think GRC as it was once known and defined is in its final days of usefulness.
There's one other potentially interesting tie-in here, and that's to overall data analytics, which I've noticed slowly creeping into organizations. A lot of the focus has been on using data lakes, mining, and analytics in lieu of traditional SIEM and log management, but I think there's also a potentially interesting confluence with security KPIs, too. In fact, thinking about pulling in SOAR capabilities and other monitoring and assessment capabilities and data, it's not unreasonable to think that KPIs become the tweakable dials CISOs (and up) use to balance out risk vs reward in helping provide strategic guidance for address information risk within the enterprise. At any rate, this is all very speculative and unclear right now, but something to nonetheless watch. But I have digressed...
---
The bottom line here is this: traditional policy frameworks have generally outlived their usefulness. We cannot afford to continue writing and publishing security requirements in a format that isn't easily accessible in a "work as usual" format. In an Agile/DevOps world, "security as code" is imperative, and that includes converting security requirements into KPIs.
Reputable anti-malware security vendor Malwarebytes is warning Mac users that malware attacks against the platform climbed 270 percent last year.
The security experts also warn that four new malware exploits targeting Macs have been identified in the first two months of 2018, noting that many of these exploits were identified by users, rather than security firms.
In one instance, a Mac user discovered that their DNS settings had been changed and found themselves unable to change them back.
This past week saw the announcement of several new payment card breaches, including a point-of-sale breach at Applebee’s restaurants that affected 167 locations across 15 states.
The malware, which was discovered on February 13, 2018, was “designed to capture payment card information and may have affected a limited number of purchases” made at Applebee’s locations owned by RMH Franchise Holdings, the company said in a statement.
News outlets reported many of the affected locations had their systems infected between early December 2017 and early January 2018. Applebee’s has close to 2,000 locations around the world and 167 of them were affected by the incident.
In addition to Applebees, MenuDrive issued a breach notification to merchants saying that its desktop ordering site was injected with malware designed to capture payment card information. The incident impacted certain transactions from November 5, 2017 to November 28, 2017.
“We have learned that the malware was contained to ONLY the Desktop ordering site of the version that you are using and certain payment gateways,” the company wrote. “Thus, this incident was contained to a part of our system and did NOT impact the Mobile ordering site or any other MenuDrive versions.”
Finally, there is yet another breach notification related to Sabre Hospitality Solutions’ SynXis Central Reservations System — this time affecting Preferred Hotels & Resorts. Sabre said that a unauthorized individual used compromised user credentials to view reservation information, including payment card information, for a subset of hotel reservations that Sabre processed on behalf of the company between June 2016 and November 2017.
Other trending cybercrime events from the week include:
SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of the top trending targets are shown in the chart below.
There were several regulatory stories that made headlines this week, including the FBI’s continued push for a stronger partnership with the private sector when it comes to encryption, allegations that Geek Squad techs act as FBI spies, and new data breach notification laws.
In a keynote address at Boston College’s cybersecurity summit, FBI Director Christopher Wray said that there were 7,775 devices that the FBI could not access due to encryption in fiscal 2017, despite having approval from a judge. According to Fry, that meant the FBI could not access more than half of the devices they tried to access during the period.
“Let me be clear: the FBI supports information security measures, including strong encryption,” Fry said. “Actually, the FBI is on the front line fighting cyber crime and economic espionage. But information security programs need to be thoughtfully designed so they don’t undermine the lawful tools we need to keep the American people safe.”
However, Ars Technica noted that a consensus of technical experts has said that what the FBI has asked for is impossible.
In addition, the Electronic Frontier Foundation obtained documents via a Freedom of Information Act lawsuit that revealed the FBI and Best Buy’s Geek Squad have been working together for decades. In some cases Geek Squad techs were paid as much as $1,000 to be informants, which the EFF argued was a violation of Fourth Amendment rights as the computer searches were not authorized by their owners.
Finally, the Alabama senate unanimously passed the Alabama Breach Notification Act, and the bill will now move to the house.
“Alabama is one of two states that doesn’t have a data breach notification law,” said state Senator Arthur Orr, who sponsored Alabama’s bill. “In the case of a breach, businesses and organizations, including state government, are under no obligation to tell a person their information may have been compromised.”
With both Alabama and South Dakota recently introducing data breach notification legislation, every resident of the U.S. may soon be protected by a state breach notification law.
This article conveys my personal opinion towards security and it's underlying revenue model; I would recommend to read it with a pinch of salt (+ tequila, while we are on it). I shall be covering either side of the coin, the heads where pentesters try to give you a heads-up on underlying issues, and tails where the businesses still think they can address security at the tail-end of their development.
A recent conversation with a friend who's in information security triggered me to address the white elephant in the room. He works in a security services firm that provides intelligence feeds and alerts to the clients. Now he shared a case where his firm didn't share the right feed at the right time even though the client was "vulnerable" because the subscription model is different. I understand business is essential, but on the contrary isn't security a collective argument? I mean tomorrow if when this client gets attacked, are you going just to turn a blind eye because it didn't pay you well? I understand the remediation always cost money (or more efforts) but holding the alert to a client on some attack you witnessed in the wild based on how much money are they paying you is hard to contend.
I don't dream about the utopian world where security is obvious but we surely can walk in that direction.
Is it a domain, a pillar or with the buzz these days, insurance? Information security and privacy while being the talk of the town are still come where the business requirements end. I understand there is a paradigm shift to the left, a movement towards the inception for your "bright idea" but still we are far from an ideal world, the utopian so to speak! I have experienced from either side of the table - the one where we put ourselves in the shoes of hackers and the contrary where we hold hands with the developers to understand their pain points & work together to build a secure ecosystem. I would say it's been very few times that business pays attention to "security" from day-zero (yeah, this tells the kind of clients I am dealing with and why are in business). Often business owners say - Develop this application, based on these requirements, discuss the revenue model, maintenance costs, and yeah! Check if we need these security add-ons or do we adhere to compliance checks as no one wants auditors knocking at the door for all the wrong reasons.
This troubles me. Why don't we understand information security as important a pillar as your whole revenue model?
I have many issues with how "security" is being tossed around as a buzz-word to earn dollars, but very few respect the gravity or the very objective of its existence. I mean whether it's information, financial, or life security - they all have very realistic and quantifiable effects on someone's physical well-being. Every month, I see tens (if not hundreds) of reports and advisories where quality is embarrassingly bad. When you tap to find the right reasons - either the "good" firms are costly, or someone has a comfort zone with existing firms, or worst that neither the business care nor do they pressure firms for better quality. I mean at the end, it's a just plain & straightforward business transaction or a compliance check to make auditor happy.
Have you ever asked yourself the questions,
Now, while I have touched both sides of the problem in this short article; I hope you got the message (fingers crossed). Please do take security seriously, and not only as your business transaction! Every time you do something that involves security on either sides, think - You invest your next big crypto-currency in an exchange/ market that gets hacked because of their lack of due-diligence? Or, your medical records became public because someone didn't perform a good pen-test. Or, you lose your savings because your bank didn't do a thorough "security" check of its infrastructure. If you think you are untouchable because of your home router security; you, my friend are living in an illusion. And, my final rant to the firms where there are good consultants but the reporting, or seriousness in delivering the message to the business is so fcuking messed up, that all their efforts go in vain. Take your deliverable seriously; it's the only window business has to peep into the issues (existing or foreseen), and plan the remediation in time.
That's all my friends. Stay safe and be responsible; security is a cumulative effort and everyone has to be vigilant because you never know where the next cyber-attack be.
This week, Stefano Righi of UEFI joins us for an interview! Sven Morgenroth, Security Researcher at Netsparker joins us for the Technical Segment! In the news, we have updates from FinFisher, Equifax, Facebook, and more on this episode of Paul's Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/Episode550
Visit https://www.securityweekly.com/psw for all the latest episodes!
This series of posts recounts how, in November 2016, we hunted for and took down Gooligan, the infamous Android OAuth stealing botnet. What makes Gooligan special is its weaponization of OAuth tokens, something that was never observed in mainstream crimeware before. At its peak, Gooligan had hijacked over 1M OAuth tokens in an attempt to perform fraudulent Play store installs and reviews.
Gooligan marks a turning point in Android malware evolution as the first large scale OAuth crimeware
While I rarely talk publicly about it, a key function of our research team is to assist product teams when they face major attacks. Gooligan’s very public nature and the extensive cross-industry collaboration around its takedown provided the perfect opportunity to shed some light on this aspect of our mission.
Being part of the emergency response task force is a central aspect of our team, as it allows us to focus on helping our users when they need it the most and exposes us to tough challenges in real time, as they occur. Overcoming these challenges fuels our understanding of the security and abuse landscape. Quite a few of our most successful research projects started due to these escalations, including our work on fake phone verified accounts , the study of HTTPS interception , and the analysis of mail delivery security .
Given the complexity of this subject, I broke it down into three posts to ensure that I can provide a a full debrief of what went down and cover all the major aspects of the Gooligan escalation. This first post recounts the Gooligan origin story and offers an overview of how Gooligan works. The second post provides an in-depth analysis of Gooligan’s inner workings and an analysis of its network infrastructure. The final post discusses Gooligan various monetization schemas and its takedown.
This series of posts is modeled after the talk I gave with Oren Koriat from Check Point, at Botconf in December 2017, on the subject. Here is a re-recording of the talk:
You can get the slides here but they are pretty bare.
As OAuth token abuse is Gooligan’s key innovation, let’s start by quickly summarizing how OAuth tokens work, so it is clear why this is such a game changer.
OAuth tokens are the de facto standard for granting apps and devices restricted access to online accounts without sharing passwords and with a limited set of privileges. For example, you can use an OAuth token to only allow an app to read your Twitter timeline, while preventing it from changing your settings or posting on your behalf.
Under the hood , the service provides the app, on your behalf, with an OAuth token that is tied to the exact privileges you want to grant. In a way that is similar but not exactly the same, when you sign up with your Google account on an Android device, Google gives the device a token that allows it to access Google services on your behalf. This is the long term token that Gooligan stole in order to impersonate users on the Play Store. You can read more about Android long term tokens here .
Overall, Gooligan is made of six key components:
Analyzing Gooligan’s code allowed us to trace it back to earlier malware families, as it built upon their codebase. While those families are clearly related code-wise, we can't ascertain whether the same actor is behind all of them, because a lot of the shared features were extensively discussed in Chinese blogs.
As visible in the timeline above, Gooligan’s genesis can be traced back to the SnapPea adware that emerged in March 2015 and was discovered by Check Point in July of the same year. SnapPea’s key innovation was the weaponization of the exploit kit Kingroot , which was until then used by enthusiasts to root their phones and install custom ROMs.
SnapPea Kingroot straightforward weaponization led to a rather unusual infection vector: its authors resorted to backdooring the backup application SnapPea to be able to infect victims. After an Android device was physically connected to an infected PC, the malicious SnapPea application used Kingroot to root the device in order to install malware on the device. Gooligan is related to SnapPea because Gooligan also use Kingroot exploits to root devices but in an untethered way via a custom remote server.
Following SnapPea footsteps Gooligan weaponizes the Kingroot exploits to root old unpatched Android devices.
A few months after SnapPea appeared, Cheetah Mobile uncovered Ghost Push , which quickly became one of the largest Android (off-market) botnets. What set Ghost Push apart technically from SnapPea was the addition of code that allowed it to persist during the device reset. This persistence was accomplished by patching, among other things, the recovery script located in the system partition after Ghost Push gained root access in the same way Snappea did. Gooligan reused the same persistent code.
Gooligan borrowed from Ghost Push the code used to ensure its persistence across device resets.
As outline in this post Gooligan is a complex malware that built on previous malware generation and extend it to a brand new vector of attack: OAuth tokens theft.
Gooligan marks a turning point in Android malware evolution as the first large scale OAuth crimeware
Building up on this post, the next one of the serie will provide in-depth analysis of Gooligan’s inner workings and an analysis of its network infrastructure. The final post will discusses Gooligan various monetization schemas and its takedown
Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about Gooligan.
To get notified when my next post is online, follow me on Twitter , Facebook , Google+ , or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .
A bientôt!
The Olympic Destroyer cyberattack is a very recent and notable attack by sophisticated threat actors against a globally renowned 2-week sporting event that takes place once every four years in a different part of the world. Successfully attacking the Winter Olympics requires motivation, planning, resources and time.
Cyberattack campaigns are often a reflection of real world tensions and provide insight into the possible suspects in the attack. Much has been written about the perpetrators behind Olympic Destroyer emanating from either North Korea or Russia. Both have motivations. North Korea would like to embarrass its sibling South Korea, the holders of the 23rd Winter Olympics. Russia could be seeking revenge for the IOC ban on their team. And Russia has precedence, having previously been blamed for attacks on other sporting organizations, such as the intrusion at the World Anti Doping Agency that was targeted via a stolen International Olympic Committee account.
There has been much said about attribution, with accusations of misleading false flags and anti-forensics built into the malware. As Talos points out in their report, attribution is hard.
But attribution is not just hard, it’s often a wilderness of mirrors and, more often than not, a bit anticlimactic.
The motivation of our following analysis is not to point the finger of blame about who did the attacking, but to utilize our expertise in analyzing malware code and understanding the behaviors it exhibits to highlight the heritage, evolution and commonalities we found in the code of the Olympic Destroyer malware.
Besides analyzing the behavior of a sample, our sandbox performs several levels of code analysis, eventually extracting all code components, regardless if they are run at run-time or not. As we described in a blog post a few years ago, this technique is essential if we are to detect any dormant functionality that might be present within the sample.
After decomposing the code components in normalized basic blocks, the sandbox computes smart code hashes that are stored and indexed in our threat intelligence knowledge base. Over the last 3 years we have been collecting code hashes for millions of files, so when we want to hunt for other samples related to the same actor, we are able to query our backend for any other binaries that have been reusing significant amounts of code.
The rationale being that actors usually build up their code base over time, and reuse it over and over again across different campaigns. Code surely might evolve, but some components are bound to remain the same. This is the intuition that drove our investigation on Olympic Destroyer further. The first results were obviously some variants of the Olympic Destroyer binaries which we have already mentioned in our previous post. However, it quickly got way more interesting.
A very specific code hash led us through this process: 7CE26E95118044757D3C7A97CF9D240A (Lastline customers can use it to query our Global Threat Intelligence Network). This rare code hash surprisingly linked 21ca710ed3bc536bd5394f0bff6d6140809156cf, a payload of the Olympic Destroyer campaign, with some other samples of a remote access trojan, “TVSpy.” Though the actual internal name of the threat is TVRAT, the malware is known and labelled in VirusTotal as Trojan.Pavica or Trojan.Mezzo, none of which were previously connected to the original Olympic Destroyer campaign.
Figure 1 shows the actual code referenced by the code hash: it is a function used to read a buffer, and subsequently parse PE header from it.
Figure 1: The code referenced by the code hash 7CE26E95118044757D3C7A97CF9D240A shared by both the Olympic Destroyer sample 21ca710ed3bc536bd5394f0bff6d6140809156cf sha1 and TVSpy sample a61b8258e080857adc2d7da3bd78871f88edec2c.
This is not where code re-usage ends, as the actual function referencing and invoking the following fragment (see Figure 2) also shares almost all of the same logic. This function is responsible for loading PE file from the memory buffer and executing an entry point.
Figure 2: Function responsible for loading PE file from memory reused in both Olympic Destroyer and TV Spy
We decided to further investigate this piece of code since loading PE from memory is not all that common. Its origin opened several questions:
Our first discovery was a Remote Access trojan called TVSpy, mentioned above. This family has been the subject of a few previous research investigations, and a recent Benkow Lab blog post (from November 2017) even reported that the source code was available on github.
Unfortunately, all links to github are now dead. But that didn’t stop us from finding the actual source code (or at least evidence that it was indeed published at some point). Apparently it was sold for $US500 on an underground Russian forum in 2015. Even though the original post and links are gone, a Russian information security forum kept a copy of the source code package alongside a description of the original sale announcement (see Figure 3).
Figure 3: TVSpy code as sold in an underground forum (according to researchers from ru-sfera.org)
Although interesting, this connection was eventually not enough to connect Olympic Destroyer to Russia or to TVSpy. So we kept digging. Further research finally identified the code in Figures 1 and 2 to be part of an open source project called LoadDLL (see Figure 4) and available on codeproject.com (first published back in March 2014).
Figure 4: Fragment of LoadDLL source code from LoadDLL project
However, a couple things still didn’t add up: why had we only managed to identify samples from 2017 even if the source code was released in 2014? What about older versions of TVSpy? How come our search didn’t return any of those samples? Were Olympic Destroyer and TVSpy samples from 2017 sharing more than just the LoadDLL code?
Apparently TVSpy went through a few transformations. Samples from 2015 did embed and use the LoadDLL code, but the compiler did some specific optimizations that made the code unique (see Figure 5). In particular the compiler optimized out both “flags” (not used in the function) and “read_proc” (statically link function) from the parameters of LoadDll, but it couldn’t optimize out a “if (read_proc)” check even though it is useless since “read_proc” is not passed as a parameter anymore.
Figure 5. Reconstructed source code of LoadDll from TVSpy dated back to 2015
The “read_proc” function itself is also identical to one from source code (see Figures 6 and 7) and as you can see in Figure 8, it also gets called exactly the same way as the original source code from codeproject.com.
Figure 6: read_proc function implementation
Figure 7: read_proc function implementation
The most interesting aspect for us is in fact the version of TVSpy that dates back to 2017-2018 and shares with Olympic Destroyer almost the exact binary code of LoadDLL. You can see LoadDll_LoadHeaders for those samples in Figure 9: as you might notice the function looks different then the one from the older version (see Figure 8).
Figure 8. Reconstructed source code of LoadDLL_LoadHeaders function from TVSpy dated back to 2015
First, we thought that the authors added new checks before calling read_proc function, making clear link between Olympic Destroyer and TVSpy (how, after all, could there be the same code modifications if the authors were not the same?). However, after further review we figured that read_proc didn’t exist anymore. Instead it was compiled inline resulting in a statically linked memcpy function.
Figure 9. Reconstructed LoadDLL_LoadHeaders from TVSpy and OlympicDestroyer samples, including additional check due to inlining of the read_proc function.
Also the meaningless check in LoadDll (“if (read_proc)”) we mentioned before has disappeared in the new version of the code (see Figure 10).
Figure 10. Reconstructed LoadDLL_LoadHeaders from TVSpy and Olympic Destroyer samples, including additional check due to inlining of the read_proc function.
In conclusion, we believe that this is not enough evidence to substantiate a claim that Olympic Destroyer and new versions of TVSpy using the same modified source code are built by the same author.
The more probable version for us is that the sample was built on a new compiler that further optimized the code. It would still mean that both new version of TVSpy and Olympic Destroyer are built using the same toolchain configured in the very same way (to enable full optimization and link C++ runtime statically). We actually went to the extent of compiling the LoadDLL on MS Visual Studio 2017 with C++ runtime statically linked, and we managed to get the very same code as the one included in both Olympic Destroyer and TVSpy.
Although we would have liked to finally solve the dilemma, and unveil which were the actors behind the Olympic Destroyer attack, we ended up with more questions than answers, but admittedly, that’s what research sometimes is about.
First, why would the authors of an allegedly state sponsored malware use an old LoadDLL project from an open source project from 2014? It is hard to believe that they could not come up with their own implementation or use much more advanced open-source projects for that, and definitely not relying on an educational prototype buried way beyond the first page of results in Google.
Or maybe the actors were not that much advanced as we would like to think, maybe seeing this as a one-time job, without enough resources to avoid using publicly available source code to quickly build their malware? Or maybe it’s just another red flag, and the real authors decided to use the TVSpy source code as released in 2015 to leave a “Russian fingerprint”?
Maybe all of the above?
At the beginning of this article we stated that attribution is not just hard, it’s often a wilderness of mirrors and more often than not, a bit anticlimactic. As a matter of fact, that was quite a precise prediction.
The post From Russia(?) with Code appeared first on Lastline.
This week, Paul and John are accompanied by Eyal Neemany, Senior Cyber Security Researcher at Javelin Networks! In the news, we have updates from Duo Security, SolarWinds, AlgoSec, Martin Shkreli, and more on this episode of Enterprise Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ES_Episode82
Visit https://www.securityweekly.com/esw for all the latest episodes!
Patching security vulnerabilities in industrial control systems (ICS) is useless in most cases and actively harmful in others, ICS security expert and former NSA analyst Robert M. Lee of Dragos told the US Senate in written testimony last Thursday. The "patch, patch, patch" mantra has become a blind tenet of faith in the IT security realm, but has little application to industrial control systems, where legacy equipment is often insecure by design.
(Insider Story) |
| Click on the detailed behavior report. |
 |
| Screenshots and File operations |
 |
| DNS, IP Traffic and Behavior tags |
This week, Michael & Paul interview Shawn Tuma, Cybersec and Data Privacy Attorney at Scheef & Stone, LLP! In the Article Discussion, Michael and Paul talk how to build trust with colleagues, simple concepts to free up innovation, and how to avoid death by committee! In the news, we have updates from PhishMe, Splunk, CyberX, and more on this episode of Business Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/BSWEpisode76
Visit https://www.securityweekly.com/bsw for all the latest episodes!
Last week, researchers observed a 1.35 Tbps distributed denial-of-service attack (DDOS) attack targeting GitHub. It was the largest DDoS attack ever recorded, surpassing the 1.2 Tbps attack against DNS provider Dyn in October 2016.
The attack leveraged a newly observed reflection and amplification vector known as memcached. Akamai researchers warned that other organizations experienced similar DDoS attacks using the new method following the GitHub attack and that even larger attacks may be possible in the future.
“Memcached can have both UDP and TCP listeners and requires no authentication,” the researchers wrote. “Since UDP is easily spoofable, it makes this service vulnerable to use as a reflector. Worse, memcached can have an amplification factor of over 50,000, meaning a 203 byte request results in a 100 megabyte response.”
The attack was mitigated within 10 minutes, GitHub said. The following day GitHub was the target of a second DDoS attack that disrupted availability for a 15-minute period, ThousandEyes reported.
“Because of its ability to create such massive attacks, it is likely that attackers will adopt memcached reflection as a favorite tool rapidly,” Akamai researchers wrote. “The good news is that providers can rate limit traffic from source port 11211 and prevent traffic from entering and exiting their networks, but this will take time.”
Wired reported there are approximately 100,000 memcached servers that currently have no authentication protection and can be abused by malicious attackers to carry out similar potentially massive, botnet-free DDoS attacks.
Other trending cybercrime events from the week include:
SurfWatch Labs collected data on many different companies tied to cybercrime over the past week. Some of the top trending targets are shown in the chart below.
Equifax was back in the news this week after announcing it had discovered an additional 2.4 million U.S. consumers who were affected by its massive 2017 data breach, bringing the total number of people impacted to 147.9 million.
“This is not about newly discovered stolen data,” said Paulino do Rego Barros, Jr., Interim chief executive officer in a press release. “It’s about sifting through the previously identified stolen data, analyzing other information in our databases that was not taken by the attackers, and making connections that enabled us to identify additional individuals.”
The company also said that it expects breach-related costs to hit $275 million in 2018, which Reuters noted could make the Equifax breach the most costly hack in corporate history:
The projection, which was disclosed on a Friday morning earnings conference call, is on top of $164 million in pretax costs posted in the second half of 2017. That brings expected breach-related costs through the end of this year to $439 million, some $125 million of which Equifax said will be covered by insurance.
Those breach-related costs could rise further once legal actions from consumers and regulators are finally resolved. However, Sen. Elizabeth Warren recently stated that “Equifax is still making money off their own breach” and that even consumers who do not want to do business with them may end up buying credit protection services from another company who “very well may be using Equifax to do the back office part.”
It’s the same criticism she waged in January when introducing a bill with Sen. Mark Warner to address problems related to credit agencies collecting data without strict protections in place to secure that information. As CNET noted, if such a bill was in place at the time of the Equifax breach, the company likely would have faced a fine of at least $14.3 billion.
This week, Keith and Paul discuss Facebook’s mandatory malware scan, GitLeaks: Check git repos for secrets and keys, New York quietly working to prevent a major cyber attack, and more on this episode of Application Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ASW_Episode07
Visit https://www.securityweekly.com/asw for all the latest episodes!
This week, Mary Beth Borgwing of Mach37, joins us for an interview! In our second feature interview, Paul speaks with Cybersecurity Journalist Bruce Sussman of SecureWorld! In the news, we have updates from Quickjack, GitHub, the 2018 Olympics, and more on this episode of Paul's Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/Episode549
Visit https://www.securityweekly.com/psw for all the latest episodes!
This week, Paul is joined by Doug White to interview Ferruh Mavituna, Founder and Product Manager of Netsparker! In the news, we have updates from Atos, Trustwave, Radware, and more on this episode of Enterprise Security Weekly!
Full Show Notes: https://wiki.securityweekly.com/ES_Episode81
Visit https://www.securityweekly.com/esw for all the latest episodes!
Recently I noticed a new service/ project that is turning few heads among my peers in security community - CertDB. A one of its kind which indexes the domains SSL certs with their details, IP records, geo-location and timelines, common-name etc. They term themselves as Internet-wide search engine for digital certificates. They have a unique business statement when you get to understand the different components (search vectors) they are incorporating in this project. I know there are few transparent cert registries like Certificate Search but as per their website,
Examining the data hidden in digital certificates provides a lot of insight about business activity in a particular geography or even collaboration between 2 different companies.
I know and agree with them on these insights that they do come handy while performing reconnaissance during a security assessment (OR) validating the SSL/ TLS certificates for your client. It does reflect on the fact that maybe the certificate is about to expire, or new domains have been registered in the same certificate (example, Subject Alternate Name: DNS Name). But when I browsed through their project website, I was surprised the way they articulated their USP (unique selling point),
For example, the registration of a new unknown domain in Palo Alto hints at a new start-up; switching from the "Wildcard" certificate to "Let's Encrypt" tells us about the organization's budget constraints; issuing a certificate in an organization with domains of another organization speaks about collaboration between companies, or even at an acquisition of one company by another.
Now, I am intrigued to do a detailed article on their services, business model, filters and even an interview with their project team.
Question: Are you curious/interested, and what would you like to ask them? Do leave a comment.