Hello,
I recently posted a message, where I asked how to create a profile which could be used with ArchLinux, but now I just solved this by having installed Lubuntu 16.04 (4.4.0-31-generic 64-bit), so that I was able to analyze my system's dumped memory using the pre-built Ubuntu 16.04 image I found on GitHub (the image I created by myself couldn't be used by Volatility, although I definitely followed each step precisely).
The checks I performed confirmed my suspicion that my system would be compromised, as one can see by taking a look at the results I uploaded on GoogleDrive:
https://drive.google.com/open?id=0B62Y5Qk_rdbWTnNYWlJRWXpsZUEE.g.:
linux_check_afinfo
Symbol Name Member Address
------------------------------------------ ------------------------------ ------------------
udplite6_seq_afinfo next 0xffffffff81effcc8
udplite6_seq_afinfo stop 0xffffffff81eff808
udplite4_seq_afinfo next 0xffffffff81efeac8
udplite4_seq_afinfo stop 0xffffffff81efbce8
udp4_seq_afinfo start 0xffffffff81efae00
udp4_seq_afinfo stop 0xffffffff81efa3a0
linux_check_inline_kernel
Name Member Hook Type Hook Address
------------------------------------------------ ---------------- --------- ------------------
udp4_seq_afinfo stop JMP 0x0000000000000000
[A huge number of hooks shown by linux_check_syscall]
Using the netstat plugin shows no result at all (none of the connections shown by using the normal Linux netstat command). Neither linux_lsmod nor linux_hidden_modules give any output as well.
I assume that my system is infected by an ACPI rootkit, which is able to compromise both Linux and Windows systems. After having submitted the extracted the ACPI tables' code to
malwr.com, where it gets executed on a Windows sandbox, it shows that the system gets manipulated in the following way:
https://malwr.com/analysis/ODkxOThjOTk1MDAzNGE4M2JhOWNhNzk1ZTJjM2IyYWQ/It might be interesting that the ACPI code of four different systems being used by me seems to have been manipulated in the same way, since the extracted code found on one of the other systems leads to the same result when submitting it to
malwr.com. E.g., the link above shows the result for the analysis of ACPI code on my AMD 64-bit desktop computer (Asus-M4N68T-M LE mainboard), while the ACPI code extracted from my Lenovo G710 notebook leads to the same when executed on a Windows system:
https://malwr.com/analysis/MjZkOGU4Y2ZmMGM5NDQ1Njg5OTc4NTVlOTQ5NThiMmY/I guess everyone can see that the results show how the Windows system gets compromised for being able to monitor it and gaining remote access over it, if you take a look at the file and registry activities (just googling some of the file names makes that clear).
Since a Linux system running on the same machine gets compromised as well, it would be reasonable to assume that this also takes place by the ACPI code's execution. Taking a look at the dmesg output, which I also uploaded on GoogleDrive, seems to confirm this assumption:
[ 0.225468] ACPI: Added _OSI(Module Device)
[ 0.225470] ACPI: Added _OSI(Processor Device)
[ 0.225471] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.225472] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.227433] ACPI: Executed 1 blocks of module-level executable AML code
[ 0.293448] ACPI: Interpreter enabled
[ 0.293458] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20150930/hwxface-580)
[ 0.293469] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.293470] ACPI: Using IOAPIC for interrupt routing
[ 0.293491] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[ 0.294509] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
[ 0.294522] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.298938] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[ 0.298943] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.299051] acpi PNP0A03:00: _OSC: platform does not support [PCIeHotplug PCIeCapability]
[ 0.299099] acpi PNP0A03:00: _OSC: not requesting control; platform does not support [PCIeCapability]
[ 0.299101] acpi PNP0A03:00: _OSC: OS requested [PCIeHotplug PME AER PCIeCapability]
[ 0.299103] acpi PNP0A03:00: _OSC: platform willing to grant [PME AER]
[ 0.299104] acpi PNP0A03:00: _OSC failed (AE_SUPPORT); disabling ASPM
[ 8.647712] ACPI Warning: SystemIO range 0x0000000000000600-0x000000000000063F conflicts with OpRegion 0x0000000000000600-0x00000000000006FF (\_SB_.PCI0.SBRG.ASOC.SMRG) (20150930/utaddress-254)
So I would appreciate it, if anyone would have an idea on how to proceed with a further analysis. It would be interesting, if one would be able to see how exactly the ACPI code's execution interacts with the kernel in order to compromise the system. And of course it would be interesting to discover where the relevant network traffic gets forwarded to / comes in from (for remote access), since the checks I already performed showed that the networking structure got manipulated, so that the usage of Wireshark etc. won't show anything.