By: Nidhi Rastogi, Sharmishtha Dutta, Mohammed J. Zaki, Alex Gittens, Charu Aggarwal
Malware threat intelligence uncovers deep information about malware, threat actors, and their tactics, Indicators of Compromise(IoC), and vulnerabilities in different platforms from scattered threat sources. This collective information can guide decision making in cyber defense applications utilized by security operation centers(SoCs). In this paper, we introduce an open-source malware ontology – MALOnt that allows the structured extraction of information and knowledge graph generation, especially for threat intelligence. The knowledge graph that uses MALOnt is instantiated from a corpus comprising hundreds of annotated malware threat reports. The knowledge graph enables the analysis, detection, classification, and attribution of cyber threats caused by malware. We also demonstrate the annotation process using MALOnt on exemplar threat intelligence reports. A work in progress, this research is part of a larger effort towards auto-generation of knowledge graphs (KGs)for gathering malware threat intelligence from heterogeneous online resources.
Firmware Command and Control will create an agile embedded response capability foundational with baselined firmware and behaviors with bi-directional sharing of threat to upstream energy security operations
* Embedded devices control the most critical functions on the electric grid with little to no insight into the firmware or ability to mitigate from cyber attacks.
* The adversaries have ‘raced to the bottom’ hiding access in embedded devices
* Firmware will be baselined to detect changes with advanced ML similarity with constraints
* Embedded host agile response
* Structured threat sharing between the device and upstream security
* Firmware C2 will monitor and mitigate previously unmonitored devices controlling the most critical functions in the electric grid.
* Baselined embedded firmware with all constraints for setting changes
* Low-impact cyber operations protected/hidden from adversaries
* Structured Threat: Visual, Sharable, Actionable, and Implementable (IT/OT)
* Firmware C2 uses recent ML concepts to baseline firmware to detect unexplained changes, described in structured threat for bi-direction upstream energy security operations actions and awareness.
Forescout selected by U.S. Department of Energy to Participate in Firmware Project Under Grid Modernization Lab Consortium
FirmWare Test Suite’s ACPI tests are improving. It sounds like they are acpica-dump compatible now, and FTWS dumps more than acpidump!
[PATCH 1/2] doc: add new –dump-acpi-from-sysfs option
[PATCH 0/2] make the acpi logs from fwts can be used acpica debugging
“-dumpfile=acpidump.log: load ACPI tables from output generated from acpidump or from sudo fwts –dump. The latter is preferred as fwts –dump is able to dump more tables than acpidump.[…]
SymCC is a compiler wrapper which embeds symbolic execution into the program during compilation, and an associated run-time support library. In essence, the compiler inserts code that computes symbolic expressions for each value in the program. The actual computation happens through calls to the support library at run time. To build the pass and the support library, make sure that LLVM 8, 9 or 10 and Z3 version 4.5 or later, as well as a C++ compiler with support for C++17 are installed. […]
IntelMCDowngrade: Scripts to collect microcode from CPUMicrocodes Repo and to downgrade to a compatible microcode.[…]
In previous posts, we explained how to dump Exynos bootROM and reverse its USB stack.[…]
Hmm, it seems that Alex Ionescu, author of VisualUEFI has disappeared online, partially.
I was going to point someone to an old post of his on Windows binaries included in WBPT ACPI, for an answer to the below question:
but it appears his Twitter account is no longer active and all the old tweets are gone:
His web site appears to be blank (default, unconfigured) state:
The Github web page for Alex has a link to his Twitter URL, which appears to redirect to another user:
https://github.com/aionescu (maybe this is innocent Github redirection foo?).
Just being a bit paranoid, but maybe you should be careful about using some of the binaries checked into VisualUEFI:
Keep an eye out for any strange checkins:
I’ve probably missed something and he’s moved onto another account or something. But be careful with anything in binary (or source form) online, in general, anyway.
If someone can clarify things, please leave a Comment on this post. Thanks.
This utility is an app indicator (tray icon) to help you reboot into other OSes, or UEFI/BIOS, or the same OS. Instead of picking the OS you want during reboot at the grub menu, you can just preselect it from the menu here. Basically it’s a wrapper around grub-reboot. I’ve only tested this on Ubuntu 20.04.
[ This is 2 year old news, but I’m just learning about it… 😦 ]
Wireshark is a tool used to sniff network packets and dissect the protocols and help debug them. Since version 3.0.0 or so, you can use Wireshark to sniff TPM v2. Not the hardware TPM chip, but a TPM2 simulator, which is simulated over the network, so Wireshark can capture it, and there’s a Wireshark Dissector (parser) for TPM2 protocol.
Created by the TPM2 community:
There is a brief mention of this Wireshark TPM2 dissector in this FOSDEM presentation:
PS: Mostly only related by the “Shark” suffix string, but if you are debugging Linux, KernelShark is a nice tool. I haven’t tried it with a TPM, but you might be able to see Linux kernel TPM trace log traffic through KernelShark…
[…]The goal is to have you own certificate in the Secure Boot db variable[…]Requirements: Under Arch Linux, install the packages efitools and sbsigntool.[…]
[[ UPDATE: project URL: https://github.com/Bareflank/standalone_cxx ]]
Last year at CppCon there was a UEFI security talk by Dr. Rian Quinn, “[…] a lead developer and co-founder of the Bareflank Hypervisor, and is an active member of several open source projects including OpenXT.[…]”
[…]In this presentation, we will examine how C++ works behind the scenes as well as how to include C++ and the Standard Library in freestanding environments. Such environments include shellcode, UEFI, embedded systems (with no OS available), and unikernels. […]Finally, this presentation will conclude with a demonstration of a UEFI application written in C++ as well as a demonstration of leveraging C++ in shellcode.
Maybe I missed it, but I didn’t find the slides for this talk along with the other slides on: https://github.com/CppCon/CppCon2019
Dell BiosVerification.py Live Response API Script: This set of tools uses the VMware Carbon Black Security Cloud Live Response APIs to retrieve artifacts generated by the Dell Trusted Device SafeBIOS verification service. The Dell Trusted Device agent saves BIOS image files to the filesystem when a verification failure event is detected. Incident responders can use this set of scripts to retrieve the BIOS image files for forensic analysis.[…]
Great news for Windows users!
(Great news for Windows-based AMD users, who can’t use CHIPSEC.
I am guessing this new UEFI feature works on Intel and AMD, but not ARM…
Open Source Community: someone needs to add a CHIPSEC patch to ClamAV. 🙂
Baremetal environment for “System programming lab” class in Dept. of Information Science, The University of Tokyo. […]The bootloader is implemented referencing UEFI Specification Version 2.8 (PDF). To support UEFI boot in qemu emulation, OVMF is automatically installed by make command. The following tools need to be installed by users to build the bootloader, the kernel and the apps.[…]
A simple utility to find and mount EFI partitions.
Written in Ruby, for a Linux-like environment.
there is another exploit from the original researcher.
This sequel is an improvement on American Unsigned Language, in that it works on mainline kernels and does not require any reboots.[…]
View at Medium.com
PS: It is a shame that AMD has not ported CHIPSEC to their CPU, as CHIPSEC only currently does not support AMD and only works on Intel processors. Alternately, AMD could have bypassed contributing to an Intel-led CHIPSEC project and created their own security diagnstic tool. If this were an Intel CVE, I’d expect the Intel CHIPSEC team to add a new security test for this CVE, and to look forward to upcoming CHIPSEC release to help with detecting this. But given it is AMD, which has zero interst in CHIPSEC, will they release any tool? AMD: you have money now with the Ryzen, spend a bit on security, ok?
A UEFI Application that hooks SetVariable to allow a user-space program to access kernel memory.