BloodHound data collection, aka Sharphound, is quite a complex beast.
When giving BloodHound workshops, the part where I get the most questions is
always data collection.
How is the BloodHound data collected? What methods do what? Who am I talking
to? How do I fly under the radar?
These are all very relevant questions when you think about it.
After all, the rest is just a gorgeous UI sitting on top of a cool data model,
but the only bit of BloodHound code that ever touches the targeted network is
SharpHound. And so questions about it should be mandatory.
Now even thought I’ve been working with BloodHound for quite a while, there is
always this moment where I have to check before answering… (I feel the older I
get, the quicker I understand, but the less I remember… but that’s another story
I guess…)
Wir freuen uns, dass das Bundesamt für Sicherheit in der Informationstechnik
(BSI) im Rahmen des gemeinsam mit ERNW durchgeführten SiSyPHuS Win10-Projekts
(Studie zu Systemintegrität, Protokollierung, Härtung
und Sicherheitsfunktionen in Windows 10) heute (ca. 10 Uhr) die nächsten
drei Arbeitspakete veröffentlicht:
Empfehlung zur Härtung von Windows 10 mit Bordmitteln
Empfehlung zur Konfiguration der Protokollierung in Windows 10
Gruppenrichtlinien zu den Konfigurationsempfehlungen für Härtung und
Protokollierung für Windows 10
In den Dokumenten finden sich unterschiedliche Empfehlungen für
Domänenmitglieder (mit normalem und mit hohem Schutzbedarf) und
Einzelplatzrechner. Die Dokumente bauen auf den Empfehlungen von Microsofts
Security Baseline und dem CIS Benchmark für Windows 10 auf und ergänzen diese in
von Microsoft und CIS nicht betrachteten Bereichen oder modifizieren sie dort,
wo es aus Erfahrung von ERNW im Hardening von Windows-Systemen sinnvoll ist.
Last year, the CISO of a customer sent me a laptop for analysis. The reason was
that he feared the company could have been victim of industrial espionage.
Starting in spring 2020, the IT help desk got several employee laptops with full
hard drives, caused by a huge amount of audio recordings. The audio files
contained recordings even of highly sensitive telephone conferences. An
automated scan on all employee computers for such audio recordings showed that
about 300 devices were affected.
In this post, I will introduce fpicker. Fpicker is a Frida-based
coverage-guided, mostly in-process, blackbox fuzzing suite. Its most significant
feature is the AFL++ proxy mode which enables blackbox in-process fuzzing with
AFL++ on platforms supported by Frida. In practice, this means that fpicker
enables fuzzing binary-only targets with AFL++ on potentially any system that is
supported by Frida. For example, it allows fuzzing a user-space application on
the iOS operating system, such as the Bluetooth daemon bluetoothd – which was
part of the original motivation to implement fpicker.
I am glad to announce the release of the ERNW whitepaper 71 containing
information about quarantine file formats of different AV software vendors. It
is available
here.
Anti-Virus Software
I took quarantine files from real-life incidents and created some in a lab
environment. Afterwards I tried to identify metadata, like timestamps, path
names, malware names, and the actual malicious file in the quarantine files. One
goal was to use this information to support our incident analyses: Using the
results, we can now easily create timelines showing information about
quarantined files, extract the detected malware, and sometimes even find
information about processes that created the malicious files.
It’s Friday, you managed to escape for a couple of hours from a busy working day
to see a doctor. Now you have to wait in a boring waiting room at the clinic
until it’s your turn to see her majesty. What would you like to do in this time?
Answer pending business emails, get lost in social media, or choose a new theme
to make your iPhone look awesome? What about: all of the above? It’s nice to
have everything on your iPhone: MDM enrollment to access business data, in
addition to jailbreak for device freedom. However, MDM solutions ban jailbroken
devices, because they are not secure enough to handle sensitive business data.
And so, cat and mouse games of jailbreak detection/bypass between MDM solutions
and some users develop.
With this blog post, I will provide information on how to proceed when testing
ELK Stack landscapes. Information regarding the exploitation of the ELK Stack is
very rare on the internet. Therefore, following article aims to provide you with
some approaches that can be useful during a penetration test.
Disclaimer:
All information below were collected during a research project and there is no
claim for completeness. The guide focuses on ELK Stack deployments for Linux
machines. Further, this article does not include information for identifying
misconfigurations in a white-box configuration audit.
In the
last blog post,
we discussed how fuzzers determine the uniqueness of a crash. In this blog post,
we discuss how we can manually triage a crash and determine the root cause. As
an example, we use a heap-based buffer overflow I found in GNU readline 8.1 rc2,
which has been fixed in the newest release. We use GDB and rr for time-travel
debugging to determine the root cause of the bug.
In August 2020 we reported six vulnerabilities in SolarWinds N-Central
12.3.0.670 to the vendor.
The following CVE IDs were assigned to the issues :
CVE-2020-25617: RCE in N-Central Administration Console (AdvancedScripts
Endpoint)
CVE-2020-25618: Local Privilege Escalation from nable User to root (N-Central
Backend Server)
CVE-2020-25619: Access to Internal Services through SSH Port Forwarding
(N-Central Backend Server)
CVE-2020-25620: SolarWinds Support Account with Default Credentials
CVE-2020-25621: Local Database does not require Authentication (N-Central
Backend Server)
CVE-2020-25622: CSRF in N-Central Administration Console (AdvancedScripts
Endpoint)
The vulnerabilities have been found in the course of an extensive research
project, in which we analyze the security of multiple Unified Endpoint
Management (UEM) solutions. Similar vulnerabilities have been found in other
solutions as we pointed out in previous posts about the
Ivanti DSM Suite
and
Nagios XI.
The final outcome of the research project will be published as a whitepaper and
possibly conference talk as soon as the project including all disclosure
processes concludes.
This blogpost sheds some light on how fuzzers handle crash deduplication and
what a unique crash is for a fuzzer. For this, we take a look at two contrived
examples and compare the unique crashes identified by
AFL++ and
honggfuzz.
Both examples are similar. They read from STDIN, check if the first character of
the read data is a digit, then call a vulnerable function. The main difference
in test1.c is
that the program crashes directly in the vuln function due to a null pointer
dereference. In
test2.c, a
previously allocated buffer is freed; this buffer is again freed at the end of
main, resulting in libc identifying the double free and raising a sigabort.