RSS feed

Weekly infosec news summary for 2017.08.13 – 2017.08.20


“The Apple Developer Cert Revocation List (CRL) is currently over 45MB in size, containing over 1.1M revocations due to ‘Key Compromise’” Will Dormann‏


Top stories

ShadowPad: Server management software (NetSarang) hit in supply chain attack

Kaspersky announced new malware found due to an investigation by a financial institution that noticed suspicious DNS requests, which led them to the NetSarang software installed on their network, which is a maker of server management software from South Korea (link). The software had been modified in an update to include malicious code that would beacon out to a DNS server with basic recon info about the infected system. The DNS server may then respond with a decryption key to activate the second stage payload that can download and execute arbitrary code. The second stage is known to have been activated against a target in Hong Kong.

This is previously unknown malware that includes advanced functionality such as maintaining a virtual file system (VFS) within the Windows registry. The updates were code signed with the legitimate NetSarang cert, implying that the attackers made their way into the build process. This is therefore more advanced than the recent NotPetya infection, which also infected via auto-updates, but that attack required only compromising the auto-update servers.

These malicious updates had been sent out for 17 days, starting on July 18, 2017, until Kaspersky and NetSarang stopped it on August 4.

Standard advice from infosec has been to keep up with updates, but with attacks like this and NotPetya, one needs to be more cautious about updates. Some advice:

  • Use segmentation: Keep your business’s own production data isolated from your finance team or other teams.
  • Know all of the assets in your environment, including all applications, and enforce application white-listing to ensure no new vendors are used with approval. This limits the number of vendors being used, which in turn limits your attack surface to attacks like this. If, for some category of software, you have one of every type installed on your network (for example, video conferencing software), then an attack on any one of those vendors will impact you.
  • Vet your vendors (aka perform third-party audits) where your vendors respond to questionnaires and attest to the security controls they have in place.

This attack was detected because the C2 used the suspicious looking randomly generated domain nylalobghyhirgh[.]com. Had a reasonable C2 domain been used, or if the autoupdate server served as the C2 as was the case with NotPetya, this attack would have been much more difficult to detect.

AWS announcements

AWS held a summit in New York this week, where they announced a number of new services and additional features to existing services (link). From a security perspective, the most important are:

  • Cloudtrail is now enabled by default for all accounts! (link) It has 7 days of retention, so you should still enable Cloudtrail yourself to write to an S3 bucket for long-term storage.
  • Amazon launched Macie, a service that uses machine learning to classify content in S3 buckets and alert you about suspicious access (link). Beware of costs as someone with a normally $5K/mo AWS bill turned it on, and ended up with a $60K bill (link).
  • CloudHSM now offers pay as you go pricing (link). Historically, this hardware security module (HSM) service for managing and using crypto keys in a FIPS 140-2 Level 3 certified way, required a $5K upfront fee, and $1.88/hr rate ($1373/mo). Now you can simply pay an hourly fee of $1.60 ($1169/mo).

Hacking back

This week a phishing site made to look like the ProtonMail login screen was hacked back by ProtonMail where they stated on twitter “We also hacked the phishing site so the link is down now” (link). The concept of hacking back has caused some drama over the years, as some have wanted to be allowed to hack back against those who hack them to either better identify who the attackers are, what was taken, or cripple the attacks (as ProtonMail did). Other have worried this could cause more problems as you might accidentally hack innocent bystanders, disrupt investigations, or other reasons. Matt Weeks compiled a list of known hack backs that have happened, and found that there was no negative result from any of them (link).


  • Maersk losses from NotPetya $200M-$300M: The shipping company Maersk released updated guidance stating the loss in revenue from NotPetya is estimated at $200M-$300M. Security Week collected a number of such statements from companies about their losses from NotPetya (link) that include:
    • Maersk: $200M-$300M
    • Nuance Communications: $15M
    • Mondelez International (owner of U.K. chocolate maker Cadbury): $150M
    • Saint-Gobain (French construction giant): $387M
  • Blackstone backs out of NSO deal: Blackstone had been reported to be in talks to invest $400M into NSO Group (a spyware vendor), but has backed out of that plan.
  • Court rejects LinkedIn claim that unauthorized scraping is hacking: Many tech companies provide access to their pages to search engines, but have teams devoted to stopping scrapers. In an unexpected court ruling (link), LinkedIn has been forced to remove any protections in place against scrapers (or at least this scraper in particular). The ruling includes statements implying that bypassing CAPTCHAs, or anything meant to slow down bots, is also authorized access. I believe additional court rulings are needed to clarify this situation, as perhaps using the CFAA was simply not the correct tool to use in this case.

Conference materials and publications

  • USENIX Security papers and WOOT papers: This conference took place this past week in Vancouver. Facebook selects what they believe is the best paper from this conference for Internet defence, and selected Detecting Credential Spearphishing Attacks in Enterprise Settings for which they won $100K (link). The paper looked at a 4 year dataset of 370M emails from a large enterprise with thousands of employees, and they successfully detected 6/7 known attacks that succeeded, 9/10 attacks that failed, and detected 2 previously unknown attacks, with a false positive rate of %0.004. The research had the benefit of a lot of good data features, including domain reputation (including if anyone at the company had ever visited the domain previously) and sender reputation (including if the email was spoofed or from a domain that looks similar to a known good domain).


  • nccgroup/G-Scout: Tool for assessing the security of a Google Cloud Platform (GCP) environment, much like NCC Group’s other tool Scout2 that they use for AWS environments.
  • objective-see/sniffMK: macOS mouse and keyboard sniffer, surprisingly developed for the legitimate purpose of analyzing the macOS malware FruitFly which can simulate mouse and keyboard events.

Other reads

  • Ransomware Changed the Rules: the grugq makes the case that ransomware has “forced companies to take real security steps because the risk of a cyber security failure is no longer limited to reputation, or borne by customers, but is an existential risk to the company itself”. It is “real, directed at the business itself, understandable by non-experts, and visible outside the infosec echo chamber.” I agree with this and would also add that ransomware is immediately and clearly visible and the impact is quantifiable. I mentioned this back in July that “Cryptocurrency hacks and ransomware have been an interesting phenomenon in infosec as they provide very clear understandings of the impacts of security issues. There are few security compromises that evidence the timing of the compromise so immediately, or the cost so precisely.” (link).
  • LLVM on Windows now supports PDB Debug Info: This info will help better understand Windows binaries, including those provided by the Microsoft Symbol server.
  • Bug bounty for $15K for open prod instance of Jenkins at Snapchat: Snapchat exposed two Jenkins instances that required Google accounts for authentication. Unfortunately, access was not restricted to just Snapchat employees with Google accounts, but rather to anyone with a Google account. $5K was awarded for finding a test instance of a Jenkins server (link), and $15K was awarded for finding a production instance (link). As more companies are putting their private services on the public Internet with some authentication proxy in front, as opposed to inside a corporate intranet, as a sort of BeyondCorp strategy, it is critical that this authentication work correctly. We saw last week that Google’s authentication proxy for their own services was not properly protecting access (link). When proxying access like this to internal services, ensure that the service is only accessible via the proxy (Google’s flaw) and ensure the authentication is properly controlling who can and cannot access the resource (Snapchat’s flaw).